From nobody Mon Oct 2 01:10:37 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E053134FFD for ; Mon, 2 Oct 2017 01:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, 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 7rEa4zYuN1Ot for ; Mon, 2 Oct 2017 01:10:28 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8477134FFA for ; Mon, 2 Oct 2017 01:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24229; q=dns/txt; s=iport; t=1506931824; x=1508141424; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=OL/lX1vhH8jVKIA7R0f8nZkax+DjDfOaspSGgULJSOM=; b=J/uKonL/OnWbLVcFzES64C25kwRoKCBW1wSt5i3TqEO3g4MNLPA5irkv 7H51DrvsXjC43m87LrtBrjKigA8ulkjPDMqZdHDnAzJlOvCyxuuz+jXsl Yjel75DrY2uf6tiEoee+EVbh31q64J14iHg9qxqm2WpPBKWA6Xgl9QnpP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQAw89FZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEFuJ4N5ixOQY5Y6ggQKGAEKhElPAoR9FQECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBASFLCxALGBULBwMCAicfEQYNBgIBAYokCBCkaYInJ4sLAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWDLYNTgWorgn2EPy9VglSCYQWYWIhah16NB4tdhyy?= =?us-ascii?q?NeYdbgTk1IkJMMiEIHRVJhGGCPT82hnosghUBAQE?= X-IronPort-AV: E=Sophos;i="5.42,468,1500940800"; d="scan'208,217";a="656148410" 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; 02 Oct 2017 08:10:19 +0000 Received: from [10.63.23.52] (dhcp-ensft1-uk-vla370-10-63-23-52.cisco.com [10.63.23.52]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v928AIim032464; Mon, 2 Oct 2017 08:10:19 GMT To: Andy Bierman Cc: Balazs Lengyel , Martin Bjorklund , "netmod@ietf.org" References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com> From: Robert Wilton Message-ID: <79d37d96-fc49-9d02-201f-663dfdf3d836@cisco.com> Date: Mon, 2 Oct 2017 09:10:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FA54B088E403C1188DB4C8CD" Content-Language: en-US Archived-At: Subject: Re: [netmod] Comments on NMDA-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, 02 Oct 2017 08:10:36 -0000 This is a multi-part message in MIME format. --------------FA54B088E403C1188DB4C8CD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, On 29/09/2017 17:46, Andy Bierman wrote: > > > On Thu, Sep 28, 2017 at 9:28 AM, Robert Wilton > wrote: > > Hi, > > Regarding the issue "Is it allowed to violate uniqueness of key > values?", https://github.com/netmod-wg/datastore-dt/issues/10 > > > We have discussed this further, and would like to extend the text > in the draft to explicitly allow key uniqueness to be violated! > > > so we can rubber-stamp buggy servers? > I do not agree this is needed. So, the aim here is not to standardize buggy servers. The aim here is to ensure that clients understand that the content of the operational state datastore aims to reflect the live operational state of the device.  Because it is reflecting live data, and that data may be constantly changing, it is not possibly to guarantee that the data tree that represents the operational state is always a valid state data tree. > > We have thought of several cases where it is possible that > duplicate entries could appear, and we don't want to force any > overhead on the device to guarantee that this does not occur, nor > do we want to force synchronization between configuration > processing and what is reported in .  Of course, in > normal circumstances this constraint, like the others, should not > be violated. This is already stated in the draft. > > Examples of where uniqueness of list keys could be violated include: > 1) If a device is internally paging the results back for a long > list, then it is possible that a entry could have been reported > near the beginning of the list, then moved, and then reported > again at the end of the list. > > > > The data is question is simply part of an and it is > subject to the validation > requirements for RPC replies only.  Note also that the payload to > represent an arbitrary > configuration datastore has to be done with anydata or anyxml.  RPC > reply validation > rules for these nodes do not extend to contents of the anydata instance. The text in section 4.7  is referring to the validity of the state data tree represented by rather than the contents of an . The same considerations should also apply if the data is being streamed from the device via YANG push, or one of the other telemetry protocols. > > > 2) If the list being stored somewhere in the system has become > corrupted and contains duplicate entries.  It is better to return > truth. > > > > It is better to fix the buggy server. > Again, a representation of some portion of a datastore in an > has nothing to do with the YANG validation of a datastore within a server. I strongly agree that it is better to fix a buggy server, but it becomes much harder to fix if nobody is allowed to see that it is broken in the first place.  I.e. it is better to return the actual data that is wrong than to pretend that it is OK (e.g. by removing any entries that have duplicate keys before returning the data). Do have any objections with the specific text change that I have proposed below. Thanks, Rob > > > 3) On a distributed system where the list is being constructed > from multiple nodes (e.g. linecards or peer devices) then if a > list entry is moved from one node to another then it is again > possible that an entry could be reported in both places (or > neither) for a short interval before the system becomes consistent > again. > > > > Once again, this is an representation, not the validation > of a datastore > within a server. > > > > Andy > > > > Proposed text: > > OLD: > >    SHOULD conform to any constraints specified in > the data >    model, but given the principal aim of returning "in use" values, it >    is possible that constraints MAY be violated under some >    circumstances, e.g., an abnormal value is "in use", or due to > remnant >    configuration (see Section 4.3.1).  Note, that deviations are still >    used when it is known in advance that a device does not fully > conform >    to the schema. > >    Only semantic constraints MAY be violated, these are the YANG > "when", >    "must", "mandatory", "unique", "min-elements", and "max-elements" >    statements. > > NEW: > >    SHOULD conform to any constraints specified in > the data >    model, but given the principal aim of returning "in use" values, it >    is possible that constraints MAY be violated under some >    circumstances, e.g., an abnormal value is "in use", the > structure of >    a list is being modified, or due to remnant configuration (see >    Section 4.3.1).  Note, that deviations are still used when it is >    known in advance that a device does not fully conform to the >    schema. > >    Only semantic constraints MAY be violated, these are the YANG > "when", >    "must", "mandatory", "unique", "min-elements", and "max-elements" >    statements; and the uniqueness of key values. > > Again, if there are no objections, I will apply this change. > > Thanks, > Rob > > > On 14/09/2017 16:44, Balazs Lengyel wrote: > > See below ! > > > On 2017-09-14 16:32, Martin Bjorklund wrote: > > CH 4.4.)  "Validation is performed on the contents of > ." > This to me means that default data is not considered > at validation > > Note that RFC 7950, section 6.4.1, says: > >     In the accessible tree, all leafs and leaf-lists with > default values >     in use exist (see Sections 7.6.1 and 7.7.2). > > So defaults are taken into account when intended is validated. > > BALAZS: Yes the two seem to contradict each other. This can be > understood in your way, however the current text is not clear > enough. I would add: > Validation is performed on the contents of > (EXTENDED WITH DEFAULT CONFIGURATION). > > which would be a backwards incompatible change. Also > if validation > does not consider system configured data that would > allow cases like > multiple interfaces named lo0. One from one > from system > configuration. IMHO while it is OK to violate > uniqueness because of > remnant data, the above violation of uniqueness seems > a bad idea. > > If your system adds data to , or to , > it will be > validated. > > Ch. 4.7) Is it allowed to violate uniqueness of key > values? IMHO it > should not be. > > Agreed.  Note that the draft explicitly lists the > constraints that can > be violated, and uniqueness of keys is not listed. > > BALAZS: If that is the intent I would propose to explicitly > state it. For me it was non-trivial. > Can a a choice statement be violated? Having to existing > branches at the same time? It seems a semantic constraint to > me. IMHO yes. > Can an if-feature be violated? If  support has just changed > and we have some remnant config, I can very well imagine it > violated. > > Also here could you change > If a node in  does not meet the syntactic > constraints then it cannot   be returned > to > If a node in  does not meet the syntactic > constraints then it MUST NOT be returned > > /martin > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --------------FA54B088E403C1188DB4C8CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,


On 29/09/2017 17:46, Andy Bierman wrote:


On Thu, Sep 28, 2017 at 9:28 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi,

Regarding the issue "Is it allowed to violate uniqueness of key values?", https://github.com/netmod-wg/datastore-dt/issues/10

We have discussed this further, and would like to extend the text in the draft to explicitly allow key uniqueness to be violated!


so we can rubber-stamp buggy servers?
I do not agree this is needed.

So, the aim here is not to standardize buggy servers.

The aim here is to ensure that clients understand that the content of the operational state datastore aims to reflect the live operational state of the device.  Because it is reflecting live data, and that data may be constantly changing, it is not possibly to guarantee that the data tree that represents the operational state is always a valid state data tree.



 
We have thought of several cases where it is possible that duplicate entries could appear, and we don't want to force any overhead on the device to guarantee that this does not occur, nor do we want to force synchronization between configuration processing and what is reported in <operational>.  Of course, in normal circumstances this constraint, like the others, should not be violated.  This is already stated in the draft.

Examples of where uniqueness of list keys could be violated include:
1) If a device is internally paging the results back for a long list, then it is possible that a entry could have been reported near the beginning of the list, then moved, and then reported again at the end of the list.


The data is question is simply part of an <rpc-reply> and it is subject to the validation
requirements for RPC replies only.  Note also that the payload to represent an arbitrary
configuration datastore has to be done with anydata or anyxml.  RPC reply validation
rules for these nodes do not extend to contents of the anydata instance.

The text in section 4.7  is referring to the validity of the state data tree represented by <operational> rather than the contents of an <rpc-reply>.

The same considerations should also apply if the data is being streamed from the device via YANG push, or one of the other telemetry protocols.



2) If the list being stored somewhere in the system has become corrupted and contains duplicate entries.  It is better to return truth.


It is better to fix the buggy server.
Again, a representation of some portion of a datastore in an <rpc-reply>
has nothing to do with the YANG validation of a datastore within a server.

I strongly agree that it is better to fix a buggy server, but it becomes much harder to fix if nobody is allowed to see that it is broken in the first place.  I.e. it is better to return the actual data that is wrong than to pretend that it is OK (e.g. by removing any entries that have duplicate keys before returning the data).

Do have any objections with the specific text change that I have proposed below.

Thanks,
Rob




 
3) On a distributed system where the list is being constructed from multiple nodes (e.g. linecards or peer devices) then if a list entry is moved from one node to another then it is again possible that an entry could be reported in both places (or neither) for a short interval before the system becomes consistent again.


Once again, this is an <rpc-reply> representation, not the validation of a datastore
within a server.

 


Andy



Proposed text:

OLD:

   <operational> SHOULD conform to any constraints specified in the data
   model, but given the principal aim of returning "in use" values, it
   is possible that constraints MAY be violated under some
   circumstances, e.g., an abnormal value is "in use", or due to remnant
   configuration (see Section 4.3.1).  Note, that deviations are still
   used when it is known in advance that a device does not fully conform
   to the <operational> schema.

   Only semantic constraints MAY be violated, these are the YANG "when",
   "must", "mandatory", "unique", "min-elements", and "max-elements"
   statements.

NEW:

   <operational> SHOULD conform to any constraints specified in the data
   model, but given the principal aim of returning "in use" values, it
   is possible that constraints MAY be violated under some
   circumstances, e.g., an abnormal value is "in use", the structure of
   a list is being modified, or due to remnant configuration (see
   Section 4.3.1).  Note, that deviations are still used when it is
   known in advance that a device does not fully conform to the
   <operational> schema.

   Only semantic constraints MAY be violated, these are the YANG "when",
   "must", "mandatory", "unique", "min-elements", and "max-elements"
   statements; and the uniqueness of key values.

Again, if there are no objections, I will apply this change.

Thanks,
Rob


On 14/09/2017 16:44, Balazs Lengyel wrote:
See below !


On 2017-09-14 16:32, Martin Bjorklund wrote:

CH 4.4.)  "Validation is performed on the contents of <intended>."
This to me means that default data is not considered at validation
Note that RFC 7950, section 6.4.1, says:

    In the accessible tree, all leafs and leaf-lists with default values
    in use exist (see Sections 7.6.1 and 7.7.2).

So defaults are taken into account when intended is validated.
BALAZS: Yes the two seem to contradict each other. This can be understood in your way, however the current text is not clear enough. I would add:
Validation is performed on the contents of <intended> (EXTENDED WITH DEFAULT CONFIGURATION).
which would be a backwards incompatible change. Also if validation
does not consider system configured data that would allow cases like
multiple interfaces named lo0. One from <intended> one from system
configuration. IMHO while it is OK to violate uniqueness because of
remnant data, the above violation of uniqueness seems a bad idea.
If your system adds data to <running>, or to <intended>, it will be
validated.

Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
should not be.
Agreed.  Note that the draft explicitly lists the constraints that can
be violated, and uniqueness of keys is not listed.
BALAZS: If that is the intent I would propose to explicitly state it. For me it was non-trivial.
Can a a choice statement be violated? Having to existing branches at the same time? It seems a semantic constraint to me. IMHO yes.
Can an if-feature be violated? If  support has just changed and we have some remnant config, I can very well imagine it violated.

Also here could you change
If a node in  <operational> does not meet the syntactic constraints then it cannot   be returned
to
If a node in  <operational> does not meet the syntactic constraints then it MUST NOT be returned
/martin


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


--------------FA54B088E403C1188DB4C8CD-- From nobody Mon Oct 2 02:10:52 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A213448C for ; Mon, 2 Oct 2017 02:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.8 X-Spam-Level: X-Spam-Status: No, score=-11.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTEB6FIdL2Pi for ; Mon, 2 Oct 2017 02:10:49 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B522F132F2C for ; Mon, 2 Oct 2017 02:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1242; q=dns/txt; s=iport; t=1506935448; x=1508145048; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=+fqyTtZ/XBYRk7CRim7UZagYZMmSsR4gMexD1+fD4qA=; b=VXbDZ++aR8dW+GE4NgKrcP4RNp0TDNBJzrbj3dVO/VTjHUDMVRAT46Vh MpCKnzRLPTdBab3viByswcTlLG9PupETHCOtsp4EpI+0rF8yDCt504G2Z DK81GAd2hb1XbT5sakoupeKZIyjN+aBzlCButBckwgkWrW+bliUamVqxg g=; X-IronPort-AV: E=Sophos;i="5.42,468,1500940800"; d="scan'208";a="697696087" 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; 02 Oct 2017 09:10:46 +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 v929Ak9a030821; Mon, 2 Oct 2017 09:10:46 GMT To: "t.petch" , Kent Watsen , Robert Wilton , netmod@ietf.org, Lou Berger References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com> <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net> <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net> From: Benoit Claise Message-ID: <920d0500-e7ea-66ff-5124-a025a438dbac@cisco.com> Date: Mon, 2 Oct 2017 11:10:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions - this appendix is normative X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2017 09:10:50 -0000 Dear all, To avoid any confusion, just clearly mention it.     "This appendix is normative | informative" No need to debate for hours on this. Regards, Benoit > ----- Original Message ----- > From: "Lou Berger" > Sent: Thursday, September 14, 2017 6:06 PM > >> On 9/14/2017 12:36 PM, t.petch wrote: >>> Appendices are Normative if they say that they are Normative. The >>> default is that they are not so say that they are and they are. > This is >>> well established practice. >> Hi Tom, >> My memory (I haven't checked recently) is there is nothing in or >> defined process that says if an Appendix is normative or not. Other >> SDOs certainly have formal definitions here. Within the IETF, my view >> has been that if an appendix includes RFC2119 language, it is >> normative. Actually, strictly speaking, any text in a Standards Track >> RFC that doesn't include RFC2119 language is just informative. > Lou > > Try RFC4910. > > ' This appendix is normative.' > > and not a SHOULD or a MUST in sight. > > Tom Petch > >> Lou >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Oct 2 03:39:50 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F589134590 for ; Mon, 2 Oct 2017 03:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSmULLFVeZFX for ; Mon, 2 Oct 2017 03:39:45 -0700 (PDT) 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 B80E413458F for ; Mon, 2 Oct 2017 03:39:45 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id B93F6215E33 for ; Mon, 2 Oct 2017 04:39:42 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id Gafe1w01i2SSUrH01afhr2; Mon, 02 Oct 2017 04:39:42 -0600 X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=AUd_NHdVAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=2zrnvUJXJ44BzUHwDMAA: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: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=scCuWiYllLXlW806dcROQHzY83O6QYab53yDJly5FuM=; b=FGAyq7fbclPyGRlzuk5TSSWhDX 1w8rUJS+0gHfVx2vBwpOmTZkVF7LzWGcTNjn/vV59K2l86pd7SIlgwFZHgXlRQbbdkUdvjbvKt0sQ PHau5mTNkNIss71rQ2lic0c8l; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:48379 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dyy8Q-001pVW-ME; Mon, 02 Oct 2017 04:39:38 -0600 From: Lou Berger To: Benoit Claise , "t.petch" , Kent Watsen , Robert Wilton , Date: Mon, 02 Oct 2017 06:39:35 -0400 Message-ID: <15edcab6a58.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <920d0500-e7ea-66ff-5124-a025a438dbac@cisco.com> References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com> <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net> <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net> <920d0500-e7ea-66ff-5124-a025a438dbac@cisco.com> User-Agent: AquaMail/1.11.0-568 (build: 101100004) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dyy8Q-001pVW-ME X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:48379 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] upcoming adoptions - this appendix is normative X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2017 10:39:47 -0000 Benoit, I think this and related topic was closed with the conclusion of sticking with 2119 language for normative text in current and future WG docs. We certainly can add this sentence as well. Lou On October 2, 2017 5:11:20 AM Benoit Claise wrote: > Dear all, > > To avoid any confusion, just clearly mention it. >     "This appendix is normative | informative" > No need to debate for hours on this. > > Regards, Benoit >> ----- Original Message ----- >> From: "Lou Berger" >> Sent: Thursday, September 14, 2017 6:06 PM >> >>> On 9/14/2017 12:36 PM, t.petch wrote: >>>> Appendices are Normative if they say that they are Normative. The >>>> default is that they are not so say that they are and they are. >> This is >>>> well established practice. >>> Hi Tom, >>> My memory (I haven't checked recently) is there is nothing in or >>> defined process that says if an Appendix is normative or not. Other >>> SDOs certainly have formal definitions here. Within the IETF, my view >>> has been that if an appendix includes RFC2119 language, it is >>> normative. Actually, strictly speaking, any text in a Standards Track >>> RFC that doesn't include RFC2119 language is just informative. >> Lou >> >> Try RFC4910. >> >> ' This appendix is normative.' >> >> and not a SHOULD or a MUST in sight. >> >> Tom Petch >> >>> Lou >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >> > > From nobody Mon Oct 2 03:55:59 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35701320BD for ; Mon, 2 Oct 2017 03:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tsJP12mempNL for ; Mon, 2 Oct 2017 03:55:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 04D92132055 for ; Mon, 2 Oct 2017 03:55:56 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id B26BB1AE018C; Mon, 2 Oct 2017 12:55:54 +0200 (CEST) Date: Mon, 02 Oct 2017 12:54:25 +0200 (CEST) Message-Id: <20171002.125425.1097312546879219757.mbj@tail-f.com> To: andy@yumaworks.com Cc: rwilton@cisco.com, balazs.lengyel@ericsson.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Comments on NMDA-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, 02 Oct 2017 10:55:58 -0000 Andy Bierman wrote: > On Thu, Sep 28, 2017 at 9:28 AM, Robert Wilton wrote: > > > Hi, > > > > Regarding the issue "Is it allowed to violate uniqueness of key values?", > > https://github.com/netmod-wg/datastore-dt/issues/10 > > > > We have discussed this further, and would like to extend the text in the > > draft to explicitly allow key uniqueness to be violated! > > > > > so we can rubber-stamp buggy servers? One scenario is if you a have large ordered-by user list in , and the server starts to send the entries to a client. Before sending the last entry, the list might change, for example the first entry might have been moved to be last. Now the server might actually send the same entry twice. Another sceanrio is that the server sends a leafref that points to some node that hasn't been sent yet, but before the server gets to that node, it is removed. > I do not agree this is needed. > > > > > We have thought of several cases where it is possible that duplicate > > entries could appear, and we don't want to force any overhead on the device > > to guarantee that this does not occur, nor do we want to force > > synchronization between configuration processing and what is reported in > > . Of course, in normal circumstances this constraint, like > > the others, should not be violated. This is already stated in the draft. > > > > Examples of where uniqueness of list keys could be violated include: > > 1) If a device is internally paging the results back for a long list, then > > it is possible that a entry could have been reported near the beginning of > > the list, then moved, and then reported again at the end of the list. > > > > > The data is question is simply part of an and it is subject to > the validation > requirements for RPC replies only. Do you mean that the validation requirement applies to a pure snapshot of , but is not required to return a pure snapshot, which means that the reply can be invalid? /martin From nobody Mon Oct 2 04:05:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9F213458A for ; Mon, 2 Oct 2017 04:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tGYHwL80J6y for ; Mon, 2 Oct 2017 04:05:12 -0700 (PDT) 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 E4956134292 for ; Mon, 2 Oct 2017 04:05:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BAFF4F68; Mon, 2 Oct 2017 13:05:07 +0200 (CEST) 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 hTp1Y7DVYDCr; Mon, 2 Oct 2017 13:05:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 2 Oct 2017 13:05:07 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E3A1200FD; Mon, 2 Oct 2017 13:05:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XAXo9bVHF4LC; Mon, 2 Oct 2017 13:05:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40FBE200FC; Mon, 2 Oct 2017 13:05:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 46B24411E1FF; Mon, 2 Oct 2017 13:05:04 +0200 (CEST) Date: Mon, 2 Oct 2017 13:05:04 +0200 From: Juergen Schoenwaelder To: Lou Berger Cc: Benoit Claise , "t.petch" , Kent Watsen , Robert Wilton , netmod@ietf.org Message-ID: <20171002110504.d6kscxoot3nb3c3a@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Benoit Claise , "t.petch" , Kent Watsen , Robert Wilton , netmod@ietf.org References: <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com> <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net> <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net> <920d0500-e7ea-66ff-5124-a025a438dbac@cisco.com> <15edcab6a58.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 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: <15edcab6a58.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] upcoming adoptions - this appendix is normative X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2017 11:05:16 -0000 Lou, the conclusion is that we add RFC 2119 here and there but I disagree with the notion that normative text needs RFC 2119 language, i.e., that text that does not use RFC 2119 language is not normative. See the pointers to the RFCs that I have provided. Now you want to make this even a rule for all future WG docs so I strongly oppose to that. /js On Mon, Oct 02, 2017 at 06:39:35AM -0400, Lou Berger wrote: > Benoit, > > I think this and related topic was closed with the conclusion of sticking > with 2119 language for normative text in current and future WG docs. We > certainly can add this sentence as well. > > Lou > > > On October 2, 2017 5:11:20 AM Benoit Claise wrote: > > > Dear all, > > > > To avoid any confusion, just clearly mention it. > >     "This appendix is normative | informative" > > No need to debate for hours on this. > > > > Regards, Benoit > > > ----- Original Message ----- > > > From: "Lou Berger" > > > Sent: Thursday, September 14, 2017 6:06 PM > > > > > > > On 9/14/2017 12:36 PM, t.petch wrote: > > > > > Appendices are Normative if they say that they are Normative. The > > > > > default is that they are not so say that they are and they are. > > > This is > > > > > well established practice. > > > > Hi Tom, > > > > My memory (I haven't checked recently) is there is nothing in or > > > > defined process that says if an Appendix is normative or not. Other > > > > SDOs certainly have formal definitions here. Within the IETF, my view > > > > has been that if an appendix includes RFC2119 language, it is > > > > normative. Actually, strictly speaking, any text in a Standards Track > > > > RFC that doesn't include RFC2119 language is just informative. > > > Lou > > > > > > Try RFC4910. > > > > > > ' This appendix is normative.' > > > > > > and not a SHOULD or a MUST in sight. > > > > > > Tom Petch > > > > > > > Lou > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > . > > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 2 04:59:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948E51345D2 for ; Mon, 2 Oct 2017 04:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-TMH3QUYvsn for ; Mon, 2 Oct 2017 04:59:00 -0700 (PDT) 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 E8B6D1323B4 for ; Mon, 2 Oct 2017 04:58:59 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 1B3C91AB1BE for ; Mon, 2 Oct 2017 05:58:55 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Gbyr1w0072SSUrH01byuhU; Mon, 02 Oct 2017 05:58:55 -0600 X-Authority-Analysis: v=2.2 cv=K/VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=AUd_NHdVAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=fCKLsFGb-9ytqeNey90A: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: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=hS4b1bRSZ8IlML0AuQHZowjopplzeyqykLMGsEo4MlE=; b=TDZqmMKSiLW8ut5H1MnlvbRZSz vrUDmGc/B6w6x8yf4zNe948oCksoAAnxWfCLRzi6Pp8KBkkAN2mWRoCDZfPcZBo0orU213Gq3LTGA LHwN5fqgVbjMTcN1o5CY7ezKE; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:36178 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dyzN5-0023rU-09; Mon, 02 Oct 2017 05:58:51 -0600 To: Benoit Claise , "t.petch" , Kent Watsen , Robert Wilton , netmod@ietf.org References: <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com> <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net> <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net> <920d0500-e7ea-66ff-5124-a025a438dbac@cisco.com> <15edcab6a58.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171002110504.d6kscxoot3nb3c3a@elstar.local> From: Lou Berger Message-ID: <4f2f072c-ff80-30a9-5bc8-08a9d527f52b@labn.net> Date: Mon, 2 Oct 2017 07:58:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171002110504.d6kscxoot3nb3c3a@elstar.local> Content-Type: text/plain; charset=utf-8 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.84.20 X-Exim-ID: 1dyzN5-0023rU-09 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:36178 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] upcoming adoptions - this appendix is normative X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2017 11:59:01 -0000 Juerge, Understood.  I think you made this clear in our previous discussion on this topic, even though ~93% of the RFCs published in the last 5 years use it.   We certainly can discuss this with our AD, and if there's sufficient interest in the WG even discuss it in Singapore. If others are interested in face to face time for such a discussion, please let us (all) know on the list. Cheers, Lou On 10/2/2017 7:05 AM, Juergen Schoenwaelder wrote: > Lou, > > the conclusion is that we add RFC 2119 here and there but I disagree > with the notion that normative text needs RFC 2119 language, i.e., > that text that does not use RFC 2119 language is not normative. See > the pointers to the RFCs that I have provided. Now you want to make > this even a rule for all future WG docs so I strongly oppose to that. > > /js > > On Mon, Oct 02, 2017 at 06:39:35AM -0400, Lou Berger wrote: >> Benoit, >> >> I think this and related topic was closed with the conclusion of sticking >> with 2119 language for normative text in current and future WG docs. We >> certainly can add this sentence as well. >> >> Lou >> >> >> On October 2, 2017 5:11:20 AM Benoit Claise wrote: >> >>> Dear all, >>> >>> To avoid any confusion, just clearly mention it. >>>     "This appendix is normative | informative" >>> No need to debate for hours on this. >>> >>> Regards, Benoit >>>> ----- Original Message ----- >>>> From: "Lou Berger" >>>> Sent: Thursday, September 14, 2017 6:06 PM >>>> >>>>> On 9/14/2017 12:36 PM, t.petch wrote: >>>>>> Appendices are Normative if they say that they are Normative. The >>>>>> default is that they are not so say that they are and they are. >>>> This is >>>>>> well established practice. >>>>> Hi Tom, >>>>> My memory (I haven't checked recently) is there is nothing in or >>>>> defined process that says if an Appendix is normative or not. Other >>>>> SDOs certainly have formal definitions here. Within the IETF, my view >>>>> has been that if an appendix includes RFC2119 language, it is >>>>> normative. Actually, strictly speaking, any text in a Standards Track >>>>> RFC that doesn't include RFC2119 language is just informative. >>>> Lou >>>> >>>> Try RFC4910. >>>> >>>> ' This appendix is normative.' >>>> >>>> and not a SHOULD or a MUST in sight. >>>> >>>> Tom Petch >>>> >>>>> Lou >>>>> >>>> _______________________________________________ >>>> 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 Oct 2 06:09:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026CD134626; Mon, 2 Oct 2017 06:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, 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 7NlOQ6Iw7lFK; Mon, 2 Oct 2017 06:08:48 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C5413461B; Mon, 2 Oct 2017 06:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34534; q=dns/txt; s=iport; t=1506949728; x=1508159328; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to; bh=i1K8DdvO7F4XuVbbfYSYZ9x+Z2I6jU/jpjTETt3uERE=; b=dszUTDQYgMyZmbtvw1kjRfLrzLrw0UnniJKkUmxCF177BK/RWjsbZz0V pfss9WnsIcS6uxLzl2CUUOLMhblxwB7vnYHdiKW7eQEV6RrNW5paT8FTS 3Ez+MQ6hVHLSo0lAVcwtj0NRVc6pknDip5w0KW3eBF8KG/O2m9jqUUvfZ I=; X-IronPort-AV: E=Sophos;i="5.42,469,1500940800"; d="scan'208,217";a="657974512" 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; 02 Oct 2017 13:08:46 +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 v92D8j4h016829; Mon, 2 Oct 2017 13:08:45 GMT To: Andy Bierman , Robert Wilton , "Acee Lindem (acee)" , "netmod@ietf.org" References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz> <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com> <87h8w0bbyf.fsf@nic.cz> From: Benoit Claise Cc: "rtg-dt-yang-arch@ietf.org" , Alia Atlas , "Joe Clarke (jclarke)" Message-ID: Date: Mon, 2 Oct 2017 15:08:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <87h8w0bbyf.fsf@nic.cz> Content-Type: multipart/alternative; boundary="------------22EF1BE0E352524CD612AE6E" Content-Language: en-US Archived-At: Subject: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2017 13:08:52 -0000 This is a multi-part message in MIME format. --------------22EF1BE0E352524CD612AE6E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, [including the routing and multicast YANG design teams] Can we please finalize the discussion regarding ietf-routing versus ietf-routing-2, sooner than later. I care about the NMDA transition strategy. Here are all the ietf-routing dependent YANG modules (those modules that depend on ietf-routing) https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents So many YANG modules. Look at the difference for ietf-routing-2: https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents Some dependent modules are compliant with ietf-routing-2, the multicast YANG modules, but these are the only ones. Changing the module name from ietf-routing to ietf-routing-2 implies that the we have to warn all draft authors of ietf-routing YANG dependent modules:     1. to make sure they are aware of ietf-routing-2  (publishing a RFC8022bis mentioning in the module description that this module is not compatible with the NMDA architecture, and providing a pointer to ietf-routing-2 ... is not an automatic way... so barely useful)     2. to ask them to change their import to ietf-routing-2 Hopefully, in the routing case, it's mainly the IETF. I'm glad that we didn't change the ietf-interfaces to ietf-interfaces-2, we would have to deal with cross SDO/consortia/opensource project issues Note: we're in a transition phase today, while we implement the soon-to-be-published draft-clacla-netmod-model-catalog-02 Because of this, the SDO/consortia/opensource dependent YANG modules will only appear in the Impact Analysis tomorrow at https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents In the mean time, you can see all these dependent modules Ex: https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces         => click on "dependents" Those dependent modules is a new feature of draft-clacla-netmod-model-catalog-02 I'm wondering if this NMDA transition hurdle doesn't make a good justification to keep the same module name! We could debate whether ietf-routing is implemented or not, but the point is moot: we don't know what we don't know. Regarding one point made by Andy: I should explain the use-case for identifying NMDA vs. NMDA-transition modules. I do not want to present both types (for a given module) to the user. So the tools need to know in "NMDA mode" which modules are duplicates for NMDA-transition purpose only, so those modules can be hidden from the user. In "legacy mode" the NMDA modules would be hidden and the transition modules would be exposed to the user instead. Guessing which is which will only cause unhappy customers so we will force vendors to tag the modules with our own YANG extensions to tell them apart. We recognized this use case and tagged the YANG module "tree-type" in the YANG catalog. In the soon-to-be-published but already implemented draft-clacla-netmod-model-catalog-02 draft, you will see: leaf tree-type { type enumeration { enum "split" { description "This module uses a split config/operational state layout."; } enum "nmda-compatible" { description "This module is compatible with the Network Management Datastores Architecture (NMDA) and combines config and operational state nodes."; } enum "transitional-extra" { description "This module is derived as a '-state' module to allow for transitioning to a full NMDA-compliant tree structure."; } enum "openconfig" { description "This module uses the Openconfig data element layout."; } enum "unclassified" { description "This module does not belong to any category or can't be determined."; } enum "not-applicable" { description "This module is not applicable. For example, because the YANG module only contains typedefs, groupings, or is a submodule"; } } description "The type of data element tree used by the module as it relates to the Network Management Datastores Architecture."; reference "draft-dsdt-nmda-guidelines Guidelines for YANG Module Authors (NMDA)"; } description "Grouping of YANG module metadata that extends the common list defined in the YANG Module Library (RFC 7895)."; } If not convinced already, I hope that you start to see the YANG catalog value for the industry. Let's keep in mind that automation is key. Therefore, YANG modules without module details (metadata) and related tools is not sufficient for the industry. Regards, Benoit > Andy Bierman writes: > >> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton wrote: >> >>> >>> On 15/09/2017 16:23, Andy Bierman wrote: >>> >>> Hi, >>> >>> So are you saying the NMDA transition strategy should be ignored? >>> >>> My personal preference for the routing modules would be to keep the same >>> module name and deprecate the old nodes. >>> >>> However, I doubt that there are many implementations of this 8022 yet, and >>> if the authors prefer to use a new namespace without the old nodes then I'm >>> fine with that also. Are you opposed to this approach? >>> >>> >> A new module name mandates a new namespace, so they go together. >> Abandoning the old module is fine, except leaving that module with status >> "current" is not fine. >> IMO you need to republish the old module as well, with everything status >> obsolete. > I don't agree with this. The "status" tag is justified for subsequent > revisions of the same module so as to aid old clients. > > But if the module name and namespace URI are different, there is no such > concern. Modules contained in RFCs 7223, 8022 etc. just define some > schemas that happen to be good for my purposes. So I want to be able to > continue using them, and don't want tools to issue useless warnings or > even refuse to process such modules. > > I am fine though with making a new revision of ietf-routing > etc. mentioning in the module description that this module is not > compatible with the NMDA architecture, and providing a pointer to > ietf-routing-2. > > Lada > >> >> >>> E.g. For ietf-interfaces, and ietf-ip, which are older, and hence probably >>> much more widely implemented then I think that the modules should be >>> updated in place with the existing state tree deprecated. I.e. I support >>> what Martin has done in his IDs, and don't want this to change. >>> >>> What is the problem with deprecated nodes? >>> >>> Nothing really, but I guess that they are likely to be baggage that is >>> going to be around for a long time even if very few people ever implement >>> the deprecated nodes. >>> >>> >>> Why aren't you following your own transition strategy? >>> >>> Really because I'm not an author, both solutions seem valid, and I >>> actually think just reaching a conclusion quickly is more important than >>> which particular solution is chosen. I don't see any advantage is pushing >>> back the adoption call - it seems like it will probably just delay when we >>> can do WG LC. >>> >>> I actually think that the bigger question that needs to be resolved is >>> whether we need an optional extension to mark a module as NMDA compatible, >>> or for the extra NMDA state module, as I think that both you and Tom have >>> been asking for. >>> >> I am no fan of YANG conformance. >> The WG does not seem to understand the difference between >> (A) what a server is supposed to do >> (B) what a server claims to do >> >> There is no way to express (A) in a YANG module, just (B) in the new >> yang-library. >> >> >> Andy >> >> >> >>> Thanks, >>> Rob >>> >>> >>> >>> >>> Andy >>> >>> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton wrote: >>> >>>> >>>> On 15/09/2017 15:52, Acee Lindem (acee) wrote: >>>> >>>>> Hi, >>>>> >>>>> With respect to WG adoption, we will do whatever the WG decides for the >>>>> RFC 8022 model. We have a strong preference toward not carrying the >>>>> deprecated nodes forward and new module versions appears to be a good way >>>>> to achieve this. >>>>> >>>> Can we not adopt regardless? We know that we are going to bis 8022, and >>>> having an adopted draft gives it a bit more legitimacy and helps other >>>> folks to migrate. >>>> >>>> Or perhaps we can start the call for adoption and continue to try and >>>> resolve this issue at the same time ;-). I think that it would be good to >>>> try and get the updated model drafts to WG LC by Singapore. >>>> >>>> I know that it hasn't been asked yet, but I support adoption of any 8022 >>>> bis draft that (i) provides the correct NDMA combined tree (ii) removes or >>>> deprecates the old state nodes :-) >>>> >>>> Sorry, if I'm being pushy :-) >>>> Rob >>>> >>>> >>>> >>>>> I agree with Lada that deprecating all the schema nodes is unnecessary. >>>>> However, we’ll do what it takes to reach consensus and satisfy the most >>>>> pedantic among us. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka" >>>>> wrote: >>>>> >>>>> Kent Watsen píše v ÄŒt 14. 09. 2017 v 14:52 +0000: >>>>>>> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy >>>>>>> module, but does it actually say it? (I can't find it) >>>>>>> >>>>>> The modules contained therein have different names and namespaces, so >>>>>> there is >>>>>> no formal ancestry. I would prefer to keep the modules from RFC 8022 as >>>>>> they are >>>>>> - some weirdos may still want to use them. >>>>>> >>>>>> The draft does say that it obsoletes 8022, but I'm unsure if that's >>>>>>> going to >>>>>>> have a meaningful impact in the wild. I think Juergen said they had >>>>>>> this >>>>>>> issue with MIB2 and only after a couple years of misuse did they >>>>>>> republish the >>>>>>> legacy MIBs with deprecated status. >>>>>>> >>>>>>> I'm okay with this change being made after adoption, so long as there's >>>>>>> general agreement to do it. Are the authors okay with it, or are there >>>>>>> any >>>>>>> better suggestions? >>>>>>> >>>>>>> PS: Sadly, the 'module' statement does not have 'status' as a >>>>>>> substatement [I >>>>>>> just added this omission to the yang-next tracker]. I think the only >>>>>>> way to >>>>>>> "deprecate a module" is to instead deprecate the all the >>>>>>> nodes/rpcs/notifications in the module. Kind of ugly, but it's for a >>>>>>> deprecated module, so who care, right? ;) >>>>>>> >>>>>> I think it is unnecessary. If somebody needs adding such a module to the >>>>>> data >>>>>> model, he/she should probably have a reason to do so, such as data >>>>>> implemented >>>>>> on the server. >>>>>> >>>>>> Lada >>>>>> >>>>>> Kent >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Hi Rob, >>>>>>> >>>>>>> On 9/14/2017 9:37 AM, Robert Wilton wrote: >>>>>>> >>>>>>>> Hi Kent & Lou, >>>>>>>> >>>>>>>> When do you think that it will be possible to start the adoption >>>>>>>> >>>>>>> process >>>>>>> >>>>>>>> on these drafts? >>>>>>>> >>>>>>>> I think that the first two at least would seem to be ready for >>>>>>>> adoption. For the 3rd draft, there still seems to be an open >>>>>>>> >>>>>>> question >>>>>>> >>>>>>>> of what to do with the old state tree, but presumably that could be >>>>>>>> solved after the draft has been adopted? >>>>>>>> >>>>>>> I see an update for the third was published yesterday >>>>>>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02) that >>>>>>> clarifies the intent is to replace the current modules, and presumably >>>>>>> obsolete 8022. And now that this intended direction is clear in the >>>>>>> draft we could poll it. >>>>>>> >>>>>>> I think this still doesn't address if we need to indicate that the >>>>>>> rfc8022 defined modules are deprecated by some other mechanisms than >>>>>>> just replacing the RFC, e.g., by updating the old modules with all >>>>>>> nodes >>>>>>> marked as deprecated. I think you're right that this could be done >>>>>>> post >>>>>>> adoption. Of course others are free to disagree. >>>>>>> >>>>>>> I check with Kent and see what he thinks. >>>>>>> >>>>>>> Thanks, >>>>>>> Lou >>>>>>> >>>>>>> Thanks, >>>>>>>> Rob >>>>>>>> >>>>>>>> >>>>>>>> On 30/08/2017 00:46, Kent Watsen wrote: >>>>>>>> >>>>>>>>> Hey folks, >>>>>>>>> >>>>>>>>> As discussed at the last meeting, we are heading to revising >>>>>>>>> >>>>>>>> existing RFCs >>>>>>>> to align them with NMDA. The first batch have been published as >>>>>>>>> individual drafts: >>>>>>>>> >>>>>>>>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 >>>>>>>>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 >>>>>>>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00 >>>>>>>>> >>>>>>>>> Please take a look (comments welcome!) and stay tuned for the >>>>>>>>> >>>>>>>> related >>>>>>>> adoption calls. >>>>>>>>> Thanks, >>>>>>>>> Kent (and Lou) >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> --------------22EF1BE0E352524CD612AE6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

[including the routing and multicast YANG design teams]
Can we please finalize the discussion regarding ietf-routing versus ietf-routing-2, sooner than later.

I care about the NMDA transition strategy.

Here are all the ietf-routing dependent YANG modules (those modules that depend on ietf-routing)
    https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
So many YANG modules.

Look at the difference for ietf-routing-2:
    https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
Some dependent modules are compliant with ietf-routing-2, the multicast YANG modules, but these are the only ones.

Changing the module name from ietf-routing to ietf-routing-2 implies that the we have to warn all draft authors of ietf-routing YANG dependent modules:
    1. to make sure they are aware of ietf-routing-2  (publishing a RFC8022bis mentioning in the module description that this module is not compatible with the NMDA architecture, and providing a pointer to ietf-routing-2 ... is not an automatic way... so barely useful)
    2. to ask them to change their import to ietf-routing-2
Hopefully, in the routing case, it's mainly the IETF.
I'm glad that we didn't change the ietf-interfaces to ietf-interfaces-2, we would have to deal with cross SDO/consortia/opensource project issues
Note:
we're in a transition phase today, while we implement the soon-to-be-published draft-clacla-netmod-model-catalog-02
Because of this, the SDO/consortia/opensource dependent YANG modules will only appear in the Impact Analysis tomorrow at
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
In the mean time, you can see all these dependent modules
Ex: https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces
        => click on "dependents"
Those dependent modules is a new feature of draft-clacla-netmod-model-catalog-02

I'm wondering if this NMDA transition hurdle doesn't make a good justification to keep the same module name!
We could debate whether ietf-routing is implemented or not, but the point is moot: we don't know what we don't know.

Regarding one point made by Andy:
I should explain the use-case for identifying NMDA vs. NMDA-transition modules.
I do not want to present both types (for a given module) to the user.
So the tools need to know in "NMDA mode" which modules are duplicates
for NMDA-transition purpose only, so those modules can be hidden from the user.
In "legacy mode" the NMDA modules would be hidden and the transition modules
would be exposed to the user instead.

Guessing which is which will only cause unhappy customers so we will force
vendors to tag the modules with our own YANG extensions to tell them apart.
We recognized this use case and tagged the YANG module "tree-type" in the YANG catalog.
In the soon-to-be-published but already implemented draft-clacla-netmod-model-catalog-02 draft, you will see:
leaf tree-type {
      type enumeration {
        enum "split" {
          description
            "This module uses a split config/operational state layout.";
        }
        enum "nmda-compatible" {
          description
            "This module is compatible with the Network Management Datastores
             Architecture (NMDA) and combines config and operational state nodes.";
        }
        enum "transitional-extra" {
          description
            "This module is derived as a '-state' module to allow for transitioning
             to a full NMDA-compliant tree structure.";
        }
        enum "openconfig" {
          description
            "This module uses the Openconfig data element layout.";
        }
        enum "unclassified" {
          description
            "This module does not belong to any category or can't be determined.";
        }
        enum "not-applicable" {
          description
            "This module is not applicable. For example, because the YANG module only contains typedefs, groupings, or is a submodule";
        }
      }
      description
        "The type of data element tree used by the module as it relates to the
         Network Management Datastores Architecture.";
      reference "draft-dsdt-nmda-guidelines Guidelines for YANG Module Authors (NMDA)";
    }
    description
      "Grouping of YANG module metadata that extends the common list defined in the YANG
       Module Library (RFC 7895).";
}

If not convinced already, I hope that you start to see the YANG catalog value for the industry.
Let's keep in mind that automation is key. Therefore, YANG modules without module details (metadata) and related tools is not sufficient for the industry.

Regards, Benoit
Andy Bierman <andy@yumaworks.com> writes:


On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 15/09/2017 16:23, Andy Bierman wrote:

Hi,

So are you saying the NMDA transition strategy should be ignored?

My personal preference for the routing modules would be to keep the same
module name and deprecate the old nodes.

However, I doubt that there are many implementations of this 8022 yet, and
if the authors prefer to use a new namespace without the old nodes then I'm
fine with that also.  Are you opposed to this approach?



A new module name mandates a new namespace, so they go together.
Abandoning the old module is fine, except leaving that module with status
"current" is not fine.
IMO you need to republish the old module as well, with everything status
obsolete.

I don't agree with this. The "status" tag is justified for subsequent
revisions of the same module so as to aid old clients.

But if the module name and namespace URI are different, there is no such
concern. Modules contained in RFCs 7223, 8022 etc. just define some
schemas that happen to be good for my purposes. So I want to be able to
continue using them, and don't want tools to issue useless warnings or
even refuse to process such modules.

I am fine though with making a new revision of ietf-routing
etc. mentioning in the module description that this module is not
compatible with the NMDA architecture, and providing a pointer to
ietf-routing-2.

Lada





E.g. For ietf-interfaces, and ietf-ip, which are older, and hence probably
much more widely implemented then I think that the modules should be
updated in place with the existing state tree deprecated.  I.e. I support
what Martin has done in his IDs, and don't want this to change.

What is the problem with deprecated nodes?

Nothing really, but I guess that they are likely to be baggage that is
going to be around for a long time even if very few people ever implement
the deprecated nodes.


Why aren't you following your own transition strategy?

Really because I'm not an author, both solutions seem valid, and I
actually think just reaching a conclusion quickly is more important than
which particular solution is chosen.  I don't see any advantage is pushing
back the adoption call - it seems like it will probably just delay when we
can do WG LC.

I actually think that the bigger question that needs to be resolved is
whether we need an optional extension to mark a module as NMDA compatible,
or for the extra NMDA state module, as I think that both you and Tom have
been asking for.


I am no fan of YANG conformance.
The WG does not seem to understand the difference between
   (A) what a server is supposed to do
   (B) what a server claims to do

There is no way to express (A) in a YANG module, just (B) in the new
yang-library.


Andy




Thanks,
Rob




Andy

On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 15/09/2017 15:52, Acee Lindem (acee) wrote:


Hi,

With respect to WG adoption, we will do whatever the WG decides for the
RFC 8022 model. We have a strong preference toward not carrying the
deprecated nodes forward and new module versions appears to be a good way
to achieve this.


Can we not adopt regardless?  We know that we are going to bis 8022, and
having an adopted draft gives it a bit more legitimacy and helps other
folks to migrate.

Or perhaps we can start the call for adoption and continue to try and
resolve this issue at the same time ;-).  I think that it would be good to
try and get the updated model drafts to WG LC by Singapore.

I know that it hasn't been asked yet, but I support adoption of any 8022
bis draft that (i) provides the correct NDMA combined tree (ii) removes or
deprecates the old state nodes :-)

Sorry, if I'm being pushy :-)
Rob




I agree with Lada that deprecating all the schema nodes is unnecessary.
However, we’ll do what it takes to reach consensus and satisfy the most
pedantic among us.

Thanks,
Acee

On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
<netmod-bounces@ietf.org on behalf of lhotka@nic.cz> wrote:

Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:


                

                  
rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy
module, but does it actually say it?  (I can't find it)



                

                
The modules contained therein have different names and namespaces, so
there is
no formal ancestry. I would prefer to keep the modules from RFC 8022 as
they are
- some weirdos may still want to use them.

The draft does say that it obsoletes 8022, but I'm unsure if that's


                

                  
going to
have a meaningful impact in the wild.  I think Juergen said they had
this
issue with MIB2 and only after a couple years of misuse did they
republish the
legacy MIBs with deprecated status.

I'm okay with this change being made after adoption, so long as there's
general agreement to do it.  Are the authors okay with it, or are there
any
better suggestions?

PS: Sadly, the 'module' statement does not have 'status' as a
substatement [I
just added this omission to the yang-next tracker].  I think the only
way to
"deprecate a module" is to instead deprecate the all the
nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
deprecated module, so who care, right?  ;)



                

                
I think it is unnecessary. If somebody needs adding such a module to the
data
model, he/she should probably have a reason to do so, such as data
implemented
on the server.

Lada

Kent


                

                  

--

Hi Rob,

On 9/14/2017 9:37 AM, Robert Wilton wrote:



                  

                    
Hi Kent & Lou,

When do you think that it will be possible to start the adoption



                  

                  
process



                  

                    
on these drafts?

I think that the first two at least would seem to be ready for
adoption.  For the 3rd draft, there still seems to be an open



                  

                  
question



                  

                    
of what to do with the old state tree, but presumably that could be
solved after the draft has been adopted?



                  

                  
I see an update for the third was published yesterday
(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
clarifies the intent is to replace the current modules, and presumably
obsolete 8022.  And now that this intended direction is clear in the
draft we could poll it.

I think this still doesn't address if we need to indicate that the
rfc8022 defined modules are deprecated by some other mechanisms than
just replacing the RFC, e.g., by updating the old modules with all
nodes
marked as deprecated.  I think you're right that this could be done
post
adoption.  Of course others are free to disagree.

I check with Kent and see what he thinks.

Thanks,
Lou

Thanks,


                  

                    
Rob


On 30/08/2017 00:46, Kent Watsen wrote:



                    

                      
Hey folks,

As discussed at the last meeting, we are heading to revising



                    

                    
existing RFCs


                  

                  

                  

                    
to align them with NMDA.  The first batch have been published as


                    

                      
individual drafts:

1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

Please take a look (comments welcome!) and stay tuned for the



                    

                    
related


                  

                  

                  

                    
adoption calls.


                    

                      
Thanks,
Kent (and Lou)


_______________________________________________
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

_______________________________________________
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



          

          




        

      

      

    

    

  


--------------22EF1BE0E352524CD612AE6E--


From nobody Mon Oct  2 06:15:48 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F3E134628 for ; Mon,  2 Oct 2017 06:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 fxuRNIA4VyUx for ; Mon,  2 Oct 2017 06:15:45 -0700 (PDT)
Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [63.128.21.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05722132F8F for ; Mon,  2 Oct 2017 06:15:44 -0700 (PDT)
Received: from ex-hc3.corp.adtran.com (ex-hc2.adtran.com [76.164.174.82]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-198-azeHjrDQMcO-GY9_Tg_Qeg-1; Mon, 02 Oct 2017 09:15:42 -0400
Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0361.001; Mon, 2 Oct 2017 08:15:40 -0500
From: JOEY BOYD 
To: "'netmod@ietf.org'" 
Thread-Topic: Backward Compatibility Question
Thread-Index: AdM3mbcvie9AP8VEQcaGGyl32renDQD5rWMg
Date: Mon, 2 Oct 2017 13:15:40 +0000
Message-ID: <26CE489EF4611643B3EFE43D06E02654015E7548A6@ex-mb1.corp.adtran.com>
References: <26CE489EF4611643B3EFE43D06E02654015E751148@ex-mb1.corp.adtran.com>
In-Reply-To: <26CE489EF4611643B3EFE43D06E02654015E751148@ex-mb1.corp.adtran.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.112.103]
MIME-Version: 1.0
X-MC-Unique: azeHjrDQMcO-GY9_Tg_Qeg-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Backward Compatibility Question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 13:15:47 -0000

Hello,

Does anyone have thoughts on this?

Regards,
Joey

-----Original Message-----
From: JOEY BOYD=20
Sent: Wednesday, September 27, 2017 9:06 AM
To: 'netmod@ietf.org'
Subject: Backward Compatibility Question

Hi all,

Suppose I had a published YANG model with the following leaf.


  leaf thing1 {
    type uint8;
    description
      "Thing 1.";
  }

Later, I realize that I wish I had modeled this in a choice as I now have a=
 mutually exclusive option to 'thing1' which I want to add to the model.

  leaf thing2 {
    type empty;
    description
      "Thing 2.";
  }

This is a very simplified example but should be sufficient to demonstrate t=
he problem.=20

If I look at the XML representation of 'thing1', it looks like this.

123

If I were to move 'thing1' into a choice with a single case, it would look =
like this.

choice things {
  case thing1 {
    leaf thing1 {
      type uint8;
      description
        "Thing 1.";
    }
  }
}

Looking to the XML representation, it looks the same as before.

123

To me, this means that taking a single node or set of nodes and moving them=
 under a case within a new choice statement is a backward compatible change=
. This assumes, of course, any mandatory or default behavior is preserved. =
I now can add 'thing2' to the existing model as an option to 'thing1'.

choice things {
  case thing1 {
    leaf thing1 {
      type uint8;
      description
        "Thing 1.";
    }
  }
  case thing2 {
    leaf thing2 {
      type empty;
      description
        "Thing 2.";
    }
  }
}

Do you agree with this analysis or am I missing something?

Best regards,
Joey


From nobody Mon Oct  2 07:18:07 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73ADF1345D4 for ; Mon,  2 Oct 2017 07:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 Z1ri-WIO6WZy for ; Mon,  2 Oct 2017 07:18:03 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D09134611 for ; Mon,  2 Oct 2017 07:18:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3703; q=dns/txt; s=iport; t=1506953883; x=1508163483; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=4hxo+/xLG/4vTfaOl29EB/R0qibTJQI+5+Xorat9bxU=; b=YoHPeIGmDbaYtbdtAyHxuV3d3n4NNreHMieNg4oJfXpcUAp1WOhz/+hn QbM4Q8xT9JlfSTbXIAVD041U51pnI5zBLcWRRtjtiQBg2mU5eTK0PW/II L//88V6kMum8zp4rQ+Q3glKxyEenAlXvIxkDKQiGfsGzvoVnq1KeTOfLV o=;
X-IronPort-AV: E=Sophos;i="5.42,469,1500940800"; d="scan'208";a="697702083"
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 Oct 2017 14:18:01 +0000
Received: from [10.63.23.52] (dhcp-ensft1-uk-vla370-10-63-23-52.cisco.com [10.63.23.52]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v92EI0Ka015358; Mon, 2 Oct 2017 14:18:01 GMT
To: Lou Berger , Benoit Claise , "t.petch" , Kent Watsen , netmod@ietf.org
References: <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>  <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net> <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net> <920d0500-e7ea-66ff-5124-a025a438dbac@cisco.com> <15edcab6a58.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171002110504.d6kscxoot3nb3c3a@elstar.local> <4f2f072c-ff80-30a9-5bc8-08a9d527f52b@labn.net>
From: Robert Wilton 
Message-ID: <4aac1910-dee9-9a8f-0b4a-1adf3103c9d4@cisco.com>
Date: Mon, 2 Oct 2017 15:18:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <4f2f072c-ff80-30a9-5bc8-08a9d527f52b@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] upcoming adoptions - this appendix is normative
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 14:18:06 -0000

This discussion may be conflating two issues:

(i) Does RFC text have to use RFC2119 terms to be normative?
RFC 8174 categorically states that text can still be normative without 
using RFC 2119 terms.

(ii) Should standards track documents use RFC 2119 terms?
If 93% of recently published standards track RFCs make use of RFC 2119 
terms then that seems like a strong consistency argument to use them 
unless there is a good reason not to.

We've already agreed that the datastores draft will use RFC 2119 terms 
where appropriate.  For the model drafts, Benoit's suggestion to state 
that the appendix is normative seems like an easy solution where it is 
required.

If it gets discussed at Singapore then I would suggest doing so at a bar 
rather than spending WG time on it ;-)

Cheers,
Rob


On 02/10/2017 12:58, Lou Berger wrote:
> Juerge,
>
> Understood.  I think you made this clear in our previous discussion on
> this topic, even though ~93% of the RFCs published in the last 5 years
> use it.   We certainly can discuss this with our AD, and if there's
> sufficient interest in the WG even discuss it in Singapore. If others
> are interested in face to face time for such a discussion, please let us
> (all) know on the list.
>
> Cheers,
>
> Lou
>
> On 10/2/2017 7:05 AM, Juergen Schoenwaelder wrote:
>> Lou,
>>
>> the conclusion is that we add RFC 2119 here and there but I disagree
>> with the notion that normative text needs RFC 2119 language, i.e.,
>> that text that does not use RFC 2119 language is not normative. See
>> the pointers to the RFCs that I have provided. Now you want to make
>> this even a rule for all future WG docs so I strongly oppose to that.
>>
>> /js
>>
>> On Mon, Oct 02, 2017 at 06:39:35AM -0400, Lou Berger wrote:
>>> Benoit,
>>>
>>> I think this and related topic was closed with the conclusion of sticking
>>> with 2119 language for normative text in current and future WG docs. We
>>> certainly can add this sentence as well.
>>>
>>> Lou
>>>
>>>
>>> On October 2, 2017 5:11:20 AM Benoit Claise  wrote:
>>>
>>>> Dear all,
>>>>
>>>> To avoid any confusion, just clearly mention it.
>>>>       "This appendix is normative | informative"
>>>> No need to debate for hours on this.
>>>>
>>>> Regards, Benoit
>>>>> ----- Original Message -----
>>>>> From: "Lou Berger" 
>>>>> Sent: Thursday, September 14, 2017 6:06 PM
>>>>>
>>>>>> On 9/14/2017 12:36 PM, t.petch wrote:
>>>>>>> Appendices are Normative if they say that they are Normative.  The
>>>>>>> default is that they are not so say that they are and they are.
>>>>> This is
>>>>>>> well established practice.
>>>>>> Hi Tom,
>>>>>> My memory (I haven't checked recently) is there is nothing in or
>>>>>> defined process that says if an Appendix is normative or not. Other
>>>>>> SDOs certainly have formal definitions here. Within the IETF, my view
>>>>>> has been that if an appendix includes RFC2119 language, it is
>>>>>> normative. Actually, strictly speaking, any text in a Standards Track
>>>>>> RFC that doesn't include RFC2119 language is just informative.
>>>>> Lou
>>>>>
>>>>> Try RFC4910.
>>>>>
>>>>> '   This appendix is normative.'
>>>>>
>>>>> and not a SHOULD or a MUST in sight.
>>>>>
>>>>> Tom Petch
>>>>>
>>>>>> Lou
>>>>>>
>>>>> _______________________________________________
>>>>> 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 Oct  2 08:58:00 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8886A13304D for ; Mon,  2 Oct 2017 08:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.801
X-Spam-Level: 
X-Spam-Status: No, score=-11.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDVQxIoFWIpO for ; Mon,  2 Oct 2017 08:57:57 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2BE132811 for ; Mon,  2 Oct 2017 08:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1888; q=dns/txt; s=iport; t=1506959876; x=1508169476; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=8FiRAnjZgarHZEM2hOda67GebqXERWF9QuyZ/F2Kmxk=; b=QbRAQnuJrxq+cHlTvuT4RCjZaxio4Re2ZSUzAtisgj9UjOgVGwzFAcF7 AUtOhrsSkBxqg4lz7cqnL1hCdah5v1qEgCiwQZPPpB4h2mpzyhclMMmdS 5wWjyOvjugUzG5jufG0OkRkjOq7byd36z75NS+4lHjt2LaKOyDT7ZdrvM M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQCyYNJZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhS+EIIsTqSMKikEUAQIBAQEBAQEBax0LhUIPAQV2AiYCUwwNCAEBF4o?= =?us-ascii?q?VlTGQEYIniy0BCyaBDoIfg1OCFYd0gyCCYQWhMpRli12HLI15h1uBOTYhgQ4yI?= =?us-ascii?q?QgdFYdnP4gGgkEBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,470,1500940800"; d="scan'208";a="656157489"
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; 02 Oct 2017 15:57:52 +0000
Received: from [10.63.23.52] (dhcp-ensft1-uk-vla370-10-63-23-52.cisco.com [10.63.23.52]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v92FvqfQ021460 for ; Mon, 2 Oct 2017 15:57:52 GMT
From: Robert Wilton 
To: "netmod@ietf.org" 
Message-ID: <4cd17980-d898-58cf-3c01-5d8fafadca04@cisco.com>
Date: Mon, 2 Oct 2017 16:57:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] import by revision and updated modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 15:57:58 -0000

Ideally, I think that it would be good if the ietf-routing module could 
be upgraded in place without a namespace change.

However, one problem with this approach is that it looks like YANG's 
"import by revision" doesn't help in the way that one might hope:

If ietf-routing is published with revision B, then ideally all the 
modules that are augmenting from ietf-routing would be able to indicate 
that they need at least revision B.

The YANG import revision-date keyword doesn't help because that means 
that they have to import exactly revision B.  So we could have 30+ 
augmenting modules that all import with ietf-routing revision B.  E.g. 
if import revision-date was used then what happens when a new revision C 
of ietf-routing needs to be provided, perhaps to add an extra leaf?  
Suddenly all those modules that previously used revision-date to import 
revision B would need to have a new version published to import revision 
C! Naturally, this problem would recurse down to all other augmenting 
modules, anywhere where import by revision is used.  This sounds like it 
would be a maintenance nightmare.

It seems like the "import with revision-date" functionality in YANG may 
not help with this upgrade problem, and perhaps a more useful variant 
would be an "import with at least revision X" that would accept any 
revision X or later.  This might be another feature request for YANG 
2.0.  Or perhaps this could be solved more elegantly with some proper 
semantic versioning of YANG modules.

I guess that for ietf-routing, the pragmatic solution would be for 
dependent modules to use 'import' and not 'import by revision'.  Perhaps 
with a comment indicating which module they are dependent on.

Thinking about it further, I am slightly unsure when using "import with 
revision-date" is a genuinely good idea.

Thanks,
Rob



From nobody Mon Oct  2 09:27:54 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACECE1344D0 for ; Mon,  2 Oct 2017 09:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fOTMS-aD_Wj for ; Mon,  2 Oct 2017 09:27:43 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C87133059 for ; Mon,  2 Oct 2017 09:27:42 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id n140so4385928lfn.4 for ; Mon, 02 Oct 2017 09:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AT7uTFYZFNXUTexjmGDrHCRcfzt0wDbWFKEUMqvu1Ok=; b=mX2WKsTRnNanVUfQl1eGD4E8vxL179KSqvSeNf+/BUdYAAUSEDLQujKHgjz51I8/Y+ kFlt3rjRXL1I1UR1t8SSgAaA5kYW6N/yKZnz1SpAIblfELHjmkb9X/GL49/wZ1f5bFPJ uWuDMQ/HUeTNbS2ExiPBD1b4YUrMK13aQHIIKe6/Q7k9POdrwYcc7cHzpQY0wBrfhbKZ Adcn9yWmw3GsK61ag2DdwHeO1Co6/smoT4NEkZMYJnqcQEVVL3aSNEUfluTaEPT55qqO jRL5uU5y9i2pDdThBpXBoOL+ZT6livUASv6Z3VrY3Dhd20AyyVs32J7Nh1HXFm0HrERf Z2vA==
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=AT7uTFYZFNXUTexjmGDrHCRcfzt0wDbWFKEUMqvu1Ok=; b=B/GW/u17SMhthKp0Nfn9gmRFyQRvTmBZjeZf8r6Cv8QUgRvzs0KiDJ59+pOYjp9WAs t0q4NGTepR205TGCIzNjc3S8SD3eXHYvBdlIXPch80FiGhJU3pUhy2+odM8Np2cUrtlk 106H9fExScASe65kO0uKPNcLHv9pa739Rltn5Qk1XYucihu7nrC9Y7ImKwXWFIBFhKNK dIQlul+qtELZMX5l0snadSpT0qyh/NaV9PfT8NVzdPITl8f+HJ/9fnjArZBuCZZWhPt/ wW1uiVmmjFM9nZwWhwJ7oSgo88mVJucnzBeuEPQEfwVj/MbLrHFSS8EoIMIZC1QZoCuy PBSg==
X-Gm-Message-State: AHPjjUhvvLOB1pyrHymw5qSsNs1e3hG+Klq/3fModz+m3R3y1XEzq+eA YkwLqPw9VEz7h5+uitBpVAj2/a+/tEVqRxSWCTOSyQ==
X-Google-Smtp-Source: AOwi7QBi6gBFbXCGV7bRj7Hwjj5iFLbgYG9TUCQpgYD8+w55a581uceUucUZzggQfqRpxmeXyNHhQr1nh8rNow26xRs=
X-Received: by 10.46.83.17 with SMTP id h17mr7370128ljb.158.1506961660681; Mon, 02 Oct 2017 09:27:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.143.139 with HTTP; Mon, 2 Oct 2017 09:27:39 -0700 (PDT)
In-Reply-To: <26CE489EF4611643B3EFE43D06E02654015E7548A6@ex-mb1.corp.adtran.com>
References: <26CE489EF4611643B3EFE43D06E02654015E751148@ex-mb1.corp.adtran.com> <26CE489EF4611643B3EFE43D06E02654015E7548A6@ex-mb1.corp.adtran.com>
From: Andy Bierman 
Date: Mon, 2 Oct 2017 09:27:39 -0700
Message-ID: 
To: JOEY BOYD 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1ced7079e013055a92da48"
Archived-At: 
Subject: Re: [netmod] Backward Compatibility Question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 16:27:53 -0000

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

On Mon, Oct 2, 2017 at 6:15 AM, JOEY BOYD  wrote:

> Hello,
>
> Does anyone have thoughts on this?
>

The choice and case nodes are schema nodes so they are never an issue
for data tree XPath such as must/when.

The change works in your example because a leaf cannot be augmented.
If it was container and some other module augmented it, that module
will break if the container is changed to a choice.



>
> Regards,
> Joey
>

Andy


>
> -----Original Message-----
> From: JOEY BOYD
> Sent: Wednesday, September 27, 2017 9:06 AM
> To: 'netmod@ietf.org'
> Subject: Backward Compatibility Question
>
> Hi all,
>
> Suppose I had a published YANG model with the following leaf.
>
>
>   leaf thing1 {
>     type uint8;
>     description
>       "Thing 1.";
>   }
>
> Later, I realize that I wish I had modeled this in a choice as I now have
> a mutually exclusive option to 'thing1' which I want to add to the model.
>
>   leaf thing2 {
>     type empty;
>     description
>       "Thing 2.";
>   }
>
> This is a very simplified example but should be sufficient to demonstrate
> the problem.
>
> If I look at the XML representation of 'thing1', it looks like this.
>
> 123
>
> If I were to move 'thing1' into a choice with a single case, it would look
> like this.
>
> choice things {
>   case thing1 {
>     leaf thing1 {
>       type uint8;
>       description
>         "Thing 1.";
>     }
>   }
> }
>
> Looking to the XML representation, it looks the same as before.
>
> 123
>
> To me, this means that taking a single node or set of nodes and moving
> them under a case within a new choice statement is a backward compatible
> change. This assumes, of course, any mandatory or default behavior is
> preserved. I now can add 'thing2' to the existing model as an option to
> 'thing1'.
>
> choice things {
>   case thing1 {
>     leaf thing1 {
>       type uint8;
>       description
>         "Thing 1.";
>     }
>   }
>   case thing2 {
>     leaf thing2 {
>       type empty;
>       description
>         "Thing 2.";
>     }
>   }
> }
>
> Do you agree with this analysis or am I missing something?
>
> Best regards,
> Joey
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Mon, Oct 2, 2017 at 6:15 AM, JOEY BOYD <joey.boyd@adtran.com=
> wrote:
Hello,



Does anyone have thoughts on this?

The =
choice and case nodes are schema nodes so they are never an issue
for data tree XPath such as must/when.

The change=
 works in your example because a leaf cannot be augmented.
If it =
was container and some other module augmented it, that module
wil=
l break if the container is changed to a choice.

=
=C2=A0



Regards,

Joey

Andy
=C2=A0



-----Original Message-----

From: JOEY BOYD

Sent: Wednesday, September 27, 2017 9:06 AM

To: 'netmod@ietf.org'

Subject: Backward Compatibility Question



Hi all,



Suppose I had a published YANG model with the following leaf.





=C2=A0 leaf thing1 {

=C2=A0 =C2=A0 type uint8;

=C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 "Thing 1.";

=C2=A0 }



Later, I realize that I wish I had modeled this in a choice as I now have a=
 mutually exclusive option to 'thing1' which I want to add to the m=
odel.



=C2=A0 leaf thing2 {

=C2=A0 =C2=A0 type empty;

=C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 "Thing 2.";

=C2=A0 }



This is a very simplified example but should be sufficient to demonstrate t=
he problem.



If I look at the XML representation of 'thing1', it looks like this=
.



<thing1>123</thing1>



If I were to move 'thing1' into a choice with a single case, it wou=
ld look like this.



choice things {

=C2=A0 case thing1 {

=C2=A0 =C2=A0 leaf thing1 {

=C2=A0 =C2=A0 =C2=A0 type uint8;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thing 1.";

=C2=A0 =C2=A0 }

=C2=A0 }

}



Looking to the XML representation, it looks the same as before.



<thing1>123</thing1>



To me, this means that taking a single node or set of nodes and moving them=
 under a case within a new choice statement is a backward compatible change=
. This assumes, of course, any mandatory or default behavior is preserved. =
I now can add 'thing2' to the existing model as an option to 't=
hing1'.



choice things {

=C2=A0 case thing1 {

=C2=A0 =C2=A0 leaf thing1 {

=C2=A0 =C2=A0 =C2=A0 type uint8;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thing 1.";

=C2=A0 =C2=A0 }

=C2=A0 }

=C2=A0 case thing2 {

=C2=A0 =C2=A0 leaf thing2 {

=C2=A0 =C2=A0 =C2=A0 type empty;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thing 2.";

=C2=A0 =C2=A0 }

=C2=A0 }

}



Do you agree with this analysis or am I missing something?



Best regards,

Joey



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1ced7079e013055a92da48--


From nobody Mon Oct  2 09:31:41 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D231344C6 for ; Mon,  2 Oct 2017 09:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 Bd3V95smBhY9 for ; Mon,  2 Oct 2017 09:31:37 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0124.outbound.protection.outlook.com [104.47.40.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261E313234B for ; Mon,  2 Oct 2017 09:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h1t4K2kFAX/vsoMgQfvcs1nyVnWhlwPInAU+i1Z1zug=; b=B+7xhPApIPWe1epNhmRFmUf435tv5hqc1eYpiya/JzYxE+gwEzaabHL6zjtgR2d1YhPhAVAw3YjsrXg4USkvUUnZjXpvrTYh7tKJRz8gjBA2f7T6h93J84qv1Jc/0nau1oYKcF5iHKedc42grfnrs80dkclwD7iGwJ7tkwWCZG0=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Mon, 2 Oct 2017 16:31:35 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Mon, 2 Oct 2017 16:31:35 +0000
From: Kent Watsen 
To: JOEY BOYD , "'netmod@ietf.org'" 
Thread-Topic: [netmod] Backward Compatibility Question
Thread-Index: AQHTO5vpie9AP8VEQcaGGyl32renDQ==
Date: Mon, 2 Oct 2017 16:31:35 +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; BLUPR05MB273; 6:ta3QCUK3dpLIDGdhtPmiKFNhqvrHgT3RRGVajHKAIXKM4hUlY8ss2DGZK2G6L3jEFh4/oghUAk7hHioB6UZniqpZKlql+vqZUMQMjn0VisnkXNw/LCkbYzJ6l07iH0t2k70/hoPaQwk2USo/BWaymqIwexXliSafrl7Vw33f740rRCpm9+7AzUfcOuyjRyQSR5BfqZvpYE6f9LSUsd/GCbHgj5/oltUppml+7DZCQmxVbcs9FjtVYHZlLdraa9P9huwQ9olKO3jIkuOiR6fsEhmyX13EgKac2qJ9s/gsXBgotpr8vEAcvBukfhiPtIfJFsaaQlI3exDBHwQbVV1o/Q==; 5:Xe7wSvNuLP6uu30WcmBSvCfOkTCtNq4nP4rRRjWk/huKgYE1GdIIJsHVJNHz4nPvr3/pG0PCKwYZtx9iES+oVocw9wCmxLa/wNlqlrO0o/brb+Gg8Obi0Pe1+yYUbCMgVDhBkDmXB5glzTby3UQXzw==; 24:ehXNMDaWdyiKjTT4LREJEN9CLJs/xwh7eC7gfF3vBSftKmnxlzgrfSV5GFCjLS+4eDq35jR4D6SfP7O+GOMoyRUuB/H90ridKiWBwuwC2Bk=; 7:k2M0G6GG0iBDirMyvqysX+afx5xH1Tc8J2T3o1NlGgVOqTkqCPdOSW8O+uT9fZQz5LaZPsi+JEuyY2WwjIucQn3Fa4VzTz1plp8Rt3qd+ZWxTwWYN+ANB/1OTAt5QKRwA0HxzrCnsl+Amc0pJZVXW+u8olcHHkLbgfGAPGsy5/w/206uMci2engjDV7tTenMvQlCLj/Y8mc8XfP05pUmzoCPjFoUqF2XI7yN7Fi/ei0=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 011f3cc0-151a-400f-7010-08d509b30c8c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB273; 
x-ms-traffictypediagnostic: BLUPR05MB273:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(12181511122)(6055026)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB273; 
x-forefront-prvs: 0448A97BF2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(377454003)(189002)(53754006)(13464003)(199003)(6116002)(66066001)(97736004)(102836003)(36756003)(3846002)(3660700001)(58126008)(83506001)(110136005)(966005)(53936002)(2906002)(189998001)(3280700002)(478600001)(6246003)(86362001)(575784001)(83716003)(14454004)(25786009)(229853002)(561944003)(77096006)(105586002)(106356001)(33656002)(82746002)(5660300001)(81156014)(2900100001)(68736007)(8936002)(8676002)(54356999)(53546010)(305945005)(7736002)(6306002)(99286003)(6506006)(81166006)(50986999)(6486002)(6436002)(316002)(6512007)(101416001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 16:31:35.6338 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273
Archived-At: 
Subject: Re: [netmod] Backward Compatibility Question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 16:31:39 -0000

SGkgSm9leSwNCg0KWW91ciBwcm9wb3NhbCBsb29rcyBmaW5lIHRvIG1lLCBzaW5jZSBpdCBkb2Vz
bid0IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mIHRoZSBkYXRhIG1vZGVsLiAgTm90ZSB0aGF0IGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tMTEgc2F5czoNCg0KICAg
byAgQW55IHNldCBvZiBkYXRhIGRlZmluaXRpb24gbm9kZXMgbWF5IGJlIHJlcGxhY2VkIHdpdGgg
YW5vdGhlciBzZXQNCiAgICAgIG9mIHN5bnRhY3RpY2FsbHkgYW5kIHNlbWFudGljYWxseSBlcXVp
dmFsZW50IG5vZGVzLiAgRm9yIGV4YW1wbGUsDQogICAgICBhIHNldCBvZiBsZWFmcyBtYXkgYmUg
cmVwbGFjZWQgYnkgYSAidXNlcyIgc3RhdGVtZW50IG9mIGEgZ3JvdXBpbmcNCiAgICAgIHdpdGgg
dGhlIHNhbWUgbGVhZnMuDQoNCktlbnQNCg0KLS0NCg0KSGVsbG8sDQoNCkRvZXMgYW55b25lIGhh
dmUgdGhvdWdodHMgb24gdGhpcz8NCg0KUmVnYXJkcywNCkpvZXkNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IEpPRVkgQk9ZRCANClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVy
IDI3LCAyMDE3IDk6MDYgQU0NClRvOiAnbmV0bW9kQGlldGYub3JnJw0KU3ViamVjdDogQmFja3dh
cmQgQ29tcGF0aWJpbGl0eSBRdWVzdGlvbg0KDQpIaSBhbGwsDQoNClN1cHBvc2UgSSBoYWQgYSBw
dWJsaXNoZWQgWUFORyBtb2RlbCB3aXRoIHRoZSBmb2xsb3dpbmcgbGVhZi4NCg0KDQogIGxlYWYg
dGhpbmcxIHsNCiAgICB0eXBlIHVpbnQ4Ow0KICAgIGRlc2NyaXB0aW9uDQogICAgICAiVGhpbmcg
MS4iOw0KICB9DQoNCkxhdGVyLCBJIHJlYWxpemUgdGhhdCBJIHdpc2ggSSBoYWQgbW9kZWxlZCB0
aGlzIGluIGEgY2hvaWNlIGFzIEkgbm93IGhhdmUgYSBtdXR1YWxseSBleGNsdXNpdmUgb3B0aW9u
IHRvICd0aGluZzEnIHdoaWNoIEkgd2FudCB0byBhZGQgdG8gdGhlIG1vZGVsLg0KDQogIGxlYWYg
dGhpbmcyIHsNCiAgICB0eXBlIGVtcHR5Ow0KICAgIGRlc2NyaXB0aW9uDQogICAgICAiVGhpbmcg
Mi4iOw0KICB9DQoNClRoaXMgaXMgYSB2ZXJ5IHNpbXBsaWZpZWQgZXhhbXBsZSBidXQgc2hvdWxk
IGJlIHN1ZmZpY2llbnQgdG8gZGVtb25zdHJhdGUgdGhlIHByb2JsZW0uIA0KDQpJZiBJIGxvb2sg
YXQgdGhlIFhNTCByZXByZXNlbnRhdGlvbiBvZiAndGhpbmcxJywgaXQgbG9va3MgbGlrZSB0aGlz
Lg0KDQo8dGhpbmcxPjEyMzwvdGhpbmcxPg0KDQpJZiBJIHdlcmUgdG8gbW92ZSAndGhpbmcxJyBp
bnRvIGEgY2hvaWNlIHdpdGggYSBzaW5nbGUgY2FzZSwgaXQgd291bGQgbG9vayBsaWtlIHRoaXMu
DQoNCmNob2ljZSB0aGluZ3Mgew0KICBjYXNlIHRoaW5nMSB7DQogICAgbGVhZiB0aGluZzEgew0K
ICAgICAgdHlwZSB1aW50ODsNCiAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICJUaGluZyAxLiI7
DQogICAgfQ0KICB9DQp9DQoNCkxvb2tpbmcgdG8gdGhlIFhNTCByZXByZXNlbnRhdGlvbiwgaXQg
bG9va3MgdGhlIHNhbWUgYXMgYmVmb3JlLg0KDQo8dGhpbmcxPjEyMzwvdGhpbmcxPg0KDQpUbyBt
ZSwgdGhpcyBtZWFucyB0aGF0IHRha2luZyBhIHNpbmdsZSBub2RlIG9yIHNldCBvZiBub2RlcyBh
bmQgbW92aW5nIHRoZW0gdW5kZXIgYSBjYXNlIHdpdGhpbiBhIG5ldyBjaG9pY2Ugc3RhdGVtZW50
IGlzIGEgYmFja3dhcmQgY29tcGF0aWJsZSBjaGFuZ2UuIFRoaXMgYXNzdW1lcywgb2YgY291cnNl
LCBhbnkgbWFuZGF0b3J5IG9yIGRlZmF1bHQgYmVoYXZpb3IgaXMgcHJlc2VydmVkLiBJIG5vdyBj
YW4gYWRkICd0aGluZzInIHRvIHRoZSBleGlzdGluZyBtb2RlbCBhcyBhbiBvcHRpb24gdG8gJ3Ro
aW5nMScuDQoNCmNob2ljZSB0aGluZ3Mgew0KICBjYXNlIHRoaW5nMSB7DQogICAgbGVhZiB0aGlu
ZzEgew0KICAgICAgdHlwZSB1aW50ODsNCiAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICJUaGlu
ZyAxLiI7DQogICAgfQ0KICB9DQogIGNhc2UgdGhpbmcyIHsNCiAgICBsZWFmIHRoaW5nMiB7DQog
ICAgICB0eXBlIGVtcHR5Ow0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgIlRoaW5nIDIuIjsN
CiAgICB9DQogIH0NCn0NCg0KRG8geW91IGFncmVlIHdpdGggdGhpcyBhbmFseXNpcyBvciBhbSBJ
IG1pc3Npbmcgc29tZXRoaW5nPw0KDQpCZXN0IHJlZ2FyZHMsDQpKb2V5DQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0
DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJ
Q0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1Aw
eG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT12aTNxa0ZiNkhqbUlsSG8x
clhKMkVWLVB4NThhRkxxTmNfTDZoRnNpdWc0JnM9UkJpYUdvRVdDbmloUHFHVm1ENm55Vm9HXy0y
dmxhbGhPc3F3VWpzU1JxZyZlPSANCg0KDQo=


From nobody Mon Oct  2 09:37:50 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86D71344D3 for ; Mon,  2 Oct 2017 09:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level: 
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 z4SL-n4s7Pun for ; Mon,  2 Oct 2017 09:37:42 -0700 (PDT)
Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com [74.125.83.44]) (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 4B8D9132F65 for ; Mon,  2 Oct 2017 09:37:42 -0700 (PDT)
Received: by mail-pg0-f44.google.com with SMTP id u144so551191pgb.8 for ; Mon, 02 Oct 2017 09:37:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JKolFI7NH46aBUOp4sZjRRvUHwPdCrYMycMr2Xf2n3U=; b=ohofHLwnPYzkr3qn1LTbm/BWLmFYuLCI+paYR0Dk9Yj16WvMDcmY4QCUcDDrupEOZQ Vokd0kGuumW9OEpLxhMRRHTAAqgRl2rQh+gTTAsMEHczZ6EoeqB4Yc/NZaBXrgW/+Hon m/p7dsaupJcv0GHcFJreVU4bNvpiCJsTCopVDtoCYoIZwzSv1bZDvx+7qlkmWCcsMjbb LXbJuEXTpnl5OCJ/6fqmx5hvQhxGT30ZDtoW083XQREyC0Pp0k5MBk/sBxBd4+ytqrmc ngT1po9b+NxHcNl8HnQk5BRoscgbtj9ewBAaMGkKdesF52dNIGIZpH4EY0lpp9S9NEBn z41g==
X-Gm-Message-State: AHPjjUiTRw7nYEonkLLAnxyRF+fasmsQnucDRQsmV+AyubinsFHxcdb5 2EwJVRUfaQ503GZy67e0z2oaa6o2ARU=
X-Google-Smtp-Source: AOwi7QDuXrybhjXxjJ/lT0w95vbEdlZTcHkCx+IfMTF2cSPhj1CsWcEfslkpnIkXjLG86DKCZcvfyg==
X-Received: by 10.99.117.13 with SMTP id q13mr12861630pgc.366.1506962261390; Mon, 02 Oct 2017 09:37:41 -0700 (PDT)
Received: from [192.168.1.100] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id s62sm20572921pfe.91.2017.10.02.09.37.40 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Oct 2017 09:37:40 -0700 (PDT)
To: netmod@ietf.org
References: <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>  <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net> <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net> <920d0500-e7ea-66ff-5124-a025a438dbac@cisco.com> <15edcab6a58.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171002110504.d6kscxoot3nb3c3a@elstar.local> <4f2f072c-ff80-30a9-5bc8-08a9d527f52b@labn.net> <4aac1910-dee9-9a8f-0b4a-1adf3103c9d4@cisco.com>
From: Randy Presuhn 
Message-ID: 
Date: Mon, 2 Oct 2017 09:37:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <4aac1910-dee9-9a8f-0b4a-1adf3103c9d4@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] upcoming adoptions - this appendix is normative
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 16:37:49 -0000

Hi -

On 10/2/2017 7:18 AM, Robert Wilton wrote:
> This discussion may be conflating two issues:
> 
> (i) Does RFC text have to use RFC2119 terms to be normative?
> RFC 8174 categorically states that text can still be normative without 
> using RFC 2119 terms.

Thus it's clear that their usage is not necessarily necessary.

> (ii) Should standards track documents use RFC 2119 terms?
> If 93% of recently published standards track RFCs make use of RFC 2119 
> terms then that seems like a strong consistency argument to use them 
> unless there is a good reason not to.

I think RFC 2119 itself provides a fair counter-argument to the
imposition of such a requirement.  RFC 2119 states that "[i]mperatives
of the type defined in this memo must be used with care and sparingly."
To use "with care" and "sparingly" seems contrary to the notion of
employing them merely for "consistency."

Randy


From nobody Mon Oct  2 09:38:56 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA384132F65 for ; Mon,  2 Oct 2017 09:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5p750ep2n_P for ; Mon,  2 Oct 2017 09:38:54 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 18BB91344C6 for ; Mon,  2 Oct 2017 09:38:54 -0700 (PDT)
Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dz3k3-0002hG-Jr for ietf-supjps-netmod@ietf.org; Mon, 02 Oct 2017 17:38:51 +0100
From: "Jon Shallow" 
To: 
Date: Mon, 2 Oct 2017 17:38:50 +0100
Message-ID: <050801d33b9c$ed929560$c8b7c020$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0509_01D33BA5.4F57C0B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdM7nO15rmjN5pBQSk+F0IC3O8vbgw==
Content-Language: en-gb
Archived-At: 
Subject: [netmod] draft-ietf-netmod-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, 02 Oct 2017 16:38:56 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0509_01D33BA5.4F57C0B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi there,

 

I'm currently working on another draft ietf specification
(draft-ietf-dots-data-channel) which has a ordering requirement, but the
'ordered-by' statement is not specified (missing?)  for the 'list acl' in
container 'access-lists' in 4.1 IETF Access Control List
"ietf-access-control-list@2017-09-12.yang". 

 

Container 'aces' has the 'ordered-by-user' statement for the list ACE.

      container aces {

        description

          "The access-list-entries container contains

           a list of access-list-entries(ACE).";

        list ace {

          key "rule-name";

          ordered-by user;

          description

            "List of access list entries(ACE)";

          .....           

 

Container 'access-lists' does not have the 'ordered-by-user' statement for
the list ACL.

  container access-lists {

    description

      "This is a top level container for Access Control Lists.

       It can have one or more Access Control Lists.";

    list acl {

      key "acl-type acl-name";

      description

        "An Access Control List(ACL) is an ordered list of

         Access List Entries (ACE). Each Access Control Entry has a

         list of match criteria and a list of actions.

         Since there are several kinds of Access Control Lists

         implemented with different attributes for

         different vendors, this

         model accommodates customizing Access Control Lists for

         each kind and for each vendor.";

      .......

 

Is there a good reason why 'list acl' is not defined as sortable?

- or is it defined elsewhere as being sortable?

- or is the intention that there can only be one ACL?

 

We potentially have a requirement for multiple ACLs, each with its own set
of sorted ACEs where the ACLs cannot be configured in a random order and
need to know how to move forward.

 

Regards

 

Jon


------=_NextPart_000_0509_01D33BA5.4F57C0B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi =
there,
 
I’m currently working on another draft ietf =
specification (draft-ietf-dots-data-channel) which has a ordering =
requirement, but the ‘ordered-by’ statement is not specified =
(missing?)  for the ‘list acl’ in container =
‘access-lists’ in 4.1 IETF Access Control List =
"ietf-access-control-list@2017-09-12.yang". 
 
Container =
‘aces’ has the ‘ordered-by-user’ statement for =
the list ACE.
      container aces =
{
        =
description
          =
"The access-list-entries container contains
         &=
nbsp; a list of access-list-entries(ACE).";
        list ace =
{
          =
key "rule-name";
          =
ordered-by user;
          =
description
         &=
nbsp;  "List of access list =
entries(ACE)";
          =
.....           =

 
Container ‘access-lists’ does not have the =
‘ordered-by-user’ statement for the list =
ACL.
  container access-lists =
{
    =
description
      "This is a top =
level container for Access Control Lists.
       It can have one =
or more Access Control Lists.";
    list acl {
      key "acl-type =
acl-name";
      =
description
        "An =
Access Control List(ACL) is an ordered list of
         =
Access List Entries (ACE). Each Access Control Entry has =
a
         list =
of match criteria and a list of actions.
         Since =
there are several kinds of Access Control Lists
         =
implemented with different attributes for
         =
different vendors, this
         model =
accommodates customizing Access Control Lists for
         each =
kind and for each vendor.";
      =
.......
 
Is there a good reason why ‘list acl’ is =
not defined as sortable?
 - or is it =
defined elsewhere as being sortable?
- or is the intention that there can only be one =
ACL?
 
We potentially have a requirement for multiple ACLs, =
each with its own set of sorted ACEs where the ACLs cannot be configured =
in a random order and need to know how to move forward.
 
Regards
 
Jon

------=_NextPart_000_0509_01D33BA5.4F57C0B0--


From nobody Mon Oct  2 09:45:06 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43C7133039 for ; Mon,  2 Oct 2017 09:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnw3kK6i3f3z for ; Mon,  2 Oct 2017 09:45:01 -0700 (PDT)
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 B571913234B for ; Mon,  2 Oct 2017 09:45:00 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id m142so2924742lfg.8 for ; Mon, 02 Oct 2017 09:45:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6V5neIFTgOKIuMozg557bJcGAIYEi3adpbpwdtaQQmc=; b=RDrJShFLWIxrv5vfIRg7SPPn0yGqR9wYM+AHG2bmdfkthEeniTPk8RooOrCPkx0fWf IJ3H0pY1kZCrR0TdUXFZ7cvRl9Fw4da5me/iS0wjatvlrUPFIwenoVsDJ6V9VVsdKqoo YZc8d6ax+omXdLqq/XwtP+3va8BTK4g52ypWhbDNGq2lwZxVmxHWwq8T1ytNOmAAsEuM k0WPf6MtY5t6EUmRT5tLFch4zBmAfeGIfnBlB08GeVdl+8JbDfsIudDfToNVzcrNE+Kz yCjZ8ViMzZXjAMZBX7yCaGDpyN+po3TxKr6LG1p7mDiBvfd/L82Jrn9r+OfM5AEAGkVg vTvw==
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=6V5neIFTgOKIuMozg557bJcGAIYEi3adpbpwdtaQQmc=; b=lKE7FyQJ0IdAGWGVqZ+AEnUZYoqaUuOG/YjdfkR30fHpz/FVgXylddsm+ANMEJV8ri mD2pKji3PJuDAzEUV6a/llbVT/bPYy/rZZr5VimIjcxSDOdxGt0GvUoFYlEcVBW9f5XH aOyafFeU55vrWTyxS2jIx5JBborcmhR9dlT9OQ1v58T6rIGEwgWKA5BPQ2HbldezZHXF zhq6K00jfTTPuX8rwJ4Wa41WfF4nQdyhJR85g2QPluAw4BNQVPP24C/hjx1m7zDSPte7 58RyDbaBu853BxFN8RQUluiECSgua7NvDDH4ZK/Edg5W/rhKFNzZR7hGZBHXOfnz4dOm cYyQ==
X-Gm-Message-State: AHPjjUj9oS6k0v7sdsZE4lI1bYczXmwV5Y+/v86lUygrYXWJPqEhX2Ua +Qk4AJysz0ZD6TQ6WPTZi1iNAASIpYFz608POmIW3Q==
X-Google-Smtp-Source: AOwi7QCnnI0erxU1SLWyrdiE3u7rsSbxun0YGnOUozvifnSymvDHbQtxl4VGmYullIOjAOqvRGN5KrfqAL2JRfNuJD8=
X-Received: by 10.46.4.154 with SMTP id a26mr7583477ljf.6.1506962698987; Mon, 02 Oct 2017 09:44:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.143.139 with HTTP; Mon, 2 Oct 2017 09:44:57 -0700 (PDT)
In-Reply-To: 
References: 
From: Andy Bierman 
Date: Mon, 2 Oct 2017 09:44:57 -0700
Message-ID: 
To: Kent Watsen 
Cc: JOEY BOYD , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1ce05e5cff0b055a9318b5"
Archived-At: 
Subject: Re: [netmod] Backward Compatibility Question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 16:45:05 -0000

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

Hi,

It would change the schema node for an object if it was wrapped it in a
choice.
This affects augment and deviation statements that reference the old schema
node.
The 'uses' node is a special case since it never appears in a schema node
identifier.

Andy

On Mon, Oct 2, 2017 at 9:31 AM, Kent Watsen  wrote:

> Hi Joey,
>
> Your proposal looks fine to me, since it doesn't change the semantics of
> the data model.  Note that https://tools.ietf.org/html/rfc7950#section-11
> says:
>
>    o  Any set of data definition nodes may be replaced with another set
>       of syntactically and semantically equivalent nodes.  For example,
>       a set of leafs may be replaced by a "uses" statement of a grouping
>       with the same leafs.
>
> Kent
>
> --
>
> Hello,
>
> Does anyone have thoughts on this?
>
> Regards,
> Joey
>
> -----Original Message-----
> From: JOEY BOYD
> Sent: Wednesday, September 27, 2017 9:06 AM
> To: 'netmod@ietf.org'
> Subject: Backward Compatibility Question
>
> Hi all,
>
> Suppose I had a published YANG model with the following leaf.
>
>
>   leaf thing1 {
>     type uint8;
>     description
>       "Thing 1.";
>   }
>
> Later, I realize that I wish I had modeled this in a choice as I now have
> a mutually exclusive option to 'thing1' which I want to add to the model.
>
>   leaf thing2 {
>     type empty;
>     description
>       "Thing 2.";
>   }
>
> This is a very simplified example but should be sufficient to demonstrate
> the problem.
>
> If I look at the XML representation of 'thing1', it looks like this.
>
> 123
>
> If I were to move 'thing1' into a choice with a single case, it would look
> like this.
>
> choice things {
>   case thing1 {
>     leaf thing1 {
>       type uint8;
>       description
>         "Thing 1.";
>     }
>   }
> }
>
> Looking to the XML representation, it looks the same as before.
>
> 123
>
> To me, this means that taking a single node or set of nodes and moving
> them under a case within a new choice statement is a backward compatible
> change. This assumes, of course, any mandatory or default behavior is
> preserved. I now can add 'thing2' to the existing model as an option to
> 'thing1'.
>
> choice things {
>   case thing1 {
>     leaf thing1 {
>       type uint8;
>       description
>         "Thing 1.";
>     }
>   }
>   case thing2 {
>     leaf thing2 {
>       type empty;
>       description
>         "Thing 2.";
>     }
>   }
> }
>
> Do you agree with this analysis or am I missing something?
>
> Best regards,
> Joey
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=
> vi3qkFb6HjmIlHo1rXJ2EV-Px58aFLqNc_L6hFsiug4&s=RBiaGoEWCnihPqGVmD6nyVoG_-
> 2vlalhOsqwUjsSRqg&e=
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

It would change the schema node for=
 an object if it was wrapped it in a choice.
This affects augment=
 and deviation statements that reference the old schema node.
The=
 'uses' node is a special case since it never appears in a schema n=
ode identifier.

Andy

On Mon, Oct 2, 2017 at 9:=
31 AM, Kent Watsen <kwatsen@juniper.net> wrote:
Hi Joey,



Your proposal looks fine to me, since it doesn't change the semantics o=
f the data model.=C2=A0 Note that https://tools.ietf.o=
rg/html/rfc7950#section-11 says:



=C2=A0 =C2=A0o=C2=A0 Any set of data definition nodes may be replaced with =
another set

=C2=A0 =C2=A0 =C2=A0 of syntactically and semantically equivalent nodes.=C2=
=A0 For example,

=C2=A0 =C2=A0 =C2=A0 a set of leafs may be replaced by a "uses" s=
tatement of a grouping

=C2=A0 =C2=A0 =C2=A0 with the same leafs.



Kent



--



Hello,



Does anyone have thoughts on this?



Regards,

Joey



-----Original Message-----

From: JOEY BOYD

Sent: Wednesday, September 27, 2017 9:06 AM

To: 'netmod@ietf.org'

Subject: Backward Compatibility Question



Hi all,



Suppose I had a published YANG model with the following leaf.





=C2=A0 leaf thing1 {

=C2=A0 =C2=A0 type uint8;

=C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 "Thing 1.";

=C2=A0 }



Later, I realize that I wish I had modeled this in a choice as I now have a=
 mutually exclusive option to 'thing1' which I want to add to the m=
odel.



=C2=A0 leaf thing2 {

=C2=A0 =C2=A0 type empty;

=C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 "Thing 2.";

=C2=A0 }



This is a very simplified example but should be sufficient to demonstrate t=
he problem.



If I look at the XML representation of 'thing1', it looks like this=
.



<thing1>123</thing1>



If I were to move 'thing1' into a choice with a single case, it wou=
ld look like this.



choice things {

=C2=A0 case thing1 {

=C2=A0 =C2=A0 leaf thing1 {

=C2=A0 =C2=A0 =C2=A0 type uint8;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thing 1.";

=C2=A0 =C2=A0 }

=C2=A0 }

}



Looking to the XML representation, it looks the same as before.



<thing1>123</thing1>



To me, this means that taking a single node or set of nodes and moving them=
 under a case within a new choice statement is a backward compatible change=
. This assumes, of course, any mandatory or default behavior is preserved. =
I now can add 'thing2' to the existing model as an option to 't=
hing1'.



choice things {

=C2=A0 case thing1 {

=C2=A0 =C2=A0 leaf thing1 {

=C2=A0 =C2=A0 =C2=A0 type uint8;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thing 1.";

=C2=A0 =C2=A0 }

=C2=A0 }

=C2=A0 case thing2 {

=C2=A0 =C2=A0 leaf thing2 {

=C2=A0 =C2=A0 =C2=A0 type empty;

=C2=A0 =C2=A0 =C2=A0 description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Thing 2.";

=C2=A0 =C2=A0 }

=C2=A0 }

}



Do you agree with this analysis or am I missing something?



Best regards,

Joey



_______________________________________________

netmod mailing list

netmod@ietf.org

ht=
tps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org=
_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scb=
fh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYa=
GTvjISlaJdcZo&m=3Dvi3qkFb6HjmIlHo1rXJ2EV-Px58aFLqNc_L6hF=
siug4&s=3DRBiaGoEWCnihPqGVmD6nyVoG_-2vlalhOsqwUjsSRqg&e=
=3D





_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1ce05e5cff0b055a9318b5--


From nobody Mon Oct  2 10:03:59 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A014132F7D for ; Mon,  2 Oct 2017 10:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 u65LfZL9OuFL for ; Mon,  2 Oct 2017 10:03:57 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CAA133044 for ; Mon,  2 Oct 2017 10:03:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1769; q=dns/txt; s=iport; t=1506963836; x=1508173436; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=0dKvWlxYsseAxkHzlRzxeZIhQKU8anTxi5DyqqaJuRk=; b=YlvwOf7a36gi+bTfKxy539jB0139GkdXmdZMC381YJbsL1hO48TK9dB4 J2Rz9FrWGUgQt0nx+rt8nyxVILLmIDMoO7+/yjOd3WmfZ3SLginwzh6IJ nnzxesoai8XP4m/FCmuCVaXhUwpuu4c5oCaTQ4SGHUGqDsAIFxrLF9fYa A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQAScdJZ/xbLJq1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRBbieDeYsTkGaYPgoYC4RJTwKFBBQBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBAQEhDwEFNhsLGAICJgICJzAGAQwGAgEBiiQIEKUPgieLMAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARsFgQ6CH4NTghWCfYgXgmEFoTKUZYtdhyyNeYdbgTk2IYEOMiE?= =?us-ascii?q?IHRVJhl5APzaKEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,470,1500940800"; d="scan'208";a="697704881"
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 Oct 2017 17:03:44 +0000
Received: from [10.63.23.52] (dhcp-ensft1-uk-vla370-10-63-23-52.cisco.com [10.63.23.52]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v92H3iuH017242; Mon, 2 Oct 2017 17:03:44 GMT
To: Randy Presuhn , netmod@ietf.org
References: <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>  <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net> <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net> <920d0500-e7ea-66ff-5124-a025a438dbac@cisco.com> <15edcab6a58.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171002110504.d6kscxoot3nb3c3a@elstar.local> <4f2f072c-ff80-30a9-5bc8-08a9d527f52b@labn.net> <4aac1910-dee9-9a8f-0b4a-1adf3103c9d4@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Mon, 2 Oct 2017 18:03:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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] upcoming adoptions - this appendix is normative
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 17:03:58 -0000

Hi Randy,


On 02/10/2017 17:37, Randy Presuhn wrote:
> Hi -
>
> On 10/2/2017 7:18 AM, Robert Wilton wrote:
>> This discussion may be conflating two issues:
>>
>> (i) Does RFC text have to use RFC2119 terms to be normative?
>> RFC 8174 categorically states that text can still be normative 
>> without using RFC 2119 terms.
>
> Thus it's clear that their usage is not necessarily necessary.
>
>> (ii) Should standards track documents use RFC 2119 terms?
>> If 93% of recently published standards track RFCs make use of RFC 
>> 2119 terms then that seems like a strong consistency argument to use 
>> them unless there is a good reason not to.
>
> I think RFC 2119 itself provides a fair counter-argument to the
> imposition of such a requirement.  RFC 2119 states that "[i]mperatives
> of the type defined in this memo must be used with care and sparingly."
> To use "with care" and "sparingly" seems contrary to the notion of
> employing them merely for "consistency."
I interpret this slightly differently.

If a standards track RFC has some text that should be interpreted in a 
way that matches (or perhaps is close) to the RFC 2119 language 
semantics then it is more consistent and less ambiguous to use RFC 2119 
terms since the vast majority of other RFCs are using it.  If nothing in 
the draft matches the RFC 2119 language then of course you don't need to 
cite it.

It might be interesting to look at the 7% of RFCs that don't use it and 
see if that was because it wasn't necessary, due to the authors choice, 
or some other reason.

Thanks,
Rob


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


From nobody Mon Oct  2 10:19:29 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30570120720 for ; Mon,  2 Oct 2017 10:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Zp8PA6DPrxMN for ; Mon,  2 Oct 2017 10:19:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7602A1321C9 for ; Mon,  2 Oct 2017 10:19:26 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 740BF1AE018C; Mon,  2 Oct 2017 19:19:25 +0200 (CEST)
Date: Mon, 02 Oct 2017 19:19:25 +0200 (CEST)
Message-Id: <20171002.191925.1932918019399415014.mbj@tail-f.com>
To: joey.boyd@adtran.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <26CE489EF4611643B3EFE43D06E02654015E7548A6@ex-mb1.corp.adtran.com>
References: <26CE489EF4611643B3EFE43D06E02654015E751148@ex-mb1.corp.adtran.com> <26CE489EF4611643B3EFE43D06E02654015E7548A6@ex-mb1.corp.adtran.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Backward Compatibility Question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 17:19:28 -0000

JOEY BOYD  wrote:
> Hello,
> 
> Does anyone have thoughts on this?
> 
> Regards,
> Joey
> 
> -----Original Message-----
> From: JOEY BOYD 
> Sent: Wednesday, September 27, 2017 9:06 AM
> To: 'netmod@ietf.org'
> Subject: Backward Compatibility Question
> 
> Hi all,
> 
> Suppose I had a published YANG model with the following leaf.
> 
> 
>   leaf thing1 {
>     type uint8;
>     description
>       "Thing 1.";
>   }
> 
> Later, I realize that I wish I had modeled this in a choice as I now have a mutually exclusive option to 'thing1' which I want to add to the model.
> 
>   leaf thing2 {
>     type empty;
>     description
>       "Thing 2.";
>   }
> 
> This is a very simplified example but should be sufficient to demonstrate the problem. 
> 
> If I look at the XML representation of 'thing1', it looks like this.
> 
> 123
> 
> If I were to move 'thing1' into a choice with a single case, it would look like this.
> 
> choice things {
>   case thing1 {
>     leaf thing1 {
>       type uint8;
>       description
>         "Thing 1.";
>     }
>   }
> }
> 
> Looking to the XML representation, it looks the same as before.

But it is not backwards compatible, since the schema tree has
changed.  Suppose that "thing1" was a container; then some other
module might have augmented that container.  If you put the node in a
choice and case, the augment will no longer work.


/martin




> 
> 123
> 
> To me, this means that taking a single node or set of nodes and moving them under a case within a new choice statement is a backward compatible change. This assumes, of course, any mandatory or default behavior is preserved. I now can add 'thing2' to the existing model as an option to 'thing1'.
> 
> choice things {
>   case thing1 {
>     leaf thing1 {
>       type uint8;
>       description
>         "Thing 1.";
>     }
>   }
>   case thing2 {
>     leaf thing2 {
>       type empty;
>       description
>         "Thing 2.";
>     }
>   }
> }
> 
> Do you agree with this analysis or am I missing something?
> 
> Best regards,
> Joey
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Mon Oct  2 10:34:13 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEA3133039; Mon,  2 Oct 2017 10:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=nio365.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 VUfxYcM-mKsj; Mon,  2 Oct 2017 10:34:10 -0700 (PDT)
Received: from mx0b-00010702.pphosted.com (mx0a-00010702.pphosted.com [148.163.156.75]) (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 6BD8413301C; Mon,  2 Oct 2017 10:34:10 -0700 (PDT)
Received: from pps.filterd (m0098781.ppops.net [127.0.0.1]) by mx0a-00010702.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v92HIQVE031399; Mon, 2 Oct 2017 12:34:09 -0500
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0114.outbound.protection.outlook.com [207.46.163.114]) by mx0a-00010702.pphosted.com with ESMTP id 2dbsr783hj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 02 Oct 2017 12:34:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LdjFlDWkcrDphXJL5i9bOqDal4rFkfkqmnhMFBcbLRg=; b=R+EMdh8MA7ARHpDbU+Kob/s4kT8e2sZvz9y8QWbo/txzrRYIOjHQIX9uIerYoMpFAw8xd8hsNegDemfXqSeCSUn7xfg9rkokMWZabEkvEpuUbJnl1eoYfwra2JnTZ++ro1Xt+C/PCa90WqIbzNc76xtS70op9wpTR5Euu2C8wpM=
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com (10.160.219.156) by DM2PR0401MB1392.namprd04.prod.outlook.com (10.160.221.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 2 Oct 2017 17:34:06 +0000
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::b172:affa:cf1d:384e]) by DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::b172:affa:cf1d:384e%18]) with mapi id 15.20.0077.016; Mon, 2 Oct 2017 17:34:06 +0000
From: Rodney Cummings 
To: "tictoc@ietf.org" , "netmod@ietf.org" 
Thread-Topic: draft-ietf-tictoc-1588v2-yang-05: port-number
Thread-Index: AdM7naceqW92Otk+TBSUBZ12gBb0TQ==
Date: Mon, 2 Oct 2017 17:34:06 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.164.62.43]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0401MB1392; 6:GUGnldwpr0AMAAgIf0YpNLvg/qGKbxpITTUuN+rpV/PBvocCC+IkhqAb0ZeEMJZLAeMYZ+2Oal70EFll7rwdrB+WI3l9PqZsp1T5XFj+CyV2AGhnoAri/MuzF7Il/BACsuI6CEt0iJVhKqKYQLFoA1h3ljz3qu3FVenfgnYoM1MdH+0a6eKg+eQhMKIpmuqZ3t4Jc/0Flg7MlG1WppIDB/0Ks4QwoKtwrQ3KmqqpgovcECLoHHLopnBornZ8LOoT86uGu3oakbH3oN57ResQAO/9YXyk7W5J5aUWd0G6Stm7g0lHWw9H732mTrIsYg5WKQpQsZU/loRdVIO2FWBOkg==; 5:zVcA6ffUlqoAOq/h4AcyUH31MUzauED96QMLygIGHvna9ry63KHwNZOtnhKq/8x7TbCODgmTJy+OOpncx//+4bec6T2cowhUT/n8pkvqSTZiUqkV/9LJkVz/MB96wUwaO60SKs3YOfI8V2dDXxpEyA==; 24:94NHTOc1It5jdOcX4agGaWZlseRRdFIitTvCcL9sGGeC5Wrx1gfNoNf4wxKgbRc0N1eGCugNnYmIox7DQ+rKshoZh+Nm5oHpJLJUiwCBriA=; 7:Rwr1ymVSTWphuqWWjae0n26Y4/6K5yrD0ReZrJx4Vvh6EyhSFRTPKlJe5ZnytOQr3iqbZC8cR3hWuBKv48Rr4SzUIEmAD9dibuLQv8pCMJ8qMctB6pHR0uLrQtJIlfOYpHa4N7iEPCW71l5HGpstqj/FqBUr7pjfCoAuTKUqGxwl4HQITbbqSIr8MWHkY74vEsoCvPLUre355ll9oG0HaMkh32i+OixOZfLSG8P2MrY=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: bb925758-a33c-4190-8618-08d509bbc81e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR0401MB1392; 
x-ms-traffictypediagnostic: DM2PR0401MB1392:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0401MB1392; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0401MB1392; 
x-forefront-prvs: 0448A97BF2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(199003)(189002)(5250100002)(101416001)(14454004)(5660300001)(25786009)(81156014)(9686003)(2906002)(55016002)(53936002)(105586002)(8936002)(6116002)(305945005)(33656002)(6436002)(8676002)(106356001)(3846002)(99286003)(3660700001)(7736002)(6506006)(102836003)(3280700002)(2501003)(74316002)(2900100001)(81166006)(50986999)(110136005)(478600001)(7696004)(66066001)(54356999)(450100002)(86362001)(316002)(68736007)(230783001)(189998001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0401MB1392; H:DM2PR0401MB1389.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ni.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 17:34:06.1739 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0401MB1392
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-02_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710020252
Archived-At: 
Subject: [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 17:34:12 -0000

Hi folks,

One of the last topics that we need to resolve for WG Last Call of draft-ie=
tf-tictoc-1588v2-yang-05 is the representation of port-number, which serves=
 as the key to the list of 1588 port data sets (i.e. port-list). I've had s=
ome offline discussion with IEEE 1588 WG members, and I'm copying NETMOD me=
mbers for YANG expertise.

I think we can narrow the possible options to two, so I'm starting a new th=
read to focus on those.

IEEE Std 1588-2008 is the time sync standard that specifies the information=
 model on which draft-ietf-tictoc-1588v2-yang-05 is based. In IEEE Std 1588=
-2008, subclause 5.3.5 specifies the following data type to identify each l=
ogical port in the 1588 product:
   struct PortIdentity {
      ClockIdentity clockIdentity;
      Uinteger16 portNumber;
   };
IEEE Std 1588-2008 uses this data type as the "portIdentity" of the port in=
 its on-the-wire protocol, state machines, and so on. In other words, in th=
e 1588 standard itself, portIdentity is a "real thing" with real implementa=
tion.
=20
IEEE Std 1588-2008 also specifies a list of logical ports in each "clock", =
and portIdentity.portNumber is used as the key to that list of ports.

In the YANG of draft-ietf-tictoc-1588v2-yang-05, we use YANG-style names (e=
.g. port-list, port-number), but otherwise we've tried to keep consistent t=
o the IEEE Std 1588-2008 information model.

We have a challenge with port-number. If YANG represents port-identity as a=
 container within port-list, YANG does not allow a key to be a leaf within =
a container, so we cannot use port-identity/port-number as the key to port-=
list.

It seems that we have two options:

Option 1: Use a leafref
---

YANG summary:

        list port-ds-list {
          key "port-number";
          leaf port-number {
            type uint16;
          }
          container port-identity {
             leaf clock-identity {
                type clock-identity-type;
                config false;
             }
             leaf port-number {
                type leafref{
                   path "../../port-number";
                }
                config false;
             }
          }
        }

This has disadvantages from the YANG perspective, in that port-number is du=
plicated. The "config false" is intended to mitigate YANG implementation ch=
allenges, such that only one value of port-number is provided for configura=
tion.

Option 2: Use a grouping
---

YANG summary:

     grouping port-identity-grouping {
       leaf clock-identity {
         type clock-identity-type;
       }
       leaf port-number {
         type uint16;
       }
     }
     list port-ds-list {
       key "port-number";
       uses port-identity-grouping;
     }

This has disadvantages from the 1588 perspective, in that it is not possibl=
e for a 1588-aware management client to "get" portIdentity. We are removing=
 a 1588 "real thing" from the data model in order to accommodate a syntax l=
imitation of YANG.=20

Question for NETMOD experts
---

My personal preference is Option 1 (leafref). Nevertheless, if the "config =
false" does not provide sufficient mitigation for today's YANG implementati=
ons, we can go with Option 2.=20

Feedback is very much appreciated.

Thanks folks,
Rodney Cummings
Co-author draft-ietf-tictoc-1588v2-yang-05


From nobody Mon Oct  2 11:14:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41370132FA7; Mon,  2 Oct 2017 11:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8xJtkhJ5NMGR; Mon,  2 Oct 2017 11:14:31 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6F03113469D; Mon,  2 Oct 2017 11:14:31 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 547CD1AE018C; Mon,  2 Oct 2017 20:14:30 +0200 (CEST)
Date: Mon, 02 Oct 2017 20:14:30 +0200 (CEST)
Message-Id: <20171002.201430.1078877259363120382.mbj@tail-f.com>
To: rodney.cummings@ni.com
Cc: tictoc@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] draft-ietf-tictoc-1588v2-yang-05: port-number
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 18:14:33 -0000

Rodney Cummings  wrote:
> Hi folks,
> 
> One of the last topics that we need to resolve for WG Last Call of
> draft-ietf-tictoc-1588v2-yang-05 is the representation of port-number,
> which serves as the key to the list of 1588 port data sets
> (i.e. port-list). I've had some offline discussion with IEEE 1588 WG
> members, and I'm copying NETMOD members for YANG expertise.
> 
> I think we can narrow the possible options to two, so I'm starting a
> new thread to focus on those.
> 
> IEEE Std 1588-2008 is the time sync standard that specifies the
> information model on which draft-ietf-tictoc-1588v2-yang-05 is
> based. In IEEE Std 1588-2008, subclause 5.3.5 specifies the following
> data type to identify each logical port in the 1588 product:
>    struct PortIdentity {
>       ClockIdentity clockIdentity;
>       Uinteger16 portNumber;
>    };
> IEEE Std 1588-2008 uses this data type as the "portIdentity" of the
> port in its on-the-wire protocol, state machines, and so on. In other
> words, in the 1588 standard itself, portIdentity is a "real thing"
> with real implementation.
>  
> IEEE Std 1588-2008 also specifies a list of logical ports in each
> "clock", and portIdentity.portNumber is used as the key to that list
> of ports.
> 
> In the YANG of draft-ietf-tictoc-1588v2-yang-05, we use YANG-style
> names (e.g. port-list, port-number), but otherwise we've tried to keep
> consistent to the IEEE Std 1588-2008 information model.
> 
> We have a challenge with port-number. If YANG represents port-identity
> as a container within port-list, YANG does not allow a key to be a
> leaf within a container, so we cannot use port-identity/port-number as
> the key to port-list.
> 
> It seems that we have two options:
> 
> Option 1: Use a leafref
> ---
> 
> YANG summary:
> 
>         list port-ds-list {
>           key "port-number";
>           leaf port-number {
>             type uint16;
>           }
>           container port-identity {
>              leaf clock-identity {
>                 type clock-identity-type;
>                 config false;
>              }
>              leaf port-number {
>                 type leafref{
>                    path "../../port-number";
>                 }
>                 config false;
>              }
>           }
>         }
> 
> This has disadvantages from the YANG perspective, in that port-number
> is duplicated. The "config false" is intended to mitigate YANG
> implementation challenges, such that only one value of port-number is
> provided for configuration.
> 
> Option 2: Use a grouping
> ---
> 
> YANG summary:
> 
>      grouping port-identity-grouping {
>        leaf clock-identity {
>          type clock-identity-type;
>        }
>        leaf port-number {
>          type uint16;
>        }
>      }
>      list port-ds-list {
>        key "port-number";
>        uses port-identity-grouping;
>      }
> 
> This has disadvantages from the 1588 perspective, in that it is not
> possible for a 1588-aware management client to "get" portIdentity. We
> are removing a 1588 "real thing" from the data model in order to
> accommodate a syntax limitation of YANG.

I think that in general when you go from an information model to a
concrete data model, you need to adapt to the data modelling language
you are using, and this will in most cases mean that there will be
some differences; in some cases the data model structure is different,
and in some cases the data model will result in a more detailed
model.  How keys are specified is one such example.  If you were to
use SMIv2, you'd have to change the names (so that they are unique),
and you'd have to map the structures to conceptual tables.

Clients need to understand the data model in use (not just the
information model behid it).

> Question for NETMOD experts
> ---
> 
> My personal preference is Option 1 (leafref). Nevertheless, if the
> "config false" does not provide sufficient mitigation for today's YANG
> implementations, we can go with Option 2.

I don't think any implementation would have any problem supporting
option 1, but it does look a bit odd.  Also, it only "helps" if the
client is getting the data using , but it will not help if it is
using .


I think that the cleanest solution is to not try to completely mimic
the structure from the information model, but make sure that the
text in the description statements make it clear that the data model
looks different compared to the information model, in order to help
the readers.



/martin



> 
> Feedback is very much appreciated.
> 
> Thanks folks,
> Rodney Cummings
> Co-author draft-ietf-tictoc-1588v2-yang-05
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Mon Oct  2 13:06:39 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D38134840; Mon,  2 Oct 2017 13:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 kEFrgC9bWx5Z; Mon,  2 Oct 2017 13:06:36 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0112.outbound.protection.outlook.com [104.47.38.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399511320D8; Mon,  2 Oct 2017 13:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yia6ZvQ5euRSiutsT+YkkorqxvzQjzN7PQCd+jArgeE=; b=QQEhoqYxmbsFcXnrLDBOm7dNUjPq3cuCwh/J06vR2sHtUqRQCnqnJzTJQTuxPjGiEKAvB1WH8632OyDmUhMvdZcuV3w5UTK/UOv8/y014k+3FkNb0znJ3dau11KR25XbsPkLKYrlwHDcSOkZ0rXveagsoG5nopdhM0nt8tzqVD4=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB276.namprd05.prod.outlook.com (10.141.22.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Mon, 2 Oct 2017 20:06:34 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Mon, 2 Oct 2017 20:06:34 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" , "draft-ietf-netmod-rfc6087bis@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QA8+mcxSk5vUmECY2lUkQ4OqLQ2OsA
Date: Mon, 2 Oct 2017 20:06:34 +0000
Message-ID: <6B61FA71-CD63-4501-A1B7-F661F943C9AA@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.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:seHzCmkhVAAhZroOPDaWR1MUnj6VvOAK6EaYjiFwB+wIP04Ix3v/qkMaruBONul3oEdqQ4Gs012qXee8j1N435gZojC6w1QAruEVikCgZLPNWlt+R1Tn+CuOoDdPP7G4Yl/sDhO5VmrXtlJ/XR5tnODC5Z7Kj0ocszAurooi+WICKDvRw+p4Bt0NEAteobC6WL7xaj+90613CDpNR+oAf0VKr2Gjvy4GVuiOmXevX5QPeG79MZ8rUGxV7VZ0CbbmSmqTADSGVoJqyy602FeQZ2/zDF+uoeI2qp1kAQuxbfHfvL7D9F3VTXwYo5AVjNWWXLQYHQ65Ki4k5O/sb5oWIw==; 5:kH5E5tsdklFC4/Q+O0MByX2uKWnpNfG3w4ptdNmTkkdyOHb3SDVxETXo9bB3tlCaNVTbu1wE0jVDYlYkNseelc+OgVY+ZEDO/ICgdOXU11m2I2Lc7l4FNAwnrWYSeTLXP3x2AGNHtnafRakqGrvUaQ==; 24:fIq73L0uyOZGhZHgH9BZicpIALdFYv+Atqs/Xtigb7P3zpXELxR6W9sJ4LMXZp1u6kEnQ3eN0vhrmAVRPznISUimND3ojDY/MMcKFxP/Q4Y=; 7:2BGer7kFzIImJJEhy0elK4SmTdLsunH6f045b7SaplEzcDM1D+ai67MsFzzvfcE1JINQ9YNc+aeCq4wJmin58Rf11ki+o2mQFb3fq7a45fvqU4cKxduEhoKTsmuXuN+2BAM4fPIDRRZDi/tHy1j5ILJmzUbT7qGSqG3S/skq2fvg7r5SBxXB+A7g8b6mUE2WU/+fhJmfiHPOchqY9rKi2+VC66X/fUNvjfC1VULsg3s=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: a47f695e-33ac-46a0-4505-08d509d114c9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB276; 
x-ms-traffictypediagnostic: BLUPR05MB276:
x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB276; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB276; 
x-forefront-prvs: 0448A97BF2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(76176999)(450100002)(82746002)(83506001)(25786009)(2501003)(478600001)(6486002)(33656002)(6506006)(3846002)(77096006)(6436002)(316002)(2900100001)(230783001)(54906003)(966005)(86362001)(66066001)(2950100002)(6916009)(58126008)(97736004)(99286003)(6116002)(5640700003)(3280700002)(6512007)(229853002)(36756003)(5660300001)(2906002)(6306002)(102836003)(3660700001)(83716003)(50986999)(53936002)(101416001)(105586002)(54356999)(106356001)(8936002)(81166006)(4326008)(7736002)(14454004)(6246003)(189998001)(8676002)(305945005)(81156014)(1730700003)(2351001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB276; H:BLUPR05MB275.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)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 20:06:34.2624 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB276
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Oct 2017 20:06:38 -0000

DQpUaGUgTGFzdCBDYWxsIGZvciB0aGlzIGRvY3VtZW50IGhhcyBjb21wbGV0ZWQgd2l0aCAqbm8q
IHJlc3BvbnNlcywgb3RoZXIgdGhhbiBCZW5vaXQncyBxdWVzdGlvbiByZWdhcmRpbmcgaWYgaXQg
c2hvdWxkIGJlIGEgQkNQLCB3aGljaCBhbHNvIGhhZCBubyByZXNwb25zZXMsIG90aGVyIHRoYW4g
bXkgb3duIHdvbmRlcmluZyBpZiBZQU5HIChhbmQgaGVuY2UgdGhlIGd1aWRlbGluZXMpIHdhcyBz
dGFibGUgZW5vdWdoLg0KDQpMb3UgYW5kIEkgZGlzY3Vzc2VkLiAgSXQgaXMgb3VyIG9waW5pb24g
dGhhdCwgZ2l2ZW4gdGhlIG5hdHVyZSBvZiB0aGlzIGRvY3VtZW50LCB0aGUgV0cgaW1wbGljaXRs
eSBzdXBwb3J0cyBpdCBhbHJlYWR5LiAgU28sIHJlYWxseSwgdGhlIG9ubHkgdGhpbmcgdGhhdCBt
YXR0ZXJzLCBpcyBpZiB0aGVyZSBhcmUgYW55IGlzc3Vlcy9jb25jZXJucy4gIFNpbmNlIG5vIGlz
c3Vlcy9jb25jZXJucyB3ZXJlIHJhaXNlZCwgd2UgY2hvb3NlIHRvIGRlY2xhcmUgdGhlIExhc3Qg
Q2FsbCBzdWNjZXNzZnVsLiAgQXMgZm9yIHByb21vdGluZyBpdCB0byBhIEJDUCwgdGhlcmUgYXBw
ZWFycyB0byBiZSBubyBjb25zZW5zdXMgdG8gZG8gc28gYXQgdGhpcyB0aW1lLiAgIEFjY29yZGlu
Z2x5LCBhcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQsIEkgcGxhbiB0byBzZW5kIHRoZSBzaGVwaGVy
ZCB3cml0ZS11cCAod2l0aCB0aGVzZSBjb21tZW50cyBpbmNsdWRlZCkgdG8gdGhlIEFEIGluIHRo
ZSBuZXh0IGZldyBkYXlzLg0KDQpMb29raW5nIGZvcndhcmRzLCB3ZSd2ZSBjcmVhdGVkIGEgbmV3
IEdpdEh1YiByZXBvIGNhbGxlZCAiZ3VpZGVsaW5lcy1uZXh0IiAobW9kZWxlZCBhZnRlciB5YW5n
LW5leHQpIHRvIGNhcHR1cmUgb24tZ29pbmcgY29tbWVudHMvc3VnZ2VzdGlvbnMgZm9yIGZ1dHVy
ZSB1cGRhdGVzIHRvIHRoZSBkb2N1bWVudDogaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9n
dWlkZWxpbmVzLW5leHQuDQoNCktlbnQgKGFuZCBMb3UpDQoNCg0KDQo=


From nobody Mon Oct  2 15:41:48 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88411348F9 for ; Mon,  2 Oct 2017 15:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, 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 WJdZc4nh__RT for ; Mon,  2 Oct 2017 15:41:46 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA6113422F for ; Mon,  2 Oct 2017 15:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6662; q=dns/txt; s=iport; t=1506984105; x=1508193705; h=subject:references:from:to:cc:message-id:date: mime-version:in-reply-to; bh=Ja768IIt7dxm1CVMNHDgGYxWPPH8BTdJ3A6D2kt1fUM=; b=O4tC4QGEXnJdGr58cvFVssaoeZO9dG/BbtIq+u8mxDRkoVKSEd4WgCi7 1wgSB/FU6L5Kv7Q0JfESpwI21rv/jOuQ4bqYeBxoZJX/LE7htzJUFFEz8 iHy7+TrZ4UTfc7i/3C0/JY5ClMbq7rlW8ysEnbJsY/h8RMlamIl6u8Iil Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAgArv9JZ/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRBbieDeYsTkDsrkG6FPg6CBAolhRYChQEXAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEDAyNUAhAcAwECKwICTwgGDQYCAQGKLBAypQyCJyeLDAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2DLYNTghWCfYMygRpYgnOCYQWMNoUKj3KHXo0HghRbhRSDWoc?= =?us-ascii?q?sjXmHW4E5IAE2gQ4yIQgdFR+HST42AYlDAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,471,1500940800";  d="scan'208,217";a="697710656"
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; 02 Oct 2017 22:41:43 +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 v92MfhWs003169; Mon, 2 Oct 2017 22:41:43 GMT
References: <150695377176.28796.2391371404908608890.idtracker@ietfa.amsl.com>
From: Benoit Claise 
To: NETMOD Working Group 
Cc: Henrik Levkowetz 
X-Forwarded-Message-Id: <150695377176.28796.2391371404908608890.idtracker@ietfa.amsl.com>
Message-ID: <82fc5391-a747-09a2-08f2-a59e49b6c26f@cisco.com>
Date: Tue, 3 Oct 2017 00:41:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150695377176.28796.2391371404908608890.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------93D8A4F273563232F76560D8"
Content-Language: en-US
Archived-At: 
Subject: [netmod] New Version Notification for draft-clacla-netmod-model-catalog-02.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, 02 Oct 2017 22:41:48 -0000

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

Dear all,

What's new in this draft?

    o  Add a belongs-to leaf to track parent modules.

    o  Add leafs to track dependents and dependencies for a given module.

    o  Simplify the generated-from enumerated values.

    o  Refine the type for compilation-result to be an inet:uri.

    o  Add leafs for semantic versioning.

    o  Reorder the organization leaf to be with other module keys.

    o  Add text to describe generated-from and semantic versioning.

All of this is implemented already in the yangcatalog.org, except one 
which we're busy finalizing: the semantic versioning.
https://www.yangcatalog.org/yang-search/module_details.php starts to be 
quite complete.

Regards, Joe and Benoit

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-clacla-netmod-model-catalog-02.txt
Date: 	Mon, 2 Oct 2017 07:16:11 -0700
From: 	internet-drafts@ietf.org
To: 	Benoit Claise , Joe Clarke 



A new version of I-D, draft-clacla-netmod-model-catalog-02.txt
has been successfully submitted by Benoit Claise and posted to the
IETF repository.

Name:		draft-clacla-netmod-model-catalog
Revision:	02
Title:		YANG module for yangcatalog.org
Document date:	2017-10-01
Group:		Individual Submission
Pages:		37
URL:            https://www.ietf.org/internet-drafts/draft-clacla-netmod-model-catalog-02.txt
Status:         https://datatracker.ietf.org/doc/draft-clacla-netmod-model-catalog/
Htmlized:       https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-clacla-netmod-model-catalog-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-clacla-netmod-model-catalog-02

Abstract:
    This document specifies a YANG module that contains metadata related
    to YANG modules and vendor implementations of those YANG modules.

                                                                                   


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

.


--------------93D8A4F273563232F76560D8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    What's new in this draft?
    
   o  Add a belongs-to leaf to track parent modules.

   o  Add leafs to track dependents and dependencies for a given module.

   o  Simplify the generated-from enumerated values.

   o  Refine the type for compilation-result to be an inet:uri.

   o  Add leafs for semantic versioning.

   o  Reorder the organization leaf to be with other module keys.

   o  Add text to describe generated-from and semantic versioning.

    All of this is implemented already in the yangcatalog.org, except
    one which we're busy finalizing: the semantic versioning.

    https://www.yangcatalog.org/yang-search/module_details.php starts to
    be quite complete.

    

    
Regards, Joe and Benoit

      

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

        
          

            Subject:
            
            New Version Notification for
              draft-clacla-netmod-model-catalog-02.txt
          

          

            Date: 
            Mon, 2 Oct 2017 07:16:11 -0700
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Benoit Claise <bclaise@cisco.com>, Joe Clarke
              <jclarke@cisco.com>
          

        
      

      

      

      
A new version of I-D, draft-clacla-netmod-model-catalog-02.txt
has been successfully submitted by Benoit Claise and posted to the
IETF repository.

Name:		draft-clacla-netmod-model-catalog
Revision:	02
Title:		YANG module for yangcatalog.org
Document date:	2017-10-01
Group:		Individual Submission
Pages:		37
URL:            https://www.ietf.org/internet-drafts/draft-clacla-netmod-model-catalog-02.txt
Status:         https://datatracker.ietf.org/doc/draft-clacla-netmod-model-catalog/
Htmlized:       https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-clacla-netmod-model-catalog-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-clacla-netmod-model-catalog-02

Abstract:
   This document specifies a YANG module that contains metadata related
   to YANG modules and vendor implementations of those YANG modules.

                                                                                  


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

.



    

  


--------------93D8A4F273563232F76560D8--


From nobody Tue Oct  3 08:41:06 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D478134DFC; Tue,  3 Oct 2017 08:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.372
X-Spam-Level: **
X-Spam-Status: No, score=2.372 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, 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=no 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 3N7Eqy9dQXaA; Tue,  3 Oct 2017 08:41:02 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0130.outbound.protection.outlook.com [104.47.2.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE03124F57; Tue,  3 Oct 2017 08:40:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t7Qg+UIYZOQEeA8URyWOz9FyiMpCXxme9hVLGADulNI=; b=Iv488BAsdGmp0aiueuiZhVtsanPe51YFFi2ttoKc6+pFWKqhjrzwLY3F8gSOTfM8G/h8JZXUybLsjmfj4KTZfwYsD9NdDJ1RsXj8ridBA1zsxEiW4WaUVtht6e1K9t8YW1/eVJuf3TfULACMlTegTaExA1bRBJ9fNTYlz5nub2E=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (109.146.128.123) 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.77.5; Tue, 3 Oct 2017 15:40:57 +0000
Message-ID: <000201d33c5d$bad62da0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Kent Watsen" , 
Cc: , 
References:  <6B61FA71-CD63-4501-A1B7-F661F943C9AA@juniper.net>
Date: Tue, 3 Oct 2017 12:23:50 +0100
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: [109.146.128.123]
X-ClientProxiedBy: AM4P190CA0009.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:56::19) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: a0edb8a2-7586-4ea4-f2af-08d50a752441
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR0701MB3003; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:A8riXBtYZPHTX9dD1YdHVNEB0R+svmijbNEe75Cj3FlkOdiA7Pw1e+wSO3tK21A7W2oy8U3zeNOg1f0fGlOeJyCT1AmIHwifjw4jtMEontvDBH9BeoJTklLyAffC37xbbHjVY8Wz6kKOU6HNl5G6d2mUfSkrFWNVOGlOFO10nx91XX+slx2XXeSdrsoB1Dt0sKWa/qeQ9Y8e52e1jQ/l4z3rNGeEpZfLSqM73aKOtP8crswkTtfuP94S9tRCagBo; 25:Q999CpkA7DAUBbMmqZcbq+wvrEgs9i6U+0rEhZl2gHXJN21G2/jRPrD+TcfGH5TJLamuE1Lm/tH6rAW/FIUnMas/MoxWGxXoC4VupSii9Bd7U8g5eAKvZh40o/W6gUX7/SUS2fxKv9ZOx0h8Qeqn9eVjJjhqvFJvlrh5SIkNiPQDJIv0WVxMBa5sFx/KiGnb//S8ECPJTwQ/bAYAXQH6mhvtAKLk/bBdIboGOfFxxbJp3DYss1y2cmX0cXLHF07cfW6yU0zDlX3zAlyjTTEy837S2xQoBFtDvzsYM/ujQdTEfbwcom0PyZsQ/lkWQUrhcRpD8ljh7Lnlu+a1R9VGdg==; 31:cTh/jQniL6xtTA0RD1YFDtDPXjZkQ5gtz648dIB8l/6CVjAV+FVLwBNlzAVO9G1YhL6YHsavXyfSKUQJeTYygi1DLYsDhEx8knMuZ1AHlB3zDtK8Jni5E/qZJ/bDC9DFTPcCTIDm7ZbxC58wU3WYNDUfkGaGT2gD5sQpgcEmNveWoYHU/NnZkxhIVnEXMrDMlumAPMZ5jZ71ClHBj3dlmbrbttexECZsg7fmWk0vPkI=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003:
X-Exchange-Antispam-Report-Test: UriScan:(166708455590820)(138986009662008)(100405760836317); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3003; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 4:OsHTvpwkEgJkagSwmjJqcpRI25v4gIoS6k9x93X6/PFzhAirw3eJcecaisLePmlSK09amsPv5qscjgTicbfvu8m+Gkm/kGi8UCQCV/wyNBIq59VXm7u4DzTnqwc4RY3AC+PTZFt4gMo11fLeGWxS5bb/Ar9m+o5ICefl7vxlMwl1MaFJB9lQL+PNtzFnHU0KeiNt/V1ICPAW6y2/kS1pasBWcnqtvyNWGAMWjCGEckKtJoYFyyD9Z9rOPccSKme0bW5jAvcaodk1GZKn9CewA8SxeBjDHwy6VsaEE2hIfWOWReHlW0fsUt3XiLmCMAEJ1lm4fsN0Ijt8lNCA8PIpZNbLakKtk4sFuRvgOBFBNk15JEQmD7hiPMH9pVVFQzc7
X-Forefront-PRVS: 044968D9E1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(377454003)(189002)(199003)(13464003)(14496001)(1556002)(189998001)(6246003)(4326008)(81686999)(7736002)(61296003)(76176999)(53936002)(6486002)(81816999)(8676002)(50226002)(106356001)(50986999)(84392002)(8936002)(2906002)(81166006)(81156014)(6496005)(44736005)(105586002)(230700001)(33646002)(68736007)(6306002)(966005)(3846002)(478600001)(97736004)(230783001)(54906003)(8666007)(305945005)(9686003)(1941001)(229853002)(116806002)(1456003)(316002)(110136005)(86362001)(16526017)(5660300001)(23756003)(47776003)(25786009)(4720700003)(44716002)(6666003)(50466002)(66066001)(101416001)(62236002)(6116002)(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: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:GcVovJR1JrxRHrNbvXWSGfg8OSNdIjn13qN6m?= =?iso-8859-1?Q?E0mMYHQzd577HwmnB+vXGRkGl3VVe60GQ1OnWc6hq6ImGARlYWrCzdRiV4?= =?iso-8859-1?Q?gI7dv9ZH2DfA7LE4deKBvkepWrqf5Rqa5QjbKLuLbREfsYA8cOnDyVBe0k?= =?iso-8859-1?Q?rWguqXyYZvltvJJNijun2IN534+Ws7imRzt0/YOFYuYqC7HPNnp+1o3Aft?= =?iso-8859-1?Q?D8QW8Wc+C3FBzrLrqTditZGCObt3W8JkIh13HhYvM7CFH1yeNaNwCfCEIe?= =?iso-8859-1?Q?14VO7RiS16WQfp3Bux0gVfiWqHQPqjIUxjFn0JLUB83PWgnkRy7EFZW12r?= =?iso-8859-1?Q?0tLFpWxNSmcj4i4+/n9mxIAeXUlV5eK5v+GtNngvOFcb91FTh4ezRP8n3L?= =?iso-8859-1?Q?1beO+T0goC6o4LTs7sBAV2ySZEc/P2R748z3OX17D/2iXtERBeFCt3ljAO?= =?iso-8859-1?Q?MzzJra6S/iFCCWYoC4Mq09VjcIdGeDOW8X+EOAQJvYHSBQlxsWW7vFkr/w?= =?iso-8859-1?Q?aaxCC2Bn9EC+4F3++xO05P+R+yVvkpmnj/Gd2VJNVyuyI1iALE9oVlV0+r?= =?iso-8859-1?Q?9f0n9Ix082wOLazBC1KnQQI/CC6/ePWHtx6G20H+n1yalu2CIlGjuZsK/O?= =?iso-8859-1?Q?Ztr5wDcsdVVEhDHFqOEdOaev4VEUY66yCglqqRQgFK2kdUjK9U85AsrBjq?= =?iso-8859-1?Q?m0bkssv+eLsxhaWOWlVuhADN+9IWrqjfC2BMqUWsiq4cL9OSzCpbknevyM?= =?iso-8859-1?Q?huRPDuez4Rn881unlJ83qsD2T4R+Obiuc+qTXnDQPXH/BTa4JM8h92Z063?= =?iso-8859-1?Q?jG0pc3xdtG2gWA1EGf2IPNqoJHqUQsv1cgsn2EyauINazSOQsWSZ8Ym3ni?= =?iso-8859-1?Q?CwyUAkVIORWcvbxPqZ54O7PvPfcEbNTClDq7rQKeYhFobWrNmjLBxVzQD0?= =?iso-8859-1?Q?kvH2C1mc3/pB1WjoI3fxs4W9jIq0h8BjCUItVrPcuIF9x5t8OryYGlWQDv?= =?iso-8859-1?Q?38JNzxhMfT2PqLY0UzHNxL8Pw0SbbiLM/fhQ5kLqkWLI6++InvAjxgiyzG?= =?iso-8859-1?Q?WLzy78elnVxNh6IzWzxsC+RvPn1MYf60p3N75/4cXNEbIplRG9u8xwkvHM?= =?iso-8859-1?Q?aiOe18oR7o7jFD8za99HMSivTTdS9OfT64N1duB6xiQFrTdSg7OKH1+N0z?= =?iso-8859-1?Q?SH8ZOy+eQ5CsoqUUkgRw4l02RbfH7+aTTpJv2i3uDSDHRn/0hK3X/AOGh9?= =?iso-8859-1?Q?Jlw+AGMZ4Dts4rNs+BykGBxigAfUvLzEGwoAMxObaOJmjlxKUGkE9XgzC5?= =?iso-8859-1?Q?8yYsSKizs03BnIYeBK9CYNpQ4MH8HOKTPtwIcQCZXYDAO6ZWgm/k18545D?= =?iso-8859-1?Q?ztAqn1BRnbEASXjnyI66zxLm+zFSsLyruVAcC7ZZiVmgdGVz3xHZJMj+6f?= =?iso-8859-1?Q?E/DtJjaS1wnvOM4PNjE6baY4L6e6/Au62NdNBpbB90Z4D6zyRWWDri41ub?= =?iso-8859-1?Q?XMFk3f0xiHU+3wPjHtlR/zMjIwwqhE3qujMFLWzs7EztWNmlRATOUNk30p?= =?iso-8859-1?Q?BQzvJnFAb37lDgZ6yK77ESqd6gEQ=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:th2VffE/QVLev8QJ96NvteJP7rK5pu9G1ou0G3nD2EWqONqX25cWTNXCq+s4TcFGup4G4C/mNOCt1BLI1jsbLTRT0wx/ZZXRW1P4ZynySHZiVW0B/uL36YiZ81xy8WrUHvKBTEsLF2Nzse3mxKd70etK34qYzK7ggMZg0BM4WGjCTyvspJw3iUDCw7ixRzIk4HlHKwGw2YEwHplj8P0paZhxgOmJJt6gz8k7lHWv7oYpoJc/Ayu31NNRXDLa0sVn13XJg3MXMSKAbh39L7hTbgVKPFBBZph/ll3WGfejUDy2gHuaFXH8qg72/Av5CnC2ED2TMUZKzPGEKuhua2NVow==; 5:RXEzceTs8pF+1q+Q2Kvs0o82EyTGXxB/bwMPBZvnFkA7Pbi8axUOcTuaSv43wdnAe7JBoeHBVQJLrUgiUhbgPtHaOoluiUq4Rkk1lfhQl9MsfXA6sRcSiwMHVevF04b1zjdj16jZxubJqNcqZH79RA==; 24:T5wPAUbyTNvPedZ5BZT1b/n4rWSvFsx3KmtV13I8NvYN7KGG4PN037Tvs/e5vo+6xrvEK+Vgu2z+Eu7FkPrD8voX/5zo44E8xCwpPw2gewk=; 7:UXBp5zZ2NRuuhsEtlPhd1Ho73aLN2KLiRIdqRz0c0SG9/7EXnbAExIZw5QklSK8Wc7nipz2qa5dKEov0Jmgk8x5T8kd7RsbyGrGyaKUv+JsxIAXvoVghZtmeUvFMmCBbBPpEZBZVsVSKcQgRFt/lMZwYPCHeuH2OIrY0ZPHdko4OODhX8eX6YHB/RZ5lB6UpPnCvcW0BobDrcOuwfFQAKcTJwodwR9qKJr0i8Awob1s=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2017 15:40:57.3233 (UTC)
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] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 03 Oct 2017 15:41:04 -0000

----- Original Message -----
From: "Kent Watsen" 
Sent: Monday, October 02, 2017 9:06 PM

> The Last Call for this document has completed with *no* responses,
other than Benoit's question regarding if it should be a BCP, which also
had no responses, other than my own wondering if YANG (and hence the
guidelines) was stable enough.
>
> Lou and I discussed.  It is our opinion that, given the nature of this
document, the WG implicitly supports it already.  So, really, the only
thing that matters, is if there are any issues/concerns.  Since no
issues/concerns were raised, we choose to declare the Last Call
successful.  As for promoting it to a BCP, there appears to be no
consensus to do so at this time.   Accordingly, as the document
shepherd, I plan to send the shepherd write-up (with these comments
included) to the AD in the next few days.

Kent

The trouble is that a number of other things have been going on, mostly
NMDA and the
ramifications thereof, and so this one never moved up my todo list.

Yes, it is an I-D that matters, the timing is unfortunate.

Tom Petch


> Looking forwards, we've created a new GitHub repo called
"guidelines-next" (modeled after yang-next) to capture on-going
comments/suggestions for future updates to the document:
https://github.com/netmod-wg/guidelines-next.
>
> Kent (and Lou)
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Oct  3 11:24:26 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49CC134FCA; Tue,  3 Oct 2017 11:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=nio365.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 3DiIohfbcyIc; Tue,  3 Oct 2017 11:24:22 -0700 (PDT)
Received: from mx0b-00010702.pphosted.com (mx0a-00010702.pphosted.com [148.163.156.75]) (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 154DC134FC6; Tue,  3 Oct 2017 11:24:22 -0700 (PDT)
Received: from pps.filterd (m0098781.ppops.net [127.0.0.1]) by mx0a-00010702.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v93IKMBX005400; Tue, 3 Oct 2017 13:24:20 -0500
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0018.outbound.protection.outlook.com [216.32.180.18]) by mx0a-00010702.pphosted.com with ESMTP id 2dcfp4g2kc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Oct 2017 13:24:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hxIWRnDWa65EIDl1c6AqhIfFZncxNRA42UoAawJpgdM=; b=hiLMbA+fdNOYQl4VCtmwd7HHxqo/9neO+YJOIIU9BHCc0EDK1asdrpFEyk88KFfBM9pqhp69hRDq2gm5XOEkB4CsAhrP9v3htSGi8WX9UFoOIRMssXapUj9q0dZWtz5dMRpMhUek4oBfIaowJas0aT+eVoY+Y/vTrMKnIb4dSQA=
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com (10.160.219.156) by DM2PR0401MB1392.namprd04.prod.outlook.com (10.160.221.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 3 Oct 2017 18:24:17 +0000
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::b172:affa:cf1d:384e]) by DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::b172:affa:cf1d:384e%18]) with mapi id 15.20.0077.016; Tue, 3 Oct 2017 18:24:17 +0000
From: Rodney Cummings 
To: Martin Bjorklund 
CC: "tictoc@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number
Thread-Index: AdM7naceqW92Otk+TBSUBZ12gBb0TQADKMgAADGI7JA=
Date: Tue, 3 Oct 2017 18:24:17 +0000
Message-ID: 
References:  <20171002.201430.1078877259363120382.mbj@tail-f.com>
In-Reply-To: <20171002.201430.1078877259363120382.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.164.62.43]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0401MB1392; 6:WAZVXN1MV8W/XZZDtYh+Sni28gtAZa7DH95PsVLnFZmnkgmQiWlaToy3T4kf8rg6kfGZMHbcZuPQOm6O3qzZXWS9YkRNY5GVgl2LSmH6cMU3jNCAQCRvmpIZcvzrVtkggS6X144mdutqvufOMIBDnxNU5su8JZXpYFv8MjTkySmkkKrt9TU1dKj6ZRPCC+ClvNuaUauKlAZl7MgvxvzZzTwfV53zrHJJtlIF0S6ytKcuJvkqamLpuCK5DndL/ooSnkq01IlCyW/ObuPodfP6qpJ+xEEp6rTr/oJnelFTjh8EGI/9y4dwtMONZouVrrlPD955XenuLunjThRxDCc1YQ==; 5:NwkrQ4tucDvMX9xlqpM0XqPf+3sXSPtvgAzri7axr8fBu5OcpAUOKJWSuJjS5lP7ggy9qTFc+YbSavFs9jjGpqAtlNw5BTWy9Alw9yxAj0rjqhrggZQTfTq0rYS6WsA/cFTyeih7hg5YPCkEdlK6Yg==; 24:/bQCkzJ2hIh0nzdKR3yn9i6Qeahi/DruyXraAq1lX5n+zr7NYcQzBfFWSOvk73IGhXGC4rh2bhdIZQrx2gWu8pNZNvuFd+5NY6yAizlT474=; 7:uOLysw97HuQqYvAvu2UPk1hOzX3iofwcU7FibQX6Hw739l5yDZH5zObMhugYZ90Gt1yzpvgvpa6EuTQYLaNJF12PxqU+h/vL4Thuv1B7ZpkCCGuRyH7xuKaUiZHztxojegViN32oocvMUB+PMvF8bHxe2oDVL8hlMSjnIaneSsfhR//Iz5ujiJk+MsId+7JDvX8HolUMFTIzqcoqbRMiMcA75G2waQa+xzMZrV13TiU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: fe83d4fe-6c0a-49ac-afae-08d50a8bf58b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR0401MB1392; 
x-ms-traffictypediagnostic: DM2PR0401MB1392:
x-exchange-antispam-report-test: UriScan:(10436049006162)(145744241990776);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0401MB1392; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0401MB1392; 
x-forefront-prvs: 044968D9E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(199003)(377454003)(51444003)(13464003)(189002)(24454002)(105586002)(2950100002)(74316002)(5660300001)(8676002)(6436002)(6916009)(81166006)(81156014)(7696004)(14454004)(50986999)(2906002)(54356999)(76176999)(3660700001)(6506006)(3280700002)(8936002)(25786009)(66066001)(229853002)(4326008)(3846002)(6116002)(102836003)(101416001)(33656002)(106356001)(966005)(478600001)(305945005)(7736002)(97736004)(99286003)(55016002)(53546010)(575784001)(230783001)(54906003)(9686003)(6306002)(2900100001)(53936002)(5250100002)(86362001)(6246003)(316002)(68736007)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0401MB1392; H:DM2PR0401MB1389.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ni.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2017 18:24:17.7534 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0401MB1392
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-03_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710030259
Archived-At: 
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 03 Oct 2017 18:24:25 -0000

Thanks Martin,

Your rationale sounds reasonable to me. We can use the description to
explain differences in the models for the reader.=20

Your rationale got me thinking a bit about clock-identity. The 1588
information model and protocol uses clock-identity as a member of
port-identity (along with port-number). Nevertheless, that
instance-list[instance-number]/port-identity/clock-identity=20
is equivalent to instance-list[instance-number]/clock-identity
(part of grouping default-ds-entry in draft-ietf-tictoc-1588v2-yang-05).
So... we are currently repeating clock-identity as we repeated
port-number. If we apply your rationale, we can remove that
repetition as well.

I propose that we go with Option 2, but without using a grouping,
and use the same approach for clock-identity.=20

This would look like:

list port-ds-list {
   key "port-number";
   leaf port-number {
      description=20
         "Port number.
         =20
         The data sets (i.e. information model) of IEEE Std 1588-2008
         specify a member portDS.portIdentity, which uses a typed=20
         struct with members clockIdentity and portNumber.

         In this YANG data model, portIdentity is not provided as
         a container, but both of its members are provided as a leaf.
         portIdentity.portNumber is provided as this port-number leaf
         in YANG. portIdentity.clockIdentity is provided as the
         clock-identity leaf in the instance (i.e. ../../clock-identity).";
      type uint16;
   }
}

Rodney

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Monday, October 2, 2017 1:15 PM
> To: Rodney Cummings 
> Cc: tictoc@ietf.org; netmod@ietf.org
> Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05: port-number
>=20
> Rodney Cummings  wrote:
> > Hi folks,
> >
> > One of the last topics that we need to resolve for WG Last Call of
> > draft-ietf-tictoc-1588v2-yang-05 is the representation of port-number,
> > which serves as the key to the list of 1588 port data sets
> > (i.e. port-list). I've had some offline discussion with IEEE 1588 WG
> > members, and I'm copying NETMOD members for YANG expertise.
> >
> > I think we can narrow the possible options to two, so I'm starting a
> > new thread to focus on those.
> >
> > IEEE Std 1588-2008 is the time sync standard that specifies the
> > information model on which draft-ietf-tictoc-1588v2-yang-05 is
> > based. In IEEE Std 1588-2008, subclause 5.3.5 specifies the following
> > data type to identify each logical port in the 1588 product:
> >    struct PortIdentity {
> >       ClockIdentity clockIdentity;
> >       Uinteger16 portNumber;
> >    };
> > IEEE Std 1588-2008 uses this data type as the "portIdentity" of the
> > port in its on-the-wire protocol, state machines, and so on. In other
> > words, in the 1588 standard itself, portIdentity is a "real thing"
> > with real implementation.
> >
> > IEEE Std 1588-2008 also specifies a list of logical ports in each
> > "clock", and portIdentity.portNumber is used as the key to that list
> > of ports.
> >
> > In the YANG of draft-ietf-tictoc-1588v2-yang-05, we use YANG-style
> > names (e.g. port-list, port-number), but otherwise we've tried to keep
> > consistent to the IEEE Std 1588-2008 information model.
> >
> > We have a challenge with port-number. If YANG represents port-identity
> > as a container within port-list, YANG does not allow a key to be a
> > leaf within a container, so we cannot use port-identity/port-number as
> > the key to port-list.
> >
> > It seems that we have two options:
> >
> > Option 1: Use a leafref
> > ---
> >
> > YANG summary:
> >
> >         list port-ds-list {
> >           key "port-number";
> >           leaf port-number {
> >             type uint16;
> >           }
> >           container port-identity {
> >              leaf clock-identity {
> >                 type clock-identity-type;
> >                 config false;
> >              }
> >              leaf port-number {
> >                 type leafref{
> >                    path "../../port-number";
> >                 }
> >                 config false;
> >              }
> >           }
> >         }
> >
> > This has disadvantages from the YANG perspective, in that port-number
> > is duplicated. The "config false" is intended to mitigate YANG
> > implementation challenges, such that only one value of port-number is
> > provided for configuration.
> >
> > Option 2: Use a grouping
> > ---
> >
> > YANG summary:
> >
> >      grouping port-identity-grouping {
> >        leaf clock-identity {
> >          type clock-identity-type;
> >        }
> >        leaf port-number {
> >          type uint16;
> >        }
> >      }
> >      list port-ds-list {
> >        key "port-number";
> >        uses port-identity-grouping;
> >      }
> >
> > This has disadvantages from the 1588 perspective, in that it is not
> > possible for a 1588-aware management client to "get" portIdentity. We
> > are removing a 1588 "real thing" from the data model in order to
> > accommodate a syntax limitation of YANG.
>=20
> I think that in general when you go from an information model to a
> concrete data model, you need to adapt to the data modelling language
> you are using, and this will in most cases mean that there will be
> some differences; in some cases the data model structure is different,
> and in some cases the data model will result in a more detailed
> model.  How keys are specified is one such example.  If you were to
> use SMIv2, you'd have to change the names (so that they are unique),
> and you'd have to map the structures to conceptual tables.
>=20
> Clients need to understand the data model in use (not just the
> information model behid it).
>=20
> > Question for NETMOD experts
> > ---
> >
> > My personal preference is Option 1 (leafref). Nevertheless, if the
> > "config false" does not provide sufficient mitigation for today's YANG
> > implementations, we can go with Option 2.
>=20
> I don't think any implementation would have any problem supporting
> option 1, but it does look a bit odd.  Also, it only "helps" if the
> client is getting the data using , but it will not help if it is
> using .
>=20
>=20
> I think that the cleanest solution is to not try to completely mimic
> the structure from the information model, but make sure that the
> text in the description statements make it clear that the data model
> looks different compared to the information model, in order to help
> the readers.
>=20
>=20
>=20
> /martin
>=20
>=20
>=20
> >
> > Feedback is very much appreciated.
> >
> > Thanks folks,
> > Rodney Cummings
> > Co-author draft-ietf-tictoc-1588v2-yang-05
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DI_0YwoKy7z5LMTVdy=
O6YCi
> E2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=
=3DHQ-
> S1mMpOcwPGLxrc9fTcSPc3vMBTRPINVlW5icLVhI&s=3DvW2fbaZlyBrALsCxc0EC961aVU3t=
5gm
> DrURSXdnPR8A&e=3D
> >


From nobody Tue Oct  3 14:59:29 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 866C9132F3F; Tue,  3 Oct 2017 14:59:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150706796848.30662.11163600742801874248@ietfa.amsl.com>
Date: Tue, 03 Oct 2017 14:59:28 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-14.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 03 Oct 2017 21:59:28 -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-14.txt
	Pages           : 55
	Date            : 2017-10-03

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-14
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-14

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


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Oct  3 16:57:00 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B021C1341F8 for ; Tue,  3 Oct 2017 16:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlSRD7IQ9Jxa for ; Tue,  3 Oct 2017 16:56:56 -0700 (PDT)
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 BC93A13232C for ; Tue,  3 Oct 2017 16:56:56 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id i195so5578745pgd.9 for ; Tue, 03 Oct 2017 16:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=GKls5AZISM5SSxfzJAVgNcPKFAsemTFmHOY1N4ZFU9o=; b=B5R4PM6TviXnMH98GFrc3M4bJVBls7y6lIqDQEFTjRwG6SMoD2wZy57EEzG1OleBuL k4hIjshcvsXZfF0ym4VyQc/tY6zVRyVStx4Battg1B4DbZHNf3F1O/bBO6j8tz1nAxsL DemZiEOvirsHl0/2m8lsKDmsijaozZMYnGBnh0d4Wsn+F/z4g7EcKzDwquoSZFwbTQUT Ae6XIi4StXLy+GyUppBojHB7iU9qr6RkdrNMwKAU8plyP6G0mY7kKdGT2MmjQeVgXs6w 8NmbUlv9NgHYhyaCow227eoU3a8DYSf3IhSUq475O2sh7Mk2eFr8XHUKD12Y5tS0zzNq CClA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GKls5AZISM5SSxfzJAVgNcPKFAsemTFmHOY1N4ZFU9o=; b=aimfOBRZtZZeM5DkojYhgLM+wNCdgyh6SRfLatkRTjjCN00LgsnqL/yKhMo9hS+H73 W7JwStxTl9nLLNIau3fBwDT5dkx/3lS/8FqQKxIg/h2iEbESP0Ef+jyMMkXPt1wpQj3i 8kIoaV862Gh+V43n2f6ToJZJzJDVGGYSTt2FyAzBpyQLKlzd3kMm1/eLT41prrLyUOBp /VUaTJn5VAQjNq8OdFvIol7JfSJrr31IHVGhIzp88eynBgzhBQX01Vvo7Wa2foWY9sSQ M5PtS2edjhWchdMXo1CiUOqFNwgJCtD2BdthhaCu1ZhMLPBB6SP9acTXW4aZl3xeXE91 oi+g==
X-Gm-Message-State: AHPjjUi+ioelPuqJnuY6jYQxJaMcD8z2T6UFuBediC0M4YRMAF9GZ3tT 7aAtZcJSrmYKLGjraOYVTOGEySYT
X-Google-Smtp-Source: AOwi7QDEopl5MOpwdpnnyJWVvSlHxDqmqvt0N+aGHCd14nYyjk6PRZ/6r98Ox6x4Mp0BTczZWKxv5A==
X-Received: by 10.99.117.65 with SMTP id f1mr17000533pgn.104.1507075016247; Tue, 03 Oct 2017 16:56:56 -0700 (PDT)
Received: from [10.154.131.13] ([128.107.241.185]) by smtp.gmail.com with ESMTPSA id c16sm22682390pfj.123.2017.10.03.16.56.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Oct 2017 16:56:54 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_317CEFB0-F08E-4E61-88C3-D041A81E5413"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <050801d33b9c$ed929560$c8b7c020$@jpshallow.com>
Date: Tue, 3 Oct 2017 16:56:55 -0700
Cc: netmod@ietf.org
Message-Id: 
References: <050801d33b9c$ed929560$c8b7c020$@jpshallow.com>
To: Jon Shallow 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-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, 03 Oct 2017 23:56:59 -0000

--Apple-Mail=_317CEFB0-F08E-4E61-88C3-D041A81E5413
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Jon,

=E2=80=98ordered-by user=E2=80=99 directive is useful to have on list of =
ACLs as/when they are applied. For example, in the latest published =
draft (-14) we added the 'ordered-by user=E2=80=99 statement to the list =
of ACLs when they are applied to the interfaces. You would not order the =
=E2=80=9Cglobal=E2=80=9D ACLs list (under access-lists), because another =
interface may want a different order of ACLs.=20

Does that help?


> On Oct 2, 2017, at 9:38 AM, Jon Shallow  =
wrote:
>=20
> Hi there,
> =20
> I=E2=80=99m currently working on another draft ietf specification =
(draft-ietf-dots-data-channel) which has a ordering requirement, but the =
=E2=80=98ordered-by=E2=80=99 statement is not specified (missing?)  for =
the =E2=80=98list acl=E2=80=99 in container =E2=80=98access-lists=E2=80=99=
 in 4.1 IETF Access Control List =
"ietf-access-control-list@2017-09-12.yang =
".=20
> =20
> Container =E2=80=98aces=E2=80=99 has the =E2=80=98ordered-by-user=E2=80=99=
 statement for the list ACE.
>       container aces {
>         description
>           "The access-list-entries container contains
>            a list of access-list-entries(ACE).";
>         list ace {
>           key "rule-name";
>           ordered-by user;
>           description
>             "List of access list entries(ACE)";
>           .....          =20
> =20
> Container =E2=80=98access-lists=E2=80=99 does not have the =
=E2=80=98ordered-by-user=E2=80=99 statement for the list ACL.
>   container access-lists {
>     description
>       "This is a top level container for Access Control Lists.
>        It can have one or more Access Control Lists.";
>     list acl {
>       key "acl-type acl-name";
>       description
>         "An Access Control List(ACL) is an ordered list of
>          Access List Entries (ACE). Each Access Control Entry has a
>          list of match criteria and a list of actions.
>          Since there are several kinds of Access Control Lists
>          implemented with different attributes for
>          different vendors, this
>          model accommodates customizing Access Control Lists for
>          each kind and for each vendor.";
>       .......
> =20
> Is there a good reason why =E2=80=98list acl=E2=80=99 is not defined =
as sortable?
> - or is it defined elsewhere as being sortable?
> - or is the intention that there can only be one ACL?
> =20
> We potentially have a requirement for multiple ACLs, each with its own =
set of sorted ACEs where the ACLs cannot be configured in a random order =
and need to know how to move forward.
> =20
> Regards
> =20
> Jon
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_317CEFB0-F08E-4E61-88C3-D041A81E5413
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Jon,

=E2=80=98ordered-by user=E2=80=99 directive is useful to have =
on list of ACLs as/when they are applied. For example, in the latest =
published draft (-14) we added the 'ordered-by user=E2=80=99 statement =
to the list of ACLs when they are applied to the interfaces. You would =
not order the =E2=80=9Cglobal=E2=80=9D ACLs list (under access-lists), =
because another interface may want a different order of =
ACLs. 

Does=
 that help?


On =
Oct 2, 2017, at 9:38 AM, Jon Shallow <supjps-ietf@jpshallow.com> wrote:

Hi there,
 
I=E2=80=99m=
 currently working on another draft ietf specification =
(draft-ietf-dots-data-channel) which has a ordering requirement, but the =
=E2=80=98ordered-by=E2=80=99 statement is not specified (missing?) =
 for the =E2=80=98list acl=E2=80=99 in container =E2=80=98access-list=
s=E2=80=99 in 4.1 IETF Access Control List "ietf-access-control-list@2017-09-12.yang". 
 
Container =
=E2=80=98aces=E2=80=99 has the =E2=80=98ordered-by-user=E2=80=99 =
statement for the list ACE.
      =
container aces {
        description
          "The =
access-list-entries container contains
           =
a list of access-list-entries(ACE).";
        list ace {
          key =
"rule-name";
          =
ordered-by user;
          =
description
          &nb=
sp; "List of access list entries(ACE)";
          =
.....           
 
Container =
=E2=80=98access-lists=E2=80=99 does not have the =E2=80=98ordered-by-user=E2=
=80=99 statement for the list ACL.
  container access-lists {
    description
      "This is =
a top level container for Access Control Lists.
       It can have one or more =
Access Control Lists.";
    list acl {
      key =
"acl-type acl-name";
      description
        "An Access Control =
List(ACL) is an ordered list of
         Access List =
Entries (ACE). Each Access Control Entry has a
         list of =
match criteria and a list of actions.
         Since there =
are several kinds of Access Control Lists
         implemented =
with different attributes for
         different =
vendors, this
         model =
accommodates customizing Access Control Lists for
         each kind =
and for each vendor.";
      .......
 
Is there =
a good reason why =E2=80=98list acl=E2=80=99 is not defined as =
sortable?
-=
 or is it defined elsewhere as being sortable?
- or is =
the intention that there can only be one ACL?
 
We =
potentially have a requirement for multiple ACLs, each with its own set =
of sorted ACEs where the ACLs cannot be configured in a random order and =
need to know how to move forward.
 
Regards
 
Jon
_______________________________________________
netmod mailing =
list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_317CEFB0-F08E-4E61-88C3-D041A81E5413--


From nobody Wed Oct  4 13:22:04 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6913447B; Wed,  4 Oct 2017 13:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J7nuhXJ70QY; Wed,  4 Oct 2017 13:22:01 -0700 (PDT)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 1C8D313430E; Wed,  4 Oct 2017 13:22:01 -0700 (PDT)
Received: by mail-pg0-x231.google.com with SMTP id s184so5435524pgc.0; Wed, 04 Oct 2017 13:22:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q62mJwLyYtnk83uabOtFGmCZkFah08IBSV0Abqdz40M=; b=IH13CSTMDCYJjZk/U7jjzn+KW2OJIKxrQ0Lxtu9NWC5F/kvFwZT8zjC2rhS6/4uFqI xzJeqygPxYhuA8BG2fTjvxZL/saqxtQpuXpFVpmFGW7t7kmI8jc6NWBwvHEaP12lkcKd 7uQJeFCpgUihcAC7aJlM6Q+BW17n82wY5+zi6vwGNtrOP5F31gN1AQ5q2uJyOa76ix9c 9VkZamzHsH2MlOk7P5z7xcDirXflzmt2LmsI5I7BoWozGIChwWQKwjwCPuSh2fHmPPxR 05n3la2Lq/AEuUgSt5/ulLfltVI/B6japgLxCHs13TLwn2L7oPqW98tnxtecgYxOJzhy XXtw==
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=q62mJwLyYtnk83uabOtFGmCZkFah08IBSV0Abqdz40M=; b=asbe/D3UyR3bZ6sMwNV9/a6jhujIB404udajp4yafKHYZFz0wUMrprgeIdd91EfjtM dq+QEiQ+/4FDqWf1+Be7ZFVpAYP1YxELGhQbZ1k3v6Vhf5an7YrkuX6dgXqxhrYlMpB3 gluDXvYe2rBsCeLXkPmdu4CiQGCfxitp5KSmRYM0E0EQHN6XCWlloK2a84xl6dyBpA9i PelihCjL+1Vv4T7Bm5ApdE6iKPApRDxCJmoBe1K3xQk/8X8cLheaLAPh/j3i8mlKnok+ 0cuGW+toPtR56DJayNU9JKf5hbbiGua3Cp3gKy4XArweQSAQDd4anl+sXzXAf2yrx/wa 6FhA==
X-Gm-Message-State: AHPjjUh0bKsw2dS+3mO91LyViRKLikiELEO45Bdd6eoiCaL/O7gzUUlJ fWh9S8iOUkEATyWTm4UloQbyh4Zv
X-Google-Smtp-Source: AOwi7QDKdeoEC/9rkoxhQY2CLeTq605MGd9jGYbrZwll4bmbEqAswrVwwty41sjh9KjGjlflPD1LGw==
X-Received: by 10.99.175.14 with SMTP id w14mr19652131pge.365.1507148520171; Wed, 04 Oct 2017 13:22:00 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1320:15ce:87f1:cff1:16e8? ([2001:420:30d:1320:15ce:87f1:cff1:16e8]) by smtp.gmail.com with ESMTPSA id p70sm29450571pfk.130.2017.10.04.13.21.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Oct 2017 13:21:58 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <150706796848.30662.11163600742801874248@ietfa.amsl.com>
Date: Wed, 4 Oct 2017 13:22:02 -0700
Cc: i-d-announce@ietf.org, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <150706796848.30662.11163600742801874248@ietfa.amsl.com>
To: internet-drafts@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-14.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, 04 Oct 2017 20:22:03 -0000

This version of the drafts addresses the remaining comments we received =
on the document. In particular, this version of the draft adds support =
for configuring ACLs under and interface, adds an ability to support =
statistics under that interface and under ACE, and changed forwarding =
actions from a choice to an identity to enable implementations to add =
their own.

At this time, we believe the document is ready for LC.

Thanks.

> On Oct 3, 2017, at 2:59 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-14.txt
> 	Pages           : 55
> 	Date            : 2017-10-03
>=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-14
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-14
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-14
>=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 Thu Oct  5 01:08:19 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E7C13416B for ; Thu,  5 Oct 2017 01:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pShWFp-NWXNG for ; Thu,  5 Oct 2017 01:08:15 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 0CA671321CB for ; Thu,  5 Oct 2017 01:08:15 -0700 (PDT)
Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e01CX-0004rJ-5F; Thu, 05 Oct 2017 09:08:13 +0100
From: "Jon Shallow" 
To: "'Mahesh Jethanandani'" , 
References: <050801d33b9c$ed929560$c8b7c020$@jpshallow.com> 
In-Reply-To: 
Date: Thu, 5 Oct 2017 09:08:13 +0100
Message-ID: <077701d33db1$17aa5160$46fef420$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0778_01D33DB9.796F7CB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ18Axf/JP9v/XDquaZDSgLRAtNwwG+35yAoYGJh9A=
Content-Language: en-gb
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-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: Thu, 05 Oct 2017 08:08:18 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0778_01D33DB9.796F7CB0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20

Hi Mahesh,

=20

I think that we can with a bit of re-work, use the interfaces concept.  =
The clue that I had missed was in the (now deleted in -04) text in the =
following section.

=20

A.2.  A company proprietary module example             =20

=20

   Access control list typically does not exist in isolation.  Instead,

   they are associated with a certain scope in which they are applied,

   for example, an interface of a set of interfaces.  How to attach an

   access control list to an interface (or other system artifact) is

   outside the scope of this model, as it depends on the specifics of

   the system model that is being applied.  However, in general, the

   general design pattern will involved adding a data node with a

   reference, or set of references, to ACLs that are to be applied to

   the interface.  For this purpose, the type definition "access-

   control-list-ref" can be used.

=20

Thanks for your help.

=20

Regards

=20

Jon

=20

From: Mahesh Jethanandani [mailto: mjethanandani@gmail.com]=20
Sent: 04 October 2017 00:57
To: Jon Shallow
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-acl-model

=20

Jon,

=20

=E2=80=98ordered-by user=E2=80=99 directive is useful to have on list of =
ACLs as/when they are applied. For example, in the latest published =
draft (-14) we added the 'ordered-by user=E2=80=99 statement to the list =
of ACLs when they are applied to the interfaces. You would not order the =
=E2=80=9Cglobal=E2=80=9D ACLs list (under access-lists), because another =
interface may want a different order of ACLs.=20

=20

Does that help?

=20


------=_NextPart_000_0778_01D33DB9.796F7CB0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


 
Hi Mahesh,
 
I think that we can with a bit of re-work, use the interfaces =
concept.=C2=A0 The clue that I had missed was in the (now deleted in =
-04) text in the following section.
 
A.2.=C2=A0 A company proprietary module =
example=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 
 
=C2=A0=C2=A0 Access control list typically does not exist in =
isolation.=C2=A0 Instead,
=C2=A0=C2=A0 they are associated with a certain scope in which they =
are applied,
=C2=A0=C2=A0 for example, an interface of a set of interfaces.=C2=A0 =
How to attach an
=C2=A0=C2=A0 access control list to an interface (or other system =
artifact) is
=C2=A0=C2=A0 outside the scope of this model, as it depends on the =
specifics of
=C2=A0=C2=A0 the system model that is being applied.=C2=A0 However, =
in general, the
=C2=A0=C2=A0 general design pattern will involved adding a data node =
with a
=C2=A0=C2=A0 reference, or set of references, to ACLs that are to be =
applied to
=C2=A0=C2=A0 the interface.=C2=A0 For this purpose, the type =
definition "access-
=C2=A0=C2=A0 control-list-ref" can be =
used.
 
Thanks for your help.
 
Regards
 
Jon
 
From:=
 Mahesh =
Jethanandani [mailto: mjethanandani@gmail.com] 
Sent: 04 =
October 2017 00:57
To: Jon Shallow
Cc: =
netmod@ietf.org
Subject: Re: [netmod] =
draft-ietf-netmod-acl-model
 
Jon,
 
=E2=80=98ordered-by user=E2=80=99 directive is useful =
to have on list of ACLs as/when they are applied. For example, in the =
latest published draft (-14) we added the 'ordered-by user=E2=80=99 =
statement to the list of ACLs when they are applied to the interfaces. =
You would not order the =E2=80=9Cglobal=E2=80=9D ACLs list (under =
access-lists), because another interface may want a different order of =
ACLs. 
 
Does that help?
 

------=_NextPart_000_0778_01D33DB9.796F7CB0--


From nobody Thu Oct  5 05:51:54 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67E132C3F for ; Thu,  5 Oct 2017 05:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnuhA2yphOHB for ; Thu,  5 Oct 2017 05:51:50 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 90F1913455C for ; Thu,  5 Oct 2017 05:51:49 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id F13BB1820F79; Thu,  5 Oct 2017 14:51:44 +0200 (CEST)
Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id 7AA2E1820E6E; Thu,  5 Oct 2017 14:51:41 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , netmod@ietf.org
In-Reply-To: <20170927.125558.606437323539289377.mbj@tail-f.com>
References: <150650952130.25003.1792240611663747386@ietfa.amsl.com> <20170927.125558.606437323539289377.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
Date: Thu, 05 Oct 2017 14:52:31 +0200
Message-ID: <877ew9zrhs.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.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, 05 Oct 2017 12:51:52 -0000

Martin Bjorklund  writes:

> Hi,
>
> This version fixes the XPath context for parent-reference.
>
>
> However, there is one more thing to discuss, which is the term "mount
> point".  
>
> The current text says:
>
>    - mount point: container or list node whose definition contains
>      the "mount-point" extension statement. The argument of the
>      "mount-point" statement defines the name of the mount point.
>
>
> So if we have:
>     
>   container top {
>     container root {
>       yangmnt:mount-point ni;
>     }
>   }
>     
> There is one mount point, the node /top/root, with the name "ni".
>
> Pretty confusing...   Does anyone have any comments around this?

What about this?

OLD

    - mount point: container or list node whose definition contains
      the "mount-point" extension statement. The argument of the
      "mount-point" statement defines the name of the mount point.

NEW

    - mount point: container or list node whose definition contains
      the "mount-point" extension statement. The argument of the
      "mount-point" statement defines a label that is used for
      referencing the mount point.

Lada

>
>
>
> /martin
>
>
>
>
>
> internet-drafts@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Network Modeling WG of the IETF.
>> 
>>         Title           : YANG Schema Mount
>>         Authors         : Martin Bjorklund
>>                           Ladislav Lhotka
>> 	Filename        : draft-ietf-netmod-schema-mount-07.txt
>> 	Pages           : 27
>> 	Date            : 2017-09-27
>> 
>> Abstract:
>>    This document defines a mechanism to combine YANG modules into the
>>    schema defined in other YANG modules.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-07
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Fri Oct  6 04:42:05 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222B2134956 for ; Fri,  6 Oct 2017 04:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.21
X-Spam-Level: 
X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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 hVIq82KauEec for ; Fri,  6 Oct 2017 04:42:02 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0136.outbound.protection.outlook.com [104.47.2.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAAA913445F for ; Fri,  6 Oct 2017 04:42:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kH/ILodBJYKCG5TrcDOHmu3yh1nGcBed+f5kLDER268=; b=QOdBFUC1g472C8j516355MLIq38mR4c5UNJ+/Sq0YUMCn0VV3VC4id39ZVeI4v2992zciw4AM2CAnH1sj6x0KpppaI1pF9RpkPqbPwJuF457eYkCT1fT+yNnFfnLD2E8qCJmTaPF5B5+R+YvpcNQ+9mv8YgrYA8Mr3OCdx/oOQw=
Received: from pc6 (109.146.128.123) by VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 6 Oct 2017 11:41:59 +0000
Message-ID: <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Ladislav Lhotka" , "Martin Bjorklund" , 
References: <150650952130.25003.1792240611663747386@ietfa.amsl.com> <20170927.125558.606437323539289377.mbj@tail-f.com> <877ew9zrhs.fsf@nic.cz>
Date: Fri, 6 Oct 2017 12:39:01 +0100
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: [109.146.128.123]
X-ClientProxiedBy: DB6PR0202CA0028.eurprd02.prod.outlook.com (2603:10a6:4:a5::14) To VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21)
X-MS-Office365-Filtering-Correlation-Id: c474feab-92f1-40e0-02ac-08d50caf4140
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR0701MB3007; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:4XcCxDn6DzXOT2Ibf4u+zoFLTprrT+fuogjERhrTt4WB/+UhdT9hJ+T65HIQOPqyXL2HtAcQgmjxETzR0+yqhEwnuAOV9PppjceeitTsta1K/prog0eYF6zqI74+HKIXxgmbjCZc7dGj18XTvVOMrtl053qudhVDtVHUBWUHCnYjCk+B38HvyT43tkdppHH6jc48auq9NWoNMwpdhME8/FEIZ+hDCkuy75lfyNq56Xx+EOgqteU8dsX3B2j7tHrE; 25:C4DkO907nrPdDEA5sOxCmHf2gDdOw214vxLRwJA1MsgYipHAH2SzhXNlJr7jRPMZsVunWdFXk0T51CdpZo2EyxNwyWkooD9q/t4/xnEIr1ZOKe1j4/56mrgaUcKWQz2h2fP8BuuYw/qB8CesfwkIytZa+Q84e6cD2nT0nUf3nXxt17DAPAJ0gVd3djx2MQxs/TnC7TEjBRUPXZj1UH8RkslxX18EWcq+OmMVrqRR7rU0icfWPBkefQ7IMhi/XlFbD/ejPCj6joyzLpX6jzAkmws4oedodzGeLlRlo6Oa+nvyer690/JndW0UmI2jCSp46P2ub9irtUfd1kiP4NaMwg==; 31:UjV0Hs9jBwXDEqrK+rlDTyR1IPGflcIi1XntWDvPz+Z+7jFcjduAnlDCr8uz7I713rUWgAql6rlbHCHLs4a0lYmzDC/Iqp9j357XArEyXTSovBstUS9eDY+YzyxejO8j0jKG6VwzF6OGqbY4BJ4k02wFTdLkPH66UoMtzHxEiIxZ4cNGURadHNjx4OiXMydDiTwl+edcW1ItHz6k5FjvsrxmyCl/BYvIi4rip9fI3Ns=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3007:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(10201501046)(12181511122)(3002001)(100000703101)(100105400095)(93006095)(93001095)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3007; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 4:He1J6r9nD1bRYbMSYqAWDFQCYMxZLFNVLzt2kx0lbDcVB7e4f2S55aKvsayVCuvMHxPtd/x4P1CyQ3+7KfdiKnuRkeby6ysXkSMM635tfJCewjHNPNoPkB2p1i5I2z5g4GTv6uKH4WrSbdMISv8gqbw+YVu1mpOXo8zTfofuX+uyHO0c+DmIv3Koja5ibHdZu5tivzT8h/b9AuMC2wYM4WOr3BB7ukL6LXPn05SfUD/BOXwHsnAW2Y42jnWxsHWT
X-Forefront-PRVS: 0452022BE1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(376002)(346002)(39860400002)(189002)(377454003)(13464003)(199003)(51444003)(14496001)(8676002)(6496005)(6246003)(61296003)(305945005)(76176999)(316002)(53936002)(81686999)(105586002)(106356001)(478600001)(8936002)(50986999)(81166006)(110136005)(25786009)(1556002)(6666003)(189998001)(101416001)(230783001)(4720700003)(68736007)(6486002)(50466002)(44736005)(1456003)(116806002)(81156014)(97736004)(6116002)(3846002)(229853002)(23756003)(33646002)(62236002)(44716002)(2906002)(5660300001)(7736002)(81816999)(16526018)(47776003)(9686003)(230700001)(86362001)(66066001)(84392002)(50226002)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; 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; VI1PR0701MB3007; 23:ySIaBDO4LX962cjKIimekZxe+ZepnkKrYT0XE?= =?iso-8859-1?Q?kRCQdOp+9qOwRIXbNY6wlIPk/O+EJ4j4PtV7F+VYrWKAhipdqAaRMNmBLQ?= =?iso-8859-1?Q?wO9RYpl4WoNuDJtet6nBD6JXgfcc2ZLa1HxBclwPSi8k0k+PQ7pWJlb1dI?= =?iso-8859-1?Q?7a9//dA7eDrdRi2fe6xnl8nmbTw/tKrXhQwaYJ99pAqYH1IM5uwHwM7Nly?= =?iso-8859-1?Q?18wAuOD1+ovzBf4brxhcLQ7FiDG5hWEHPgqKMdLMmH+49cxHSxIL/0pEmN?= =?iso-8859-1?Q?RTBieQaLa9oWq5QimB83AMicUVa/ogoqXtZVprM7uGy83XJ6RYqfFoP+7N?= =?iso-8859-1?Q?JWJEqy+O/CH+M3Y6+qnYVT6FVdqTMjTwobAlhw3leaR2iIxfv6/90cPXLF?= =?iso-8859-1?Q?6I3ZjtQAkGvT7O1Znn8oi3UVwn5NF2gO6E3rUBdBBI+L6xPhQhJrSBrsJD?= =?iso-8859-1?Q?zG2B1jE+NrCr7ZugVb6zEGM+XHsRjXjehgu51HBfSAoe9juiJghratGYSB?= =?iso-8859-1?Q?u6WDIjvBtFZjLzW1sWzWCoI1dQgZJhYou3U9GqmYlXXs1nlCxYLRUXZ3PT?= =?iso-8859-1?Q?Uija5BYFqTk07+fP5yJIWSwjK1tetNZponBswcdZcu48W+hAzqfXJjsDN5?= =?iso-8859-1?Q?3Z082FaAjGqK9yUv6T63qVz2tz7yqMRim9bX5A1kMcYseEYoNlbHAFB5RN?= =?iso-8859-1?Q?9GD3tv7Ayagwwyq3t3zPyOrge7OBF4ky1eWDoOtz77C+iIJnBE6rL50Kpf?= =?iso-8859-1?Q?5PmKHAWZ+yLHVOppR+yjjEWseKMmkhtuOgLZ1J6i8F4CgqiKku24/3sMQ2?= =?iso-8859-1?Q?NCmT0tZrzSrV5ZRS+kFZrdvZsirakhsY84mmNUNM0FQkjrgpFQVf/Pt5EU?= =?iso-8859-1?Q?3nV+YwfzUdvSnjiPY27N/QCYvuKJYSGeC1u3WuBbHVaZtA31yqqDUje2Pf?= =?iso-8859-1?Q?nOIiVGdFG7ywEBkDxzXfy51aM6atqkDv2lkL3v6wQ5QoJa0+1c0idfRXFf?= =?iso-8859-1?Q?eoRbgENLQkAbv3neb9B+Oc4xVbeNYXqPv64w5w+bmcBIgpb46e6MpQAjFg?= =?iso-8859-1?Q?5R/qSg3JhLsrseMYPJE/B24YpiOWe9BlijK7kZ783Qj2/nP8NIjZUyPdNg?= =?iso-8859-1?Q?jwM+Km3HXhKKlizIrahP0bIRuHjzh6FEUAyVBfVI0rVXve/7kAYPhtUC7c?= =?iso-8859-1?Q?jmfYCTE+Ihwp3XjfQQjbuH1RfziUnc09213gXPFfS8c9og4G6n8mk+uwTu?= =?iso-8859-1?Q?zJ//0iuOQ8B/f+NkmDQX43kHO8HZ9PFYQqY/ah30NcGdBEG2SDeHzI5nkL?= =?iso-8859-1?Q?8DYrQ1zy5f+pfdW9jSLiS+ORizXLFxomKojihGXDAbKHkP141pJBn5H23F?= =?iso-8859-1?Q?Cg1WJ9xnMfuVJUhwQdjrz7r6Sfl46mBYmj+E31kgvarmCqONDt1tH197ri?= =?iso-8859-1?Q?wA0QSWqDU4xSwiCqV9lD8dJHGF/F7lZMjL08bPFbm6JQzwjZU2LfvlMluN?= =?iso-8859-1?Q?wu5mf2LJ97eZiqKIDuGyWliQsRkY5xbxFJTsFgL7oQAi3onbzjsl0bLCn8?= =?iso-8859-1?Q?4mukxcnuyzB2gxjRKnXi7cA9/yfY=3D?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:ZplxuXmRCDkkFW+oa1BDeZyDqIPfpEiE1/LGc94HJV+vwIJmzhOuQNHb4QuRlY1HZNZpC/KJAz58pw9xr/m9pkeSbfBAUzNYnUe0eOEs6UZNSKTKzHSNNaZr+18QQCYrfaAX6KJMsi3nxCpSPNPOFsWWvqpZPxmUXd5RW+wrgHSnq3v4ueGrYKsH8OfXZEqRW1K9F1TxbUqIt3+1ut+qiGiT9j8agnQfM5pUdEwwHD/XDP4cGpHoSHxqqElNjHyP1AjP/P82kCBI03TbW8v69qkxH7cr9f433W2TOBAUISM2m1LgplB/RPtcFNkK/A+sTjQrKi+/g5zQ+Tx6swX1vg==; 5:s7Ktf8W1jiDxCHzOalvuqRK9uLdkkNSoGZ0QN0xDqo9dbAHK17sDIAiBke0YsDIB/YZixx/EtvL9RaS2ZWsCPGPA51Yf1mXIuyQTghOlJt4TlpzuJVVFGiekdcXVWSRFTvl5K5LeKGe3IGQO64bkqw==; 24:xRugEWrUqF424RcsZcSjqbzsrOc7tXH7vUZVLeGeZ7E48aGgsnQLhZmWeYv7s0Vkde7XtocDPpvx7j8bFJrIMmfLBb5de1s4u4l9EqMWClY=; 7:umgU8W4ppuVaOlwy+9kr6ictLxpQa33Qk/an58pilGVeBA1gQlZSCXAElqIR0r+MzKaWSxaNNeWRjN+W0ZGMmc9sGFqwFkr1VKLYgVOSw31rlflToDan+39ZukbwGLsxKw1qbeDRJwpT2NHe5NKypOAKCGpze8CB8Qx3L6AW9nI97VWYbUrrknfa9PH0q6GuHPF6dNkVC7nJ6Mbl08hf2hlE/V3UuuskP+KoFqArpNM=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2017 11:41:59.1942 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.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, 06 Oct 2017 11:42:04 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
Sent: Thursday, October 05, 2017 1:52 PM
> Martin Bjorklund  writes:
>
> > This version fixes the XPath context for parent-reference.
> >
> > However, there is one more thing to discuss, which is the term
"mount
> > point".
> >
> > The current text says:
> >
> >    - mount point: container or list node whose definition contains
> >      the "mount-point" extension statement. The argument of the
> >      "mount-point" statement defines the name of the mount point.
> >
> > So if we have:
> >
> >   container top {
> >     container root {
> >       yangmnt:mount-point ni;
> >     }
> >   }
> >
> > There is one mount point, the node /top/root, with the name "ni".
> >
> > Pretty confusing...   Does anyone have any comments around this?
>
> What about this?
>
> OLD
>
>     - mount point: container or list node whose definition contains
>       the "mount-point" extension statement. The argument of the
>       "mount-point" statement defines the name of the mount point.
>
> NEW
>
>     - mount point: container or list node whose definition contains
>       the "mount-point" extension statement. The argument of the
>       "mount-point" statement defines a label that is used for
>       referencing the mount point.

Lada

Trouble is 'label' is not a defined term in RFC7950 which leaves me (and
others) wondering what is this undefined concept.  I know plenty of
languages that have the concept of a label but YANG is not one of them.

I looked to see what the ABNF says for inspiration but there isn't
any:-)  I think that there should be.

I looked for a worked example for inspiration, nope, none of them
either!   What I mean is that in e.g. A.3  mount point with name root
appears, but that is the only instance of 'root'.  The whole point is
that root should appear more than once, once for where the mount will
be, and then once or more times for the part that will be mounted, so an
example where name appears once is not an example IMHO!

Tom Petch

> Lada
>
> >
> >
> >
> > /martin
> >


From nobody Fri Oct  6 06:25:50 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32A1342C5 for ; Fri,  6 Oct 2017 06:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju7VmjCuDaVQ for ; Fri,  6 Oct 2017 06:25:43 -0700 (PDT)
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 3965F1342EB for ; Fri,  6 Oct 2017 06:25:43 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 103EC1E0F27 for ; Fri,  6 Oct 2017 07:25:42 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id JDRe1w00x2SSUrH01DRhfU; Fri, 06 Oct 2017 07:25:42 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=XAHhotjdU0W7_qHwrFIA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To: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=/W1+ecB9pw+k+8I3armxkhNjF6XmZ2Wya25WNe3RD4Y=; b=hzOK3z1XxZJcrXeUTKAQPILAwF gwdV42URFVhUwmai8Q7c45TJgxli7LXB3ZBnlxkzYaLQqThNuVSaD6g7uVzyCFblQF9S0+3JedkXt 6e8NTbXikI7uwRPfoyEaUiBVi;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:42136 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e0SdG-002JTT-LW; Fri, 06 Oct 2017 07:25:38 -0600
To: NetMod WG 
Cc: rtg-dir@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
From: Lou Berger 
Message-ID: 
Date: Fri, 6 Oct 2017 09:25:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
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.84.20
X-Exim-ID: 1e0SdG-002JTT-LW
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:42136
X-Source-Auth: lberger@labn.net
X-Email-Count: 8
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] handling module incompatibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 13:25:45 -0000

Hi,

    As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name.  I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.

The background (as explained off-list by others, so I hope I have it
right)  is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed.  L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.

In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules.  This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted.  RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling.  For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.

So the discussion for the WG is:

How do we handle incompatible module changes, notably when one module
'obsoletes' another module --  from both the process and tooling
perspectives?

I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.

Cheers,

Lou

(as contributor/reviewer)



From nobody Fri Oct  6 07:50:09 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1D61349E1; Fri,  6 Oct 2017 07:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C7Xn4ToTlIf; Fri,  6 Oct 2017 07:50:01 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF701349E6; Fri,  6 Oct 2017 07:50:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2755; q=dns/txt; s=iport; t=1507301401; x=1508511001; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=CMvCbyQotz3AerGFn14WXI+lCXTMfwRZ62bsmwq0dng=; b=do19hOMIhx6c0fi/+xV5D3EWh7vB2DIi/Ds4u4BHOK65WHTgssrjLPPI Wt2yiGl9HI3i0FTrlwCWl3W4ZGHF2S6V6vbBvyCkX6h7+11ZWWerQUA20 /MFnAxTyz/hFyPIBfRSrugrDS77ogOUR+oQ3o4xXb3vxrFyvJ0HAJHmU5 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQCyl9dZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEFuJ4N6ixOQaZYvghIKGAuESU8ChGEWAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAQEBIQ8BBTYLEAsOCgICJgICJzAGAQwGAgEBiiQIEKQ4foIniykBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGgWBDoIfg1OCFYJ+iBeCYQWRQI9zlGWCFIlJhy2KFoN?= =?us-ascii?q?mh12BOSYCL0JMMiEIHRVJhx4/Nok9AQEB?=
X-IronPort-AV: E=Sophos;i="5.42,483,1500940800"; d="scan'208";a="697849007"
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 Oct 2017 14:49:51 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v96EnojD008148; Fri, 6 Oct 2017 14:49:51 GMT
To: Lou Berger , NetMod WG 
Cc: rtg-dir@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
References: 
From: Robert Wilton 
Message-ID: 
Date: Fri, 6 Oct 2017 15:49:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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] handling module incompatibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 14:50:08 -0000

Hi,

On 06/10/2017 14:25, Lou Berger wrote:
> Hi,
>
>      As part of the my Routing Directorate review of
> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
> changes being made to the ietf-l3vpn-svc module without changing the
> name.  I raised this with the YANG doctors and others involved with the
> draft and it surfaced some topics which really should be discussed here
> in NetMod.
>
> The background (as explained off-list by others, so I hope I have it
> right)  is that one of the YANG Doctors noted that RFC8049 was broken
> and could not be implemented as defined, and therefore a fix was
> needed.  L3SM has concluded so the fix is in the individual draft
> draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
> module could not be implemented, the feeling by the YANG Dr was that
> even though the new module is incompatible with the original definition
> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
> RFC 6020) didn't have to be followed and the same name could be used.

I think that this is the view that I support as well.  If something is 
clearly broken then it should be possible to fix it without requiring a 
new module name, just an updated revision.

Once the modules are properly stable, have multiple implementations, 
then I fully support the 7950 update guidelines, but I think that they 
are a bit strict as IETF is developing brand new modules, particularly 
those that don't necessarily have implementations behind them at the 
point that they reach RFC.

Thanks,
Rob


>
> In the subsequent discussion with the YANG Drs., the general discussion
> was heading down the path of using a new module name, and thereby not
> violating YANG module update rules.  This lead us back to the a similar
> discussion we've been having in the context of 8022bis: how best to
> indicate that a whole module is being obsoleted.  RFCs do this by adding
> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
> help YANG tooling.  For 8022, we have one approach - publishing an
> updated rev of the original module marking all nodes as deprecated - but
> that doesn't really make sense for rfc8049bis.
>
> So the discussion for the WG is:
>
> How do we handle incompatible module changes, notably when one module
> 'obsoletes' another module --  from both the process and tooling
> perspectives?
>
> I know Benoit plans to bring in some thoughts/proposals, perhaps there
> are others.
>
> Cheers,
>
> Lou
>
> (as contributor/reviewer)
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Oct  6 08:05:42 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E118613456A; Fri,  6 Oct 2017 08:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 QlXpaawMdkMO; Fri,  6 Oct 2017 08:05:26 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0104.outbound.protection.outlook.com [104.47.40.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0718B13457D; Fri,  6 Oct 2017 08:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4yFLcITujzUDdstCTcu/hn292Yqe+CM7DSIqqqpbteQ=; b=A+TRbkZgNSbvPauUsPvUQ+hZzD/Q65wqZ/SlHwf2yj2S+lw2TBbejyHVk2LX6HmqcwXmi7GYiEwdRH2TSvNaH+A/RLzSVbqZpgKzi3WQ7qViePD//Bu8Tg8Mp9mb8+zlPqgPx9LLfFXSuCBpF2P9kO7VMh+wKHIBmfgxGqfjIBo=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Fri, 6 Oct 2017 15:05:24 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.026; Fri, 6 Oct 2017 15:05:24 +0000
From: Kent Watsen 
To: Robert Wilton , Lou Berger , "NetMod WG" 
CC: "rtg-dir@ietf.org" , "draft-wu-l3sm-rfc8049bis.all@ietf.org" 
Thread-Topic: [netmod] handling module incompatibility
Thread-Index: AQHTPqai0t9hgxnOAU2uzTmhUr8jqqLW52sA///BT4A=
Date: Fri, 6 Oct 2017 15:05:24 +0000
Message-ID: <043E4E16-C916-483B-BC6F-C43215850D43@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
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:FlCbyKB3ee0xMk6uSb4NREsV4xJYI1dap2LemYUEY6j2WRlIx9bDdWhTsBdM7/3eN4UYQrfEjvOeLmBOcUQeUHhXFIQX9Lx9ijW0BDwsaZng4p0CeuFux92FIssVISTAgq0rNCg50JhJqW9JgNRcDrsDyQVAIif9/BUlsCVYdYQHh6Ss6yeOoPgTrdIuKoWyywz8i2g5WDVCCnvwuhr7lKpJDEqV7r6hY5DubcYq0upDHHkJJhUBukHxTaBMo/+GXkGG9JE2M7HuGayOwIO+RJZuLL+NX/h6I+rul1rKvs5Dt7XC8nHaBvafD4XCGfPRr4oznsoExjxxXx8wiwmKww==; 5:l8OI9hL9XnrZ+efCwhGSikqEZNSMvXzuhSnrf1oL4GBl1wALlT4B/LGUYu/22DCwNQQTfkmvLfJtMxlPjKp+qoLWACINXL5BKR/ru6jLHE2OmzxDJ509/f9y5X5ZDdCzN1lvKYCpbXgUom+Ds4ykVQ==; 24:/Jy+ysvZLbDBTgMsy1P5iwbMlVRrvBOUwj+oYuhB8Qt1G3OXOOIavbyNC8Yn7YxfO4cXPJHof8G4yMpGRUQVaomWL9fo1eY/xDUdGTavHIs=; 7:U8t5pkQKObRBxbY4Ot8vKJ3VQ0MZ0JtCxt5M8whaL3Ci8tHBH42C2/p6iY7daWa9qOimZ5R8z3K5IX6kRLyFUmPcOro6raoRSJq8W0N0l6LnO3kv/IrX2oxgWB3jcQVt+rx1H9WTDd4bVyst2ELo5jBbqbw4PY7+FP7X4+dOC1KEoLgPVlJCC6wKLxqCdBfevBPpnwQwnpi8536pJ5DVVwMNZfh7J5E3NmiX3i6ecT4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b30137db-5ce7-4907-c9db-08d50ccbabfb
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB275; 
x-ms-traffictypediagnostic: BLUPR05MB275:
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB275; 
x-forefront-prvs: 0452022BE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(189002)(51444003)(199003)(966005)(81156014)(189998001)(316002)(305945005)(66066001)(83506001)(86362001)(478600001)(14454004)(110136005)(2950100002)(36756003)(83716003)(97736004)(4326008)(6436002)(6512007)(33656002)(5660300001)(58126008)(54906003)(25786009)(102836003)(106356001)(68736007)(229853002)(3660700001)(105586002)(3280700002)(81166006)(76176999)(2900100001)(7736002)(6116002)(6486002)(3846002)(54356999)(77096006)(6506006)(6246003)(8676002)(82746002)(53936002)(6306002)(8936002)(2906002)(101416001)(50986999)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 15:05:24.5624 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275
Archived-At: 
Subject: Re: [netmod] handling module incompatibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 15:05:30 -0000

DQoNCj4+ICAgICAgQXMgcGFydCBvZiB0aGUgbXkgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXcg
b2YNCj4+IGRyYWZ0LXd1LWwzc20tcmZjODA0OWJpcyBJIG5vdGVkIHRoYXQgdGhlcmUgd2VyZSBz
ZXZlcmFsIGluY29tcGF0aWJsZQ0KPj4gY2hhbmdlcyBiZWluZyBtYWRlIHRvIHRoZSBpZXRmLWwz
dnBuLXN2YyBtb2R1bGUgd2l0aG91dCBjaGFuZ2luZyB0aGUNCj4+IG5hbWUuICBJIHJhaXNlZCB0
aGlzIHdpdGggdGhlIFlBTkcgZG9jdG9ycyBhbmQgb3RoZXJzIGludm9sdmVkIHdpdGggdGhlDQo+
PiBkcmFmdCBhbmQgaXQgc3VyZmFjZWQgc29tZSB0b3BpY3Mgd2hpY2ggcmVhbGx5IHNob3VsZCBi
ZSBkaXNjdXNzZWQgaGVyZQ0KPj4gaW4gTmV0TW9kLg0KPj4NCj4+IFRoZSBiYWNrZ3JvdW5kIChh
cyBleHBsYWluZWQgb2ZmLWxpc3QgYnkgb3RoZXJzLCBzbyBJIGhvcGUgSSBoYXZlIGl0DQo+PiBy
aWdodCkgIGlzIHRoYXQgb25lIG9mIHRoZSBZQU5HIERvY3RvcnMgbm90ZWQgdGhhdCBSRkM4MDQ5
IHdhcyBicm9rZW4NCj4+IGFuZCBjb3VsZCBub3QgYmUgaW1wbGVtZW50ZWQgYXMgZGVmaW5lZCwg
YW5kIHRoZXJlZm9yZSBhIGZpeCB3YXMNCj4+IG5lZWRlZC4gIEwzU00gaGFzIGNvbmNsdWRlZCBz
byB0aGUgZml4IGlzIGluIHRoZSBpbmRpdmlkdWFsIGRyYWZ0DQo+PiBkcmFmdC13dS1sM3NtLXJm
YzgwNDliaXMuICBTaW5jZSB0aGUgcmZjODA0OSB2ZXJzaW9uIG9mIGlldGYtbDN2cG4tc3ZjDQo+
PiBtb2R1bGUgY291bGQgbm90IGJlIGltcGxlbWVudGVkLCB0aGUgZmVlbGluZyBieSB0aGUgWUFO
RyBEciB3YXMgdGhhdA0KPj4gZXZlbiB0aG91Z2ggdGhlIG5ldyBtb2R1bGUgaXMgaW5jb21wYXRp
YmxlIHdpdGggdGhlIG9yaWdpbmFsIGRlZmluaXRpb24NCj4+IHRoZSBtb2R1bGUgdGhlIHJ1bGUg
ZGVmaW5lZCBpbiBTZWN0aW9uIDExIG9mIFlBTkcgMS4xIChvciBzZWN0aW9uIDEwIG9mDQo+PiBS
RkMgNjAyMCkgZGlkbid0IGhhdmUgdG8gYmUgZm9sbG93ZWQgYW5kIHRoZSBzYW1lIG5hbWUgY291
bGQgYmUgdXNlZC4NCj4NCj5JIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgdmlldyB0aGF0IEkgc3Vw
cG9ydCBhcyB3ZWxsLiAgSWYgc29tZXRoaW5nIGlzIA0KPmNsZWFybHkgYnJva2VuIHRoZW4gaXQg
c2hvdWxkIGJlIHBvc3NpYmxlIHRvIGZpeCBpdCB3aXRob3V0IHJlcXVpcmluZyBhIA0KPm5ldyBt
b2R1bGUgbmFtZSwganVzdCBhbiB1cGRhdGVkIHJldmlzaW9uLg0KPg0KPk9uY2UgdGhlIG1vZHVs
ZXMgYXJlIHByb3Blcmx5IHN0YWJsZSwgaGF2ZSBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMsIA0K
PnRoZW4gSSBmdWxseSBzdXBwb3J0IHRoZSA3OTUwIHVwZGF0ZSBndWlkZWxpbmVzLCBidXQgSSB0
aGluayB0aGF0IHRoZXkgDQo+YXJlIGEgYml0IHN0cmljdCBhcyBJRVRGIGlzIGRldmVsb3Bpbmcg
YnJhbmQgbmV3IG1vZHVsZXMsIHBhcnRpY3VsYXJseSANCj50aG9zZSB0aGF0IGRvbid0IG5lY2Vz
c2FyaWx5IGhhdmUgaW1wbGVtZW50YXRpb25zIGJlaGluZCB0aGVtIGF0IHRoZSANCj5wb2ludCB0
aGF0IHRoZXkgcmVhY2ggUkZDLg0KDQoNCkkgYWdyZWUgd2l0aCBhbGxvd2luZyBhIGRvLW92ZXIg
dXNpbmcgdGhlIHNhbWUgbW9kdWxlIG5hbWUuDQoNCldpdGggcmVnYXJkcyB0byBob3cgdG8gaW5k
aWNhdGUgdGhhdCBhbiBlbnRpcmUgbW9kdWxlIGlzIG9ic29sZXRlLCBJDQphZGRlZCB0aGlzIGVu
dHJ5IHRvIHRoZSB5YW5nLW5leHQgdHJhY2tlciBhIHdoaWxlIGFnbzogaHR0cHM6Ly9naXRodWIu
Y29tL25ldG1vZC13Zy95YW5nLW5leHQvaXNzdWVzLzI4Lg0KDQpLLiAgLy8gY29udHJpYnV0b3IN
Cg0KDQoNCg==


From nobody Fri Oct  6 08:32:55 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6BC1349E6; Fri,  6 Oct 2017 08:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eQTYvxwvO_c9; Fri,  6 Oct 2017 08:32:46 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B1EE113308A; Fri,  6 Oct 2017 08:32:45 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F5E61AE0310; Fri,  6 Oct 2017 17:32:44 +0200 (CEST)
Date: Fri, 06 Oct 2017 17:32:44 +0200 (CEST)
Message-Id: <20171006.173244.1167478609964390238.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: andy@yumaworks.com, rwilton@cisco.com, acee@cisco.com, netmod@ietf.org, rtg-dt-yang-arch@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <87h8w0bbyf.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=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 15:32:49 -0000

QmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPiBEZWFyIGFsbCwNCj4g
DQo+IFtpbmNsdWRpbmcgdGhlIHJvdXRpbmcgYW5kIG11bHRpY2FzdCBZQU5HIGRlc2lnbiB0ZWFt
c10NCj4gQ2FuIHdlIHBsZWFzZSBmaW5hbGl6ZSB0aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcgaWV0
Zi1yb3V0aW5nIHZlcnN1cw0KPiBpZXRmLXJvdXRpbmctMiwgc29vbmVyIHRoYW4gbGF0ZXIuDQo+
IA0KPiBJIGNhcmUgYWJvdXQgdGhlIE5NREEgdHJhbnNpdGlvbiBzdHJhdGVneS4NCj4gDQo+IEhl
cmUgYXJlIGFsbCB0aGUgaWV0Zi1yb3V0aW5nIGRlcGVuZGVudCBZQU5HIG1vZHVsZXMgKHRob3Nl
IG1vZHVsZXMNCj4gdGhhdCBkZXBlbmQgb24gaWV0Zi1yb3V0aW5nKQ0KPiBodHRwczovL3d3dy55
YW5nY2F0YWxvZy5vcmcveWFuZy1zZWFyY2gvaW1wYWN0X2FuYWx5c2lzLnBocD9tb2R1bGVzW109
aWV0Zi1yb3V0aW5nJnJlY3Vyc2U9MCZyZmNzPTEmc2hvd19zdWJtPTEmc2hvd19kaXI9ZGVwZW5k
ZW50cw0KPiBTbyBtYW55IFlBTkcgbW9kdWxlcy4NCj4gDQo+IExvb2sgYXQgdGhlIGRpZmZlcmVu
Y2UgZm9yIGlldGYtcm91dGluZy0yOg0KPiBodHRwczovL3d3dy55YW5nY2F0YWxvZy5vcmcveWFu
Zy1zZWFyY2gvaW1wYWN0X2FuYWx5c2lzLnBocD9tb2R1bGVzW109aWV0Zi1yb3V0aW5nLTImcmVj
dXJzZT0wJnJmY3M9MSZzaG93X3N1Ym09MSZzaG93X2Rpcj1kZXBlbmRlbnRzDQo+IFNvbWUgZGVw
ZW5kZW50IG1vZHVsZXMgYXJlIGNvbXBsaWFudCB3aXRoIGlldGYtcm91dGluZy0yLCB0aGUNCj4g
bXVsdGljYXN0IFlBTkcgbW9kdWxlcywgYnV0IHRoZXNlIGFyZSB0aGUgb25seSBvbmVzLg0KPiAN
Cj4gQ2hhbmdpbmcgdGhlIG1vZHVsZSBuYW1lIGZyb20gaWV0Zi1yb3V0aW5nIHRvIGlldGYtcm91
dGluZy0yIGltcGxpZXMNCj4gdGhhdCB0aGUgd2UgaGF2ZSB0byB3YXJuIGFsbCBkcmFmdCBhdXRo
b3JzIG9mIGlldGYtcm91dGluZyBZQU5HDQo+IGRlcGVuZGVudCBtb2R1bGVzOg0KPiDCoMKgwqAg
MS4gdG8gbWFrZSBzdXJlIHRoZXkgYXJlIGF3YXJlIG9mIGlldGYtcm91dGluZy0ywqAgKHB1Ymxp
c2hpbmcgYQ0KPiBSRkM4MDIyYmlzIG1lbnRpb25pbmcgaW4gdGhlIG1vZHVsZSBkZXNjcmlwdGlv
biB0aGF0IHRoaXMgbW9kdWxlIGlzDQo+IG5vdCBjb21wYXRpYmxlIHdpdGggdGhlIE5NREEgYXJj
aGl0ZWN0dXJlLCBhbmQgcHJvdmlkaW5nIGEgcG9pbnRlciB0bw0KPiBpZXRmLXJvdXRpbmctMiAu
Li4gaXMgbm90IGFuIGF1dG9tYXRpYyB3YXkuLi4gc28gYmFyZWx5IHVzZWZ1bCkNCj4gwqDCoMKg
IDIuIHRvIGFzayB0aGVtIHRvIGNoYW5nZSB0aGVpciBpbXBvcnQgdG8gaWV0Zi1yb3V0aW5nLTIN
Cj4gSG9wZWZ1bGx5LCBpbiB0aGUgcm91dGluZyBjYXNlLCBpdCdzIG1haW5seSB0aGUgSUVURi4N
Cj4gSSdtIGdsYWQgdGhhdCB3ZSBkaWRuJ3QgY2hhbmdlIHRoZSBpZXRmLWludGVyZmFjZXMgdG8N
Cj4gaWV0Zi1pbnRlcmZhY2VzLTIsIHdlIHdvdWxkIGhhdmUgdG8gZGVhbCB3aXRoIGNyb3NzDQo+
IFNETy9jb25zb3J0aWEvb3BlbnNvdXJjZSBwcm9qZWN0IGlzc3Vlcw0KPiBOb3RlOg0KPiANCj4g
ICAgd2UncmUgaW4gYSB0cmFuc2l0aW9uIHBoYXNlIHRvZGF5LCB3aGlsZSB3ZSBpbXBsZW1lbnQg
dGhlDQo+ICAgIHNvb24tdG8tYmUtcHVibGlzaGVkIGRyYWZ0LWNsYWNsYS1uZXRtb2QtbW9kZWwt
Y2F0YWxvZy0wMg0KPiAgICBCZWNhdXNlIG9mIHRoaXMsIHRoZSBTRE8vY29uc29ydGlhL29wZW5z
b3VyY2UgZGVwZW5kZW50IFlBTkcgbW9kdWxlcw0KPiAgICB3aWxsIG9ubHkgYXBwZWFyIGluIHRo
ZSBJbXBhY3QgQW5hbHlzaXMgdG9tb3Jyb3cgYXQNCj4gICAgaHR0cHM6Ly93d3cueWFuZ2NhdGFs
b2cub3JnL3lhbmctc2VhcmNoL2ltcGFjdF9hbmFseXNpcy5waHA/bW9kdWxlc1tdPWlldGYtaW50
ZXJmYWNlcyZyZWN1cnNlPTAmcmZjcz0xJnNob3dfc3VibT0xJnNob3dfZGlyPWRlcGVuZGVudHMN
Cj4gICAgSW4gdGhlIG1lYW4gdGltZSwgeW91IGNhbiBzZWUgYWxsIHRoZXNlIGRlcGVuZGVudCBt
b2R1bGVzDQo+ICAgIEV4Og0KPiAgICBodHRwczovL3d3dy55YW5nY2F0YWxvZy5vcmcveWFuZy1z
ZWFyY2gvbW9kdWxlX2RldGFpbHMucGhwP21vZHVsZT1pZXRmLWludGVyZmFjZXMNCj4gICAgIMKg
wqDCoCDCoMKgwqAgPT4gY2xpY2sgb24gImRlcGVuZGVudHMiDQo+ICAgIFRob3NlIGRlcGVuZGVu
dCBtb2R1bGVzIGlzIGEgbmV3IGZlYXR1cmUgb2YNCj4gICAgZHJhZnQtY2xhY2xhLW5ldG1vZC1t
b2RlbC1jYXRhbG9nLTAyDQo+IA0KPiANCj4gSSdtIHdvbmRlcmluZyBpZiB0aGlzIE5NREEgdHJh
bnNpdGlvbiBodXJkbGUgZG9lc24ndCBtYWtlIGEgZ29vZA0KPiBqdXN0aWZpY2F0aW9uIHRvIGtl
ZXAgdGhlIHNhbWUgbW9kdWxlIG5hbWUhDQo+IFdlIGNvdWxkIGRlYmF0ZSB3aGV0aGVyIGlldGYt
cm91dGluZyBpcyBpbXBsZW1lbnRlZCBvciBub3QsIGJ1dCB0aGUNCj4gcG9pbnQgaXMgbW9vdDog
d2UgZG9uJ3Qga25vdyB3aGF0IHdlIGRvbid0IGtub3cuDQoNCkFncmVlZC4gIEkgdGhpbmsgdGhl
cmUgYXJlIG5vIHJlYWwgcmVhc29ucyBmb3Iga2VlcGluZyB0aGUgbW9kdWxlIG5hbWUNCmFuZCBk
ZXByZWNhdGUgdGhlIG9sZCBkZWZpbnRpaW9ucy4gIFllcywgaXQgYWRkcyBzb21lIG5vaXNlIHRv
IHRoZQ0KbW9kdWxlIGJ1dCB0aGUgZmFjdCBpcyB0aGF0IHdlIGRvIGRlcHJlY2F0ZSBhbGwgdGhl
c2UgZGVmaW50aW9ucywgYW5kDQpJIHRoaW5rIHdlIHNob3VsZCBub3QgaGlkZSB0aGF0LiAgDQoN
Cg0KL21hcnRpbg0KDQoNCg0KPiANCj4gUmVnYXJkaW5nIG9uZSBwb2ludCBtYWRlIGJ5IEFuZHk6
DQo+IA0KPiAgICBJIHNob3VsZCBleHBsYWluIHRoZSB1c2UtY2FzZSBmb3IgaWRlbnRpZnlpbmcg
Tk1EQSB2cy4NCj4gICAgTk1EQS10cmFuc2l0aW9uIG1vZHVsZXMuDQo+ICAgIEkgZG8gbm90IHdh
bnQgdG8gcHJlc2VudCBib3RoIHR5cGVzIChmb3IgYSBnaXZlbiBtb2R1bGUpIHRvIHRoZSB1c2Vy
Lg0KPiAgICBTbyB0aGUgdG9vbHMgbmVlZCB0byBrbm93IGluICJOTURBIG1vZGUiIHdoaWNoIG1v
ZHVsZXMgYXJlIGR1cGxpY2F0ZXMNCj4gICAgZm9yIE5NREEtdHJhbnNpdGlvbiBwdXJwb3NlIG9u
bHksIHNvIHRob3NlIG1vZHVsZXMgY2FuIGJlIGhpZGRlbg0KPiAgICBmcm9tIHRoZSB1c2VyLg0K
PiAgICBJbiAibGVnYWN5IG1vZGUiIHRoZSBOTURBIG1vZHVsZXMgd291bGQgYmUgaGlkZGVuIGFu
ZCB0aGUgdHJhbnNpdGlvbg0KPiAgICBtb2R1bGVzDQo+ICAgIHdvdWxkIGJlIGV4cG9zZWQgdG8g
dGhlIHVzZXIgaW5zdGVhZC4NCj4gDQo+ICAgIEd1ZXNzaW5nIHdoaWNoIGlzIHdoaWNoIHdpbGwg
b25seSBjYXVzZSB1bmhhcHB5IGN1c3RvbWVycyBzbyB3ZSB3aWxsDQo+ICAgIGZvcmNlDQo+ICAg
IHZlbmRvcnMgdG8gdGFnIHRoZSBtb2R1bGVzIHdpdGggb3VyIG93biBZQU5HIGV4dGVuc2lvbnMg
dG8gdGVsbCB0aGVtDQo+ICAgIGFwYXJ0Lg0KPiANCj4gV2UgcmVjb2duaXplZCB0aGlzIHVzZSBj
YXNlIGFuZCB0YWdnZWQgdGhlIFlBTkcgbW9kdWxlICJ0cmVlLXR5cGUiIGluDQo+IHRoZSBZQU5H
IGNhdGFsb2cuDQo+IEluIHRoZSBzb29uLXRvLWJlLXB1Ymxpc2hlZCBidXQgYWxyZWFkeSBpbXBs
ZW1lbnRlZA0KPiBkcmFmdC1jbGFjbGEtbmV0bW9kLW1vZGVsLWNhdGFsb2ctMDIgZHJhZnQsIHlv
dSB3aWxsIHNlZToNCj4gDQo+ICAgIGxlYWYgdHJlZS10eXBlIHsNCj4gICAgICAgICAgIHR5cGUg
ZW51bWVyYXRpb24gew0KPiAgICAgICAgICAgICBlbnVtICJzcGxpdCIgew0KPiAgICAgICAgICAg
ICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgICAgICAiVGhpcyBtb2R1bGUgdXNlcyBhIHNw
bGl0IGNvbmZpZy9vcGVyYXRpb25hbCBzdGF0ZSBsYXlvdXQuIjsNCj4gICAgICAgICAgICAgfQ0K
PiAgICAgICAgICAgICBlbnVtICJubWRhLWNvbXBhdGlibGUiIHsNCj4gICAgICAgICAgICAgICBk
ZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgICAgIlRoaXMgbW9kdWxlIGlzIGNvbXBhdGlibGUg
d2l0aCB0aGUgTmV0d29yayBNYW5hZ2VtZW50DQo+ICAgICAgICAgICAgICAgICBEYXRhc3RvcmVz
DQo+ICAgICAgICAgICAgICAgICAgQXJjaGl0ZWN0dXJlIChOTURBKSBhbmQgY29tYmluZXMgY29u
ZmlnIGFuZCBvcGVyYXRpb25hbCBzdGF0ZQ0KPiAgICAgICAgICAgICAgICAgIG5vZGVzLiI7DQo+
ICAgICAgICAgICAgIH0NCj4gICAgICAgICAgICAgZW51bSAidHJhbnNpdGlvbmFsLWV4dHJhIiB7
DQo+ICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAgICAgICAgICJUaGlzIG1v
ZHVsZSBpcyBkZXJpdmVkIGFzIGEgJy1zdGF0ZScgbW9kdWxlIHRvIGFsbG93IGZvcg0KPiAgICAg
ICAgICAgICAgICAgdHJhbnNpdGlvbmluZw0KPiAgICAgICAgICAgICAgICAgIHRvIGEgZnVsbCBO
TURBLWNvbXBsaWFudCB0cmVlIHN0cnVjdHVyZS4iOw0KPiAgICAgICAgICAgICB9DQo+ICAgICAg
ICAgICAgIGVudW0gIm9wZW5jb25maWciIHsNCj4gICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0K
PiAgICAgICAgICAgICAgICAgIlRoaXMgbW9kdWxlIHVzZXMgdGhlIE9wZW5jb25maWcgZGF0YSBl
bGVtZW50IGxheW91dC4iOw0KPiAgICAgICAgICAgICB9DQo+ICAgICAgICAgICAgIGVudW0gInVu
Y2xhc3NpZmllZCIgew0KPiAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAg
ICAgICAiVGhpcyBtb2R1bGUgZG9lcyBub3QgYmVsb25nIHRvIGFueSBjYXRlZ29yeSBvciBjYW4n
dCBiZQ0KPiAgICAgICAgICAgICAgICAgZGV0ZXJtaW5lZC4iOw0KPiAgICAgICAgICAgICB9DQo+
ICAgICAgICAgICAgIGVudW0gIm5vdC1hcHBsaWNhYmxlIiB7DQo+ICAgICAgICAgICAgICAgZGVz
Y3JpcHRpb24NCj4gICAgICAgICAgICAgICAgICJUaGlzIG1vZHVsZSBpcyBub3QgYXBwbGljYWJs
ZS4gRm9yIGV4YW1wbGUsIGJlY2F1c2UgdGhlIFlBTkcNCj4gICAgICAgICAgICAgICAgIG1vZHVs
ZSBvbmx5IGNvbnRhaW5zIHR5cGVkZWZzLCBncm91cGluZ3MsIG9yIGlzIGEgc3VibW9kdWxlIjsN
Cj4gICAgICAgICAgICAgfQ0KPiAgICAgICAgICAgfQ0KPiAgICAgICAgICAgZGVzY3JpcHRpb24N
Cj4gICAgICAgICAgICAgIlRoZSB0eXBlIG9mIGRhdGEgZWxlbWVudCB0cmVlIHVzZWQgYnkgdGhl
IG1vZHVsZSBhcyBpdCByZWxhdGVzIHRvDQo+ICAgICAgICAgICAgIHRoZQ0KPiAgICAgICAgICAg
ICAgTmV0d29yayBNYW5hZ2VtZW50IERhdGFzdG9yZXMgQXJjaGl0ZWN0dXJlLiI7DQo+ICAgICAg
ICAgICByZWZlcmVuY2UgImRyYWZ0LWRzZHQtbm1kYS1ndWlkZWxpbmVzIEd1aWRlbGluZXMgZm9y
IFlBTkcgTW9kdWxlDQo+ICAgICAgICAgICBBdXRob3JzIChOTURBKSI7DQo+ICAgICAgICAgfQ0K
PiAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAiR3JvdXBpbmcgb2YgWUFORyBtb2R1
bGUgbWV0YWRhdGEgdGhhdCBleHRlbmRzIHRoZSBjb21tb24gbGlzdA0KPiAgICAgICAgICAgZGVm
aW5lZCBpbiB0aGUgWUFORw0KPiAgICAgICAgICAgIE1vZHVsZSBMaWJyYXJ5IChSRkMgNzg5NSku
IjsNCj4gICAgfQ0KPiANCj4gDQo+IElmIG5vdCBjb252aW5jZWQgYWxyZWFkeSwgSSBob3BlIHRo
YXQgeW91IHN0YXJ0IHRvIHNlZSB0aGUgWUFORw0KPiBjYXRhbG9nIHZhbHVlIGZvciB0aGUgaW5k
dXN0cnkuDQo+IExldCdzIGtlZXAgaW4gbWluZCB0aGF0IGF1dG9tYXRpb24gaXMga2V5LiBUaGVy
ZWZvcmUsIFlBTkcgbW9kdWxlcw0KPiB3aXRob3V0IG1vZHVsZSBkZXRhaWxzIChtZXRhZGF0YSkg
YW5kIHJlbGF0ZWQgdG9vbHMgaXMgbm90IHN1ZmZpY2llbnQNCj4gZm9yIHRoZSBpbmR1c3RyeS4N
Cj4gDQo+IFJlZ2FyZHMsIEJlbm9pdA0KPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3Mu
Y29tPiB3cml0ZXM6DQo+ID4NCj4gPj4gT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgOTowMiBBTSwg
Um9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+DQo+ID4+IHdyb3RlOg0KPiA+Pg0KPiA+
Pj4NCj4gPj4+IE9uIDE1LzA5LzIwMTcgMTY6MjMsIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPj4+
DQo+ID4+PiBIaSwNCj4gPj4+DQo+ID4+PiBTbyBhcmUgeW91IHNheWluZyB0aGUgTk1EQSB0cmFu
c2l0aW9uIHN0cmF0ZWd5IHNob3VsZCBiZSBpZ25vcmVkPw0KPiA+Pj4NCj4gPj4+IE15IHBlcnNv
bmFsIHByZWZlcmVuY2UgZm9yIHRoZSByb3V0aW5nIG1vZHVsZXMgd291bGQgYmUgdG8ga2VlcCB0
aGUNCj4gPj4+IHNhbWUNCj4gPj4+IG1vZHVsZSBuYW1lIGFuZCBkZXByZWNhdGUgdGhlIG9sZCBu
b2Rlcy4NCj4gPj4+DQo+ID4+PiBIb3dldmVyLCBJIGRvdWJ0IHRoYXQgdGhlcmUgYXJlIG1hbnkg
aW1wbGVtZW50YXRpb25zIG9mIHRoaXMgODAyMiB5ZXQsDQo+ID4+PiBhbmQNCj4gPj4+IGlmIHRo
ZSBhdXRob3JzIHByZWZlciB0byB1c2UgYSBuZXcgbmFtZXNwYWNlIHdpdGhvdXQgdGhlIG9sZCBu
b2Rlcw0KPiA+Pj4gdGhlbiBJJ20NCj4gPj4+IGZpbmUgd2l0aCB0aGF0IGFsc28uICBBcmUgeW91
IG9wcG9zZWQgdG8gdGhpcyBhcHByb2FjaD8NCj4gPj4+DQo+ID4+Pg0KPiA+PiBBIG5ldyBtb2R1
bGUgbmFtZSBtYW5kYXRlcyBhIG5ldyBuYW1lc3BhY2UsIHNvIHRoZXkgZ28gdG9nZXRoZXIuDQo+
ID4+IEFiYW5kb25pbmcgdGhlIG9sZCBtb2R1bGUgaXMgZmluZSwgZXhjZXB0IGxlYXZpbmcgdGhh
dCBtb2R1bGUgd2l0aA0KPiA+PiBzdGF0dXMNCj4gPj4gImN1cnJlbnQiIGlzIG5vdCBmaW5lLg0K
PiA+PiBJTU8geW91IG5lZWQgdG8gcmVwdWJsaXNoIHRoZSBvbGQgbW9kdWxlIGFzIHdlbGwsIHdp
dGggZXZlcnl0aGluZw0KPiA+PiBzdGF0dXMNCj4gPj4gb2Jzb2xldGUuDQo+ID4gSSBkb24ndCBh
Z3JlZSB3aXRoIHRoaXMuIFRoZSAic3RhdHVzIiB0YWcgaXMganVzdGlmaWVkIGZvciBzdWJzZXF1
ZW50DQo+ID4gcmV2aXNpb25zIG9mIHRoZSBzYW1lIG1vZHVsZSBzbyBhcyB0byBhaWQgb2xkIGNs
aWVudHMuDQo+ID4NCj4gPiBCdXQgaWYgdGhlIG1vZHVsZSBuYW1lIGFuZCBuYW1lc3BhY2UgVVJJ
IGFyZSBkaWZmZXJlbnQsIHRoZXJlIGlzIG5vDQo+ID4gc3VjaA0KPiA+IGNvbmNlcm4uIE1vZHVs
ZXMgY29udGFpbmVkIGluIFJGQ3MgNzIyMywgODAyMiBldGMuIGp1c3QgZGVmaW5lIHNvbWUNCj4g
PiBzY2hlbWFzIHRoYXQgaGFwcGVuIHRvIGJlIGdvb2QgZm9yIG15IHB1cnBvc2VzLiBTbyBJIHdh
bnQgdG8gYmUgYWJsZQ0KPiA+IHRvDQo+ID4gY29udGludWUgdXNpbmcgdGhlbSwgYW5kIGRvbid0
IHdhbnQgdG9vbHMgdG8gaXNzdWUgdXNlbGVzcyB3YXJuaW5ncyBvcg0KPiA+IGV2ZW4gcmVmdXNl
IHRvIHByb2Nlc3Mgc3VjaCBtb2R1bGVzLg0KPiA+DQo+ID4gSSBhbSBmaW5lIHRob3VnaCB3aXRo
IG1ha2luZyBhIG5ldyByZXZpc2lvbiBvZiBpZXRmLXJvdXRpbmcNCj4gPiBldGMuIG1lbnRpb25p
bmcgaW4gdGhlIG1vZHVsZSBkZXNjcmlwdGlvbiB0aGF0IHRoaXMgbW9kdWxlIGlzIG5vdA0KPiA+
IGNvbXBhdGlibGUgd2l0aCB0aGUgTk1EQSBhcmNoaXRlY3R1cmUsIGFuZCBwcm92aWRpbmcgYSBw
b2ludGVyIHRvDQo+ID4gaWV0Zi1yb3V0aW5nLTIuDQo+ID4NCj4gPiBMYWRhDQo+ID4NCj4gPj4N
Cj4gPj4NCj4gPj4+IEUuZy4gRm9yIGlldGYtaW50ZXJmYWNlcywgYW5kIGlldGYtaXAsIHdoaWNo
IGFyZSBvbGRlciwgYW5kIGhlbmNlDQo+ID4+PiBwcm9iYWJseQ0KPiA+Pj4gbXVjaCBtb3JlIHdp
ZGVseSBpbXBsZW1lbnRlZCB0aGVuIEkgdGhpbmsgdGhhdCB0aGUgbW9kdWxlcyBzaG91bGQgYmUN
Cj4gPj4+IHVwZGF0ZWQgaW4gcGxhY2Ugd2l0aCB0aGUgZXhpc3Rpbmcgc3RhdGUgdHJlZSBkZXBy
ZWNhdGVkLiAgSS5lLiBJDQo+ID4+PiBzdXBwb3J0DQo+ID4+PiB3aGF0IE1hcnRpbiBoYXMgZG9u
ZSBpbiBoaXMgSURzLCBhbmQgZG9uJ3Qgd2FudCB0aGlzIHRvIGNoYW5nZS4NCj4gPj4+DQo+ID4+
PiBXaGF0IGlzIHRoZSBwcm9ibGVtIHdpdGggZGVwcmVjYXRlZCBub2Rlcz8NCj4gPj4+DQo+ID4+
PiBOb3RoaW5nIHJlYWxseSwgYnV0IEkgZ3Vlc3MgdGhhdCB0aGV5IGFyZSBsaWtlbHkgdG8gYmUg
YmFnZ2FnZSB0aGF0IGlzDQo+ID4+PiBnb2luZyB0byBiZSBhcm91bmQgZm9yIGEgbG9uZyB0aW1l
IGV2ZW4gaWYgdmVyeSBmZXcgcGVvcGxlIGV2ZXINCj4gPj4+IGltcGxlbWVudA0KPiA+Pj4gdGhl
IGRlcHJlY2F0ZWQgbm9kZXMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFdoeSBhcmVuJ3QgeW91IGZv
bGxvd2luZyB5b3VyIG93biB0cmFuc2l0aW9uIHN0cmF0ZWd5Pw0KPiA+Pj4NCj4gPj4+IFJlYWxs
eSBiZWNhdXNlIEknbSBub3QgYW4gYXV0aG9yLCBib3RoIHNvbHV0aW9ucyBzZWVtIHZhbGlkLCBh
bmQgSQ0KPiA+Pj4gYWN0dWFsbHkgdGhpbmsganVzdCByZWFjaGluZyBhIGNvbmNsdXNpb24gcXVp
Y2tseSBpcyBtb3JlIGltcG9ydGFudA0KPiA+Pj4gdGhhbg0KPiA+Pj4gd2hpY2ggcGFydGljdWxh
ciBzb2x1dGlvbiBpcyBjaG9zZW4uICBJIGRvbid0IHNlZSBhbnkgYWR2YW50YWdlIGlzDQo+ID4+
PiBwdXNoaW5nDQo+ID4+PiBiYWNrIHRoZSBhZG9wdGlvbiBjYWxsIC0gaXQgc2VlbXMgbGlrZSBp
dCB3aWxsIHByb2JhYmx5IGp1c3QgZGVsYXkNCj4gPj4+IHdoZW4gd2UNCj4gPj4+IGNhbiBkbyBX
RyBMQy4NCj4gPj4+DQo+ID4+PiBJIGFjdHVhbGx5IHRoaW5rIHRoYXQgdGhlIGJpZ2dlciBxdWVz
dGlvbiB0aGF0IG5lZWRzIHRvIGJlIHJlc29sdmVkIGlzDQo+ID4+PiB3aGV0aGVyIHdlIG5lZWQg
YW4gb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIG1hcmsgYSBtb2R1bGUgYXMgTk1EQQ0KPiA+Pj4gY29t
cGF0aWJsZSwNCj4gPj4+IG9yIGZvciB0aGUgZXh0cmEgTk1EQSBzdGF0ZSBtb2R1bGUsIGFzIEkg
dGhpbmsgdGhhdCBib3RoIHlvdSBhbmQgVG9tDQo+ID4+PiBoYXZlDQo+ID4+PiBiZWVuIGFza2lu
ZyBmb3IuDQo+ID4+Pg0KPiA+PiBJIGFtIG5vIGZhbiBvZiBZQU5HIGNvbmZvcm1hbmNlLg0KPiA+
PiBUaGUgV0cgZG9lcyBub3Qgc2VlbSB0byB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdl
ZW4NCj4gPj4gICAgIChBKSB3aGF0IGEgc2VydmVyIGlzIHN1cHBvc2VkIHRvIGRvDQo+ID4+ICAg
ICAoQikgd2hhdCBhIHNlcnZlciBjbGFpbXMgdG8gZG8NCj4gPj4NCj4gPj4gVGhlcmUgaXMgbm8g
d2F5IHRvIGV4cHJlc3MgKEEpIGluIGEgWUFORyBtb2R1bGUsIGp1c3QgKEIpIGluIHRoZSBuZXcN
Cj4gPj4geWFuZy1saWJyYXJ5Lg0KPiA+Pg0KPiA+Pg0KPiA+PiBBbmR5DQo+ID4+DQo+ID4+DQo+
ID4+DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBSb2INCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+
DQo+ID4+PiBBbmR5DQo+ID4+Pg0KPiA+Pj4gT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgODowMSBB
TSwgUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+DQo+ID4+PiB3cm90ZToNCj4gPj4+
DQo+ID4+Pj4NCj4gPj4+PiBPbiAxNS8wOS8yMDE3IDE1OjUyLCBBY2VlIExpbmRlbSAoYWNlZSkg
d3JvdGU6DQo+ID4+Pj4NCj4gPj4+Pj4gSGksDQo+ID4+Pj4+DQo+ID4+Pj4+IFdpdGggcmVzcGVj
dCB0byBXRyBhZG9wdGlvbiwgd2Ugd2lsbCBkbyB3aGF0ZXZlciB0aGUgV0cgZGVjaWRlcyBmb3IN
Cj4gPj4+Pj4gdGhlDQo+ID4+Pj4+IFJGQyA4MDIyIG1vZGVsLiBXZSBoYXZlIGEgc3Ryb25nIHBy
ZWZlcmVuY2UgdG93YXJkIG5vdCBjYXJyeWluZyB0aGUNCj4gPj4+Pj4gZGVwcmVjYXRlZCBub2Rl
cyBmb3J3YXJkIGFuZCBuZXcgbW9kdWxlIHZlcnNpb25zIGFwcGVhcnMgdG8gYmUgYSBnb29kDQo+
ID4+Pj4+IHdheQ0KPiA+Pj4+PiB0byBhY2hpZXZlIHRoaXMuDQo+ID4+Pj4+DQo+ID4+Pj4gQ2Fu
IHdlIG5vdCBhZG9wdCByZWdhcmRsZXNzPyAgV2Uga25vdyB0aGF0IHdlIGFyZSBnb2luZyB0byBi
aXMgODAyMiwNCj4gPj4+PiBhbmQNCj4gPj4+PiBoYXZpbmcgYW4gYWRvcHRlZCBkcmFmdCBnaXZl
cyBpdCBhIGJpdCBtb3JlIGxlZ2l0aW1hY3kgYW5kIGhlbHBzIG90aGVyDQo+ID4+Pj4gZm9sa3Mg
dG8gbWlncmF0ZS4NCj4gPj4+Pg0KPiA+Pj4+IE9yIHBlcmhhcHMgd2UgY2FuIHN0YXJ0IHRoZSBj
YWxsIGZvciBhZG9wdGlvbiBhbmQgY29udGludWUgdG8gdHJ5IGFuZA0KPiA+Pj4+IHJlc29sdmUg
dGhpcyBpc3N1ZSBhdCB0aGUgc2FtZSB0aW1lIDstKS4gIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBi
ZQ0KPiA+Pj4+IGdvb2QgdG8NCj4gPj4+PiB0cnkgYW5kIGdldCB0aGUgdXBkYXRlZCBtb2RlbCBk
cmFmdHMgdG8gV0cgTEMgYnkgU2luZ2Fwb3JlLg0KPiA+Pj4+DQo+ID4+Pj4gSSBrbm93IHRoYXQg
aXQgaGFzbid0IGJlZW4gYXNrZWQgeWV0LCBidXQgSSBzdXBwb3J0IGFkb3B0aW9uIG9mIGFueQ0K
PiA+Pj4+IDgwMjINCj4gPj4+PiBiaXMgZHJhZnQgdGhhdCAoaSkgcHJvdmlkZXMgdGhlIGNvcnJl
Y3QgTkRNQSBjb21iaW5lZCB0cmVlIChpaSkNCj4gPj4+PiByZW1vdmVzIG9yDQo+ID4+Pj4gZGVw
cmVjYXRlcyB0aGUgb2xkIHN0YXRlIG5vZGVzIDotKQ0KPiA+Pj4+DQo+ID4+Pj4gU29ycnksIGlm
IEknbSBiZWluZyBwdXNoeSA6LSkNCj4gPj4+PiBSb2INCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4N
Cj4gPj4+Pj4gSSBhZ3JlZSB3aXRoIExhZGEgdGhhdCBkZXByZWNhdGluZyBhbGwgdGhlIHNjaGVt
YSBub2RlcyBpcw0KPiA+Pj4+PiB1bm5lY2Vzc2FyeS4NCj4gPj4+Pj4gSG93ZXZlciwgd2XigJls
bCBkbyB3aGF0IGl0IHRha2VzIHRvIHJlYWNoIGNvbnNlbnN1cyBhbmQgc2F0aXNmeSB0aGUNCj4g
Pj4+Pj4gbW9zdA0KPiA+Pj4+PiBwZWRhbnRpYyBhbW9uZyB1cy4NCj4gPj4+Pj4NCj4gPj4+Pj4g
VGhhbmtzLA0KPiA+Pj4+PiBBY2VlDQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIDkvMTUvMTcsIDY6Mzgg
QU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCj4gPj4+Pj4gPG5ldG1v
ZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCj4g
Pj4+Pj4NCj4gPj4+Pj4gS2VudCBXYXRzZW4gcMOtxaFlIHYgxIx0IDE0LiAwOS4gMjAxNyB2IDE0
OjUyICswMDAwOg0KPiA+Pj4+Pj4+IHJmYzgwMjJiaXMtMDIgc2lnbmFscyB0aGUgaW50ZW50IHRv
IGRpdGNoIHRoZQ0KPiA+Pj4+Pj4+IGN1cnJlbnQvc29vbi10by1iZS1sZWdhY3kNCj4gPj4+Pj4+
PiBtb2R1bGUsIGJ1dCBkb2VzIGl0IGFjdHVhbGx5IHNheSBpdD8gIChJIGNhbid0IGZpbmQgaXQp
DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+IFRoZSBtb2R1bGVzIGNvbnRhaW5lZCB0aGVyZWluIGhhdmUg
ZGlmZmVyZW50IG5hbWVzIGFuZCBuYW1lc3BhY2VzLCBzbw0KPiA+Pj4+Pj4gdGhlcmUgaXMNCj4g
Pj4+Pj4+IG5vIGZvcm1hbCBhbmNlc3RyeS4gSSB3b3VsZCBwcmVmZXIgdG8ga2VlcCB0aGUgbW9k
dWxlcyBmcm9tIFJGQyA4MDIyDQo+ID4+Pj4+PiBhcw0KPiA+Pj4+Pj4gdGhleSBhcmUNCj4gPj4+
Pj4+IC0gc29tZSB3ZWlyZG9zIG1heSBzdGlsbCB3YW50IHRvIHVzZSB0aGVtLg0KPiA+Pj4+Pj4N
Cj4gPj4+Pj4+IFRoZSBkcmFmdCBkb2VzIHNheSB0aGF0IGl0IG9ic29sZXRlcyA4MDIyLCBidXQg
SSdtIHVuc3VyZSBpZiB0aGF0J3MNCj4gPj4+Pj4+PiBnb2luZyB0bw0KPiA+Pj4+Pj4+IGhhdmUg
YSBtZWFuaW5nZnVsIGltcGFjdCBpbiB0aGUgd2lsZC4gIEkgdGhpbmsgSnVlcmdlbiBzYWlkIHRo
ZXkgaGFkDQo+ID4+Pj4+Pj4gdGhpcw0KPiA+Pj4+Pj4+IGlzc3VlIHdpdGggTUlCMiBhbmQgb25s
eSBhZnRlciBhIGNvdXBsZSB5ZWFycyBvZiBtaXN1c2UgZGlkIHRoZXkNCj4gPj4+Pj4+PiByZXB1
Ymxpc2ggdGhlDQo+ID4+Pj4+Pj4gbGVnYWN5IE1JQnMgd2l0aCBkZXByZWNhdGVkIHN0YXR1cy4N
Cj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEknbSBva2F5IHdpdGggdGhpcyBjaGFuZ2UgYmVpbmcgbWFk
ZSBhZnRlciBhZG9wdGlvbiwgc28gbG9uZyBhcw0KPiA+Pj4+Pj4+IHRoZXJlJ3MNCj4gPj4+Pj4+
PiBnZW5lcmFsIGFncmVlbWVudCB0byBkbyBpdC4gIEFyZSB0aGUgYXV0aG9ycyBva2F5IHdpdGgg
aXQsIG9yIGFyZQ0KPiA+Pj4+Pj4+IHRoZXJlDQo+ID4+Pj4+Pj4gYW55DQo+ID4+Pj4+Pj4gYmV0
dGVyIHN1Z2dlc3Rpb25zPw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gUFM6IFNhZGx5LCB0aGUgJ21v
ZHVsZScgc3RhdGVtZW50IGRvZXMgbm90IGhhdmUgJ3N0YXR1cycgYXMgYQ0KPiA+Pj4+Pj4+IHN1
YnN0YXRlbWVudCBbSQ0KPiA+Pj4+Pj4+IGp1c3QgYWRkZWQgdGhpcyBvbWlzc2lvbiB0byB0aGUg
eWFuZy1uZXh0IHRyYWNrZXJdLiAgSSB0aGluayB0aGUgb25seQ0KPiA+Pj4+Pj4+IHdheSB0bw0K
PiA+Pj4+Pj4+ICJkZXByZWNhdGUgYSBtb2R1bGUiIGlzIHRvIGluc3RlYWQgZGVwcmVjYXRlIHRo
ZSBhbGwgdGhlDQo+ID4+Pj4+Pj4gbm9kZXMvcnBjcy9ub3RpZmljYXRpb25zIGluIHRoZSBtb2R1
bGUuICBLaW5kIG9mIHVnbHksIGJ1dCBpdCdzIGZvciBhDQo+ID4+Pj4+Pj4gZGVwcmVjYXRlZCBt
b2R1bGUsIHNvIHdobyBjYXJlLCByaWdodD8gIDspDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+IEkgdGhp
bmsgaXQgaXMgdW5uZWNlc3NhcnkuIElmIHNvbWVib2R5IG5lZWRzIGFkZGluZyBzdWNoIGEgbW9k
dWxlIHRvDQo+ID4+Pj4+PiB0aGUNCj4gPj4+Pj4+IGRhdGENCj4gPj4+Pj4+IG1vZGVsLCBoZS9z
aGUgc2hvdWxkIHByb2JhYmx5IGhhdmUgYSByZWFzb24gdG8gZG8gc28sIHN1Y2ggYXMgZGF0YQ0K
PiA+Pj4+Pj4gaW1wbGVtZW50ZWQNCj4gPj4+Pj4+IG9uIHRoZSBzZXJ2ZXIuDQo+ID4+Pj4+Pg0K
PiA+Pj4+Pj4gTGFkYQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEtlbnQNCj4gPj4+Pj4+Pg0KPiA+Pj4+
Pj4+IC0tDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBIaSBSb2IsDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+
PiBPbiA5LzE0LzIwMTcgOTozNyBBTSwgUm9iZXJ0IFdpbHRvbiB3cm90ZToNCj4gPj4+Pj4+Pg0K
PiA+Pj4+Pj4+PiBIaSBLZW50ICYgTG91LA0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBXaGVuIGRv
IHlvdSB0aGluayB0aGF0IGl0IHdpbGwgYmUgcG9zc2libGUgdG8gc3RhcnQgdGhlIGFkb3B0aW9u
DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4gcHJvY2Vzcw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IG9u
IHRoZXNlIGRyYWZ0cz8NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSSB0aGluayB0aGF0IHRoZSBm
aXJzdCB0d28gYXQgbGVhc3Qgd291bGQgc2VlbSB0byBiZSByZWFkeSBmb3INCj4gPj4+Pj4+Pj4g
YWRvcHRpb24uICBGb3IgdGhlIDNyZCBkcmFmdCwgdGhlcmUgc3RpbGwgc2VlbXMgdG8gYmUgYW4g
b3Blbg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+IHF1ZXN0aW9uDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+
Pj4gb2Ygd2hhdCB0byBkbyB3aXRoIHRoZSBvbGQgc3RhdGUgdHJlZSwgYnV0IHByZXN1bWFibHkg
dGhhdCBjb3VsZCBiZQ0KPiA+Pj4+Pj4+PiBzb2x2ZWQgYWZ0ZXIgdGhlIGRyYWZ0IGhhcyBiZWVu
IGFkb3B0ZWQ/DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSSBzZWUgYW4gdXBkYXRlIGZvciB0aGUg
dGhpcmQgd2FzIHB1Ymxpc2hlZCB5ZXN0ZXJkYXkNCj4gPj4+Pj4+PiAoaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDIpICB0aGF0DQo+ID4+
Pj4+Pj4gY2xhcmlmaWVzIHRoZSBpbnRlbnQgaXMgdG8gcmVwbGFjZSB0aGUgY3VycmVudCBtb2R1
bGVzLCBhbmQgcHJlc3VtYWJseQ0KPiA+Pj4+Pj4+IG9ic29sZXRlIDgwMjIuICBBbmQgbm93IHRo
YXQgdGhpcyBpbnRlbmRlZCBkaXJlY3Rpb24gaXMgY2xlYXIgaW4gdGhlDQo+ID4+Pj4+Pj4gZHJh
ZnQgd2UgY291bGQgcG9sbCBpdC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBz
dGlsbCBkb2Vzbid0IGFkZHJlc3MgaWYgd2UgbmVlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0KPiA+
Pj4+Pj4+IHJmYzgwMjIgZGVmaW5lZCBtb2R1bGVzIGFyZSBkZXByZWNhdGVkIGJ5IHNvbWUgb3Ro
ZXIgbWVjaGFuaXNtcyB0aGFuDQo+ID4+Pj4+Pj4ganVzdCByZXBsYWNpbmcgdGhlIFJGQywgZS5n
LiwgYnkgdXBkYXRpbmcgdGhlIG9sZCBtb2R1bGVzIHdpdGggYWxsDQo+ID4+Pj4+Pj4gbm9kZXMN
Cj4gPj4+Pj4+PiBtYXJrZWQgYXMgZGVwcmVjYXRlZC4gIEkgdGhpbmsgeW91J3JlIHJpZ2h0IHRo
YXQgdGhpcyBjb3VsZCBiZSBkb25lDQo+ID4+Pj4+Pj4gcG9zdA0KPiA+Pj4+Pj4+IGFkb3B0aW9u
LiAgT2YgY291cnNlIG90aGVycyBhcmUgZnJlZSB0byBkaXNhZ3JlZS4NCj4gPj4+Pj4+Pg0KPiA+
Pj4+Pj4+IEkgY2hlY2sgd2l0aCBLZW50IGFuZCBzZWUgd2hhdCBoZSB0aGlua3MuDQo+ID4+Pj4+
Pj4NCj4gPj4+Pj4+PiBUaGFua3MsDQo+ID4+Pj4+Pj4gTG91DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+
PiBUaGFua3MsDQo+ID4+Pj4+Pj4+IFJvYg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+
Pj4+PiBPbiAzMC8wOC8yMDE3IDAwOjQ2LCBLZW50IFdhdHNlbiB3cm90ZToNCj4gPj4+Pj4+Pj4N
Cj4gPj4+Pj4+Pj4+IEhleSBmb2xrcywNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBBcyBkaXNj
dXNzZWQgYXQgdGhlIGxhc3QgbWVldGluZywgd2UgYXJlIGhlYWRpbmcgdG8gcmV2aXNpbmcNCj4g
Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IGV4aXN0aW5nIFJGQ3MNCj4gPj4+Pj4+Pj4gdG8gYWxpZ24g
dGhlbSB3aXRoIE5NREEuICBUaGUgZmlyc3QgYmF0Y2ggaGF2ZSBiZWVuIHB1Ymxpc2hlZCBhcw0K
PiA+Pj4+Pj4+Pj4gaW5kaXZpZHVhbCBkcmFmdHM6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g
MS4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJqb3JrbHVuZC1uZXRtb2QtcmZj
NzIyM2Jpcy0wMA0KPiA+Pj4+Pj4+Pj4gMi4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWJqb3JrbHVuZC1uZXRtb2QtcmZjNzI3N2Jpcy0wMA0KPiA+Pj4+Pj4+Pj4gMy4gaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDANCj4g
Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBQbGVhc2UgdGFrZSBhIGxvb2sgKGNvbW1lbnRzIHdlbGNv
bWUhKSBhbmQgc3RheSB0dW5lZCBmb3IgdGhlDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiByZWxh
dGVkDQo+ID4+Pj4+Pj4+IGFkb3B0aW9uIGNhbGxzLg0KPiA+Pj4+Pj4+Pj4gVGhhbmtzLA0KPiA+
Pj4+Pj4+Pj4gS2VudCAoYW5kIExvdSkNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+
Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
Pj4+Pj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+IG5ldG1vZEBpZXRmLm9y
Zw0KPiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QNCj4gPj4+Pj4+Pj4+IC4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4g
bmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPiA+Pj4+Pj4+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4+Pj4+Pj4N
Cj4gPj4+Pj4+IC0tDQo+ID4+Pj4+PiBMYWRpc2xhdiBMaG90a2ENCj4gPj4+Pj4+IEhlYWQsIENa
Lk5JQyBMYWJzDQo+ID4+Pj4+PiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPj4+
Pj4+DQo+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiA+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4gbmV0bW9kQGlldGYu
b3JnDQo+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KPiA+Pj4+Pj4NCj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4gPj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+Pj4+PiBuZXRtb2RA
aWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRtb2QNCj4gPj4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPj4+PiBuZXRtb2RA
aWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KPiA+Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gDQo=


From nobody Fri Oct  6 08:48:15 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E982132D17; Fri,  6 Oct 2017 08:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mGqsSHBv0Qj3; Fri,  6 Oct 2017 08:48:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7A13308A; Fri,  6 Oct 2017 08:48:11 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id B173C1AE0310; Fri,  6 Oct 2017 17:48:10 +0200 (CEST)
Date: Fri, 06 Oct 2017 17:48:10 +0200 (CEST)
Message-Id: <20171006.174810.2100217316354098631.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: rtg-dt-yang-arch@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20171006.173244.1167478609964390238.mbj@tail-f.com>
References: <87h8w0bbyf.fsf@nic.cz>  <20171006.173244.1167478609964390238.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=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 15:48:14 -0000

TWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KPiBCZW5vaXQgQ2xhaXNl
IDxiY2xhaXNlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gRGVhciBhbGwsDQo+ID4gDQo+ID4gW2lu
Y2x1ZGluZyB0aGUgcm91dGluZyBhbmQgbXVsdGljYXN0IFlBTkcgZGVzaWduIHRlYW1zXQ0KPiA+
IENhbiB3ZSBwbGVhc2UgZmluYWxpemUgdGhlIGRpc2N1c3Npb24gcmVnYXJkaW5nIGlldGYtcm91
dGluZyB2ZXJzdXMNCj4gPiBpZXRmLXJvdXRpbmctMiwgc29vbmVyIHRoYW4gbGF0ZXIuDQo+ID4g
DQo+ID4gSSBjYXJlIGFib3V0IHRoZSBOTURBIHRyYW5zaXRpb24gc3RyYXRlZ3kuDQo+ID4gDQo+
ID4gSGVyZSBhcmUgYWxsIHRoZSBpZXRmLXJvdXRpbmcgZGVwZW5kZW50IFlBTkcgbW9kdWxlcyAo
dGhvc2UgbW9kdWxlcw0KPiA+IHRoYXQgZGVwZW5kIG9uIGlldGYtcm91dGluZykNCj4gPiBodHRw
czovL3d3dy55YW5nY2F0YWxvZy5vcmcveWFuZy1zZWFyY2gvaW1wYWN0X2FuYWx5c2lzLnBocD9t
b2R1bGVzW109aWV0Zi1yb3V0aW5nJnJlY3Vyc2U9MCZyZmNzPTEmc2hvd19zdWJtPTEmc2hvd19k
aXI9ZGVwZW5kZW50cw0KPiA+IFNvIG1hbnkgWUFORyBtb2R1bGVzLg0KPiA+IA0KPiA+IExvb2sg
YXQgdGhlIGRpZmZlcmVuY2UgZm9yIGlldGYtcm91dGluZy0yOg0KPiA+IGh0dHBzOi8vd3d3Lnlh
bmdjYXRhbG9nLm9yZy95YW5nLXNlYXJjaC9pbXBhY3RfYW5hbHlzaXMucGhwP21vZHVsZXNbXT1p
ZXRmLXJvdXRpbmctMiZyZWN1cnNlPTAmcmZjcz0xJnNob3dfc3VibT0xJnNob3dfZGlyPWRlcGVu
ZGVudHMNCj4gPiBTb21lIGRlcGVuZGVudCBtb2R1bGVzIGFyZSBjb21wbGlhbnQgd2l0aCBpZXRm
LXJvdXRpbmctMiwgdGhlDQo+ID4gbXVsdGljYXN0IFlBTkcgbW9kdWxlcywgYnV0IHRoZXNlIGFy
ZSB0aGUgb25seSBvbmVzLg0KPiA+IA0KPiA+IENoYW5naW5nIHRoZSBtb2R1bGUgbmFtZSBmcm9t
IGlldGYtcm91dGluZyB0byBpZXRmLXJvdXRpbmctMiBpbXBsaWVzDQo+ID4gdGhhdCB0aGUgd2Ug
aGF2ZSB0byB3YXJuIGFsbCBkcmFmdCBhdXRob3JzIG9mIGlldGYtcm91dGluZyBZQU5HDQo+ID4g
ZGVwZW5kZW50IG1vZHVsZXM6DQo+ID4gwqDCoMKgIDEuIHRvIG1ha2Ugc3VyZSB0aGV5IGFyZSBh
d2FyZSBvZiBpZXRmLXJvdXRpbmctMsKgIChwdWJsaXNoaW5nIGENCj4gPiBSRkM4MDIyYmlzIG1l
bnRpb25pbmcgaW4gdGhlIG1vZHVsZSBkZXNjcmlwdGlvbiB0aGF0IHRoaXMgbW9kdWxlIGlzDQo+
ID4gbm90IGNvbXBhdGlibGUgd2l0aCB0aGUgTk1EQSBhcmNoaXRlY3R1cmUsIGFuZCBwcm92aWRp
bmcgYSBwb2ludGVyIHRvDQo+ID4gaWV0Zi1yb3V0aW5nLTIgLi4uIGlzIG5vdCBhbiBhdXRvbWF0
aWMgd2F5Li4uIHNvIGJhcmVseSB1c2VmdWwpDQo+ID4gwqDCoMKgIDIuIHRvIGFzayB0aGVtIHRv
IGNoYW5nZSB0aGVpciBpbXBvcnQgdG8gaWV0Zi1yb3V0aW5nLTINCj4gPiBIb3BlZnVsbHksIGlu
IHRoZSByb3V0aW5nIGNhc2UsIGl0J3MgbWFpbmx5IHRoZSBJRVRGLg0KPiA+IEknbSBnbGFkIHRo
YXQgd2UgZGlkbid0IGNoYW5nZSB0aGUgaWV0Zi1pbnRlcmZhY2VzIHRvDQo+ID4gaWV0Zi1pbnRl
cmZhY2VzLTIsIHdlIHdvdWxkIGhhdmUgdG8gZGVhbCB3aXRoIGNyb3NzDQo+ID4gU0RPL2NvbnNv
cnRpYS9vcGVuc291cmNlIHByb2plY3QgaXNzdWVzDQo+ID4gTm90ZToNCj4gPiANCj4gPiAgICB3
ZSdyZSBpbiBhIHRyYW5zaXRpb24gcGhhc2UgdG9kYXksIHdoaWxlIHdlIGltcGxlbWVudCB0aGUN
Cj4gPiAgICBzb29uLXRvLWJlLXB1Ymxpc2hlZCBkcmFmdC1jbGFjbGEtbmV0bW9kLW1vZGVsLWNh
dGFsb2ctMDINCj4gPiAgICBCZWNhdXNlIG9mIHRoaXMsIHRoZSBTRE8vY29uc29ydGlhL29wZW5z
b3VyY2UgZGVwZW5kZW50IFlBTkcgbW9kdWxlcw0KPiA+ICAgIHdpbGwgb25seSBhcHBlYXIgaW4g
dGhlIEltcGFjdCBBbmFseXNpcyB0b21vcnJvdyBhdA0KPiA+ICAgIGh0dHBzOi8vd3d3Lnlhbmdj
YXRhbG9nLm9yZy95YW5nLXNlYXJjaC9pbXBhY3RfYW5hbHlzaXMucGhwP21vZHVsZXNbXT1pZXRm
LWludGVyZmFjZXMmcmVjdXJzZT0wJnJmY3M9MSZzaG93X3N1Ym09MSZzaG93X2Rpcj1kZXBlbmRl
bnRzDQo+ID4gICAgSW4gdGhlIG1lYW4gdGltZSwgeW91IGNhbiBzZWUgYWxsIHRoZXNlIGRlcGVu
ZGVudCBtb2R1bGVzDQo+ID4gICAgRXg6DQo+ID4gICAgaHR0cHM6Ly93d3cueWFuZ2NhdGFsb2cu
b3JnL3lhbmctc2VhcmNoL21vZHVsZV9kZXRhaWxzLnBocD9tb2R1bGU9aWV0Zi1pbnRlcmZhY2Vz
DQo+ID4gICAgIMKgwqDCoCDCoMKgwqAgPT4gY2xpY2sgb24gImRlcGVuZGVudHMiDQo+ID4gICAg
VGhvc2UgZGVwZW5kZW50IG1vZHVsZXMgaXMgYSBuZXcgZmVhdHVyZSBvZg0KPiA+ICAgIGRyYWZ0
LWNsYWNsYS1uZXRtb2QtbW9kZWwtY2F0YWxvZy0wMg0KPiA+IA0KPiA+IA0KPiA+IEknbSB3b25k
ZXJpbmcgaWYgdGhpcyBOTURBIHRyYW5zaXRpb24gaHVyZGxlIGRvZXNuJ3QgbWFrZSBhIGdvb2QN
Cj4gPiBqdXN0aWZpY2F0aW9uIHRvIGtlZXAgdGhlIHNhbWUgbW9kdWxlIG5hbWUhDQo+ID4gV2Ug
Y291bGQgZGViYXRlIHdoZXRoZXIgaWV0Zi1yb3V0aW5nIGlzIGltcGxlbWVudGVkIG9yIG5vdCwg
YnV0IHRoZQ0KPiA+IHBvaW50IGlzIG1vb3Q6IHdlIGRvbid0IGtub3cgd2hhdCB3ZSBkb24ndCBr
bm93Lg0KPiANCj4gQWdyZWVkLiAgSSB0aGluayB0aGVyZSBhcmUgbm8gcmVhbCByZWFzb25zIGZv
ciBrZWVwaW5nIHRoZSBtb2R1bGUgbmFtZQ0KPiBhbmQgZGVwcmVjYXRlIHRoZSBvbGQgZGVmaW50
aWlvbnMuDQoNCldob29wcywgZm9yZ290IGEgIm5vdCIsIHRoaXMgc2hvdWxkIGhhdmUgYmVlbjoN
Cg0KICBJIHRoaW5rIHRoZXJlIGFyZSBubyByZWFsIHJlYXNvbnMgZm9yIG5vdCBrZWVwaW5nIHRo
ZSBtb2R1bGUgbmFtZQ0KICBhbmQgZGVwcmVjYXRlIHRoZSBvbGQgZGVmaW50aWlvbnMuDQoNCj4g
WWVzLCBpdCBhZGRzIHNvbWUgbm9pc2UgdG8gdGhlDQo+IG1vZHVsZSBidXQgdGhlIGZhY3QgaXMg
dGhhdCB3ZSBkbyBkZXByZWNhdGUgYWxsIHRoZXNlIGRlZmludGlvbnMsIGFuZA0KPiBJIHRoaW5r
IHdlIHNob3VsZCBub3QgaGlkZSB0aGF0LiAgDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+IA0KPiAv
bWFydGluDQo+IA0KPiANCj4gDQo+ID4gDQo+ID4gUmVnYXJkaW5nIG9uZSBwb2ludCBtYWRlIGJ5
IEFuZHk6DQo+ID4gDQo+ID4gICAgSSBzaG91bGQgZXhwbGFpbiB0aGUgdXNlLWNhc2UgZm9yIGlk
ZW50aWZ5aW5nIE5NREEgdnMuDQo+ID4gICAgTk1EQS10cmFuc2l0aW9uIG1vZHVsZXMuDQo+ID4g
ICAgSSBkbyBub3Qgd2FudCB0byBwcmVzZW50IGJvdGggdHlwZXMgKGZvciBhIGdpdmVuIG1vZHVs
ZSkgdG8gdGhlIHVzZXIuDQo+ID4gICAgU28gdGhlIHRvb2xzIG5lZWQgdG8ga25vdyBpbiAiTk1E
QSBtb2RlIiB3aGljaCBtb2R1bGVzIGFyZSBkdXBsaWNhdGVzDQo+ID4gICAgZm9yIE5NREEtdHJh
bnNpdGlvbiBwdXJwb3NlIG9ubHksIHNvIHRob3NlIG1vZHVsZXMgY2FuIGJlIGhpZGRlbg0KPiA+
ICAgIGZyb20gdGhlIHVzZXIuDQo+ID4gICAgSW4gImxlZ2FjeSBtb2RlIiB0aGUgTk1EQSBtb2R1
bGVzIHdvdWxkIGJlIGhpZGRlbiBhbmQgdGhlIHRyYW5zaXRpb24NCj4gPiAgICBtb2R1bGVzDQo+
ID4gICAgd291bGQgYmUgZXhwb3NlZCB0byB0aGUgdXNlciBpbnN0ZWFkLg0KPiA+IA0KPiA+ICAg
IEd1ZXNzaW5nIHdoaWNoIGlzIHdoaWNoIHdpbGwgb25seSBjYXVzZSB1bmhhcHB5IGN1c3RvbWVy
cyBzbyB3ZSB3aWxsDQo+ID4gICAgZm9yY2UNCj4gPiAgICB2ZW5kb3JzIHRvIHRhZyB0aGUgbW9k
dWxlcyB3aXRoIG91ciBvd24gWUFORyBleHRlbnNpb25zIHRvIHRlbGwgdGhlbQ0KPiA+ICAgIGFw
YXJ0Lg0KPiA+IA0KPiA+IFdlIHJlY29nbml6ZWQgdGhpcyB1c2UgY2FzZSBhbmQgdGFnZ2VkIHRo
ZSBZQU5HIG1vZHVsZSAidHJlZS10eXBlIiBpbg0KPiA+IHRoZSBZQU5HIGNhdGFsb2cuDQo+ID4g
SW4gdGhlIHNvb24tdG8tYmUtcHVibGlzaGVkIGJ1dCBhbHJlYWR5IGltcGxlbWVudGVkDQo+ID4g
ZHJhZnQtY2xhY2xhLW5ldG1vZC1tb2RlbC1jYXRhbG9nLTAyIGRyYWZ0LCB5b3Ugd2lsbCBzZWU6
DQo+ID4gDQo+ID4gICAgbGVhZiB0cmVlLXR5cGUgew0KPiA+ICAgICAgICAgICB0eXBlIGVudW1l
cmF0aW9uIHsNCj4gPiAgICAgICAgICAgICBlbnVtICJzcGxpdCIgew0KPiA+ICAgICAgICAgICAg
ICAgZGVzY3JpcHRpb24NCj4gPiAgICAgICAgICAgICAgICAgIlRoaXMgbW9kdWxlIHVzZXMgYSBz
cGxpdCBjb25maWcvb3BlcmF0aW9uYWwgc3RhdGUgbGF5b3V0LiI7DQo+ID4gICAgICAgICAgICAg
fQ0KPiA+ICAgICAgICAgICAgIGVudW0gIm5tZGEtY29tcGF0aWJsZSIgew0KPiA+ICAgICAgICAg
ICAgICAgZGVzY3JpcHRpb24NCj4gPiAgICAgICAgICAgICAgICAgIlRoaXMgbW9kdWxlIGlzIGNv
bXBhdGlibGUgd2l0aCB0aGUgTmV0d29yayBNYW5hZ2VtZW50DQo+ID4gICAgICAgICAgICAgICAg
IERhdGFzdG9yZXMNCj4gPiAgICAgICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSAoTk1EQSkgYW5k
IGNvbWJpbmVzIGNvbmZpZyBhbmQgb3BlcmF0aW9uYWwgc3RhdGUNCj4gPiAgICAgICAgICAgICAg
ICAgIG5vZGVzLiI7DQo+ID4gICAgICAgICAgICAgfQ0KPiA+ICAgICAgICAgICAgIGVudW0gInRy
YW5zaXRpb25hbC1leHRyYSIgew0KPiA+ICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gPiAg
ICAgICAgICAgICAgICAgIlRoaXMgbW9kdWxlIGlzIGRlcml2ZWQgYXMgYSAnLXN0YXRlJyBtb2R1
bGUgdG8gYWxsb3cgZm9yDQo+ID4gICAgICAgICAgICAgICAgIHRyYW5zaXRpb25pbmcNCj4gPiAg
ICAgICAgICAgICAgICAgIHRvIGEgZnVsbCBOTURBLWNvbXBsaWFudCB0cmVlIHN0cnVjdHVyZS4i
Ow0KPiA+ICAgICAgICAgICAgIH0NCj4gPiAgICAgICAgICAgICBlbnVtICJvcGVuY29uZmlnIiB7
DQo+ID4gICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiA+ICAgICAgICAgICAgICAgICAiVGhp
cyBtb2R1bGUgdXNlcyB0aGUgT3BlbmNvbmZpZyBkYXRhIGVsZW1lbnQgbGF5b3V0LiI7DQo+ID4g
ICAgICAgICAgICAgfQ0KPiA+ICAgICAgICAgICAgIGVudW0gInVuY2xhc3NpZmllZCIgew0KPiA+
ICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gPiAgICAgICAgICAgICAgICAgIlRoaXMgbW9k
dWxlIGRvZXMgbm90IGJlbG9uZyB0byBhbnkgY2F0ZWdvcnkgb3IgY2FuJ3QgYmUNCj4gPiAgICAg
ICAgICAgICAgICAgZGV0ZXJtaW5lZC4iOw0KPiA+ICAgICAgICAgICAgIH0NCj4gPiAgICAgICAg
ICAgICBlbnVtICJub3QtYXBwbGljYWJsZSIgew0KPiA+ICAgICAgICAgICAgICAgZGVzY3JpcHRp
b24NCj4gPiAgICAgICAgICAgICAgICAgIlRoaXMgbW9kdWxlIGlzIG5vdCBhcHBsaWNhYmxlLiBG
b3IgZXhhbXBsZSwgYmVjYXVzZSB0aGUgWUFORw0KPiA+ICAgICAgICAgICAgICAgICBtb2R1bGUg
b25seSBjb250YWlucyB0eXBlZGVmcywgZ3JvdXBpbmdzLCBvciBpcyBhIHN1Ym1vZHVsZSI7DQo+
ID4gICAgICAgICAgICAgfQ0KPiA+ICAgICAgICAgICB9DQo+ID4gICAgICAgICAgIGRlc2NyaXB0
aW9uDQo+ID4gICAgICAgICAgICAgIlRoZSB0eXBlIG9mIGRhdGEgZWxlbWVudCB0cmVlIHVzZWQg
YnkgdGhlIG1vZHVsZSBhcyBpdCByZWxhdGVzIHRvDQo+ID4gICAgICAgICAgICAgdGhlDQo+ID4g
ICAgICAgICAgICAgIE5ldHdvcmsgTWFuYWdlbWVudCBEYXRhc3RvcmVzIEFyY2hpdGVjdHVyZS4i
Ow0KPiA+ICAgICAgICAgICByZWZlcmVuY2UgImRyYWZ0LWRzZHQtbm1kYS1ndWlkZWxpbmVzIEd1
aWRlbGluZXMgZm9yIFlBTkcgTW9kdWxlDQo+ID4gICAgICAgICAgIEF1dGhvcnMgKE5NREEpIjsN
Cj4gPiAgICAgICAgIH0NCj4gPiAgICAgICAgIGRlc2NyaXB0aW9uDQo+ID4gICAgICAgICAgICJH
cm91cGluZyBvZiBZQU5HIG1vZHVsZSBtZXRhZGF0YSB0aGF0IGV4dGVuZHMgdGhlIGNvbW1vbiBs
aXN0DQo+ID4gICAgICAgICAgIGRlZmluZWQgaW4gdGhlIFlBTkcNCj4gPiAgICAgICAgICAgIE1v
ZHVsZSBMaWJyYXJ5IChSRkMgNzg5NSkuIjsNCj4gPiAgICB9DQo+ID4gDQo+ID4gDQo+ID4gSWYg
bm90IGNvbnZpbmNlZCBhbHJlYWR5LCBJIGhvcGUgdGhhdCB5b3Ugc3RhcnQgdG8gc2VlIHRoZSBZ
QU5HDQo+ID4gY2F0YWxvZyB2YWx1ZSBmb3IgdGhlIGluZHVzdHJ5Lg0KPiA+IExldCdzIGtlZXAg
aW4gbWluZCB0aGF0IGF1dG9tYXRpb24gaXMga2V5LiBUaGVyZWZvcmUsIFlBTkcgbW9kdWxlcw0K
PiA+IHdpdGhvdXQgbW9kdWxlIGRldGFpbHMgKG1ldGFkYXRhKSBhbmQgcmVsYXRlZCB0b29scyBp
cyBub3Qgc3VmZmljaWVudA0KPiA+IGZvciB0aGUgaW5kdXN0cnkuDQo+ID4gDQo+ID4gUmVnYXJk
cywgQmVub2l0DQo+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JpdGVz
Og0KPiA+ID4NCj4gPiA+PiBPbiBGcmksIFNlcCAxNSwgMjAxNyBhdCA5OjAyIEFNLCBSb2JlcnQg
V2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT4NCj4gPiA+PiB3cm90ZToNCj4gPiA+Pg0KPiA+ID4+
Pg0KPiA+ID4+PiBPbiAxNS8wOS8yMDE3IDE2OjIzLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4g
Pj4+DQo+ID4gPj4+IEhpLA0KPiA+ID4+Pg0KPiA+ID4+PiBTbyBhcmUgeW91IHNheWluZyB0aGUg
Tk1EQSB0cmFuc2l0aW9uIHN0cmF0ZWd5IHNob3VsZCBiZSBpZ25vcmVkPw0KPiA+ID4+Pg0KPiA+
ID4+PiBNeSBwZXJzb25hbCBwcmVmZXJlbmNlIGZvciB0aGUgcm91dGluZyBtb2R1bGVzIHdvdWxk
IGJlIHRvIGtlZXAgdGhlDQo+ID4gPj4+IHNhbWUNCj4gPiA+Pj4gbW9kdWxlIG5hbWUgYW5kIGRl
cHJlY2F0ZSB0aGUgb2xkIG5vZGVzLg0KPiA+ID4+Pg0KPiA+ID4+PiBIb3dldmVyLCBJIGRvdWJ0
IHRoYXQgdGhlcmUgYXJlIG1hbnkgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgODAyMiB5ZXQsDQo+
ID4gPj4+IGFuZA0KPiA+ID4+PiBpZiB0aGUgYXV0aG9ycyBwcmVmZXIgdG8gdXNlIGEgbmV3IG5h
bWVzcGFjZSB3aXRob3V0IHRoZSBvbGQgbm9kZXMNCj4gPiA+Pj4gdGhlbiBJJ20NCj4gPiA+Pj4g
ZmluZSB3aXRoIHRoYXQgYWxzby4gIEFyZSB5b3Ugb3Bwb3NlZCB0byB0aGlzIGFwcHJvYWNoPw0K
PiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+IEEgbmV3IG1vZHVsZSBuYW1lIG1hbmRhdGVzIGEgbmV3
IG5hbWVzcGFjZSwgc28gdGhleSBnbyB0b2dldGhlci4NCj4gPiA+PiBBYmFuZG9uaW5nIHRoZSBv
bGQgbW9kdWxlIGlzIGZpbmUsIGV4Y2VwdCBsZWF2aW5nIHRoYXQgbW9kdWxlIHdpdGgNCj4gPiA+
PiBzdGF0dXMNCj4gPiA+PiAiY3VycmVudCIgaXMgbm90IGZpbmUuDQo+ID4gPj4gSU1PIHlvdSBu
ZWVkIHRvIHJlcHVibGlzaCB0aGUgb2xkIG1vZHVsZSBhcyB3ZWxsLCB3aXRoIGV2ZXJ5dGhpbmcN
Cj4gPiA+PiBzdGF0dXMNCj4gPiA+PiBvYnNvbGV0ZS4NCj4gPiA+IEkgZG9uJ3QgYWdyZWUgd2l0
aCB0aGlzLiBUaGUgInN0YXR1cyIgdGFnIGlzIGp1c3RpZmllZCBmb3Igc3Vic2VxdWVudA0KPiA+
ID4gcmV2aXNpb25zIG9mIHRoZSBzYW1lIG1vZHVsZSBzbyBhcyB0byBhaWQgb2xkIGNsaWVudHMu
DQo+ID4gPg0KPiA+ID4gQnV0IGlmIHRoZSBtb2R1bGUgbmFtZSBhbmQgbmFtZXNwYWNlIFVSSSBh
cmUgZGlmZmVyZW50LCB0aGVyZSBpcyBubw0KPiA+ID4gc3VjaA0KPiA+ID4gY29uY2Vybi4gTW9k
dWxlcyBjb250YWluZWQgaW4gUkZDcyA3MjIzLCA4MDIyIGV0Yy4ganVzdCBkZWZpbmUgc29tZQ0K
PiA+ID4gc2NoZW1hcyB0aGF0IGhhcHBlbiB0byBiZSBnb29kIGZvciBteSBwdXJwb3Nlcy4gU28g
SSB3YW50IHRvIGJlIGFibGUNCj4gPiA+IHRvDQo+ID4gPiBjb250aW51ZSB1c2luZyB0aGVtLCBh
bmQgZG9uJ3Qgd2FudCB0b29scyB0byBpc3N1ZSB1c2VsZXNzIHdhcm5pbmdzIG9yDQo+ID4gPiBl
dmVuIHJlZnVzZSB0byBwcm9jZXNzIHN1Y2ggbW9kdWxlcy4NCj4gPiA+DQo+ID4gPiBJIGFtIGZp
bmUgdGhvdWdoIHdpdGggbWFraW5nIGEgbmV3IHJldmlzaW9uIG9mIGlldGYtcm91dGluZw0KPiA+
ID4gZXRjLiBtZW50aW9uaW5nIGluIHRoZSBtb2R1bGUgZGVzY3JpcHRpb24gdGhhdCB0aGlzIG1v
ZHVsZSBpcyBub3QNCj4gPiA+IGNvbXBhdGlibGUgd2l0aCB0aGUgTk1EQSBhcmNoaXRlY3R1cmUs
IGFuZCBwcm92aWRpbmcgYSBwb2ludGVyIHRvDQo+ID4gPiBpZXRmLXJvdXRpbmctMi4NCj4gPiA+
DQo+ID4gPiBMYWRhDQo+ID4gPg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pj4gRS5nLiBGb3IgaWV0
Zi1pbnRlcmZhY2VzLCBhbmQgaWV0Zi1pcCwgd2hpY2ggYXJlIG9sZGVyLCBhbmQgaGVuY2UNCj4g
PiA+Pj4gcHJvYmFibHkNCj4gPiA+Pj4gbXVjaCBtb3JlIHdpZGVseSBpbXBsZW1lbnRlZCB0aGVu
IEkgdGhpbmsgdGhhdCB0aGUgbW9kdWxlcyBzaG91bGQgYmUNCj4gPiA+Pj4gdXBkYXRlZCBpbiBw
bGFjZSB3aXRoIHRoZSBleGlzdGluZyBzdGF0ZSB0cmVlIGRlcHJlY2F0ZWQuICBJLmUuIEkNCj4g
PiA+Pj4gc3VwcG9ydA0KPiA+ID4+PiB3aGF0IE1hcnRpbiBoYXMgZG9uZSBpbiBoaXMgSURzLCBh
bmQgZG9uJ3Qgd2FudCB0aGlzIHRvIGNoYW5nZS4NCj4gPiA+Pj4NCj4gPiA+Pj4gV2hhdCBpcyB0
aGUgcHJvYmxlbSB3aXRoIGRlcHJlY2F0ZWQgbm9kZXM/DQo+ID4gPj4+DQo+ID4gPj4+IE5vdGhp
bmcgcmVhbGx5LCBidXQgSSBndWVzcyB0aGF0IHRoZXkgYXJlIGxpa2VseSB0byBiZSBiYWdnYWdl
IHRoYXQgaXMNCj4gPiA+Pj4gZ29pbmcgdG8gYmUgYXJvdW5kIGZvciBhIGxvbmcgdGltZSBldmVu
IGlmIHZlcnkgZmV3IHBlb3BsZSBldmVyDQo+ID4gPj4+IGltcGxlbWVudA0KPiA+ID4+PiB0aGUg
ZGVwcmVjYXRlZCBub2Rlcy4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gV2h5IGFyZW4ndCB5
b3UgZm9sbG93aW5nIHlvdXIgb3duIHRyYW5zaXRpb24gc3RyYXRlZ3k/DQo+ID4gPj4+DQo+ID4g
Pj4+IFJlYWxseSBiZWNhdXNlIEknbSBub3QgYW4gYXV0aG9yLCBib3RoIHNvbHV0aW9ucyBzZWVt
IHZhbGlkLCBhbmQgSQ0KPiA+ID4+PiBhY3R1YWxseSB0aGluayBqdXN0IHJlYWNoaW5nIGEgY29u
Y2x1c2lvbiBxdWlja2x5IGlzIG1vcmUgaW1wb3J0YW50DQo+ID4gPj4+IHRoYW4NCj4gPiA+Pj4g
d2hpY2ggcGFydGljdWxhciBzb2x1dGlvbiBpcyBjaG9zZW4uICBJIGRvbid0IHNlZSBhbnkgYWR2
YW50YWdlIGlzDQo+ID4gPj4+IHB1c2hpbmcNCj4gPiA+Pj4gYmFjayB0aGUgYWRvcHRpb24gY2Fs
bCAtIGl0IHNlZW1zIGxpa2UgaXQgd2lsbCBwcm9iYWJseSBqdXN0IGRlbGF5DQo+ID4gPj4+IHdo
ZW4gd2UNCj4gPiA+Pj4gY2FuIGRvIFdHIExDLg0KPiA+ID4+Pg0KPiA+ID4+PiBJIGFjdHVhbGx5
IHRoaW5rIHRoYXQgdGhlIGJpZ2dlciBxdWVzdGlvbiB0aGF0IG5lZWRzIHRvIGJlIHJlc29sdmVk
IGlzDQo+ID4gPj4+IHdoZXRoZXIgd2UgbmVlZCBhbiBvcHRpb25hbCBleHRlbnNpb24gdG8gbWFy
ayBhIG1vZHVsZSBhcyBOTURBDQo+ID4gPj4+IGNvbXBhdGlibGUsDQo+ID4gPj4+IG9yIGZvciB0
aGUgZXh0cmEgTk1EQSBzdGF0ZSBtb2R1bGUsIGFzIEkgdGhpbmsgdGhhdCBib3RoIHlvdSBhbmQg
VG9tDQo+ID4gPj4+IGhhdmUNCj4gPiA+Pj4gYmVlbiBhc2tpbmcgZm9yLg0KPiA+ID4+Pg0KPiA+
ID4+IEkgYW0gbm8gZmFuIG9mIFlBTkcgY29uZm9ybWFuY2UuDQo+ID4gPj4gVGhlIFdHIGRvZXMg
bm90IHNlZW0gdG8gdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuDQo+ID4gPj4gICAg
IChBKSB3aGF0IGEgc2VydmVyIGlzIHN1cHBvc2VkIHRvIGRvDQo+ID4gPj4gICAgIChCKSB3aGF0
IGEgc2VydmVyIGNsYWltcyB0byBkbw0KPiA+ID4+DQo+ID4gPj4gVGhlcmUgaXMgbm8gd2F5IHRv
IGV4cHJlc3MgKEEpIGluIGEgWUFORyBtb2R1bGUsIGp1c3QgKEIpIGluIHRoZSBuZXcNCj4gPiA+
PiB5YW5nLWxpYnJhcnkuDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IEFuZHkNCj4gPiA+Pg0KPiA+
ID4+DQo+ID4gPj4NCj4gPiA+Pj4gVGhhbmtzLA0KPiA+ID4+PiBSb2INCj4gPiA+Pj4NCj4gPiA+
Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gQW5keQ0KPiA+ID4+Pg0KPiA+ID4+PiBPbiBG
cmksIFNlcCAxNSwgMjAxNyBhdCA4OjAxIEFNLCBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2Nv
LmNvbT4NCj4gPiA+Pj4gd3JvdGU6DQo+ID4gPj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gT24gMTUv
MDkvMjAxNyAxNTo1MiwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPiA+ID4+Pj4NCj4gPiA+
Pj4+PiBIaSwNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IFdpdGggcmVzcGVjdCB0byBXRyBhZG9wdGlv
biwgd2Ugd2lsbCBkbyB3aGF0ZXZlciB0aGUgV0cgZGVjaWRlcyBmb3INCj4gPiA+Pj4+PiB0aGUN
Cj4gPiA+Pj4+PiBSRkMgODAyMiBtb2RlbC4gV2UgaGF2ZSBhIHN0cm9uZyBwcmVmZXJlbmNlIHRv
d2FyZCBub3QgY2FycnlpbmcgdGhlDQo+ID4gPj4+Pj4gZGVwcmVjYXRlZCBub2RlcyBmb3J3YXJk
IGFuZCBuZXcgbW9kdWxlIHZlcnNpb25zIGFwcGVhcnMgdG8gYmUgYSBnb29kDQo+ID4gPj4+Pj4g
d2F5DQo+ID4gPj4+Pj4gdG8gYWNoaWV2ZSB0aGlzLg0KPiA+ID4+Pj4+DQo+ID4gPj4+PiBDYW4g
d2Ugbm90IGFkb3B0IHJlZ2FyZGxlc3M/ICBXZSBrbm93IHRoYXQgd2UgYXJlIGdvaW5nIHRvIGJp
cyA4MDIyLA0KPiA+ID4+Pj4gYW5kDQo+ID4gPj4+PiBoYXZpbmcgYW4gYWRvcHRlZCBkcmFmdCBn
aXZlcyBpdCBhIGJpdCBtb3JlIGxlZ2l0aW1hY3kgYW5kIGhlbHBzIG90aGVyDQo+ID4gPj4+PiBm
b2xrcyB0byBtaWdyYXRlLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IE9yIHBlcmhhcHMgd2UgY2FuIHN0
YXJ0IHRoZSBjYWxsIGZvciBhZG9wdGlvbiBhbmQgY29udGludWUgdG8gdHJ5IGFuZA0KPiA+ID4+
Pj4gcmVzb2x2ZSB0aGlzIGlzc3VlIGF0IHRoZSBzYW1lIHRpbWUgOy0pLiAgSSB0aGluayB0aGF0
IGl0IHdvdWxkIGJlDQo+ID4gPj4+PiBnb29kIHRvDQo+ID4gPj4+PiB0cnkgYW5kIGdldCB0aGUg
dXBkYXRlZCBtb2RlbCBkcmFmdHMgdG8gV0cgTEMgYnkgU2luZ2Fwb3JlLg0KPiA+ID4+Pj4NCj4g
PiA+Pj4+IEkga25vdyB0aGF0IGl0IGhhc24ndCBiZWVuIGFza2VkIHlldCwgYnV0IEkgc3VwcG9y
dCBhZG9wdGlvbiBvZiBhbnkNCj4gPiA+Pj4+IDgwMjINCj4gPiA+Pj4+IGJpcyBkcmFmdCB0aGF0
IChpKSBwcm92aWRlcyB0aGUgY29ycmVjdCBORE1BIGNvbWJpbmVkIHRyZWUgKGlpKQ0KPiA+ID4+
Pj4gcmVtb3ZlcyBvcg0KPiA+ID4+Pj4gZGVwcmVjYXRlcyB0aGUgb2xkIHN0YXRlIG5vZGVzIDot
KQ0KPiA+ID4+Pj4NCj4gPiA+Pj4+IFNvcnJ5LCBpZiBJJ20gYmVpbmcgcHVzaHkgOi0pDQo+ID4g
Pj4+PiBSb2INCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+PiBJIGFncmVl
IHdpdGggTGFkYSB0aGF0IGRlcHJlY2F0aW5nIGFsbCB0aGUgc2NoZW1hIG5vZGVzIGlzDQo+ID4g
Pj4+Pj4gdW5uZWNlc3NhcnkuDQo+ID4gPj4+Pj4gSG93ZXZlciwgd2XigJlsbCBkbyB3aGF0IGl0
IHRha2VzIHRvIHJlYWNoIGNvbnNlbnN1cyBhbmQgc2F0aXNmeSB0aGUNCj4gPiA+Pj4+PiBtb3N0
DQo+ID4gPj4+Pj4gcGVkYW50aWMgYW1vbmcgdXMuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBUaGFu
a3MsDQo+ID4gPj4+Pj4gQWNlZQ0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gT24gOS8xNS8xNywgNjoz
OCBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPiA+ID4+Pj4+IDxu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6
DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBLZW50IFdhdHNlbiBww63FoWUgdiDEjHQgMTQuIDA5LiAy
MDE3IHYgMTQ6NTIgKzAwMDA6DQo+ID4gPj4+Pj4+PiByZmM4MDIyYmlzLTAyIHNpZ25hbHMgdGhl
IGludGVudCB0byBkaXRjaCB0aGUNCj4gPiA+Pj4+Pj4+IGN1cnJlbnQvc29vbi10by1iZS1sZWdh
Y3kNCj4gPiA+Pj4+Pj4+IG1vZHVsZSwgYnV0IGRvZXMgaXQgYWN0dWFsbHkgc2F5IGl0PyAgKEkg
Y2FuJ3QgZmluZCBpdCkNCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+IFRoZSBtb2R1bGVzIGNvbnRh
aW5lZCB0aGVyZWluIGhhdmUgZGlmZmVyZW50IG5hbWVzIGFuZCBuYW1lc3BhY2VzLCBzbw0KPiA+
ID4+Pj4+PiB0aGVyZSBpcw0KPiA+ID4+Pj4+PiBubyBmb3JtYWwgYW5jZXN0cnkuIEkgd291bGQg
cHJlZmVyIHRvIGtlZXAgdGhlIG1vZHVsZXMgZnJvbSBSRkMgODAyMg0KPiA+ID4+Pj4+PiBhcw0K
PiA+ID4+Pj4+PiB0aGV5IGFyZQ0KPiA+ID4+Pj4+PiAtIHNvbWUgd2VpcmRvcyBtYXkgc3RpbGwg
d2FudCB0byB1c2UgdGhlbS4NCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gVGhlIGRyYWZ0IGRvZXMg
c2F5IHRoYXQgaXQgb2Jzb2xldGVzIDgwMjIsIGJ1dCBJJ20gdW5zdXJlIGlmIHRoYXQncw0KPiA+
ID4+Pj4+Pj4gZ29pbmcgdG8NCj4gPiA+Pj4+Pj4+IGhhdmUgYSBtZWFuaW5nZnVsIGltcGFjdCBp
biB0aGUgd2lsZC4gIEkgdGhpbmsgSnVlcmdlbiBzYWlkIHRoZXkgaGFkDQo+ID4gPj4+Pj4+PiB0
aGlzDQo+ID4gPj4+Pj4+PiBpc3N1ZSB3aXRoIE1JQjIgYW5kIG9ubHkgYWZ0ZXIgYSBjb3VwbGUg
eWVhcnMgb2YgbWlzdXNlIGRpZCB0aGV5DQo+ID4gPj4+Pj4+PiByZXB1Ymxpc2ggdGhlDQo+ID4g
Pj4+Pj4+PiBsZWdhY3kgTUlCcyB3aXRoIGRlcHJlY2F0ZWQgc3RhdHVzLg0KPiA+ID4+Pj4+Pj4N
Cj4gPiA+Pj4+Pj4+IEknbSBva2F5IHdpdGggdGhpcyBjaGFuZ2UgYmVpbmcgbWFkZSBhZnRlciBh
ZG9wdGlvbiwgc28gbG9uZyBhcw0KPiA+ID4+Pj4+Pj4gdGhlcmUncw0KPiA+ID4+Pj4+Pj4gZ2Vu
ZXJhbCBhZ3JlZW1lbnQgdG8gZG8gaXQuICBBcmUgdGhlIGF1dGhvcnMgb2theSB3aXRoIGl0LCBv
ciBhcmUNCj4gPiA+Pj4+Pj4+IHRoZXJlDQo+ID4gPj4+Pj4+PiBhbnkNCj4gPiA+Pj4+Pj4+IGJl
dHRlciBzdWdnZXN0aW9ucz8NCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiBQUzogU2FkbHksIHRo
ZSAnbW9kdWxlJyBzdGF0ZW1lbnQgZG9lcyBub3QgaGF2ZSAnc3RhdHVzJyBhcyBhDQo+ID4gPj4+
Pj4+PiBzdWJzdGF0ZW1lbnQgW0kNCj4gPiA+Pj4+Pj4+IGp1c3QgYWRkZWQgdGhpcyBvbWlzc2lv
biB0byB0aGUgeWFuZy1uZXh0IHRyYWNrZXJdLiAgSSB0aGluayB0aGUgb25seQ0KPiA+ID4+Pj4+
Pj4gd2F5IHRvDQo+ID4gPj4+Pj4+PiAiZGVwcmVjYXRlIGEgbW9kdWxlIiBpcyB0byBpbnN0ZWFk
IGRlcHJlY2F0ZSB0aGUgYWxsIHRoZQ0KPiA+ID4+Pj4+Pj4gbm9kZXMvcnBjcy9ub3RpZmljYXRp
b25zIGluIHRoZSBtb2R1bGUuICBLaW5kIG9mIHVnbHksIGJ1dCBpdCdzIGZvciBhDQo+ID4gPj4+
Pj4+PiBkZXByZWNhdGVkIG1vZHVsZSwgc28gd2hvIGNhcmUsIHJpZ2h0PyAgOykNCj4gPiA+Pj4+
Pj4+DQo+ID4gPj4+Pj4+IEkgdGhpbmsgaXQgaXMgdW5uZWNlc3NhcnkuIElmIHNvbWVib2R5IG5l
ZWRzIGFkZGluZyBzdWNoIGEgbW9kdWxlIHRvDQo+ID4gPj4+Pj4+IHRoZQ0KPiA+ID4+Pj4+PiBk
YXRhDQo+ID4gPj4+Pj4+IG1vZGVsLCBoZS9zaGUgc2hvdWxkIHByb2JhYmx5IGhhdmUgYSByZWFz
b24gdG8gZG8gc28sIHN1Y2ggYXMgZGF0YQ0KPiA+ID4+Pj4+PiBpbXBsZW1lbnRlZA0KPiA+ID4+
Pj4+PiBvbiB0aGUgc2VydmVyLg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBMYWRhDQo+ID4gPj4+
Pj4+DQo+ID4gPj4+Pj4+IEtlbnQNCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiAtLQ0KPiA+ID4+
Pj4+Pj4NCj4gPiA+Pj4+Pj4+IEhpIFJvYiwNCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiBPbiA5
LzE0LzIwMTcgOTozNyBBTSwgUm9iZXJ0IFdpbHRvbiB3cm90ZToNCj4gPiA+Pj4+Pj4+DQo+ID4g
Pj4+Pj4+Pj4gSGkgS2VudCAmIExvdSwNCj4gPiA+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4+IFdoZW4g
ZG8geW91IHRoaW5rIHRoYXQgaXQgd2lsbCBiZSBwb3NzaWJsZSB0byBzdGFydCB0aGUgYWRvcHRp
b24NCj4gPiA+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4gcHJvY2Vzcw0KPiA+ID4+Pj4+Pj4NCj4gPiA+
Pj4+Pj4+PiBvbiB0aGVzZSBkcmFmdHM/DQo+ID4gPj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+PiBJIHRo
aW5rIHRoYXQgdGhlIGZpcnN0IHR3byBhdCBsZWFzdCB3b3VsZCBzZWVtIHRvIGJlIHJlYWR5IGZv
cg0KPiA+ID4+Pj4+Pj4+IGFkb3B0aW9uLiAgRm9yIHRoZSAzcmQgZHJhZnQsIHRoZXJlIHN0aWxs
IHNlZW1zIHRvIGJlIGFuIG9wZW4NCj4gPiA+Pj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4gcXVlc3Rpb24N
Cj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pj4gb2Ygd2hhdCB0byBkbyB3aXRoIHRoZSBvbGQgc3Rh
dGUgdHJlZSwgYnV0IHByZXN1bWFibHkgdGhhdCBjb3VsZCBiZQ0KPiA+ID4+Pj4+Pj4+IHNvbHZl
ZCBhZnRlciB0aGUgZHJhZnQgaGFzIGJlZW4gYWRvcHRlZD8NCj4gPiA+Pj4+Pj4+Pg0KPiA+ID4+
Pj4+Pj4gSSBzZWUgYW4gdXBkYXRlIGZvciB0aGUgdGhpcmQgd2FzIHB1Ymxpc2hlZCB5ZXN0ZXJk
YXkNCj4gPiA+Pj4+Pj4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWNlZS1u
ZXRtb2QtcmZjODAyMmJpcy0wMikgIHRoYXQNCj4gPiA+Pj4+Pj4+IGNsYXJpZmllcyB0aGUgaW50
ZW50IGlzIHRvIHJlcGxhY2UgdGhlIGN1cnJlbnQgbW9kdWxlcywgYW5kIHByZXN1bWFibHkNCj4g
PiA+Pj4+Pj4+IG9ic29sZXRlIDgwMjIuICBBbmQgbm93IHRoYXQgdGhpcyBpbnRlbmRlZCBkaXJl
Y3Rpb24gaXMgY2xlYXIgaW4gdGhlDQo+ID4gPj4+Pj4+PiBkcmFmdCB3ZSBjb3VsZCBwb2xsIGl0
Lg0KPiA+ID4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBzdGlsbCBkb2Vzbid0IGFk
ZHJlc3MgaWYgd2UgbmVlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0KPiA+ID4+Pj4+Pj4gcmZjODAy
MiBkZWZpbmVkIG1vZHVsZXMgYXJlIGRlcHJlY2F0ZWQgYnkgc29tZSBvdGhlciBtZWNoYW5pc21z
IHRoYW4NCj4gPiA+Pj4+Pj4+IGp1c3QgcmVwbGFjaW5nIHRoZSBSRkMsIGUuZy4sIGJ5IHVwZGF0
aW5nIHRoZSBvbGQgbW9kdWxlcyB3aXRoIGFsbA0KPiA+ID4+Pj4+Pj4gbm9kZXMNCj4gPiA+Pj4+
Pj4+IG1hcmtlZCBhcyBkZXByZWNhdGVkLiAgSSB0aGluayB5b3UncmUgcmlnaHQgdGhhdCB0aGlz
IGNvdWxkIGJlIGRvbmUNCj4gPiA+Pj4+Pj4+IHBvc3QNCj4gPiA+Pj4+Pj4+IGFkb3B0aW9uLiAg
T2YgY291cnNlIG90aGVycyBhcmUgZnJlZSB0byBkaXNhZ3JlZS4NCj4gPiA+Pj4+Pj4+DQo+ID4g
Pj4+Pj4+PiBJIGNoZWNrIHdpdGggS2VudCBhbmQgc2VlIHdoYXQgaGUgdGhpbmtzLg0KPiA+ID4+
Pj4+Pj4NCj4gPiA+Pj4+Pj4+IFRoYW5rcywNCj4gPiA+Pj4+Pj4+IExvdQ0KPiA+ID4+Pj4+Pj4N
Cj4gPiA+Pj4+Pj4+IFRoYW5rcywNCj4gPiA+Pj4+Pj4+PiBSb2INCj4gPiA+Pj4+Pj4+Pg0KPiA+
ID4+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pj4gT24gMzAvMDgvMjAxNyAwMDo0NiwgS2VudCBXYXRzZW4g
d3JvdGU6DQo+ID4gPj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4gSGV5IGZvbGtzLA0KPiA+ID4+Pj4+
Pj4+Pg0KPiA+ID4+Pj4+Pj4+PiBBcyBkaXNjdXNzZWQgYXQgdGhlIGxhc3QgbWVldGluZywgd2Ug
YXJlIGhlYWRpbmcgdG8gcmV2aXNpbmcNCj4gPiA+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+PiBleGlz
dGluZyBSRkNzDQo+ID4gPj4+Pj4+Pj4gdG8gYWxpZ24gdGhlbSB3aXRoIE5NREEuICBUaGUgZmly
c3QgYmF0Y2ggaGF2ZSBiZWVuIHB1Ymxpc2hlZCBhcw0KPiA+ID4+Pj4+Pj4+PiBpbmRpdmlkdWFs
IGRyYWZ0czoNCj4gPiA+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4gMS4gaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWJqb3JrbHVuZC1uZXRtb2QtcmZjNzIyM2Jpcy0wMA0KPiA+ID4+
Pj4+Pj4+PiAyLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmpvcmtsdW5kLW5l
dG1vZC1yZmM3Mjc3YmlzLTAwDQo+ID4gPj4+Pj4+Pj4+IDMuIGh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLTAwDQo+ID4gPj4+Pj4+Pj4+DQo+
ID4gPj4+Pj4+Pj4+IFBsZWFzZSB0YWtlIGEgbG9vayAoY29tbWVudHMgd2VsY29tZSEpIGFuZCBz
dGF5IHR1bmVkIGZvciB0aGUNCj4gPiA+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+PiByZWxhdGVkDQo+
ID4gPj4+Pj4+Pj4gYWRvcHRpb24gY2FsbHMuDQo+ID4gPj4+Pj4+Pj4+IFRoYW5rcywNCj4gPiA+
Pj4+Pj4+Pj4gS2VudCAoYW5kIExvdSkNCj4gPiA+Pj4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+Pj4NCj4g
PiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPiA+Pj4+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4+Pj4+Pj4+PiBuZXRt
b2RAaWV0Zi5vcmcNCj4gPiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCj4gPiA+Pj4+Pj4+Pj4gLg0KPiA+ID4+Pj4+Pj4+Pg0KPiA+ID4+Pj4+
Pj4+Pg0KPiA+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gPiA+Pj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4+Pj4+IG5l
dG1vZEBpZXRmLm9yZw0KPiA+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+IC0tDQo+ID4gPj4+Pj4+IExh
ZGlzbGF2IExob3RrYQ0KPiA+ID4+Pj4+PiBIZWFkLCBDWi5OSUMgTGFicw0KPiA+ID4+Pj4+PiBQ
R1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+Pj4+Pj4g
bmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4+Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+Pj4+
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+Pj4+
Pj4NCj4gPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiA+ID4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4+PiBuZXRtb2RAaWV0
Zi5vcmcNCj4gPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KPiA+ID4+Pj4+DQo+ID4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiA+ID4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4+Pj4g
bmV0bW9kQGlldGYub3JnDQo+ID4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZA0KPiA+ID4+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiANCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxp
bmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Fri Oct  6 09:01:58 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE05B126DFE; Fri,  6 Oct 2017 09:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 zbXAmfbXArCc; Fri,  6 Oct 2017 09:01:49 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1D01349F6; Fri,  6 Oct 2017 09:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16987; q=dns/txt; s=iport; t=1507305709; x=1508515309; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ipr8BjIfZoHxtq3i2sWlARJGHmr1aGZqIYgk88oY/rw=; b=RyPxUMgslQBpeamlIxYCwzUeHKEKd47ICw5IB4FUfTQXmQtuUlPzKLIa kghXpsM9WsmQwr+89V2V/kl1R0Tw5zNlgbwA0Sa92xJyFFiv6Pqh2VtCz zpF8NBVwn0ir4Dfr+fohpoEJZh4aZ+fRVnJgzJOcd1wYk770kNpZmcIQA A=;
X-IronPort-AV: E=Sophos;i="5.42,484,1500940800"; d="scan'208";a="655280820"
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 Oct 2017 16:01:47 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v96G1lwE031722; Fri, 6 Oct 2017 16:01:47 GMT
To: Martin Bjorklund , bclaise@cisco.com
Cc: andy@yumaworks.com, acee@cisco.com, netmod@ietf.org, rtg-dt-yang-arch@ietf.org
References:  <87h8w0bbyf.fsf@nic.cz>  <20171006.173244.1167478609964390238.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com>
Date: Fri, 6 Oct 2017 17:01:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20171006.173244.1167478609964390238.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] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 16:01:53 -0000

On 06/10/2017 16:32, Martin Bjorklund wrote:
> Benoit Claise  wrote:
>> Dear all,
>>
>> [including the routing and multicast YANG design teams]
>> Can we please finalize the discussion regarding ietf-routing versus
>> ietf-routing-2, sooner than later.
>>
>> I care about the NMDA transition strategy.
>>
>> Here are all the ietf-routing dependent YANG modules (those modules
>> that depend on ietf-routing)
>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
>> So many YANG modules.
>>
>> Look at the difference for ietf-routing-2:
>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
>> Some dependent modules are compliant with ietf-routing-2, the
>> multicast YANG modules, but these are the only ones.
>>
>> Changing the module name from ietf-routing to ietf-routing-2 implies
>> that the we have to warn all draft authors of ietf-routing YANG
>> dependent modules:
>>      1. to make sure they are aware of ietf-routing-2  (publishing a
>> RFC8022bis mentioning in the module description that this module is
>> not compatible with the NMDA architecture, and providing a pointer to
>> ietf-routing-2 ... is not an automatic way... so barely useful)
>>      2. to ask them to change their import to ietf-routing-2
>> Hopefully, in the routing case, it's mainly the IETF.
>> I'm glad that we didn't change the ietf-interfaces to
>> ietf-interfaces-2, we would have to deal with cross
>> SDO/consortia/opensource project issues
>> Note:
>>
>>     we're in a transition phase today, while we implement the
>>     soon-to-be-published draft-clacla-netmod-model-catalog-02
>>     Because of this, the SDO/consortia/opensource dependent YANG modules
>>     will only appear in the Impact Analysis tomorrow at
>>     https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
>>     In the mean time, you can see all these dependent modules
>>     Ex:
>>     https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces
>>              => click on "dependents"
>>     Those dependent modules is a new feature of
>>     draft-clacla-netmod-model-catalog-02
>>
>>
>> I'm wondering if this NMDA transition hurdle doesn't make a good
>> justification to keep the same module name!
>> We could debate whether ietf-routing is implemented or not, but the
>> point is moot: we don't know what we don't know.
> Agreed.  I think there are no real reasons for keeping the module name
> and deprecate the old defintiions.  Yes, it adds some noise to the
> module but the fact is that we do deprecate all these defintions, and
> I think we should not hide that.
This is also my preferred option.

I would like to just deprecate these nodes now, and then (for the 
routing module that is unlikely to have been widely implement) update it 
again in a 1-2 years time to remove the deprecated nodes (we can warn 
now that they will get removed).

Conversely, for ietf interfaces (which is much more likely to be widely 
implemented), I think that they should move to obsolete after 1-2 years 
and then hopefully be removed 1-2 years after that.

Thanks,
Rob


>
>
> /martin
>
>
>
>> Regarding one point made by Andy:
>>
>>     I should explain the use-case for identifying NMDA vs.
>>     NMDA-transition modules.
>>     I do not want to present both types (for a given module) to the user.
>>     So the tools need to know in "NMDA mode" which modules are duplicates
>>     for NMDA-transition purpose only, so those modules can be hidden
>>     from the user.
>>     In "legacy mode" the NMDA modules would be hidden and the transition
>>     modules
>>     would be exposed to the user instead.
>>
>>     Guessing which is which will only cause unhappy customers so we will
>>     force
>>     vendors to tag the modules with our own YANG extensions to tell them
>>     apart.
>>
>> We recognized this use case and tagged the YANG module "tree-type" in
>> the YANG catalog.
>> In the soon-to-be-published but already implemented
>> draft-clacla-netmod-model-catalog-02 draft, you will see:
>>
>>     leaf tree-type {
>>            type enumeration {
>>              enum "split" {
>>                description
>>                  "This module uses a split config/operational state layout.";
>>              }
>>              enum "nmda-compatible" {
>>                description
>>                  "This module is compatible with the Network Management
>>                  Datastores
>>                   Architecture (NMDA) and combines config and operational state
>>                   nodes.";
>>              }
>>              enum "transitional-extra" {
>>                description
>>                  "This module is derived as a '-state' module to allow for
>>                  transitioning
>>                   to a full NMDA-compliant tree structure.";
>>              }
>>              enum "openconfig" {
>>                description
>>                  "This module uses the Openconfig data element layout.";
>>              }
>>              enum "unclassified" {
>>                description
>>                  "This module does not belong to any category or can't be
>>                  determined.";
>>              }
>>              enum "not-applicable" {
>>                description
>>                  "This module is not applicable. For example, because the YANG
>>                  module only contains typedefs, groupings, or is a submodule";
>>              }
>>            }
>>            description
>>              "The type of data element tree used by the module as it relates to
>>              the
>>               Network Management Datastores Architecture.";
>>            reference "draft-dsdt-nmda-guidelines Guidelines for YANG Module
>>            Authors (NMDA)";
>>          }
>>          description
>>            "Grouping of YANG module metadata that extends the common list
>>            defined in the YANG
>>             Module Library (RFC 7895).";
>>     }
>>
>>
>> If not convinced already, I hope that you start to see the YANG
>> catalog value for the industry.
>> Let's keep in mind that automation is key. Therefore, YANG modules
>> without module details (metadata) and related tools is not sufficient
>> for the industry.
>>
>> Regards, Benoit
>>> Andy Bierman  writes:
>>>
>>>> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton 
>>>> wrote:
>>>>
>>>>> On 15/09/2017 16:23, Andy Bierman wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> So are you saying the NMDA transition strategy should be ignored?
>>>>>
>>>>> My personal preference for the routing modules would be to keep the
>>>>> same
>>>>> module name and deprecate the old nodes.
>>>>>
>>>>> However, I doubt that there are many implementations of this 8022 yet,
>>>>> and
>>>>> if the authors prefer to use a new namespace without the old nodes
>>>>> then I'm
>>>>> fine with that also.  Are you opposed to this approach?
>>>>>
>>>>>
>>>> A new module name mandates a new namespace, so they go together.
>>>> Abandoning the old module is fine, except leaving that module with
>>>> status
>>>> "current" is not fine.
>>>> IMO you need to republish the old module as well, with everything
>>>> status
>>>> obsolete.
>>> I don't agree with this. The "status" tag is justified for subsequent
>>> revisions of the same module so as to aid old clients.
>>>
>>> But if the module name and namespace URI are different, there is no
>>> such
>>> concern. Modules contained in RFCs 7223, 8022 etc. just define some
>>> schemas that happen to be good for my purposes. So I want to be able
>>> to
>>> continue using them, and don't want tools to issue useless warnings or
>>> even refuse to process such modules.
>>>
>>> I am fine though with making a new revision of ietf-routing
>>> etc. mentioning in the module description that this module is not
>>> compatible with the NMDA architecture, and providing a pointer to
>>> ietf-routing-2.
>>>
>>> Lada
>>>
>>>>
>>>>> E.g. For ietf-interfaces, and ietf-ip, which are older, and hence
>>>>> probably
>>>>> much more widely implemented then I think that the modules should be
>>>>> updated in place with the existing state tree deprecated.  I.e. I
>>>>> support
>>>>> what Martin has done in his IDs, and don't want this to change.
>>>>>
>>>>> What is the problem with deprecated nodes?
>>>>>
>>>>> Nothing really, but I guess that they are likely to be baggage that is
>>>>> going to be around for a long time even if very few people ever
>>>>> implement
>>>>> the deprecated nodes.
>>>>>
>>>>>
>>>>> Why aren't you following your own transition strategy?
>>>>>
>>>>> Really because I'm not an author, both solutions seem valid, and I
>>>>> actually think just reaching a conclusion quickly is more important
>>>>> than
>>>>> which particular solution is chosen.  I don't see any advantage is
>>>>> pushing
>>>>> back the adoption call - it seems like it will probably just delay
>>>>> when we
>>>>> can do WG LC.
>>>>>
>>>>> I actually think that the bigger question that needs to be resolved is
>>>>> whether we need an optional extension to mark a module as NMDA
>>>>> compatible,
>>>>> or for the extra NMDA state module, as I think that both you and Tom
>>>>> have
>>>>> been asking for.
>>>>>
>>>> I am no fan of YANG conformance.
>>>> The WG does not seem to understand the difference between
>>>>      (A) what a server is supposed to do
>>>>      (B) what a server claims to do
>>>>
>>>> There is no way to express (A) in a YANG module, just (B) in the new
>>>> yang-library.
>>>>
>>>>
>>>> Andy
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton 
>>>>> wrote:
>>>>>
>>>>>> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> With respect to WG adoption, we will do whatever the WG decides for
>>>>>>> the
>>>>>>> RFC 8022 model. We have a strong preference toward not carrying the
>>>>>>> deprecated nodes forward and new module versions appears to be a good
>>>>>>> way
>>>>>>> to achieve this.
>>>>>>>
>>>>>> Can we not adopt regardless?  We know that we are going to bis 8022,
>>>>>> and
>>>>>> having an adopted draft gives it a bit more legitimacy and helps other
>>>>>> folks to migrate.
>>>>>>
>>>>>> Or perhaps we can start the call for adoption and continue to try and
>>>>>> resolve this issue at the same time ;-).  I think that it would be
>>>>>> good to
>>>>>> try and get the updated model drafts to WG LC by Singapore.
>>>>>>
>>>>>> I know that it hasn't been asked yet, but I support adoption of any
>>>>>> 8022
>>>>>> bis draft that (i) provides the correct NDMA combined tree (ii)
>>>>>> removes or
>>>>>> deprecates the old state nodes :-)
>>>>>>
>>>>>> Sorry, if I'm being pushy :-)
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I agree with Lada that deprecating all the schema nodes is
>>>>>>> unnecessary.
>>>>>>> However, we’ll do what it takes to reach consensus and satisfy the
>>>>>>> most
>>>>>>> pedantic among us.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Acee
>>>>>>>
>>>>>>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>>>>>>>  wrote:
>>>>>>>
>>>>>>> Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
>>>>>>>>> rfc8022bis-02 signals the intent to ditch the
>>>>>>>>> current/soon-to-be-legacy
>>>>>>>>> module, but does it actually say it?  (I can't find it)
>>>>>>>>>
>>>>>>>> The modules contained therein have different names and namespaces, so
>>>>>>>> there is
>>>>>>>> no formal ancestry. I would prefer to keep the modules from RFC 8022
>>>>>>>> as
>>>>>>>> they are
>>>>>>>> - some weirdos may still want to use them.
>>>>>>>>
>>>>>>>> The draft does say that it obsoletes 8022, but I'm unsure if that's
>>>>>>>>> going to
>>>>>>>>> have a meaningful impact in the wild.  I think Juergen said they had
>>>>>>>>> this
>>>>>>>>> issue with MIB2 and only after a couple years of misuse did they
>>>>>>>>> republish the
>>>>>>>>> legacy MIBs with deprecated status.
>>>>>>>>>
>>>>>>>>> I'm okay with this change being made after adoption, so long as
>>>>>>>>> there's
>>>>>>>>> general agreement to do it.  Are the authors okay with it, or are
>>>>>>>>> there
>>>>>>>>> any
>>>>>>>>> better suggestions?
>>>>>>>>>
>>>>>>>>> PS: Sadly, the 'module' statement does not have 'status' as a
>>>>>>>>> substatement [I
>>>>>>>>> just added this omission to the yang-next tracker].  I think the only
>>>>>>>>> way to
>>>>>>>>> "deprecate a module" is to instead deprecate the all the
>>>>>>>>> nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
>>>>>>>>> deprecated module, so who care, right?  ;)
>>>>>>>>>
>>>>>>>> I think it is unnecessary. If somebody needs adding such a module to
>>>>>>>> the
>>>>>>>> data
>>>>>>>> model, he/she should probably have a reason to do so, such as data
>>>>>>>> implemented
>>>>>>>> on the server.
>>>>>>>>
>>>>>>>> Lada
>>>>>>>>
>>>>>>>> Kent
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Hi Rob,
>>>>>>>>>
>>>>>>>>> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>>>>>>>>>
>>>>>>>>>> Hi Kent & Lou,
>>>>>>>>>>
>>>>>>>>>> When do you think that it will be possible to start the adoption
>>>>>>>>>>
>>>>>>>>> process
>>>>>>>>>
>>>>>>>>>> on these drafts?
>>>>>>>>>>
>>>>>>>>>> I think that the first two at least would seem to be ready for
>>>>>>>>>> adoption.  For the 3rd draft, there still seems to be an open
>>>>>>>>>>
>>>>>>>>> question
>>>>>>>>>
>>>>>>>>>> of what to do with the old state tree, but presumably that could be
>>>>>>>>>> solved after the draft has been adopted?
>>>>>>>>>>
>>>>>>>>> I see an update for the third was published yesterday
>>>>>>>>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
>>>>>>>>> clarifies the intent is to replace the current modules, and presumably
>>>>>>>>> obsolete 8022.  And now that this intended direction is clear in the
>>>>>>>>> draft we could poll it.
>>>>>>>>>
>>>>>>>>> I think this still doesn't address if we need to indicate that the
>>>>>>>>> rfc8022 defined modules are deprecated by some other mechanisms than
>>>>>>>>> just replacing the RFC, e.g., by updating the old modules with all
>>>>>>>>> nodes
>>>>>>>>> marked as deprecated.  I think you're right that this could be done
>>>>>>>>> post
>>>>>>>>> adoption.  Of course others are free to disagree.
>>>>>>>>>
>>>>>>>>> I check with Kent and see what he thinks.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Lou
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>> Rob
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 30/08/2017 00:46, Kent Watsen wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey folks,
>>>>>>>>>>>
>>>>>>>>>>> As discussed at the last meeting, we are heading to revising
>>>>>>>>>>>
>>>>>>>>>> existing RFCs
>>>>>>>>>> to align them with NMDA.  The first batch have been published as
>>>>>>>>>>> individual drafts:
>>>>>>>>>>>
>>>>>>>>>>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>>>>>>>>>>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>>>>>>>>>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>>>>>>>>>
>>>>>>>>>>> Please take a look (comments welcome!) and stay tuned for the
>>>>>>>>>>>
>>>>>>>>>> related
>>>>>>>>>> adoption calls.
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Kent (and Lou)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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 Fri Oct  6 09:37:59 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BE2134A66; Fri,  6 Oct 2017 09:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 rvkC6dw_94zc; Fri,  6 Oct 2017 09:37:50 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0136.outbound.protection.outlook.com [104.47.1.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E73134A61; Fri,  6 Oct 2017 09:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rXP7Jx4mXxG05rujN401rP5FgBmbKVQeeOTh6yphcg4=; b=UkbXZAGyyJ+Ct/f9QQxoK62mCoUID85KlWzIXkgQOqUPM35wcVdxJiN6V71iCWNCkVYrSK8kaYvwXQKutkXPosXEXx3jXPYl5rDhxl4eOH79iKWNo2xIPZgM6HM0MNSSHyxmv6PJ4BnsM0Lrg49a2U5UTHS8/IFCjX9Zscjk1nk=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (109.146.128.123) 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.77.5; Fri, 6 Oct 2017 16:37:47 +0000
Message-ID: <015501d33ec1$28882e60$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "NetMod WG" , "Lou Berger" 
Cc: , 
References: 
Date: Fri, 6 Oct 2017 17:34:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [109.146.128.123]
X-ClientProxiedBy: AM5PR04CA0035.eurprd04.prod.outlook.com (2603:10a6:206:1::48) To DB6PR0701MB2999.eurprd07.prod.outlook.com (2603:10a6:4:73::9)
X-MS-Office365-Filtering-Correlation-Id: f6d1732d-6fb7-4190-b665-08d50cd893de
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB6PR0701MB2999; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 3:UJ1XM2lC3DuhSXOjCEIu3DDBtmuC8Yhc/3pzymv9DaNjdp4k0sjCqGmOtD5CmxdDOojM7f2ZX1a1dqN5dYBZoLokZk3F2SOKc2/YLucWIHaH7ZN/tLS+ej1X9nmq9esql9DcrHQ5YwLigXlvsus21Ycq4VWQpRzMQeZ+40fClXhVKrjhcgqDWNMOidaJRdV8CJhfDwGHPSn6bIruzJyFuF+X3YpgFV6B3OPCqigaddyyFXGHdox8VwfE8D6VOl9/; 25:QdqaHf85S979ccza5GBSQKYtihevUmqHgx0dCTWP3L+fIALwKrzw/h1cLtwL7kxI/MRV8OgSKB1X4SDsFmQHiQPk6VkHQzCWiOYt7z39sJcNwzm73bwBph84NzR+23M2vwlnDTwAAIuvJjC1GDX2U++7pGyoohdj6l5gCRCR4iddc2zkGzNB9aqx7Ug2+DkaZwUYsLA2aftnE3YqSWzn/PPT38XqnbQ/u6btLm46lGu18g1wZo4QGJssD/JvxIl9t4rwDQQv4JOaseryKSO6JYHh5sTixpAyPY+c4OwhPW0nD/vav56UBCQHwYAn2K2/t7FolvR7SJAaFSXLACE67g==; 31:lrWGMqduNh2rUz/Kze6WP+Rq5GJeODSvbGLjSFlUc6j54hT6havrsBkAmHBcKu9KOKgOpbaJPOlqD9fwr73/QMH4cjH9DPCGxgAUPOc9vCYv4jtTtVenslPaCCu2aNQPlIGZNjWCuwzEiJamLR7eTTcRyj11lzNO6DrgHw+ar0o+Hz+Xdzx3BaAkLL41Mk+DKzTUcbkkTgqXODM9pdG2s/cKTAhbga/xB5iiJezN578=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2999:
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2999; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 4:kVe95c9C6vCLQpr1HwlTF8BZQ5oYT5CVzoYlAXiTVQ64TV4QzQJdbj38bTLxeXpqk/x+h9YJBp8NOEKU29uGVWsQ/qHecYT7oEMF4MTewucmfE6QV3aEjzTTI6E2luRMWLi1J61Gw3JaISuadLvzpNL1wOJfmrjY7o1zSZUNCiMZH2ZazPktuzcxJkAjD7GQJl9mXUjDHvKzg2OUJdViz2epAhozSzZhqPGqbhrIpV7xFxKqqs7X6ZcnnAdclRwO
X-Forefront-PRVS: 0452022BE1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(199003)(13464003)(189002)(377454003)(101416001)(81156014)(44716002)(62236002)(68736007)(189998001)(66066001)(1456003)(106356001)(53936002)(14496001)(105586002)(25786009)(229853002)(116806002)(9686003)(97736004)(86362001)(61296003)(23676002)(8676002)(81166006)(47776003)(8936002)(478600001)(316002)(230700001)(3846002)(305945005)(16526018)(6116002)(5660300001)(54906003)(110136005)(84392002)(4326008)(7736002)(6486002)(1556002)(81686999)(76176999)(6246003)(50466002)(44736005)(50986999)(33646002)(2906002)(81816999)(6666003)(6496005)(50226002)(4720700003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; 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?MTtEQjZQUjA3MDFNQjI5OTk7MjM6SW5IeW0rbWV1clNkMFpXZ3BKRU9vTEFV?= =?utf-8?B?M21LTXdSQjRoL1orbHd5K2tHS05heHZ2L2JqNzEvU0xEZ1Z6c29BNzAySk00?= =?utf-8?B?VlR2QjRzNER2V1V0YmpGdERIN2VoZ1ZQdEhEMWRNQ09rM1lySmJRVGpMVndi?= =?utf-8?B?UEZZNmJpeWF3RkNSakNOUnYyeUxjejVxVHJ4MlVLRkJyN3V4TEplTlFrdDBt?= =?utf-8?B?NC93cnBpTzB2blFaTlBaelhvRllJeWNmclZhait6cEN2Q1FMYTZ3SzYrWDN3?= =?utf-8?B?eFVsaGJsRm8xYmZCVGE4RDVXZnpkUXp1N2NOYkpDd09aNnBhaEFtNDhIeE4z?= =?utf-8?B?c05QNm5TYmZLVGdnY1FzNEdhZTVTZFFHK3hRbUl6R0YvNmdFWUZTQjlXTERo?= =?utf-8?B?NVlVYWIrM2x3Q0R0eVZXcCtVZmtlakJtakhtWmNhUW5Ga2VWbVQyYUxneko4?= =?utf-8?B?Y1pmdStmZzVOblNzZUN4VHM4VCtzS0ZPaXhQWkhpczYwUi85TmJ4VUNjVmh3?= =?utf-8?B?ZDJzb0s2SHBZUnJsTEVKR0pjYUF6V0xPTjFVR09FbCtJL3UvUjVhSnhTY3Fq?= =?utf-8?B?YnBLQlBJV0hRM0x5RU51RGNBQVdZZ2hiNG84c0hlZXluWUUxb2RHRUVOU2xw?= =?utf-8?B?QzJRNmRJM0k2cUQ5WmxWdkVpdVZUUXJoSUNLQ1hxZHlrVTh0RzhZRVFqaDJO?= =?utf-8?B?cjlaeEFIR1gxRW1mcTRGQVJpRXhVcGxzbGpNSUJhRkJWK1M2eUY4NWxzejF2?= =?utf-8?B?MDBmUDVPUE5IUG1maW1SVHNCMnRhUUw1ZFl6b1l1c3FIL2R3MXRMclJ0Q1hX?= =?utf-8?B?dEpIYzdMUnZ6dFY1aUhNQ2lyRm9pRTh6VUQ3YXZWK3pFV0psbjVIcUdIVTdV?= =?utf-8?B?bTBuUnJVdGZHRGdEbjZ3NlJUamtrUE9JOXduMVZOTHJzdkZqOFltbUlaS0pJ?= =?utf-8?B?VjYrOVN4WVd5aEpTUzZNakNJdUp2V21ZWHVTeDdIRTM0c0JFMXU5Rnd2ZHoy?= =?utf-8?B?b2V1TE8rRXd3ZkRFelBzRSsvQ2Y1azlyT2gxS0U5MnNuc0xwb2FkeVQrNlVp?= =?utf-8?B?S3NBSFExSE9rVWhUenk1UkVTSitudTRTLzFSckswcFlDTzVWcTVmaGs0cFFj?= =?utf-8?B?MGk4a3VmaDZwaWp1d0w2ZStmejBBYmEzc29LcDRwN1hpemtzTUNrUmhQQWxS?= =?utf-8?B?di9SclBLbi9UVzAya0EyeE5BZWRlK2JWbkd0Z3ZpN3ppZ2dnd3R2MXdsS2Ey?= =?utf-8?B?M2NzQ3RsZTNsYk4yZGNmZ05Xb3RXRzQvU2dLZjNuQWVrL01FL0drK2liUjN1?= =?utf-8?B?SnlnZEVpOVlXTjlNR3h2Yi92aEVUS1ZKejAxVUdHT28vN1Y4MCtjMkx6QXV3?= =?utf-8?B?a20wOXgzRzhIQThsZFFUeEtiekFLZzFTcXBDR0U4bXYwRi9lVnE0aDhDNDJ2?= =?utf-8?B?WGdzZWNwbUZzak5GQ2gxZGxSeXh1R3VJYjJ5Z0NBVG5sQ3lRT2FTT2ozS0J1?= =?utf-8?B?STZ5MUlzK3dydDc5V0hXTVhpb09zVUE1Q0huL3hraGZGL1owY1ZtYkxPeU9Z?= =?utf-8?B?anVTNlFtc2gxcFJrUXVvVktVR1hManF4WXNEVFRtdnJKQ0FXbC9Bc0hOUVBr?= =?utf-8?B?RGp0SE5FZW02NDhGZ0NycUlyUEV2MldNdWZXRkg5T0NGSUpIZjM2ck11NGkw?= =?utf-8?B?MUhRb0FXUGNIazZWblE3UmxBRDFkb0hwa1p0WEZPeTBweWlwQytiR2lpNERl?= =?utf-8?B?NUpTS2k4eC9VRmdpMlpKTVBIWEQ0Z3NXUC80NENGM1A0RDNOckQ3V3F6UXBm?= =?utf-8?B?WWxIVDFsQjVKczgwQmJuZko1R0laS1JjTzNVNUo1cHdOaDYvdFdxa3IzYUdU?= =?utf-8?B?d1drbVk2RGxHNHRyMGVwR0JPdldKTWMwbFVqMWRqUGlxcnFFMkRRMlVSbnFy?= =?utf-8?B?ZTkyYUU3Y3BveEE9PQ==?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:W58WXOI1uzwbYhOyPi/ZiCWt3RBoH9YjVr9Tl9pfLsYgQVAbNS2DIlYRmZ4qBcI/CpLpfhwcI4PAMXNXsp1PDo5laFdtedZyVqV6YrP+gIq+tvqkW2ANMa6bdKz9bwLX7XHfZyFrMPOtewWx9FshQ5q70c9b2YYXctijPbs8iaaQUeAtUXFh4SFtvZnVwH64ZJJkbPIjnG9k4s5rPggkBMAt1K0YhQGJdwsuA8t4Wr8qZ17vD5NAT6ncswd3k9H3M/vpOLahZC4xfjFMHnpD0blDTaRWww8gYsTfuPW+oDe/0e2nXwUe4ra02PozMt8BUIU/cmvZZSsSekKW9UpY7A==; 5:lCuBHFJWXuD0vILPoQVsK0WN2Nci/eus2K6cW8PJD8O/v1gjkyk0DEm9Vf6mZBTDIq4zkBxhmuNddzsmXtZsQN0+/IHgFohGK30dDHfvR/a96lZ6j7UwftCN2P4oec8/brUD+veq++DvdfqeYSfohg==; 24:tsbnTmSqShHlq0FHStJDmXiH0XEUql+NwcGPqOp2zmvDvAZivaJ1PFqIitIAv7w84USiYEGRIVjApo7N3TVlWdVibYshNORnpUNegYDhnLk=; 7:B5HziRPCRkFH+FKHgy6r7cdAuFXn/DtBW7qXC6yHFRF4ETuS7Cgpy9N9+0RoV8bpQBxYqAH16XKh4Mu8EZDdo+F0bSTLBn6wHGyVuJlO+TCRj5lVPmFs30lE/MgzkSwf2IWHR6xaqHby21hCgDVC5B0rVEY1ERsj7tr3IAVQ5HYb4hap0FzlJOrx0bvvS1aqYdvQP6yiaEbvcndeydFWGL9qbAgW+vFeWj3B5fe7JMU=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2017 16:37:47.1890 (UTC)
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: Re: [netmod] handling module incompatibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 16:37:52 -0000

----- Original Message -----
From: "Lou Berger" 
Sent: Friday, October 06, 2017 2:25 PM

> As part of the my Routing Directorate review of
> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
> changes being made to the ietf-l3vpn-svc module without changing the
> name. I raised this with the YANG doctors and others involved with the
> draft and it surfaced some topics which really should be discussed
here
> in NetMod.
>
> The background (as explained off-list by others, so I hope I have it
> right) is that one of the YANG Doctors noted that RFC8049 was broken
> and could not be implemented as defined, and therefore a fix was
> needed. L3SM has concluded so the fix is in the individual draft
> draft-wu-l3sm-rfc8049bis. Since the rfc8049 version of ietf-l3vpn-svc
> module could not be implemented, the feeling by the YANG Dr was that
> even though the new module is incompatible with the original
definition
> the module the rule defined in Section 11 of YANG 1.1 (or section 10
of
> RFC 6020) didn't have to be followed and the same name could be used.
>
> In the subsequent discussion with the YANG Drs., the general
discussion
> was heading down the path of using a new module name, and thereby not
> violating YANG module update rules. This lead us back to the a similar
> discussion we've been having in the context of 8022bis: how best to
> indicate that a whole module is being obsoleted. RFCs do this by
adding
> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
> help YANG tooling. For 8022, we have one approach - publishing an
> updated rev of the original module marking all nodes as deprecated -
but
> that doesn't really make sense for rfc8049bis.
>
> So the discussion for the WG is:
>
> How do we handle incompatible module changes, notably when one module
> 'obsoletes' another module -- from both the process and tooling
> perspectives?

Add a new substatement to the module statement, 'obsoletes' or
'supersedes'or such like..

And I mean write the RFC now, do not wait for a future version or
revision of RFC7950.

Tom Petch

> I know Benoit plans to bring in some thoughts/proposals, perhaps there
> are others.
>
> Cheers,
>
> Lou
>
> (as contributor/reviewer)
>
>


From nobody Fri Oct  6 09:53:49 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0F2134A30; Fri,  6 Oct 2017 09:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id velxKUoDVmUP; Fri,  6 Oct 2017 09:53:45 -0700 (PDT)
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 C721D132403; Fri,  6 Oct 2017 09:53:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9D39218; Fri,  6 Oct 2017 18:53:43 +0200 (CEST)
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 qz_-1kr6duZU; Fri,  6 Oct 2017 18:53:40 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri,  6 Oct 2017 18:53:43 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58CA420108; Fri,  6 Oct 2017 18:53:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YN7jrnlkACCf; Fri,  6 Oct 2017 18:53:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B868620107; Fri,  6 Oct 2017 18:53:42 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8F0E04122D3C; Fri,  6 Oct 2017 18:53:42 +0200 (CEST)
Date: Fri, 6 Oct 2017 18:53:42 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Lou Berger , NetMod WG , rtg-dir@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
Message-ID: <20171006165342.syfqsjsdmr2tzgqg@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Lou Berger , NetMod WG , rtg-dir@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
References:  
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: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] handling module incompatibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 16:53:47 -0000

On Fri, Oct 06, 2017 at 03:49:50PM +0100, Robert Wilton wrote:
> Hi,
> 
> On 06/10/2017 14:25, Lou Berger wrote:
> > Hi,
> > 
> >      As part of the my Routing Directorate review of
> > draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
> > changes being made to the ietf-l3vpn-svc module without changing the
> > name.  I raised this with the YANG doctors and others involved with the
> > draft and it surfaced some topics which really should be discussed here
> > in NetMod.
> > 
> > The background (as explained off-list by others, so I hope I have it
> > right)  is that one of the YANG Doctors noted that RFC8049 was broken
> > and could not be implemented as defined, and therefore a fix was
> > needed.  L3SM has concluded so the fix is in the individual draft
> > draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
> > module could not be implemented, the feeling by the YANG Dr was that
> > even though the new module is incompatible with the original definition
> > the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
> > RFC 6020) didn't have to be followed and the same name could be used.
> 
> I think that this is the view that I support as well.  If something is
> clearly broken then it should be possible to fix it without requiring a new
> module name, just an updated revision.
>

The hidden question is what is 'broken' or 'clearly broken' and when
are definitions in a module broken and when is the damage so big that
the whole module is broken. Does a broken xpath statement cause the
whole module to be fundamentally flawed such that an implementation of
the rest is impossible?

It is not uncommon to find errors in data models and it is then often
a matter of a new revision or errata to address those. The question
here is when is an entire module broken up to the point that nobody
ever will have implemented it or parts of it.

I do not know the answer but I see a certain risk that minor bugs will
be used to argue none of the YANG update rules apply.

/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 Oct  6 14:12:02 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE24013239C; Fri,  6 Oct 2017 14:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBX8KHdKPMLO; Fri,  6 Oct 2017 14:11:59 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0343D1320C9; Fri,  6 Oct 2017 14:11:58 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id d17so21701502lfe.2; Fri, 06 Oct 2017 14:11:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=eAmU8px+TdU1tOOqEXrguF2GKhJJ6dLH1M+iWwnv79I=; b=IaELiB8aKhrZwJQRT9d6ohTItSMGGuwwSsuFPF2kVCjpoNikh4P02Vtz06Twg/29bh LM/o7a+1Kuc3yOrSBQZbQmalJiXbawIW7M25GnNos91lcSYLA9azE4KkHIJx/paGtuOF vBuwF4P39Ai164b92uo+tbRrjB+5J+Tqn0pGgy6MO/FQkzpjFVQlcJhuQUfF0PU+qcL4 UYYKyQuZZIkTefKC8C7IeWzMYnlGzDfs8ll34AtwV8YviDpzkSSAZqo5DBqB5ea0LUvP +GP4ehZ7OzJpZcDIWQZk/mCIiwVatfLhkqPKUpM/KeBnxf/VUsGQzVJ2oV7vJyDeANls zjfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=eAmU8px+TdU1tOOqEXrguF2GKhJJ6dLH1M+iWwnv79I=; b=RBNUWR/3zLR5OMHEIyyQp8fUorv5OI1HvTsfJNgJaohpEDzxvYNTq6Hp386QsVWLKd MnBxhCBJ5UjdNpiuF1oPdwceCkRhPhIoHRCcLkpn8dZlUjUUTWNgLoCsc0LaxlN+su1i ITrmNpDeK51dd/GCNhzPMye44H3dBFub56uLcxHTBDIf/ZVeZSJJ4E/QT495EkI+LVXf bK4+grWGSaMfMjFa0L7J4nAhIVND1Tf1137NXYXE8SYZmrmDlSJOkLfFIXvcvGS8d1pw fTW6HGWnH2zCRgVUDxqoq7Aq7Mx59+FTW2PBWKa8AvCyO8s94LTyCB/sOMrSIe3Y3vWC subQ==
X-Gm-Message-State: AMCzsaUCgeYWMojvQCfTQP4azoDD4/ZfhSRD/asKLjHHRsn8+GcboFKy M9xxZxTjy1l/NNNNlB28bDnb+ay9
X-Google-Smtp-Source: AOwi7QAZG3layFA11LPAuOmP4p+JkMBDaw+cazWloT5UPtq0AZFdhr6yhfQtGCtIzKJVf+UIXPJ/RA==
X-Received: by 10.25.210.211 with SMTP id j202mr1398100lfg.8.1507324316538; Fri, 06 Oct 2017 14:11:56 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id l14sm425137lfb.7.2017.10.06.14.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Oct 2017 14:11:55 -0700 (PDT)
From: "Xufeng Liu" 
To: , "'NetMod WG'" 
Date: Fri, 6 Oct 2017 17:11:52 -0400
Message-ID: <033601d33ee7$bd359810$37a0c830$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0337_01D33EC6.3624BB60"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/g==
Content-Language: en-us
Archived-At: 
Subject: [netmod] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 21:12:01 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0337_01D33EC6.3624BB60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

During the design team discussion for TE and MPLS YANG modeling, we have
received a request from implementers: How to minimize the number of
NETCONF/RESTCONF RPCs to improve operation efficiency? Especially for the
case when the operator or client software needs to retrieve the object
contents pointed by a leafref.

For example, given the following simplified TE tunnel model,

+--rw te

    +--rw explicit-paths

    |  +--rw explicit-path* [name]

    |     +--rw name                      string

    |        +--rw explicit-route-object* [index]

    |           +--rw index                   uint32

    |           +--rw explicit-route-usage?   identityref

    +--rw tunnels

    |  +--rw tunnel* [name]

    |  |  +--rw name                   string

    |  |  +--rw paths

    |  |  |  +--rw path* [name]

|  |  |     +--rw explicit-path?  ->
../../../../../explicit-paths/explicit-path/name

 

when the client tries to retrieve a tunnel's information based on the tunnel
name, the "get" operation returns a list of leafref's pointing to the paths
of the tunnel. The client needs to issue at least one more "get" operation
to retrieve the path information about the given tunnel. The request is to
combine these two operations into one.

In the RDBMS SQL world, "join" can be used when SQL "select" is performed,
but NETCONF/YANG currently does not have this capability.

We'd like to ask whether such a request is considered reasonable.

If the request is reasonable, the next question is how to proceed. This
seems to be a protocol issue rather than YANG modeling issue. Is it
acceptable to add a new operation to achieve such a  operation
with expanded leafref's?

Comments and suggestions are appreciated.

Thanks,

- Xufeng

 


------=_NextPart_000_0337_01D33EC6.3624BB60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


During the design team discussion for TE and MPLS YANG =
modeling, we have received a request from implementers: How to minimize =
the number of NETCONF/RESTCONF RPCs to improve operation efficiency? =
Especially for the case when the operator or client software needs to =
retrieve the object contents pointed by a leafref.
For example, given the following simplified TE tunnel =
model,
+--rw te
    +--rw explicit-paths
    |  +--rw explicit-path* =
[name]
    =
|     +--rw =
name         =
            &=
nbsp;string
    =
|        +--rw explicit-route-object* =
[index]
    =
|           +--rw =
index           &n=
bsp;       uint32
    =
|           +--rw =
explicit-route-usage?   identityref
    +--rw tunnels
    |  +--rw tunnel* =
[name]
    |  |  =
+--rw name         =
          string
    |  |  +--rw =
paths
    |  |  =
|  +--rw path* [name]
|  |  |     =
+--rw explicit-path?  -> =
../../../../../explicit-paths/explicit-path/name
 
when the =
client tries to retrieve a tunnel’s information based on the =
tunnel name, the “get” operation returns a list of =
leafref’s pointing to the paths of the tunnel. The client needs to =
issue at least one more “get” operation to retrieve the path =
information about the given tunnel. The request is to combine these two =
operations into one.
In the RDBMS SQL =
world, “join” can be used when SQL “select” is =
performed, but NETCONF/YANG currently does not have this =
capability.
We’d like to ask =
whether such a request is considered reasonable.
If the request is reasonable, the next question is how =
to proceed. This seems to be a protocol issue rather than YANG modeling =
issue. Is it acceptable to add a new operation to achieve such a =
<get-data> operation with expanded =
leafref’s?
Comments and =
suggestions are appreciated.
Thanks,
- =
Xufeng
 

------=_NextPart_000_0337_01D33EC6.3624BB60--


From nobody Fri Oct  6 14:51:33 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE1513239C; Fri,  6 Oct 2017 14:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 jdJDIhDsMtR8; Fri,  6 Oct 2017 14:51:29 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A70C124F57; Fri,  6 Oct 2017 14:51:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0LFV3z6TsVJNBadER+j/hu1r1GK8L5mDxFGEDdXuL48=; b=C6MUoGq8M6BvkPaQcGRyMgMzC0sNNboH+zS/dPtW7F7JwXhZL9mAqSg4D9gLl34coL0ZYuLtsL0VLBZ2fWYYk/4Ag6AFu1QkckX31ZLOU4jTxFQte9jIBQ8zJXN4VE7fjjAyFAu6lfkNT+l/Oklg922Ym/7S1Mp850cD9YOW5tU=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 6 Oct 2017 21:51:27 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.026; Fri, 6 Oct 2017 21:51:27 +0000
From: Kent Watsen 
To: Xufeng Liu , "netconf@ietf.org" , 'NetMod WG' 
Thread-Topic: [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/v//yKSA
Date: Fri, 6 Oct 2017 21:51:27 +0000
Message-ID: <277614BE-7ECA-409C-B817-83464860CE05@juniper.net>
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>
In-Reply-To: <033601d33ee7$bd359810$37a0c830$@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.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:T6GSmLc4Y1KgNBhMjcv+MueWDBB78k+AKk4uv0KMzcagHvUQ/EhvUwaBV2ZDM3ig5yBlgA7XwV+pFoUbVayvaDZ/6/6wJ+5syV3WXLEP5ZnNUBCCK53rxXKSiHV3xxEJowc2PQmNUS9p7QdniTya4Dvf+1cncZHO16V03eYhavYdtPWTA1oGi1/ssM0MukC2+fY41UsqT71aKmtqGbkxNSmZKqIxyzcj5qDAc0MX6TlNnEgUoIfhiPCbDEhir3v9nR/z0qDGoxHp73QlywIiw8P6MsnRPn62DR9rbgEbQ9cLe+bsi338O/7/+pvmP8Q6Z4GYvgp1nA5mnUR3fOISDA==; 5:gn1qioeD0qVj0k09NcVpDHj6P3daFAZu8TG51BEk1Bs2KmtAEVAU4pN6R8q037/MICyk8WIZNTnsPcKCSYrQfOYGZ8mrRkPsLoee5pmyMmcc+INPaJCrRIAj09gP+1oN+wJbVkDyu/2d0TWXpaR2Fg==; 24:jOz6u8NMG596nyNe6W/K7M3bYmMdOpYMh3X8c30hexdNAkngZUTB91HOP2Efnu9froxU6jWcUS1MElS+x0tkyKyA7KzGKt+Lx8wViQvIIZM=; 7:s8yfRJE6+5Q/jfNmrCm/7/J7vW7JrS7AU/28Mg81AZrynkSpA9/pGj7+z5qN/Ynn8HGNI3GUPrxeudpt4/k4G7JoUq8rGrAd9rADlARhgyiRwLNv6zH9sHIHthu4TOdVgYcacaNvVknxmI8IN5tjn/GuzT46F61asv40upqyEnnpQ2HbsRy2ab9w7iZrPiJCH+aQWrRIYawFqoS/uq07pOkPfW2WcHAaXKdw3pNuLZk=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: dfc2d85f-a71b-434a-377c-08d50d04657a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB273; 
x-ms-traffictypediagnostic: BLUPR05MB273:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(12181511122)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB273; 
x-forefront-prvs: 0452022BE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(377454003)(199003)(24454002)(189002)(101416001)(6246003)(86362001)(105586002)(82746002)(66066001)(83506001)(14454004)(106356001)(39060400002)(110136005)(33656002)(58126008)(3280700002)(2950100002)(3660700001)(68736007)(2501003)(83716003)(316002)(36756003)(5660300001)(189998001)(7736002)(6436002)(6506006)(2900100001)(6116002)(478600001)(3846002)(102836003)(25786009)(50986999)(76176999)(54356999)(2906002)(236005)(53936002)(6306002)(99286003)(54896002)(97736004)(8676002)(6512007)(77096006)(6486002)(229853002)(8936002)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_277614BE7ECA409CB81783464860CE05junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 21:51:27.5081 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273
Archived-At: 
Subject: Re: [netmod] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 21:51:31 -0000

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

DQpNeSBleHBlcmllbmNlIGlzIHRoYXQgY2xpZW50cyBnZXQgdGhlIGVudGlyZSBjb25maWcgaW4g
b25lIGNhbGwsIGFuZCB0aGVuIGNhbiBwZXJmb3JtIHN1Y2ggcmVzb2x1dGlvbnMgbG9jYWxseS4N
Cg0KQlRXLCByZWFsbHkgbG9uZyByZWxhdGl2ZSBwYXRocyBhcmUgaGFyZGVyIHRvIHJlYWQgdGhh
biBhbiBhYnNvbHV0aW9uIHBhdGguDQouLi8uLi8uLi8uLi8uLi9leHBsaWNpdC1wYXRocy9leHBs
aWNpdC1wYXRoL25hbWUNCk9uIDEwLzYvMTcsIDU6MTEgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9m
IFh1ZmVuZyBMaXUiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiB4dWZlbmcubGl1LmlldGZAZ21haWwuY29tPG1haWx0
bzp4dWZlbmcubGl1LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkR1cmluZyB0aGUgZGVzaWdu
IHRlYW0gZGlzY3Vzc2lvbiBmb3IgVEUgYW5kIE1QTFMgWUFORyBtb2RlbGluZywgd2UgaGF2ZSBy
ZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSBpbXBsZW1lbnRlcnM6IEhvdyB0byBtaW5pbWl6ZSB0aGUg
bnVtYmVyIG9mIE5FVENPTkYvUkVTVENPTkYgUlBDcyB0byBpbXByb3ZlIG9wZXJhdGlvbiBlZmZp
Y2llbmN5PyBFc3BlY2lhbGx5IGZvciB0aGUgY2FzZSB3aGVuIHRoZSBvcGVyYXRvciBvciBjbGll
bnQgc29mdHdhcmUgbmVlZHMgdG8gcmV0cmlldmUgdGhlIG9iamVjdCBjb250ZW50cyBwb2ludGVk
IGJ5IGEgbGVhZnJlZi4NCkZvciBleGFtcGxlLCBnaXZlbiB0aGUgZm9sbG93aW5nIHNpbXBsaWZp
ZWQgVEUgdHVubmVsIG1vZGVsLA0KDQorLS1ydyB0ZQ0KDQogICAgKy0tcncgZXhwbGljaXQtcGF0
aHMNCg0KICAgIHwgICstLXJ3IGV4cGxpY2l0LXBhdGgqIFtuYW1lXQ0KDQogICAgfCAgICAgKy0t
cncgbmFtZSAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCg0KICAgIHwgICAgICAgICstLXJ3
IGV4cGxpY2l0LXJvdXRlLW9iamVjdCogW2luZGV4XQ0KDQogICAgfCAgICAgICAgICAgKy0tcncg
aW5kZXggICAgICAgICAgICAgICAgICAgdWludDMyDQoNCiAgICB8ICAgICAgICAgICArLS1ydyBl
eHBsaWNpdC1yb3V0ZS11c2FnZT8gICBpZGVudGl0eXJlZg0KDQogICAgKy0tcncgdHVubmVscw0K
DQogICAgfCAgKy0tcncgdHVubmVsKiBbbmFtZV0NCg0KICAgIHwgIHwgICstLXJ3IG5hbWUgICAg
ICAgICAgICAgICAgICAgc3RyaW5nDQoNCiAgICB8ICB8ICArLS1ydyBwYXRocw0KDQogICAgfCAg
fCAgfCAgKy0tcncgcGF0aCogW25hbWVdDQoNCnwgIHwgIHwgICAgICstLXJ3IGV4cGxpY2l0LXBh
dGg/ICAtPiAuLi8uLi8uLi8uLi8uLi9leHBsaWNpdC1wYXRocy9leHBsaWNpdC1wYXRoL25hbWUN
Cg0Kd2hlbiB0aGUgY2xpZW50IHRyaWVzIHRvIHJldHJpZXZlIGEgdHVubmVs4oCZcyBpbmZvcm1h
dGlvbiBiYXNlZCBvbiB0aGUgdHVubmVsIG5hbWUsIHRoZSDigJxnZXTigJ0gb3BlcmF0aW9uIHJl
dHVybnMgYSBsaXN0IG9mIGxlYWZyZWbigJlzIHBvaW50aW5nIHRvIHRoZSBwYXRocyBvZiB0aGUg
dHVubmVsLiBUaGUgY2xpZW50IG5lZWRzIHRvIGlzc3VlIGF0IGxlYXN0IG9uZSBtb3JlIOKAnGdl
dOKAnSBvcGVyYXRpb24gdG8gcmV0cmlldmUgdGhlIHBhdGggaW5mb3JtYXRpb24gYWJvdXQgdGhl
IGdpdmVuIHR1bm5lbC4gVGhlIHJlcXVlc3QgaXMgdG8gY29tYmluZSB0aGVzZSB0d28gb3BlcmF0
aW9ucyBpbnRvIG9uZS4NCkluIHRoZSBSREJNUyBTUUwgd29ybGQsIOKAnGpvaW7igJ0gY2FuIGJl
IHVzZWQgd2hlbiBTUUwg4oCcc2VsZWN04oCdIGlzIHBlcmZvcm1lZCwgYnV0IE5FVENPTkYvWUFO
RyBjdXJyZW50bHkgZG9lcyBub3QgaGF2ZSB0aGlzIGNhcGFiaWxpdHkuDQpXZeKAmWQgbGlrZSB0
byBhc2sgd2hldGhlciBzdWNoIGEgcmVxdWVzdCBpcyBjb25zaWRlcmVkIHJlYXNvbmFibGUuDQpJ
ZiB0aGUgcmVxdWVzdCBpcyByZWFzb25hYmxlLCB0aGUgbmV4dCBxdWVzdGlvbiBpcyBob3cgdG8g
cHJvY2VlZC4gVGhpcyBzZWVtcyB0byBiZSBhIHByb3RvY29sIGlzc3VlIHJhdGhlciB0aGFuIFlB
TkcgbW9kZWxpbmcgaXNzdWUuIElzIGl0IGFjY2VwdGFibGUgdG8gYWRkIGEgbmV3IG9wZXJhdGlv
biB0byBhY2hpZXZlIHN1Y2ggYSA8Z2V0LWRhdGE+IG9wZXJhdGlvbiB3aXRoIGV4cGFuZGVkIGxl
YWZyZWbigJlzPw0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBhcHByZWNpYXRlZC4NClRo
YW5rcywNCi0gWHVmZW5nDQoNCg==

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE
ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K
CXttYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206OC4w
cHQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWxpbmUtaGVpZ2h0OjEwNSU7DQoJZm9udC1zaXplOjEx
LjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQpwLk1zb05vU3BhY2luZywgbGkuTXNvTm9TcGFjaW5nLCBkaXYuTXNvTm9T
cGFjaW5nDQoJe21zby1zdHlsZS1wcmlvcml0eToxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9
DQpwLkNvZGUsIGxpLkNvZGUsIGRpdi5Db2RlDQoJe21zby1zdHlsZS1uYW1lOkNvZGU7DQoJbWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm
b250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K
c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u
dC1mYW1pbHk6Q2FsaWJyaTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29s
b3I6d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpu
b25lIG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z
dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx
LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMw
NTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdo
dDoxMDUlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlIj5NeSBleHBl
cmllbmNlIGlzIHRoYXQgY2xpZW50cyBnZXQgdGhlIGVudGlyZSBjb25maWcgaW4gb25lIGNhbGws
IGFuZCB0aGVuIGNhbiBwZXJmb3JtIHN1Y2ggcmVzb2x1dGlvbnMgbG9jYWxseS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdDtsaW5lLWhlaWdodDoxMDUlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhl
aWdodDoxMDUlIj5CVFcsIHJlYWxseSBsb25nIHJlbGF0aXZlIHBhdGhzIGFyZSBoYXJkZXIgdG8g
cmVhZCB0aGFuIGFuIGFic29sdXRpb24gcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtsaW5lLWhlaWdo
dDoxMDUlIj4uLi8uLi8uLi8uLi8uLi9leHBsaWNpdC1wYXRocy9leHBsaWNpdC1wYXRoL25hbWU8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIDEwLzYvMTcsIDU6MTEgUE0sICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgWHVmZW5nIExp
dSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRt
b2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86eHVm
ZW5nLmxpdS5pZXRmQGdtYWlsLmNvbSI+eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2xpbmUtaGVpZ2h0OjEwNSUiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkR1cmluZyB0aGUgZGVzaWduIHRlYW0gZGlzY3Vzc2lvbiBmb3IgVEUgYW5kIE1QTFMgWUFO
RyBtb2RlbGluZywgd2UgaGF2ZSByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSBpbXBsZW1lbnRlcnM6
IEhvdyB0byBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9mIE5FVENPTkYvUkVTVENPTkYgUlBDcyB0byBp
bXByb3ZlIG9wZXJhdGlvbiBlZmZpY2llbmN5PyBFc3BlY2lhbGx5IGZvciB0aGUgY2FzZSB3aGVu
IHRoZSBvcGVyYXRvcg0KIG9yIGNsaWVudCBzb2Z0d2FyZSBuZWVkcyB0byByZXRyaWV2ZSB0aGUg
b2JqZWN0IGNvbnRlbnRzIHBvaW50ZWQgYnkgYSBsZWFmcmVmLjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIGdpdmVuIHRoZSBmb2xsb3dpbmcgc2ltcGxp
ZmllZCBURSB0dW5uZWwgbW9kZWwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iQ29kZSI+JiM0
MzstLXJ3IHRlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iQ29kZSI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICYjNDM7LS1ydyBleHBsaWNpdC1wYXRoczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9IkNv
ZGUiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBleHBsaWNpdC1wYXRoKiBb
bmFtZV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJDb2RlIj4mbmJzcDsmbmJzcDsmbmJzcDsg
fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbmFtZSZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdHJp
bmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJDb2RlIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgZXhwbGlj
aXQtcm91dGUtb2JqZWN0KiBbaW5kZXhdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iQ29kZSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGluZGV4Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQzMjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9IkNvZGUiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBleHBsaWNp
dC1yb3V0ZS11c2FnZT8mbmJzcDsmbmJzcDsgaWRlbnRpdHlyZWY8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJDb2RlIj4mbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHR1bm5lbHM8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJDb2RlIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQz
Oy0tcncgdHVubmVsKiBbbmFtZV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJDb2RlIj4mbmJz
cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBuYW1lJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N0cmluZzxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9IkNvZGUiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsg
JiM0MzstLXJ3IHBhdGhzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iQ29kZSI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwYXRoKiBbbmFtZV08
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJDb2RlIiBzdHlsZT0idGV4dC1pbmRlbnQ6MjQuMHB0
Ij58Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgZXhw
bGljaXQtcGF0aD8mbmJzcDsgLSZndDsgLi4vLi4vLi4vLi4vLi4vZXhwbGljaXQtcGF0aHMvZXhw
bGljaXQtcGF0aC9uYW1lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoZW4gdGhlIGNsaWVudCB0
cmllcyB0byByZXRyaWV2ZSBhIHR1bm5lbOKAmXMgaW5mb3JtYXRpb24gYmFzZWQgb24gdGhlIHR1
bm5lbCBuYW1lLCB0aGUg4oCcZ2V04oCdIG9wZXJhdGlvbiByZXR1cm5zIGEgbGlzdCBvZiBsZWFm
cmVm4oCZcyBwb2ludGluZyB0byB0aGUgcGF0aHMgb2YgdGhlIHR1bm5lbC4gVGhlIGNsaWVudCBu
ZWVkcyB0byBpc3N1ZSBhdCBsZWFzdCBvbmUgbW9yZSDigJxnZXTigJ0gb3BlcmF0aW9uIHRvIHJl
dHJpZXZlDQogdGhlIHBhdGggaW5mb3JtYXRpb24gYWJvdXQgdGhlIGdpdmVuIHR1bm5lbC4gVGhl
IHJlcXVlc3QgaXMgdG8gY29tYmluZSB0aGVzZSB0d28gb3BlcmF0aW9ucyBpbnRvIG9uZS48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBSREJNUyBTUUwgd29ybGQs
IOKAnGpvaW7igJ0gY2FuIGJlIHVzZWQgd2hlbiBTUUwg4oCcc2VsZWN04oCdIGlzIHBlcmZvcm1l
ZCwgYnV0IE5FVENPTkYvWUFORyBjdXJyZW50bHkgZG9lcyBub3QgaGF2ZSB0aGlzIGNhcGFiaWxp
dHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZeKAmWQgbGlrZSB0byBh
c2sgd2hldGhlciBzdWNoIGEgcmVxdWVzdCBpcyBjb25zaWRlcmVkIHJlYXNvbmFibGUuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgcmVxdWVzdCBpcyByZWFzb25h
YmxlLCB0aGUgbmV4dCBxdWVzdGlvbiBpcyBob3cgdG8gcHJvY2VlZC4gVGhpcyBzZWVtcyB0byBi
ZSBhIHByb3RvY29sIGlzc3VlIHJhdGhlciB0aGFuIFlBTkcgbW9kZWxpbmcgaXNzdWUuIElzIGl0
IGFjY2VwdGFibGUgdG8gYWRkIGEgbmV3IG9wZXJhdGlvbiB0byBhY2hpZXZlIHN1Y2ggYSAmbHQ7
Z2V0LWRhdGEmZ3Q7IG9wZXJhdGlvbiB3aXRoIGV4cGFuZGVkIGxlYWZyZWbigJlzPzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFy
ZSBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r
cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gWHVmZW5nPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_277614BE7ECA409CB81783464860CE05junipernet_--


From nobody Fri Oct  6 14:57:44 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F9133090; Fri,  6 Oct 2017 14:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 uf6aXb2b0sMz; Fri,  6 Oct 2017 14:57:40 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0105.outbound.protection.outlook.com [104.47.42.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86D713239C; Fri,  6 Oct 2017 14:57:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cPok1KRDHSJkgqYKXwslqDQglP22TwAULRyG/MbVLiU=; b=DC5Xg8wEE4zoPApOTQaWxvVlprURUb3DTrDPCaerhB986q7b/7MhNnrpi+DGwIkZ80KGj5fZG3BFUhKBW3zKkRwY3CahuL2oiaoSJnmYWgluFY01/D7PFRKdiRdQMCVEyLSO+TeSdnef1wAnTBu5lKmA98iyZtzEvPdzV7f1a6E=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB273.namprd05.prod.outlook.com (10.141.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 6 Oct 2017 21:57:38 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.026; Fri, 6 Oct 2017 21:57:38 +0000
From: Kent Watsen 
To: Xufeng Liu , "netconf@ietf.org" , 'NetMod WG' 
Thread-Topic: [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/v//yKSAgAABvQA=
Date: Fri, 6 Oct 2017 21:57:38 +0000
Message-ID: 
References: <033601d33ee7$bd359810$37a0c830$@gmail.com> <277614BE-7ECA-409C-B817-83464860CE05@juniper.net>
In-Reply-To: <277614BE-7ECA-409C-B817-83464860CE05@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.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:67R7Yt4FxHgdVZCl2vKYTWJDBHgkFByMoPAOgevaI0Qud83gPn3V7QaiDffND3PoMfLyhbpUDQ5Yn0PMGXQqerzm3rvJwgB3xattlBzu3UUUmOrmkAkKQtriF4T20JLvEHzDQShDc9ASeYjU1Braun/m6yusFJ8yn2gvGS3vDiXIV5Ikj9FDFlSO2VPVw68XUuejy2+cQPqqsPzrFn8CnfFJXrLaFjq13AbGiznWffSVZV0fPQio/31N1ooyxUBxStmyVhYlD5VJnuSVC+fW7wMLKY6j7zu4xklSWEAzZCYgiiEiO/VKACFKVLlfGzwox5feF0taa/uV4rkcXWLT1A==; 5:+ZEUSRwWilFRR9aPO3eH6b89j16tC18JXJ7wUxrS7O4vGHShO/hsQgKgdy9ppZivO9Vi29NYwfmKuc9jYgb97cENqd7E31hIlr0lPqsbcr11o8piSrUqpqRgYghlQUNKTPl8m6IvCtwx14CzqYz/5g==; 24:Iig1m1tc/IxWlpX9kSgrm7VwlXKvq6j+D1ipu11tDC73fXgYOePjANzWx0I0p0WsL6vuaOo+P0Cbq60NCU/782hygTuAdGQZbSHq5OBDwH0=; 7:1PecZBqiEB3u4Ev2JD0dYxiWixFCJ3UjtnN2PjzCMNPhyV6D9yJGv9EjwUh/C4loWO8a3Ws76QN0nRrCto6riAHdKAifSD59fipFuBgXUCIVhiu+Wr5AQKIMrdse8OP4hL2PK5ulq5S9q29S9mwMP+6dMnZePCDALjzABEDPJDuXgfx+xE7sKKROykNK4YczJ9zuUEiyIKWBOiXjsDaSF9DjGsXsTUjPhSR34jHepnA=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 695df127-03a6-48c8-53b0-08d50d0542c6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB273; 
x-ms-traffictypediagnostic: BLUPR05MB273:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(12181511122)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB273; 
x-forefront-prvs: 0452022BE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(377454003)(199003)(24454002)(189002)(101416001)(6246003)(86362001)(105586002)(82746002)(53546010)(66066001)(83506001)(14454004)(106356001)(39060400002)(110136005)(33656002)(58126008)(3280700002)(2950100002)(3660700001)(68736007)(2501003)(83716003)(316002)(36756003)(5660300001)(189998001)(7736002)(6436002)(6506006)(2900100001)(6116002)(478600001)(305945005)(3846002)(102836003)(25786009)(50986999)(76176999)(54356999)(2906002)(53936002)(99286003)(97736004)(8676002)(6512007)(77096006)(6486002)(229853002)(8936002)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB273; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <927BF3AE8C95244094D04DCE9EC665F0@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 21:57:38.7678 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273
Archived-At: 
Subject: Re: [netmod] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 06 Oct 2017 21:57:42 -0000

W1NvcnJ5LCBmYXQtZmluZ2VyZWQgdGhlIHNlbmQgYnV0dG9uXQ0KDQpIZXJlJ3MgaG93IHRoZSBw
YXRocyBtaWdodCBiZSBhbHRlcmVkOg0KLSAgLi4vLi4vLi4vLi4vLi4vZXhwbGljaXQtcGF0aHMv
ZXhwbGljaXQtcGF0aC9uYW1lDQorIC9leHBsaWNpdC1wYXRocy9leHBsaWNpdC1wYXRoL25hbWUN
Cg0KQmFjayB0byB5b3VyIHF1ZXN0aW9uLCBJIGd1ZXNzIHRoYXQgc29tZXRoaW5nIGNvdWxkIGJl
IGRvbmUsIGJ1dCBJJ20gdW5zdXJlIGlmIGhvdyBpbXBvcnRhbnQgaXQgd291bGQgYmUgcmVsYXRp
dmUgdG8gb3RoZXIgd29yayBnb2luZyBvbiBpbiB0aGUgTkVUQ09ORiBXRy4gIEl0IHdpbGwgYmUg
aW50ZXJlc3RpbmcgdG8gc2VlIHdoYXQgb3RoZXIgb3BpbmlvbnMgYXJlLg0KDQpLLiAvLyBjb250
cmlidXRvcg0KDQoNCg0KDQpPbiAxMC82LzE3LCA1OjExIFBNLCAibmV0bW9kIG9uIGJlaGFsZiBv
ZiBYdWZlbmcgTGl1IiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHh1ZmVu
Zy5saXUuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KwqANCkR1cmluZyB0aGUgZGVzaWduIHRlYW0g
ZGlzY3Vzc2lvbiBmb3IgVEUgYW5kIE1QTFMgWUFORyBtb2RlbGluZywgd2UgaGF2ZSByZWNlaXZl
ZCBhIHJlcXVlc3QgZnJvbSBpbXBsZW1lbnRlcnM6IEhvdyB0byBtaW5pbWl6ZSB0aGUgbnVtYmVy
IG9mIE5FVENPTkYvUkVTVENPTkYgUlBDcyB0byBpbXByb3ZlIG9wZXJhdGlvbiBlZmZpY2llbmN5
PyBFc3BlY2lhbGx5IGZvciB0aGUgY2FzZSB3aGVuIHRoZSBvcGVyYXRvciBvciBjbGllbnQgc29m
dHdhcmUgbmVlZHMgdG8gcmV0cmlldmUgdGhlIG9iamVjdCBjb250ZW50cyBwb2ludGVkIGJ5IGEg
bGVhZnJlZi4NCkZvciBleGFtcGxlLCBnaXZlbiB0aGUgZm9sbG93aW5nIHNpbXBsaWZpZWQgVEUg
dHVubmVsIG1vZGVsLA0KKy0tcncgdGUNCsKgwqDCoCArLS1ydyBleHBsaWNpdC1wYXRocw0KwqDC
oMKgIHzCoCArLS1ydyBleHBsaWNpdC1wYXRoKiBbbmFtZV0NCsKgwqDCoCB8wqDCoMKgwqAgKy0t
cncgbmFtZcKgwqDCoMKgwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBzdHJpbmcN
CsKgwqDCoCB8wqDCoMKgwqDCoMKgwqAgKy0tcncgZXhwbGljaXQtcm91dGUtb2JqZWN0KiBbaW5k
ZXhdDQrCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJ3IGluZGV4wqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHVpbnQzMg0KwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKg
wqDCoCArLS1ydyBleHBsaWNpdC1yb3V0ZS11c2FnZT/CoMKgIGlkZW50aXR5cmVmDQrCoMKgwqAg
Ky0tcncgdHVubmVscw0KwqDCoMKgIHzCoCArLS1ydyB0dW5uZWwqIFtuYW1lXQ0KwqDCoMKgIHzC
oCB8wqAgKy0tcncgbmFtZcKgwqDCoMKgwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqBzdHJp
bmcNCsKgwqDCoCB8wqAgfMKgICstLXJ3IHBhdGhzDQrCoMKgwqAgfMKgIHzCoCB8wqAgKy0tcncg
cGF0aCogW25hbWVdDQogICAgfMKgIHzCoCB8wqDCoMKgwqAgKy0tcncgZXhwbGljaXQtcGF0aD/C
oCAtPiAuLi8uLi8uLi8uLi8uLi9leHBsaWNpdC1wYXRocy9leHBsaWNpdC1wYXRoL25hbWUNCsKg
DQp3aGVuIHRoZSBjbGllbnQgdHJpZXMgdG8gcmV0cmlldmUgYSB0dW5uZWzigJlzIGluZm9ybWF0
aW9uIGJhc2VkIG9uIHRoZSB0dW5uZWwgbmFtZSwgdGhlIOKAnGdldOKAnSBvcGVyYXRpb24gcmV0
dXJucyBhIGxpc3Qgb2YgbGVhZnJlZuKAmXMgcG9pbnRpbmcgdG8gdGhlIHBhdGhzIG9mIHRoZSB0
dW5uZWwuIFRoZSBjbGllbnQgbmVlZHMgdG8gaXNzdWUgYXQgbGVhc3Qgb25lIG1vcmUg4oCcZ2V0
4oCdIG9wZXJhdGlvbiB0byByZXRyaWV2ZSB0aGUgcGF0aCBpbmZvcm1hdGlvbiBhYm91dCB0aGUg
Z2l2ZW4gdHVubmVsLiBUaGUgcmVxdWVzdCBpcyB0byBjb21iaW5lIHRoZXNlIHR3byBvcGVyYXRp
b25zIGludG8gb25lLg0KSW4gdGhlIFJEQk1TIFNRTCB3b3JsZCwg4oCcam9pbuKAnSBjYW4gYmUg
dXNlZCB3aGVuIFNRTCDigJxzZWxlY3TigJ0gaXMgcGVyZm9ybWVkLCBidXQgTkVUQ09ORi9ZQU5H
IGN1cnJlbnRseSBkb2VzIG5vdCBoYXZlIHRoaXMgY2FwYWJpbGl0eS4NCldl4oCZZCBsaWtlIHRv
IGFzayB3aGV0aGVyIHN1Y2ggYSByZXF1ZXN0IGlzIGNvbnNpZGVyZWQgcmVhc29uYWJsZS4NCklm
IHRoZSByZXF1ZXN0IGlzIHJlYXNvbmFibGUsIHRoZSBuZXh0IHF1ZXN0aW9uIGlzIGhvdyB0byBw
cm9jZWVkLiBUaGlzIHNlZW1zIHRvIGJlIGEgcHJvdG9jb2wgaXNzdWUgcmF0aGVyIHRoYW4gWUFO
RyBtb2RlbGluZyBpc3N1ZS4gSXMgaXQgYWNjZXB0YWJsZSB0byBhZGQgYSBuZXcgb3BlcmF0aW9u
IHRvIGFjaGlldmUgc3VjaCBhIDxnZXQtZGF0YT4gb3BlcmF0aW9uIHdpdGggZXhwYW5kZWQgbGVh
ZnJlZuKAmXM/DQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIGFwcHJlY2lhdGVkLg0KVGhh
bmtzLA0KLSBYdWZlbmcNCsKgDQoNCg0K


From nobody Sun Oct  8 07:58:45 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018D213463F; Sun,  8 Oct 2017 07:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, 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 urUoKUifTDHM; Sun,  8 Oct 2017 07:58:37 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CB8132397; Sun,  8 Oct 2017 07:58:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23939; q=dns/txt; s=iport; t=1507474716; x=1508684316; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=WeV3hKj7T9+RyNwXpT7F3WeRl6RamhRZrW3a6jav4u8=; b=NiB6FcsY2rVYf2/dTcpaCHIdodvz38KKcqVeJCMGkyOruGxzCtjX5OCT FeNDrUZs1UZrBJyHXx1laclc96K/U/5j9EXGqh1ea9IYzAC5ZpT0J9YVa j4wRwZI4eyHJl3BcOwPx6neTUf0+lIpv2jF07Brn1BSYvWzixMG13kZAe E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADXPNpZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzCBEW4ng3qKH3SnHA6CBAofhRwChGAYAQIBAQEBAQEBayiFGQY?= =?us-ascii?q?jTggQCQIONAICVwYBDAYCAQEXihUQiFKdZ4InJ4p+AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYMtg1OBaiuCfoRMBQESAYMygmEFihqCHIUKj3OHXoNfiSiCFFuIboc?= =?us-ascii?q?tihaDZoddgTkfOIEDCzIhCB0VSYcfPjaHCYI0AQEB?=
X-IronPort-AV: E=Sophos;i="5.42,495,1500940800";  d="scan'208,217";a="656225827"
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; 08 Oct 2017 14:58:33 +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 v98EwWUG013302; Sun, 8 Oct 2017 14:58:32 GMT
To: Lou Berger , NetMod WG 
Cc: rtg-dir@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org, draft-acee-netmod-rfc8022bis@ietf.org
References: 
From: Benoit Claise 
Message-ID: <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com>
Date: Sun, 8 Oct 2017 16:58:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------1339468C61E431C5BF82A962"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] handling module incompatibility => handling module transition
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 08 Oct 2017 14:58:40 -0000

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

Dear all,

Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049 is 
broken. The small problem is: trying to maintain backward compatibility.
draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.

Let me extend the scope of this email thread from "handling module 
incompatibility" to "handling module incompatibility and NMDA transition".
As I mentioned in the past (see "semver.org comparison of two YANG 
modules" email in NETMOD), I believe the IETF will have to change its 
way of working in terms of backward compatibility. See also the email 
"ietf-routing or ietf-routing-2? module naming convention for NMDA 
transition. Re: [netmod] upcoming adoptions" in NETMOD.

However, we will have to tackle this discussion one day or the other:
- we need _an automatic way_ to make the link between the YANG module in 
RFC8049 and the YANG module in draft-wu-l3sm-rfc8049bis, or any non 
backward compatible YANG modules.
- we need _an automatic way_ to make the link between the YANG module in 
RFC8022 and the YANG module in draft-acee-netmod-rfc8022bis, or any new 
YANG module names used for NMDA transition.
Note: actually, we face two different problems. draft-wu-l3sm-rfc8049bis 
might be declared backward incompatible with RFC8049, while RFC8022bis 
is backward compatible with RFC8022. The RFC8022bis went for a new YANG 
module name ietf-routing-2 to avoid to document the -state tree (as 
deprecated), based on the argument that ietf-routing is not yet implemented.

Which solutions do we have from here?
#1. We keep the same module name and express that the YANG module in 
draft-wu-l3sm-rfc8049bis is not backward compatible with the RFC8049 
one. This is the openconfig way. See draft-clacla-netmod-model-catalog 
(and draft-openconfig-netmod-model-catalog before)

       // extension statements
          extension openconfig-version {
            argument "semver" {
              yin-element false;
            }
            description
              "The OpenConfig version number for the module. This is
              expressed as a semantic version number of the form:
                x.y.z
               where:
                * x corresponds to the major version,
                * y corresponds to a minor version,
                * z corresponds to a patch version.
              This version corresponds to the model file within which it is
              defined, and does not cover the whole set of OpenConfig models.
              Where several modules are used to build up a single block of
              functionality, the same module version is specified across each
              file that makes up the module.

              A major version number of 0 indicates that this model is still
              in development (whether within OpenConfig or with industry
              partners), and is potentially subject to change.

              Following a release of major version 1, all modules will
              increment major revision number where backwards incompatible
              changes to the model are made.

              The minor version is changed when features are added to the
              model that do not impact current clients use of the model.

              The patch-level version is incremented when non-feature changes
              (such as bugfixes or clarifications to human-readable
              descriptions that do not impact model functionality) are made
              that maintain backwards compatibility.

              The version number is stored in the module meta-data.";
          }

Similarly, we always keep the same YANG module name in case of NMDA 
transition. So ietf-routing-2 should be changed back to ietf-routing.
The email thread "[Rtg-dt-yang-arch] ietf-routing or ietf-routing-2? 
module naming convention for NMDA transition. Re: [netmod] upcoming 
adoptions" seems to go in that direction.

#2. Or we have a different module name, let's say ietf-l3vpn-svc-2 or 
ietf-routing-2 but then, how do we make the link with the previous module?
Then ...  What? We create extension that will link the 
draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? Same 
principle as #1, but just more complex.
Or we have a new YANG keyword (this implies YANG 2.0)

    file"ietf-l3vpn-svc@2017-09-14.yang"
    module ietf-l3vpn-svc-2 {
      yang-version 1.1;
      namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
      prefix l3vpn-svc;
      *_obsolete|update _*ietf-l3vpn-svc@2017-01-2

And whose responsibility is this to warn/push all authors of 
ietf-routing YANG modules to move to ietf-routing-2? (*)

The following are non solution IMO:
- Going from the draft-wu-l3sm-rfc8049bis YANG _module _to the 
draft-wu-l3sm-rfc8049bis _document _to lookup the IETF "obsolete" flag 
in order to understand that the RFC8049 YANG module is obsolete is not 
an automatic solution.
- Using the yangcatalog.org might be a solution as we track the derived 
semantic, but this is just an offline trick. This is not what I call 
"automatic way"
- Using the YANG module description field might be interesting, but 
again this is not an "automatic way":

      description
       "This YANG module defines a generic service configuration
        model for Layer 3 VPNs. This model is common across all
        vendor implementations. This obsoletes the RFC8049 YANG
        module, ietf-l3vpn-svc@2017-01-2";
      revision 2017-09-14 {
       description
        "First revision ofRFC8049 .";
       reference
        "RFC xxxx: YANG Data Model for L3VPN Service Delivery";


In conclusion, I believe openconfig got this right and that solution #1 
is the solution to go ... while waiting for a new YANG keyword in YANG 2.0

(*) If you want to change the module from ietf-routing to 
ietf-routing-2, then you should follow with all authors of dependent 
modules to make sure they transition to ietf-routing-2
In the yangcatalog.org, because I needed the information as OPS AD, we 
created a small script to get that authors list for IETF drafts. For the 
ietf-routing, this produces the following
{
     "output": {
         "author-email": [
"draft-ietf-mpls-static-yang@ietf.org",
"draft-ietf-mpls-base-yang@ietf.org",
"draft-ietf-ospf-sr-yang@ietf.org",
"draft-ietf-pim-yang@ietf.org",
"draft-ietf-bier-bier-yang@ietf.org",
"draft-zhang-bier-te-yang@ietf.org",
"draft-ietf-isis-yang-isis-cfg@ietf.org",
"draft-ietf-teas-yang-rsvp-te@ietf.org",
"draft-ietf-mpls-mldp-yang@ietf.org",
"draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",
"draft-ietf-isis-sr-yang@ietf.org",
"draft-acee-rtgwg-yang-rib-extend@ietf.org",
"draft-ietf-pim-igmp-mld-yang@ietf.org",
"draft-ietf-i2rs-fb-rib-data-model@ietf.org",
"draft-ietf-ospf-yang@ietf.org",
"draft-ietf-rtgwg-yang-rip@ietf.org",
"draft-ietf-spring-sr-yang@ietf.org",
"draft-ietf-teas-yang-rsvp@ietf.org",
"draft-ietf-i2rs-pkt-eca-data-model@ietf.org",
"draft-ietf-mpls-ldp-yang@ietf.org",
"draft-ietf-bfd-yang@ietf.org",
"draft-ietf-pim-msdp-yang@ietf.org"
         ]
     }
}

Fortunately, we only deal with IETF dependent YANG modules in case of 
the ietf-routing. That's an easier case.
If we would change ietf-interfaces to ietf-interfaces-2, we would have 
an cross SDO issue ... Btw, there are no automatic ways to extract the 
authors of YANG modules from different SDOs: it's only a metadata that 
that the different SDOs should insert in the yangcatalog. So we would 
have to rely on liaisons or direct emails, assuming we know the authors. 
Time consuming, believe me.

Regards, Benoit
> Hi,
>
>      As part of the my Routing Directorate review of
> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
> changes being made to the ietf-l3vpn-svc module without changing the
> name.  I raised this with the YANG doctors and others involved with the
> draft and it surfaced some topics which really should be discussed here
> in NetMod.
>
> The background (as explained off-list by others, so I hope I have it
> right)  is that one of the YANG Doctors noted that RFC8049 was broken
> and could not be implemented as defined, and therefore a fix was
> needed.  L3SM has concluded so the fix is in the individual draft
> draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
> module could not be implemented, the feeling by the YANG Dr was that
> even though the new module is incompatible with the original definition
> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
> RFC 6020) didn't have to be followed and the same name could be used.
>
> In the subsequent discussion with the YANG Drs., the general discussion
> was heading down the path of using a new module name, and thereby not
> violating YANG module update rules.  This lead us back to the a similar
> discussion we've been having in the context of 8022bis: how best to
> indicate that a whole module is being obsoleted.  RFCs do this by adding
> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
> help YANG tooling.  For 8022, we have one approach - publishing an
> updated rev of the original module marking all nodes as deprecated - but
> that doesn't really make sense for rfc8049bis.
>
> So the discussion for the WG is:
>
> How do we handle incompatible module changes, notably when one module
> 'obsoletes' another module --  from both the process and tooling
> perspectives?
>
> I know Benoit plans to bring in some thoughts/proposals, perhaps there
> are others.
>
> Cheers,
>
> Lou
>
> (as contributor/reviewer)
>
>
> .
>


--------------1339468C61E431C5BF82A962
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dear all,

      

      Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049
      is broken. The small problem is: trying to maintain backward
      compatibility.

      draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.

      

      Let me extend the scope of this email thread from "handling module
      incompatibility" to "handling module incompatibility and NMDA
      transition".

      As I mentioned in the past (see "semver.org comparison of two YANG
      modules" email in NETMOD), I believe the IETF will have to change
      its way of working in terms of backward compatibility. See also
      the email "ietf-routing or ietf-routing-2? module naming
      convention for NMDA transition. Re: [netmod] upcoming adoptions"
      in NETMOD. 

      

      However, we will have to tackle this discussion one day or the
      other: 

      - we need an automatic way to make the link between the
      YANG module in RFC8049 and the YANG module in
      draft-wu-l3sm-rfc8049bis, or any non backward compatible YANG
      modules.

      - we need an automatic way to make the link between the
      YANG module in RFC8022 and the YANG module in
      draft-acee-netmod-rfc8022bis, or any new YANG module names used
      for NMDA transition.

      Note: actually, we face two different problems.
      draft-wu-l3sm-rfc8049bis might be declared backward incompatible
      with RFC8049, while RFC8022bis is backward compatible with
      RFC8022. The RFC8022bis went for a new YANG module name
      ietf-routing-2 to avoid to document the -state tree (as
      deprecated), based on the argument that ietf-routing is not yet
      implemented.

      

      Which solutions do we have from here? 

      #1. We keep the same module name and express that the YANG module
      in draft-wu-l3sm-rfc8049bis is not backward compatible with the
      RFC8049 one. This is the openconfig way. See
      draft-clacla-netmod-model-catalog (and
      draft-openconfig-netmod-model-catalog before)

      
      

        
  // extension statements
     extension openconfig-version {
       argument "semver" {
         yin-element false;
       }
       description
         "The OpenConfig version number for the module. This is
         expressed as a semantic version number of the form:
           x.y.z
          where:
           * x corresponds to the major version,
           * y corresponds to a minor version,
           * z corresponds to a patch version.
         This version corresponds to the model file within which it is
         defined, and does not cover the whole set of OpenConfig models.
         Where several modules are used to build up a single block of
         functionality, the same module version is specified across each
         file that makes up the module.

         A major version number of 0 indicates that this model is still
         in development (whether within OpenConfig or with industry
         partners), and is potentially subject to change.

         Following a release of major version 1, all modules will
         increment major revision number where backwards incompatible
         changes to the model are made.

         The minor version is changed when features are added to the
         model that do not impact current clients use of the model.

         The patch-level version is incremented when non-feature changes
         (such as bugfixes or clarifications to human-readable
         descriptions that do not impact model functionality) are made
         that maintain backwards compatibility.

         The version number is stored in the module meta-data.";
     }

      

      Similarly, we always keep the same YANG module name in case of
      NMDA transition. So ietf-routing-2 should be changed back to
      ietf-routing.

      The email thread "[Rtg-dt-yang-arch] ietf-routing or
      ietf-routing-2? module naming convention for NMDA transition. Re:
      [netmod] upcoming adoptions" seems to go in that direction.

      

      #2. Or we have a different module name, let's say ietf-l3vpn-svc-2
      or ietf-routing-2 but then, how do we make the link with the
      previous module? 

      Then ...  What? We create extension that will link the
      draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module?
      Same principle as #1, but just more complex. 

      Or we have a new YANG keyword (this implies YANG 2.0)

      

        
<CODE BEGINS>file "ietf-l3vpn-svc@2017-09-14.yang"
module ietf-l3vpn-svc-2 {
 yang-version 1.1;
 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
 prefix l3vpn-svc;
 obsolete|update ietf-l3vpn-svc@2017-01-2


      

      And whose responsibility is this to warn/push all authors of
      ietf-routing YANG modules to move to ietf-routing-2? (*)

      

      The following are non solution IMO:

      - Going from the draft-wu-l3sm-rfc8049bis YANG module to
      the draft-wu-l3sm-rfc8049bis document to lookup the IETF
      "obsolete" flag in order to understand that the RFC8049 YANG
      module is obsolete is not an automatic solution.

      - Using the yangcatalog.org might be a solution as we track the
      derived semantic, but this is just an offline trick. This is not
      what I call "automatic way"

      - Using the YANG module description field might be interesting,
      but again this is not an "automatic way":

      

        
 description
  "This YANG module defines a generic service configuration
   model for Layer 3 VPNs. This model is common across all
   vendor implementations. This obsoletes the RFC8049 YANG 
   module, ietf-l3vpn-svc@2017-01-2";
 revision 2017-09-14 {
  description
   "First revision of RFC8049.";
  reference
   "RFC xxxx: YANG Data Model for L3VPN Service Delivery";

      

      

      In conclusion, I believe openconfig got this right and that
      solution #1 is the solution to go ... while waiting for a new YANG
      keyword in YANG 2.0

      

      (*) If you want to change the module from ietf-routing to
      ietf-routing-2, then you should follow with all authors of
      dependent modules to make sure they transition to ietf-routing-2

      In the yangcatalog.org, because I needed the information as OPS
      AD, we created a small script to get that authors list for IETF
      drafts. For the ietf-routing, this produces the following

      {

          "output": {

              "author-email": [

                  "draft-ietf-mpls-static-yang@ietf.org",

                  "draft-ietf-mpls-base-yang@ietf.org",

                  "draft-ietf-ospf-sr-yang@ietf.org",

                  "draft-ietf-pim-yang@ietf.org",

                  "draft-ietf-bier-bier-yang@ietf.org",

                  "draft-zhang-bier-te-yang@ietf.org",

                  "draft-ietf-isis-yang-isis-cfg@ietf.org",

                  "draft-ietf-teas-yang-rsvp-te@ietf.org",

                  "draft-ietf-mpls-mldp-yang@ietf.org",

                  "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",

                  "draft-ietf-isis-sr-yang@ietf.org",

                  "draft-acee-rtgwg-yang-rib-extend@ietf.org",

                  "draft-ietf-pim-igmp-mld-yang@ietf.org",

                  "draft-ietf-i2rs-fb-rib-data-model@ietf.org",

                  "draft-ietf-ospf-yang@ietf.org",

                  "draft-ietf-rtgwg-yang-rip@ietf.org",

                  "draft-ietf-spring-sr-yang@ietf.org",

                  "draft-ietf-teas-yang-rsvp@ietf.org",

                  "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",

                  "draft-ietf-mpls-ldp-yang@ietf.org",

                  "draft-ietf-bfd-yang@ietf.org",

                  "draft-ietf-pim-msdp-yang@ietf.org"

              ]

          }

      }

      

      Fortunately, we only deal with IETF dependent YANG modules in case
      of the ietf-routing. That's an easier case.

      If we would change ietf-interfaces to ietf-interfaces-2, we would
      have an cross SDO issue ... Btw, there are no automatic ways to
      extract the authors of YANG modules from different SDOs: it's only
      a metadata that that the different SDOs should insert in the
      yangcatalog. So we would have to rely on liaisons or direct
      emails, assuming we know the authors. Time consuming, believe me.

      

      Regards, Benoit

    

    

      
Hi,

    As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name.  I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.

The background (as explained off-list by others, so I hope I have it
right)  is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed.  L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.

In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules.  This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted.  RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling.  For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.

So the discussion for the WG is:

How do we handle incompatible module changes, notably when one module
'obsoletes' another module --  from both the process and tooling
perspectives?

I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.

Cheers,

Lou

(as contributor/reviewer)


.



    

    

  


--------------1339468C61E431C5BF82A962--


From nobody Sun Oct  8 11:01:09 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B15913314B; Sun,  8 Oct 2017 11:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCbd7cBkgBgd; Sun,  8 Oct 2017 11:00:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 786CC1320D9; Sun,  8 Oct 2017 11:00:59 -0700 (PDT)
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 9AC4A1AE018C; Sun,  8 Oct 2017 20:00:57 +0200 (CEST)
To: Xufeng Liu 
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>
From: Per Hedeland 
Cc: netconf@ietf.org, 'NetMod WG' 
Message-ID: 
Date: Sun, 8 Oct 2017 20:00:57 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <033601d33ee7$bd359810$37a0c830$@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 08 Oct 2017 18:01:01 -0000

On 2017-10-06 23:11, Xufeng Liu wrote:
> During the design team discussion for TE and MPLS YANG modeling, we have received a request from implementers: How to minimize the number of NETCONF/RESTCONF RPCs to improve operation efficiency? 
> Especially for the case when the operator or client software needs to retrieve the object contents pointed by a leafref.
> 
> For example, given the following simplified TE tunnel model,
> 
> +--rw te
> 
>      +--rw explicit-paths
> 
>      |  +--rw explicit-path* [name]
> 
>      |     +--rw name                      string
> 
>      |        +--rw explicit-route-object* [index]
> 
>      |           +--rw index                   uint32
> 
>      |           +--rw explicit-route-usage?   identityref
> 
>      +--rw tunnels
> 
>      |  +--rw tunnel* [name]
> 
>      |  |  +--rw name                   string
> 
>      |  |  +--rw paths
> 
>      |  |  |  +--rw path* [name]
> 
> |  |  |     +--rw explicit-path?  -> ../../../../../explicit-paths/explicit-path/name
> 
> when the client tries to retrieve a tunnels information based on the tunnel name, the get operation returns a list of leafrefs pointing to the paths of the tunnel.

Sorry, I'm afraid I don't follow. Can you explain exactly what your
"get" request is (protocol and payload), and where the "list of
leafref's" (whatever that may be) occurs in the reply?

JFYI, in case there is some fundamental misunderstanding here: a leaf of
type leafref has a single value - *one* of those that satisfy the leafref
constraint, in case there are multiple "candidates".

--Per

> The client needs to issue at 
> least one more get operation to retrieve the path information about the given tunnel. The request is to combine these two operations into one.
> 
> In the RDBMS SQL world, join can be used when SQL select is performed, but NETCONF/YANG currently does not have this capability.
> 
> Wed like to ask whether such a request is considered reasonable.
> 
> If the request is reasonable, the next question is how to proceed. This seems to be a protocol issue rather than YANG modeling issue. Is it acceptable to add a new operation to achieve such a 
>  operation with expanded leafrefs?
> 
> Comments and suggestions are appreciated.
> 
> Thanks,
> 
> - Xufeng
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Sun Oct  8 14:36:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744F9132A89; Sun,  8 Oct 2017 14:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 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, 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 7AhSISIoCbH5; Sun,  8 Oct 2017 14:36:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FD5132320; Sun,  8 Oct 2017 14:36:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXC18750; Sun, 08 Oct 2017 21:36:21 +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.301.0; Sun, 8 Oct 2017 22:36:20 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000;  Sun, 8 Oct 2017 14:36:08 -0700
From: Igor Bryskin 
To: "per@tail-f.com" , "xufeng.liu.ietf@gmail.com" 
CC: "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/gBsqhSA///GxXk=
Date: Sun, 8 Oct 2017 21:36:07 +0000
Message-ID: 
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_etPan59da9a3312305c3a3f7flocalhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59DA9A55.00B0, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9c1704efd10219ce476efdd10cc12770
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 08 Oct 2017 21:36:26 -0000

--_000_etPan59da9a3312305c3a3f7flocalhost_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Per,

In a nutshell we would lika for a netconf client to have a way  to instruct=
 the server on whether in response to the get request the server needs to p=
rovide the entire body of a datastore node pointed to by a leafref or just =
a pointer to said node, so that the node's body could be retrieved by a sub=
sequent separate request. This is requested by implementors who want to opt=
imise rhe number of interactions between a client and its server.

Cheers,
Igor
From:Per Hedeland
To:Xufeng Liu,
Cc:netconf@ietf.org,'NetMod WG',
Date:2017-10-08 14:01:27
Subject:Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

On 2017-10-06 23:11, Xufeng Liu wrote:
> During the design team discussion for TE and MPLS YANG modeling, we have =
received a request from implementers: How to minimize the number of NETCONF=
/RESTCONF RPCs to improve operation efficiency?
> Especially for the case when the operator or client software needs to ret=
rieve the object contents pointed by a leafref.
>
> For example, given the following simplified TE tunnel model,
>
> +--rw te
>
>      +--rw explicit-paths
>
>      |  +--rw explicit-path* [name]
>
>      |     +--rw name                      string
>
>      |        +--rw explicit-route-object* [index]
>
>      |           +--rw index                   uint32
>
>      |           +--rw explicit-route-usage?   identityref
>
>      +--rw tunnels
>
>      |  +--rw tunnel* [name]
>
>      |  |  +--rw name                   string
>
>      |  |  +--rw paths
>
>      |  |  |  +--rw path* [name]
>
> |  |  |     +--rw explicit-path?  -> ../../../../../explicit-paths/explic=
it-path/name
>
> when the client tries to retrieve a tunnel=19s information based on the t=
unnel name, the =1Cget=1D operation returns a list of leafref=19s pointing =
to the paths of the tunnel.

Sorry, I'm afraid I don't follow. Can you explain exactly what your
"get" request is (protocol and payload), and where the "list of
leafref's" (whatever that may be) occurs in the reply?

JFYI, in case there is some fundamental misunderstanding here: a leaf of
type leafref has a single value - *one* of those that satisfy the leafref
constraint, in case there are multiple "candidates".

--Per

> The client needs to issue at
> least one more =1Cget=1D operation to retrieve the path information about=
 the given tunnel. The request is to combine these two operations into one.
>
> In the RDBMS SQL world, =1Cjoin=1D can be used when SQL =1Cselect=1D is p=
erformed, but NETCONF/YANG currently does not have this capability.
>
> We=19d like to ask whether such a request is considered reasonable.
>
> If the request is reasonable, the next question is how to proceed. This s=
eems to be a protocol issue rather than YANG modeling issue. Is it acceptab=
le to add a new operation to achieve such a
>  operation with expanded leafref=19s?
>
> Comments and suggestions are appreciated.
>
> Thanks,
>
> - Xufeng
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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

--_000_etPan59da9a3312305c3a3f7flocalhost_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Per,



In a nutshell we would lika for a netconf client to have a way  to ins=
truct the server on whether in response to the get request the server needs=
 to provide the entire body of a datastore node pointed to by a leafref or =
just a pointer to said node, so that
 the node's body could be retrieved by a subsequent separate request. This =
is requested by implementors who want to optimise rhe number of interaction=
s between a client and its server.



Cheers,

Igor






From:Per Hedeland


To:Xufeng Liu,


Cc:netconf@ietf.org,'NetMod WG',=



Date:2017-10-08 14:01:27


Subject:Re: [Netconf] [netmod] R=
etrieving Information Pointed by leafref












On 2017-10-06 23:11, Xufeng Liu wrote:

> During the design team discussion for TE and MPLS YANG modeling, we ha=
ve received a request from implementers: How to minimize the number of NETC=
ONF/RESTCONF RPCs to improve operation efficiency?


> Especially for the case when the operator or client software needs to =
retrieve the object contents pointed by a leafref.

> 

> For example, given the following simplified TE tunnel model,

> 

> +--rw te

> 

>      +--rw explicit-paths

> 

>      |  +--rw explicit-path* [name]<=
br>
> 

>      |     +--rw name=
            &nb=
sp;         string

> 

>      |      &nb=
sp; +--rw explicit-route-object* [index]

> 

>      |      &nb=
sp;    +--rw index      &n=
bsp;            uint=
32

> 

>      |      &nb=
sp;    +--rw explicit-route-usage?   identityr=
ef

> 

>      +--rw tunnels

> 

>      |  +--rw tunnel* [name]

> 

>      |  |  +--rw name &nbs=
p;            &=
nbsp;    string

> 

>      |  |  +--rw paths

> 

>      |  |  |  +--rw path* =
[name]

> 

> |  |  |     +--rw explicit-path?&nbs=
p; -> ../../../../../explicit-paths/explicit-path/name

> 

> when the client tries to retrieve a tunnels information based on =
the tunnel name, the get operation returns a list of leafref=
s pointing to the paths of the tunnel.



Sorry, I'm afraid I don't follow. Can you explain exactly what your

"get" request is (protocol and payload), and where the "list=
 of

leafref's" (whatever that may be) occurs in the reply?



JFYI, in case there is some fundamental misunderstanding here: a leaf of
type leafref has a single value - *one* of those that satisfy the leafref
constraint, in case there are multiple "candidates".



--Per



> The client needs to issue at 

> least one more get operation to retrieve the path informatio=
n about the given tunnel. The request is to combine these two operations in=
to one.

> 

> In the RDBMS SQL world, join can be used when SQL selec=
t is performed, but NETCONF/YANG currently does not have this capabili=
ty.

> 

> Wed like to ask whether such a request is considered reasonable.<=
br>
> 

> If the request is reasonable, the next question is how to proceed. Thi=
s seems to be a protocol issue rather than YANG modeling issue. Is it accep=
table to add a new operation to achieve such a


> <get-data> operation with expanded leafrefs?

> 

> Comments and suggestions are appreciated.

> 

> Thanks,

> 

> - Xufeng

> 

> 

> 

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.i=
etf.org/mailman/listinfo/netmod

> 



_______________________________________________

Netconf mailing list

Netconf@ietf.org

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







--_000_etPan59da9a3312305c3a3f7flocalhost_--


From nobody Sun Oct  8 16:04:12 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CFD132F76; Sun,  8 Oct 2017 16:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 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, 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 N94368T-KH0u; Sun,  8 Oct 2017 16:04:02 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF341330BF; Sun,  8 Oct 2017 16:04:01 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQD20206; Sun, 08 Oct 2017 23:03:59 +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.301.0; Mon, 9 Oct 2017 00:03:58 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000;  Sun, 8 Oct 2017 16:03:40 -0700
From: Igor Bryskin 
To: Igor Bryskin , "per@tail-f.com" ,  "xufeng.liu.ietf@gmail.com" 
CC: "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/gBsqhSA///GxXmAABh1KA==
Date: Sun, 8 Oct 2017 23:03:39 +0000
Message-ID: 
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>, , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_etPan59daaeb66daf0f5d4ba3localhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.59DAAEE0.0031, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f33fc7b725f35566479b73ba291ab56a
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 08 Oct 2017 23:04:05 -0000

--_000_etPan59daaeb66daf0f5d4ba3localhost_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Joel,

Thanks, I think I didnt explain our problem correctly.

In our case we have a leafref pointing to a te tunnel name, which happens t=
o be a key to lookup the (axilary) tunnel.  We need  a way to include the e=
ntire tunnel body (not just a name) into the get response. This is to optim=
ize the number of iterations between the client and the server. As Xufeng p=
ut it something similar to SQL join,

Igor
From:Igor Bryskin
To:per@tail-f.com,xufeng.liu.ietf@gmail.com,
Cc:netconf@ietf.org,netmod@ietf.org,
Date:2017-10-08 17:36:47
Subject:Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

Hi Per,

In a nutshell we would lika for a netconf client to have a way  to instruct=
 the server on whether in response to the get request the server needs to p=
rovide the entire body of a datastore node pointed to by a leafref or just =
a pointer to said node, so that the node's body could be retrieved by a sub=
sequent separate request. This is requested by implementors who want to opt=
imise rhe number of interactions between a client and its server.

Cheers,
Igor
From:Per Hedeland
To:Xufeng Liu,
Cc:netconf@ietf.org,'NetMod WG',
Date:2017-10-08 14:01:27
Subject:Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

On 2017-10-06 23:11, Xufeng Liu wrote:
> During the design team discussion for TE and MPLS YANG modeling, we have =
received a request from implementers: How to minimize the number of NETCONF=
/RESTCONF RPCs to improve operation efficiency?
> Especially for the case when the operator or client software needs to ret=
rieve the object contents pointed by a leafref.
>
> For example, given the following simplified TE tunnel model,
>
> +--rw te
>
>      +--rw explicit-paths
>
>      |  +--rw explicit-path* [name]
>
>      |     +--rw name                      string
>
>      |        +--rw explicit-route-object* [index]
>
>      |           +--rw index                   uint32
>
>      |           +--rw explicit-route-usage?   identityref
>
>      +--rw tunnels
>
>      |  +--rw tunnel* [name]
>
>      |  |  +--rw name                   string
>
>      |  |  +--rw paths
>
>      |  |  |  +--rw path* [name]
>
> |  |  |     +--rw explicit-path?  -> ../../../../../explicit-paths/explic=
it-path/name
>
> when the client tries to retrieve a tunnel=19s information based on the t=
unnel name, the =1Cget=1D operation returns a list of leafref=19s pointing =
to the paths of the tunnel.

Sorry, I'm afraid I don't follow. Can you explain exactly what your
"get" request is (protocol and payload), and where the "list of
leafref's" (whatever that may be) occurs in the reply?

JFYI, in case there is some fundamental misunderstanding here: a leaf of
type leafref has a single value - *one* of those that satisfy the leafref
constraint, in case there are multiple "candidates".

--Per

> The client needs to issue at
> least one more =1Cget=1D operation to retrieve the path information about=
 the given tunnel. The request is to combine these two operations into one.
>
> In the RDBMS SQL world, =1Cjoin=1D can be used when SQL =1Cselect=1D is p=
erformed, but NETCONF/YANG currently does not have this capability.
>
> We=19d like to ask whether such a request is considered reasonable.
>
> If the request is reasonable, the next question is how to proceed. This s=
eems to be a protocol issue rather than YANG modeling issue. Is it acceptab=
le to add a new operation to achieve such a
>  operation with expanded leafref=19s?
>
> Comments and suggestions are appreciated.
>
> Thanks,
>
> - Xufeng
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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

--_000_etPan59daaeb66daf0f5d4ba3localhost_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable










Hi Joel,



Thanks, I think I didnt explain our problem correctly.



In our case we have a leafref pointing to a te tunnel name, which happens t=
o be a key to lookup the (axilary) tunnel.  We need  a way to inc=
lude the entire tunnel body (not just a name) into the get response. This i=
s to optimize the number of iterations between
 the client and the server. As Xufeng put it something similar to SQL join,=




Igor






From:Igor Bryskin


To:per@tail-f.com,xufeng.liu.iet=
f@gmail.com,


Cc:netconf@ietf.org,netmod@ietf.=
org,


Date:2017-10-08 17:36:47


Subject:Re: [Netconf] [netmod] R=
etrieving Information Pointed by leafref













Hi Per,



In a nutshell we would lika for a netconf client to have a way  to ins=
truct the server on whether in response to the get request the server needs=
 to provide the entire body of a datastore node pointed to by a leafref or =
just a pointer to said node, so that
 the node's body could be retrieved by a subsequent separate request. This =
is requested by implementors who want to optimise rhe number of interaction=
s between a client and its server.



Cheers,

Igor






From:Per Hedeland


To:Xufeng Liu,


Cc:netconf@ietf.org,'NetMod WG',=



Date:2017-10-08 14:01:27


Subject:Re: [Netconf] [netmod] R=
etrieving Information Pointed by leafref












On 2017-10-06 23:11, Xufeng Liu wrote:

> During the design team discussion for TE and MPLS YANG modeling, we ha=
ve received a request from implementers: How to minimize the number of NETC=
ONF/RESTCONF RPCs to improve operation efficiency?


> Especially for the case when the operator or client software needs to =
retrieve the object contents pointed by a leafref.

> 

> For example, given the following simplified TE tunnel model,

> 

> +--rw te

> 

>      +--rw explicit-paths

> 

>      |  +--rw explicit-path* [name]<=
br>
> 

>      |     +--rw name=
            &nb=
sp;         string

> 

>      |      &nb=
sp; +--rw explicit-route-object* [index]

> 

>      |      &nb=
sp;    +--rw index      &n=
bsp;            uint=
32

> 

>      |      &nb=
sp;    +--rw explicit-route-usage?   identityr=
ef

> 

>      +--rw tunnels

> 

>      |  +--rw tunnel* [name]

> 

>      |  |  +--rw name &nbs=
p;            &=
nbsp;    string

> 

>      |  |  +--rw paths

> 

>      |  |  |  +--rw path* =
[name]

> 

> |  |  |     +--rw explicit-path?&nbs=
p; -> ../../../../../explicit-paths/explicit-path/name

> 

> when the client tries to retrieve a tunnels information based on =
the tunnel name, the get operation returns a list of leafref=
s pointing to the paths of the tunnel.



Sorry, I'm afraid I don't follow. Can you explain exactly what your

"get" request is (protocol and payload), and where the "list=
 of

leafref's" (whatever that may be) occurs in the reply?



JFYI, in case there is some fundamental misunderstanding here: a leaf of
type leafref has a single value - *one* of those that satisfy the leafref
constraint, in case there are multiple "candidates".



--Per



> The client needs to issue at 

> least one more get operation to retrieve the path informatio=
n about the given tunnel. The request is to combine these two operations in=
to one.

> 

> In the RDBMS SQL world, join can be used when SQL selec=
t is performed, but NETCONF/YANG currently does not have this capabili=
ty.

> 

> Wed like to ask whether such a request is considered reasonable.<=
br>
> 

> If the request is reasonable, the next question is how to proceed. Thi=
s seems to be a protocol issue rather than YANG modeling issue. Is it accep=
table to add a new operation to achieve such a


> <get-data> operation with expanded leafrefs?

> 

> Comments and suggestions are appreciated.

> 

> Thanks,

> 

> - Xufeng

> 

> 

> 

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.i=
etf.org/mailman/listinfo/netmod

> 



_______________________________________________

Netconf mailing list

Netconf@ietf.org

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








--_000_etPan59daaeb66daf0f5d4ba3localhost_--


From nobody Mon Oct  9 01:43:51 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFB7134D62 for ; Mon,  9 Oct 2017 01:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.101
X-Spam-Level: 
X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 xnrbgFZyvMV6 for ; Mon,  9 Oct 2017 01:43:48 -0700 (PDT)
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 A3117134D2E for ; Mon,  9 Oct 2017 01:43:47 -0700 (PDT)
Received: from birdie14 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 75E42608FA; Mon,  9 Oct 2017 10:43:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1507538624; bh=wiVfoHUwWz63n0VzrTUstT8D7+WflP2mdYb73pymulk=; h=From:To:Date; b=Inl6XH4Of4I3cH/62lMAaV2458aIuUfGgLtycGWK4CJrsyI2AkZhunDomejMELBuq 7qNi1EWJ7QjUvk1IKn0j29/SZohrV+t0Ja4uPFhoDgufa7CGV3y4ntNtH9aQ5k8lCh hnqleThMdTBHWxt5cbpSh66djqCEUC7bFl0tLsJ4=
Message-ID: <1507538675.15153.15.camel@nic.cz>
From: Ladislav Lhotka 
To: "t.petch" , Martin Bjorklund ,  netmod@ietf.org
Date: Mon, 09 Oct 2017 10:44:35 +0200
In-Reply-To: <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
References: <150650952130.25003.1792240611663747386@ietfa.amsl.com> <20170927.125558.606437323539289377.mbj@tail-f.com> <877ew9zrhs.fsf@nic.cz> <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.1 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] Odp.:  I-D Action: draft-ietf-netmod-schema-mount-07.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, 09 Oct 2017 08:43:51 -0000

t.petch píše v Pá 06. 10. 2017 v 12:39 +0100:
> ----- Original Message -----
> From: "Ladislav Lhotka" 
> Sent: Thursday, October 05, 2017 1:52 PM
> > Martin Bjorklund  writes:
> > 
> > > This version fixes the XPath context for parent-reference.
> > > 
> > > However, there is one more thing to discuss, which is the term
> 
> "mount
> > > point".
> > > 
> > > The current text says:
> > > 
> > >    - mount point: container or list node whose definition contains
> > >      the "mount-point" extension statement. The argument of the
> > >      "mount-point" statement defines the name of the mount point.
> > > 
> > > So if we have:
> > > 
> > >   container top {
> > >     container root {
> > >       yangmnt:mount-point ni;
> > >     }
> > >   }
> > > 
> > > There is one mount point, the node /top/root, with the name "ni".
> > > 
> > > Pretty confusing...   Does anyone have any comments around this?
> > 
> > What about this?
> > 
> > OLD
> > 
> >     - mount point: container or list node whose definition contains
> >       the "mount-point" extension statement. The argument of the
> >       "mount-point" statement defines the name of the mount point.
> > 
> > NEW
> > 
> >     - mount point: container or list node whose definition contains
> >       the "mount-point" extension statement. The argument of the
> >       "mount-point" statement defines a label that is used for
> >       referencing the mount point.
> 
> Lada
> 
> Trouble is 'label' is not a defined term in RFC7950 which leaves me (and
> others) wondering what is this undefined concept.  I know plenty of
> languages that have the concept of a label but YANG is not one of them.

The argument of the "schema-mount" extension is used exclusively for the
purposes of schema mount so it is fully appropriate that the term "label" is
unknown to RFC 7950. In fact, the problem that Martin pointed to is that data
nodes in RFC 7950 already have their name and now we are introducing the same
term with a different meaning.

Lada

> 
> I looked to see what the ABNF says for inspiration but there isn't
> any:-)  I think that there should be.
> 
> I looked for a worked example for inspiration, nope, none of them
> either!   What I mean is that in e.g. A.3  mount point with name root
> appears, but that is the only instance of 'root'.  The whole point is
> that root should appear more than once, once for where the mount will
> be, and then once or more times for the part that will be mounted, so an
> example where name appears once is not an example IMHO!
> 
> Tom Petch
> 
> > Lada
> > 
> > > 
> > > 
> > > 
> > > /martin
> > > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Oct  9 06:42:23 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0347A134540; Mon,  9 Oct 2017 06:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9Rd5x4QNFAb; Mon,  9 Oct 2017 06:42:19 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3425E134544; Mon,  9 Oct 2017 06:42:16 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id l194so13590015qke.13; Mon, 09 Oct 2017 06:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=WSSF92VqfmwMslo6VurRPTBUBg4q1ZAUEhBDwwYhdGg=; b=kS2GvBwmDwoeGmK+B2UnEEdnATjK6J3ePcBqIFa1gkzRKd1D7coShbaWLNJYyA/4yK 6bJ11jOWtEflFa/oNfTmqhfBHZz3egn27iZODyXsJwnZgcXY4kLyGLE334VbhZ3MkzGI ZTl+fGczIx/d0qm6wlBcw6FdAIrxZV7K8esARE80ANC8osxsOB13BU+AOShaaJjtX1Wo g5LuoQtlEtDLqjO6MAheAZdZ0s1Gs1VmB+dWZwQPqMj3qFKiHb6GROR/qxhaYcC8YrmV +svknTR76IV5ckuLMUJ73NkBK/gpK4rrPTkRU/0UVAlmNk8SuvZZWLGnnmGx3RCEbC8G dPpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=WSSF92VqfmwMslo6VurRPTBUBg4q1ZAUEhBDwwYhdGg=; b=sKrq+DtgRGLchvp5cVV+0PrXtnapI7prh/dYuOFImtuFl2m+PizJE8G1SaSwI7zglO 41YoF/CjWoyWAETVH+jJkoPQdVXf/eQ2qxvTQFi33KIDvcGHX/G2ULJxlvvMAFIhaVW5 oPKEOgNW1tE5PV4clXAjXSjfFrB/4CTIjmdsKMEp+L+Bh4qK6ynjzlzKg1dxE9nTprwx bKyifuAjYiE67mgKpoYZym8Ds7XelsJC8g/iz2/RGsvXVTfSu274GoG2r7u/iEtr8N9N hANPzE0+RyxT32UvQW2VIE67hIPZfFMI3b2atUumSSr7DEZFW7yfXHuTqQO2R7jX8yEv 4GgA==
X-Gm-Message-State: AMCzsaUQq6KAeXqMSoCMdRB/+UkTlhw5RanJlzYuyElH8rlCVp42PKT0 ErFhw/8f9voGaJOebnqndII=
X-Google-Smtp-Source: AOwi7QC7xQ7NUpQ8B//s8yr/0hHbkCzh/hF5iR+G0pXwUDRLEKBI4ZXj3nfW0swCIWMOeHmn+/l1+A==
X-Received: by 10.55.142.5 with SMTP id q5mr9434836qkd.83.1507556535343; Mon, 09 Oct 2017 06:42:15 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id y63sm4795200qky.75.2017.10.09.06.42.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 06:42:14 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Igor Bryskin'" , 
Cc: , 
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>, ,  
In-Reply-To: 
Date: Mon, 9 Oct 2017 09:42:14 -0400
Message-ID: <049501d34104$6aa46670$3fed3350$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0496_01D340E2.E39CB180"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJRlvjQguq0FpBEphzfpMnulw/GOQFkJZc0AsOBiP0AqC3rDqG4V7HA
Content-Language: en-us
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 13:42:22 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0496_01D340E2.E39CB180
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Per,

=20

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]=20
Sent: Sunday, October 8, 2017 7:04 PM
To: Igor Bryskin ; per@tail-f.com;
xufeng.liu.ietf@gmail.com
Cc: netconf@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by =
leafref

=20


Hi Joel,

Thanks, I think I didnt explain our problem correctly.

In our case we have a leafref pointing to a te tunnel name, which =
happens to
be a key to lookup the (axilary) tunnel.  We need  a way to include the
entire tunnel body (not just a name) into the get response. This is to
optimize the number of iterations between the client and the server. As
Xufeng put it something similar to SQL join,

Igor

From:Igor Bryskin

To:per@tail-f.com,xufeng.liu.ietf@gmail.com,

Cc:netconf@ietf.org,netmod@ietf.org,

Date:2017-10-08 17:36:47

Subject:Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

=20

Hi Per,

In a nutshell we would lika for a netconf client to have a way  to =
instruct
the server on whether in response to the get request the server needs to
provide the entire body of a datastore node pointed to by a leafref or =
just
a pointer to said node, so that the node's body could be retrieved by a
subsequent separate request. This is requested by implementors who want =
to
optimise rhe number of interactions between a client and its server.

Cheers,
Igor

From:Per Hedeland

To:Xufeng Liu,

Cc:netconf@ietf.org,'NetMod WG',

Date:2017-10-08 14:01:27

Subject:Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

=20

On 2017-10-06 23:11, Xufeng Liu wrote:
> During the design team discussion for TE and MPLS YANG modeling, we =
have
received a request from implementers: How to minimize the number of
NETCONF/RESTCONF RPCs to improve operation efficiency?=20
> Especially for the case when the operator or client software needs to
retrieve the object contents pointed by a leafref.
>=20
> For example, given the following simplified TE tunnel model,
>=20
> +--rw te
>=20
>      +--rw explicit-paths
>=20
>      |  +--rw explicit-path* [name]
>=20
>      |     +--rw name                      string
>=20
>      |        +--rw explicit-route-object* [index]
>=20
>      |           +--rw index                   uint32
>=20
>      |           +--rw explicit-route-usage?   identityref
>=20
>      +--rw tunnels
>=20
>      |  +--rw tunnel* [name]
>=20
>      |  |  +--rw name                   string
>=20
>      |  |  +--rw paths
>=20
>      |  |  |  +--rw path* [name]
>=20
> |  |  |     +--rw explicit-path?  ->
../../../../../explicit-paths/explicit-path/name
>=20
> when the client tries to retrieve a tunnels information based on the
tunnel name, the =1Cget operation returns a list of leafrefs pointing to =
the
paths of the tunnel.

Sorry, I'm afraid I don't follow. Can you explain exactly what your
"get" request is (protocol and payload), and where the "list of
leafref's" (whatever that may be) occurs in the reply?

[Xufeng]  The "get" operation is the NETCONF/RESTCON  protocol
operation, or the  operation described in

https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
operations on {+restconf}/ds/ described in

https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00.

=20

We have a list of leafref values because in this example model, each =
tunnel
contains a list of paths, each of them contains a leafref. The "get" =
returns
a value for each instance of such a leafref, which (as a string value) =
will
be used as a constraint (foreign key) to retrieve the instance of an
explicit-path in the model above.



JFYI, in case there is some fundamental misunderstanding here: a leaf of
type leafref has a single value - *one* of those that satisfy the =
leafref
constraint, in case there are multiple "candidates".

--Per

> The client needs to issue at=20
> least one more =1Cget operation to retrieve the path information about =
the
given tunnel. The request is to combine these two operations into one.
>=20
> In the RDBMS SQL world, =1Cjoin can be used when SQL =1Cselect is =
performed,
but NETCONF/YANG currently does not have this capability.
>=20
> Wed like to ask whether such a request is considered reasonable.
>=20
> If the request is reasonable, the next question is how to proceed. =
This
seems to be a protocol issue rather than YANG modeling issue. Is it
acceptable to add a new operation to achieve such a=20
>  operation with expanded leafrefs?
>=20
> Comments and suggestions are appreciated.
>=20
> Thanks,
>=20
> - Xufeng
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org =20
> https://www.ietf.org/mailman/listinfo/netmod
>=20

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


------=_NextPart_000_0496_01D340E2.E39CB180
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi =
Per,
 
From: Igor =
Bryskin [mailto:Igor.Bryskin@huawei.com] 
Sent: Sunday, =
October 8, 2017 7:04 PM
To: Igor Bryskin =
<Igor.Bryskin@huawei.com>; per@tail-f.com; =
xufeng.liu.ietf@gmail.com
Cc: netconf@ietf.org; =
netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving =
Information Pointed by leafref
 

Hi =
Joel,

Thanks, I think I didnt explain our problem =
correctly.

In our case we have a leafref pointing to a te tunnel =
name, which happens to be a key to lookup the (axilary) tunnel.  We =
need  a way to include the entire tunnel body (not just a name) =
into the get response. This is to optimize the number of iterations =
between the client and the server. As Xufeng put it something similar to =
SQL join,

Igor
From:Igor =
Bryskin
To:per@tail-f.com,xufeng.liu.ietf@gmail.com,=

Cc:netconf@ietf.org,netmod@ietf.org,
Date:2017-10-08 =
17:36:47
Subject:Re: [Netconf] [netmod] Retrieving Information =
Pointed by leafref
 
<=
div>
Hi Per,

In a nutshell we would lika =
for a netconf client to have a way  to instruct the server on =
whether in response to the get request the server needs to provide the =
entire body of a datastore node pointed to by a leafref or just a =
pointer to said node, so that the node's body could be retrieved by a =
subsequent separate request. This is requested by implementors who want =
to optimise rhe number of interactions between a client and its =
server.

Cheers,
Igor
From:Per =
Hedeland
To:Xufeng =
Liu,
Cc:netconf@ietf.org,'NetMod =
WG',
Date:2017-10-08 =
14:01:27
Subject:Re: [Netconf] [netmod] Retrieving Information =
Pointed by leafref
 
=

On 2017-10-06 =
23:11, Xufeng Liu wrote:
> During the design team discussion for =
TE and MPLS YANG modeling, we have received a request from implementers: =
How to minimize the number of NETCONF/RESTCONF RPCs to improve operation =
efficiency? 
> Especially for the case when the operator or client =
software needs to retrieve the object contents pointed by a =
leafref.
> 
> For example, given the following simplified TE =
tunnel model,
> 
> +--rw te
> =

>      +--rw explicit-paths
> =

>      |  +--rw explicit-path* =
[name]
> 
>      =
|     +--rw =
name           &nb=
sp;          string
> =

>      =
|        +--rw explicit-route-object* =
[index]
> 
>      =
|           +--rw =
index           &n=
bsp;       uint32
> =

>      =
|           +--rw =
explicit-route-usage?   identityref
> =

>      +--rw tunnels
> =

>      |  +--rw tunnel* =
[name]
> 
>      |  |  =
+--rw =
name           &nb=
sp;       string
> =

>      |  |  +--rw =
paths
> 
>      |  |  =
|  +--rw path* [name]
> 
> |  |  =
|     +--rw explicit-path?  -> =
../../../../../explicit-paths/explicit-path/name
> 
> when =
the client tries to retrieve a tunnels information based on the tunnel =
name, the get operation returns a list of leafrefs pointing to the =
paths of the tunnel.

Sorry, I'm afraid I don't follow. Can you =
explain exactly what your
"get" request is (protocol and =
payload), and where the "list of
leafref's" (whatever that =
may be) occurs in the reply?
[Xufeng]  The “get” operation =
is the NETCONF/RESTCON <get> protocol operation, or the =
<get-data> operation described in https://tools.ietf.org/htm=
l/draft-dsdt-nmda-netconf-01 and the GET operations on =
{+restconf}/ds/<datastore> described in  =
https://tools.ietf.org/htm=
l/draft-ietf-netconf-nmda-restconf-00.
<=
p class=3DMsoNormal> 
We have a list of leafref values because in this =
example model, each tunnel contains a list of paths, each of them =
contains a leafref. The “get” returns a value for each =
instance of such a leafref, which (as a string value) will be used as a =
constraint (foreign key) to retrieve the instance of an explicit-path in =
the model above.


JFYI, in case there is some =
fundamental misunderstanding here: a leaf of
type leafref has a =
single value - *one* of those that satisfy the leafref
constraint, in =
case there are multiple "candidates".

--Per

> =
The client needs to issue at 
> least one more get operation =
to retrieve the path information about the given tunnel. The request is =
to combine these two operations into one.
> 
> In the RDBMS =
SQL world, join can be used when SQL select is performed, but =
NETCONF/YANG currently does not have this capability.
> 
> =
Wed like to ask whether such a request is considered reasonable.
> =

> If the request is reasonable, the next question is how to =
proceed. This seems to be a protocol issue rather than YANG modeling =
issue. Is it acceptable to add a new operation to achieve such a =

> <get-data> operation with expanded leafrefs?
> =

> Comments and suggestions are appreciated.
> 
> =
Thanks,
> 
> - Xufeng
> 
> 
> 
> =
_______________________________________________
> netmod mailing =
list
> netmod@ietf.org
> https://www.ietf.or=
g/mailman/listinfo/netmod
> =


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

------=_NextPart_000_0496_01D340E2.E39CB180--


From nobody Mon Oct  9 07:46:20 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE5E1342D1; Mon,  9 Oct 2017 07:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 8BbHsTD-ouLd; Mon,  9 Oct 2017 07:46:09 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18829134520; Mon,  9 Oct 2017 07:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23331; q=dns/txt; s=iport; t=1507560367; x=1508769967; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=PeqmHqHEo4wzGwWA3YGKGzsHeMjGerXRjqjzBqdOA0Y=; b=R5KIl1Uw2LWt3wN3MbE+ew2wvRmlQo8ZAQM4A9W5GY6EsYbryBjKw79k 7npxjuIlzWF6gS24pxwv9L9AKrCUsgJdIhdB6ScNJ4uUeU5KgcnXo/xpy 9nDHvHteWCt0oXTahcMTdWWqHqphBiz8Yw85a/7M3Z2JB/NDU7CmJKYpf 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAACbittZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9BgRFuJ44ZdJBGK3mHTI1qghIKGAEKgV6Ca08ChHUYAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQECAQEBJQZBCwULCxEDAQEBASAHByEGHwkIBgEMBgIBAYoUA?= =?us-ascii?q?w0IEKl5OieHFQ2DVgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgy2DU4FqK4JJNYJ?= =?us-ascii?q?eghA2FoU+BZFAjzk8h16IEIR5i12HLox0gQmHXYE5HziBDjIhCB0VSYUaHIFoP?= =?us-ascii?q?zYBAYloAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,500,1500940800";  d="scan'208,217";a="656250473"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2017 14:46:04 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v99Ek47S018009; Mon, 9 Oct 2017 14:46:04 GMT
To: Xufeng Liu , "'Igor Bryskin'" , per@tail-f.com
Cc: netconf@ietf.org, netmod@ietf.org
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>    <049501d34104$6aa46670$3fed3350$@gmail.com>
From: Robert Wilton 
Message-ID: 
Date: Mon, 9 Oct 2017 15:46:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <049501d34104$6aa46670$3fed3350$@gmail.com>
Content-Type: multipart/alternative; boundary="------------F86C82F1B87D48DBEC56326C"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 14:46:12 -0000

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

I'm not sure that my XPath foo is good enough, but would NETCONF's XPath 
filter solve this problem?

Thanks,
Rob


On 09/10/2017 14:42, Xufeng Liu wrote:
>
> Hi Per,
>
> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
> *Sent:* Sunday, October 8, 2017 7:04 PM
> *To:* Igor Bryskin ; per@tail-f.com; 
> xufeng.liu.ietf@gmail.com
> *Cc:* netconf@ietf.org; netmod@ietf.org
> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by 
> leafref
>
>
> Hi Joel,
>
> Thanks, I think I didnt explain our problem correctly.
>
> In our case we have a leafref pointing to a te tunnel name, which 
> happens to be a key to lookup the (axilary) tunnel.  We need  a way to 
> include the entire tunnel body (not just a name) into the get 
> response. This is to optimize the number of iterations between the 
> client and the server. As Xufeng put it something similar to SQL join,
>
> Igor
>
> *From:*Igor Bryskin
>
> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>
> *Cc:*netconf@ietf.org,netmod@ietf.org,
>
> *Date:*2017-10-08 17:36:47
>
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
>
> Hi Per,
>
> In a nutshell we would lika for a netconf client to have a way  to 
> instruct the server on whether in response to the get request the 
> server needs to provide the entire body of a datastore node pointed to 
> by a leafref or just a pointer to said node, so that the node's body 
> could be retrieved by a subsequent separate request. This is requested 
> by implementors who want to optimise rhe number of interactions 
> between a client and its server.
>
> Cheers,
> Igor
>
> *From:*Per Hedeland
>
> *To:*Xufeng Liu,
>
> *Cc:*netconf@ietf.org,'NetMod WG',
>
> *Date:*2017-10-08 14:01:27
>
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
>
> On 2017-10-06 23:11, Xufeng Liu wrote:
> > During the design team discussion for TE and MPLS YANG modeling, we 
> have received a request from implementers: How to minimize the number 
> of NETCONF/RESTCONF RPCs to improve operation efficiency?
> > Especially for the case when the operator or client software needs 
> to retrieve the object contents pointed by a leafref.
> >
> > For example, given the following simplified TE tunnel model,
> >
> > +--rw te
> >
> >      +--rw explicit-paths
> >
> >      |  +--rw explicit-path* [name]
> >
> >      |     +--rw name                      string
> >
> >      |        +--rw explicit-route-object* [index]
> >
> >      |           +--rw index uint32
> >
> >      |           +--rw explicit-route-usage? identityref
> >
> >      +--rw tunnels
> >
> >      |  +--rw tunnel* [name]
> >
> >      |  |  +--rw name                   string
> >
> >      |  |  +--rw paths
> >
> >      |  |  |  +--rw path* [name]
> >
> > |  |  |     +--rw explicit-path?  -> 
> ../../../../../explicit-paths/explicit-path/name
> >
> > when the client tries to retrieve a tunnels information based on the 
> tunnel name, the get operation returns a list of leafrefs pointing to 
> the paths of the tunnel.
>
> Sorry, I'm afraid I don't follow. Can you explain exactly what your
> "get" request is (protocol and payload), and where the "list of
> leafref's" (whatever that may be) occurs in the reply?
>
> */[Xufeng]  The “get” operation is the NETCONF/RESTCON  protocol 
> operation, or the  operation described in 
> https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET 
> operations on {+restconf}/ds/ described in 
> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>
> *//*
>
> */We have a list of leafref values because in this example model, each 
> tunnel contains a list of paths, each of them contains a leafref. The 
> “get” returns a value for each instance of such a leafref, which (as a 
> string value) will be used as a constraint (foreign key) to retrieve 
> the instance of an explicit-path in the model above./*
>
>
>
> JFYI, in case there is some fundamental misunderstanding here: a leaf of
> type leafref has a single value - *one* of those that satisfy the leafref
> constraint, in case there are multiple "candidates".
>
> --Per
>
> > The client needs to issue at
> > least one more get operation to retrieve the path information about 
> the given tunnel. The request is to combine these two operations into one.
> >
> > In the RDBMS SQL world, join can be used when SQL select is 
> performed, but NETCONF/YANG currently does not have this capability.
> >
> > Wed like to ask whether such a request is considered reasonable.
> >
> > If the request is reasonable, the next question is how to proceed. 
> This seems to be a protocol issue rather than YANG modeling issue. Is 
> it acceptable to add a new operation to achieve such a
> >  operation with expanded leafrefs?
> >
> > Comments and suggestions are appreciated.
> >
> > Thanks,
> >
> > - Xufeng
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org 
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> _______________________________________________
> 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


--------------F86C82F1B87D48DBEC56326C
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    I'm not sure that my XPath foo is good enough, but would NETCONF's
    XPath filter solve this problem?

    

    Thanks,

    Rob

    

    

    
On 09/10/2017 14:42, Xufeng Liu wrote:

    

    

      
      
      
      

        
Hi Per,

        
 

        

          

            

              
From: Igor Bryskin
                [mailto:Igor.Bryskin@huawei.com] 

                Sent: Sunday, October 8, 2017 7:04 PM

                To: Igor Bryskin <Igor.Bryskin@huawei.com>;
                per@tail-f.com; xufeng.liu.ietf@gmail.com

                Cc: netconf@ietf.org; netmod@ietf.org

                Subject: Re: [Netconf] [netmod] Retrieving
                Information Pointed by leafref

            

          

          
 

          

            


              Hi Joel,

              

              Thanks, I think I didnt explain our problem correctly.

              

              In our case we have a leafref pointing to a te tunnel
              name, which happens to be a key to lookup the (axilary)
              tunnel.  We need  a way to include the entire tunnel body
              (not just a name) into the get response. This is to
              optimize the number of iterations between the client and
              the server. As Xufeng put it something similar to SQL
              join,

              

              Igor

          

          

            

              
From:Igor Bryskin

            

            
            
            

              
Date:2017-10-08 17:36:47

            

            

              
Subject:Re: [Netconf] [netmod]
                  Retrieving Information Pointed by leafref

            

            

              
 

            

          

          

            

              

                
Hi Per,

                  

                  In a nutshell we would lika for a netconf client to
                  have a way  to instruct the server on whether in
                  response to the get request the server needs to
                  provide the entire body of a datastore node pointed to
                  by a leafref or just a pointer to said node, so that
                  the node's body could be retrieved by a subsequent
                  separate request. This is requested by implementors
                  who want to optimise rhe number of interactions
                  between a client and its server.

                  

                  Cheers,

                  Igor

              

              

                

                  
From:Per Hedeland

                

                

                  
To:Xufeng Liu,

                

                

                  
Cc:netconf@ietf.org,'NetMod
                      WG',

                

                

                  
Date:2017-10-08 14:01:27

                

                

                  
Subject:Re: [Netconf] [netmod]
                      Retrieving Information Pointed by leafref

                

                

                  
 

                

              

            

            

              
On
                  2017-10-06 23:11, Xufeng Liu wrote:

                  > During the design team discussion for TE and MPLS
                  YANG modeling, we have received a request from
                  implementers: How to minimize the number of
                  NETCONF/RESTCONF RPCs to improve operation efficiency?
                  

                  > Especially for the case when the operator or
                  client software needs to retrieve the object contents
                  pointed by a leafref.

                  > 

                  > For example, given the following simplified TE
                  tunnel model,

                  > 

                  > +--rw te

                  > 

                  >      +--rw explicit-paths

                  > 

                  >      |  +--rw explicit-path* [name]

                  > 

                  >      |     +--rw name                      string

                  > 

                  >      |        +--rw explicit-route-object*
                  [index]

                  > 

                  >      |           +--rw index                  
                  uint32

                  > 

                  >      |           +--rw explicit-route-usage?  
                  identityref

                  > 

                  >      +--rw tunnels

                  > 

                  >      |  +--rw tunnel* [name]

                  > 

                  >      |  |  +--rw name                   string

                  > 

                  >      |  |  +--rw paths

                  > 

                  >      |  |  |  +--rw path* [name]

                  > 

                  > |  |  |     +--rw explicit-path?  ->
                  ../../../../../explicit-paths/explicit-path/name

                  > 

                  > when the client tries to retrieve a tunnels
                  information based on the tunnel name, the get
                  operation returns a list of leafrefs pointing to the
                  paths of the tunnel.

                  

                  Sorry, I'm afraid I don't follow. Can you explain
                  exactly what your

                  "get" request is (protocol and payload), and where the
                  "list of

                  leafref's" (whatever that may be) occurs in the reply?

              
[Xufeng]  The “get” operation
                    is the NETCONF/RESTCON <get> protocol
                    operation, or the <get-data> operation
                    described in https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01
                    and the GET operations on
                    {+restconf}/ds/<datastore> described in  https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00.

              
 

              
We have a list of leafref
                    values because in this example model, each tunnel
                    contains a list of paths, each of them contains a
                    leafref. The “get” returns a value for each instance
                    of such a leafref, which (as a string value) will be
                    used as a constraint (foreign key) to retrieve the
                    instance of an explicit-path in the model above.

              


                  

                  JFYI, in case there is some fundamental
                  misunderstanding here: a leaf of

                  type leafref has a single value - *one* of those that
                  satisfy the leafref

                  constraint, in case there are multiple "candidates".

                  

                  --Per

                  

                  > The client needs to issue at 

                  > least one more get operation to retrieve the
                  path information about the given tunnel. The request
                  is to combine these two operations into one.

                  > 

                  > In the RDBMS SQL world, join can be used when
                  SQL select is performed, but NETCONF/YANG currently
                  does not have this capability.

                  > 

                  > Wed like to ask whether such a request is
                  considered reasonable.

                  > 

                  > If the request is reasonable, the next question
                  is how to proceed. This seems to be a protocol issue
                  rather than YANG modeling issue. Is it acceptable to
                  add a new operation to achieve such a 

                  > <get-data> operation with expanded
                  leafrefs?

                  > 

                  > Comments and suggestions are appreciated.

                  > 

                  > Thanks,

                  > 

                  > - Xufeng

                  > 

                  > 

                  > 

                  > _______________________________________________

                  > netmod mailing list

                  > netmod@ietf.org

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

                  > 

                  

                  _______________________________________________

                  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


    

    

  


--------------F86C82F1B87D48DBEC56326C--


From nobody Mon Oct  9 09:09:18 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DD7134642; Mon,  9 Oct 2017 09:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDx91TEjVktM; Mon,  9 Oct 2017 09:09:08 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D966134FCF; Mon,  9 Oct 2017 09:05:44 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.51]) by mail.tail-f.com (Postfix) with ESMTPSA id A45BD1AE0402; Mon,  9 Oct 2017 18:05:41 +0200 (CEST)
To: Xufeng Liu 
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>    <049501d34104$6aa46670$3fed3350$@gmail.com>
Cc: 'Igor Bryskin' , netconf@ietf.org, netmod@ietf.org
From: Per Hedeland 
Message-ID: <59DB9E54.8080805@tail-f.com>
Date: Mon, 9 Oct 2017 18:05:40 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <049501d34104$6aa46670$3fed3350$@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 16:09:11 -0000

I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path could
be for a non-key leaf, and/or the path could traverse list nodes, and/or
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.

Thus it seems to me that your use case is not a reasonable basis for a
new protocol operation. My XPath foo isn't very good either, but I do
believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along the
lines of

 /te/tunnels/tunnel[name='foo'] | /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]

--Per

On 2017-10-09 15:42, Xufeng Liu wrote:
> Hi Per,
> 
>  
> 
> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
> *Sent:* Sunday, October 8, 2017 7:04 PM
> *To:* Igor Bryskin ; per@tail-f.com; xufeng.liu.ietf@gmail.com
> *Cc:* netconf@ietf.org; netmod@ietf.org
> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
> 
>  
> 
> 
> Hi Joel,
> 
> Thanks, I think I didnt explain our problem correctly.
> 
> In our case we have a leafref pointing to a te tunnel name, which happens to be a key to lookup the (axilary) tunnel.  We need  a way to include the entire tunnel body (not just a name) into the get
> response. This is to optimize the number of iterations between the client and the server. As Xufeng put it something similar to SQL join,
> 
> Igor
> 
> *From:*Igor Bryskin
> 
> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
> 
> *Cc:*netconf@ietf.org,netmod@ietf.org,
> 
> *Date:*2017-10-08 17:36:47
> 
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
> 
>  
> 
> Hi Per,
> 
> In a nutshell we would lika for a netconf client to have a way  to instruct the server on whether in response to the get request the server needs to provide the entire body of a datastore node pointed
> to by a leafref or just a pointer to said node, so that the node's body could be retrieved by a subsequent separate request. This is requested by implementors who want to optimise rhe number of
> interactions between a client and its server.
> 
> Cheers,
> Igor
> 
> *From:*Per Hedeland
> 
> *To:*Xufeng Liu,
> 
> *Cc:*netconf@ietf.org,'NetMod WG',
> 
> *Date:*2017-10-08 14:01:27
> 
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
> 
>  
> 
> On 2017-10-06 23:11, Xufeng Liu wrote:
>> During the design team discussion for TE and MPLS YANG modeling, we have received a request from implementers: How to minimize the number of NETCONF/RESTCONF RPCs to improve operation efficiency? 
>> Especially for the case when the operator or client software needs to retrieve the object contents pointed by a leafref.
>> 
>> For example, given the following simplified TE tunnel model,
>> 
>> +--rw te
>> 
>>      +--rw explicit-paths
>> 
>>      |  +--rw explicit-path* [name]
>> 
>>      |     +--rw name                      string
>> 
>>      |        +--rw explicit-route-object* [index]
>> 
>>      |           +--rw index                   uint32
>> 
>>      |           +--rw explicit-route-usage?   identityref
>> 
>>      +--rw tunnels
>> 
>>      |  +--rw tunnel* [name]
>> 
>>      |  |  +--rw name                   string
>> 
>>      |  |  +--rw paths
>> 
>>      |  |  |  +--rw path* [name]
>> 
>> |  |  |     +--rw explicit-path?  -> ../../../../../explicit-paths/explicit-path/name
>> 
>> when the client tries to retrieve a tunnels information based on the tunnel name, the get operation returns a list of leafrefs pointing to the paths of the tunnel.
> 
> Sorry, I'm afraid I don't follow. Can you explain exactly what your
> "get" request is (protocol and payload), and where the "list of
> leafref's" (whatever that may be) occurs in the reply?
> 
> */[Xufeng]  The get operation is the NETCONF/RESTCON  protocol operation, or the  operation described in https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET operations
> on {+restconf}/ds/ described in  https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
> 
> */ /*
> 
> */We have a list of leafref values because in this example model, each tunnel contains a list of paths, each of them contains a leafref. The get returns a value for each instance of such a leafref,
> which (as a string value) will be used as a constraint (foreign key) to retrieve the instance of an explicit-path in the model above./*
> 
> 
> 
> JFYI, in case there is some fundamental misunderstanding here: a leaf of
> type leafref has a single value - *one* of those that satisfy the leafref
> constraint, in case there are multiple "candidates".
> 
> --Per
> 
>> The client needs to issue at 
>> least one more get operation to retrieve the path information about the given tunnel. The request is to combine these two operations into one.
>> 
>> In the RDBMS SQL world, join can be used when SQL select is performed, but NETCONF/YANG currently does not have this capability.
>> 
>> Wed like to ask whether such a request is considered reasonable.
>> 
>> If the request is reasonable, the next question is how to proceed. This seems to be a protocol issue rather than YANG modeling issue. Is it acceptable to add a new operation to achieve such a 
>>  operation with expanded leafrefs?
>> 
>> Comments and suggestions are appreciated.
>> 
>> Thanks,
>> 
>> - Xufeng
>> 
>> 
>> 
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf
> 


From nobody Mon Oct  9 10:08:14 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F79813470B; Mon,  9 Oct 2017 10:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-eoJ0Dkrig3; Mon,  9 Oct 2017 10:08:06 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5A91346E1; Mon,  9 Oct 2017 10:08:05 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXF26777; Mon, 09 Oct 2017 17:08:02 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 18:08:01 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 10:07:55 -0700
From: Igor Bryskin 
To: Per Hedeland , Xufeng Liu 
CC: "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/gBsqhSA///GxXmAABh1KIABatEAgAAoFACAAGilEA==
Date: Mon, 9 Oct 2017 17:07:54 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com>
References: <033601d33ee7$bd359810$37a0c830$@gmail.com>    <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com>
In-Reply-To: <59DB9E54.8080805@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.154.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59DBACF3.0022, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f06b03e3335ab3f1842511953643139d
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 17:08:08 -0000

Hi Per,

Basically, what we need is a way for a client to request something like thi=
s:

get  joint with 

with a server interpreting the request as follows:
if a node pointed by XPath contains a pointer (e.g. key leafref) matching o=
ne of the XPath from the "joint with" list, then the server must provide th=
e entire body of the node pointed by the pointer, otherwise, just the point=
er (as it happens today, that is, when no "joint with" list specified).

We think that this would allow for the client to optimize the number of req=
uest-response iterations depending on application/use case.

Regards,
Igor =20






-----Original Message-----
From: Per Hedeland [mailto:per@tail-f.com]=20
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path could
be for a non-key leaf, and/or the path could traverse list nodes, and/or
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.

Thus it seems to me that your use case is not a reasonable basis for a
new protocol operation. My XPath foo isn't very good either, but I do
believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along the
lines of

 /te/tunnels/tunnel[name=3D'foo'] | /te/explicit-paths/explicit-path[name=
=3D/te/tunnels/tunnel[name=3D'foo']/paths/path/explicit-path]

--Per

On 2017-10-09 15:42, Xufeng Liu wrote:
> Hi Per,
>=20
> =20
>=20
> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
> *Sent:* Sunday, October 8, 2017 7:04 PM
> *To:* Igor Bryskin ; per@tail-f.com; xufeng.liu.=
ietf@gmail.com
> *Cc:* netconf@ietf.org; netmod@ietf.org
> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by leafr=
ef
>=20
> =20
>=20
>=20
> Hi Joel,
>=20
> Thanks, I think I didnt explain our problem correctly.
>=20
> In our case we have a leafref pointing to a te tunnel name, which happens=
 to be a key to lookup the (axilary) tunnel.  We need  a way to include the=
 entire tunnel body (not just a name) into the get
> response. This is to optimize the number of iterations between the client=
 and the server. As Xufeng put it something similar to SQL join,
>=20
> Igor
>=20
> *From:*Igor Bryskin
>=20
> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>=20
> *Cc:*netconf@ietf.org,netmod@ietf.org,
>=20
> *Date:*2017-10-08 17:36:47
>=20
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafre=
f
>=20
> =20
>=20
> Hi Per,
>=20
> In a nutshell we would lika for a netconf client to have a way  to instru=
ct the server on whether in response to the get request the server needs to=
 provide the entire body of a datastore node pointed
> to by a leafref or just a pointer to said node, so that the node's body c=
ould be retrieved by a subsequent separate request. This is requested by im=
plementors who want to optimise rhe number of
> interactions between a client and its server.
>=20
> Cheers,
> Igor
>=20
> *From:*Per Hedeland
>=20
> *To:*Xufeng Liu,
>=20
> *Cc:*netconf@ietf.org,'NetMod WG',
>=20
> *Date:*2017-10-08 14:01:27
>=20
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafre=
f
>=20
> =20
>=20
> On 2017-10-06 23:11, Xufeng Liu wrote:
>> During the design team discussion for TE and MPLS YANG modeling, we have=
 received a request from implementers: How to minimize the number of NETCON=
F/RESTCONF RPCs to improve operation efficiency?=20
>> Especially for the case when the operator or client software needs to re=
trieve the object contents pointed by a leafref.
>>=20
>> For example, given the following simplified TE tunnel model,
>>=20
>> +--rw te
>>=20
>>      +--rw explicit-paths
>>=20
>>      |  +--rw explicit-path* [name]
>>=20
>>      |     +--rw name                      string
>>=20
>>      |        +--rw explicit-route-object* [index]
>>=20
>>      |           +--rw index                   uint32
>>=20
>>      |           +--rw explicit-route-usage?   identityref
>>=20
>>      +--rw tunnels
>>=20
>>      |  +--rw tunnel* [name]
>>=20
>>      |  |  +--rw name                   string
>>=20
>>      |  |  +--rw paths
>>=20
>>      |  |  |  +--rw path* [name]
>>=20
>> |  |  |     +--rw explicit-path?  -> ../../../../../explicit-paths/expli=
cit-path/name
>>=20
>> when the client tries to retrieve a tunnels information based on the tun=
nel name, the =1Cget operation returns a list of leafrefs pointing to the p=
aths of the tunnel.
>=20
> Sorry, I'm afraid I don't follow. Can you explain exactly what your
> "get" request is (protocol and payload), and where the "list of
> leafref's" (whatever that may be) occurs in the reply?
>=20
> */[Xufeng]  The =1Cget=1D operation is the NETCONF/RESTCON  protocol=
 operation, or the  operation described in https://tools.ietf.org=
/html/draft-dsdt-nmda-netconf-01 and the GET operations
> on {+restconf}/ds/ described in  https://tools.ietf.org/html/d=
raft-ietf-netconf-nmda-restconf-00./*
>=20
> */ /*
>=20
> */We have a list of leafref values because in this example model, each tu=
nnel contains a list of paths, each of them contains a leafref. The =1Cget=
=1D returns a value for each instance of such a leafref,
> which (as a string value) will be used as a constraint (foreign key) to r=
etrieve the instance of an explicit-path in the model above./*
>=20
>=20
>=20
> JFYI, in case there is some fundamental misunderstanding here: a leaf of
> type leafref has a single value - *one* of those that satisfy the leafref
> constraint, in case there are multiple "candidates".
>=20
> --Per
>=20
>> The client needs to issue at=20
>> least one more =1Cget operation to retrieve the path information about t=
he given tunnel. The request is to combine these two operations into one.
>>=20
>> In the RDBMS SQL world, =1Cjoin can be used when SQL =1Cselect is perfor=
med, but NETCONF/YANG currently does not have this capability.
>>=20
>> Wed like to ask whether such a request is considered reasonable.
>>=20
>> If the request is reasonable, the next question is how to proceed. This =
seems to be a protocol issue rather than YANG modeling issue. Is it accepta=
ble to add a new operation to achieve such a=20
>>  operation with expanded leafrefs?
>>=20
>> Comments and suggestions are appreciated.
>>=20
>> Thanks,
>>=20
>> - Xufeng
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf
>=20


From nobody Mon Oct  9 10:13:58 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0122D134710; Mon,  9 Oct 2017 10:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFuIKEmTpRbx; Mon,  9 Oct 2017 10:13:53 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EDCE3133087; Mon,  9 Oct 2017 10:13:48 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 243FC1AE0402; Mon,  9 Oct 2017 19:13:48 +0200 (CEST)
Date: Mon, 09 Oct 2017 19:13:47 +0200 (CEST)
Message-Id: <20171009.191347.1897981146275128665.mbj@tail-f.com>
To: Igor.Bryskin@huawei.com
Cc: per@tail-f.com, xufeng.liu.ietf@gmail.com, netconf@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com>
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.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]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 17:13:56 -0000

Igor Bryskin  wrote:
> 
> Hi Per,
> 
> Basically, what we need is a way for a client to request something
> like this:
> 
> get  joint with 

... which is what Per's expression does!  Note that "|" in XPath means
"union".

But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").

> with a server interpreting the request as follows:
> if a node pointed by XPath contains a pointer (e.g. key leafref)
> matching one of the XPath from the "joint with" list, then the server
> must provide the entire body of the node pointed by the pointer,
> otherwise, just the pointer (as it happens today, that is, when no
> "joint with" list specified).
> 
> We think that this would allow for the client to optimize the number
> of request-response iterations depending on application/use case.
> 
> Regards,
> Igor  



/martin


> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Per Hedeland [mailto:per@tail-f.com] 
> Sent: Monday, October 09, 2017 12:06 PM
> To: Xufeng Liu
> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
> leafref
> 
> I understand your use case, but a leaf of type leafref does not in
> general identify a single node in the data tree - the leafref path
> could
> be for a non-key leaf, and/or the path could traverse list nodes,
> and/or
> the "target" list could have multiple keys and thus multiple
> leafref-leafs be required to identify a specific list entry.
> 
> Thus it seems to me that your use case is not a reasonable basis for a
> new protocol operation. My XPath foo isn't very good either, but I do
> believe Robert's suggestion of using an XPath filter could be a way
> forward. I *think* the filter expression would be something along the
> lines of
> 
>  /te/tunnels/tunnel[name='foo'] |
>  /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]
> 
> --Per
> 
> On 2017-10-09 15:42, Xufeng Liu wrote:
> > Hi Per,
> > 
> >  
> > 
> > *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
> > *Sent:* Sunday, October 8, 2017 7:04 PM
> > *To:* Igor Bryskin ; per@tail-f.com;
> > *xufeng.liu.ietf@gmail.com
> > *Cc:* netconf@ietf.org; netmod@ietf.org
> > *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
> > *leafref
> > 
> >  
> > 
> > 
> > Hi Joel,
> > 
> > Thanks, I think I didnt explain our problem correctly.
> > 
> > In our case we have a leafref pointing to a te tunnel name, which
> > happens to be a key to lookup the (axilary) tunnel.  We need a way to
> > include the entire tunnel body (not just a name) into the get
> > response. This is to optimize the number of iterations between the
> > client and the server. As Xufeng put it something similar to SQL join,
> > 
> > Igor
> > 
> > *From:*Igor Bryskin
> > 
> > *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
> > 
> > *Cc:*netconf@ietf.org,netmod@ietf.org,
> > 
> > *Date:*2017-10-08 17:36:47
> > 
> > *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
> > *leafref
> > 
> >  
> > 
> > Hi Per,
> > 
> > In a nutshell we would lika for a netconf client to have a way to
> > instruct the server on whether in response to the get request the
> > server needs to provide the entire body of a datastore node pointed
> > to by a leafref or just a pointer to said node, so that the node's
> > body could be retrieved by a subsequent separate request. This is
> > requested by implementors who want to optimise rhe number of
> > interactions between a client and its server.
> > 
> > Cheers,
> > Igor
> > 
> > *From:*Per Hedeland
> > 
> > *To:*Xufeng Liu,
> > 
> > *Cc:*netconf@ietf.org,'NetMod WG',
> > 
> > *Date:*2017-10-08 14:01:27
> > 
> > *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
> > *leafref
> > 
> >  
> > 
> > On 2017-10-06 23:11, Xufeng Liu wrote:
> >> During the design team discussion for TE and MPLS YANG modeling, we
> >> have received a request from implementers: How to minimize the number
> >> of NETCONF/RESTCONF RPCs to improve operation efficiency?
> >> Especially for the case when the operator or client software needs to
> >> retrieve the object contents pointed by a leafref.
> >> 
> >> For example, given the following simplified TE tunnel model,
> >> 
> >> +--rw te
> >> 
> >>      +--rw explicit-paths
> >> 
> >>      |  +--rw explicit-path* [name]
> >> 
> >>      |     +--rw name                      string
> >> 
> >>      |        +--rw explicit-route-object* [index]
> >> 
> >>      |           +--rw index                   uint32
> >> 
> >>      |           +--rw explicit-route-usage?   identityref
> >> 
> >>      +--rw tunnels
> >> 
> >>      |  +--rw tunnel* [name]
> >> 
> >>      |  |  +--rw name                   string
> >> 
> >>      |  |  +--rw paths
> >> 
> >>      |  |  |  +--rw path* [name]
> >> 
> >> |  |  |     +--rw explicit-path?  ->
> >> |  |  |     ../../../../../explicit-paths/explicit-path/name
> >> 
> >> when the client tries to retrieve a tunnels information based on the
> >> tunnel name, the get operation returns a list of leafrefs pointing
> >> to the paths of the tunnel.
> > 
> > Sorry, I'm afraid I don't follow. Can you explain exactly what your
> > "get" request is (protocol and payload), and where the "list of
> > leafref's" (whatever that may be) occurs in the reply?
> > 
> > */[Xufeng] The get operation is the NETCONF/RESTCON  protocol
> > *operation, or the  operation described in
> > *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
> > *operations
> > on {+restconf}/ds/ described in
> > https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
> > 
> > */ /*
> > 
> > */We have a list of leafref values because in this example model, each
> > *tunnel contains a list of paths, each of them contains a leafref. The
> > *get returns a value for each instance of such a leafref,
> > which (as a string value) will be used as a constraint (foreign key)
> > to retrieve the instance of an explicit-path in the model above./*
> > 
> > 
> > 
> > JFYI, in case there is some fundamental misunderstanding here: a leaf
> > of
> > type leafref has a single value - *one* of those that satisfy the
> > leafref
> > constraint, in case there are multiple "candidates".
> > 
> > --Per
> > 
> >> The client needs to issue at 
> >> least one more get operation to retrieve the path information about
> >> the given tunnel. The request is to combine these two operations into
> >> one.
> >> 
> >> In the RDBMS SQL world, join can be used when SQL select is
> >> performed, but NETCONF/YANG currently does not have this capability.
> >> 
> >> Wed like to ask whether such a request is considered reasonable.
> >> 
> >> If the request is reasonable, the next question is how to
> >> proceed. This seems to be a protocol issue rather than YANG modeling
> >> issue. Is it acceptable to add a new operation to achieve such a
> >>  operation with expanded leafrefs?
> >> 
> >> Comments and suggestions are appreciated.
> >> 
> >> Thanks,
> >> 
> >> - Xufeng
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> 
> > 
> > _______________________________________________
> > 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 Mon Oct  9 10:22:44 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58B3134716; Mon,  9 Oct 2017 10:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG7anY5anGiI; Mon,  9 Oct 2017 10:22:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC5D1346FA; Mon,  9 Oct 2017 10:22:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQF11162; Mon, 09 Oct 2017 17:22:15 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 18:22:13 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 10:22:03 -0700
From: Igor Bryskin 
To: Martin Bjorklund 
CC: "per@tail-f.com" , "xufeng.liu.ietf@gmail.com" , "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/gBsqhSA///GxXmAABh1KIABatEAgAAoFACAAGilEP//qmOAgAB07YA=
Date: Mon, 9 Oct 2017 17:22:03 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909CDB2EA@SJCEML702-CHM.china.huawei.com>
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com>
In-Reply-To: <20171009.191347.1897981146275128665.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.154.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59DBB05C.0041, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7079aeb8228ea02727df538f1c1af6e1
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 17:22:41 -0000

> But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").

We think this is good enough. In all other cases leafref is simply not qual=
ified for the expansion.
I am not an expert , but I believe there is a similar capability in SQL, no=
?

Igor

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com]=20
Sent: Monday, October 09, 2017 1:14 PM
To: Igor Bryskin
Cc: per@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org; netmod@iet=
f.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

Igor Bryskin  wrote:
>=20
> Hi Per,
>=20
> Basically, what we need is a way for a client to request something
> like this:
>=20
> get  joint with 

... which is what Per's expression does!  Note that "|" in XPath means
"union".

But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").

> with a server interpreting the request as follows:
> if a node pointed by XPath contains a pointer (e.g. key leafref)
> matching one of the XPath from the "joint with" list, then the server
> must provide the entire body of the node pointed by the pointer,
> otherwise, just the pointer (as it happens today, that is, when no
> "joint with" list specified).
>=20
> We think that this would allow for the client to optimize the number
> of request-response iterations depending on application/use case.
>=20
> Regards,
> Igor =20



/martin


>=20
>=20
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: Per Hedeland [mailto:per@tail-f.com]=20
> Sent: Monday, October 09, 2017 12:06 PM
> To: Xufeng Liu
> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
> leafref
>=20
> I understand your use case, but a leaf of type leafref does not in
> general identify a single node in the data tree - the leafref path
> could
> be for a non-key leaf, and/or the path could traverse list nodes,
> and/or
> the "target" list could have multiple keys and thus multiple
> leafref-leafs be required to identify a specific list entry.
>=20
> Thus it seems to me that your use case is not a reasonable basis for a
> new protocol operation. My XPath foo isn't very good either, but I do
> believe Robert's suggestion of using an XPath filter could be a way
> forward. I *think* the filter expression would be something along the
> lines of
>=20
>  /te/tunnels/tunnel[name=3D'foo'] |
>  /te/explicit-paths/explicit-path[name=3D/te/tunnels/tunnel[name=3D'foo']=
/paths/path/explicit-path]
>=20
> --Per
>=20
> On 2017-10-09 15:42, Xufeng Liu wrote:
> > Hi Per,
> >=20
> > =20
> >=20
> > *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
> > *Sent:* Sunday, October 8, 2017 7:04 PM
> > *To:* Igor Bryskin ; per@tail-f.com;
> > *xufeng.liu.ietf@gmail.com
> > *Cc:* netconf@ietf.org; netmod@ietf.org
> > *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
> > *leafref
> >=20
> > =20
> >=20
> >=20
> > Hi Joel,
> >=20
> > Thanks, I think I didnt explain our problem correctly.
> >=20
> > In our case we have a leafref pointing to a te tunnel name, which
> > happens to be a key to lookup the (axilary) tunnel.  We need a way to
> > include the entire tunnel body (not just a name) into the get
> > response. This is to optimize the number of iterations between the
> > client and the server. As Xufeng put it something similar to SQL join,
> >=20
> > Igor
> >=20
> > *From:*Igor Bryskin
> >=20
> > *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
> >=20
> > *Cc:*netconf@ietf.org,netmod@ietf.org,
> >=20
> > *Date:*2017-10-08 17:36:47
> >=20
> > *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
> > *leafref
> >=20
> > =20
> >=20
> > Hi Per,
> >=20
> > In a nutshell we would lika for a netconf client to have a way to
> > instruct the server on whether in response to the get request the
> > server needs to provide the entire body of a datastore node pointed
> > to by a leafref or just a pointer to said node, so that the node's
> > body could be retrieved by a subsequent separate request. This is
> > requested by implementors who want to optimise rhe number of
> > interactions between a client and its server.
> >=20
> > Cheers,
> > Igor
> >=20
> > *From:*Per Hedeland
> >=20
> > *To:*Xufeng Liu,
> >=20
> > *Cc:*netconf@ietf.org,'NetMod WG',
> >=20
> > *Date:*2017-10-08 14:01:27
> >=20
> > *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
> > *leafref
> >=20
> > =20
> >=20
> > On 2017-10-06 23:11, Xufeng Liu wrote:
> >> During the design team discussion for TE and MPLS YANG modeling, we
> >> have received a request from implementers: How to minimize the number
> >> of NETCONF/RESTCONF RPCs to improve operation efficiency?
> >> Especially for the case when the operator or client software needs to
> >> retrieve the object contents pointed by a leafref.
> >>=20
> >> For example, given the following simplified TE tunnel model,
> >>=20
> >> +--rw te
> >>=20
> >>      +--rw explicit-paths
> >>=20
> >>      |  +--rw explicit-path* [name]
> >>=20
> >>      |     +--rw name                      string
> >>=20
> >>      |        +--rw explicit-route-object* [index]
> >>=20
> >>      |           +--rw index                   uint32
> >>=20
> >>      |           +--rw explicit-route-usage?   identityref
> >>=20
> >>      +--rw tunnels
> >>=20
> >>      |  +--rw tunnel* [name]
> >>=20
> >>      |  |  +--rw name                   string
> >>=20
> >>      |  |  +--rw paths
> >>=20
> >>      |  |  |  +--rw path* [name]
> >>=20
> >> |  |  |     +--rw explicit-path?  ->
> >> |  |  |     ../../../../../explicit-paths/explicit-path/name
> >>=20
> >> when the client tries to retrieve a tunnels information based on the
> >> tunnel name, the =1Cget operation returns a list of leafrefs pointing
> >> to the paths of the tunnel.
> >=20
> > Sorry, I'm afraid I don't follow. Can you explain exactly what your
> > "get" request is (protocol and payload), and where the "list of
> > leafref's" (whatever that may be) occurs in the reply?
> >=20
> > */[Xufeng] The =1Cget=1D operation is the NETCONF/RESTCON  protoco=
l
> > *operation, or the  operation described in
> > *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
> > *operations
> > on {+restconf}/ds/ described in
> > https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
> >=20
> > */ /*
> >=20
> > */We have a list of leafref values because in this example model, each
> > *tunnel contains a list of paths, each of them contains a leafref. The
> > *=1Cget=1D returns a value for each instance of such a leafref,
> > which (as a string value) will be used as a constraint (foreign key)
> > to retrieve the instance of an explicit-path in the model above./*
> >=20
> >=20
> >=20
> > JFYI, in case there is some fundamental misunderstanding here: a leaf
> > of
> > type leafref has a single value - *one* of those that satisfy the
> > leafref
> > constraint, in case there are multiple "candidates".
> >=20
> > --Per
> >=20
> >> The client needs to issue at=20
> >> least one more =1Cget operation to retrieve the path information about
> >> the given tunnel. The request is to combine these two operations into
> >> one.
> >>=20
> >> In the RDBMS SQL world, =1Cjoin can be used when SQL =1Cselect is
> >> performed, but NETCONF/YANG currently does not have this capability.
> >>=20
> >> Wed like to ask whether such a request is considered reasonable.
> >>=20
> >> If the request is reasonable, the next question is how to
> >> proceed. This seems to be a protocol issue rather than YANG modeling
> >> issue. Is it acceptable to add a new operation to achieve such a
> >>  operation with expanded leafrefs?
> >>=20
> >> Comments and suggestions are appreciated.
> >>=20
> >> Thanks,
> >>=20
> >> - Xufeng
> >>=20
> >>=20
> >>=20
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>=20
> >=20
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org 
> > https://www.ietf.org/mailman/listinfo/netconf
> >=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>=20


From nobody Mon Oct  9 12:12:18 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655F2126DFE; Mon,  9 Oct 2017 12:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opEIxg5M_dvi; Mon,  9 Oct 2017 12:12:09 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7831286C7; Mon,  9 Oct 2017 12:12:09 -0700 (PDT)
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 B48A91AE0402; Mon,  9 Oct 2017 21:12:07 +0200 (CEST)
To: Martin Bjorklund 
Cc: Igor.Bryskin@huawei.com, xufeng.liu.ietf@gmail.com, netconf@ietf.org, netmod@ietf.org
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com>
From: Per Hedeland 
Message-ID: <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>
Date: Mon, 9 Oct 2017 21:12:07 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20171009.191347.1897981146275128665.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 19:12:12 -0000

On 2017-10-09 19:13, Martin Bjorklund wrote:
> Igor Bryskin  wrote:
>>
>> Hi Per,
>>
>> Basically, what we need is a way for a client to request something
>> like this:
>>
>> get  joint with 
> 
> ... which is what Per's expression does!  Note that "|" in XPath means
> "union".
> 
> But as Per explained, it only works in some cases (when the leafref
> acts a "single pointer").

Well, that particular expression works only in that case - but since it
is effectively the client that (perhaps based on the data model) decides
what the leafref-leafs "mean" (in this case the single key of a single
list), other cases can be handled the same way. E.g. multiple
leafref-to-key leafs that together give the keys of a multi-key list
just amounts to a slightly hairier XPath filter...

--Per

>> with a server interpreting the request as follows:
>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>> matching one of the XPath from the "joint with" list, then the server
>> must provide the entire body of the node pointed by the pointer,
>> otherwise, just the pointer (as it happens today, that is, when no
>> "joint with" list specified).
>>
>> We think that this would allow for the client to optimize the number
>> of request-response iterations depending on application/use case.
>>
>> Regards,
>> Igor
> 
> 
> 
> /martin
> 
> 
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Per Hedeland [mailto:per@tail-f.com]
>> Sent: Monday, October 09, 2017 12:06 PM
>> To: Xufeng Liu
>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>> leafref
>>
>> I understand your use case, but a leaf of type leafref does not in
>> general identify a single node in the data tree - the leafref path
>> could
>> be for a non-key leaf, and/or the path could traverse list nodes,
>> and/or
>> the "target" list could have multiple keys and thus multiple
>> leafref-leafs be required to identify a specific list entry.
>>
>> Thus it seems to me that your use case is not a reasonable basis for a
>> new protocol operation. My XPath foo isn't very good either, but I do
>> believe Robert's suggestion of using an XPath filter could be a way
>> forward. I *think* the filter expression would be something along the
>> lines of
>>
>>   /te/tunnels/tunnel[name='foo'] |
>>   /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]
>>
>> --Per
>>
>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>> Hi Per,
>>>
>>>   
>>>
>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>> *To:* Igor Bryskin ; per@tail-f.com;
>>> *xufeng.liu.ietf@gmail.com
>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
>>> *leafref
>>>
>>>   
>>>
>>>
>>> Hi Joel,
>>>
>>> Thanks, I think I didnt explain our problem correctly.
>>>
>>> In our case we have a leafref pointing to a te tunnel name, which
>>> happens to be a key to lookup the (axilary) tunnel.  We need a way to
>>> include the entire tunnel body (not just a name) into the get
>>> response. This is to optimize the number of iterations between the
>>> client and the server. As Xufeng put it something similar to SQL join,
>>>
>>> Igor
>>>
>>> *From:*Igor Bryskin
>>>
>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>
>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>
>>> *Date:*2017-10-08 17:36:47
>>>
>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>> *leafref
>>>
>>>   
>>>
>>> Hi Per,
>>>
>>> In a nutshell we would lika for a netconf client to have a way to
>>> instruct the server on whether in response to the get request the
>>> server needs to provide the entire body of a datastore node pointed
>>> to by a leafref or just a pointer to said node, so that the node's
>>> body could be retrieved by a subsequent separate request. This is
>>> requested by implementors who want to optimise rhe number of
>>> interactions between a client and its server.
>>>
>>> Cheers,
>>> Igor
>>>
>>> *From:*Per Hedeland
>>>
>>> *To:*Xufeng Liu,
>>>
>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>
>>> *Date:*2017-10-08 14:01:27
>>>
>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>> *leafref
>>>
>>>   
>>>
>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>> During the design team discussion for TE and MPLS YANG modeling, we
>>>> have received a request from implementers: How to minimize the number
>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>> Especially for the case when the operator or client software needs to
>>>> retrieve the object contents pointed by a leafref.
>>>>
>>>> For example, given the following simplified TE tunnel model,
>>>>
>>>> +--rw te
>>>>
>>>>       +--rw explicit-paths
>>>>
>>>>       |  +--rw explicit-path* [name]
>>>>
>>>>       |     +--rw name                      string
>>>>
>>>>       |        +--rw explicit-route-object* [index]
>>>>
>>>>       |           +--rw index                   uint32
>>>>
>>>>       |           +--rw explicit-route-usage?   identityref
>>>>
>>>>       +--rw tunnels
>>>>
>>>>       |  +--rw tunnel* [name]
>>>>
>>>>       |  |  +--rw name                   string
>>>>
>>>>       |  |  +--rw paths
>>>>
>>>>       |  |  |  +--rw path* [name]
>>>>
>>>> |  |  |     +--rw explicit-path?  ->
>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>
>>>> when the client tries to retrieve a tunnels information based on the
>>>> tunnel name, the get operation returns a list of leafrefs pointing
>>>> to the paths of the tunnel.
>>>
>>> Sorry, I'm afraid I don't follow. Can you explain exactly what your
>>> "get" request is (protocol and payload), and where the "list of
>>> leafref's" (whatever that may be) occurs in the reply?
>>>
>>> */[Xufeng] The get operation is the NETCONF/RESTCON  protocol
>>> *operation, or the  operation described in
>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
>>> *operations
>>> on {+restconf}/ds/ described in
>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>
>>> */ /*
>>>
>>> */We have a list of leafref values because in this example model, each
>>> *tunnel contains a list of paths, each of them contains a leafref. The
>>> *get returns a value for each instance of such a leafref,
>>> which (as a string value) will be used as a constraint (foreign key)
>>> to retrieve the instance of an explicit-path in the model above./*
>>>
>>>
>>>
>>> JFYI, in case there is some fundamental misunderstanding here: a leaf
>>> of
>>> type leafref has a single value - *one* of those that satisfy the
>>> leafref
>>> constraint, in case there are multiple "candidates".
>>>
>>> --Per
>>>
>>>> The client needs to issue at
>>>> least one more get operation to retrieve the path information about
>>>> the given tunnel. The request is to combine these two operations into
>>>> one.
>>>>
>>>> In the RDBMS SQL world, join can be used when SQL select is
>>>> performed, but NETCONF/YANG currently does not have this capability.
>>>>
>>>> Wed like to ask whether such a request is considered reasonable.
>>>>
>>>> If the request is reasonable, the next question is how to
>>>> proceed. This seems to be a protocol issue rather than YANG modeling
>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>  operation with expanded leafrefs?
>>>>
>>>> Comments and suggestions are appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> - Xufeng
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>
>>> _______________________________________________
>>> 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 Mon Oct  9 12:52:48 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9721C133211; Mon,  9 Oct 2017 12:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juKrTp61AG0d; Mon,  9 Oct 2017 12:52:43 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E632C132332; Mon,  9 Oct 2017 12:52:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQF25096; Mon, 09 Oct 2017 19:52:39 +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.301.0; Mon, 9 Oct 2017 20:52:38 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000;  Mon, 9 Oct 2017 12:52:26 -0700
From: Igor Bryskin 
To: "per@tail-f.com" , "mbj@tail-f.com" 
CC: Igor Bryskin , "xufeng.liu.ietf@gmail.com" , "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/gBsqhSA///GxXmAABh1KIABatEAgAAoFACAAGilEP//qmOAgAAhEID//5Xqmw==
Date: Mon, 9 Oct 2017 19:52:25 +0000
Message-ID: 
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com>, <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>
In-Reply-To: <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_etPan59dbd3668bfdc1a12f7localhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59DBD388.009F, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f33fc7b725f35566479b73ba291ab56a
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 19:52:47 -0000

--_000_etPan59dbd3668bfdc1a12f7localhost_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I agree. For example, a leafref may point not to a singls entity, but to a =
list of entities, and the client might want to expand all of them into the =
joint get response.

Igor

From:Per Hedeland
To:Martin Bjorklund,
Cc:Igor Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,
Date:2017-10-09 15:12:22
Subject:Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

On 2017-10-09 19:13, Martin Bjorklund wrote:
> Igor Bryskin  wrote:
>>
>> Hi Per,
>>
>> Basically, what we need is a way for a client to request something
>> like this:
>>
>> get  joint with 
>
> ... which is what Per's expression does!  Note that "|" in XPath means
> "union".
>
> But as Per explained, it only works in some cases (when the leafref
> acts a "single pointer").

Well, that particular expression works only in that case - but since it
is effectively the client that (perhaps based on the data model) decides
what the leafref-leafs "mean" (in this case the single key of a single
list), other cases can be handled the same way. E.g. multiple
leafref-to-key leafs that together give the keys of a multi-key list
just amounts to a slightly hairier XPath filter...

--Per

>> with a server interpreting the request as follows:
>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>> matching one of the XPath from the "joint with" list, then the server
>> must provide the entire body of the node pointed by the pointer,
>> otherwise, just the pointer (as it happens today, that is, when no
>> "joint with" list specified).
>>
>> We think that this would allow for the client to optimize the number
>> of request-response iterations depending on application/use case.
>>
>> Regards,
>> Igor
>
>
>
> /martin
>
>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Per Hedeland [mailto:per@tail-f.com]
>> Sent: Monday, October 09, 2017 12:06 PM
>> To: Xufeng Liu
>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>> leafref
>>
>> I understand your use case, but a leaf of type leafref does not in
>> general identify a single node in the data tree - the leafref path
>> could
>> be for a non-key leaf, and/or the path could traverse list nodes,
>> and/or
>> the "target" list could have multiple keys and thus multiple
>> leafref-leafs be required to identify a specific list entry.
>>
>> Thus it seems to me that your use case is not a reasonable basis for a
>> new protocol operation. My XPath foo isn't very good either, but I do
>> believe Robert's suggestion of using an XPath filter could be a way
>> forward. I *think* the filter expression would be something along the
>> lines of
>>
>>   /te/tunnels/tunnel[name=3D'foo'] |
>>   /te/explicit-paths/explicit-path[name=3D/te/tunnels/tunnel[name=3D'foo=
']/paths/path/explicit-path]
>>
>> --Per
>>
>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>> Hi Per,
>>>
>>>
>>>
>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>> *To:* Igor Bryskin ; per@tail-f.com;
>>> *xufeng.liu.ietf@gmail.com
>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
>>> *leafref
>>>
>>>
>>>
>>>
>>> Hi Joel,
>>>
>>> Thanks, I think I didnt explain our problem correctly.
>>>
>>> In our case we have a leafref pointing to a te tunnel name, which
>>> happens to be a key to lookup the (axilary) tunnel.  We need a way to
>>> include the entire tunnel body (not just a name) into the get
>>> response. This is to optimize the number of iterations between the
>>> client and the server. As Xufeng put it something similar to SQL join,
>>>
>>> Igor
>>>
>>> *From:*Igor Bryskin
>>>
>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>
>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>
>>> *Date:*2017-10-08 17:36:47
>>>
>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>> *leafref
>>>
>>>
>>>
>>> Hi Per,
>>>
>>> In a nutshell we would lika for a netconf client to have a way to
>>> instruct the server on whether in response to the get request the
>>> server needs to provide the entire body of a datastore node pointed
>>> to by a leafref or just a pointer to said node, so that the node's
>>> body could be retrieved by a subsequent separate request. This is
>>> requested by implementors who want to optimise rhe number of
>>> interactions between a client and its server.
>>>
>>> Cheers,
>>> Igor
>>>
>>> *From:*Per Hedeland
>>>
>>> *To:*Xufeng Liu,
>>>
>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>
>>> *Date:*2017-10-08 14:01:27
>>>
>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>> *leafref
>>>
>>>
>>>
>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>> During the design team discussion for TE and MPLS YANG modeling, we
>>>> have received a request from implementers: How to minimize the number
>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>> Especially for the case when the operator or client software needs to
>>>> retrieve the object contents pointed by a leafref.
>>>>
>>>> For example, given the following simplified TE tunnel model,
>>>>
>>>> +--rw te
>>>>
>>>>       +--rw explicit-paths
>>>>
>>>>       |  +--rw explicit-path* [name]
>>>>
>>>>       |     +--rw name                      string
>>>>
>>>>       |        +--rw explicit-route-object* [index]
>>>>
>>>>       |           +--rw index                   uint32
>>>>
>>>>       |           +--rw explicit-route-usage?   identityref
>>>>
>>>>       +--rw tunnels
>>>>
>>>>       |  +--rw tunnel* [name]
>>>>
>>>>       |  |  +--rw name                   string
>>>>
>>>>       |  |  +--rw paths
>>>>
>>>>       |  |  |  +--rw path* [name]
>>>>
>>>> |  |  |     +--rw explicit-path?  ->
>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>
>>>> when the client tries to retrieve a tunnels information based on the
>>>> tunnel name, the =1Cget operation returns a list of leafrefs pointing
>>>> to the paths of the tunnel.
>>>
>>> Sorry, I'm afraid I don't follow. Can you explain exactly what your
>>> "get" request is (protocol and payload), and where the "list of
>>> leafref's" (whatever that may be) occurs in the reply?
>>>
>>> */[Xufeng] The =1Cget=1D operation is the NETCONF/RESTCON  protoco=
l
>>> *operation, or the  operation described in
>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
>>> *operations
>>> on {+restconf}/ds/ described in
>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>
>>> */ /*
>>>
>>> */We have a list of leafref values because in this example model, each
>>> *tunnel contains a list of paths, each of them contains a leafref. The
>>> *=1Cget=1D returns a value for each instance of such a leafref,
>>> which (as a string value) will be used as a constraint (foreign key)
>>> to retrieve the instance of an explicit-path in the model above./*
>>>
>>>
>>>
>>> JFYI, in case there is some fundamental misunderstanding here: a leaf
>>> of
>>> type leafref has a single value - *one* of those that satisfy the
>>> leafref
>>> constraint, in case there are multiple "candidates".
>>>
>>> --Per
>>>
>>>> The client needs to issue at
>>>> least one more =1Cget operation to retrieve the path information about
>>>> the given tunnel. The request is to combine these two operations into
>>>> one.
>>>>
>>>> In the RDBMS SQL world, =1Cjoin can be used when SQL =1Cselect is
>>>> performed, but NETCONF/YANG currently does not have this capability.
>>>>
>>>> Wed like to ask whether such a request is considered reasonable.
>>>>
>>>> If the request is reasonable, the next question is how to
>>>> proceed. This seems to be a protocol issue rather than YANG modeling
>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>  operation with expanded leafrefs?
>>>>
>>>> Comments and suggestions are appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> - Xufeng
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>
>>> _______________________________________________
>>> 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
>>


--_000_etPan59dbd3668bfdc1a12f7localhost_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











I agree. For example, a leafref may point not to a singls entity, but =
to a list of entities, and the client might want to expand all of them into=
 the joint get response.



Igor








From:Per Hedeland


To:Martin Bjorklund,


Cc:Igor Bryskin,xufeng.liu.ietf@=
gmail.com,netconf@ietf.org,netmod@ietf.org,


Date:2017-10-09 15:12:22


Subject:Re: [Netconf] [netmod] R=
etrieving Information Pointed by leafref












On 2017-10-09 19:13, Martin Bjorklund wrote:

> Igor Bryskin <Igor.Bryskin@huawei.com> wrote:

>>

>> Hi Per,

>>

>> Basically, what we need is a way for a client to request something=


>> like this:

>>

>> get <XPath> joint with <XPath1, XPath2, ..., XPathn>
> 

> ... which is what Per's expression does!  Note that "|"=
 in XPath means

> "union".

> 

> But as Per explained, it only works in some cases (when the leafref
> acts a "single pointer").



Well, that particular expression works only in that case - but since it

is effectively the client that (perhaps based on the data model) decides
what the leafref-leafs "mean" (in this case the single key of a s=
ingle

list), other cases can be handled the same way. E.g. multiple

leafref-to-key leafs that together give the keys of a multi-key list

just amounts to a slightly hairier XPath filter...



--Per



>> with a server interpreting the request as follows:

>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>> matching one of the XPath from the "joint with" list, th=
en the server

>> must provide the entire body of the node pointed by the pointer,
>> otherwise, just the pointer (as it happens today, that is, when no=


>> "joint with" list specified).

>>

>> We think that this would allow for the client to optimize the numb=
er

>> of request-response iterations depending on application/use case.<=
br>
>>

>> Regards,

>> Igor

> 

> 

> 

> /martin

> 

> 

>>

>>

>>

>>

>>

>>

>> -----Original Message-----

>> From: Per Hedeland [mailto:per@t=
ail-f.com]

>> Sent: Monday, October 09, 2017 12:06 PM

>> To: Xufeng Liu

>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org

>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by<=
br>
>> leafref

>>

>> I understand your use case, but a leaf of type leafref does not in=


>> general identify a single node in the data tree - the leafref path=


>> could

>> be for a non-key leaf, and/or the path could traverse list nodes,<=
br>
>> and/or

>> the "target" list could have multiple keys and thus mult=
iple

>> leafref-leafs be required to identify a specific list entry.

>>

>> Thus it seems to me that your use case is not a reasonable basis f=
or a

>> new protocol operation. My XPath foo isn't very good either, but I=
 do

>> believe Robert's suggestion of using an XPath filter could be a wa=
y

>> forward. I *think* the filter expression would be something along =
the

>> lines of

>>

>>   /te/tunnels/tunnel[name=3D'foo'] |

>>   /te/explicit-paths/explicit-path[name=3D/te/tunnels/tu=
nnel[name=3D'foo']/paths/path/explicit-path]

>>

>> --Per

>>

>> On 2017-10-09 15:42, Xufeng Liu wrote:

>>> Hi Per,

>>>

>>>   

>>>

>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]

>>> *Sent:* Sunday, October 8, 2017 7:04 PM

>>> *To:* Igor Bryskin <Igor.Bryskin@huawei.com>; per@tail-f=
.com;

>>> *xufeng.liu.ietf@gmail.com

>>> *Cc:* netconf@ietf.org; netmod@ietf.org

>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Point=
ed by

>>> *leafref

>>>

>>>   

>>>

>>>

>>> Hi Joel,

>>>

>>> Thanks, I think I didnt explain our problem correctly.

>>>

>>> In our case we have a leafref pointing to a te tunnel name, wh=
ich

>>> happens to be a key to lookup the (axilary) tunnel.  We n=
eed a way to

>>> include the entire tunnel body (not just a name) into the get<=
br>
>>> response. This is to optimize the number of iterations between=
 the

>>> client and the server. As Xufeng put it something similar to S=
QL join,

>>>

>>> Igor

>>>

>>> *From:*Igor Bryskin

>>>

>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,

>>>

>>> *Cc:*netconf@ietf.org,netmod@ietf.org,

>>>

>>> *Date:*2017-10-08 17:36:47

>>>

>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointe=
d by

>>> *leafref

>>>

>>>   

>>>

>>> Hi Per,

>>>

>>> In a nutshell we would lika for a netconf client to have a way=
 to

>>> instruct the server on whether in response to the get request =
the

>>> server needs to provide the entire body of a datastore node po=
inted

>>> to by a leafref or just a pointer to said node, so that the no=
de's

>>> body could be retrieved by a subsequent separate request. This=
 is

>>> requested by implementors who want to optimise rhe number of
>>> interactions between a client and its server.

>>>

>>> Cheers,

>>> Igor

>>>

>>> *From:*Per Hedeland

>>>

>>> *To:*Xufeng Liu,

>>>

>>> *Cc:*netconf@ietf.org,'NetMod WG',

>>>

>>> *Date:*2017-10-08 14:01:27

>>>

>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointe=
d by

>>> *leafref

>>>

>>>   

>>>

>>> On 2017-10-06 23:11, Xufeng Liu wrote:

>>>> During the design team discussion for TE and MPLS YANG mod=
eling, we

>>>> have received a request from implementers: How to minimize=
 the number

>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?<=
br>
>>>> Especially for the case when the operator or client softwa=
re needs to

>>>> retrieve the object contents pointed by a leafref.

>>>>

>>>> For example, given the following simplified TE tunnel mode=
l,

>>>>

>>>> +--rw te

>>>>

>>>>       +--rw explicit-pat=
hs

>>>>

>>>>       |  +--rw expl=
icit-path* [name]

>>>>

>>>>       |   &nb=
sp; +--rw name         &nb=
sp;            strin=
g

>>>>

>>>>       |   &nb=
sp;    +--rw explicit-route-object* [index]

>>>>

>>>>       |   &nb=
sp;       +--rw index   &n=
bsp;            =
;   uint32

>>>>

>>>>       |   &nb=
sp;       +--rw explicit-route-usage?&nbs=
p;  identityref

>>>>

>>>>       +--rw tunnels

>>>>

>>>>       |  +--rw tunn=
el* [name]

>>>>

>>>>       |  |  +-=
-rw name           &=
nbsp;       string

>>>>

>>>>       |  |  +-=
-rw paths

>>>>

>>>>       |  |  | =
; +--rw path* [name]

>>>>

>>>> |  |  |     +--rw explic=
it-path?  ->

>>>> |  |  |     ../../../../../e=
xplicit-paths/explicit-path/name

>>>>

>>>> when the client tries to retrieve a tunnels information ba=
sed on the

>>>> tunnel name, the get operation returns a list of leaf=
refs pointing

>>>> to the paths of the tunnel.

>>>

>>> Sorry, I'm afraid I don't follow. Can you explain exactly what=
 your

>>> "get" request is (protocol and payload), and where t=
he "list of

>>> leafref's" (whatever that may be) occurs in the reply?
>>>

>>> */[Xufeng] The get operation is the NETCONF/RESTCON =
<get> protocol

>>> *operation, or the <get-data> operation described in

>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and th=
e GET

>>> *operations

>>> on {+restconf}/ds/<datastore> described in

>>> 
https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*

>>>

>>> */ /*

>>>

>>> */We have a list of leafref values because in this example mod=
el, each

>>> *tunnel contains a list of paths, each of them contains a leaf=
ref. The

>>> *get returns a value for each instance of such a lea=
fref,

>>> which (as a string value) will be used as a constraint (foreig=
n key)

>>> to retrieve the instance of an explicit-path in the model abov=
e./*

>>>

>>>

>>>

>>> JFYI, in case there is some fundamental misunderstanding here:=
 a leaf

>>> of

>>> type leafref has a single value - *one* of those that satisfy =
the

>>> leafref

>>> constraint, in case there are multiple "candidates".=


>>>

>>> --Per

>>>

>>>> The client needs to issue at

>>>> least one more get operation to retrieve the path inf=
ormation about

>>>> the given tunnel. The request is to combine these two oper=
ations into

>>>> one.

>>>>

>>>> In the RDBMS SQL world, join can be used when SQL =
8;select is

>>>> performed, but NETCONF/YANG currently does not have this c=
apability.

>>>>

>>>> Wed like to ask whether such a request is considered reaso=
nable.

>>>>

>>>> If the request is reasonable, the next question is how to<=
br>
>>>> proceed. This seems to be a protocol issue rather than YAN=
G modeling

>>>> issue. Is it acceptable to add a new operation to achieve =
such a

>>>> <get-data> operation with expanded leafrefs?

>>>>

>>>> Comments and suggestions are appreciated.

>>>>

>>>> Thanks,

>>>>

>>>> - Xufeng

>>>>

>>>>

>>>>

>>>> _______________________________________________

>>>> netmod mailing list

>>>> netmod@ietf.org <mai=
lto:netmod@ietf.org>

>>>> h=
ttps://www.ietf.org/mailman/listinfo/netmod

>>>>

>>>

>>> _______________________________________________

>>> Netconf mailing list

>>> Netconf@ietf.org <mailt=
o:Netconf@ietf.org>

>>> http=
s://www.ietf.org/mailman/listinfo/netconf

>>>

>>

>> _______________________________________________

>> Netconf mailing list

>> Netconf@ietf.org

>> https://=
www.ietf.org/mailman/listinfo/netconf

>>









--_000_etPan59dbd3668bfdc1a12f7localhost_--


From nobody Mon Oct  9 14:07:02 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06194134218; Mon,  9 Oct 2017 14:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 NrL0vs5CZ_DR; Mon,  9 Oct 2017 14:06:51 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681BD124B17; Mon,  9 Oct 2017 14:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57275; q=dns/txt; s=iport; t=1507583210; x=1508792810; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=1QpOar5J4Pbeusc35ek8k78oCRUXMtXus0pX8dIXwIY=; b=TA8++2WV5bM5m7AGUt5K7Fnc+aXihFfldnAHL+fWXHjhKrMj5cLkB6M1 HgVOx6uXZB2Dt5/FUaYnxVkcsbYWXdKFqIUirk48Tl2f5WMbcb0prdUAH jJilGtp/zxED9RD5/F6WuoghJuWLJzLR5pWoE6+KnLFpHVP1/mmWyqYC8 0=;
X-IronPort-AV: E=Sophos;i="5.42,501,1500940800";  d="scan'208,217";a="697921366"
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; 09 Oct 2017 21:06:48 +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 v99L6mho012924; Mon, 9 Oct 2017 21:06:48 GMT
To: Robert Wilton , Martin Bjorklund 
Cc: andy@yumaworks.com, acee@cisco.com, netmod@ietf.org, rtg-dt-yang-arch@ietf.org
References:  <87h8w0bbyf.fsf@nic.cz>  <20171006.173244.1167478609964390238.mbj@tail-f.com> <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com>
From: Benoit Claise 
Message-ID: <16eda4e4-5612-918c-9d06-eec39f67e88a@cisco.com>
Date: Mon, 9 Oct 2017 23:06:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com>
Content-Type: multipart/alternative; boundary="------------A719FFE3846AF308C7C7534D"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 21:06:55 -0000

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

On 10/6/2017 6:01 PM, Robert Wilton wrote:
>
>
> On 06/10/2017 16:32, Martin Bjorklund wrote:
>> Benoit Claise  wrote:
>>> Dear all,
>>>
>>> [including the routing and multicast YANG design teams]
>>> Can we please finalize the discussion regarding ietf-routing versus
>>> ietf-routing-2, sooner than later.
>>>
>>> I care about the NMDA transition strategy.
>>>
>>> Here are all the ietf-routing dependent YANG modules (those modules
>>> that depend on ietf-routing)
>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents 
>>>
>>> So many YANG modules.
>>>
>>> Look at the difference for ietf-routing-2:
>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents 
>>>
>>> Some dependent modules are compliant with ietf-routing-2, the
>>> multicast YANG modules, but these are the only ones.
>>>
>>> Changing the module name from ietf-routing to ietf-routing-2 implies
>>> that the we have to warn all draft authors of ietf-routing YANG
>>> dependent modules:
>>>      1. to make sure they are aware of ietf-routing-2 (publishing a
>>> RFC8022bis mentioning in the module description that this module is
>>> not compatible with the NMDA architecture, and providing a pointer to
>>> ietf-routing-2 ... is not an automatic way... so barely useful)
>>>      2. to ask them to change their import to ietf-routing-2
>>> Hopefully, in the routing case, it's mainly the IETF.
>>> I'm glad that we didn't change the ietf-interfaces to
>>> ietf-interfaces-2, we would have to deal with cross
>>> SDO/consortia/opensource project issues
>>> Note:
>>>
>>>     we're in a transition phase today, while we implement the
>>>     soon-to-be-published draft-clacla-netmod-model-catalog-02
>>>     Because of this, the SDO/consortia/opensource dependent YANG 
>>> modules
>>>     will only appear in the Impact Analysis tomorrow at
>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
>>>     In the mean time, you can see all these dependent modules
>>>     Ex:
>>> https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces
>>>              => click on "dependents"
>>>     Those dependent modules is a new feature of
>>>     draft-clacla-netmod-model-catalog-02
>>>
>>>
>>> I'm wondering if this NMDA transition hurdle doesn't make a good
>>> justification to keep the same module name!
>>> We could debate whether ietf-routing is implemented or not, but the
>>> point is moot: we don't know what we don't know.
>> Agreed.  I think there are no real reasons for keeping the module name
>> and deprecate the old defintiions.  Yes, it adds some noise to the
>> module but the fact is that we do deprecate all these defintions, and
>> I think we should not hide that.
> This is also my preferred option.
>
> I would like to just deprecate these nodes now, and then (for the 
> routing module that is unlikely to have been widely implement) update 
> it again in a 1-2 years time to remove the deprecated nodes (we can 
> warn now that they will get removed).
According to Acee, there is one ietf-routing implementation (based on an 
old draft version). If the point is that we don't want ietf-routing 
implementations to implement "deprecated" leaves, can we "obsolete" them 
now.
RFC 7950:

    7.21.2. The "status" Statement

        The "status" statement takes as an argument one of the strings
        "current", "deprecated", or "obsolete".

        o  "current" means that the definition is current and valid.

        o  "deprecated" indicates an obsolete definition, but it permits
           new/continued implementation in order to foster interoperability
           with older/existing implementations.

        o  "obsolete" means that the definition is obsolete and SHOULD NOT be
           implemented and/or can be removed from implementations.

Advantages:
     - we keep the same ietf-routing YANG module names
     - new implementations don't implement the "obsolete" parts.

Regards, Benoit
>
> Conversely, for ietf interfaces (which is much more likely to be 
> widely implemented), I think that they should move to obsolete after 
> 1-2 years and then hopefully be removed 1-2 years after that.
>
> Thanks,
> Rob
>
>
>>
>>
>> /martin
>>
>>
>>
>>> Regarding one point made by Andy:
>>>
>>>     I should explain the use-case for identifying NMDA vs.
>>>     NMDA-transition modules.
>>>     I do not want to present both types (for a given module) to the 
>>> user.
>>>     So the tools need to know in "NMDA mode" which modules are 
>>> duplicates
>>>     for NMDA-transition purpose only, so those modules can be hidden
>>>     from the user.
>>>     In "legacy mode" the NMDA modules would be hidden and the 
>>> transition
>>>     modules
>>>     would be exposed to the user instead.
>>>
>>>     Guessing which is which will only cause unhappy customers so we 
>>> will
>>>     force
>>>     vendors to tag the modules with our own YANG extensions to tell 
>>> them
>>>     apart.
>>>
>>> We recognized this use case and tagged the YANG module "tree-type" in
>>> the YANG catalog.
>>> In the soon-to-be-published but already implemented
>>> draft-clacla-netmod-model-catalog-02 draft, you will see:
>>>
>>>     leaf tree-type {
>>>            type enumeration {
>>>              enum "split" {
>>>                description
>>>                  "This module uses a split config/operational state 
>>> layout.";
>>>              }
>>>              enum "nmda-compatible" {
>>>                description
>>>                  "This module is compatible with the Network Management
>>>                  Datastores
>>>                   Architecture (NMDA) and combines config and 
>>> operational state
>>>                   nodes.";
>>>              }
>>>              enum "transitional-extra" {
>>>                description
>>>                  "This module is derived as a '-state' module to 
>>> allow for
>>>                  transitioning
>>>                   to a full NMDA-compliant tree structure.";
>>>              }
>>>              enum "openconfig" {
>>>                description
>>>                  "This module uses the Openconfig data element 
>>> layout.";
>>>              }
>>>              enum "unclassified" {
>>>                description
>>>                  "This module does not belong to any category or 
>>> can't be
>>>                  determined.";
>>>              }
>>>              enum "not-applicable" {
>>>                description
>>>                  "This module is not applicable. For example, 
>>> because the YANG
>>>                  module only contains typedefs, groupings, or is a 
>>> submodule";
>>>              }
>>>            }
>>>            description
>>>              "The type of data element tree used by the module as it 
>>> relates to
>>>              the
>>>               Network Management Datastores Architecture.";
>>>            reference "draft-dsdt-nmda-guidelines Guidelines for YANG 
>>> Module
>>>            Authors (NMDA)";
>>>          }
>>>          description
>>>            "Grouping of YANG module metadata that extends the common 
>>> list
>>>            defined in the YANG
>>>             Module Library (RFC 7895).";
>>>     }
>>>
>>>
>>> If not convinced already, I hope that you start to see the YANG
>>> catalog value for the industry.
>>> Let's keep in mind that automation is key. Therefore, YANG modules
>>> without module details (metadata) and related tools is not sufficient
>>> for the industry.
>>>
>>> Regards, Benoit
>>>> Andy Bierman  writes:
>>>>
>>>>> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton 
>>>>> wrote:
>>>>>
>>>>>> On 15/09/2017 16:23, Andy Bierman wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> So are you saying the NMDA transition strategy should be ignored?
>>>>>>
>>>>>> My personal preference for the routing modules would be to keep the
>>>>>> same
>>>>>> module name and deprecate the old nodes.
>>>>>>
>>>>>> However, I doubt that there are many implementations of this 8022 
>>>>>> yet,
>>>>>> and
>>>>>> if the authors prefer to use a new namespace without the old nodes
>>>>>> then I'm
>>>>>> fine with that also.  Are you opposed to this approach?
>>>>>>
>>>>>>
>>>>> A new module name mandates a new namespace, so they go together.
>>>>> Abandoning the old module is fine, except leaving that module with
>>>>> status
>>>>> "current" is not fine.
>>>>> IMO you need to republish the old module as well, with everything
>>>>> status
>>>>> obsolete.
>>>> I don't agree with this. The "status" tag is justified for subsequent
>>>> revisions of the same module so as to aid old clients.
>>>>
>>>> But if the module name and namespace URI are different, there is no
>>>> such
>>>> concern. Modules contained in RFCs 7223, 8022 etc. just define some
>>>> schemas that happen to be good for my purposes. So I want to be able
>>>> to
>>>> continue using them, and don't want tools to issue useless warnings or
>>>> even refuse to process such modules.
>>>>
>>>> I am fine though with making a new revision of ietf-routing
>>>> etc. mentioning in the module description that this module is not
>>>> compatible with the NMDA architecture, and providing a pointer to
>>>> ietf-routing-2.
>>>>
>>>> Lada
>>>>
>>>>>
>>>>>> E.g. For ietf-interfaces, and ietf-ip, which are older, and hence
>>>>>> probably
>>>>>> much more widely implemented then I think that the modules should be
>>>>>> updated in place with the existing state tree deprecated.  I.e. I
>>>>>> support
>>>>>> what Martin has done in his IDs, and don't want this to change.
>>>>>>
>>>>>> What is the problem with deprecated nodes?
>>>>>>
>>>>>> Nothing really, but I guess that they are likely to be baggage 
>>>>>> that is
>>>>>> going to be around for a long time even if very few people ever
>>>>>> implement
>>>>>> the deprecated nodes.
>>>>>>
>>>>>>
>>>>>> Why aren't you following your own transition strategy?
>>>>>>
>>>>>> Really because I'm not an author, both solutions seem valid, and I
>>>>>> actually think just reaching a conclusion quickly is more important
>>>>>> than
>>>>>> which particular solution is chosen.  I don't see any advantage is
>>>>>> pushing
>>>>>> back the adoption call - it seems like it will probably just delay
>>>>>> when we
>>>>>> can do WG LC.
>>>>>>
>>>>>> I actually think that the bigger question that needs to be 
>>>>>> resolved is
>>>>>> whether we need an optional extension to mark a module as NMDA
>>>>>> compatible,
>>>>>> or for the extra NMDA state module, as I think that both you and Tom
>>>>>> have
>>>>>> been asking for.
>>>>>>
>>>>> I am no fan of YANG conformance.
>>>>> The WG does not seem to understand the difference between
>>>>>      (A) what a server is supposed to do
>>>>>      (B) what a server claims to do
>>>>>
>>>>> There is no way to express (A) in a YANG module, just (B) in the new
>>>>> yang-library.
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton 
>>>>>> wrote:
>>>>>>
>>>>>>> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> With respect to WG adoption, we will do whatever the WG decides 
>>>>>>>> for
>>>>>>>> the
>>>>>>>> RFC 8022 model. We have a strong preference toward not carrying 
>>>>>>>> the
>>>>>>>> deprecated nodes forward and new module versions appears to be 
>>>>>>>> a good
>>>>>>>> way
>>>>>>>> to achieve this.
>>>>>>>>
>>>>>>> Can we not adopt regardless?  We know that we are going to bis 
>>>>>>> 8022,
>>>>>>> and
>>>>>>> having an adopted draft gives it a bit more legitimacy and helps 
>>>>>>> other
>>>>>>> folks to migrate.
>>>>>>>
>>>>>>> Or perhaps we can start the call for adoption and continue to 
>>>>>>> try and
>>>>>>> resolve this issue at the same time ;-).  I think that it would be
>>>>>>> good to
>>>>>>> try and get the updated model drafts to WG LC by Singapore.
>>>>>>>
>>>>>>> I know that it hasn't been asked yet, but I support adoption of any
>>>>>>> 8022
>>>>>>> bis draft that (i) provides the correct NDMA combined tree (ii)
>>>>>>> removes or
>>>>>>> deprecates the old state nodes :-)
>>>>>>>
>>>>>>> Sorry, if I'm being pushy :-)
>>>>>>> Rob
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I agree with Lada that deprecating all the schema nodes is
>>>>>>>> unnecessary.
>>>>>>>> However, we’ll do what it takes to reach consensus and satisfy the
>>>>>>>> most
>>>>>>>> pedantic among us.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Acee
>>>>>>>>
>>>>>>>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
>>>>>>>>>> rfc8022bis-02 signals the intent to ditch the
>>>>>>>>>> current/soon-to-be-legacy
>>>>>>>>>> module, but does it actually say it?  (I can't find it)
>>>>>>>>>>
>>>>>>>>> The modules contained therein have different names and 
>>>>>>>>> namespaces, so
>>>>>>>>> there is
>>>>>>>>> no formal ancestry. I would prefer to keep the modules from 
>>>>>>>>> RFC 8022
>>>>>>>>> as
>>>>>>>>> they are
>>>>>>>>> - some weirdos may still want to use them.
>>>>>>>>>
>>>>>>>>> The draft does say that it obsoletes 8022, but I'm unsure if 
>>>>>>>>> that's
>>>>>>>>>> going to
>>>>>>>>>> have a meaningful impact in the wild.  I think Juergen said 
>>>>>>>>>> they had
>>>>>>>>>> this
>>>>>>>>>> issue with MIB2 and only after a couple years of misuse did they
>>>>>>>>>> republish the
>>>>>>>>>> legacy MIBs with deprecated status.
>>>>>>>>>>
>>>>>>>>>> I'm okay with this change being made after adoption, so long as
>>>>>>>>>> there's
>>>>>>>>>> general agreement to do it.  Are the authors okay with it, or 
>>>>>>>>>> are
>>>>>>>>>> there
>>>>>>>>>> any
>>>>>>>>>> better suggestions?
>>>>>>>>>>
>>>>>>>>>> PS: Sadly, the 'module' statement does not have 'status' as a
>>>>>>>>>> substatement [I
>>>>>>>>>> just added this omission to the yang-next tracker].  I think 
>>>>>>>>>> the only
>>>>>>>>>> way to
>>>>>>>>>> "deprecate a module" is to instead deprecate the all the
>>>>>>>>>> nodes/rpcs/notifications in the module.  Kind of ugly, but 
>>>>>>>>>> it's for a
>>>>>>>>>> deprecated module, so who care, right?  ;)
>>>>>>>>>>
>>>>>>>>> I think it is unnecessary. If somebody needs adding such a 
>>>>>>>>> module to
>>>>>>>>> the
>>>>>>>>> data
>>>>>>>>> model, he/she should probably have a reason to do so, such as 
>>>>>>>>> data
>>>>>>>>> implemented
>>>>>>>>> on the server.
>>>>>>>>>
>>>>>>>>> Lada
>>>>>>>>>
>>>>>>>>> Kent
>>>>>>>>>> -- 
>>>>>>>>>>
>>>>>>>>>> Hi Rob,
>>>>>>>>>>
>>>>>>>>>> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Kent & Lou,
>>>>>>>>>>>
>>>>>>>>>>> When do you think that it will be possible to start the 
>>>>>>>>>>> adoption
>>>>>>>>>>>
>>>>>>>>>> process
>>>>>>>>>>
>>>>>>>>>>> on these drafts?
>>>>>>>>>>>
>>>>>>>>>>> I think that the first two at least would seem to be ready for
>>>>>>>>>>> adoption.  For the 3rd draft, there still seems to be an open
>>>>>>>>>>>
>>>>>>>>>> question
>>>>>>>>>>
>>>>>>>>>>> of what to do with the old state tree, but presumably that 
>>>>>>>>>>> could be
>>>>>>>>>>> solved after the draft has been adopted?
>>>>>>>>>>>
>>>>>>>>>> I see an update for the third was published yesterday
>>>>>>>>>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  
>>>>>>>>>> that
>>>>>>>>>> clarifies the intent is to replace the current modules, and 
>>>>>>>>>> presumably
>>>>>>>>>> obsolete 8022.  And now that this intended direction is clear 
>>>>>>>>>> in the
>>>>>>>>>> draft we could poll it.
>>>>>>>>>>
>>>>>>>>>> I think this still doesn't address if we need to indicate 
>>>>>>>>>> that the
>>>>>>>>>> rfc8022 defined modules are deprecated by some other 
>>>>>>>>>> mechanisms than
>>>>>>>>>> just replacing the RFC, e.g., by updating the old modules 
>>>>>>>>>> with all
>>>>>>>>>> nodes
>>>>>>>>>> marked as deprecated.  I think you're right that this could 
>>>>>>>>>> be done
>>>>>>>>>> post
>>>>>>>>>> adoption.  Of course others are free to disagree.
>>>>>>>>>>
>>>>>>>>>> I check with Kent and see what he thinks.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Lou
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>> Rob
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 30/08/2017 00:46, Kent Watsen wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>
>>>>>>>>>>>> As discussed at the last meeting, we are heading to revising
>>>>>>>>>>>>
>>>>>>>>>>> existing RFCs
>>>>>>>>>>> to align them with NMDA.  The first batch have been 
>>>>>>>>>>> published as
>>>>>>>>>>>> individual drafts:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. 
>>>>>>>>>>>> https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 
>>>>>>>>>>>>
>>>>>>>>>>>> 2. 
>>>>>>>>>>>> https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 
>>>>>>>>>>>>
>>>>>>>>>>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>>>>>>>>>>
>>>>>>>>>>>> Please take a look (comments welcome!) and stay tuned for the
>>>>>>>>>>>>
>>>>>>>>>>> related
>>>>>>>>>>> adoption calls.
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Kent (and Lou)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>
>>>>>>
>
> .
>


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


  
    
  
  
    
On 10/6/2017 6:01 PM, Robert Wilton
      wrote:

    

    

      

      

      On 06/10/2017 16:32, Martin Bjorklund wrote:
      

      
Benoit Claise <bclaise@cisco.com>
        wrote:
        

        
Dear all,
          

          

          [including the routing and multicast YANG design teams]
          

          Can we please finalize the discussion regarding ietf-routing
          versus
          

          ietf-routing-2, sooner than later.
          

          

          I care about the NMDA transition strategy.
          

          

          Here are all the ietf-routing dependent YANG modules (those
          modules
          

          that depend on ietf-routing)
          

https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
          

          So many YANG modules.
          

          

          Look at the difference for ietf-routing-2:
          

https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
          

          Some dependent modules are compliant with ietf-routing-2, the
          

          multicast YANG modules, but these are the only ones.
          

          

          Changing the module name from ietf-routing to ietf-routing-2
          implies
          

          that the we have to warn all draft authors of ietf-routing
          YANG
          

          dependent modules:
          

               1. to make sure they are aware of ietf-routing-2 
          (publishing a
          

          RFC8022bis mentioning in the module description that this
          module is
          

          not compatible with the NMDA architecture, and providing a
          pointer to
          

          ietf-routing-2 ... is not an automatic way... so barely
          useful)
          

               2. to ask them to change their import to ietf-routing-2
          

          Hopefully, in the routing case, it's mainly the IETF.
          

          I'm glad that we didn't change the ietf-interfaces to
          

          ietf-interfaces-2, we would have to deal with cross
          

          SDO/consortia/opensource project issues
          

          Note:
          

          

              we're in a transition phase today, while we implement the
          

              soon-to-be-published draft-clacla-netmod-model-catalog-02
          

              Because of this, the SDO/consortia/opensource dependent
          YANG modules
          

              will only appear in the Impact Analysis tomorrow at
          

             
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents

              In the mean time, you can see all these dependent modules
          

              Ex:
          

             
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces

                       => click on "dependents"
          

              Those dependent modules is a new feature of
          

              draft-clacla-netmod-model-catalog-02
          

          

          

          I'm wondering if this NMDA transition hurdle doesn't make a
          good
          

          justification to keep the same module name!
          

          We could debate whether ietf-routing is implemented or not,
          but the
          

          point is moot: we don't know what we don't know.
          

        

        Agreed.  I think there are no real reasons for keeping the
        module name
        

        and deprecate the old defintiions.  Yes, it adds some noise to
        the
        

        module but the fact is that we do deprecate all these
        defintions, and
        

        I think we should not hide that.
        

      

      This is also my preferred option.
      

      

      I would like to just deprecate these nodes now, and then (for the
      routing module that is unlikely to have been widely implement)
      update it again in a 1-2 years time to remove the deprecated nodes
      (we can warn now that they will get removed).
      

    

    According to Acee, there is one ietf-routing implementation (based
    on an old draft version). If the point is that we don't want
    ietf-routing implementations to implement "deprecated" leaves, can
    we "obsolete" them now. 

    RFC 7950:

    

      
7.21.2.  The "status" Statement

   The "status" statement takes as an argument one of the strings
   "current", "deprecated", or "obsolete".

   o  "current" means that the definition is current and valid.

   o  "deprecated" indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

    

    Advantages:

        - we keep the same ietf-routing YANG module names

        - new implementations don't implement the "obsolete" parts.

    

    Regards, Benoit

    

      

      Conversely, for ietf interfaces (which is much more likely to be
      widely implemented), I think that they should move to obsolete
      after 1-2 years and then hopefully be removed 1-2 years after
      that.
      

      

      Thanks,
      

      Rob
      

      

      

      

        

        

        /martin
        

        

        

        

        
Regarding one point made by Andy:
          

          

              I should explain the use-case for identifying NMDA vs.
          

              NMDA-transition modules.
          

              I do not want to present both types (for a given module)
          to the user.
          

              So the tools need to know in "NMDA mode" which modules are
          duplicates
          

              for NMDA-transition purpose only, so those modules can be
          hidden
          

              from the user.
          

              In "legacy mode" the NMDA modules would be hidden and the
          transition
          

              modules
          

              would be exposed to the user instead.
          

          

              Guessing which is which will only cause unhappy customers
          so we will
          

              force
          

              vendors to tag the modules with our own YANG extensions to
          tell them
          

              apart.
          

          

          We recognized this use case and tagged the YANG module
          "tree-type" in
          

          the YANG catalog.
          

          In the soon-to-be-published but already implemented
          

          draft-clacla-netmod-model-catalog-02 draft, you will see:
          

          

              leaf tree-type {
          

                     type enumeration {
          

                       enum "split" {
          

                         description
          

                           "This module uses a split config/operational
          state layout.";
          

                       }
          

                       enum "nmda-compatible" {
          

                         description
          

                           "This module is compatible with the Network
          Management
          

                           Datastores
          

                            Architecture (NMDA) and combines config and
          operational state
          

                            nodes.";
          

                       }
          

                       enum "transitional-extra" {
          

                         description
          

                           "This module is derived as a '-state' module
          to allow for
          

                           transitioning
          

                            to a full NMDA-compliant tree structure.";
          

                       }
          

                       enum "openconfig" {
          

                         description
          

                           "This module uses the Openconfig data element
          layout.";
          

                       }
          

                       enum "unclassified" {
          

                         description
          

                           "This module does not belong to any category
          or can't be
          

                           determined.";
          

                       }
          

                       enum "not-applicable" {
          

                         description
          

                           "This module is not applicable. For example,
          because the YANG
          

                           module only contains typedefs, groupings, or
          is a submodule";
          

                       }
          

                     }
          

                     description
          

                       "The type of data element tree used by the module
          as it relates to
          

                       the
          

                        Network Management Datastores Architecture.";
          

                     reference "draft-dsdt-nmda-guidelines Guidelines
          for YANG Module
          

                     Authors (NMDA)";
          

                   }
          

                   description
          

                     "Grouping of YANG module metadata that extends the
          common list
          

                     defined in the YANG
          

                      Module Library (RFC 7895).";
          

              }
          

          

          

          If not convinced already, I hope that you start to see the
          YANG
          

          catalog value for the industry.
          

          Let's keep in mind that automation is key. Therefore, YANG
          modules
          

          without module details (metadata) and related tools is not
          sufficient
          

          for the industry.
          

          

          Regards, Benoit
          

          
Andy Bierman
            <andy@yumaworks.com> writes:
            

            

            
On Fri, Sep 15, 2017 at 9:02 AM,
              Robert Wilton <rwilton@cisco.com>
              

              wrote:
              

              

              
On 15/09/2017 16:23, Andy Bierman
                wrote:
                

                

                Hi,
                

                

                So are you saying the NMDA transition strategy should be
                ignored?
                

                

                My personal preference for the routing modules would be
                to keep the
                

                same
                

                module name and deprecate the old nodes.
                

                

                However, I doubt that there are many implementations of
                this 8022 yet,
                

                and
                

                if the authors prefer to use a new namespace without the
                old nodes
                

                then I'm
                

                fine with that also.  Are you opposed to this approach?
                

                

                

              

              A new module name mandates a new namespace, so they go
              together.
              

              Abandoning the old module is fine, except leaving that
              module with
              

              status
              

              "current" is not fine.
              

              IMO you need to republish the old module as well, with
              everything
              

              status
              

              obsolete.
              

            

            I don't agree with this. The "status" tag is justified for
            subsequent
            

            revisions of the same module so as to aid old clients.
            

            

            But if the module name and namespace URI are different,
            there is no
            

            such
            

            concern. Modules contained in RFCs 7223, 8022 etc. just
            define some
            

            schemas that happen to be good for my purposes. So I want to
            be able
            

            to
            

            continue using them, and don't want tools to issue useless
            warnings or
            

            even refuse to process such modules.
            

            

            I am fine though with making a new revision of ietf-routing
            

            etc. mentioning in the module description that this module
            is not
            

            compatible with the NMDA architecture, and providing a
            pointer to
            

            ietf-routing-2.
            

            

            Lada
            

            

            

              

              
E.g. For ietf-interfaces, and
                ietf-ip, which are older, and hence
                

                probably
                

                much more widely implemented then I think that the
                modules should be
                

                updated in place with the existing state tree
                deprecated.  I.e. I
                

                support
                

                what Martin has done in his IDs, and don't want this to
                change.
                

                

                What is the problem with deprecated nodes?
                

                

                Nothing really, but I guess that they are likely to be
                baggage that is
                

                going to be around for a long time even if very few
                people ever
                

                implement
                

                the deprecated nodes.
                

                

                

                Why aren't you following your own transition strategy?
                

                

                Really because I'm not an author, both solutions seem
                valid, and I
                

                actually think just reaching a conclusion quickly is
                more important
                

                than
                

                which particular solution is chosen.  I don't see any
                advantage is
                

                pushing
                

                back the adoption call - it seems like it will probably
                just delay
                

                when we
                

                can do WG LC.
                

                

                I actually think that the bigger question that needs to
                be resolved is
                

                whether we need an optional extension to mark a module
                as NMDA
                

                compatible,
                

                or for the extra NMDA state module, as I think that both
                you and Tom
                

                have
                

                been asking for.
                

                

              

              I am no fan of YANG conformance.
              

              The WG does not seem to understand the difference between
              

                   (A) what a server is supposed to do
              

                   (B) what a server claims to do
              

              

              There is no way to express (A) in a YANG module, just (B)
              in the new
              

              yang-library.
              

              

              

              Andy
              

              

              

              

              
Thanks,
                

                Rob
                

                

                

                

                

                Andy
                

                

                On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton
                <rwilton@cisco.com>
                

                wrote:
                

                

                
On 15/09/2017 15:52, Acee Lindem
                  (acee) wrote:
                  

                  

                  
Hi,
                    

                    

                    With respect to WG adoption, we will do whatever the
                    WG decides for
                    

                    the
                    

                    RFC 8022 model. We have a strong preference toward
                    not carrying the
                    

                    deprecated nodes forward and new module versions
                    appears to be a good
                    

                    way
                    

                    to achieve this.
                    

                    

                  

                  Can we not adopt regardless?  We know that we are
                  going to bis 8022,
                  

                  and
                  

                  having an adopted draft gives it a bit more legitimacy
                  and helps other
                  

                  folks to migrate.
                  

                  

                  Or perhaps we can start the call for adoption and
                  continue to try and
                  

                  resolve this issue at the same time ;-).  I think that
                  it would be
                  

                  good to
                  

                  try and get the updated model drafts to WG LC by
                  Singapore.
                  

                  

                  I know that it hasn't been asked yet, but I support
                  adoption of any
                  

                  8022
                  

                  bis draft that (i) provides the correct NDMA combined
                  tree (ii)
                  

                  removes or
                  

                  deprecates the old state nodes :-)
                  

                  

                  Sorry, if I'm being pushy :-)
                  

                  Rob
                  

                  

                  

                  

                  
I agree with Lada that
                    deprecating all the schema nodes is
                    

                    unnecessary.
                    

                    However, we’ll do what it takes to reach consensus
                    and satisfy the
                    

                    most
                    

                    pedantic among us.
                    

                    

                    Thanks,
                    

                    Acee
                    

                    

                    On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav
                    Lhotka"
                    

                    <netmod-bounces@ietf.org on behalf of
                    lhotka@nic.cz> wrote:
                    

                    

                    Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
                    

                    

                      
rfc8022bis-02 signals the
                        intent to ditch the
                        

                        current/soon-to-be-legacy
                        

                        module, but does it actually say it?  (I can't
                        find it)
                        

                        

                      

                      The modules contained therein have different names
                      and namespaces, so
                      

                      there is
                      

                      no formal ancestry. I would prefer to keep the
                      modules from RFC 8022
                      

                      as
                      

                      they are
                      

                      - some weirdos may still want to use them.
                      

                      

                      The draft does say that it obsoletes 8022, but I'm
                      unsure if that's
                      

                      
going to
                        

                        have a meaningful impact in the wild.  I think
                        Juergen said they had
                        

                        this
                        

                        issue with MIB2 and only after a couple years of
                        misuse did they
                        

                        republish the
                        

                        legacy MIBs with deprecated status.
                        

                        

                        I'm okay with this change being made after
                        adoption, so long as
                        

                        there's
                        

                        general agreement to do it.  Are the authors
                        okay with it, or are
                        

                        there
                        

                        any
                        

                        better suggestions?
                        

                        

                        PS: Sadly, the 'module' statement does not have
                        'status' as a
                        

                        substatement [I
                        

                        just added this omission to the yang-next
                        tracker].  I think the only
                        

                        way to
                        

                        "deprecate a module" is to instead deprecate the
                        all the
                        

                        nodes/rpcs/notifications in the module.  Kind of
                        ugly, but it's for a
                        

                        deprecated module, so who care, right?  ;)
                        

                        

                      

                      I think it is unnecessary. If somebody needs
                      adding such a module to
                      

                      the
                      

                      data
                      

                      model, he/she should probably have a reason to do
                      so, such as data
                      

                      implemented
                      

                      on the server.
                      

                      

                      Lada
                      

                      

                      Kent
                      

                      
--
                        

                        

                        Hi Rob,
                        

                        

                        On 9/14/2017 9:37 AM, Robert Wilton wrote:
                        

                        

                        
Hi Kent & Lou,
                          

                          

                          When do you think that it will be possible to
                          start the adoption
                          

                          

                        

                        process
                        

                        

                        
on these drafts?
                          

                          

                          I think that the first two at least would seem
                          to be ready for
                          

                          adoption.  For the 3rd draft, there still
                          seems to be an open
                          

                          

                        

                        question
                        

                        

                        
of what to do with the
                          old state tree, but presumably that could be
                          

                          solved after the draft has been adopted?
                          

                          

                        

                        I see an update for the third was published
                        yesterday
                        

(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
                        

                        clarifies the intent is to replace the current
                        modules, and presumably
                        

                        obsolete 8022.  And now that this intended
                        direction is clear in the
                        

                        draft we could poll it.
                        

                        

                        I think this still doesn't address if we need to
                        indicate that the
                        

                        rfc8022 defined modules are deprecated by some
                        other mechanisms than
                        

                        just replacing the RFC, e.g., by updating the
                        old modules with all
                        

                        nodes
                        

                        marked as deprecated.  I think you're right that
                        this could be done
                        

                        post
                        

                        adoption.  Of course others are free to
                        disagree.
                        

                        

                        I check with Kent and see what he thinks.
                        

                        

                        Thanks,
                        

                        Lou
                        

                        

                        Thanks,
                        

                        
Rob
                          

                          

                          

                          On 30/08/2017 00:46, Kent Watsen wrote:
                          

                          

                          
Hey folks,
                            

                            

                            As discussed at the last meeting, we are
                            heading to revising
                            

                            

                          

                          existing RFCs
                          

                          to align them with NMDA.  The first batch have
                          been published as
                          

                          
individual drafts:
                            

                            

                            1.
                            https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
                            

                            2.
                            https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
                            

                            3.
                            https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
                            

                            

                            Please take a look (comments welcome!) and
                            stay tuned for the
                            

                            

                          

                          related
                          

                          adoption calls.
                          

                          
Thanks,
                            

                            Kent (and Lou)
                            

                            

                            

_______________________________________________
                            

                            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
                      

                      

                      _______________________________________________
                      

                      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
                  

                  

                

                

              

            

          

        

      

      

      .
      

      

    

    

  


--------------A719FFE3846AF308C7C7534D--


From nobody Mon Oct  9 14:20:42 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49F134218; Mon,  9 Oct 2017 14:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LbaichG54w2j; Mon,  9 Oct 2017 14:20:39 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 59FF4134307; Mon,  9 Oct 2017 14:20:35 -0700 (PDT)
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 C6CF11AE0402; Mon,  9 Oct 2017 23:20:33 +0200 (CEST)
To: Igor Bryskin 
Cc: "mbj@tail-f.com" , "xufeng.liu.ietf@gmail.com" , "netconf@ietf.org" , "netmod@ietf.org" 
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com> 
From: Per Hedeland 
Message-ID: 
Date: Mon, 9 Oct 2017 23:20:33 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 21:20:41 -0000

Just to be clear: what we're suggesting is that you can use the
already-existing standard NETCONF XPath capability to achieve the desired
result - see https://tools.ietf.org/html/rfc6241#section-8.9

--Per

On 2017-10-09 21:52, Igor Bryskin wrote:
> I agree. For example, a leafref may point not to a singls entity, but to a list of entities, and the client might want to expand all of them into the joint get response.
> 
> Igor
> 
> *From:*Per Hedeland
> *To:*Martin Bjorklund,
> *Cc:*Igor Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,
> *Date:*2017-10-09 15:12:22
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
> 
> On 2017-10-09 19:13, Martin Bjorklund wrote:
>> Igor Bryskin  wrote:
>>>
>>> Hi Per,
>>>
>>> Basically, what we need is a way for a client to request something
>>> like this:
>>>
>>> get  joint with 
>> 
>> ... which is what Per's expression does!  Note that "|" in XPath means
>> "union".
>> 
>> But as Per explained, it only works in some cases (when the leafref
>> acts a "single pointer").
> 
> Well, that particular expression works only in that case - but since it
> is effectively the client that (perhaps based on the data model) decides
> what the leafref-leafs "mean" (in this case the single key of a single
> list), other cases can be handled the same way. E.g. multiple
> leafref-to-key leafs that together give the keys of a multi-key list
> just amounts to a slightly hairier XPath filter...
> 
> --Per
> 
>>> with a server interpreting the request as follows:
>>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>>> matching one of the XPath from the "joint with" list, then the server
>>> must provide the entire body of the node pointed by the pointer,
>>> otherwise, just the pointer (as it happens today, that is, when no
>>> "joint with" list specified).
>>>
>>> We think that this would allow for the client to optimize the number
>>> of request-response iterations depending on application/use case.
>>>
>>> Regards,
>>> Igor
>> 
>> 
>> 
>> /martin
>> 
>> 
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Per Hedeland [mailto:per@tail-f.com]
>>> Sent: Monday, October 09, 2017 12:06 PM
>>> To: Xufeng Liu
>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>>> leafref
>>>
>>> I understand your use case, but a leaf of type leafref does not in
>>> general identify a single node in the data tree - the leafref path
>>> could
>>> be for a non-key leaf, and/or the path could traverse list nodes,
>>> and/or
>>> the "target" list could have multiple keys and thus multiple
>>> leafref-leafs be required to identify a specific list entry.
>>>
>>> Thus it seems to me that your use case is not a reasonable basis for a
>>> new protocol operation. My XPath foo isn't very good either, but I do
>>> believe Robert's suggestion of using an XPath filter could be a way
>>> forward. I *think* the filter expression would be something along the
>>> lines of
>>>
>>>   /te/tunnels/tunnel[name='foo'] |
>>>   /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]
>>>
>>> --Per
>>>
>>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>>> Hi Per,
>>>>
>>>>   
>>>>
>>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>>> *To:* Igor Bryskin ; per@tail-f.com;
>>>> *xufeng.liu.ietf@gmail.com
>>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> *leafref
>>>>
>>>>   
>>>>
>>>>
>>>> Hi Joel,
>>>>
>>>> Thanks, I think I didnt explain our problem correctly.
>>>>
>>>> In our case we have a leafref pointing to a te tunnel name, which
>>>> happens to be a key to lookup the (axilary) tunnel.  We need a way to
>>>> include the entire tunnel body (not just a name) into the get
>>>> response. This is to optimize the number of iterations between the
>>>> client and the server. As Xufeng put it something similar to SQL join,
>>>>
>>>> Igor
>>>>
>>>> *From:*Igor Bryskin
>>>>
>>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>>
>>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>>
>>>> *Date:*2017-10-08 17:36:47
>>>>
>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> *leafref
>>>>
>>>>   
>>>>
>>>> Hi Per,
>>>>
>>>> In a nutshell we would lika for a netconf client to have a way to
>>>> instruct the server on whether in response to the get request the
>>>> server needs to provide the entire body of a datastore node pointed
>>>> to by a leafref or just a pointer to said node, so that the node's
>>>> body could be retrieved by a subsequent separate request. This is
>>>> requested by implementors who want to optimise rhe number of
>>>> interactions between a client and its server.
>>>>
>>>> Cheers,
>>>> Igor
>>>>
>>>> *From:*Per Hedeland
>>>>
>>>> *To:*Xufeng Liu,
>>>>
>>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>>
>>>> *Date:*2017-10-08 14:01:27
>>>>
>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> *leafref
>>>>
>>>>   
>>>>
>>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>>> During the design team discussion for TE and MPLS YANG modeling, we
>>>>> have received a request from implementers: How to minimize the number
>>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>>> Especially for the case when the operator or client software needs to
>>>>> retrieve the object contents pointed by a leafref.
>>>>>
>>>>> For example, given the following simplified TE tunnel model,
>>>>>
>>>>> +--rw te
>>>>>
>>>>>       +--rw explicit-paths
>>>>>
>>>>>       |  +--rw explicit-path* [name]
>>>>>
>>>>>       |     +--rw name                      string
>>>>>
>>>>>       |        +--rw explicit-route-object* [index]
>>>>>
>>>>>       |           +--rw index                   uint32
>>>>>
>>>>>       |           +--rw explicit-route-usage?   identityref
>>>>>
>>>>>       +--rw tunnels
>>>>>
>>>>>       |  +--rw tunnel* [name]
>>>>>
>>>>>       |  |  +--rw name                   string
>>>>>
>>>>>       |  |  +--rw paths
>>>>>
>>>>>       |  |  |  +--rw path* [name]
>>>>>
>>>>> |  |  |     +--rw explicit-path?  ->
>>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>>
>>>>> when the client tries to retrieve a tunnels information based on the
>>>>> tunnel name, the get operation returns a list of leafrefs pointing
>>>>> to the paths of the tunnel.
>>>>
>>>> Sorry, I'm afraid I don't follow. Can you explain exactly what your
>>>> "get" request is (protocol and payload), and where the "list of
>>>> leafref's" (whatever that may be) occurs in the reply?
>>>>
>>>> */[Xufeng] The get operation is the NETCONF/RESTCON  protocol
>>>> *operation, or the  operation described in
>>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
>>>> *operations
>>>> on {+restconf}/ds/ described in
>>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>>
>>>> */ /*
>>>>
>>>> */We have a list of leafref values because in this example model, each
>>>> *tunnel contains a list of paths, each of them contains a leafref. The
>>>> *get returns a value for each instance of such a leafref,
>>>> which (as a string value) will be used as a constraint (foreign key)
>>>> to retrieve the instance of an explicit-path in the model above./*
>>>>
>>>>
>>>>
>>>> JFYI, in case there is some fundamental misunderstanding here: a leaf
>>>> of
>>>> type leafref has a single value - *one* of those that satisfy the
>>>> leafref
>>>> constraint, in case there are multiple "candidates".
>>>>
>>>> --Per
>>>>
>>>>> The client needs to issue at
>>>>> least one more get operation to retrieve the path information about
>>>>> the given tunnel. The request is to combine these two operations into
>>>>> one.
>>>>>
>>>>> In the RDBMS SQL world, join can be used when SQL select is
>>>>> performed, but NETCONF/YANG currently does not have this capability.
>>>>>
>>>>> Wed like to ask whether such a request is considered reasonable.
>>>>>
>>>>> If the request is reasonable, the next question is how to
>>>>> proceed. This seems to be a protocol issue rather than YANG modeling
>>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>>  operation with expanded leafrefs?
>>>>>
>>>>> Comments and suggestions are appreciated.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> - Xufeng
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Mon Oct  9 15:11:21 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE2B132195; Mon,  9 Oct 2017 15:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKAv_fn3DH8o; Mon,  9 Oct 2017 15:11:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649D8120720; Mon,  9 Oct 2017 15:11:11 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQF36951; Mon, 09 Oct 2017 22:11:09 +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.301.0; Mon, 9 Oct 2017 23:11:08 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000;  Mon, 9 Oct 2017 15:11:05 -0700
From: Igor Bryskin 
To: Per Hedeland 
CC: "mbj@tail-f.com" , "xufeng.liu.ietf@gmail.com" , "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netmod] Retrieving Information Pointed by leafref
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/gBsqhSA///GxXmAABh1KIABatEAgAAoFACAAGilEP//qmOAgAAhEID//5Xqm4AAjfiAgABtyeA=
Date: Mon, 9 Oct 2017 22:11:04 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com>
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.154.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59DBF3FD.014F, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7079aeb8228ea02727df538f1c1af6e1
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Oct 2017 22:11:15 -0000

Hi Per,

This is a good news, but, please, help us out.=20
Consider, we have a node - "te-tunnel" - which among other attributes has t=
wo key leafref lists:
1) each member of the 1st list points to a "connection" supporting the te-t=
unnel. All connections supporting all te-tunnels are stored in a single lis=
t of connections.=20
2) each member of the 2nd list points to a supporting "te-tunnel" - the te-=
tunnel in question depends on. All te=3Dtunnels including the te-tunnel in =
question, are stored in a single list of te-tunnels.

The question: how the client can retrieve via a single request all attribut=
es of the te-tunnel in question along with all parameters of all connection=
s supporting the te-tunnel, but with just pointers to supporting te-tunnels=
 (so that the interested client can use the pointers to retrieve full data =
via subsequent separate requests) ?

Likewise, how the client can ask for full data of the te-tunnel and all sup=
porting te-tunnels and just pointers for supporting connections?

I really appreciate your help,

Igor  =20

=20
-----Original Message-----
From: Per Hedeland [mailto:per@tail-f.com]=20
Sent: Monday, October 09, 2017 5:21 PM
To: Igor Bryskin
Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org; netmod@iet=
f.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

Just to be clear: what we're suggesting is that you can use the
already-existing standard NETCONF XPath capability to achieve the desired
result - see https://tools.ietf.org/html/rfc6241#section-8.9

--Per

On 2017-10-09 21:52, Igor Bryskin wrote:
> I agree. For example, a leafref may point not to a singls entity, but to =
a list of entities, and the client might want to expand all of them into th=
e joint get response.
>=20
> Igor
>=20
> *From:*Per Hedeland
> *To:*Martin Bjorklund,
> *Cc:*Igor Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.=
org,
> *Date:*2017-10-09 15:12:22
> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafre=
f
>=20
> On 2017-10-09 19:13, Martin Bjorklund wrote:
>> Igor Bryskin  wrote:
>>>
>>> Hi Per,
>>>
>>> Basically, what we need is a way for a client to request something
>>> like this:
>>>
>>> get  joint with 
>>=20
>> ... which is what Per's expression does!  Note that "|" in XPath means
>> "union".
>>=20
>> But as Per explained, it only works in some cases (when the leafref
>> acts a "single pointer").
>=20
> Well, that particular expression works only in that case - but since it
> is effectively the client that (perhaps based on the data model) decides
> what the leafref-leafs "mean" (in this case the single key of a single
> list), other cases can be handled the same way. E.g. multiple
> leafref-to-key leafs that together give the keys of a multi-key list
> just amounts to a slightly hairier XPath filter...
>=20
> --Per
>=20
>>> with a server interpreting the request as follows:
>>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>>> matching one of the XPath from the "joint with" list, then the server
>>> must provide the entire body of the node pointed by the pointer,
>>> otherwise, just the pointer (as it happens today, that is, when no
>>> "joint with" list specified).
>>>
>>> We think that this would allow for the client to optimize the number
>>> of request-response iterations depending on application/use case.
>>>
>>> Regards,
>>> Igor
>>=20
>>=20
>>=20
>> /martin
>>=20
>>=20
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Per Hedeland [mailto:per@tail-f.com]
>>> Sent: Monday, October 09, 2017 12:06 PM
>>> To: Xufeng Liu
>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>>> leafref
>>>
>>> I understand your use case, but a leaf of type leafref does not in
>>> general identify a single node in the data tree - the leafref path
>>> could
>>> be for a non-key leaf, and/or the path could traverse list nodes,
>>> and/or
>>> the "target" list could have multiple keys and thus multiple
>>> leafref-leafs be required to identify a specific list entry.
>>>
>>> Thus it seems to me that your use case is not a reasonable basis for a
>>> new protocol operation. My XPath foo isn't very good either, but I do
>>> believe Robert's suggestion of using an XPath filter could be a way
>>> forward. I *think* the filter expression would be something along the
>>> lines of
>>>
>>>   /te/tunnels/tunnel[name=3D'foo'] |
>>>   /te/explicit-paths/explicit-path[name=3D/te/tunnels/tunnel[name=3D'fo=
o']/paths/path/explicit-path]
>>>
>>> --Per
>>>
>>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>>> Hi Per,
>>>>
>>>>  =20
>>>>
>>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>>> *To:* Igor Bryskin ; per@tail-f.com;
>>>> *xufeng.liu.ietf@gmail.com
>>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> *leafref
>>>>
>>>>  =20
>>>>
>>>>
>>>> Hi Joel,
>>>>
>>>> Thanks, I think I didnt explain our problem correctly.
>>>>
>>>> In our case we have a leafref pointing to a te tunnel name, which
>>>> happens to be a key to lookup the (axilary) tunnel.  We need a way to
>>>> include the entire tunnel body (not just a name) into the get
>>>> response. This is to optimize the number of iterations between the
>>>> client and the server. As Xufeng put it something similar to SQL join,
>>>>
>>>> Igor
>>>>
>>>> *From:*Igor Bryskin
>>>>
>>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>>
>>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>>
>>>> *Date:*2017-10-08 17:36:47
>>>>
>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> *leafref
>>>>
>>>>  =20
>>>>
>>>> Hi Per,
>>>>
>>>> In a nutshell we would lika for a netconf client to have a way to
>>>> instruct the server on whether in response to the get request the
>>>> server needs to provide the entire body of a datastore node pointed
>>>> to by a leafref or just a pointer to said node, so that the node's
>>>> body could be retrieved by a subsequent separate request. This is
>>>> requested by implementors who want to optimise rhe number of
>>>> interactions between a client and its server.
>>>>
>>>> Cheers,
>>>> Igor
>>>>
>>>> *From:*Per Hedeland
>>>>
>>>> *To:*Xufeng Liu,
>>>>
>>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>>
>>>> *Date:*2017-10-08 14:01:27
>>>>
>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> *leafref
>>>>
>>>>  =20
>>>>
>>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>>> During the design team discussion for TE and MPLS YANG modeling, we
>>>>> have received a request from implementers: How to minimize the number
>>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>>> Especially for the case when the operator or client software needs to
>>>>> retrieve the object contents pointed by a leafref.
>>>>>
>>>>> For example, given the following simplified TE tunnel model,
>>>>>
>>>>> +--rw te
>>>>>
>>>>>       +--rw explicit-paths
>>>>>
>>>>>       |  +--rw explicit-path* [name]
>>>>>
>>>>>       |     +--rw name                      string
>>>>>
>>>>>       |        +--rw explicit-route-object* [index]
>>>>>
>>>>>       |           +--rw index                   uint32
>>>>>
>>>>>       |           +--rw explicit-route-usage?   identityref
>>>>>
>>>>>       +--rw tunnels
>>>>>
>>>>>       |  +--rw tunnel* [name]
>>>>>
>>>>>       |  |  +--rw name                   string
>>>>>
>>>>>       |  |  +--rw paths
>>>>>
>>>>>       |  |  |  +--rw path* [name]
>>>>>
>>>>> |  |  |     +--rw explicit-path?  ->
>>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>>
>>>>> when the client tries to retrieve a tunnels information based on the
>>>>> tunnel name, the =1Cget operation returns a list of leafrefs pointing
>>>>> to the paths of the tunnel.
>>>>
>>>> Sorry, I'm afraid I don't follow. Can you explain exactly what your
>>>> "get" request is (protocol and payload), and where the "list of
>>>> leafref's" (whatever that may be) occurs in the reply?
>>>>
>>>> */[Xufeng] The =1Cget=1D operation is the NETCONF/RESTCON  protoc=
ol
>>>> *operation, or the  operation described in
>>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
>>>> *operations
>>>> on {+restconf}/ds/ described in
>>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>>
>>>> */ /*
>>>>
>>>> */We have a list of leafref values because in this example model, each
>>>> *tunnel contains a list of paths, each of them contains a leafref. The
>>>> *=1Cget=1D returns a value for each instance of such a leafref,
>>>> which (as a string value) will be used as a constraint (foreign key)
>>>> to retrieve the instance of an explicit-path in the model above./*
>>>>
>>>>
>>>>
>>>> JFYI, in case there is some fundamental misunderstanding here: a leaf
>>>> of
>>>> type leafref has a single value - *one* of those that satisfy the
>>>> leafref
>>>> constraint, in case there are multiple "candidates".
>>>>
>>>> --Per
>>>>
>>>>> The client needs to issue at
>>>>> least one more =1Cget operation to retrieve the path information abou=
t
>>>>> the given tunnel. The request is to combine these two operations into
>>>>> one.
>>>>>
>>>>> In the RDBMS SQL world, =1Cjoin can be used when SQL =1Cselect is
>>>>> performed, but NETCONF/YANG currently does not have this capability.
>>>>>
>>>>> Wed like to ask whether such a request is considered reasonable.
>>>>>
>>>>> If the request is reasonable, the next question is how to
>>>>> proceed. This seems to be a protocol issue rather than YANG modeling
>>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>>  operation with expanded leafrefs?
>>>>>
>>>>> Comments and suggestions are appreciated.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> - Xufeng
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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


From nobody Mon Oct  9 23:04:26 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43688132F2E; Mon,  9 Oct 2017 23:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hPR-Qeob7Hfs; Mon,  9 Oct 2017 23:04:22 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 556D413219B; Mon,  9 Oct 2017 23:04:22 -0700 (PDT)
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 99BC91AE02A7; Tue, 10 Oct 2017 08:04:19 +0200 (CEST)
To: Igor Bryskin 
Cc: "mbj@tail-f.com" , "xufeng.liu.ietf@gmail.com" , "netconf@ietf.org" , "netmod@ietf.org" 
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>   <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com>
From: Per Hedeland 
Message-ID: <372461a9-10fb-daed-ccc0-a97661afa839@tail-f.com>
Date: Tue, 10 Oct 2017 08:04:19 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 10 Oct 2017 06:04:25 -0000

I already showed you an XPath filter expression that will do what you
originally asked for, i.e. retrieve the data for a tunnel and the
associated 'explicit-path's in a single request, based on the
(simplified) data model that you provided. What you are describing now
seems like just variations on the theme - as I wrote, it is the client
that decides, via the XPath expression, which leafref-leafs that should
be "dereferenced" for selection of additional data.

I'm afraid I don't have the time to craft XPath expressions for each and
every one of your use cases (and I wouldn't trust them to be correct
without testing anyway). I also provided a link to the definition of the
XPath capability in the NETCONF spec. XPath itself is well-established
technology, not specific to NETCONF or YANG. I suggest that you consult
the specification at http://www.w3.org/TR/1999/REC-xpath-19991116 and/or
one of the many tutorials or even books dedicated to the subject - I
don't have any specific recommendations for the latter, but maybe
someone else does.

--Per

On 2017-10-10 00:11, Igor Bryskin wrote:
> Hi Per,
> 
> This is a good news, but, please, help us out.
> Consider, we have a node - "te-tunnel" - which among other attributes has two key leafref lists:
> 1) each member of the 1st list points to a "connection" supporting the te-tunnel. All connections supporting all te-tunnels are stored in a single list of connections.
> 2) each member of the 2nd list points to a supporting "te-tunnel" - the te-tunnel in question depends on. All te=tunnels including the te-tunnel in question, are stored in a single list of te-tunnels.
> 
> The question: how the client can retrieve via a single request all attributes of the te-tunnel in question along with all parameters of all connections supporting the te-tunnel, but with just pointers to supporting te-tunnels (so that the interested client can use the pointers to retrieve full data via subsequent separate requests) ?
> 
> Likewise, how the client can ask for full data of the te-tunnel and all supporting te-tunnels and just pointers for supporting connections?
>
> I really appreciate your help,
> 
> Igor
> 
>   
> -----Original Message-----
> From: Per Hedeland [mailto:per@tail-f.com]
> Sent: Monday, October 09, 2017 5:21 PM
> To: Igor Bryskin
> Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org; netmod@ietf.org
> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
> 
> Just to be clear: what we're suggesting is that you can use the
> already-existing standard NETCONF XPath capability to achieve the desired
> result - see https://tools.ietf.org/html/rfc6241#section-8.9
> 
> --Per
> 
> On 2017-10-09 21:52, Igor Bryskin wrote:
>> I agree. For example, a leafref may point not to a singls entity, but to a list of entities, and the client might want to expand all of them into the joint get response.
>>
>> Igor
>>
>> *From:*Per Hedeland
>> *To:*Martin Bjorklund,
>> *Cc:*Igor Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,
>> *Date:*2017-10-09 15:12:22
>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
>>
>> On 2017-10-09 19:13, Martin Bjorklund wrote:
>>> Igor Bryskin  wrote:
>>>>
>>>> Hi Per,
>>>>
>>>> Basically, what we need is a way for a client to request something
>>>> like this:
>>>>
>>>> get  joint with 
>>>
>>> ... which is what Per's expression does!  Note that "|" in XPath means
>>> "union".
>>>
>>> But as Per explained, it only works in some cases (when the leafref
>>> acts a "single pointer").
>>
>> Well, that particular expression works only in that case - but since it
>> is effectively the client that (perhaps based on the data model) decides
>> what the leafref-leafs "mean" (in this case the single key of a single
>> list), other cases can be handled the same way. E.g. multiple
>> leafref-to-key leafs that together give the keys of a multi-key list
>> just amounts to a slightly hairier XPath filter...
>>
>> --Per
>>
>>>> with a server interpreting the request as follows:
>>>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>>>> matching one of the XPath from the "joint with" list, then the server
>>>> must provide the entire body of the node pointed by the pointer,
>>>> otherwise, just the pointer (as it happens today, that is, when no
>>>> "joint with" list specified).
>>>>
>>>> We think that this would allow for the client to optimize the number
>>>> of request-response iterations depending on application/use case.
>>>>
>>>> Regards,
>>>> Igor
>>>
>>>
>>>
>>> /martin
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Per Hedeland [mailto:per@tail-f.com]
>>>> Sent: Monday, October 09, 2017 12:06 PM
>>>> To: Xufeng Liu
>>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>>>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> leafref
>>>>
>>>> I understand your use case, but a leaf of type leafref does not in
>>>> general identify a single node in the data tree - the leafref path
>>>> could
>>>> be for a non-key leaf, and/or the path could traverse list nodes,
>>>> and/or
>>>> the "target" list could have multiple keys and thus multiple
>>>> leafref-leafs be required to identify a specific list entry.
>>>>
>>>> Thus it seems to me that your use case is not a reasonable basis for a
>>>> new protocol operation. My XPath foo isn't very good either, but I do
>>>> believe Robert's suggestion of using an XPath filter could be a way
>>>> forward. I *think* the filter expression would be something along the
>>>> lines of
>>>>
>>>>    /te/tunnels/tunnel[name='foo'] |
>>>>    /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]
>>>>
>>>> --Per
>>>>
>>>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>>>> Hi Per,
>>>>>
>>>>>    
>>>>>
>>>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>>>> *To:* Igor Bryskin ; per@tail-f.com;
>>>>> *xufeng.liu.ietf@gmail.com
>>>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> Thanks, I think I didnt explain our problem correctly.
>>>>>
>>>>> In our case we have a leafref pointing to a te tunnel name, which
>>>>> happens to be a key to lookup the (axilary) tunnel.  We need a way to
>>>>> include the entire tunnel body (not just a name) into the get
>>>>> response. This is to optimize the number of iterations between the
>>>>> client and the server. As Xufeng put it something similar to SQL join,
>>>>>
>>>>> Igor
>>>>>
>>>>> *From:*Igor Bryskin
>>>>>
>>>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>>>
>>>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>>>
>>>>> *Date:*2017-10-08 17:36:47
>>>>>
>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>    
>>>>>
>>>>> Hi Per,
>>>>>
>>>>> In a nutshell we would lika for a netconf client to have a way to
>>>>> instruct the server on whether in response to the get request the
>>>>> server needs to provide the entire body of a datastore node pointed
>>>>> to by a leafref or just a pointer to said node, so that the node's
>>>>> body could be retrieved by a subsequent separate request. This is
>>>>> requested by implementors who want to optimise rhe number of
>>>>> interactions between a client and its server.
>>>>>
>>>>> Cheers,
>>>>> Igor
>>>>>
>>>>> *From:*Per Hedeland
>>>>>
>>>>> *To:*Xufeng Liu,
>>>>>
>>>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>>>
>>>>> *Date:*2017-10-08 14:01:27
>>>>>
>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>    
>>>>>
>>>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>>>> During the design team discussion for TE and MPLS YANG modeling, we
>>>>>> have received a request from implementers: How to minimize the number
>>>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>>>> Especially for the case when the operator or client software needs to
>>>>>> retrieve the object contents pointed by a leafref.
>>>>>>
>>>>>> For example, given the following simplified TE tunnel model,
>>>>>>
>>>>>> +--rw te
>>>>>>
>>>>>>        +--rw explicit-paths
>>>>>>
>>>>>>        |  +--rw explicit-path* [name]
>>>>>>
>>>>>>        |     +--rw name                      string
>>>>>>
>>>>>>        |        +--rw explicit-route-object* [index]
>>>>>>
>>>>>>        |           +--rw index                   uint32
>>>>>>
>>>>>>        |           +--rw explicit-route-usage?   identityref
>>>>>>
>>>>>>        +--rw tunnels
>>>>>>
>>>>>>        |  +--rw tunnel* [name]
>>>>>>
>>>>>>        |  |  +--rw name                   string
>>>>>>
>>>>>>        |  |  +--rw paths
>>>>>>
>>>>>>        |  |  |  +--rw path* [name]
>>>>>>
>>>>>> |  |  |     +--rw explicit-path?  ->
>>>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>>>
>>>>>> when the client tries to retrieve a tunnels information based on the
>>>>>> tunnel name, the get operation returns a list of leafrefs pointing
>>>>>> to the paths of the tunnel.
>>>>>
>>>>> Sorry, I'm afraid I don't follow. Can you explain exactly what your
>>>>> "get" request is (protocol and payload), and where the "list of
>>>>> leafref's" (whatever that may be) occurs in the reply?
>>>>>
>>>>> */[Xufeng] The get operation is the NETCONF/RESTCON  protocol
>>>>> *operation, or the  operation described in
>>>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
>>>>> *operations
>>>>> on {+restconf}/ds/ described in
>>>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>>>
>>>>> */ /*
>>>>>
>>>>> */We have a list of leafref values because in this example model, each
>>>>> *tunnel contains a list of paths, each of them contains a leafref. The
>>>>> *get returns a value for each instance of such a leafref,
>>>>> which (as a string value) will be used as a constraint (foreign key)
>>>>> to retrieve the instance of an explicit-path in the model above./*
>>>>>
>>>>>
>>>>>
>>>>> JFYI, in case there is some fundamental misunderstanding here: a leaf
>>>>> of
>>>>> type leafref has a single value - *one* of those that satisfy the
>>>>> leafref
>>>>> constraint, in case there are multiple "candidates".
>>>>>
>>>>> --Per
>>>>>
>>>>>> The client needs to issue at
>>>>>> least one more get operation to retrieve the path information about
>>>>>> the given tunnel. The request is to combine these two operations into
>>>>>> one.
>>>>>>
>>>>>> In the RDBMS SQL world, join can be used when SQL select is
>>>>>> performed, but NETCONF/YANG currently does not have this capability.
>>>>>>
>>>>>> Wed like to ask whether such a request is considered reasonable.
>>>>>>
>>>>>> If the request is reasonable, the next question is how to
>>>>>> proceed. This seems to be a protocol issue rather than YANG modeling
>>>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>>>  operation with expanded leafrefs?
>>>>>>
>>>>>> Comments and suggestions are appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> - Xufeng
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Tue Oct 10 03:00:44 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2C7134458; Tue, 10 Oct 2017 03:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, 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 TS7JE5aubyhx; Tue, 10 Oct 2017 03:00:33 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972A4134C26; Tue, 10 Oct 2017 02:59:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57018; q=dns/txt; s=iport; t=1507629548; x=1508839148; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=CE8sv7jxiR7xrrTXZRfnexRASLsdr8egIhsa+7+xofw=; b=Fn75tgo/oadg3Ud7WeCGjTBa80WSDSSg3p56biGmbDSq32ucu+om+dAX 3hsYeEJIKPyTI71vEdSVnuF7FXDqEr6Luyv7cqChHg3io/vFpzOEEk5GI ZPXxsT9XrIfRZhC1THvx9f+vzO5iRvEDStMtH/LYrxBbeUgMzG8Z1SxCS 0=;
X-IronPort-AV: E=Sophos;i="5.42,504,1500940800";  d="scan'208,217";a="657996463"
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; 10 Oct 2017 09:59:07 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9A9x6Aj017368; Tue, 10 Oct 2017 09:59:06 GMT
To: Benoit Claise , Martin Bjorklund 
Cc: andy@yumaworks.com, acee@cisco.com, netmod@ietf.org, rtg-dt-yang-arch@ietf.org
References:  <87h8w0bbyf.fsf@nic.cz>  <20171006.173244.1167478609964390238.mbj@tail-f.com> <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com> <16eda4e4-5612-918c-9d06-eec39f67e88a@cisco.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 10 Oct 2017 10:59:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <16eda4e4-5612-918c-9d06-eec39f67e88a@cisco.com>
Content-Type: multipart/alternative; boundary="------------EA2F8F004D43D9F58E3FC74E"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 10 Oct 2017 10:00:43 -0000

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



On 09/10/2017 22:06, Benoit Claise wrote:
> On 10/6/2017 6:01 PM, Robert Wilton wrote:
>>
>>
>> On 06/10/2017 16:32, Martin Bjorklund wrote:
>>> Benoit Claise  wrote:
>>>> Dear all,
>>>>
>>>> [including the routing and multicast YANG design teams]
>>>> Can we please finalize the discussion regarding ietf-routing versus
>>>> ietf-routing-2, sooner than later.
>>>>
>>>> I care about the NMDA transition strategy.
>>>>
>>>> Here are all the ietf-routing dependent YANG modules (those modules
>>>> that depend on ietf-routing)
>>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents 
>>>>
>>>> So many YANG modules.
>>>>
>>>> Look at the difference for ietf-routing-2:
>>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents 
>>>>
>>>> Some dependent modules are compliant with ietf-routing-2, the
>>>> multicast YANG modules, but these are the only ones.
>>>>
>>>> Changing the module name from ietf-routing to ietf-routing-2 implies
>>>> that the we have to warn all draft authors of ietf-routing YANG
>>>> dependent modules:
>>>>      1. to make sure they are aware of ietf-routing-2 (publishing a
>>>> RFC8022bis mentioning in the module description that this module is
>>>> not compatible with the NMDA architecture, and providing a pointer to
>>>> ietf-routing-2 ... is not an automatic way... so barely useful)
>>>>      2. to ask them to change their import to ietf-routing-2
>>>> Hopefully, in the routing case, it's mainly the IETF.
>>>> I'm glad that we didn't change the ietf-interfaces to
>>>> ietf-interfaces-2, we would have to deal with cross
>>>> SDO/consortia/opensource project issues
>>>> Note:
>>>>
>>>>     we're in a transition phase today, while we implement the
>>>>     soon-to-be-published draft-clacla-netmod-model-catalog-02
>>>>     Because of this, the SDO/consortia/opensource dependent YANG 
>>>> modules
>>>>     will only appear in the Impact Analysis tomorrow at
>>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
>>>>     In the mean time, you can see all these dependent modules
>>>>     Ex:
>>>> https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces
>>>>              => click on "dependents"
>>>>     Those dependent modules is a new feature of
>>>>     draft-clacla-netmod-model-catalog-02
>>>>
>>>>
>>>> I'm wondering if this NMDA transition hurdle doesn't make a good
>>>> justification to keep the same module name!
>>>> We could debate whether ietf-routing is implemented or not, but the
>>>> point is moot: we don't know what we don't know.
>>> Agreed.  I think there are no real reasons for keeping the module name
>>> and deprecate the old defintiions.  Yes, it adds some noise to the
>>> module but the fact is that we do deprecate all these defintions, and
>>> I think we should not hide that.
>> This is also my preferred option.
>>
>> I would like to just deprecate these nodes now, and then (for the 
>> routing module that is unlikely to have been widely implement) update 
>> it again in a 1-2 years time to remove the deprecated nodes (we can 
>> warn now that they will get removed).
> According to Acee, there is one ietf-routing implementation (based on 
> an old draft version). If the point is that we don't want ietf-routing 
> implementations to implement "deprecated" leaves, can we "obsolete" 
> them now.
> RFC 7950:
>
>     7.21.2. The "status" Statement
>
>         The "status" statement takes as an argument one of the strings
>         "current", "deprecated", or "obsolete".
>
>         o  "current" means that the definition is current and valid.
>
>         o  "deprecated" indicates an obsolete definition, but it permits
>            new/continued implementation in order to foster interoperability
>            with older/existing implementations.
>
>         o  "obsolete" means that the definition is obsolete and SHOULD NOT be
>            implemented and/or can be removed from implementations.
>
> Advantages:
>     - we keep the same ietf-routing YANG module names
>     - new implementations don't implement the "obsolete" parts.

For 8022bis, I would also support keeping the existing module name, and 
moving the existing state leaves directly to obsolete.  This is with the 
justification that this draft has only recently been published, and we 
do not expect there to be many implementations yet.

For RFC 7223, I think that the state leaves should move to deprecated 
then obsolete in a later revision, because the model is much older and 
hence likely to be much more established.

Thanks,
Rob


>
> Regards, Benoit
>>
>> Conversely, for ietf interfaces (which is much more likely to be 
>> widely implemented), I think that they should move to obsolete after 
>> 1-2 years and then hopefully be removed 1-2 years after that.
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>>> Regarding one point made by Andy:
>>>>
>>>>     I should explain the use-case for identifying NMDA vs.
>>>>     NMDA-transition modules.
>>>>     I do not want to present both types (for a given module) to the 
>>>> user.
>>>>     So the tools need to know in "NMDA mode" which modules are 
>>>> duplicates
>>>>     for NMDA-transition purpose only, so those modules can be hidden
>>>>     from the user.
>>>>     In "legacy mode" the NMDA modules would be hidden and the 
>>>> transition
>>>>     modules
>>>>     would be exposed to the user instead.
>>>>
>>>>     Guessing which is which will only cause unhappy customers so we 
>>>> will
>>>>     force
>>>>     vendors to tag the modules with our own YANG extensions to tell 
>>>> them
>>>>     apart.
>>>>
>>>> We recognized this use case and tagged the YANG module "tree-type" in
>>>> the YANG catalog.
>>>> In the soon-to-be-published but already implemented
>>>> draft-clacla-netmod-model-catalog-02 draft, you will see:
>>>>
>>>>     leaf tree-type {
>>>>            type enumeration {
>>>>              enum "split" {
>>>>                description
>>>>                  "This module uses a split config/operational state 
>>>> layout.";
>>>>              }
>>>>              enum "nmda-compatible" {
>>>>                description
>>>>                  "This module is compatible with the Network 
>>>> Management
>>>>                  Datastores
>>>>                   Architecture (NMDA) and combines config and 
>>>> operational state
>>>>                   nodes.";
>>>>              }
>>>>              enum "transitional-extra" {
>>>>                description
>>>>                  "This module is derived as a '-state' module to 
>>>> allow for
>>>>                  transitioning
>>>>                   to a full NMDA-compliant tree structure.";
>>>>              }
>>>>              enum "openconfig" {
>>>>                description
>>>>                  "This module uses the Openconfig data element 
>>>> layout.";
>>>>              }
>>>>              enum "unclassified" {
>>>>                description
>>>>                  "This module does not belong to any category or 
>>>> can't be
>>>>                  determined.";
>>>>              }
>>>>              enum "not-applicable" {
>>>>                description
>>>>                  "This module is not applicable. For example, 
>>>> because the YANG
>>>>                  module only contains typedefs, groupings, or is a 
>>>> submodule";
>>>>              }
>>>>            }
>>>>            description
>>>>              "The type of data element tree used by the module as 
>>>> it relates to
>>>>              the
>>>>               Network Management Datastores Architecture.";
>>>>            reference "draft-dsdt-nmda-guidelines Guidelines for 
>>>> YANG Module
>>>>            Authors (NMDA)";
>>>>          }
>>>>          description
>>>>            "Grouping of YANG module metadata that extends the 
>>>> common list
>>>>            defined in the YANG
>>>>             Module Library (RFC 7895).";
>>>>     }
>>>>
>>>>
>>>> If not convinced already, I hope that you start to see the YANG
>>>> catalog value for the industry.
>>>> Let's keep in mind that automation is key. Therefore, YANG modules
>>>> without module details (metadata) and related tools is not sufficient
>>>> for the industry.
>>>>
>>>> Regards, Benoit
>>>>> Andy Bierman  writes:
>>>>>
>>>>>> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton 
>>>>>> wrote:
>>>>>>
>>>>>>> On 15/09/2017 16:23, Andy Bierman wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> So are you saying the NMDA transition strategy should be ignored?
>>>>>>>
>>>>>>> My personal preference for the routing modules would be to keep the
>>>>>>> same
>>>>>>> module name and deprecate the old nodes.
>>>>>>>
>>>>>>> However, I doubt that there are many implementations of this 
>>>>>>> 8022 yet,
>>>>>>> and
>>>>>>> if the authors prefer to use a new namespace without the old nodes
>>>>>>> then I'm
>>>>>>> fine with that also.  Are you opposed to this approach?
>>>>>>>
>>>>>>>
>>>>>> A new module name mandates a new namespace, so they go together.
>>>>>> Abandoning the old module is fine, except leaving that module with
>>>>>> status
>>>>>> "current" is not fine.
>>>>>> IMO you need to republish the old module as well, with everything
>>>>>> status
>>>>>> obsolete.
>>>>> I don't agree with this. The "status" tag is justified for subsequent
>>>>> revisions of the same module so as to aid old clients.
>>>>>
>>>>> But if the module name and namespace URI are different, there is no
>>>>> such
>>>>> concern. Modules contained in RFCs 7223, 8022 etc. just define some
>>>>> schemas that happen to be good for my purposes. So I want to be able
>>>>> to
>>>>> continue using them, and don't want tools to issue useless 
>>>>> warnings or
>>>>> even refuse to process such modules.
>>>>>
>>>>> I am fine though with making a new revision of ietf-routing
>>>>> etc. mentioning in the module description that this module is not
>>>>> compatible with the NMDA architecture, and providing a pointer to
>>>>> ietf-routing-2.
>>>>>
>>>>> Lada
>>>>>
>>>>>>
>>>>>>> E.g. For ietf-interfaces, and ietf-ip, which are older, and hence
>>>>>>> probably
>>>>>>> much more widely implemented then I think that the modules 
>>>>>>> should be
>>>>>>> updated in place with the existing state tree deprecated.  I.e. I
>>>>>>> support
>>>>>>> what Martin has done in his IDs, and don't want this to change.
>>>>>>>
>>>>>>> What is the problem with deprecated nodes?
>>>>>>>
>>>>>>> Nothing really, but I guess that they are likely to be baggage 
>>>>>>> that is
>>>>>>> going to be around for a long time even if very few people ever
>>>>>>> implement
>>>>>>> the deprecated nodes.
>>>>>>>
>>>>>>>
>>>>>>> Why aren't you following your own transition strategy?
>>>>>>>
>>>>>>> Really because I'm not an author, both solutions seem valid, and I
>>>>>>> actually think just reaching a conclusion quickly is more important
>>>>>>> than
>>>>>>> which particular solution is chosen.  I don't see any advantage is
>>>>>>> pushing
>>>>>>> back the adoption call - it seems like it will probably just delay
>>>>>>> when we
>>>>>>> can do WG LC.
>>>>>>>
>>>>>>> I actually think that the bigger question that needs to be 
>>>>>>> resolved is
>>>>>>> whether we need an optional extension to mark a module as NMDA
>>>>>>> compatible,
>>>>>>> or for the extra NMDA state module, as I think that both you and 
>>>>>>> Tom
>>>>>>> have
>>>>>>> been asking for.
>>>>>>>
>>>>>> I am no fan of YANG conformance.
>>>>>> The WG does not seem to understand the difference between
>>>>>>      (A) what a server is supposed to do
>>>>>>      (B) what a server claims to do
>>>>>>
>>>>>> There is no way to express (A) in a YANG module, just (B) in the new
>>>>>> yang-library.
>>>>>>
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Rob
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> With respect to WG adoption, we will do whatever the WG 
>>>>>>>>> decides for
>>>>>>>>> the
>>>>>>>>> RFC 8022 model. We have a strong preference toward not 
>>>>>>>>> carrying the
>>>>>>>>> deprecated nodes forward and new module versions appears to be 
>>>>>>>>> a good
>>>>>>>>> way
>>>>>>>>> to achieve this.
>>>>>>>>>
>>>>>>>> Can we not adopt regardless?  We know that we are going to bis 
>>>>>>>> 8022,
>>>>>>>> and
>>>>>>>> having an adopted draft gives it a bit more legitimacy and 
>>>>>>>> helps other
>>>>>>>> folks to migrate.
>>>>>>>>
>>>>>>>> Or perhaps we can start the call for adoption and continue to 
>>>>>>>> try and
>>>>>>>> resolve this issue at the same time ;-).  I think that it would be
>>>>>>>> good to
>>>>>>>> try and get the updated model drafts to WG LC by Singapore.
>>>>>>>>
>>>>>>>> I know that it hasn't been asked yet, but I support adoption of 
>>>>>>>> any
>>>>>>>> 8022
>>>>>>>> bis draft that (i) provides the correct NDMA combined tree (ii)
>>>>>>>> removes or
>>>>>>>> deprecates the old state nodes :-)
>>>>>>>>
>>>>>>>> Sorry, if I'm being pushy :-)
>>>>>>>> Rob
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I agree with Lada that deprecating all the schema nodes is
>>>>>>>>> unnecessary.
>>>>>>>>> However, we’ll do what it takes to reach consensus and satisfy 
>>>>>>>>> the
>>>>>>>>> most
>>>>>>>>> pedantic among us.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Acee
>>>>>>>>>
>>>>>>>>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
>>>>>>>>>>> rfc8022bis-02 signals the intent to ditch the
>>>>>>>>>>> current/soon-to-be-legacy
>>>>>>>>>>> module, but does it actually say it?  (I can't find it)
>>>>>>>>>>>
>>>>>>>>>> The modules contained therein have different names and 
>>>>>>>>>> namespaces, so
>>>>>>>>>> there is
>>>>>>>>>> no formal ancestry. I would prefer to keep the modules from 
>>>>>>>>>> RFC 8022
>>>>>>>>>> as
>>>>>>>>>> they are
>>>>>>>>>> - some weirdos may still want to use them.
>>>>>>>>>>
>>>>>>>>>> The draft does say that it obsoletes 8022, but I'm unsure if 
>>>>>>>>>> that's
>>>>>>>>>>> going to
>>>>>>>>>>> have a meaningful impact in the wild.  I think Juergen said 
>>>>>>>>>>> they had
>>>>>>>>>>> this
>>>>>>>>>>> issue with MIB2 and only after a couple years of misuse did 
>>>>>>>>>>> they
>>>>>>>>>>> republish the
>>>>>>>>>>> legacy MIBs with deprecated status.
>>>>>>>>>>>
>>>>>>>>>>> I'm okay with this change being made after adoption, so long as
>>>>>>>>>>> there's
>>>>>>>>>>> general agreement to do it.  Are the authors okay with it, 
>>>>>>>>>>> or are
>>>>>>>>>>> there
>>>>>>>>>>> any
>>>>>>>>>>> better suggestions?
>>>>>>>>>>>
>>>>>>>>>>> PS: Sadly, the 'module' statement does not have 'status' as a
>>>>>>>>>>> substatement [I
>>>>>>>>>>> just added this omission to the yang-next tracker].  I think 
>>>>>>>>>>> the only
>>>>>>>>>>> way to
>>>>>>>>>>> "deprecate a module" is to instead deprecate the all the
>>>>>>>>>>> nodes/rpcs/notifications in the module.  Kind of ugly, but 
>>>>>>>>>>> it's for a
>>>>>>>>>>> deprecated module, so who care, right?  ;)
>>>>>>>>>>>
>>>>>>>>>> I think it is unnecessary. If somebody needs adding such a 
>>>>>>>>>> module to
>>>>>>>>>> the
>>>>>>>>>> data
>>>>>>>>>> model, he/she should probably have a reason to do so, such as 
>>>>>>>>>> data
>>>>>>>>>> implemented
>>>>>>>>>> on the server.
>>>>>>>>>>
>>>>>>>>>> Lada
>>>>>>>>>>
>>>>>>>>>> Kent
>>>>>>>>>>> -- 
>>>>>>>>>>>
>>>>>>>>>>> Hi Rob,
>>>>>>>>>>>
>>>>>>>>>>> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Kent & Lou,
>>>>>>>>>>>>
>>>>>>>>>>>> When do you think that it will be possible to start the 
>>>>>>>>>>>> adoption
>>>>>>>>>>>>
>>>>>>>>>>> process
>>>>>>>>>>>
>>>>>>>>>>>> on these drafts?
>>>>>>>>>>>>
>>>>>>>>>>>> I think that the first two at least would seem to be ready for
>>>>>>>>>>>> adoption.  For the 3rd draft, there still seems to be an open
>>>>>>>>>>>>
>>>>>>>>>>> question
>>>>>>>>>>>
>>>>>>>>>>>> of what to do with the old state tree, but presumably that 
>>>>>>>>>>>> could be
>>>>>>>>>>>> solved after the draft has been adopted?
>>>>>>>>>>>>
>>>>>>>>>>> I see an update for the third was published yesterday
>>>>>>>>>>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02) 
>>>>>>>>>>> that
>>>>>>>>>>> clarifies the intent is to replace the current modules, and 
>>>>>>>>>>> presumably
>>>>>>>>>>> obsolete 8022.  And now that this intended direction is 
>>>>>>>>>>> clear in the
>>>>>>>>>>> draft we could poll it.
>>>>>>>>>>>
>>>>>>>>>>> I think this still doesn't address if we need to indicate 
>>>>>>>>>>> that the
>>>>>>>>>>> rfc8022 defined modules are deprecated by some other 
>>>>>>>>>>> mechanisms than
>>>>>>>>>>> just replacing the RFC, e.g., by updating the old modules 
>>>>>>>>>>> with all
>>>>>>>>>>> nodes
>>>>>>>>>>> marked as deprecated.  I think you're right that this could 
>>>>>>>>>>> be done
>>>>>>>>>>> post
>>>>>>>>>>> adoption.  Of course others are free to disagree.
>>>>>>>>>>>
>>>>>>>>>>> I check with Kent and see what he thinks.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Lou
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rob
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 30/08/2017 00:46, Kent Watsen wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey folks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> As discussed at the last meeting, we are heading to revising
>>>>>>>>>>>>>
>>>>>>>>>>>> existing RFCs
>>>>>>>>>>>> to align them with NMDA.  The first batch have been 
>>>>>>>>>>>> published as
>>>>>>>>>>>>> individual drafts:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. 
>>>>>>>>>>>>> https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. 
>>>>>>>>>>>>> https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3. 
>>>>>>>>>>>>> https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please take a look (comments welcome!) and stay tuned for the
>>>>>>>>>>>>>
>>>>>>>>>>>> related
>>>>>>>>>>>> adoption calls.
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Kent (and Lou)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>
>> .
>>
>


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


  
    
  
  
    


    

    

    
On 09/10/2017 22:06, Benoit Claise
      wrote:

    

    

      
      
On 10/6/2017 6:01 PM, Robert Wilton
        wrote:

      

      
 

        

        On 06/10/2017 16:32, Martin Bjorklund wrote: 

        
Benoit Claise <bclaise@cisco.com>
          wrote: 

          
Dear all, 

            

            [including the routing and multicast YANG design teams] 

            Can we please finalize the discussion regarding ietf-routing
            versus 

            ietf-routing-2, sooner than later. 

            

            I care about the NMDA transition strategy. 

            

            Here are all the ietf-routing dependent YANG modules (those
            modules 

            that depend on ietf-routing) 

            https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
            

            So many YANG modules. 

            

            Look at the difference for ietf-routing-2: 

            https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing-2&recurse=0&rfcs=1&show_subm=1&show_dir=dependents
            

            Some dependent modules are compliant with ietf-routing-2,
            the 

            multicast YANG modules, but these are the only ones. 

            

            Changing the module name from ietf-routing to ietf-routing-2
            implies 

            that the we have to warn all draft authors of ietf-routing
            YANG 

            dependent modules: 

                 1. to make sure they are aware of ietf-routing-2 
            (publishing a 

            RFC8022bis mentioning in the module description that this
            module is 

            not compatible with the NMDA architecture, and providing a
            pointer to 

            ietf-routing-2 ... is not an automatic way... so barely
            useful) 

                 2. to ask them to change their import to ietf-routing-2
            

            Hopefully, in the routing case, it's mainly the IETF. 

            I'm glad that we didn't change the ietf-interfaces to 

            ietf-interfaces-2, we would have to deal with cross 

            SDO/consortia/opensource project issues 

            Note: 

            

                we're in a transition phase today, while we implement
            the 

                soon-to-be-published
            draft-clacla-netmod-model-catalog-02 

                Because of this, the SDO/consortia/opensource dependent
            YANG modules 

                will only appear in the Impact Analysis tomorrow at 

               
            https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-interfaces&recurse=0&rfcs=1&show_subm=1&show_dir=dependents

                In the mean time, you can see all these dependent
            modules 

                Ex: 

               
            https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-interfaces

                         => click on "dependents" 

                Those dependent modules is a new feature of 

                draft-clacla-netmod-model-catalog-02 

            

            

            I'm wondering if this NMDA transition hurdle doesn't make a
            good 

            justification to keep the same module name! 

            We could debate whether ietf-routing is implemented or not,
            but the 

            point is moot: we don't know what we don't know. 

          

          Agreed.  I think there are no real reasons for keeping the
          module name 

          and deprecate the old defintiions.  Yes, it adds some noise to
          the 

          module but the fact is that we do deprecate all these
          defintions, and 

          I think we should not hide that. 

        

        This is also my preferred option. 

        

        I would like to just deprecate these nodes now, and then (for
        the routing module that is unlikely to have been widely
        implement) update it again in a 1-2 years time to remove the
        deprecated nodes (we can warn now that they will get removed). 

      

      According to Acee, there is one ietf-routing implementation (based
      on an old draft version). If the point is that we don't want
      ietf-routing implementations to implement "deprecated" leaves, can
      we "obsolete" them now. 

      RFC 7950:

      

        
7.21.2.  The "status" Statement

   The "status" statement takes as an argument one of the strings
   "current", "deprecated", or "obsolete".

   o  "current" means that the definition is current and valid.

   o  "deprecated" indicates an obsolete definition, but it permits
      new/continued implementation in order to foster interoperability
      with older/existing implementations.

   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

      

      Advantages:

          - we keep the same ietf-routing YANG module names

          - new implementations don't implement the "obsolete" parts.

    

    

    For 8022bis, I would also support keeping the existing module name,
    and moving the existing state leaves directly to obsolete.  This is
    with the justification that this draft has only recently been
    published, and we do not expect there to be many implementations
    yet.

    

    For RFC 7223, I think that the state leaves should move to
    deprecated then obsolete in a later revision, because the model is
    much older and hence likely to be much more established.

    

    Thanks,

    Rob

    

    

    
 

      Regards, Benoit

      
 

        Conversely, for ietf interfaces (which is much more likely to be
        widely implemented), I think that they should move to obsolete
        after 1-2 years and then hopefully be removed 1-2 years after
        that. 

        

        Thanks, 

        Rob 

        

        

        
 

          

          /martin 

          

          

          

          
Regarding one point made by Andy: 

            

                I should explain the use-case for identifying NMDA vs. 

                NMDA-transition modules. 

                I do not want to present both types (for a given module)
            to the user. 

                So the tools need to know in "NMDA mode" which modules
            are duplicates 

                for NMDA-transition purpose only, so those modules can
            be hidden 

                from the user. 

                In "legacy mode" the NMDA modules would be hidden and
            the transition 

                modules 

                would be exposed to the user instead. 

            

                Guessing which is which will only cause unhappy
            customers so we will 

                force 

                vendors to tag the modules with our own YANG extensions
            to tell them 

                apart. 

            

            We recognized this use case and tagged the YANG module
            "tree-type" in 

            the YANG catalog. 

            In the soon-to-be-published but already implemented 

            draft-clacla-netmod-model-catalog-02 draft, you will see: 

            

                leaf tree-type { 

                       type enumeration { 

                         enum "split" { 

                           description 

                             "This module uses a split
            config/operational state layout."; 

                         } 

                         enum "nmda-compatible" { 

                           description 

                             "This module is compatible with the Network
            Management 

                             Datastores 

                              Architecture (NMDA) and combines config
            and operational state 

                              nodes."; 

                         } 

                         enum "transitional-extra" { 

                           description 

                             "This module is derived as a '-state'
            module to allow for 

                             transitioning 

                              to a full NMDA-compliant tree structure.";
            

                         } 

                         enum "openconfig" { 

                           description 

                             "This module uses the Openconfig data
            element layout."; 

                         } 

                         enum "unclassified" { 

                           description 

                             "This module does not belong to any
            category or can't be 

                             determined."; 

                         } 

                         enum "not-applicable" { 

                           description 

                             "This module is not applicable. For
            example, because the YANG 

                             module only contains typedefs, groupings,
            or is a submodule"; 

                         } 

                       } 

                       description 

                         "The type of data element tree used by the
            module as it relates to 

                         the 

                          Network Management Datastores Architecture.";
            

                       reference "draft-dsdt-nmda-guidelines Guidelines
            for YANG Module 

                       Authors (NMDA)"; 

                     } 

                     description 

                       "Grouping of YANG module metadata that extends
            the common list 

                       defined in the YANG 

                        Module Library (RFC 7895)."; 

                } 

            

            

            If not convinced already, I hope that you start to see the
            YANG 

            catalog value for the industry. 

            Let's keep in mind that automation is key. Therefore, YANG
            modules 

            without module details (metadata) and related tools is not
            sufficient 

            for the industry. 

            

            Regards, Benoit 

            
Andy Bierman <andy@yumaworks.com>
              writes: 

              

              
On Fri, Sep 15, 2017 at 9:02 AM,
                Robert Wilton <rwilton@cisco.com>
                

                wrote: 

                

                
On 15/09/2017 16:23, Andy
                  Bierman wrote: 

                  

                  Hi, 

                  

                  So are you saying the NMDA transition strategy should
                  be ignored? 

                  

                  My personal preference for the routing modules would
                  be to keep the 

                  same 

                  module name and deprecate the old nodes. 

                  

                  However, I doubt that there are many implementations
                  of this 8022 yet, 

                  and 

                  if the authors prefer to use a new namespace without
                  the old nodes 

                  then I'm 

                  fine with that also.  Are you opposed to this
                  approach? 

                  

                  

                

                A new module name mandates a new namespace, so they go
                together. 

                Abandoning the old module is fine, except leaving that
                module with 

                status 

                "current" is not fine. 

                IMO you need to republish the old module as well, with
                everything 

                status 

                obsolete. 

              

              I don't agree with this. The "status" tag is justified for
              subsequent 

              revisions of the same module so as to aid old clients. 

              

              But if the module name and namespace URI are different,
              there is no 

              such 

              concern. Modules contained in RFCs 7223, 8022 etc. just
              define some 

              schemas that happen to be good for my purposes. So I want
              to be able 

              to 

              continue using them, and don't want tools to issue useless
              warnings or 

              even refuse to process such modules. 

              

              I am fine though with making a new revision of
              ietf-routing 

              etc. mentioning in the module description that this module
              is not 

              compatible with the NMDA architecture, and providing a
              pointer to 

              ietf-routing-2. 

              

              Lada 

              

              
 

                
E.g. For ietf-interfaces, and
                  ietf-ip, which are older, and hence 

                  probably 

                  much more widely implemented then I think that the
                  modules should be 

                  updated in place with the existing state tree
                  deprecated.  I.e. I 

                  support 

                  what Martin has done in his IDs, and don't want this
                  to change. 

                  

                  What is the problem with deprecated nodes? 

                  

                  Nothing really, but I guess that they are likely to be
                  baggage that is 

                  going to be around for a long time even if very few
                  people ever 

                  implement 

                  the deprecated nodes. 

                  

                  

                  Why aren't you following your own transition strategy?
                  

                  

                  Really because I'm not an author, both solutions seem
                  valid, and I 

                  actually think just reaching a conclusion quickly is
                  more important 

                  than 

                  which particular solution is chosen.  I don't see any
                  advantage is 

                  pushing 

                  back the adoption call - it seems like it will
                  probably just delay 

                  when we 

                  can do WG LC. 

                  

                  I actually think that the bigger question that needs
                  to be resolved is 

                  whether we need an optional extension to mark a module
                  as NMDA 

                  compatible, 

                  or for the extra NMDA state module, as I think that
                  both you and Tom 

                  have 

                  been asking for. 

                  

                

                I am no fan of YANG conformance. 

                The WG does not seem to understand the difference
                between 

                     (A) what a server is supposed to do 

                     (B) what a server claims to do 

                

                There is no way to express (A) in a YANG module, just
                (B) in the new 

                yang-library. 

                

                

                Andy 

                

                

                

                
Thanks, 

                  Rob 

                  

                  

                  

                  

                  Andy 

                  

                  On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton <rwilton@cisco.com>
                  

                  wrote: 

                  

                  
On 15/09/2017 15:52, Acee
                    Lindem (acee) wrote: 

                    

                    
Hi, 

                      

                      With respect to WG adoption, we will do whatever
                      the WG decides for 

                      the 

                      RFC 8022 model. We have a strong preference toward
                      not carrying the 

                      deprecated nodes forward and new module versions
                      appears to be a good 

                      way 

                      to achieve this. 

                      

                    

                    Can we not adopt regardless?  We know that we are
                    going to bis 8022, 

                    and 

                    having an adopted draft gives it a bit more
                    legitimacy and helps other 

                    folks to migrate. 

                    

                    Or perhaps we can start the call for adoption and
                    continue to try and 

                    resolve this issue at the same time ;-).  I think
                    that it would be 

                    good to 

                    try and get the updated model drafts to WG LC by
                    Singapore. 

                    

                    I know that it hasn't been asked yet, but I support
                    adoption of any 

                    8022 

                    bis draft that (i) provides the correct NDMA
                    combined tree (ii) 

                    removes or 

                    deprecates the old state nodes :-) 

                    

                    Sorry, if I'm being pushy :-) 

                    Rob 

                    

                    

                    

                    
I agree with Lada that
                      deprecating all the schema nodes is 

                      unnecessary. 

                      However, we’ll do what it takes to reach consensus
                      and satisfy the 

                      most 

                      pedantic among us. 

                      

                      Thanks, 

                      Acee 

                      

                      On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav
                      Lhotka" 

                      <netmod-bounces@ietf.org
                        on behalf of lhotka@nic.cz> wrote: 

                      

                      Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
                      

                      

                        
rfc8022bis-02 signals
                          the intent to ditch the 

                          current/soon-to-be-legacy 

                          module, but does it actually say it?  (I can't
                          find it) 

                          

                        

                        The modules contained therein have different
                        names and namespaces, so 

                        there is 

                        no formal ancestry. I would prefer to keep the
                        modules from RFC 8022 

                        as 

                        they are 

                        - some weirdos may still want to use them. 

                        

                        The draft does say that it obsoletes 8022, but
                        I'm unsure if that's 

                        
going to 

                          have a meaningful impact in the wild.  I think
                          Juergen said they had 

                          this 

                          issue with MIB2 and only after a couple years
                          of misuse did they 

                          republish the 

                          legacy MIBs with deprecated status. 

                          

                          I'm okay with this change being made after
                          adoption, so long as 

                          there's 

                          general agreement to do it.  Are the authors
                          okay with it, or are 

                          there 

                          any 

                          better suggestions? 

                          

                          PS: Sadly, the 'module' statement does not
                          have 'status' as a 

                          substatement [I 

                          just added this omission to the yang-next
                          tracker].  I think the only 

                          way to 

                          "deprecate a module" is to instead deprecate
                          the all the 

                          nodes/rpcs/notifications in the module.  Kind
                          of ugly, but it's for a 

                          deprecated module, so who care, right?  ;) 

                          

                        

                        I think it is unnecessary. If somebody needs
                        adding such a module to 

                        the 

                        data 

                        model, he/she should probably have a reason to
                        do so, such as data 

                        implemented 

                        on the server. 

                        

                        Lada 

                        

                        Kent 

                        
-- 

                          

                          Hi Rob, 

                          

                          On 9/14/2017 9:37 AM, Robert Wilton wrote: 

                          

                          
Hi Kent & Lou, 

                            

                            When do you think that it will be possible
                            to start the adoption 

                            

                          

                          process 

                          

                          
on these drafts? 

                            

                            I think that the first two at least would
                            seem to be ready for 

                            adoption.  For the 3rd draft, there still
                            seems to be an open 

                            

                          

                          question 

                          

                          
of what to do with the
                            old state tree, but presumably that could be
                            

                            solved after the draft has been adopted? 

                            

                          

                          I see an update for the third was published
                          yesterday 

                          (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02) 
                          that 

                          clarifies the intent is to replace the current
                          modules, and presumably 

                          obsolete 8022.  And now that this intended
                          direction is clear in the 

                          draft we could poll it. 

                          

                          I think this still doesn't address if we need
                          to indicate that the 

                          rfc8022 defined modules are deprecated by some
                          other mechanisms than 

                          just replacing the RFC, e.g., by updating the
                          old modules with all 

                          nodes 

                          marked as deprecated.  I think you're right
                          that this could be done 

                          post 

                          adoption.  Of course others are free to
                          disagree. 

                          

                          I check with Kent and see what he thinks. 

                          

                          Thanks, 

                          Lou 

                          

                          Thanks, 

                          
Rob 

                            

                            

                            On 30/08/2017 00:46, Kent Watsen wrote: 

                            

                            
Hey folks, 

                              

                              As discussed at the last meeting, we are
                              heading to revising 

                              

                            

                            existing RFCs 

                            to align them with NMDA.  The first batch
                            have been published as 

                            
individual drafts: 

                              

                              1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
                              

                              2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
                              

                              3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
                              

                              

                              Please take a look (comments welcome!) and
                              stay tuned for the 

                              

                            

                            related 

                            adoption calls. 

                            
Thanks, 

                              Kent (and Lou) 

                              

                              

_______________________________________________ 

                              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 

                        

                        _______________________________________________
                        

                        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
                    

                    

                  

                  

                

              

            

          

        

        

        . 

        

      

      

    

    

  


--------------EA2F8F004D43D9F58E3FC74E--


From nobody Tue Oct 10 03:15:45 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065011332DF; Tue, 10 Oct 2017 03:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iNLqVnckyMZR; Tue, 10 Oct 2017 03:15:41 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F2E19134C77; Tue, 10 Oct 2017 03:15:07 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id A03201AE02A7; Tue, 10 Oct 2017 12:15:06 +0200 (CEST)
Date: Tue, 10 Oct 2017 12:13:38 +0200 (CEST)
Message-Id: <20171010.121338.957274767620281285.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: bclaise@cisco.com, andy@yumaworks.com, acee@cisco.com, netmod@ietf.org, rtg-dt-yang-arch@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com> <16eda4e4-5612-918c-9d06-eec39f67e88a@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] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 10 Oct 2017 10:15:43 -0000

Robert Wilton  wrote:
> =

> =

> On 09/10/2017 22:06, Benoit Claise wrote:
> > On 10/6/2017 6:01 PM, Robert Wilton wrote:
> >>
> >>
> >> On 06/10/2017 16:32, Martin Bjorklund wrote:
> >>> Benoit Claise  wrote:
> >>>> Dear all,
> >>>>
> >>>> [including the routing and multicast YANG design teams]
> >>>> Can we please finalize the discussion regarding ietf-routing ver=
sus
> >>>> ietf-routing-2, sooner than later.
> >>>>
> >>>> I care about the NMDA transition strategy.
> >>>>
> >>>> Here are all the ietf-routing dependent YANG modules (those modu=
les
> >>>> that depend on ietf-routing)
> >>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modu=
les[]=3Dietf-routing&recurse=3D0&rfcs=3D1&show_subm=3D1&show_dir=3Ddepe=
ndents
> >>>> So many YANG modules.
> >>>>
> >>>> Look at the difference for ietf-routing-2:
> >>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modu=
les[]=3Dietf-routing-2&recurse=3D0&rfcs=3D1&show_subm=3D1&show_dir=3Dde=
pendents
> >>>> Some dependent modules are compliant with ietf-routing-2, the
> >>>> multicast YANG modules, but these are the only ones.
> >>>>
> >>>> Changing the module name from ietf-routing to ietf-routing-2 imp=
lies
> >>>> that the we have to warn all draft authors of ietf-routing YANG
> >>>> dependent modules:
> >>>> =A0=A0=A0=A0 1. to make sure they are aware of ietf-routing-2 (p=
ublishing a
> >>>> RFC8022bis mentioning in the module description that this module=
 is
> >>>> not compatible with the NMDA architecture, and providing a point=
er to
> >>>> ietf-routing-2 ... is not an automatic way... so barely useful)
> >>>> =A0=A0=A0=A0 2. to ask them to change their import to ietf-routi=
ng-2
> >>>> Hopefully, in the routing case, it's mainly the IETF.
> >>>> I'm glad that we didn't change the ietf-interfaces to
> >>>> ietf-interfaces-2, we would have to deal with cross
> >>>> SDO/consortia/opensource project issues
> >>>> Note:
> >>>>
> >>>> =A0=A0=A0 we're in a transition phase today, while we implement =
the
> >>>> =A0=A0=A0 soon-to-be-published draft-clacla-netmod-model-catalog=
-02
> >>>> =A0=A0=A0 Because of this, the SDO/consortia/opensource dependen=
t YANG
> >>>> modules
> >>>> =A0=A0=A0 will only appear in the Impact Analysis tomorrow at
> >>>> https://www.yangcatalog.org/yang-search/impact_analysis.php?modu=
les[]=3Dietf-interfaces&recurse=3D0&rfcs=3D1&show_subm=3D1&show_dir=3Dd=
ependents
> >>>> =A0=A0=A0 In the mean time, you can see all these dependent modu=
les
> >>>> =A0=A0=A0 Ex:
> >>>> https://www.yangcatalog.org/yang-search/module_details.php?modul=
e=3Dietf-interfaces
> >>>> =A0=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =3D> click on "dependents"
> >>>> =A0=A0=A0 Those dependent modules is a new feature of
> >>>> =A0=A0=A0 draft-clacla-netmod-model-catalog-02
> >>>>
> >>>>
> >>>> I'm wondering if this NMDA transition hurdle doesn't make a good=

> >>>> justification to keep the same module name!
> >>>> We could debate whether ietf-routing is implemented or not, but =
the
> >>>> point is moot: we don't know what we don't know.
> >>> Agreed.=A0 I think there are no real reasons for keeping the modu=
le name
> >>> and deprecate the old defintiions.=A0 Yes, it adds some noise to =
the
> >>> module but the fact is that we do deprecate all these defintions,=
 and
> >>> I think we should not hide that.
> >> This is also my preferred option.
> >>
> >> I would like to just deprecate these nodes now, and then (for the
> >> routing module that is unlikely to have been widely implement) upd=
ate
> >> it again in a 1-2 years time to remove the deprecated nodes (we ca=
n
> >> warn now that they will get removed).
> > According to Acee, there is one ietf-routing implementation (based =
on
> > an old draft version). If the point is that we don't want ietf-rout=
ing
> > implementations to implement "deprecated" leaves, can we "obsolete"=

> > them now.
> > RFC 7950:
> >
> >     7.21.2. The "status" Statement
> >
> >         The "status" statement takes as an argument one of the stri=
ngs
> >         "current", "deprecated", or "obsolete".
> >
> >         o  "current" means that the definition is current and valid=
.=

> >
> >         o  "deprecated" indicates an obsolete definition, but it pe=
rmits
> >            new/continued implementation in order to foster interope=
rability
> >            with older/existing implementations.
> >
> >         o "obsolete" means that the definition is obsolete and SHOU=
LD NOT be
> >            implemented and/or can be removed from implementations.
> >
> > Advantages:
> > =A0=A0=A0 - we keep the same ietf-routing YANG module names
> > =A0=A0=A0 - new implementations don't implement the "obsolete" part=
s.
> =

> For 8022bis, I would also support keeping the existing module name,
> and moving the existing state leaves directly to obsolete.=A0 This is=

> with the justification that this draft has only recently been
> published, and we do not expect there to be many implementations yet.=


This is fine with me as well.

> For RFC 7223, I think that the state leaves should move to deprecated=

> then obsolete in a later revision, because the model is much older an=
d
> hence likely to be much more established.

Agreed.


/martin


From nobody Tue Oct 10 03:41:39 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A333F134C9B; Tue, 10 Oct 2017 03:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 UoYKzBOeuQ95; Tue, 10 Oct 2017 03:41:36 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2D6134CA0; Tue, 10 Oct 2017 03:40:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12152; q=dns/txt; s=iport; t=1507632051; x=1508841651; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=VAU7cdMyVPTVoL/4eigtGk0rNMnCubO/G0WdbErwJ7k=; b=Q2xDa5F4znocVQyvdN2haWuYjMVN9TEDCt5AI7fVku+n5Yo6IaEBzQjT fj5zyctuyZ2djL4CX6+3Ve4CXrA6fXIz3d9hou0NVuMwhs/nbb9RCZf5d Y7dBFUNp7/HJfjA2riVq2940Nk+5EX21P53KVRhEpU37ZsOC96Hg2zbP1 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQBGo9xZ/xbLJq1RChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ/bieDeosTkFQieYdMjWqCEgoYC4FegmtPAoUJFwECAQEBAQE?= =?us-ascii?q?BAWsohR0BAQEDAQEBIQQRNgsMBAsRAwEBAQECAiMDAgIhBh8JCAYNBgIBARaJc?= =?us-ascii?q?gMNCBCnfIFtOodADYNXAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBDoIfg1OBais?= =?us-ascii?q?Lgj41gl6BexWDKYJhBYobhyaPPzyHXogShHkCghKFc4Nahy6Me4EJh12BOSABN?= =?us-ascii?q?oEOMiEIHRVJhRocgWg/NgGHfiyCFQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,504,1500940800"; d="scan'208";a="655364330"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2017 10:40:48 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9AAel7f005769; Tue, 10 Oct 2017 10:40:48 GMT
To: Igor Bryskin 
Cc: Per Hedeland , "netmod@ietf.org" , "netconf@ietf.org" 
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>   <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com>
From: Robert Wilton 
Message-ID: <42819484-f9b5-4f06-dd58-23d9bc8c1ecc@cisco.com>
Date: Tue, 10 Oct 2017 11:40:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 10 Oct 2017 10:41:38 -0000

Hi Igor,

On 09/10/2017 23:11, Igor Bryskin wrote:
> Hi Per,
>
> This is a good news, but, please, help us out.
> Consider, we have a node - "te-tunnel" - which among other attributes has two key leafref lists:
> 1) each member of the 1st list points to a "connection" supporting the te-tunnel. All connections supporting all te-tunnels are stored in a single list of connections.
> 2) each member of the 2nd list points to a supporting "te-tunnel" - the te-tunnel in question depends on. All te=tunnels including the te-tunnel in question, are stored in a single list of te-tunnels.
>
> The question: how the client can retrieve via a single request all attributes of the te-tunnel in question along with all parameters of all connections supporting the te-tunnel, but with just pointers to supporting te-tunnels (so that the interested client can use the pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):

   /te/tunnels/tunnel[name='foo'] |
   /te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connections/connection/name]

E.g. in English, this should equate to something like:

Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name matches one of the connections listed in tunnel foo.

>
> Likewise, how the client can ask for full data of the te-tunnel and all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like this:

   /te/tunnels/tunnel[name='foo'] |
   /te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnels/supporting-tunnel/name]


I'm an XPath novice, so the expressions might be wrong.

https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if 
you can construct a simple XML instance tree of your data, you could 
validate whether the XPath expression works.

I hope that this is of some help,
Rob


>
> I really appreciate your help,
>
> Igor
>
>   
> -----Original Message-----
> From: Per Hedeland [mailto:per@tail-f.com]
> Sent: Monday, October 09, 2017 5:21 PM
> To: Igor Bryskin
> Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org; netmod@ietf.org
> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
>
> Just to be clear: what we're suggesting is that you can use the
> already-existing standard NETCONF XPath capability to achieve the desired
> result - see https://tools.ietf.org/html/rfc6241#section-8.9
>
> --Per
>
> On 2017-10-09 21:52, Igor Bryskin wrote:
>> I agree. For example, a leafref may point not to a singls entity, but to a list of entities, and the client might want to expand all of them into the joint get response.
>>
>> Igor
>>
>> *From:*Per Hedeland
>> *To:*Martin Bjorklund,
>> *Cc:*Igor Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,
>> *Date:*2017-10-09 15:12:22
>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
>>
>> On 2017-10-09 19:13, Martin Bjorklund wrote:
>>> Igor Bryskin  wrote:
>>>> Hi Per,
>>>>
>>>> Basically, what we need is a way for a client to request something
>>>> like this:
>>>>
>>>> get  joint with 
>>> ... which is what Per's expression does!  Note that "|" in XPath means
>>> "union".
>>>
>>> But as Per explained, it only works in some cases (when the leafref
>>> acts a "single pointer").
>> Well, that particular expression works only in that case - but since it
>> is effectively the client that (perhaps based on the data model) decides
>> what the leafref-leafs "mean" (in this case the single key of a single
>> list), other cases can be handled the same way. E.g. multiple
>> leafref-to-key leafs that together give the keys of a multi-key list
>> just amounts to a slightly hairier XPath filter...
>>
>> --Per
>>
>>>> with a server interpreting the request as follows:
>>>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>>>> matching one of the XPath from the "joint with" list, then the server
>>>> must provide the entire body of the node pointed by the pointer,
>>>> otherwise, just the pointer (as it happens today, that is, when no
>>>> "joint with" list specified).
>>>>
>>>> We think that this would allow for the client to optimize the number
>>>> of request-response iterations depending on application/use case.
>>>>
>>>> Regards,
>>>> Igor
>>>
>>>
>>> /martin
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Per Hedeland [mailto:per@tail-f.com]
>>>> Sent: Monday, October 09, 2017 12:06 PM
>>>> To: Xufeng Liu
>>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>>>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> leafref
>>>>
>>>> I understand your use case, but a leaf of type leafref does not in
>>>> general identify a single node in the data tree - the leafref path
>>>> could
>>>> be for a non-key leaf, and/or the path could traverse list nodes,
>>>> and/or
>>>> the "target" list could have multiple keys and thus multiple
>>>> leafref-leafs be required to identify a specific list entry.
>>>>
>>>> Thus it seems to me that your use case is not a reasonable basis for a
>>>> new protocol operation. My XPath foo isn't very good either, but I do
>>>> believe Robert's suggestion of using an XPath filter could be a way
>>>> forward. I *think* the filter expression would be something along the
>>>> lines of
>>>>
>>>>    /te/tunnels/tunnel[name='foo'] |
>>>>    /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path]
>>>>
>>>> --Per
>>>>
>>>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>>>> Hi Per,
>>>>>
>>>>>    
>>>>>
>>>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>>>> *To:* Igor Bryskin ; per@tail-f.com;
>>>>> *xufeng.liu.ietf@gmail.com
>>>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>    
>>>>>
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> Thanks, I think I didnt explain our problem correctly.
>>>>>
>>>>> In our case we have a leafref pointing to a te tunnel name, which
>>>>> happens to be a key to lookup the (axilary) tunnel.  We need a way to
>>>>> include the entire tunnel body (not just a name) into the get
>>>>> response. This is to optimize the number of iterations between the
>>>>> client and the server. As Xufeng put it something similar to SQL join,
>>>>>
>>>>> Igor
>>>>>
>>>>> *From:*Igor Bryskin
>>>>>
>>>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>>>
>>>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>>>
>>>>> *Date:*2017-10-08 17:36:47
>>>>>
>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>    
>>>>>
>>>>> Hi Per,
>>>>>
>>>>> In a nutshell we would lika for a netconf client to have a way to
>>>>> instruct the server on whether in response to the get request the
>>>>> server needs to provide the entire body of a datastore node pointed
>>>>> to by a leafref or just a pointer to said node, so that the node's
>>>>> body could be retrieved by a subsequent separate request. This is
>>>>> requested by implementors who want to optimise rhe number of
>>>>> interactions between a client and its server.
>>>>>
>>>>> Cheers,
>>>>> Igor
>>>>>
>>>>> *From:*Per Hedeland
>>>>>
>>>>> *To:*Xufeng Liu,
>>>>>
>>>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>>>
>>>>> *Date:*2017-10-08 14:01:27
>>>>>
>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>    
>>>>>
>>>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>>>> During the design team discussion for TE and MPLS YANG modeling, we
>>>>>> have received a request from implementers: How to minimize the number
>>>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>>>> Especially for the case when the operator or client software needs to
>>>>>> retrieve the object contents pointed by a leafref.
>>>>>>
>>>>>> For example, given the following simplified TE tunnel model,
>>>>>>
>>>>>> +--rw te
>>>>>>
>>>>>>        +--rw explicit-paths
>>>>>>
>>>>>>        |  +--rw explicit-path* [name]
>>>>>>
>>>>>>        |     +--rw name                      string
>>>>>>
>>>>>>        |        +--rw explicit-route-object* [index]
>>>>>>
>>>>>>        |           +--rw index                   uint32
>>>>>>
>>>>>>        |           +--rw explicit-route-usage?   identityref
>>>>>>
>>>>>>        +--rw tunnels
>>>>>>
>>>>>>        |  +--rw tunnel* [name]
>>>>>>
>>>>>>        |  |  +--rw name                   string
>>>>>>
>>>>>>        |  |  +--rw paths
>>>>>>
>>>>>>        |  |  |  +--rw path* [name]
>>>>>>
>>>>>> |  |  |     +--rw explicit-path?  ->
>>>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>>>
>>>>>> when the client tries to retrieve a tunnels information based on the
>>>>>> tunnel name, the get operation returns a list of leafrefs pointing
>>>>>> to the paths of the tunnel.
>>>>> Sorry, I'm afraid I don't follow. Can you explain exactly what your
>>>>> "get" request is (protocol and payload), and where the "list of
>>>>> leafref's" (whatever that may be) occurs in the reply?
>>>>>
>>>>> */[Xufeng] The get operation is the NETCONF/RESTCON  protocol
>>>>> *operation, or the  operation described in
>>>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
>>>>> *operations
>>>>> on {+restconf}/ds/ described in
>>>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>>>
>>>>> */ /*
>>>>>
>>>>> */We have a list of leafref values because in this example model, each
>>>>> *tunnel contains a list of paths, each of them contains a leafref. The
>>>>> *get returns a value for each instance of such a leafref,
>>>>> which (as a string value) will be used as a constraint (foreign key)
>>>>> to retrieve the instance of an explicit-path in the model above./*
>>>>>
>>>>>
>>>>>
>>>>> JFYI, in case there is some fundamental misunderstanding here: a leaf
>>>>> of
>>>>> type leafref has a single value - *one* of those that satisfy the
>>>>> leafref
>>>>> constraint, in case there are multiple "candidates".
>>>>>
>>>>> --Per
>>>>>
>>>>>> The client needs to issue at
>>>>>> least one more get operation to retrieve the path information about
>>>>>> the given tunnel. The request is to combine these two operations into
>>>>>> one.
>>>>>>
>>>>>> In the RDBMS SQL world, join can be used when SQL select is
>>>>>> performed, but NETCONF/YANG currently does not have this capability.
>>>>>>
>>>>>> Wed like to ask whether such a request is considered reasonable.
>>>>>>
>>>>>> If the request is reasonable, the next question is how to
>>>>>> proceed. This seems to be a protocol issue rather than YANG modeling
>>>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>>>  operation with expanded leafrefs?
>>>>>>
>>>>>> Comments and suggestions are appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> - Xufeng
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Tue Oct 10 04:50:09 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E341344FF for ; Tue, 10 Oct 2017 04:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bA-qS74CNiP2 for ; Tue, 10 Oct 2017 04:49:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D3F43134D57 for ; Tue, 10 Oct 2017 04:49:23 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id C0F3C1AE02A7; Tue, 10 Oct 2017 13:49:22 +0200 (CEST)
Date: Tue, 10 Oct 2017 13:47:54 +0200 (CEST)
Message-Id: <20171010.134754.960517858051378663.mbj@tail-f.com>
To: ietfc@btconnect.com
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
References: <20170927.125558.606437323539289377.mbj@tail-f.com> <877ew9zrhs.fsf@nic.cz> <00be01d33e97$d5c94e80$4001a8c0@gateway.2wire.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.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, 10 Oct 2017 11:49:53 -0000

"t.petch"  wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" 
> Sent: Thursday, October 05, 2017 1:52 PM
> > Martin Bjorklund  writes:
> >
> > > This version fixes the XPath context for parent-reference.
> > >
> > > However, there is one more thing to discuss, which is the term
> "mount
> > > point".
> > >
> > > The current text says:
> > >
> > >    - mount point: container or list node whose definition contains
> > >      the "mount-point" extension statement. The argument of the
> > >      "mount-point" statement defines the name of the mount point.
> > >
> > > So if we have:
> > >
> > >   container top {
> > >     container root {
> > >       yangmnt:mount-point ni;
> > >     }
> > >   }
> > >
> > > There is one mount point, the node /top/root, with the name "ni".
> > >
> > > Pretty confusing...   Does anyone have any comments around this?
> >
> > What about this?
> >
> > OLD
> >
> >     - mount point: container or list node whose definition contains
> >       the "mount-point" extension statement. The argument of the
> >       "mount-point" statement defines the name of the mount point.
> >
> > NEW
> >
> >     - mount point: container or list node whose definition contains
> >       the "mount-point" extension statement. The argument of the
> >       "mount-point" statement defines a label that is used for
> >       referencing the mount point.
> 
> Lada
> 
> Trouble is 'label' is not a defined term in RFC7950 which leaves me (and
> others) wondering what is this undefined concept.  I know plenty of
> languages that have the concept of a label but YANG is not one of them.

As Lada explained, currently we have two meanings of the term "mount
point name" - it means both the name of the container/list node, and
the argument to the extension.  So the idea is to have a different
term for the latter.

> I looked to see what the ABNF says for inspiration but there isn't
> any:-)  I think that there should be.
> 
> I looked for a worked example for inspiration, nope, none of them
> either!   What I mean is that in e.g. A.3  mount point with name root
> appears, but that is the only instance of 'root'.  The whole point is
> that root should appear more than once, once for where the mount will
> be, and then once or more times for the part that will be mounted, so an
> example where name appears once is not an example IMHO!

I don't understand this.  Can you elaborate?


/martin


> 
> Tom Petch
> 
> > Lada
> >
> > >
> > >
> > >
> > > /martin
> > >
> 


From nobody Tue Oct 10 06:37:48 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BF7134DE4; Tue, 10 Oct 2017 06:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 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, 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 MIVD68MwqkKf; Tue, 10 Oct 2017 06:37:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D5B134DE6; Tue, 10 Oct 2017 06:35:58 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXG93729; Tue, 10 Oct 2017 13:35:54 +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.301.0; Tue, 10 Oct 2017 14:35:52 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.207]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000;  Tue, 10 Oct 2017 06:35:39 -0700
From: Igor Bryskin 
To: "rwilton@cisco.com" , Igor Bryskin 
CC: "per@tail-f.com" , "netmod@ietf.org" , "netconf@ietf.org" 
Thread-Topic: [netmod] [Netconf] Retrieving Information Pointed by leafref
Thread-Index: AQHTQbRGGxttRklx3EygrgG+VoNT76LdFeg0
Date: Tue, 10 Oct 2017 13:35:38 +0000
Message-ID: 
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>   <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com>, <42819484-f9b5-4f06-dd58-23d9bc8c1ecc@cisco.com>
In-Reply-To: <42819484-f9b5-4f06-dd58-23d9bc8c1ecc@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_etPan59dccc8e149bf9981428localhost_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59DCCCBC.0004, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.207, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d23dfa1edd529c7d57d8726bb1b9f6dd
Archived-At: 
Subject: Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 10 Oct 2017 13:37:46 -0000

--_000_etPan59dccc8e149bf9981428localhost_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Rob,

This helps a lot. What you wrote will work.

The only difference is that if we would have the "joimt with" clause as we =
proposed, the server would be able to tailor the te-tunnel presentation to =
the client's requirements, e.g. substituting the connection pointers with c=
onnection bodies, while, according to your suggestion, the server will prov=
ide the te-tunnel body as is, and then augment it with the cobbection infor=
mation, thus, leaving
for the client to "shuffle " the received data. But I do agree, this would =
be a minor inconvinience for the client, the important thing is that the cl=
ient will get all the data in one piece.

Thanks a lot,
Igor

c

From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,netmod@ietf.org,netconf@ietf.org,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

Hi Igor,

On 09/10/2017 23:11, Igor Bryskin wrote:
> Hi Per,
>
> This is a good news, but, please, help us out.
> Consider, we have a node - "te-tunnel" - which among other attributes has=
 two key leafref lists:
> 1) each member of the 1st list points to a "connection" supporting the te=
-tunnel. All connections supporting all te-tunnels are stored in a single l=
ist of connections.
> 2) each member of the 2nd list points to a supporting "te-tunnel" - the t=
e-tunnel in question depends on. All te=3Dtunnels including the te-tunnel i=
n question, are stored in a single list of te-tunnels.
>
> The question: how the client can retrieve via a single request all attrib=
utes of the te-tunnel in question along with all parameters of all connecti=
ons supporting the te-tunnel, but with just pointers to supporting te-tunne=
ls (so that the interested client can use the pointers to retrieve full dat=
a via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):

   /te/tunnels/tunnel[name=3D'foo'] |
   /te/connections/connection[name=3D/te/tunnels/tunnel[name=3D'foo']/conne=
ctions/connection/name]

E.g. in English, this should equate to something like:

Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name matche=
s one of the connections listed in tunnel foo.

>
> Likewise, how the client can ask for full data of the te-tunnel and all s=
upporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like this:

   /te/tunnels/tunnel[name=3D'foo'] |
   /te/tunnels/tunnel[name=3D/te/tunnels/tunnel[name=3D'foo']/supporting-tu=
nnels/supporting-tunnel/name]


I'm an XPath novice, so the expressions might be wrong.

https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if
you can construct a simple XML instance tree of your data, you could
validate whether the XPath expression works.

I hope that this is of some help,
Rob


>
> I really appreciate your help,
>
> Igor
>
>
> -----Original Message-----
> From: Per Hedeland [mailto:per@tail-f.com]
> Sent: Monday, October 09, 2017 5:21 PM
> To: Igor Bryskin
> Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org; netmod@i=
etf.org
> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref
>
> Just to be clear: what we're suggesting is that you can use the
> already-existing standard NETCONF XPath capability to achieve the desired
> result - see https://tools.ietf.org/html/rfc6241#section-8.9
>
> --Per
>
> On 2017-10-09 21:52, Igor Bryskin wrote:
>> I agree. For example, a leafref may point not to a singls entity, but to=
 a list of entities, and the client might want to expand all of them into t=
he joint get response.
>>
>> Igor
>>
>> *From:*Per Hedeland
>> *To:*Martin Bjorklund,
>> *Cc:*Igor Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf=
.org,
>> *Date:*2017-10-09 15:12:22
>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by leafr=
ef
>>
>> On 2017-10-09 19:13, Martin Bjorklund wrote:
>>> Igor Bryskin  wrote:
>>>> Hi Per,
>>>>
>>>> Basically, what we need is a way for a client to request something
>>>> like this:
>>>>
>>>> get  joint with 
>>> ... which is what Per's expression does!  Note that "|" in XPath means
>>> "union".
>>>
>>> But as Per explained, it only works in some cases (when the leafref
>>> acts a "single pointer").
>> Well, that particular expression works only in that case - but since it
>> is effectively the client that (perhaps based on the data model) decides
>> what the leafref-leafs "mean" (in this case the single key of a single
>> list), other cases can be handled the same way. E.g. multiple
>> leafref-to-key leafs that together give the keys of a multi-key list
>> just amounts to a slightly hairier XPath filter...
>>
>> --Per
>>
>>>> with a server interpreting the request as follows:
>>>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>>>> matching one of the XPath from the "joint with" list, then the server
>>>> must provide the entire body of the node pointed by the pointer,
>>>> otherwise, just the pointer (as it happens today, that is, when no
>>>> "joint with" list specified).
>>>>
>>>> We think that this would allow for the client to optimize the number
>>>> of request-response iterations depending on application/use case.
>>>>
>>>> Regards,
>>>> Igor
>>>
>>>
>>> /martin
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Per Hedeland [mailto:per@tail-f.com]
>>>> Sent: Monday, October 09, 2017 12:06 PM
>>>> To: Xufeng Liu
>>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>>>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> leafref
>>>>
>>>> I understand your use case, but a leaf of type leafref does not in
>>>> general identify a single node in the data tree - the leafref path
>>>> could
>>>> be for a non-key leaf, and/or the path could traverse list nodes,
>>>> and/or
>>>> the "target" list could have multiple keys and thus multiple
>>>> leafref-leafs be required to identify a specific list entry.
>>>>
>>>> Thus it seems to me that your use case is not a reasonable basis for a
>>>> new protocol operation. My XPath foo isn't very good either, but I do
>>>> believe Robert's suggestion of using an XPath filter could be a way
>>>> forward. I *think* the filter expression would be something along the
>>>> lines of
>>>>
>>>>    /te/tunnels/tunnel[name=3D'foo'] |
>>>>    /te/explicit-paths/explicit-path[name=3D/te/tunnels/tunnel[name=3D'=
foo']/paths/path/explicit-path]
>>>>
>>>> --Per
>>>>
>>>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>>>> Hi Per,
>>>>>
>>>>>
>>>>>
>>>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>>>> *To:* Igor Bryskin ; per@tail-f.com;
>>>>> *xufeng.liu.ietf@gmail.com
>>>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> Thanks, I think I didnt explain our problem correctly.
>>>>>
>>>>> In our case we have a leafref pointing to a te tunnel name, which
>>>>> happens to be a key to lookup the (axilary) tunnel.  We need a way to
>>>>> include the entire tunnel body (not just a name) into the get
>>>>> response. This is to optimize the number of iterations between the
>>>>> client and the server. As Xufeng put it something similar to SQL join=
,
>>>>>
>>>>> Igor
>>>>>
>>>>> *From:*Igor Bryskin
>>>>>
>>>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>>>
>>>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>>>
>>>>> *Date:*2017-10-08 17:36:47
>>>>>
>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>
>>>>>
>>>>> Hi Per,
>>>>>
>>>>> In a nutshell we would lika for a netconf client to have a way to
>>>>> instruct the server on whether in response to the get request the
>>>>> server needs to provide the entire body of a datastore node pointed
>>>>> to by a leafref or just a pointer to said node, so that the node's
>>>>> body could be retrieved by a subsequent separate request. This is
>>>>> requested by implementors who want to optimise rhe number of
>>>>> interactions between a client and its server.
>>>>>
>>>>> Cheers,
>>>>> Igor
>>>>>
>>>>> *From:*Per Hedeland
>>>>>
>>>>> *To:*Xufeng Liu,
>>>>>
>>>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>>>
>>>>> *Date:*2017-10-08 14:01:27
>>>>>
>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>
>>>>>
>>>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>>>> During the design team discussion for TE and MPLS YANG modeling, we
>>>>>> have received a request from implementers: How to minimize the numbe=
r
>>>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>>>> Especially for the case when the operator or client software needs t=
o
>>>>>> retrieve the object contents pointed by a leafref.
>>>>>>
>>>>>> For example, given the following simplified TE tunnel model,
>>>>>>
>>>>>> +--rw te
>>>>>>
>>>>>>        +--rw explicit-paths
>>>>>>
>>>>>>        |  +--rw explicit-path* [name]
>>>>>>
>>>>>>        |     +--rw name                      string
>>>>>>
>>>>>>        |        +--rw explicit-route-object* [index]
>>>>>>
>>>>>>        |           +--rw index                   uint32
>>>>>>
>>>>>>        |           +--rw explicit-route-usage?   identityref
>>>>>>
>>>>>>        +--rw tunnels
>>>>>>
>>>>>>        |  +--rw tunnel* [name]
>>>>>>
>>>>>>        |  |  +--rw name                   string
>>>>>>
>>>>>>        |  |  +--rw paths
>>>>>>
>>>>>>        |  |  |  +--rw path* [name]
>>>>>>
>>>>>> |  |  |     +--rw explicit-path?  ->
>>>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>>>
>>>>>> when the client tries to retrieve a tunnels information based on the
>>>>>> tunnel name, the =1Cget operation returns a list of leafrefs pointin=
g
>>>>>> to the paths of the tunnel.
>>>>> Sorry, I'm afraid I don't follow. Can you explain exactly what your
>>>>> "get" request is (protocol and payload), and where the "list of
>>>>> leafref's" (whatever that may be) occurs in the reply?
>>>>>
>>>>> */[Xufeng] The =1Cget=1D operation is the NETCONF/RESTCON  proto=
col
>>>>> *operation, or the  operation described in
>>>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET
>>>>> *operations
>>>>> on {+restconf}/ds/ described in
>>>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>>>
>>>>> */ /*
>>>>>
>>>>> */We have a list of leafref values because in this example model, eac=
h
>>>>> *tunnel contains a list of paths, each of them contains a leafref. Th=
e
>>>>> *=1Cget=1D returns a value for each instance of such a leafref,
>>>>> which (as a string value) will be used as a constraint (foreign key)
>>>>> to retrieve the instance of an explicit-path in the model above./*
>>>>>
>>>>>
>>>>>
>>>>> JFYI, in case there is some fundamental misunderstanding here: a leaf
>>>>> of
>>>>> type leafref has a single value - *one* of those that satisfy the
>>>>> leafref
>>>>> constraint, in case there are multiple "candidates".
>>>>>
>>>>> --Per
>>>>>
>>>>>> The client needs to issue at
>>>>>> least one more =1Cget operation to retrieve the path information abo=
ut
>>>>>> the given tunnel. The request is to combine these two operations int=
o
>>>>>> one.
>>>>>>
>>>>>> In the RDBMS SQL world, =1Cjoin can be used when SQL =1Cselect is
>>>>>> performed, but NETCONF/YANG currently does not have this capability.
>>>>>>
>>>>>> Wed like to ask whether such a request is considered reasonable.
>>>>>>
>>>>>> If the request is reasonable, the next question is how to
>>>>>> proceed. This seems to be a protocol issue rather than YANG modeling
>>>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>>>  operation with expanded leafrefs?
>>>>>>
>>>>>> Comments and suggestions are appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> - Xufeng
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


--_000_etPan59dccc8e149bf9981428localhost_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Rob,



This helps a lot. What you wrote will work.



The only difference is that if we would have the "joimt with" cla=
use as we proposed, the server would be able to tailor the te-tunnel presen=
tation to the client's requirements, e.g. substituting the connection point=
ers with connection bodies, while, according
 to your suggestion, the server will provide the te-tunnel body as is, and =
then augment it with the cobbection information, thus, leaving


for the client to "shuffle " the received data. But I do agree, t=
his would be a minor inconvinience for the client, the important thing is t=
hat the client will get all the data in one piece.



Thanks a lot,

Igor



c








From:Robert Wilton


To:Igor Bryskin,


Cc:Per Hedeland,netmod@ietf.org,=
netconf@ietf.org,


Date:2017-10-10 06:41:04


Subject:Re: [netmod] [Netconf] R=
etrieving Information Pointed by leafref












Hi Igor,



On 09/10/2017 23:11, Igor Bryskin wrote:

> Hi Per,

>

> This is a good news, but, please, help us out.

> Consider, we have a node - "te-tunnel" - which among other a=
ttributes has two key leafref lists:

> 1) each member of the 1st list points to a "connection" supp=
orting the te-tunnel. All connections supporting all te-tunnels are stored =
in a single list of connections.

> 2) each member of the 2nd list points to a supporting "te-tunnel&=
quot; - the te-tunnel in question depends on. All te=3Dtunnels including th=
e te-tunnel in question, are stored in a single list of te-tunnels.

>

> The question: how the client can retrieve via a single request all att=
ributes of the te-tunnel in question along with all parameters of all conne=
ctions supporting the te-tunnel, but with just pointers to supporting te-tu=
nnels (so that the interested client
 can use the pointers to retrieve full data via subsequent separate request=
s) ?

I think that it might be something like this (for tunnel name foo):



   /te/tunnels/tunnel[name=3D'foo'] |

   /te/connections/connection[name=3D/te/tunnels/tunnel[name=3D'f=
oo']/connections/connection/name]



E.g. in English, this should equate to something like:



Return all information for tunnel foo AND ALSO

Return all information for all connections where the connection name matche=
s one of the connections listed in tunnel foo.



>

> Likewise, how the client can ask for full data of the te-tunnel and al=
l supporting te-tunnels and just pointers for supporting connections?

If my xpath above is right, then this would be something roughly like this:=




   /te/tunnels/tunnel[name=3D'foo'] |

   /te/tunnels/tunnel[name=3D/te/tunnels/tunnel[name=3D'foo']/sup=
porting-tunnels/supporting-tunnel/name]





I'm an XPath novice, so the expressions might be wrong.



https://www.fre=
eformatter.com/xpath-tester.html might be useful. E.g. if


you can construct a simple XML instance tree of your data, you could 

validate whether the XPath expression works.



I hope that this is of some help,

Rob





>

> I really appreciate your help,

>

> Igor

>

>   

> -----Original Message-----

> From: Per Hedeland [mailto:per@tail-=
f.com]

> Sent: Monday, October 09, 2017 5:21 PM

> To: Igor Bryskin

> Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org; netmo=
d@ietf.org

> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leaf=
ref

>

> Just to be clear: what we're suggesting is that you can use the

> already-existing standard NETCONF XPath capability to achieve the desi=
red

> result - see https://tools.ietf.org/html/rfc6241#section-8.9

>

> --Per

>

> On 2017-10-09 21:52, Igor Bryskin wrote:

>> I agree. For example, a leafref may point not to a singls entity, =
but to a list of entities, and the client might want to expand all of them =
into the joint get response.

>>

>> Igor

>>

>> *From:*Per Hedeland

>> *To:*Martin Bjorklund,

>> *Cc:*Igor Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmo=
d@ietf.org,

>> *Date:*2017-10-09 15:12:22

>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by=
 leafref

>>

>> On 2017-10-09 19:13, Martin Bjorklund wrote:

>>> Igor Bryskin <Igor.Bryskin@huawei.com> wrote:

>>>> Hi Per,

>>>>

>>>> Basically, what we need is a way for a client to request s=
omething

>>>> like this:

>>>>

>>>> get <XPath> joint with <XPath1, XPath2, ..., XPat=
hn>

>>> ... which is what Per's expression does!  Note that "=
;|" in XPath means

>>> "union".

>>>

>>> But as Per explained, it only works in some cases (when the le=
afref

>>> acts a "single pointer").

>> Well, that particular expression works only in that case - but sin=
ce it

>> is effectively the client that (perhaps based on the data model) d=
ecides

>> what the leafref-leafs "mean" (in this case the single k=
ey of a single

>> list), other cases can be handled the same way. E.g. multiple

>> leafref-to-key leafs that together give the keys of a multi-key li=
st

>> just amounts to a slightly hairier XPath filter...

>>

>> --Per

>>

>>>> with a server interpreting the request as follows:

>>>> if a node pointed by XPath contains a pointer (e.g. key le=
afref)

>>>> matching one of the XPath from the "joint with" =
list, then the server

>>>> must provide the entire body of the node pointed by the po=
inter,

>>>> otherwise, just the pointer (as it happens today, that is,=
 when no

>>>> "joint with" list specified).

>>>>

>>>> We think that this would allow for the client to optimize =
the number

>>>> of request-response iterations depending on application/us=
e case.

>>>>

>>>> Regards,

>>>> Igor

>>>

>>>

>>> /martin

>>>

>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>> -----Original Message-----

>>>> From: Per Hedeland [mail=
to:per@tail-f.com]

>>>> Sent: Monday, October 09, 2017 12:06 PM

>>>> To: Xufeng Liu

>>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org

>>>> Subject: Re: [Netconf] [netmod] Retrieving Information Poi=
nted by

>>>> leafref

>>>>

>>>> I understand your use case, but a leaf of type leafref doe=
s not in

>>>> general identify a single node in the data tree - the leaf=
ref path

>>>> could

>>>> be for a non-key leaf, and/or the path could traverse list=
 nodes,

>>>> and/or

>>>> the "target" list could have multiple keys and t=
hus multiple

>>>> leafref-leafs be required to identify a specific list entr=
y.

>>>>

>>>> Thus it seems to me that your use case is not a reasonable=
 basis for a

>>>> new protocol operation. My XPath foo isn't very good eithe=
r, but I do

>>>> believe Robert's suggestion of using an XPath filter could=
 be a way

>>>> forward. I *think* the filter expression would be somethin=
g along the

>>>> lines of

>>>>

>>>>    /te/tunnels/tunnel[name=3D'foo'] |

>>>>    /te/explicit-paths/explicit-path[name=3D=
/te/tunnels/tunnel[name=3D'foo']/paths/path/explicit-path]

>>>>

>>>> --Per

>>>>

>>>> On 2017-10-09 15:42, Xufeng Liu wrote:

>>>>> Hi Per,

>>>>>

>>>>>    

>>>>>

>>>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]

>>>>> *Sent:* Sunday, October 8, 2017 7:04 PM

>>>>> *To:* Igor Bryskin <Igor.Bryskin@huawei.com>; pe=
r@tail-f.com;

>>>>> *xufeng.liu.ietf@gmail.com

>>>>> *Cc:* netconf@ietf.org; netmod@ietf.org

>>>>> *Subject:* Re: [Netconf] [netmod] Retrieving Informati=
on Pointed by

>>>>> *leafref

>>>>>

>>>>>    

>>>>>

>>>>>

>>>>> Hi Joel,

>>>>>

>>>>> Thanks, I think I didnt explain our problem correctly.=


>>>>>

>>>>> In our case we have a leafref pointing to a te tunnel =
name, which

>>>>> happens to be a key to lookup the (axilary) tunnel.&nb=
sp; We need a way to

>>>>> include the entire tunnel body (not just a name) into =
the get

>>>>> response. This is to optimize the number of iterations=
 between the

>>>>> client and the server. As Xufeng put it something simi=
lar to SQL join,

>>>>>

>>>>> Igor

>>>>>

>>>>> *From:*Igor Bryskin

>>>>>

>>>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,

>>>>>

>>>>> *Cc:*netconf@ietf.org,netmod@ietf.org,

>>>>>

>>>>> *Date:*2017-10-08 17:36:47

>>>>>

>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Informatio=
n Pointed by

>>>>> *leafref

>>>>>

>>>>>    

>>>>>

>>>>> Hi Per,

>>>>>

>>>>> In a nutshell we would lika for a netconf client to ha=
ve a way to

>>>>> instruct the server on whether in response to the get =
request the

>>>>> server needs to provide the entire body of a datastore=
 node pointed

>>>>> to by a leafref or just a pointer to said node, so tha=
t the node's

>>>>> body could be retrieved by a subsequent separate reque=
st. This is

>>>>> requested by implementors who want to optimise rhe num=
ber of

>>>>> interactions between a client and its server.

>>>>>

>>>>> Cheers,

>>>>> Igor

>>>>>

>>>>> *From:*Per Hedeland

>>>>>

>>>>> *To:*Xufeng Liu,

>>>>>

>>>>> *Cc:*netconf@ietf.org,'NetMod WG',

>>>>>

>>>>> *Date:*2017-10-08 14:01:27

>>>>>

>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Informatio=
n Pointed by

>>>>> *leafref

>>>>>

>>>>>    

>>>>>

>>>>> On 2017-10-06 23:11, Xufeng Liu wrote:

>>>>>> During the design team discussion for TE and MPLS =
YANG modeling, we

>>>>>> have received a request from implementers: How to =
minimize the number

>>>>>> of NETCONF/RESTCONF RPCs to improve operation effi=
ciency?

>>>>>> Especially for the case when the operator or clien=
t software needs to

>>>>>> retrieve the object contents pointed by a leafref.=


>>>>>>

>>>>>> For example, given the following simplified TE tun=
nel model,

>>>>>>

>>>>>> +--rw te

>>>>>>

>>>>>>        +--r=
w explicit-paths

>>>>>>

>>>>>>        |  =
+--rw explicit-path* [name]

>>>>>>

>>>>>>        | &=
nbsp;   +--rw name       &=
nbsp;           &nbs=
p;  string

>>>>>>

>>>>>>        | &=
nbsp;      +--rw explicit-route-object* [index=
]

>>>>>>

>>>>>>        | &=
nbsp;         +--rw index =
            &nb=
sp;     uint32

>>>>>>

>>>>>>        | &=
nbsp;         +--rw explicit-ro=
ute-usage?   identityref

>>>>>>

>>>>>>        +--r=
w tunnels

>>>>>>

>>>>>>        |  =
+--rw tunnel* [name]

>>>>>>

>>>>>>        |  =
|  +--rw name         =
;          string

>>>>>>

>>>>>>        |  =
|  +--rw paths

>>>>>>

>>>>>>        |  =
|  |  +--rw path* [name]

>>>>>>

>>>>>> |  |  |     +--r=
w explicit-path?  ->

>>>>>> |  |  |     ../../..=
/../../explicit-paths/explicit-path/name

>>>>>>

>>>>>> when the client tries to retrieve a tunnels inform=
ation based on the

>>>>>> tunnel name, the get operation returns a list=
 of leafrefs pointing

>>>>>> to the paths of the tunnel.

>>>>> Sorry, I'm afraid I don't follow. Can you explain exac=
tly what your

>>>>> "get" request is (protocol and payload), and=
 where the "list of

>>>>> leafref's" (whatever that may be) occurs in the r=
eply?

>>>>>

>>>>> */[Xufeng] The get operation is the NETCONF/=
RESTCON <get> protocol

>>>>> *operation, or the <get-data> operation describe=
d in

>>>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-0=
1 and the GET

>>>>> *operations

>>>>> on {+restconf}/ds/<datastore> described in
>>>>> 
https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*

>>>>>

>>>>> */ /*

>>>>>

>>>>> */We have a list of leafref values because in this exa=
mple model, each

>>>>> *tunnel contains a list of paths, each of them contain=
s a leafref. The

>>>>> *get returns a value for each instance of su=
ch a leafref,

>>>>> which (as a string value) will be used as a constraint=
 (foreign key)

>>>>> to retrieve the instance of an explicit-path in the mo=
del above./*

>>>>>

>>>>>

>>>>>

>>>>> JFYI, in case there is some fundamental misunderstandi=
ng here: a leaf

>>>>> of

>>>>> type leafref has a single value - *one* of those that =
satisfy the

>>>>> leafref

>>>>> constraint, in case there are multiple "candidate=
s".

>>>>>

>>>>> --Per

>>>>>

>>>>>> The client needs to issue at

>>>>>> least one more get operation to retrieve the =
path information about

>>>>>> the given tunnel. The request is to combine these =
two operations into

>>>>>> one.

>>>>>>

>>>>>> In the RDBMS SQL world, join can be used when=
 SQL select is

>>>>>> performed, but NETCONF/YANG currently does not hav=
e this capability.

>>>>>>

>>>>>> Wed like to ask whether such a request is consider=
ed reasonable.

>>>>>>

>>>>>> If the request is reasonable, the next question is=
 how to

>>>>>> proceed. This seems to be a protocol issue rather =
than YANG modeling

>>>>>> issue. Is it acceptable to add a new operation to =
achieve such a

>>>>>> <get-data> operation with expanded leafrefs?=


>>>>>>

>>>>>> Comments and suggestions are appreciated.

>>>>>>

>>>>>> Thanks,

>>>>>>

>>>>>> - Xufeng

>>>>>>

>>>>>>

>>>>>>

>>>>>> _______________________________________________
>>>>>> netmod mailing list

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

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

>>>>>>

>>>>> _______________________________________________

>>>>> Netconf mailing list

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

>>>>> https://www.ietf.org/mailman/listinfo/netconf

>>>>>

>>>> _______________________________________________

>>>> Netconf mailing list

>>>> Netconf@ietf.org

>>>> =
https://www.ietf.org/mailman/listinfo/netconf

>>>>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.i=
etf.org/mailman/listinfo/netmod

> .

>









--_000_etPan59dccc8e149bf9981428localhost_--


From nobody Wed Oct 11 00:40:13 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8CD132153 for ; Wed, 11 Oct 2017 00:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1Z3u6pCkI3I for ; Wed, 11 Oct 2017 00:40:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC56132076 for ; Wed, 11 Oct 2017 00:40:11 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 6D7881AE018C for ; Wed, 11 Oct 2017 09:40:10 +0200 (CEST)
Date: Wed, 11 Oct 2017 09:38:42 +0200 (CEST)
Message-Id: <20171011.093842.920521185013311482.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] alarm 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, 11 Oct 2017 07:40:12 -0000

Hi,

FYI - we have moved the individual draft
draft-vallin-netmod-alarm-module to CCAMP.  It is now called
draft-vallin-ccamp-alarm-module-00 (same technical content as
before).

So, please move the discussion about this draft to CCAMP.  It might be
a good idea to indicate your support (or objections I guess) of this
draft in CCAMP as well, even if you previously did so in NETMOD.


/martin


From nobody Wed Oct 11 02:43:51 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D471331E7; Wed, 11 Oct 2017 02:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 CsTEw5I6nAvv; Wed, 11 Oct 2017 02:43:35 -0700 (PDT)
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 97966128D0D; Wed, 11 Oct 2017 02:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z+kx4amaMVrw8oPFgP4087Vaw5vV9fRmmjJ/bM3lmUA=; b=ic9XKoPGDF20/LVTNJ7vaum0X34W7PhPCZZE/lp9mrPVFe5wWxavR2Ebwt6IaFBkazerfWEuP1DnvS7TKALgY/zsjGYWmGOe5aAS/cUSjmtHDxpgbozxyjFzxu4mDHL5m40Kl/Wbl9KGoJcvQYd2OIWymJP2C5ObMdEmWnvxfv4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (109.146.128.123) 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.77.5; Wed, 11 Oct 2017 09:43:31 +0000
Message-ID: <02aa01d34275$192f1840$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Igor Bryskin" , 
Cc: , 
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>   <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com>, <42819484-f9b5-4f06-dd58-23d9bc8c1ecc@cisco.com> 
Date: Wed, 11 Oct 2017 10:41:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [109.146.128.123]
X-ClientProxiedBy: AM5P190CA0005.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:14::18) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 638d12da-f9c7-4f67-1ebd-08d5108c88d4
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR0701MB3003; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:P7t05Uzppd1CXrjuNlcoKCvSN+oY8P60r97E1NfDMuHZZVzFY7JnzoLRY/B1oFINcKndX4aFYgovi+EFZYMEKHfXNRDz2KYHzKdJiRlaVaWLh3yjEhQORGkQ99DOQ8slmGhoSUG2HidlTmpfh3NW/qt0O+jpBvg3OhGlYLW79MUoWqx8GGz2OAQRyDaJCQT1DJrbRwxHK2nx8IB9l7y3yEltDsL6fmuBl+JLw7donDdwuPJCKRI9Isu91sQfaBy9; 25:Fws6uM5yp4dsu7Spfb0PUOgQ3G+w6Nq80aF7oe/4sKbliHQaOyM4b7uy6cxW5zObsQeaGgg9Rdb/NAlnFFFQhG2UGdcCvAc4XAfhgZgLFnLyp/tX0kbmO7HEMGfYMfzZeI9nMYRv6BoCwzvfVow4aHS3ak47UKaNjgTG3TR4lFTEMvDAkCdF13a7/70a20ept5fuDI+1hUT/o5AiIydcx17D6uoBbWoo8YvAjNnA+jRooT71R3NOXYXzm6BeRJfaKV8jjHBoHwoLPpJW+ueetOFEEGgj58vuTYNl9qmppj9EwzMDPQc8v0Hwmu8XC2DCYUoZ3HvvAbDeU7jg5xb2jQ==; 31:UUJQ5nAFSHkJ2kAswt9oN41eBPyR+V4Lyhl5d7eDDU7zUNp/r4PzKO98Y3UudeLTHUoRsewL1NXqnymrW6v4LN9icHmRLersQXOckW2QaSvyJBImKJ/yJixzFCD3/B8IgIlhbCFFOk4I5YSxoKKhpyENerPilDD/z1ytUIwfC4anp5Ldc5raa9+ZNcvZLkuQJ9sxRx/tdM6+LgMYRGDKTUc0lrBlqbWaAgBuXZ3RUSw=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003:
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(50582790962513);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3003; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 4:fHmJ407aviXIv+Vaj9qUaVxx/ZsHRWii9oKIDnkLliLsOJnmW13Z7cLhEnJ8swrHfbeCXU0AJGm3aV3wxbuHLkHi+V8q6chqHkhFFLcv+4XiCnOVNiDw08lR6Jrj1BxVKKPb2c78jyGW5JbcAf4kbRBv6ShQdVp16oZmmfM1rpdnceLwArPZyKWzM6vlNjLrPbe+hsVx47BogVsvPRQJGm8pRD8K4d3BD23bhDQM1uVWYW8rch7WH15mJaeIYlzIdd7inaJu3r7e5qnLPDWMFplJMDQivVl9DMhy9g54aqGyDQRq7LgkpXcl0GeN4XtW3DUZgEcNdlsHZV0I3KPHGw==
X-Forefront-PRVS: 0457F11EAF
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(51444003)(24454002)(60444003)(189002)(13464003)(377424004)(199003)(377454003)(105586002)(61296003)(966005)(44716002)(106356001)(14496001)(33646002)(110136005)(9686003)(97736004)(6306002)(50226002)(25786009)(4720700003)(101416001)(229853002)(316002)(68736007)(1456003)(4001150100001)(189998001)(50466002)(50986999)(93886005)(6666003)(86362001)(23756003)(54906003)(81816999)(76176999)(53936002)(81686999)(4326008)(6246003)(62236002)(16526018)(66066001)(84392002)(8936002)(5660300001)(81166006)(81156014)(8676002)(478600001)(6486002)(2906002)(2870700001)(7736002)(1556002)(6496005)(53546010)(116806002)(305945005)(44736005)(6116002)(47776003)(3846002)(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: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:Rs1Gosqh85SyHcjGHdaXwEktAmRFMx01Lf1kl?= =?iso-8859-1?Q?wrFPqmOOFcDvlaLfGZs/9O2vVEBp++Yv71i/NPQvgdqUkyVrVLH3OZw/tu?= =?iso-8859-1?Q?dn9lW24pVnRQqvFSddmz3GWFj+55actRvNq12H5q5s2irTOKEPTph8+uKS?= =?iso-8859-1?Q?njTIbC2lV/I+fgdUPfuPLQnMFSrtwCmw6s0GGqYnG2rnjKybJ+XVTojJI6?= =?iso-8859-1?Q?MQ0ZUH1Aaek+fRWQ4E6b36aA+q0qNLALrjxDJJvJK1soUOC1j6iscl1XIq?= =?iso-8859-1?Q?i8lPHpqiBM8ozihHhjW9nLaOCbXz1kIWKbe2d6Sy0gAv+4mGuey7vVJt/t?= =?iso-8859-1?Q?rBH1uHqGMQkuhOlOntIAQSo0LEF0CjqIX73d/rBdPYdqSvj4nGZ5XupIQ0?= =?iso-8859-1?Q?CAVF1UnHGVS2Xtax7BNarPxLYgoU2Kb+mqUUlHwEXlTBTTUgMoISgjgImi?= =?iso-8859-1?Q?kwU/GWmr+0WU2NUFL4zm7r+aGjcFSJ2bVECH5dT6cLfogKPN2HJhqDbP1l?= =?iso-8859-1?Q?ezVXQ/qN2xWOp4xH129NUhv/Q9JydIF3C01xWXqDbwuBSCk4Lt8Ikf4yxx?= =?iso-8859-1?Q?NrcADiyau+GjWeXDqa81U0pmabQgpDp1E3bfM4Yz/Mt4O0aGpQnlghFDM/?= =?iso-8859-1?Q?kkWnykNL8nxpPmamkxU6qBPeKeznXACElCGI/EDTgyqneMpvnfyIyRm7pP?= =?iso-8859-1?Q?wrAyb2VM9ICtLuHFMvq0k6RKx2PqMAAMWGwclcZDmu2X/aXg0HF8sgBvGa?= =?iso-8859-1?Q?uNIxNo9ktreY/xHODexa4d4f9rwNcsW4dH+Ii0iv+L/AY+uUr2C2+i8kU0?= =?iso-8859-1?Q?L4yLN62+rZuftOY/btmW1bzFcr/6/D3B+QjEza4fXhUWtbQKTp4edIpVcT?= =?iso-8859-1?Q?XujuIeasoI3VFfyATUTIRs/sm2fyuMPBKR+YBY8QlIdnkiYUGZS/vUD5mM?= =?iso-8859-1?Q?sQsXAvXdBdFTq++ZnthO45lscB2/zq32nhkSuiD+0YOKq+x8tFpOluYL3i?= =?iso-8859-1?Q?KWPaLem2r6ozMm7hIyeYrQs2AqtdJH75j8GzaeFYK4BIG/FDoSpWbPZO2w?= =?iso-8859-1?Q?5+vy6iZw/wQ4LGIN1IINtjQ5rf4F8Fzgt9IXcbwlMPr24TSO/jNcor8k0M?= =?iso-8859-1?Q?r+kEcXHipk4YRmoEkTpBFaU0uyPicM9LsuScysp2ruS64Ebunkwsfo7B9H?= =?iso-8859-1?Q?yjq97SOS1ESgLPAmby4+AXsJncUSvQN5ABWS8ojBHRjfNBKTiEN0bMu0uy?= =?iso-8859-1?Q?S7MgSU7vr73PzSe0nZ9aj53435++6YAx6HLAq9j08Lzo9Jjn3vAIpdDxcn?= =?iso-8859-1?Q?pPzFDr5OvCyBbxMx147O5HZX7orAWWkj4Keg8FZluXTebPVU6PT4M9U7af?= =?iso-8859-1?Q?RofopiVusupM3zfGHMHv7VE2K19y5oApZu14uqaDZu+yId2EYAE7nfeOeQ?= =?iso-8859-1?Q?vmVxZDdnwzDSR3NwuBKVIeJnp4Fvt7CjQx2FA7t3gmTmmRqw7Y8FZlcfB3?= =?iso-8859-1?Q?z7lzduNliBj1ZMTyc90Zez8WWyRKISdTojQO9MI0dMm89mdsh5D4rdUFSo?= =?iso-8859-1?Q?fMOAI3mwyGFlZhuhnv2rIGRdN760OB+HKewkuBt+E060kfaq0kq8LLN37X?= =?iso-8859-1?Q?8mNhilPSDM7ZmmA3YJQpe2nBTFofEvtLGNXUdQp2u7Yw3TEMaWF+DLUmf0?= =?iso-8859-1?Q?odUGRRXaGu++9R8n+lA=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:Ioh+mLqRSzJNBOmB2JG6ABxi0jcT03knwDmzwOHmu5xOWlKJjY19cKyijfBfA4UB0GbKZ37CfKi724hFe2YjOME4WYqgSvyan+p+zTH9dvIFX5tN7QQO3r58PQBdiwceemM++yBTlgDW3Io0NFjwoJp5p6HqCDRSYN05HeOGw3OmNKvXIzPVHi8V3gzOn/31eF1CPLhSET13dVgtlXtT/oAnodCuQ7P1thuyLCrKE9r2HbWShHIIPqFKevKdIXVE5KL24gQuyhoxeQM9htC1d/+LGxrkA4Ehf7lC0KkeXalrvk7liyI0licxZWj3taYyShopM3pxh39PK2Vbkk/X7w==; 5:sW3CgRE1gEY4Yk/dCrmoFFduqaJRKUNyqGMrMx+GxOLM7yjtk1vIKmW2nBn5e/pe1j/iSfk5fS17Ld7jE8p2BaFY7HVTBxt9TSljpOGQz1dORP5pCLmsc5Td7/r+OHgWZPU9udWQ4z9qSLZn9cVebdMUaauTuBqdwAPb0kb4VKI=; 24:SqP76PkPjdN2+5i5F8QPapbxHWgcYjzGe4u2EB1ce6wg5AU2Bin+S2fiVJjhsHWxekVcgargObMbQIMbacNHoSPKiCF5uEWRpQw1RyrHyzQ=; 7:yXlJYy0cTlhBsd06Pmom6CXhg7uLu17nycgf9jx6GelspSsM65hz3Zd9hQ9BO7qECGUMshoRjgklXlfSZ1BYXQoPC8aB1NFGkTF7jwXfLG0uQJSJfYxCbdUDiSYlKSndmVVbZF3Mp8pxeiVLHL8iJtsESeeZcQ7xDRWBJ6Cv/OXuFkqJkEebA8SNfj22C8HIHzab5ki4mzGyBPGugj6nMTi32RW4PL3QhFIJDcjDzv8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2017 09:43:31.4236 (UTC)
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] [Netconf] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Oct 2017 09:43:43 -0000

Igor

Thinking laterally, this is a problem that DNS encountered a few decades
ago and solved, by allowing the server to include additional information
not specifically requested that the server can see is going to be needed
for the next step, so if the client asks only about a CNAME, then the
server can provide the relevant IP address as well.

I suspect that the current rules for Netconf do not allow the server to
send anything not explicitly requested, which is a shame (IMO).

The DNS approach works very well, in fact I do not think we would
survive without it.

Tom Petch

----- Original Message -----
From: "Igor Bryskin" 
Sent: Tuesday, October 10, 2017 2:35 PM

Hi Rob,

This helps a lot. What you wrote will work.

The only difference is that if we would have the "joimt with" clause as
we proposed, the server would be able to tailor the te-tunnel
presentation to the client's requirements, e.g. substituting the
connection pointers with connection bodies, while, according to your
suggestion, the server will provide the te-tunnel body as is, and then
augment it with the cobbection information, thus, leaving
for the client to "shuffle " the received data. But I do agree, this
would be a minor inconvinience for the client, the important thing is
that the client will get all the data in one piece.

Thanks a lot,
Igor

c

From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,netmod@ietf.org,netconf@ietf.org,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

Hi Igor,

On 09/10/2017 23:11, Igor Bryskin wrote:
> Hi Per,
>
> This is a good news, but, please, help us out.
> Consider, we have a node - "te-tunnel" - which among other attributes
has two key leafref lists:
> 1) each member of the 1st list points to a "connection" supporting the
te-tunnel. All connections supporting all te-tunnels are stored in a
single list of connections.
> 2) each member of the 2nd list points to a supporting "te-tunnel" -
the te-tunnel in question depends on. All te=tunnels including the
te-tunnel in question, are stored in a single list of te-tunnels.
>
> The question: how the client can retrieve via a single request all
attributes of the te-tunnel in question along with all parameters of all
connections supporting the te-tunnel, but with just pointers to
supporting te-tunnels (so that the interested client can use the
pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):

   /te/tunnels/tunnel[name='foo'] |

/te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio
ns/connection/name]

E.g. in English, this should equate to something like:

Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name
matches one of the connections listed in tunnel foo.

>
> Likewise, how the client can ask for full data of the te-tunnel and
all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like
this:

   /te/tunnels/tunnel[name='foo'] |

/te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel
s/supporting-tunnel/name]


I'm an XPath novice, so the expressions might be wrong.

https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if
you can construct a simple XML instance tree of your data, you could
validate whether the XPath expression works.

I hope that this is of some help,
Rob


>
> I really appreciate your help,
>
> Igor
>
>
> -----Original Message-----
> From: Per Hedeland [mailto:per@tail-f.com]
> Sent: Monday, October 09, 2017 5:21 PM
> To: Igor Bryskin
> Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org;
netmod@ietf.org
> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref
>
> Just to be clear: what we're suggesting is that you can use the
> already-existing standard NETCONF XPath capability to achieve the
desired
> result - see https://tools.ietf.org/html/rfc6241#section-8.9
>
> --Per
>
> On 2017-10-09 21:52, Igor Bryskin wrote:
>> I agree. For example, a leafref may point not to a singls entity, but
to a list of entities, and the client might want to expand all of them
into the joint get response.
>>
>> Igor
>>
>> *From:*Per Hedeland
>> *To:*Martin Bjorklund,
>> *Cc:*Igor
Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,
>> *Date:*2017-10-09 15:12:22
>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref
>>
>> On 2017-10-09 19:13, Martin Bjorklund wrote:
>>> Igor Bryskin  wrote:
>>>> Hi Per,
>>>>
>>>> Basically, what we need is a way for a client to request something
>>>> like this:
>>>>
>>>> get  joint with 
>>> ... which is what Per's expression does!  Note that "|" in XPath
means
>>> "union".
>>>
>>> But as Per explained, it only works in some cases (when the leafref
>>> acts a "single pointer").
>> Well, that particular expression works only in that case - but since
it
>> is effectively the client that (perhaps based on the data model)
decides
>> what the leafref-leafs "mean" (in this case the single key of a
single
>> list), other cases can be handled the same way. E.g. multiple
>> leafref-to-key leafs that together give the keys of a multi-key list
>> just amounts to a slightly hairier XPath filter...
>>
>> --Per
>>
>>>> with a server interpreting the request as follows:
>>>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>>>> matching one of the XPath from the "joint with" list, then the
server
>>>> must provide the entire body of the node pointed by the pointer,
>>>> otherwise, just the pointer (as it happens today, that is, when no
>>>> "joint with" list specified).
>>>>
>>>> We think that this would allow for the client to optimize the
number
>>>> of request-response iterations depending on application/use case.
>>>>
>>>> Regards,
>>>> Igor
>>>
>>>
>>> /martin
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Per Hedeland [mailto:per@tail-f.com]
>>>> Sent: Monday, October 09, 2017 12:06 PM
>>>> To: Xufeng Liu
>>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>>>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>> leafref
>>>>
>>>> I understand your use case, but a leaf of type leafref does not in
>>>> general identify a single node in the data tree - the leafref path
>>>> could
>>>> be for a non-key leaf, and/or the path could traverse list nodes,
>>>> and/or
>>>> the "target" list could have multiple keys and thus multiple
>>>> leafref-leafs be required to identify a specific list entry.
>>>>
>>>> Thus it seems to me that your use case is not a reasonable basis
for a
>>>> new protocol operation. My XPath foo isn't very good either, but I
do
>>>> believe Robert's suggestion of using an XPath filter could be a way
>>>> forward. I *think* the filter expression would be something along
the
>>>> lines of
>>>>
>>>>    /te/tunnels/tunnel[name='foo'] |
>>>>
/te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/pat
hs/path/explicit-path]
>>>>
>>>> --Per
>>>>
>>>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>>>> Hi Per,
>>>>>
>>>>>
>>>>>
>>>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>>>> *To:* Igor Bryskin ; per@tail-f.com;
>>>>> *xufeng.liu.ietf@gmail.com
>>>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed
by
>>>>> *leafref
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Joel,
>>>>>
>>>>> Thanks, I think I didnt explain our problem correctly.
>>>>>
>>>>> In our case we have a leafref pointing to a te tunnel name, which
>>>>> happens to be a key to lookup the (axilary) tunnel.  We need a way
to
>>>>> include the entire tunnel body (not just a name) into the get
>>>>> response. This is to optimize the number of iterations between the
>>>>> client and the server. As Xufeng put it something similar to SQL
join,
>>>>>
>>>>> Igor
>>>>>
>>>>> *From:*Igor Bryskin
>>>>>
>>>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>>>
>>>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>>>
>>>>> *Date:*2017-10-08 17:36:47
>>>>>
>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>
>>>>>
>>>>> Hi Per,
>>>>>
>>>>> In a nutshell we would lika for a netconf client to have a way to
>>>>> instruct the server on whether in response to the get request the
>>>>> server needs to provide the entire body of a datastore node
pointed
>>>>> to by a leafref or just a pointer to said node, so that the node's
>>>>> body could be retrieved by a subsequent separate request. This is
>>>>> requested by implementors who want to optimise rhe number of
>>>>> interactions between a client and its server.
>>>>>
>>>>> Cheers,
>>>>> Igor
>>>>>
>>>>> *From:*Per Hedeland
>>>>>
>>>>> *To:*Xufeng Liu,
>>>>>
>>>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>>>
>>>>> *Date:*2017-10-08 14:01:27
>>>>>
>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> *leafref
>>>>>
>>>>>
>>>>>
>>>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>>>> During the design team discussion for TE and MPLS YANG modeling,
we
>>>>>> have received a request from implementers: How to minimize the
number
>>>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>>>> Especially for the case when the operator or client software
needs to
>>>>>> retrieve the object contents pointed by a leafref.
>>>>>>
>>>>>> For example, given the following simplified TE tunnel model,
>>>>>>
>>>>>> +--rw te
>>>>>>
>>>>>>        +--rw explicit-paths
>>>>>>
>>>>>>        |  +--rw explicit-path* [name]
>>>>>>
>>>>>>        |     +--rw name                      string
>>>>>>
>>>>>>        |        +--rw explicit-route-object* [index]
>>>>>>
>>>>>>        |           +--rw index                   uint32
>>>>>>
>>>>>>        |           +--rw explicit-route-usage?   identityref
>>>>>>
>>>>>>        +--rw tunnels
>>>>>>
>>>>>>        |  +--rw tunnel* [name]
>>>>>>
>>>>>>        |  |  +--rw name                   string
>>>>>>
>>>>>>        |  |  +--rw paths
>>>>>>
>>>>>>        |  |  |  +--rw path* [name]
>>>>>>
>>>>>> |  |  |     +--rw explicit-path?  ->
>>>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>>>
>>>>>> when the client tries to retrieve a tunnels information based on
the
>>>>>> tunnel name, the get operation returns a list of leafrefs
pointing
>>>>>> to the paths of the tunnel.
>>>>> Sorry, I'm afraid I don't follow. Can you explain exactly what
your
>>>>> "get" request is (protocol and payload), and where the "list of
>>>>> leafref's" (whatever that may be) occurs in the reply?
>>>>>
>>>>> */[Xufeng] The get operation is the NETCONF/RESTCON 
protocol
>>>>> *operation, or the  operation described in
>>>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the
GET
>>>>> *operations
>>>>> on {+restconf}/ds/ described in
>>>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>>>
>>>>> */ /*
>>>>>
>>>>> */We have a list of leafref values because in this example model,
each
>>>>> *tunnel contains a list of paths, each of them contains a leafref.
The
>>>>> *get returns a value for each instance of such a leafref,
>>>>> which (as a string value) will be used as a constraint (foreign
key)
>>>>> to retrieve the instance of an explicit-path in the model above./*
>>>>>
>>>>>
>>>>>
>>>>> JFYI, in case there is some fundamental misunderstanding here: a
leaf
>>>>> of
>>>>> type leafref has a single value - *one* of those that satisfy the
>>>>> leafref
>>>>> constraint, in case there are multiple "candidates".
>>>>>
>>>>> --Per
>>>>>
>>>>>> The client needs to issue at
>>>>>> least one more get operation to retrieve the path information
about
>>>>>> the given tunnel. The request is to combine these two operations
into
>>>>>> one.
>>>>>>
>>>>>> In the RDBMS SQL world, join can be used when SQL select is
>>>>>> performed, but NETCONF/YANG currently does not have this
capability.
>>>>>>
>>>>>> Wed like to ask whether such a request is considered reasonable.
>>>>>>
>>>>>> If the request is reasonable, the next question is how to
>>>>>> proceed. This seems to be a protocol issue rather than YANG
modeling
>>>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>>>  operation with expanded leafrefs?
>>>>>>
>>>>>> Comments and suggestions are appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> - Xufeng
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>




------------------------------------------------------------------------
--------


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


From nobody Wed Oct 11 03:49:22 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328F8133341; Wed, 11 Oct 2017 03:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 hbHlX7lkPr4d; Wed, 11 Oct 2017 03:49:12 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD2513308D; Wed, 11 Oct 2017 03:49:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47111; q=dns/txt; s=iport; t=1507718951; x=1508928551; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bf4/PYXG9GB3XMxu3dorvn87flQI0wLHIuuBdZsk6nk=; b=OVuGAwBjP63b/7Sp4QzqDnxEuY//+DN07gAeHpJ/g3OgFpjjGi1IhXpK P9SKFgHRSnbi0h+dqfiHOluQPpO0bUnctjUdqpqC5g0DLn3hIJApMRQyd l5kD17KMeO6twusO9yU6XKdmNK0PzqqCBYWWmRPTNyFyXUOAf8qJOMRcJ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQD29d1Z/xbLJq1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvP4ERbieDeosTkCp5h0yNaoIPAwoYAQqBXoJrTwKFGRcBAgE?= =?us-ascii?q?BAQEBAQFrKIUdAQEBBAEBGAkERxcECxEDAQEBASABBgMCAiEGHwkIBgEMBgIBA?= =?us-ascii?q?RYBiXEDFRCpCoFtOieHHg2DYgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgy2DU4F?= =?us-ascii?q?qK4JJNYJegXsVNoJzgmEFihMIhyaHHYgiPIdeiBKEeYIUhXODWocujHuBCYdfg?= =?us-ascii?q?TkhAjSBDjIhCB0VSYUaHIFoPzYBAQGHECyCFQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,361,1503360000";  d="scan'208,217";a="655386848"
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; 11 Oct 2017 10:49:08 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9BAn7cA019888; Wed, 11 Oct 2017 10:49:07 GMT
To: "t.petch" , Igor Bryskin , netconf@ietf.org, netmod@ietf.org
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>   <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com> <42819484-f9b5-4f06-dd58-23d9bc8c1ecc@cisco.com>  <02aa01d34275$192f1840$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: 
Date: Wed, 11 Oct 2017 11:49:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <02aa01d34275$192f1840$4001a8c0@gateway.2wire.net>
Content-Type: multipart/alternative; boundary="------------160EB91B6F901AE456FBD2D0"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Oct 2017 10:49:15 -0000

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

I've also been thinking about this problem a bit more :-)

The XPath solution works, but the expression isn't particularly nice to 
write, and I suspect that implementations may struggle to implement it 
efficiently (if they support XPath filtering at all).

A nicer solution here might be to allow the XPath filters to be combined 
with a subtree filter along the lines of a more advanced type of 
"Attribute Match Expression" sec 6.2.2 of rfc6241.

E.g. rather than this XPath filter:

/te:te/te:tunnels/te:tunnel[te:name='foo'] |
/te:te/te:connections/te:connection[te:name=/te:te/te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name]

Here is example of what a subtree filter combined with an XPath filter 
could potentially look like (which of course isn't valid NETCONF/YANG 
today):


   
     
     
       
     
   



Any opinions on whether this would be beneficial or is this just 
reinventing the wheel?

Thanks,
Rob


On 11/10/2017 10:41, t.petch wrote:
> Igor
>
> Thinking laterally, this is a problem that DNS encountered a few decades
> ago and solved, by allowing the server to include additional information
> not specifically requested that the server can see is going to be needed
> for the next step, so if the client asks only about a CNAME, then the
> server can provide the relevant IP address as well.
>
> I suspect that the current rules for Netconf do not allow the server to
> send anything not explicitly requested, which is a shame (IMO).
>
> The DNS approach works very well, in fact I do not think we would
> survive without it.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Igor Bryskin" 
> Sent: Tuesday, October 10, 2017 2:35 PM
>
> Hi Rob,
>
> This helps a lot. What you wrote will work.
>
> The only difference is that if we would have the "joimt with" clause as
> we proposed, the server would be able to tailor the te-tunnel
> presentation to the client's requirements, e.g. substituting the
> connection pointers with connection bodies, while, according to your
> suggestion, the server will provide the te-tunnel body as is, and then
> augment it with the cobbection information, thus, leaving
> for the client to "shuffle " the received data. But I do agree, this
> would be a minor inconvinience for the client, the important thing is
> that the client will get all the data in one piece.
>
> Thanks a lot,
> Igor
>
> c
>
> From:Robert Wilton
> To:Igor Bryskin,
> Cc:Per Hedeland,netmod@ietf.org,netconf@ietf.org,
> Date:2017-10-10 06:41:04
> Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
>
> Hi Igor,
>
> On 09/10/2017 23:11, Igor Bryskin wrote:
>> Hi Per,
>>
>> This is a good news, but, please, help us out.
>> Consider, we have a node - "te-tunnel" - which among other attributes
> has two key leafref lists:
>> 1) each member of the 1st list points to a "connection" supporting the
> te-tunnel. All connections supporting all te-tunnels are stored in a
> single list of connections.
>> 2) each member of the 2nd list points to a supporting "te-tunnel" -
> the te-tunnel in question depends on. All te=tunnels including the
> te-tunnel in question, are stored in a single list of te-tunnels.
>> The question: how the client can retrieve via a single request all
> attributes of the te-tunnel in question along with all parameters of all
> connections supporting the te-tunnel, but with just pointers to
> supporting te-tunnels (so that the interested client can use the
> pointers to retrieve full data via subsequent separate requests) ?
> I think that it might be something like this (for tunnel name foo):
>
>     /te/tunnels/tunnel[name='foo'] |
>
> /te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio
> ns/connection/name]
>
> E.g. in English, this should equate to something like:
>
> Return all information for tunnel foo AND ALSO
> Return all information for all connections where the connection name
> matches one of the connections listed in tunnel foo.
>
>> Likewise, how the client can ask for full data of the te-tunnel and
> all supporting te-tunnels and just pointers for supporting connections?
> If my xpath above is right, then this would be something roughly like
> this:
>
>     /te/tunnels/tunnel[name='foo'] |
>
> /te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel
> s/supporting-tunnel/name]
>
>
> I'm an XPath novice, so the expressions might be wrong.
>
> https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if
> you can construct a simple XML instance tree of your data, you could
> validate whether the XPath expression works.
>
> I hope that this is of some help,
> Rob
>
>
>> I really appreciate your help,
>>
>> Igor
>>
>>
>> -----Original Message-----
>> From: Per Hedeland [mailto:per@tail-f.com]
>> Sent: Monday, October 09, 2017 5:21 PM
>> To: Igor Bryskin
>> Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org;
> netmod@ietf.org
>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
> leafref
>> Just to be clear: what we're suggesting is that you can use the
>> already-existing standard NETCONF XPath capability to achieve the
> desired
>> result - see https://tools.ietf.org/html/rfc6241#section-8.9
>>
>> --Per
>>
>> On 2017-10-09 21:52, Igor Bryskin wrote:
>>> I agree. For example, a leafref may point not to a singls entity, but
> to a list of entities, and the client might want to expand all of them
> into the joint get response.
>>> Igor
>>>
>>> *From:*Per Hedeland
>>> *To:*Martin Bjorklund,
>>> *Cc:*Igor
> Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,
>>> *Date:*2017-10-09 15:12:22
>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
> leafref
>>> On 2017-10-09 19:13, Martin Bjorklund wrote:
>>>> Igor Bryskin  wrote:
>>>>> Hi Per,
>>>>>
>>>>> Basically, what we need is a way for a client to request something
>>>>> like this:
>>>>>
>>>>> get  joint with 
>>>> ... which is what Per's expression does!  Note that "|" in XPath
> means
>>>> "union".
>>>>
>>>> But as Per explained, it only works in some cases (when the leafref
>>>> acts a "single pointer").
>>> Well, that particular expression works only in that case - but since
> it
>>> is effectively the client that (perhaps based on the data model)
> decides
>>> what the leafref-leafs "mean" (in this case the single key of a
> single
>>> list), other cases can be handled the same way. E.g. multiple
>>> leafref-to-key leafs that together give the keys of a multi-key list
>>> just amounts to a slightly hairier XPath filter...
>>>
>>> --Per
>>>
>>>>> with a server interpreting the request as follows:
>>>>> if a node pointed by XPath contains a pointer (e.g. key leafref)
>>>>> matching one of the XPath from the "joint with" list, then the
> server
>>>>> must provide the entire body of the node pointed by the pointer,
>>>>> otherwise, just the pointer (as it happens today, that is, when no
>>>>> "joint with" list specified).
>>>>>
>>>>> We think that this would allow for the client to optimize the
> number
>>>>> of request-response iterations depending on application/use case.
>>>>>
>>>>> Regards,
>>>>> Igor
>>>>
>>>> /martin
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Per Hedeland [mailto:per@tail-f.com]
>>>>> Sent: Monday, October 09, 2017 12:06 PM
>>>>> To: Xufeng Liu
>>>>> Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
>>>>> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>> leafref
>>>>>
>>>>> I understand your use case, but a leaf of type leafref does not in
>>>>> general identify a single node in the data tree - the leafref path
>>>>> could
>>>>> be for a non-key leaf, and/or the path could traverse list nodes,
>>>>> and/or
>>>>> the "target" list could have multiple keys and thus multiple
>>>>> leafref-leafs be required to identify a specific list entry.
>>>>>
>>>>> Thus it seems to me that your use case is not a reasonable basis
> for a
>>>>> new protocol operation. My XPath foo isn't very good either, but I
> do
>>>>> believe Robert's suggestion of using an XPath filter could be a way
>>>>> forward. I *think* the filter expression would be something along
> the
>>>>> lines of
>>>>>
>>>>>     /te/tunnels/tunnel[name='foo'] |
>>>>>
> /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/pat
> hs/path/explicit-path]
>>>>> --Per
>>>>>
>>>>> On 2017-10-09 15:42, Xufeng Liu wrote:
>>>>>> Hi Per,
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>>>>>> *Sent:* Sunday, October 8, 2017 7:04 PM
>>>>>> *To:* Igor Bryskin ; per@tail-f.com;
>>>>>> *xufeng.liu.ietf@gmail.com
>>>>>> *Cc:* netconf@ietf.org; netmod@ietf.org
>>>>>> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed
> by
>>>>>> *leafref
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Joel,
>>>>>>
>>>>>> Thanks, I think I didnt explain our problem correctly.
>>>>>>
>>>>>> In our case we have a leafref pointing to a te tunnel name, which
>>>>>> happens to be a key to lookup the (axilary) tunnel.  We need a way
> to
>>>>>> include the entire tunnel body (not just a name) into the get
>>>>>> response. This is to optimize the number of iterations between the
>>>>>> client and the server. As Xufeng put it something similar to SQL
> join,
>>>>>> Igor
>>>>>>
>>>>>> *From:*Igor Bryskin
>>>>>>
>>>>>> *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,
>>>>>>
>>>>>> *Cc:*netconf@ietf.org,netmod@ietf.org,
>>>>>>
>>>>>> *Date:*2017-10-08 17:36:47
>>>>>>
>>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>>> *leafref
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Per,
>>>>>>
>>>>>> In a nutshell we would lika for a netconf client to have a way to
>>>>>> instruct the server on whether in response to the get request the
>>>>>> server needs to provide the entire body of a datastore node
> pointed
>>>>>> to by a leafref or just a pointer to said node, so that the node's
>>>>>> body could be retrieved by a subsequent separate request. This is
>>>>>> requested by implementors who want to optimise rhe number of
>>>>>> interactions between a client and its server.
>>>>>>
>>>>>> Cheers,
>>>>>> Igor
>>>>>>
>>>>>> *From:*Per Hedeland
>>>>>>
>>>>>> *To:*Xufeng Liu,
>>>>>>
>>>>>> *Cc:*netconf@ietf.org,'NetMod WG',
>>>>>>
>>>>>> *Date:*2017-10-08 14:01:27
>>>>>>
>>>>>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>>>>>> *leafref
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2017-10-06 23:11, Xufeng Liu wrote:
>>>>>>> During the design team discussion for TE and MPLS YANG modeling,
> we
>>>>>>> have received a request from implementers: How to minimize the
> number
>>>>>>> of NETCONF/RESTCONF RPCs to improve operation efficiency?
>>>>>>> Especially for the case when the operator or client software
> needs to
>>>>>>> retrieve the object contents pointed by a leafref.
>>>>>>>
>>>>>>> For example, given the following simplified TE tunnel model,
>>>>>>>
>>>>>>> +--rw te
>>>>>>>
>>>>>>>         +--rw explicit-paths
>>>>>>>
>>>>>>>         |  +--rw explicit-path* [name]
>>>>>>>
>>>>>>>         |     +--rw name                      string
>>>>>>>
>>>>>>>         |        +--rw explicit-route-object* [index]
>>>>>>>
>>>>>>>         |           +--rw index                   uint32
>>>>>>>
>>>>>>>         |           +--rw explicit-route-usage?   identityref
>>>>>>>
>>>>>>>         +--rw tunnels
>>>>>>>
>>>>>>>         |  +--rw tunnel* [name]
>>>>>>>
>>>>>>>         |  |  +--rw name                   string
>>>>>>>
>>>>>>>         |  |  +--rw paths
>>>>>>>
>>>>>>>         |  |  |  +--rw path* [name]
>>>>>>>
>>>>>>> |  |  |     +--rw explicit-path?  ->
>>>>>>> |  |  |     ../../../../../explicit-paths/explicit-path/name
>>>>>>>
>>>>>>> when the client tries to retrieve a tunnels information based on
> the
>>>>>>> tunnel name, the get operation returns a list of leafrefs
> pointing
>>>>>>> to the paths of the tunnel.
>>>>>> Sorry, I'm afraid I don't follow. Can you explain exactly what
> your
>>>>>> "get" request is (protocol and payload), and where the "list of
>>>>>> leafref's" (whatever that may be) occurs in the reply?
>>>>>>
>>>>>> */[Xufeng] The get operation is the NETCONF/RESTCON 
> protocol
>>>>>> *operation, or the  operation described in
>>>>>> *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the
> GET
>>>>>> *operations
>>>>>> on {+restconf}/ds/ described in
>>>>>> https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>>>>>>
>>>>>> */ /*
>>>>>>
>>>>>> */We have a list of leafref values because in this example model,
> each
>>>>>> *tunnel contains a list of paths, each of them contains a leafref.
> The
>>>>>> *get returns a value for each instance of such a leafref,
>>>>>> which (as a string value) will be used as a constraint (foreign
> key)
>>>>>> to retrieve the instance of an explicit-path in the model above./*
>>>>>>
>>>>>>
>>>>>>
>>>>>> JFYI, in case there is some fundamental misunderstanding here: a
> leaf
>>>>>> of
>>>>>> type leafref has a single value - *one* of those that satisfy the
>>>>>> leafref
>>>>>> constraint, in case there are multiple "candidates".
>>>>>>
>>>>>> --Per
>>>>>>
>>>>>>> The client needs to issue at
>>>>>>> least one more get operation to retrieve the path information
> about
>>>>>>> the given tunnel. The request is to combine these two operations
> into
>>>>>>> one.
>>>>>>>
>>>>>>> In the RDBMS SQL world, join can be used when SQL select is
>>>>>>> performed, but NETCONF/YANG currently does not have this
> capability.
>>>>>>> Wed like to ask whether such a request is considered reasonable.
>>>>>>>
>>>>>>> If the request is reasonable, the next question is how to
>>>>>>> proceed. This seems to be a protocol issue rather than YANG
> modeling
>>>>>>> issue. Is it acceptable to add a new operation to achieve such a
>>>>>>>  operation with expanded leafrefs?
>>>>>>>
>>>>>>> Comments and suggestions are appreciated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> - Xufeng
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf.org 
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>> _______________________________________________
>> 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
>>
> .
>


--------------160EB91B6F901AE456FBD2D0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
I've also been thinking about this problem a bit more :-)

    
The XPath solution works, but the expression isn't particularly
      nice to write, and I suspect that implementations may struggle to
      implement it efficiently (if they support XPath filtering at all).

    
A nicer solution here might be to allow the XPath filters to be
      combined with a subtree filter along the lines of a more advanced
      type of "Attribute Match Expression" sec 6.2.2 of rfc6241.

    
E.g. rather than this XPath filter:

    
/te:te/te:tunnels/te:tunnel[te:name='foo'] |
/te:te/te:connections/te:connection[te:name=/te:te/te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name]



    
 Here is example of what a subtree filter combined with an XPath
      filter could potentially look like (which of course isn't valid
      NETCONF/YANG today):

    
<filter type="subtree-xpath">
  <te:te xmlns:te="...">
    <te:tunnels te:name="foo"/>
    <te:connections>
      <filter type="xpath" select="te:name = ../te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name)"/>
    </te:connections>
  </te:te>
</filter>

    

    Any opinions on whether this would be beneficial or is this just
    reinventing the wheel?

    

    Thanks,

    Rob

    

    

    
On 11/10/2017 10:41, t.petch wrote:

    

    

      
Igor

Thinking laterally, this is a problem that DNS encountered a few decades
ago and solved, by allowing the server to include additional information
not specifically requested that the server can see is going to be needed
for the next step, so if the client asks only about a CNAME, then the
server can provide the relevant IP address as well.

I suspect that the current rules for Netconf do not allow the server to
send anything not explicitly requested, which is a shame (IMO).

The DNS approach works very well, in fact I do not think we would
survive without it.

Tom Petch

----- Original Message -----
From: "Igor Bryskin" <Igor.Bryskin@huawei.com>
Sent: Tuesday, October 10, 2017 2:35 PM

Hi Rob,

This helps a lot. What you wrote will work.

The only difference is that if we would have the "joimt with" clause as
we proposed, the server would be able to tailor the te-tunnel
presentation to the client's requirements, e.g. substituting the
connection pointers with connection bodies, while, according to your
suggestion, the server will provide the te-tunnel body as is, and then
augment it with the cobbection information, thus, leaving
for the client to "shuffle " the received data. But I do agree, this
would be a minor inconvinience for the client, the important thing is
that the client will get all the data in one piece.

Thanks a lot,
Igor

c

From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,netmod@ietf.org,netconf@ietf.org,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

Hi Igor,

On 09/10/2017 23:11, Igor Bryskin wrote:


      

        
Hi Per,

This is a good news, but, please, help us out.
Consider, we have a node - "te-tunnel" - which among other attributes


      

      
has two key leafref lists:


      

        
1) each member of the 1st list points to a "connection" supporting the


      

      
te-tunnel. All connections supporting all te-tunnels are stored in a
single list of connections.


      

        
2) each member of the 2nd list points to a supporting "te-tunnel" -


      

      
the te-tunnel in question depends on. All te=tunnels including the
te-tunnel in question, are stored in a single list of te-tunnels.


      

        
The question: how the client can retrieve via a single request all


      

      
attributes of the te-tunnel in question along with all parameters of all
connections supporting the te-tunnel, but with just pointers to
supporting te-tunnels (so that the interested client can use the
pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):

   /te/tunnels/tunnel[name='foo'] |

/te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio
ns/connection/name]

E.g. in English, this should equate to something like:

Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name
matches one of the connections listed in tunnel foo.



      

        
Likewise, how the client can ask for full data of the te-tunnel and


      

      
all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like
this:

   /te/tunnels/tunnel[name='foo'] |

/te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel
s/supporting-tunnel/name]


I'm an XPath novice, so the expressions might be wrong.

https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if
you can construct a simple XML instance tree of your data, you could
validate whether the XPath expression works.

I hope that this is of some help,
Rob




      

        
I really appreciate your help,

Igor


-----Original Message-----
From: Per Hedeland [mailto:per@tail-f.com]
Sent: Monday, October 09, 2017 5:21 PM
To: Igor Bryskin
Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org;


      

      
netmod@ietf.org


      

        
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by


      

      
leafref


      

        
Just to be clear: what we're suggesting is that you can use the
already-existing standard NETCONF XPath capability to achieve the


      

      
desired


      

        
result - see https://tools.ietf.org/html/rfc6241#section-8.9

--Per

On 2017-10-09 21:52, Igor Bryskin wrote:


        

          
I agree. For example, a leafref may point not to a singls entity, but


        

      

      
to a list of entities, and the client might want to expand all of them
into the joint get response.


      

        

          
Igor

*From:*Per Hedeland
*To:*Martin Bjorklund,
*Cc:*Igor


        

      

      
Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,


      

        

          
*Date:*2017-10-09 15:12:22
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by


        

      

      
leafref


      

        

          
On 2017-10-09 19:13, Martin Bjorklund wrote:


          

            
Igor Bryskin <Igor.Bryskin@huawei.com> wrote:


            

              
Hi Per,

Basically, what we need is a way for a client to request something
like this:

get <XPath> joint with <XPath1, XPath2, ..., XPathn>


            

            
... which is what Per's expression does!  Note that "|" in XPath


          

        

      

      
means


      

        

          

            
"union".

But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").


          

          
Well, that particular expression works only in that case - but since


        

      

      
it


      

        

          
is effectively the client that (perhaps based on the data model)


        

      

      
decides


      

        

          
what the leafref-leafs "mean" (in this case the single key of a


        

      

      
single


      

        

          
list), other cases can be handled the same way. E.g. multiple
leafref-to-key leafs that together give the keys of a multi-key list
just amounts to a slightly hairier XPath filter...

--Per



          

            

              
with a server interpreting the request as follows:
if a node pointed by XPath contains a pointer (e.g. key leafref)
matching one of the XPath from the "joint with" list, then the


            

          

        

      

      
server


      

        

          

            

              
must provide the entire body of the node pointed by the pointer,
otherwise, just the pointer (as it happens today, that is, when no
"joint with" list specified).

We think that this would allow for the client to optimize the


            

          

        

      

      
number


      

        

          

            

              
of request-response iterations depending on application/use case.

Regards,
Igor


            

            

/martin




            

              




-----Original Message-----
From: Per Hedeland [mailto:per@tail-f.com]
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref

I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path
could
be for a non-key leaf, and/or the path could traverse list nodes,
and/or
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.

Thus it seems to me that your use case is not a reasonable basis


            

          

        

      

      
for a


      

        

          

            

              
new protocol operation. My XPath foo isn't very good either, but I


            

          

        

      

      
do


      

        

          

            

              
believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along


            

          

        

      

      
the


      

        

          

            

              
lines of

   /te/tunnels/tunnel[name='foo'] |



            

          

        

      

      
/te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/pat
hs/path/explicit-path]


      

        

          

            

              
--Per

On 2017-10-09 15:42, Xufeng Liu wrote:


              

                
Hi Per,



*From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
*Sent:* Sunday, October 8, 2017 7:04 PM
*To:* Igor Bryskin <Igor.Bryskin@huawei.com>; per@tail-f.com;
*xufeng.liu.ietf@gmail.com
*Cc:* netconf@ietf.org; netmod@ietf.org
*Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed


              

            

          

        

      

      
by


      

        

          

            

              

                
*leafref




Hi Joel,

Thanks, I think I didnt explain our problem correctly.

In our case we have a leafref pointing to a te tunnel name, which
happens to be a key to lookup the (axilary) tunnel.  We need a way


              

            

          

        

      

      
to


      

        

          

            

              

                
include the entire tunnel body (not just a name) into the get
response. This is to optimize the number of iterations between the
client and the server. As Xufeng put it something similar to SQL


              

            

          

        

      

      
join,


      

        

          

            

              

                
Igor

*From:*Igor Bryskin

*To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,

*Cc:*netconf@ietf.org,netmod@ietf.org,

*Date:*2017-10-08 17:36:47

*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref



Hi Per,

In a nutshell we would lika for a netconf client to have a way to
instruct the server on whether in response to the get request the
server needs to provide the entire body of a datastore node


              

            

          

        

      

      
pointed


      

        

          

            

              

                
to by a leafref or just a pointer to said node, so that the node's
body could be retrieved by a subsequent separate request. This is
requested by implementors who want to optimise rhe number of
interactions between a client and its server.

Cheers,
Igor

*From:*Per Hedeland

*To:*Xufeng Liu,

*Cc:*netconf@ietf.org,'NetMod WG',

*Date:*2017-10-08 14:01:27

*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref



On 2017-10-06 23:11, Xufeng Liu wrote:


                

                  
During the design team discussion for TE and MPLS YANG modeling,


                

              

            

          

        

      

      
we


      

        

          

            

              

                

                  
have received a request from implementers: How to minimize the


                

              

            

          

        

      

      
number


      

        

          

            

              

                

                  
of NETCONF/RESTCONF RPCs to improve operation efficiency?
Especially for the case when the operator or client software


                

              

            

          

        

      

      
needs to


      

        

          

            

              

                

                  
retrieve the object contents pointed by a leafref.

For example, given the following simplified TE tunnel model,

+--rw te

       +--rw explicit-paths

       |  +--rw explicit-path* [name]

       |     +--rw name                      string

       |        +--rw explicit-route-object* [index]

       |           +--rw index                   uint32

       |           +--rw explicit-route-usage?   identityref

       +--rw tunnels

       |  +--rw tunnel* [name]

       |  |  +--rw name                   string

       |  |  +--rw paths

       |  |  |  +--rw path* [name]

|  |  |     +--rw explicit-path?  ->
|  |  |     ../../../../../explicit-paths/explicit-path/name

when the client tries to retrieve a tunnels information based on


                

              

            

          

        

      

      
the


      

        

          

            

              

                

                  
tunnel name, the get operation returns a list of leafrefs


                

              

            

          

        

      

      
pointing


      

        

          

            

              

                

                  
to the paths of the tunnel.


                

                
Sorry, I'm afraid I don't follow. Can you explain exactly what


              

            

          

        

      

      
your


      

        

          

            

              

                
"get" request is (protocol and payload), and where the "list of
leafref's" (whatever that may be) occurs in the reply?

*/[Xufeng] The get operation is the NETCONF/RESTCON <get>


              

            

          

        

      

      
protocol


      

        

          

            

              

                
*operation, or the <get-data> operation described in
*https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the


              

            

          

        

      

      
GET


      

        

          

            

              

                
*operations
on {+restconf}/ds/<datastore> described in
https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*

*/ /*

*/We have a list of leafref values because in this example model,


              

            

          

        

      

      
each


      

        

          

            

              

                
*tunnel contains a list of paths, each of them contains a leafref.


              

            

          

        

      

      
The


      

        

          

            

              

                
*get returns a value for each instance of such a leafref,
which (as a string value) will be used as a constraint (foreign


              

            

          

        

      

      
key)


      

        

          

            

              

                
to retrieve the instance of an explicit-path in the model above./*



JFYI, in case there is some fundamental misunderstanding here: a


              

            

          

        

      

      
leaf


      

        

          

            

              

                
of
type leafref has a single value - *one* of those that satisfy the
leafref
constraint, in case there are multiple "candidates".

--Per



                

                  
The client needs to issue at
least one more get operation to retrieve the path information


                

              

            

          

        

      

      
about


      

        

          

            

              

                

                  
the given tunnel. The request is to combine these two operations


                

              

            

          

        

      

      
into


      

        

          

            

              

                

                  
one.

In the RDBMS SQL world, join can be used when SQL select is
performed, but NETCONF/YANG currently does not have this


                

              

            

          

        

      

      
capability.


      

        

          

            

              

                

                  
Wed like to ask whether such a request is considered reasonable.

If the request is reasonable, the next question is how to
proceed. This seems to be a protocol issue rather than YANG


                

              

            

          

        

      

      
modeling


      

        

          

            

              

                

                  
issue. Is it acceptable to add a new operation to achieve such a
<get-data> operation with expanded leafrefs?

Comments and suggestions are appreciated.

Thanks,

- Xufeng



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



                

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



              

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



      

      



------------------------------------------------------------------------
--------




      

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



      

      
.



    

    

  


--------------160EB91B6F901AE456FBD2D0--


From nobody Wed Oct 11 07:26:03 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C4B1330BF; Wed, 11 Oct 2017 07:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 reJFpgot0t7q; Wed, 11 Oct 2017 07:25:52 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0131.outbound.protection.outlook.com [104.47.41.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08B9126CB6; Wed, 11 Oct 2017 07:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y5kiDgjGtBKUrd2kR0pGpHApfEsTQVxDDSLJ9XQ++eQ=; b=CTVX7LEh+2A+U7A2MEiVDgFQ51o+0Cqk0zt2RxwZQxBa1Jy1Ci1MhKpt96PSPax2HdW6+HGzsPGQdoVWZ/9N12OEWmV2DXHb/mfz1Y2UlYhNrg/CKGeHZJwhga18niA8hFTdVXO4vkqvfsr7plcS96ia4P2H7XG7AHwRmqJdnks=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB276.namprd05.prod.outlook.com (10.141.22.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 11 Oct 2017 14:25:51 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0077.020; Wed, 11 Oct 2017 14:25:50 +0000
From: Kent Watsen 
To: Martin Bjorklund , "rwilton@cisco.com" 
CC: "rtg-dt-yang-arch@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
Thread-Index: AQHTO3+c5Os2e4kxykquLUmb6mNpK6LW+bYAgAAIHACABQw4AIAA18gAgAAEDwCAAZW/gA==
Date: Wed, 11 Oct 2017 14:25:50 +0000
Message-ID: <424B35F1-CA91-44B7-902C-478AFD16008B@juniper.net>
References: <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com> <16eda4e4-5612-918c-9d06-eec39f67e88a@cisco.com>  <20171010.121338.957274767620281285.mbj@tail-f.com>
In-Reply-To: <20171010.121338.957274767620281285.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:Sms0TK0FYsnwcxVU2W2K/GVzS/sptSsDbDNJYTldhDxO9dwMP7XeUI8kPm30mAwgtsT/kWEsoascse0BqMaCQsC4QrY09qVC7mUwIhx476gZwAVfE+Dba7g5dqltFPqSHrDqvhLiQwOJaUZ2mLU1r1kC8FK/i+vngZTXwQTEt7bez19tsG6hyZMIaQfY3rlqMcikaeAxUGMQVdYaifdb7iJz8L9NtlDoqF46oNflufNUDBfKdKNj1r3UhSeb9GK3gGcRlHJArc70+64d2CQmupuT4Q0DDcUFL/6VxYwteuNc2/epiPu2BhKATIgocn8C+Cz1scCj25kISkXdVKPPUw==; 5:fpok3OC0izjTdaTJ3u3FNvz9Nqx+zFCi8WkeoepToMF+QK3GYxR0FazJsAziLi3FGFxZJPmpu81SPA9ZqEEERADof0qIP4MOrXl6BZPWz4aLj1i8l1q1rwfsUs7IwHfjDI3CzCO/T52Zb/Fsuw084Q==; 24:dWBbPBABG5ciXwNTuSyfsFgsNdoxTMSVpzLZcBe0Q8bG7L3noRfWtM/9Jy7TnuKYU1ZSBTzaHTkPHZHzo7uOhOa0h1hU19MntFYJ+rXXJi0=; 7:bxuyJ+PJBWnRaUoHXC8NaXrZgUtCgcYE8UKr1050YKCtpBEPCVCO+DrcAQ5pg68qrFCH0n0Z0iut85zYLlMEleEpLumTG5mhz14MqQnPmM2W4jQFnddVIScmxXwSYgP6WX76emZeYh/gI7f74xzr+01BdgoQ59C5WjODna4Zsv5BEKk0wxKBruQCpO21DI0ygLFVZizs0m4cP+XmxcLdeM9/ZV/m5WITYQuOVgwHUZE=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: a5c847d7-0f97-4b26-c6b3-08d510b3f921
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB276; 
x-ms-traffictypediagnostic: BLUPR05MB276:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:(10436049006162)(95692535739014);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB276; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB276; 
x-forefront-prvs: 0457F11EAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(377454003)(199003)(51444003)(24454002)(189002)(2900100001)(68736007)(102836003)(6116002)(106356001)(86362001)(105586002)(575784001)(54356999)(6506006)(76176999)(6436002)(77096006)(99286003)(33656002)(6512007)(6306002)(6486002)(50986999)(53936002)(189998001)(101416001)(4326008)(229853002)(6246003)(3846002)(5660300001)(966005)(83716003)(93886005)(478600001)(83506001)(2950100002)(82746002)(66066001)(36756003)(53546010)(3280700002)(81166006)(81156014)(305945005)(14454004)(2906002)(8676002)(110136005)(8936002)(3660700001)(25786009)(54906003)(316002)(97736004)(2501003)(230783001)(58126008)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB276; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2017 14:25:50.6473 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB276
Archived-At: 
Subject: Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Oct 2017 14:25:56 -0000

SSBhZ3JlZSAtIGxldCdzIGtlZXAgdGhlIG1vZHVsZSBuYW1lIGFuZCBtYXJrIHRoZSBub2RlcyBv
YnNvbGV0ZS4NCg0KS2VudCAvLyBhbnkgaGF0DQoNCg0KDQpSb2JlcnQgV2lsdG9uIDxyd2lsdG9u
QGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gT24gMDkvMTAvMjAxNyAyMjowNiwgQmVub2l0
IENsYWlzZSB3cm90ZToNCj4gPiBPbiAxMC82LzIwMTcgNjowMSBQTSwgUm9iZXJ0IFdpbHRvbiB3
cm90ZToNCj4gPj4NCj4gPj4NCj4gPj4gT24gMDYvMTAvMjAxNyAxNjozMiwgTWFydGluIEJqb3Jr
bHVuZCB3cm90ZToNCj4gPj4+IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiB3cm90
ZToNCj4gPj4+PiBEZWFyIGFsbCwNCj4gPj4+Pg0KPiA+Pj4+IFtpbmNsdWRpbmcgdGhlIHJvdXRp
bmcgYW5kIG11bHRpY2FzdCBZQU5HIGRlc2lnbiB0ZWFtc10NCj4gPj4+PiBDYW4gd2UgcGxlYXNl
IGZpbmFsaXplIHRoZSBkaXNjdXNzaW9uIHJlZ2FyZGluZyBpZXRmLXJvdXRpbmcgdmVyc3VzDQo+
ID4+Pj4gaWV0Zi1yb3V0aW5nLTIsIHNvb25lciB0aGFuIGxhdGVyLg0KPiA+Pj4+DQo+ID4+Pj4g
SSBjYXJlIGFib3V0IHRoZSBOTURBIHRyYW5zaXRpb24gc3RyYXRlZ3kuDQo+ID4+Pj4NCj4gPj4+
PiBIZXJlIGFyZSBhbGwgdGhlIGlldGYtcm91dGluZyBkZXBlbmRlbnQgWUFORyBtb2R1bGVzICh0
aG9zZSBtb2R1bGVzDQo+ID4+Pj4gdGhhdCBkZXBlbmQgb24gaWV0Zi1yb3V0aW5nKQ0KPiA+Pj4+
IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3
LnlhbmdjYXRhbG9nLm9yZ195YW5nLTJEc2VhcmNoX2ltcGFjdC01RmFuYWx5c2lzLnBocC0zRm1v
ZHVsZXMtNUItNUQtM0RpZXRmLTJEcm91dGluZy0yNnJlY3Vyc2UtM0QwLTI2cmZjcy0zRDEtMjZz
aG93LTVGc3VibS0zRDEtMjZzaG93LTVGZGlyLTNEZGVwZW5kZW50cyZkPUR3SUZBdyZjPUhBa1l1
aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQ
b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09a1hfUF92YWlPa1dOb2hLS0wwSFA4OFUtZ2xY
c21obHlqZ1d3N3J4ZzFidyZzPVBFdlZpMmRORjVfZ0lDSjdYOTdpdWN0TmFBeVVWNVBnbnNyMkxp
RExGRUEmZT0NCj4gPj4+PiBTbyBtYW55IFlBTkcgbW9kdWxlcy4NCj4gPj4+Pg0KPiA+Pj4+IExv
b2sgYXQgdGhlIGRpZmZlcmVuY2UgZm9yIGlldGYtcm91dGluZy0yOg0KPiA+Pj4+IGh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LnlhbmdjYXRh
bG9nLm9yZ195YW5nLTJEc2VhcmNoX2ltcGFjdC01RmFuYWx5c2lzLnBocC0zRm1vZHVsZXMtNUIt
NUQtM0RpZXRmLTJEcm91dGluZy0yRDItMjZyZWN1cnNlLTNEMC0yNnJmY3MtM0QxLTI2c2hvdy01
RnN1Ym0tM0QxLTI2c2hvdy01RmRpci0zRGRlcGVuZGVudHMmZD1Ed0lGQXcmYz1IQWtZdWg2M3Jz
dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZ
aHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWtYX1BfdmFpT2tXTm9oS0tMMEhQODhVLWdsWHNtaGx5
amdXdzdyeGcxYncmcz1JU2dWZV9zY3VDT29rZnNGOEM2Mm9laUdoZlRXTWpsQVhpUzdiblM0Y3Bj
JmU9DQo+ID4+Pj4gU29tZSBkZXBlbmRlbnQgbW9kdWxlcyBhcmUgY29tcGxpYW50IHdpdGggaWV0
Zi1yb3V0aW5nLTIsIHRoZQ0KPiA+Pj4+IG11bHRpY2FzdCBZQU5HIG1vZHVsZXMsIGJ1dCB0aGVz
ZSBhcmUgdGhlIG9ubHkgb25lcy4NCj4gPj4+Pg0KPiA+Pj4+IENoYW5naW5nIHRoZSBtb2R1bGUg
bmFtZSBmcm9tIGlldGYtcm91dGluZyB0byBpZXRmLXJvdXRpbmctMiBpbXBsaWVzDQo+ID4+Pj4g
dGhhdCB0aGUgd2UgaGF2ZSB0byB3YXJuIGFsbCBkcmFmdCBhdXRob3JzIG9mIGlldGYtcm91dGlu
ZyBZQU5HDQo+ID4+Pj4gZGVwZW5kZW50IG1vZHVsZXM6DQo+ID4+Pj4gw4Igw4Igw4Igw4IgIDEu
IHRvIG1ha2Ugc3VyZSB0aGV5IGFyZSBhd2FyZSBvZiBpZXRmLXJvdXRpbmctMiAocHVibGlzaGlu
ZyBhDQo+ID4+Pj4gUkZDODAyMmJpcyBtZW50aW9uaW5nIGluIHRoZSBtb2R1bGUgZGVzY3JpcHRp
b24gdGhhdCB0aGlzIG1vZHVsZSBpcw0KPiA+Pj4+IG5vdCBjb21wYXRpYmxlIHdpdGggdGhlIE5N
REEgYXJjaGl0ZWN0dXJlLCBhbmQgcHJvdmlkaW5nIGEgcG9pbnRlciB0bw0KPiA+Pj4+IGlldGYt
cm91dGluZy0yIC4uLiBpcyBub3QgYW4gYXV0b21hdGljIHdheS4uLiBzbyBiYXJlbHkgdXNlZnVs
KQ0KPiA+Pj4+IMOCIMOCIMOCIMOCICAyLiB0byBhc2sgdGhlbSB0byBjaGFuZ2UgdGhlaXIgaW1w
b3J0IHRvIGlldGYtcm91dGluZy0yDQo+ID4+Pj4gSG9wZWZ1bGx5LCBpbiB0aGUgcm91dGluZyBj
YXNlLCBpdCdzIG1haW5seSB0aGUgSUVURi4NCj4gPj4+PiBJJ20gZ2xhZCB0aGF0IHdlIGRpZG4n
dCBjaGFuZ2UgdGhlIGlldGYtaW50ZXJmYWNlcyB0bw0KPiA+Pj4+IGlldGYtaW50ZXJmYWNlcy0y
LCB3ZSB3b3VsZCBoYXZlIHRvIGRlYWwgd2l0aCBjcm9zcw0KPiA+Pj4+IFNETy9jb25zb3J0aWEv
b3BlbnNvdXJjZSBwcm9qZWN0IGlzc3Vlcw0KPiA+Pj4+IE5vdGU6DQo+ID4+Pj4NCj4gPj4+PiDD
giDDgiDDgiAgd2UncmUgaW4gYSB0cmFuc2l0aW9uIHBoYXNlIHRvZGF5LCB3aGlsZSB3ZSBpbXBs
ZW1lbnQgdGhlDQo+ID4+Pj4gw4Igw4Igw4IgIHNvb24tdG8tYmUtcHVibGlzaGVkIGRyYWZ0LWNs
YWNsYS1uZXRtb2QtbW9kZWwtY2F0YWxvZy0wMg0KPiA+Pj4+IMOCIMOCIMOCICBCZWNhdXNlIG9m
IHRoaXMsIHRoZSBTRE8vY29uc29ydGlhL29wZW5zb3VyY2UgZGVwZW5kZW50IFlBTkcNCj4gPj4+
PiBtb2R1bGVzDQo+ID4+Pj4gw4Igw4Igw4IgIHdpbGwgb25seSBhcHBlYXIgaW4gdGhlIEltcGFj
dCBBbmFseXNpcyB0b21vcnJvdyBhdA0KPiA+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LnlhbmdjYXRhbG9nLm9yZ195YW5nLTJEc2Vh
cmNoX2ltcGFjdC01RmFuYWx5c2lzLnBocC0zRm1vZHVsZXMtNUItNUQtM0RpZXRmLTJEaW50ZXJm
YWNlcy0yNnJlY3Vyc2UtM0QwLTI2cmZjcy0zRDEtMjZzaG93LTVGc3VibS0zRDEtMjZzaG93LTVG
ZGlyLTNEZGVwZW5kZW50cyZkPUR3SUZBdyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1u
ZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk
Y1pvJm09a1hfUF92YWlPa1dOb2hLS0wwSFA4OFUtZ2xYc21obHlqZ1d3N3J4ZzFidyZzPVY3dHJw
R0h1dlJTT3dtYjBwcEw3R296dHNLU1VKSTN5V0otanhlU0hUWHMmZT0NCj4gPj4+PiDDgiDDgiDD
giAgSW4gdGhlIG1lYW4gdGltZSwgeW91IGNhbiBzZWUgYWxsIHRoZXNlIGRlcGVuZGVudCBtb2R1
bGVzDQo+ID4+Pj4gw4Igw4Igw4IgIEV4Og0KPiA+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LnlhbmdjYXRhbG9nLm9yZ195YW5nLTJE
c2VhcmNoX21vZHVsZS01RmRldGFpbHMucGhwLTNGbW9kdWxlLTNEaWV0Zi0yRGludGVyZmFjZXMm
ZD1Ed0lGQXcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9
OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWtYX1BfdmFpT2tX
Tm9oS0tMMEhQODhVLWdsWHNtaGx5amdXdzdyeGcxYncmcz1ldVJuMm4taThuUVpYNVktWmllUkVz
bHdjY3Y3REpCUzZMOGpsTkJBM1RNJmU9DQo+ID4+Pj4gw4Igw4Igw4Igw4IgIMOCIMOCIMOCICDD
giDDgiDDgiAgPT4gY2xpY2sgb24gImRlcGVuZGVudHMiDQo+ID4+Pj4gw4Igw4Igw4IgIFRob3Nl
IGRlcGVuZGVudCBtb2R1bGVzIGlzIGEgbmV3IGZlYXR1cmUgb2YNCj4gPj4+PiDDgiDDgiDDgiAg
ZHJhZnQtY2xhY2xhLW5ldG1vZC1tb2RlbC1jYXRhbG9nLTAyDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+
Pj4+IEknbSB3b25kZXJpbmcgaWYgdGhpcyBOTURBIHRyYW5zaXRpb24gaHVyZGxlIGRvZXNuJ3Qg
bWFrZSBhIGdvb2QNCj4gPj4+PiBqdXN0aWZpY2F0aW9uIHRvIGtlZXAgdGhlIHNhbWUgbW9kdWxl
IG5hbWUhDQo+ID4+Pj4gV2UgY291bGQgZGViYXRlIHdoZXRoZXIgaWV0Zi1yb3V0aW5nIGlzIGlt
cGxlbWVudGVkIG9yIG5vdCwgYnV0IHRoZQ0KPiA+Pj4+IHBvaW50IGlzIG1vb3Q6IHdlIGRvbid0
IGtub3cgd2hhdCB3ZSBkb24ndCBrbm93Lg0KPiA+Pj4gQWdyZWVkLsOCICBJIHRoaW5rIHRoZXJl
IGFyZSBubyByZWFsIHJlYXNvbnMgZm9yIGtlZXBpbmcgdGhlIG1vZHVsZSBuYW1lDQo+ID4+PiBh
bmQgZGVwcmVjYXRlIHRoZSBvbGQgZGVmaW50aWlvbnMuw4IgIFllcywgaXQgYWRkcyBzb21lIG5v
aXNlIHRvIHRoZQ0KPiA+Pj4gbW9kdWxlIGJ1dCB0aGUgZmFjdCBpcyB0aGF0IHdlIGRvIGRlcHJl
Y2F0ZSBhbGwgdGhlc2UgZGVmaW50aW9ucywgYW5kDQo+ID4+PiBJIHRoaW5rIHdlIHNob3VsZCBu
b3QgaGlkZSB0aGF0Lg0KPiA+PiBUaGlzIGlzIGFsc28gbXkgcHJlZmVycmVkIG9wdGlvbi4NCj4g
Pj4NCj4gPj4gSSB3b3VsZCBsaWtlIHRvIGp1c3QgZGVwcmVjYXRlIHRoZXNlIG5vZGVzIG5vdywg
YW5kIHRoZW4gKGZvciB0aGUNCj4gPj4gcm91dGluZyBtb2R1bGUgdGhhdCBpcyB1bmxpa2VseSB0
byBoYXZlIGJlZW4gd2lkZWx5IGltcGxlbWVudCkgdXBkYXRlDQo+ID4+IGl0IGFnYWluIGluIGEg
MS0yIHllYXJzIHRpbWUgdG8gcmVtb3ZlIHRoZSBkZXByZWNhdGVkIG5vZGVzICh3ZSBjYW4NCj4g
Pj4gd2FybiBub3cgdGhhdCB0aGV5IHdpbGwgZ2V0IHJlbW92ZWQpLg0KPiA+IEFjY29yZGluZyB0
byBBY2VlLCB0aGVyZSBpcyBvbmUgaWV0Zi1yb3V0aW5nIGltcGxlbWVudGF0aW9uIChiYXNlZCBv
bg0KPiA+IGFuIG9sZCBkcmFmdCB2ZXJzaW9uKS4gSWYgdGhlIHBvaW50IGlzIHRoYXQgd2UgZG9u
J3Qgd2FudCBpZXRmLXJvdXRpbmcNCj4gPiBpbXBsZW1lbnRhdGlvbnMgdG8gaW1wbGVtZW50ICJk
ZXByZWNhdGVkIiBsZWF2ZXMsIGNhbiB3ZSAib2Jzb2xldGUiDQo+ID4gdGhlbSBub3cuDQo+ID4g
UkZDIDc5NTA6DQo+ID4NCj4gPiAgICAgNy4yMS4yLiBUaGUgInN0YXR1cyIgU3RhdGVtZW50DQo+
ID4NCj4gPiAgICAgICAgIFRoZSAic3RhdHVzIiBzdGF0ZW1lbnQgdGFrZXMgYXMgYW4gYXJndW1l
bnQgb25lIG9mIHRoZSBzdHJpbmdzDQo+ID4gICAgICAgICAiY3VycmVudCIsICJkZXByZWNhdGVk
Iiwgb3IgIm9ic29sZXRlIi4NCj4gPg0KPiA+ICAgICAgICAgbyAgImN1cnJlbnQiIG1lYW5zIHRo
YXQgdGhlIGRlZmluaXRpb24gaXMgY3VycmVudCBhbmQgdmFsaWQuDQo+ID4NCj4gPiAgICAgICAg
IG8gICJkZXByZWNhdGVkIiBpbmRpY2F0ZXMgYW4gb2Jzb2xldGUgZGVmaW5pdGlvbiwgYnV0IGl0
IHBlcm1pdHMNCj4gPiAgICAgICAgICAgIG5ldy9jb250aW51ZWQgaW1wbGVtZW50YXRpb24gaW4g
b3JkZXIgdG8gZm9zdGVyIGludGVyb3BlcmFiaWxpdHkNCj4gPiAgICAgICAgICAgIHdpdGggb2xk
ZXIvZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLg0KPiA+DQo+ID4gICAgICAgICBvICJvYnNvbGV0
ZSIgbWVhbnMgdGhhdCB0aGUgZGVmaW5pdGlvbiBpcyBvYnNvbGV0ZSBhbmQgU0hPVUxEIE5PVCBi
ZQ0KPiA+ICAgICAgICAgICAgaW1wbGVtZW50ZWQgYW5kL29yIGNhbiBiZSByZW1vdmVkIGZyb20g
aW1wbGVtZW50YXRpb25zLg0KPiA+DQo+ID4gQWR2YW50YWdlczoNCj4gPiDDgiDDgiDDgiAgLSB3
ZSBrZWVwIHRoZSBzYW1lIGlldGYtcm91dGluZyBZQU5HIG1vZHVsZSBuYW1lcw0KPiA+IMOCIMOC
IMOCICAtIG5ldyBpbXBsZW1lbnRhdGlvbnMgZG9uJ3QgaW1wbGVtZW50IHRoZSAib2Jzb2xldGUi
IHBhcnRzLg0KPiANCj4gRm9yIDgwMjJiaXMsIEkgd291bGQgYWxzbyBzdXBwb3J0IGtlZXBpbmcg
dGhlIGV4aXN0aW5nIG1vZHVsZSBuYW1lLA0KPiBhbmQgbW92aW5nIHRoZSBleGlzdGluZyBzdGF0
ZSBsZWF2ZXMgZGlyZWN0bHkgdG8gb2Jzb2xldGUuw4IgIFRoaXMgaXMNCj4gd2l0aCB0aGUganVz
dGlmaWNhdGlvbiB0aGF0IHRoaXMgZHJhZnQgaGFzIG9ubHkgcmVjZW50bHkgYmVlbg0KPiBwdWJs
aXNoZWQsIGFuZCB3ZSBkbyBub3QgZXhwZWN0IHRoZXJlIHRvIGJlIG1hbnkgaW1wbGVtZW50YXRp
b25zIHlldC4NCg0KVGhpcyBpcyBmaW5lIHdpdGggbWUgYXMgd2VsbC4NCg0KPiBGb3IgUkZDIDcy
MjMsIEkgdGhpbmsgdGhhdCB0aGUgc3RhdGUgbGVhdmVzIHNob3VsZCBtb3ZlIHRvIGRlcHJlY2F0
ZWQNCj4gdGhlbiBvYnNvbGV0ZSBpbiBhIGxhdGVyIHJldmlzaW9uLCBiZWNhdXNlIHRoZSBtb2Rl
bCBpcyBtdWNoIG9sZGVyIGFuZA0KPiBoZW5jZSBsaWtlbHkgdG8gYmUgbXVjaCBtb3JlIGVzdGFi
bGlzaGVkLg0KDQpBZ3JlZWQuDQoNCg0KL21hcnRpbg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGll
dGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt
M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUZBdyZjPUhBa1l1
aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQ
b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09a1hfUF92YWlPa1dOb2hLS0wwSFA4OFUtZ2xY
c21obHlqZ1d3N3J4ZzFidyZzPXoxRlhqRGNXQ3hzRFRidGNMQUFUYUQ0dmIzdEpITDVHaFo4dWZE
bFpMSXcmZT0NCg0KDQo=


From nobody Wed Oct 11 11:43:38 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1FF1321BB; Wed, 11 Oct 2017 11:43:35 -0700 (PDT)
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 D3c99pXkQPZl; Wed, 11 Oct 2017 11:43:31 -0700 (PDT)
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 A79D4126B6D; Wed, 11 Oct 2017 11:43:30 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id n69so3115321lfn.2; Wed, 11 Oct 2017 11:43:30 -0700 (PDT)
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 :thread-index:content-language; bh=DXQuH2GvGEvfWesAoKhn3+aDbdxx5SjmdtA3GQUOjJU=; b=ZzORWY/7YXf+IWeQZFhLs6yYHzAJWqwg63393KHea5RVDDQiikSQArTHzUbvgTOcrC l2c289gMkmgmWk4YO/2XLJC1VxivA8sOcFbg6o3Mt8KTLxfjTk+VUQuc1vo0lidItuIH 5+NiI+K/W2DYUKrJ0pIonpoAXckVkIxdACm4L3j3mts9U73YUlz1G5UfIIX0W43GvNXk iwmMHSkSFhCY/yT5yoAfwftkhhV/2d+070HpoYeg4qVUI1LdPyord5mEaS3U3pH6zfSt OMz2JXCs6ns5gMz6YBsTStr0LsxZN24chtX8h+X0zslydRavGAziHsT4Ts+bVbezrKWf 94VQ==
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:thread-index:content-language; bh=DXQuH2GvGEvfWesAoKhn3+aDbdxx5SjmdtA3GQUOjJU=; b=EyPfONhbtGxC5tNQU+JLxH5bOKSyWdL8jgIMVxXjTGKRTd0zILy/RQoT45dTThoG0U ZXVL8cya9C/K9pYB6U1cfnA6YmLV5kQzft3A+ftrdIlYy9KJJK54SHX+2p38jgX4/zvg kWI0QriB8lJ1qX+jFRpLg2wSgSAK5gyVcJCYHb2WjbrBUVO4NveuGYh6nvsojhVXBzbo O7KGhS5HbOEAxG9mwi4/8vADB21feJlzCdC4PDwYJ94VxUJ7f9QYIn/JxoO2eJupUnf5 MaY7NC78oV0aqTJA4tsVkM45ezk9377NTIXBRxR1aM9+dNoR4ekW8Egq+ZCImhL85GhJ bAmA==
X-Gm-Message-State: AMCzsaVkKGwSfkr6SGcV38NCtTZQHrCvq8xiyADmWmvMnQPjjOhIwNyr ktYc/n64dr4LgvSSxSdFxjI=
X-Google-Smtp-Source: AOwi7QBvhWURS5xe0sCzJd81NJounZ4Olp/x7yk5Kh5aufBswq/4A3nFnw9A2tK36BLxOW4Z1OwuRg==
X-Received: by 10.46.74.25 with SMTP id x25mr225444lja.83.1507747408337; Wed, 11 Oct 2017 11:43:28 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id c74sm2396082lfe.49.2017.10.11.11.43.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 11:43:27 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Robert Wilton'" , "'t.petch'" ,  "'Igor Bryskin'" , , 
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>   <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com> <42819484-f9b5-4f06-dd58-23d9bc8c1ecc@cisco.com>  <02aa01d34275$192f1840$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Date: Wed, 11 Oct 2017 14:43:23 -0400
Message-ID: <06f901d342c0$d368ef60$7a3ace20$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06FA_01D3429F.4C5E0620"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJCNZXzN3NA433K0RCvmhmflzyYmgKC1LefAcsn3JUB/odxSQE23kEDAuNnxDoDMQ9GzwGJDtqqAhsXenABrAz8bQJe5yd1AUnHAMOhTIwD4A==
Content-Language: en-us
Archived-At: 
Subject: Re: [netmod] [Netconf]   Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Oct 2017 18:43:36 -0000

This is a multipart message in MIME format.

------=_NextPart_000_06FA_01D3429F.4C5E0620
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Rob,

=20

Thanks for the proposal. I think that the subtree does help, to a =
certain extend. The approach is worth mentioning to the implementers, =
though the remaining XPath is still complicated and could be worse for a =
more complex model. The good thing about the approach is that this is =
what we already have today. I agree with Tom on that NETCONF should have =
a better solution, but that may require protocol changes and need to =
cover more generic cases as Per described.

=20

Thanks,

- Xufeng

=20

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert =
Wilton
Sent: Wednesday, October 11, 2017 6:49 AM
To: t.petch ; Igor Bryskin =
; netconf@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by =
leafref

=20

I've also been thinking about this problem a bit more :-)

The XPath solution works, but the expression isn't particularly nice to =
write, and I suspect that implementations may struggle to implement it =
efficiently (if they support XPath filtering at all).

A nicer solution here might be to allow the XPath filters to be combined =
with a subtree filter along the lines of a more advanced type of =
"Attribute Match Expression" sec 6.2.2 of rfc6241.

E.g. rather than this XPath filter:

/te:te/te:tunnels/te:tunnel[te:name=3D'foo'] |
/te:te/te:connections/te:connection[te:name=3D/te:te/te:tunnels/te:tunnel=
[te:name=3D'foo']/te:connections/te:connection/te:name]
=20

Here is example of what a subtree filter combined with an XPath filter =
could potentially look like (which of course isn't valid NETCONF/YANG =
today):


  
    
    
      
    
  



Any opinions on whether this would be beneficial or is this just =
reinventing the wheel?

Thanks,
Rob



On 11/10/2017 10:41, t.petch wrote:

Igor
=20
Thinking laterally, this is a problem that DNS encountered a few decades
ago and solved, by allowing the server to include additional information
not specifically requested that the server can see is going to be needed
for the next step, so if the client asks only about a CNAME, then the
server can provide the relevant IP address as well.
=20
I suspect that the current rules for Netconf do not allow the server to
send anything not explicitly requested, which is a shame (IMO).
=20
The DNS approach works very well, in fact I do not think we would
survive without it.
=20
Tom Petch
=20
----- Original Message -----
From: "Igor Bryskin"   =

Sent: Tuesday, October 10, 2017 2:35 PM
=20
Hi Rob,
=20
This helps a lot. What you wrote will work.
=20
The only difference is that if we would have the "joimt with" clause as
we proposed, the server would be able to tailor the te-tunnel
presentation to the client's requirements, e.g. substituting the
connection pointers with connection bodies, while, according to your
suggestion, the server will provide the te-tunnel body as is, and then
augment it with the cobbection information, thus, leaving
for the client to "shuffle " the received data. But I do agree, this
would be a minor inconvinience for the client, the important thing is
that the client will get all the data in one piece.
=20
Thanks a lot,
Igor
=20
c
=20
From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,netmod@ietf.org,netconf@ietf.org =
 ,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
=20
Hi Igor,
=20
On 09/10/2017 23:11, Igor Bryskin wrote:

Hi Per,
=20
This is a good news, but, please, help us out.
Consider, we have a node - "te-tunnel" - which among other attributes

has two key leafref lists:

1) each member of the 1st list points to a "connection" supporting the

te-tunnel. All connections supporting all te-tunnels are stored in a
single list of connections.

2) each member of the 2nd list points to a supporting "te-tunnel" -

the te-tunnel in question depends on. All te=3Dtunnels including the
te-tunnel in question, are stored in a single list of te-tunnels.

=20
The question: how the client can retrieve via a single request all

attributes of the te-tunnel in question along with all parameters of all
connections supporting the te-tunnel, but with just pointers to
supporting te-tunnels (so that the interested client can use the
pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):
=20
   /te/tunnels/tunnel[name=3D'foo'] |
=20
/te/connections/connection[name=3D/te/tunnels/tunnel[name=3D'foo']/connec=
tio
ns/connection/name]
=20
E.g. in English, this should equate to something like:
=20
Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name
matches one of the connections listed in tunnel foo.
=20

=20
Likewise, how the client can ask for full data of the te-tunnel and

all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like
this:
=20
   /te/tunnels/tunnel[name=3D'foo'] |
=20
/te/tunnels/tunnel[name=3D/te/tunnels/tunnel[name=3D'foo']/supporting-tun=
nel
s/supporting-tunnel/name]
=20
=20
I'm an XPath novice, so the expressions might be wrong.
=20
https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if
you can construct a simple XML instance tree of your data, you could
validate whether the XPath expression works.
=20
I hope that this is of some help,
Rob
=20
=20

=20
I really appreciate your help,
=20
Igor
=20
=20
-----Original Message-----
From: Per Hedeland [mailto:per@tail-f.com]
Sent: Monday, October 09, 2017 5:21 PM
To: Igor Bryskin
Cc: mbj@tail-f.com  ; xufeng.liu.ietf@gmail.com =
 ; netconf@ietf.org =
 ;

netmod@ietf.org =20

Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by

leafref

=20
Just to be clear: what we're suggesting is that you can use the
already-existing standard NETCONF XPath capability to achieve the

desired

result - see https://tools.ietf.org/html/rfc6241#section-8.9
=20
--Per
=20
On 2017-10-09 21:52, Igor Bryskin wrote:

I agree. For example, a leafref may point not to a singls entity, but

to a list of entities, and the client might want to expand all of them
into the joint get response.

=20
Igor
=20
*From:*Per Hedeland
*To:*Martin Bjorklund,
*Cc:*Igor

Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org =
 ,

*Date:*2017-10-09 15:12:22
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by

leafref

=20
On 2017-10-09 19:13, Martin Bjorklund wrote:

Igor Bryskin    =
wrote:

Hi Per,
=20
Basically, what we need is a way for a client to request something
like this:
=20
get  joint with 

... which is what Per's expression does!  Note that "|" in XPath

means

"union".
=20
But as Per explained, it only works in some cases (when the leafref
acts a "single pointer").

Well, that particular expression works only in that case - but since

it

is effectively the client that (perhaps based on the data model)

decides

what the leafref-leafs "mean" (in this case the single key of a

single

list), other cases can be handled the same way. E.g. multiple
leafref-to-key leafs that together give the keys of a multi-key list
just amounts to a slightly hairier XPath filter...
=20
--Per
=20

with a server interpreting the request as follows:
if a node pointed by XPath contains a pointer (e.g. key leafref)
matching one of the XPath from the "joint with" list, then the

server

must provide the entire body of the node pointed by the pointer,
otherwise, just the pointer (as it happens today, that is, when no
"joint with" list specified).
=20
We think that this would allow for the client to optimize the

number

of request-response iterations depending on application/use case.
=20
Regards,
Igor

=20
=20
/martin
=20
=20

=20
=20
=20
=20
=20
-----Original Message-----
From: Per Hedeland [mailto:per@tail-f.com]
Sent: Monday, October 09, 2017 12:06 PM
To: Xufeng Liu
Cc: Igor Bryskin; netconf@ietf.org  ; =
netmod@ietf.org =20
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref
=20
I understand your use case, but a leaf of type leafref does not in
general identify a single node in the data tree - the leafref path
could
be for a non-key leaf, and/or the path could traverse list nodes,
and/or
the "target" list could have multiple keys and thus multiple
leafref-leafs be required to identify a specific list entry.
=20
Thus it seems to me that your use case is not a reasonable basis

for a

new protocol operation. My XPath foo isn't very good either, but I

do

believe Robert's suggestion of using an XPath filter could be a way
forward. I *think* the filter expression would be something along

the

lines of
=20
   /te/tunnels/tunnel[name=3D'foo'] |
=20

/te/explicit-paths/explicit-path[name=3D/te/tunnels/tunnel[name=3D'foo']/=
pat
hs/path/explicit-path]

=20
--Per
=20
On 2017-10-09 15:42, Xufeng Liu wrote:

Hi Per,
=20
=20
=20
*From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
*Sent:* Sunday, October 8, 2017 7:04 PM
*To:* Igor Bryskin   =
; per@tail-f.com  ;
*xufeng.liu.ietf@gmail.com =20
*Cc:* netconf@ietf.org  ; netmod@ietf.org =
=20
*Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed

by

*leafref
=20
=20
=20
=20
Hi Joel,
=20
Thanks, I think I didnt explain our problem correctly.
=20
In our case we have a leafref pointing to a te tunnel name, which
happens to be a key to lookup the (axilary) tunnel.  We need a way

to

include the entire tunnel body (not just a name) into the get
response. This is to optimize the number of iterations between the
client and the server. As Xufeng put it something similar to SQL

join,

=20
Igor
=20
*From:*Igor Bryskin
=20
*To:*per@tail-f.com,xufeng.liu.ietf@gmail.com =
 ,
=20
*Cc:*netconf@ietf.org,netmod@ietf.org  ,
=20
*Date:*2017-10-08 17:36:47
=20
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref
=20
=20
=20
Hi Per,
=20
In a nutshell we would lika for a netconf client to have a way to
instruct the server on whether in response to the get request the
server needs to provide the entire body of a datastore node

pointed

to by a leafref or just a pointer to said node, so that the node's
body could be retrieved by a subsequent separate request. This is
requested by implementors who want to optimise rhe number of
interactions between a client and its server.
=20
Cheers,
Igor
=20
*From:*Per Hedeland
=20
*To:*Xufeng Liu,
=20
*Cc:*netconf@ietf.org,'NetMod WG',
=20
*Date:*2017-10-08 14:01:27
=20
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
*leafref
=20
=20
=20
On 2017-10-06 23:11, Xufeng Liu wrote:

During the design team discussion for TE and MPLS YANG modeling,

we

have received a request from implementers: How to minimize the

number

of NETCONF/RESTCONF RPCs to improve operation efficiency?
Especially for the case when the operator or client software

needs to

retrieve the object contents pointed by a leafref.
=20
For example, given the following simplified TE tunnel model,
=20
+--rw te
=20
       +--rw explicit-paths
=20
       |  +--rw explicit-path* [name]
=20
       |     +--rw name                      string
=20
       |        +--rw explicit-route-object* [index]
=20
       |           +--rw index                   uint32
=20
       |           +--rw explicit-route-usage?   identityref
=20
       +--rw tunnels
=20
       |  +--rw tunnel* [name]
=20
       |  |  +--rw name                   string
=20
       |  |  +--rw paths
=20
       |  |  |  +--rw path* [name]
=20
|  |  |     +--rw explicit-path?  ->
|  |  |     ../../../../../explicit-paths/explicit-path/name
=20
when the client tries to retrieve a tunnels information based on

the

tunnel name, the =1Cget operation returns a list of leafrefs

pointing

to the paths of the tunnel.

Sorry, I'm afraid I don't follow. Can you explain exactly what

your

"get" request is (protocol and payload), and where the "list of
leafref's" (whatever that may be) occurs in the reply?
=20
*/[Xufeng] The =1Cget operation is the NETCONF/RESTCON 

protocol

*operation, or the  operation described in
*https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the

GET

*operations
on {+restconf}/ds/ described in
https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
=20
*/ /*
=20
*/We have a list of leafref values because in this example model,

each

*tunnel contains a list of paths, each of them contains a leafref.

The

*=1Cget returns a value for each instance of such a leafref,
which (as a string value) will be used as a constraint (foreign

key)

to retrieve the instance of an explicit-path in the model above./*
=20
=20
=20
JFYI, in case there is some fundamental misunderstanding here: a

leaf

of
type leafref has a single value - *one* of those that satisfy the
leafref
constraint, in case there are multiple "candidates".
=20
--Per
=20

The client needs to issue at
least one more =1Cget operation to retrieve the path information

about

the given tunnel. The request is to combine these two operations

into

one.
=20
In the RDBMS SQL world, =1Cjoin can be used when SQL =1Cselect is
performed, but NETCONF/YANG currently does not have this

capability.

=20
Wed like to ask whether such a request is considered reasonable.
=20
If the request is reasonable, the next question is how to
proceed. This seems to be a protocol issue rather than YANG

modeling

issue. Is it acceptable to add a new operation to achieve such a
 operation with expanded leafrefs?
=20
Comments and suggestions are appreciated.
=20
Thanks,
=20
- Xufeng
=20
=20
=20
_______________________________________________
netmod mailing list
netmod@ietf.org     =

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

_______________________________________________
Netconf mailing list
Netconf@ietf.org     =

https://www.ietf.org/mailman/listinfo/netconf
=20

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

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

=20
=20
=20
=20
------------------------------------------------------------------------
--------
=20
=20

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

=20
.
=20

=20


------=_NextPart_000_06FA_01D3429F.4C5E0620
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hi =
Rob,
 
Thanks for the =
proposal. I think that the subtree does help, to a certain extend. The =
approach is worth mentioning to the implementers, though the remaining =
XPath is still complicated and could be worse for a more complex model. =
The good thing about the approach is that this is what we already have =
today. I agree with Tom on that NETCONF should have a better solution, =
but that may require protocol changes and need to cover more generic =
cases as Per described.
 
Thanks,
- =
Xufeng
 
From: Netconf [mailto:netconf-bounces@ietf.org] =
On Behalf Of Robert Wilton
Sent: Wednesday, October 11, =
2017 6:49 AM
To: t.petch <ietfc@btconnect.com>; Igor =
Bryskin <Igor.Bryskin@huawei.com>; netconf@ietf.org; =
netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving =
Information Pointed by leafref
 
I've also been thinking about =
this problem a bit more :-)
The XPath solution works, =
but the expression isn't particularly nice to write, and I suspect that =
implementations may struggle to implement it efficiently (if they =
support XPath filtering at all).
A nicer solution here =
might be to allow the XPath filters to be combined with a subtree filter =
along the lines of a more advanced type of "Attribute Match =
Expression" sec 6.2.2 of rfc6241.
E.g. rather than =
this XPath =
filter:
/te:te/te:tunnels/te:tunnel[te:name=3D'foo'] =
|
/te:te/te:connections/te:connection[te:name=3D/te:=
te/te:tunnels/te:tunnel[te:name=3D'foo']/te:connections/te:connection/te:=
name]
 
Here is example of =
what a subtree filter combined with an XPath filter could potentially =
look like (which of course isn't valid NETCONF/YANG =
today):
<filter =
type=3D"subtree-xpath">
=C2=A0 =
<te:te =
xmlns:te=3D"...">
=C2=A0=C2=A0=C2=A0 =
<te:tunnels =
te:name=3D"foo"/>
=C2=A0=C2=A0=C2=A0 =
<te:connections>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 <filter type=3D"xpath" select=3D"te:name =3D =
../te:tunnels/te:tunnel[te:name=3D'foo']/te:connections/te:connection/te:=
name)"/>
=C2=A0=C2=A0=C2=A0 =
</te:connections>
  =
</te:te>
</filter>

Any opinions on =
whether this would be beneficial or is this just reinventing the =
wheel?

Thanks,
Rob

On 11/10/2017 10:41, t.petch =
wrote:
Igor
=

 
Thinking laterally, this is a problem =
that DNS encountered a few decades
ago and solved, =
by allowing the server to include additional =
information
not specifically requested that the =
server can see is going to be needed
for the next =
step, so if the client asks only about a CNAME, then =
the
server can provide the relevant IP address as =
well.
 
I suspect that =
the current rules for Netconf do not allow the server =
to
send anything not explicitly requested, which is =
a shame (IMO).
 
The DNS =
approach works very well, in fact I do not think we =
would
survive without =
it.
 
Tom =
Petch
 
----- Original =
Message -----
From: "Igor Bryskin" <Igor.Bryskin@huawei.com>
Sent: Tuesday, October 10, 2017 2:35 =
PM
 
Hi =
Rob,
 
This helps a lot. =
What you wrote will =
work.
 
The only =
difference is that if we would have the "joimt with" clause =
as
we proposed, the server would be able to tailor =
the te-tunnel
presentation to the client's =
requirements, e.g. substituting the
connection =
pointers with connection bodies, while, according to =
your
suggestion, the server will provide the =
te-tunnel body as is, and then
augment it with the =
cobbection information, thus, leaving
for the =
client to "shuffle " the received data. But I do agree, =
this
would be a minor inconvinience for the client, =
the important thing is
that the client will get all =
the data in one =
piece.
 
Thanks a =
lot,
Igor
 
c
 
From:Robert =
Wilton
To:Igor Bryskin,
Cc:Per =
Hedeland,netmod@ietf.org,netconf@=
ietf.org,
Date:2017-10-10 =
06:41:04
Subject:Re: [netmod] [Netconf] Retrieving =
Information Pointed by =
leafref
 
Hi =
Igor,
 
On 09/10/2017 =
23:11, Igor Bryskin wrote:
Hi =
Per,
 
This is a good =
news, but, please, help us out.
Consider, we have a =
node - "te-tunnel" - which among other =
attributes
has two key leafref =
lists:
1) each member of =
the 1st list points to a "connection" supporting =
the
te-tunnel. All connections =
supporting all te-tunnels are stored in a
single =
list of connections.
2) each member of =
the 2nd list points to a supporting "te-tunnel" =
-
the te-tunnel in question depends =
on. All te=3Dtunnels including the
te-tunnel in =
question, are stored in a single list of =
te-tunnels.
 
The question: how the client can retrieve via a single request =
all
attributes of the te-tunnel in =
question along with all parameters of =
all
connections supporting the te-tunnel, but with =
just pointers to
supporting te-tunnels (so that the =
interested client can use the
pointers to retrieve =
full data via subsequent separate requests) ?
I =
think that it might be something like this (for tunnel name =
foo):
 
=C2=A0=C2=A0 =
/te/tunnels/tunnel[name=3D'foo'] =
|
 
/te/connections/connec=
tion[name=3D/te/tunnels/tunnel[name=3D'foo']/connectio
ns/connection/name]
 
E=
.g. in English, this should equate to something =
like:
 
Return all =
information for tunnel foo AND ALSO
Return all =
information for all connections where the connection =
name
matches one of the connections listed in =
tunnel foo.
 
 
Likewise, how the client can ask for full data of the te-tunnel =
and
all supporting te-tunnels and just =
pointers for supporting connections?
If my xpath =
above is right, then this would be something roughly =
like
this:
 
=C2=A0=C2=A0 /te/tunnels/tunnel[name=3D'foo'] =
|
 
/te/tunnels/tunnel[nam=
e=3D/te/tunnels/tunnel[name=3D'foo']/supporting-tunnel
s/supporting-tunnel/name]
 
=

 
I'm an XPath novice, so the expressions =
might be wrong.
 
https://www.free=
formatter.com/xpath-tester.html might be useful. E.g. =
if
you can construct a simple XML instance tree of =
your data, you could
validate whether the XPath =
expression works.
 
I =
hope that this is of some =
help,
Rob
 
 
 
I really appreciate your =
help,
 
Igor
 
 
-----Orig=
inal Message-----
From: Per Hedeland [mailto:per@tail-f.com]
Sent: Monday, October 09, 2017 5:21 PM
To: =
Igor Bryskin
Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; =
netconf@ietf.org;
netmod@ietf.org
Subject: Re: =
[Netconf] [netmod] Retrieving Information Pointed =
by
leafref
 
Just to be clear: what we're suggesting is that you can use =
the
already-existing standard NETCONF XPath =
capability to achieve =
the
desired
result - see https://tools.ie=
tf.org/html/rfc6241#section-8.9
 
--Per
 
On =
2017-10-09 21:52, Igor Bryskin wrote:
I agree. For =
example, a leafref may point not to a singls entity, =
but
to a list of =
entities, and the client might want to expand all of =
them
into the joint get =
response.
 
Igor
 
*From:*Per =
Hedeland
*To:*Martin =
Bjorklund,
*Cc:*Igor
Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,
*Date:*2017-10-09 =
15:12:22
*Subject:*Re: [Netconf] [netmod] =
Retrieving Information Pointed =
by
leafref
 
On 2017-10-09 19:13, Martin Bjorklund =
wrote:
Igor Bryskin <Igor.Bryskin@huawei.com> wrote:
Hi =
Per,
 
Basically, what we =
need is a way for a client to request =
something
like =
this:
 
get <XPath> =
joint with <XPath1, XPath2, ..., =
XPathn>
... which is what Per's =
expression does!=C2=A0 Note that "|" in =
XPath
means
"union".
 
But as Per explained, it =
only works in some cases (when the leafref
acts a =
"single pointer").
Well, =
that particular expression works only in that case - but =
since
it
<=
blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>
is effectively the =
client that (perhaps based on the data =
model)
decides<=
/pre>
what the =
leafref-leafs "mean" (in this case the single key of =
a
single
<=
blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>
list), other cases =
can be handled the same way. E.g. =
multiple
leafref-to-key leafs that together give =
the keys of a multi-key list
just amounts to a =
slightly hairier XPath =
filter...
 
--Per
 
with a server =
interpreting the request as follows:
if a node =
pointed by XPath contains a pointer (e.g. key =
leafref)
matching one of the XPath from the =
"joint with" list, then =
the
<=
pre>server
must provide the =
entire body of the node pointed by the =
pointer,
otherwise, just the pointer (as it happens =
today, that is, when no
"joint with" list =
specified).
 
We think =
that this would allow for the client to optimize =
the
<=
pre>number
of request-response =
iterations depending on application/use =
case.
 
Regards,
Igor
 
 
/martin
 =
;
 
 
 
 
 =
;
 
-----Original =
Message-----
From: Per Hedeland [mailto:per@tail-f.com]
Sent: Monday, October 09, 2017 12:06 PM
To: =
Xufeng Liu
Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org
=
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed =
by
leafref
 
I understand your use case, but a leaf of type leafref does not =
in
general identify a single node in the data tree =
- the leafref path
could
be =
for a non-key leaf, and/or the path could traverse list =
nodes,
and/or
the =
"target" list could have multiple keys and thus =
multiple
leafref-leafs be required to identify a =
specific list =
entry.
 
Thus it seems to =
me that your use case is not a reasonable =
basis
for a
new protocol =
operation. My XPath foo isn't very good either, but =
I
do
believe Robert's =
suggestion of using an XPath filter could be a =
way
forward. I *think* the filter expression would =
be something =
along
the
lines =
of
 
=C2=A0=C2=A0 =
/te/tunnels/tunnel[name=3D'foo'] =
|
 
<=
/blockquote>
/te/explicit-paths/explicit-path[name=3D/te=
/tunnels/tunnel[name=3D'foo']/pat
hs/path/explicit-p=
ath]
 
--Per
 
On =
2017-10-09 15:42, Xufeng Liu wrote:
Hi =
Per,
 
 
 
*From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
*Sent:* Sunday, October 8, 2017 7:04 =
PM
*To:* Igor Bryskin <Igor.Bryskin@huawei.com>; per@tail-f.com;
<=
a =
href=3D"mailto:*xufeng.liu.ietf@gmail.com">*xufeng.liu.ietf@gmail.com=

*Cc:* netconf@ietf.org; netmod@ietf.org
=
*Subject:* Re: [Netconf] [netmod] Retrieving Information =
Pointed
by
*leafref
 
 
&nb=
sp;
 
Hi =
Joel,
 
Thanks, I think I =
didnt explain our problem =
correctly.
 
In our case =
we have a leafref pointing to a te tunnel name, =
which
happens to be a key to lookup the (axilary) =
tunnel.=C2=A0 We need a =
way
<=
/blockquote>
to
include the entire =
tunnel body (not just a name) into the =
get
response. This is to optimize the number of =
iterations between the
client and the server. As =
Xufeng put it something similar to =
SQL
<=
/blockquote>
join,
 
Igor
 
*From:*Igor =
Bryskin
 
*To:*per@tail-f.=
com,xufeng.liu.ietf@gmail.com,<=
o:p>
 
*Cc:*netconf@ietf.org,netmod@ietf.org,
 
*Date:*2017-10-08 =
17:36:47
 
*Subject:*Re: =
[Netconf] [netmod] Retrieving Information Pointed =
by
*leafref
 
 
 
Hi =
Per,
 
In a nutshell we =
would lika for a netconf client to have a way =
to
instruct the server on whether in response to =
the get request the
server needs to provide the =
entire body of a datastore =
node
=

pointed
to by a leafref or =
just a pointer to said node, so that the =
node's
body could be retrieved by a subsequent =
separate request. This is
requested by implementors =
who want to optimise rhe number of
interactions =
between a client and its =
server.
 
Cheers,
Igor
 
*From:=
*Per =
Hedeland
 
*To:*Xufeng =
Liu,
 
*Cc:*netconf@ietf.o=
rg,'NetMod =
WG',
 
*Date:*2017-10-08 =
14:01:27
 
*Subject:*Re: =
[Netconf] [netmod] Retrieving Information Pointed =
by
*leafref
 
 
 
On =
2017-10-06 23:11, Xufeng Liu wrote:
During the design =
team discussion for TE and MPLS YANG =
modeling,
we
have received a =
request from implementers: How to minimize =
the
<=
/blockquote>
number
of NETCONF/RESTCONF =
RPCs to improve operation efficiency?
Especially =
for the case when the operator or client =
software
needs to
retrieve the object =
contents pointed by a =
leafref.
 
For example, =
given the following simplified TE tunnel =
model,
 
+--rw =
te
 
=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0+--rw =
explicit-paths
 
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw explicit-path* =
[name]
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--rw =
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 =
string
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw =
explicit-route-object* =
[index]
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw =
index=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
uint32
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw =
explicit-route-usage?=C2=A0=C2=A0 =
identityref
 
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--rw =
tunnels
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw tunnel* =
[name]
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--rw =
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 =
string
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--rw =
paths
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--rw path* =
[name]
 
|=C2=A0 |=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0 +--rw explicit-path?=C2=A0 =
->
|=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 =
../../../../../explicit-paths/explicit-path/name
 
when the client tries to retrieve a tunnels =
information based =
on
the
tunnel name, the =
get operation returns a list of =
leafrefs
pointing
to the paths of the =
tunnel.
Sorry, I'm afraid I don't =
follow. Can you explain exactly =
what
=

your
"get" =
request is (protocol and payload), and where the "list =
of
leafref's" (whatever that may be) occurs in =
the reply?
 
*/[Xufeng] =
The get operation is the NETCONF/RESTCON =
<get>
protocol
*operation, or the =
<get-data> operation described in
*https://t=
ools.ietf.org/html/draft-dsdt-nmda-netconf-01 and =
the
<=
/blockquote>
GET
*operations
on {+restconf}/ds/<datastore> described =
in
https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*=

 
*/ =
/*
 
*/We have a list of =
leafref values because in this example =
model,
each
*tunnel contains a =
list of paths, each of them contains a =
leafref.
The
*get returns a =
value for each instance of such a leafref,
which =
(as a string value) will be used as a constraint =
(foreign
key)
to retrieve the =
instance of an explicit-path in the model =
above./*
 
 
 
JFYI, in case there is some =
fundamental misunderstanding here: =
a
leaf
of
type leafref has a single value - *one* of those that satisfy =
the
leafref
constraint, in =
case there are multiple =
"candidates".
 
=
--Per
 
The client needs to =
issue at
least one more get operation to =
retrieve the path =
information
about
the given tunnel. =
The request is to combine these two =
operations
into
one.
=

 
In the RDBMS SQL world, join can =
be used when SQL select is
performed, but =
NETCONF/YANG currently does not have =
this
=

capability.
 
Wed like to ask whether such a request is considered =
reasonable.
 
If the =
request is reasonable, the next question is how =
to
proceed. This seems to be a protocol issue =
rather than =
YANG
=

modeling
issue. Is it =
acceptable to add a new operation to achieve such =
a
<get-data> operation with expanded =
leafrefs?
 
Comments and =
suggestions are =
appreciated.
 
Thanks,
 
- =
Xufeng
 
 =

 
__________________________________=
_____________
netmod mailing =
list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.or=
g/mailman/listinfo/netmod
 
_______________________________________________
Netconf mailing list
Netconf@ietf.org <mailto:Netconf@ietf.org>=

https://www.ietf.o=
rg/mailman/listinfo/netconf
 
_______________________________________________=

Netconf mailing list
Netconf@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/netconf
 
__________________________=
_____________________
netmod mailing =
list
netmod@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/netmod
.
 
 
 
 
 
-----------------------------------------------------------------=
-------
--------
 
 
_____________________=
__________________________
netmod mailing =
list
netmod@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/netmod
 
 
.
 
 

------=_NextPart_000_06FA_01D3429F.4C5E0620--


From nobody Thu Oct 12 04:33:20 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE36A133229 for ; Thu, 12 Oct 2017 04:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level: 
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SawyYOXbC_-u for ; Thu, 12 Oct 2017 04:33:11 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 140AC133221 for ; Thu, 12 Oct 2017 04:33:11 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id C9E8A1E07B4 for ; Thu, 12 Oct 2017 05:33:10 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id LbZ61w00j2SSUrH01bZ9QP; Thu, 12 Oct 2017 05:33:10 -0600
X-Authority-Analysis: v=2.2 cv=H76r+6Qi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=02M-m0pO-4AA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=AUd_NHdVAAAA:8 a=2HyfR_PSAAAA:8 a=uX8G0ybSAAAA:8 a=48vgC7mUAAAA:8 a=x80VczMnsuCSaJI8uN4A:9 a=9yr8KVdBzTrDuJX2:21 a=LlXhZ-qZHYRjd5_5:21 a=QEXdDO2ut3YA:10 a=EbTClS0bprYA:10 a=wU2YTnxGAAAA:8 a=wcU5tIeItnPeHyisM4EA:9 a=FZQf-a6q_S_zZExv:21 a=Ph0Lj2lIrCK3zuwf:21 a=RrarZzIY30Te7Avt:21 a=_W_S_7VecoQA:10 a=0zSPmqmPh2d1CTP8umvz:22 a=uNZJWEtFmtcl922f2nWS:22 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nrSHdctO3EdZJRoIUghOkY9RuX6O+ivae2YcwpORnQk=; b=aDYAx/gI/s1Lxt4/vPfa8P1h0c t2LQO18fOO+mVU1Do1OQAhr4fzKD/PF89RAlC1fmrmz6T4MmwffIX5LJljfU2KxF/pUpAcZW2GqBT RRYHNJPPbNwakVl5bpbJ+zp22;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:55803 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e2bje-001fjR-Lw; Thu, 12 Oct 2017 05:33:06 -0600
From: Lou Berger 
To: Benoit Claise , NetMod WG 
CC: , , 
Date: Thu, 12 Oct 2017 07:33:04 -0400
Message-ID: <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com>
References:  <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------15f105bfd50421d27d3d5b7299"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1e2bje-001fjR-Lw
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:55803
X-Source-Auth: lberger@labn.net
X-Email-Count: 8
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] [RTG-DIR] handling module incompatibility => handling module transition
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Oct 2017 11:33:15 -0000

This is a multi-part message in MIME format.
------------15f105bfd50421d27d3d5b7299
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit

So circling back to the original question: what do we do about the non 
backward-compatible module being defined in rfc8049bis?

While being sympathetic to many of the comments made below as well as the 
"do over" concept, I find the comments about adhering to the rules of 7950 
compelling - which leads to renaming the module in the bis to ietf-l3vpn-svc-2.

It would be good to ensure that this is the consensus of the group before 
asking the authors make this change.

This change course doesn't solve the versioning issue discussed below, but 
this is not a new issue it's just the first time we'll actually executing 
the steps envisioned as part of the rules laid out in yang. My personal 
take away is that means that we should immediately start work on an 
extension defining along the lines of  ' obsolete|update' mentioned below.

Lou





On October 8, 2017 10:59:15 AM Benoit Claise  wrote:

> Dear all,
>
> Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049 is
> broken. The small problem is: trying to maintain backward compatibility.
> draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.
>
> Let me extend the scope of this email thread from "handling module
> incompatibility" to "handling module incompatibility and NMDA transition".
> As I mentioned in the past (see "semver.org comparison of two YANG
> modules" email in NETMOD), I believe the IETF will have to change its
> way of working in terms of backward compatibility. See also the email
> "ietf-routing or ietf-routing-2? module naming convention for NMDA
> transition. Re: [netmod] upcoming adoptions" in NETMOD.
>
> However, we will have to tackle this discussion one day or the other:
> - we need _an automatic way_ to make the link between the YANG module in
> RFC8049 and the YANG module in draft-wu-l3sm-rfc8049bis, or any non
> backward compatible YANG modules.
> - we need _an automatic way_ to make the link between the YANG module in
> RFC8022 and the YANG module in draft-acee-netmod-rfc8022bis, or any new
> YANG module names used for NMDA transition.
> Note: actually, we face two different problems. draft-wu-l3sm-rfc8049bis
> might be declared backward incompatible with RFC8049, while RFC8022bis
> is backward compatible with RFC8022. The RFC8022bis went for a new YANG
> module name ietf-routing-2 to avoid to document the -state tree (as
> deprecated), based on the argument that ietf-routing is not yet implemented.
>
> Which solutions do we have from here?
> #1. We keep the same module name and express that the YANG module in
> draft-wu-l3sm-rfc8049bis is not backward compatible with the RFC8049
> one. This is the openconfig way. See draft-clacla-netmod-model-catalog
> (and draft-openconfig-netmod-model-catalog before)
>
>        // extension statements
>           extension openconfig-version {
>             argument "semver" {
>               yin-element false;
>             }
>             description
>               "The OpenConfig version number for the module. This is
>               expressed as a semantic version number of the form:
>                 x.y.z
>                where:
>                 * x corresponds to the major version,
>                 * y corresponds to a minor version,
>                 * z corresponds to a patch version.
>               This version corresponds to the model file within which it is
>               defined, and does not cover the whole set of OpenConfig models.
>               Where several modules are used to build up a single block of
>               functionality, the same module version is specified across each
>               file that makes up the module.
>
>               A major version number of 0 indicates that this model is still
>               in development (whether within OpenConfig or with industry
>               partners), and is potentially subject to change.
>
>               Following a release of major version 1, all modules will
>               increment major revision number where backwards incompatible
>               changes to the model are made.
>
>               The minor version is changed when features are added to the
>               model that do not impact current clients use of the model.
>
>               The patch-level version is incremented when non-feature changes
>               (such as bugfixes or clarifications to human-readable
>               descriptions that do not impact model functionality) are made
>               that maintain backwards compatibility.
>
>               The version number is stored in the module meta-data.";
>           }
>
> Similarly, we always keep the same YANG module name in case of NMDA
> transition. So ietf-routing-2 should be changed back to ietf-routing.
> The email thread "[Rtg-dt-yang-arch] ietf-routing or ietf-routing-2?
> module naming convention for NMDA transition. Re: [netmod] upcoming
> adoptions" seems to go in that direction.
>
> #2. Or we have a different module name, let's say ietf-l3vpn-svc-2 or
> ietf-routing-2 but then, how do we make the link with the previous module?
> Then ...  What? We create extension that will link the
> draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? Same
> principle as #1, but just more complex.
> Or we have a new YANG keyword (this implies YANG 2.0)
>
>     file"ietf-l3vpn-svc@2017-09-14.yang"
>     module ietf-l3vpn-svc-2 {
>       yang-version 1.1;
>       namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
>       prefix l3vpn-svc;
>       *_obsolete|update _*ietf-l3vpn-svc@2017-01-2
>
> And whose responsibility is this to warn/push all authors of
> ietf-routing YANG modules to move to ietf-routing-2? (*)
>
> The following are non solution IMO:
> - Going from the draft-wu-l3sm-rfc8049bis YANG _module _to the
> draft-wu-l3sm-rfc8049bis _document _to lookup the IETF "obsolete" flag
> in order to understand that the RFC8049 YANG module is obsolete is not
> an automatic solution.
> - Using the yangcatalog.org might be a solution as we track the derived
> semantic, but this is just an offline trick. This is not what I call
> "automatic way"
> - Using the YANG module description field might be interesting, but
> again this is not an "automatic way":
>
>       description
>        "This YANG module defines a generic service configuration
>         model for Layer 3 VPNs. This model is common across all
>         vendor implementations. This obsoletes the RFC8049 YANG
>         module, ietf-l3vpn-svc@2017-01-2";
>       revision 2017-09-14 {
>        description
>         "First revision ofRFC8049 .";
>        reference
>         "RFC xxxx: YANG Data Model for L3VPN Service Delivery";
>
>
> In conclusion, I believe openconfig got this right and that solution #1
> is the solution to go ... while waiting for a new YANG keyword in YANG 2.0
>
> (*) If you want to change the module from ietf-routing to
> ietf-routing-2, then you should follow with all authors of dependent
> modules to make sure they transition to ietf-routing-2
> In the yangcatalog.org, because I needed the information as OPS AD, we
> created a small script to get that authors list for IETF drafts. For the
> ietf-routing, this produces the following
> {
>      "output": {
>          "author-email": [
> "draft-ietf-mpls-static-yang@ietf.org",
> "draft-ietf-mpls-base-yang@ietf.org",
> "draft-ietf-ospf-sr-yang@ietf.org",
> "draft-ietf-pim-yang@ietf.org",
> "draft-ietf-bier-bier-yang@ietf.org",
> "draft-zhang-bier-te-yang@ietf.org",
> "draft-ietf-isis-yang-isis-cfg@ietf.org",
> "draft-ietf-teas-yang-rsvp-te@ietf.org",
> "draft-ietf-mpls-mldp-yang@ietf.org",
> "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",
> "draft-ietf-isis-sr-yang@ietf.org",
> "draft-acee-rtgwg-yang-rib-extend@ietf.org",
> "draft-ietf-pim-igmp-mld-yang@ietf.org",
> "draft-ietf-i2rs-fb-rib-data-model@ietf.org",
> "draft-ietf-ospf-yang@ietf.org",
> "draft-ietf-rtgwg-yang-rip@ietf.org",
> "draft-ietf-spring-sr-yang@ietf.org",
> "draft-ietf-teas-yang-rsvp@ietf.org",
> "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",
> "draft-ietf-mpls-ldp-yang@ietf.org",
> "draft-ietf-bfd-yang@ietf.org",
> "draft-ietf-pim-msdp-yang@ietf.org"
>          ]
>      }
> }
>
> Fortunately, we only deal with IETF dependent YANG modules in case of
> the ietf-routing. That's an easier case.
> If we would change ietf-interfaces to ietf-interfaces-2, we would have
> an cross SDO issue ... Btw, there are no automatic ways to extract the
> authors of YANG modules from different SDOs: it's only a metadata that
> that the different SDOs should insert in the yangcatalog. So we would
> have to rely on liaisons or direct emails, assuming we know the authors.
> Time consuming, believe me.
>
> Regards, Benoit
>> Hi,
>>
>>      As part of the my Routing Directorate review of
>> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
>> changes being made to the ietf-l3vpn-svc module without changing the
>> name.  I raised this with the YANG doctors and others involved with the
>> draft and it surfaced some topics which really should be discussed here
>> in NetMod.
>>
>> The background (as explained off-list by others, so I hope I have it
>> right)  is that one of the YANG Doctors noted that RFC8049 was broken
>> and could not be implemented as defined, and therefore a fix was
>> needed.  L3SM has concluded so the fix is in the individual draft
>> draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
>> module could not be implemented, the feeling by the YANG Dr was that
>> even though the new module is incompatible with the original definition
>> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
>> RFC 6020) didn't have to be followed and the same name could be used.
>>
>> In the subsequent discussion with the YANG Drs., the general discussion
>> was heading down the path of using a new module name, and thereby not
>> violating YANG module update rules.  This lead us back to the a similar
>> discussion we've been having in the context of 8022bis: how best to
>> indicate that a whole module is being obsoleted.  RFCs do this by adding
>> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
>> help YANG tooling.  For 8022, we have one approach - publishing an
>> updated rev of the original module marking all nodes as deprecated - but
>> that doesn't really make sense for rfc8049bis.
>>
>> So the discussion for the WG is:
>>
>> How do we handle incompatible module changes, notably when one module
>> 'obsoletes' another module --  from both the process and tooling
>> perspectives?
>>
>> I know Benoit plans to bring in some thoughts/proposals, perhaps there
>> are others.
>>
>> Cheers,
>>
>> Lou
>>
>> (as contributor/reviewer)
>>
>>
>> .
>>
>

------------15f105bfd50421d27d3d5b7299
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit



      








So circling back to the
original question: what do we do about the non backward-compatible module
being defined in rfc8049bis?


While being sympathetic to many
of the comments made below as well as the "do over" concept, I find the
comments about adhering to the rules of 7950 compelling - which leads to
renaming the module in the bis to ietf-l3vpn-svc-2.


It would be good to ensure that
this is the consensus of the group before asking the authors make this
change.


This change course doesn't
solve the versioning issue discussed below, but this is not a new issue
it's just the first time we'll actually executing the steps envisioned as
part of the rules laid out in yang. My personal take away is that means
that we should immediately start work on an extension defining along the
lines of  ' obsolete|update' mentioned below.


Lou






On
October 8, 2017 10:59:15 AM Benoit Claise <bclaise@cisco.com> wrote:



    
Dear all,

      

      Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049
      is broken. The small problem is: trying to maintain backward
      compatibility.

      draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.

      

      Let me extend the scope of this email thread from "handling module
      incompatibility" to "handling module incompatibility and NMDA
      transition".

      As I mentioned in the past (see "semver.org comparison of two YANG
      modules" email in NETMOD), I believe the IETF will have to change
      its way of working in terms of backward compatibility. See also
      the email "ietf-routing or ietf-routing-2? module naming
      convention for NMDA transition. Re: [netmod] upcoming adoptions"
      in NETMOD. 

      

      However, we will have to tackle this discussion one day or the
      other: 

      - we need an automatic way to make the link between the
      YANG module in RFC8049 and the YANG module in
      draft-wu-l3sm-rfc8049bis, or any non backward compatible YANG
      modules.

      - we need an automatic way to make the link between the
      YANG module in RFC8022 and the YANG module in
      draft-acee-netmod-rfc8022bis, or any new YANG module names used
      for NMDA transition.

      Note: actually, we face two different problems.
      draft-wu-l3sm-rfc8049bis might be declared backward incompatible
      with RFC8049, while RFC8022bis is backward compatible with
      RFC8022. The RFC8022bis went for a new YANG module name
      ietf-routing-2 to avoid to document the -state tree (as
      deprecated), based on the argument that ietf-routing is not yet
      implemented.

      

      Which solutions do we have from here? 

      #1. We keep the same module name and express that the YANG module
      in draft-wu-l3sm-rfc8049bis is not backward compatible with the
      RFC8049 one. This is the openconfig way. See
      draft-clacla-netmod-model-catalog (and
      draft-openconfig-netmod-model-catalog before)

      
      

        
  // extension statements
     extension openconfig-version {
       argument "semver" {
         yin-element false;
       }
       description
         "The OpenConfig version number for the module. This is
         expressed as a semantic version number of the form:
           x.y.z
          where:
           * x corresponds to the major version,
           * y corresponds to a minor version,
           * z corresponds to a patch version.
         This version corresponds to the model file within which it is
         defined, and does not cover the whole set of OpenConfig models.
         Where several modules are used to build up a single block of
         functionality, the same module version is specified across each
         file that makes up the module.

         A major version number of 0 indicates that this model is still
         in development (whether within OpenConfig or with industry
         partners), and is potentially subject to change.

         Following a release of major version 1, all modules will
         increment major revision number where backwards incompatible
         changes to the model are made.

         The minor version is changed when features are added to the
         model that do not impact current clients use of the model.

         The patch-level version is incremented when non-feature changes
         (such as bugfixes or clarifications to human-readable
         descriptions that do not impact model functionality) are made
         that maintain backwards compatibility.

         The version number is stored in the module meta-data.";
     }

      

      Similarly, we always keep the same YANG module name in case of
      NMDA transition. So ietf-routing-2 should be changed back to
      ietf-routing.

      The email thread "[Rtg-dt-yang-arch] ietf-routing or
      ietf-routing-2? module naming convention for NMDA transition. Re:
      [netmod] upcoming adoptions" seems to go in that direction.

      

      #2. Or we have a different module name, let's say ietf-l3vpn-svc-2
      or ietf-routing-2 but then, how do we make the link with the
      previous module? 

      Then ...  What? We create extension that will link the
      draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module?
      Same principle as #1, but just more complex. 

      Or we have a new YANG keyword (this implies YANG 2.0)

      

        
<CODE BEGINS>file "ietf-l3vpn-svc@2017-09-14.yang"
module ietf-l3vpn-svc-2 {
 yang-version 1.1;
 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
 prefix l3vpn-svc;
 obsolete|update ietf-l3vpn-svc@2017-01-2


      

      And whose responsibility is this to warn/push all authors of
      ietf-routing YANG modules to move to ietf-routing-2? (*)

      

      The following are non solution IMO:

      - Going from the draft-wu-l3sm-rfc8049bis YANG module to
      the draft-wu-l3sm-rfc8049bis document to lookup the IETF
      "obsolete" flag in order to understand that the RFC8049 YANG
      module is obsolete is not an automatic solution.

      - Using the yangcatalog.org might be a solution as we track the
      derived semantic, but this is just an offline trick. This is not
      what I call "automatic way"

      - Using the YANG module description field might be interesting,
      but again this is not an "automatic way":

      

        
 description
  "This YANG module defines a generic service configuration
   model for Layer 3 VPNs. This model is common across all
   vendor implementations. This obsoletes the RFC8049 YANG 
   module, ietf-l3vpn-svc@2017-01-2";
 revision 2017-09-14 {
  description
  
"First revision of RFC8049.";
  reference
   "RFC xxxx: YANG Data Model for L3VPN Service Delivery";

      

      

      In conclusion, I believe openconfig got this right and that
      solution #1 is the solution to go ... while waiting for a new YANG
      keyword in YANG 2.0

      

      (*) If you want to change the module from ietf-routing to
      ietf-routing-2, then you should follow with all authors of
      dependent modules to make sure they transition to ietf-routing-2

      In the yangcatalog.org, because I needed the information as OPS
      AD, we created a small script to get that authors list for IETF
      drafts. For the ietf-routing, this produces the following

      {

          "output": {

              "author-email": [

                  "draft-ietf-mpls-static-yang@ietf.org",

                  "draft-ietf-mpls-base-yang@ietf.org",

                  "draft-ietf-ospf-sr-yang@ietf.org",

                  "draft-ietf-pim-yang@ietf.org",

                  "draft-ietf-bier-bier-yang@ietf.org",

                  "draft-zhang-bier-te-yang@ietf.org",

                  "draft-ietf-isis-yang-isis-cfg@ietf.org",

                  "draft-ietf-teas-yang-rsvp-te@ietf.org",

                  "draft-ietf-mpls-mldp-yang@ietf.org",

                  "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",

                  "draft-ietf-isis-sr-yang@ietf.org",

                  "draft-acee-rtgwg-yang-rib-extend@ietf.org",

                  "draft-ietf-pim-igmp-mld-yang@ietf.org",

                  "draft-ietf-i2rs-fb-rib-data-model@ietf.org",

                  "draft-ietf-ospf-yang@ietf.org",

                  "draft-ietf-rtgwg-yang-rip@ietf.org",

                  "draft-ietf-spring-sr-yang@ietf.org",

                  "draft-ietf-teas-yang-rsvp@ietf.org",

                  "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",

                  "draft-ietf-mpls-ldp-yang@ietf.org",

                  "draft-ietf-bfd-yang@ietf.org",

                  "draft-ietf-pim-msdp-yang@ietf.org"

              ]

          }

      }

      

      Fortunately, we only deal with IETF dependent YANG modules in case
      of the ietf-routing. That's an easier case.

      If we would change ietf-interfaces to ietf-interfaces-2, we would
      have an cross SDO issue ... Btw, there are no automatic ways to
      extract the authors of YANG modules from different SDOs: it's only
      a metadata that that the different SDOs should insert in the
      yangcatalog. So we would have to rely on liaisons or direct
      emails, assuming we know the authors. Time consuming, believe me.

      

      Regards, Benoit

    

    

      
Hi,

    As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name.  I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.

The background (as explained off-list by others, so I hope I have it
right)  is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed.  L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.

In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules.  This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted.  RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling.  For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.

So the discussion for the WG is:

How do we handle incompatible module changes, notably when one module
'obsoletes' another module --  from both the process and tooling
perspectives?

I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.

Cheers,

Lou

(as contributor/reviewer)


.



    

    

  








------------15f105bfd50421d27d3d5b7299--


From nobody Thu Oct 12 06:30:26 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009A71342EA; Thu, 12 Oct 2017 06:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, 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 81WSGcwLYPdP; Thu, 12 Oct 2017 06:30:20 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3101344DF; Thu, 12 Oct 2017 06:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32323; q=dns/txt; s=iport; t=1507815012; x=1509024612; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ehjf8nRRZ08b5pmYhijdjG5RqOsz8nX6TyjdjcxppmM=; b=Dym4Am8ZTMOFr5bmOvBjuid1SrAitMmDG+Lq2VJcbEgwytlsYprsGpEQ zRhe9r3lEwf2OK0lobLo38auFZn6viyX2ZKASp9dzD2Xn6yHrkC9DMV5P vvzAAh0qPxhM0/jt1srJzikCL8dWhzWcTc3ccw+EU9LjYYE1PzHsw8p4C I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAQD0bN9Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9AgRJuJ4N6ih90kA4ili8OggQKH4UcAoR5GAECAQEBAQEBAWs?= =?us-ascii?q?ohR0BAQEDARoJTggQCQIOCiAKAgJXBgEMBgIBAReJewgQjDedZ4InJ4sQAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYMtg1iBaisLgnSETQUBEgGDMoJhBYoeghyFDI9?= =?us-ascii?q?+h16DYokqghRdiHGHLoohg2qHYIE5HziBAwsyIQgdFUmFGhyBaT42iSSCNQEBA?= =?us-ascii?q?Q?=
X-IronPort-AV: E=Sophos;i="5.43,366,1503360000";  d="scan'208,217";a="658044034"
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; 12 Oct 2017 13:30:09 +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 v9CDU8b2019476; Thu, 12 Oct 2017 13:30:08 GMT
To: Lou Berger , NetMod WG 
Cc: rtg-dir@ietf.org, draft-acee-netmod-rfc8022bis@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
References:  <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
From: Benoit Claise 
Message-ID: <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com>
Date: Thu, 12 Oct 2017 15:30:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Content-Type: multipart/alternative; boundary="------------04E5314780CBCEB69EF6D7BF"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [RTG-DIR] handling module incompatibility => handling module transition
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Oct 2017 13:30:24 -0000

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

Hi Lou,
>
> So circling back to the original question: what do we do about the non 
> backward-compatible module being defined in rfc8049bis?
>
> While being sympathetic to many of the comments made below as well as 
> the "do over" concept, I find the comments about adhering to the rules 
> of 7950 compelling - which leads to renaming the module in the bis to 
> ietf-l3vpn-svc-2.
>
> It would be good to ensure that this is the consensus of the group 
> before asking the authors make this change.
>
Since this draft is AD sponsored, I'll evaluate the consensus on RFC8049bis.
Moving to ietf-l3vpn-svc-2 is the easy path not to break backward 
compatibility. However, since ietf-l3vpn-svc is unimplementable (it has 
broken XPATH expressions, so a compliant implementation is impossible), 
so technically, ietf-l3vpn-svc does not even exist.

What NETMOD should focus on is closing on the NMDA transition: the 
ietf-routing versus ietf-routing-2 issue.
Way bigger impact in terms of dependent YANG modules

Regards, Benoit (as OPS AD)
See below.
>
> This change course doesn't solve the versioning issue discussed below, 
> but this is not a new issue it's just the first time we'll actually 
> executing the steps envisioned as part of the rules laid out in yang. 
> My personal take away is that means that we should immediately start 
> work on an extension defining along the lines of  ' 
> *_obsolete|update_*' mentioned below.
>
I believe that option 1 is the more pragmatic and complete solution. 
option 2 is just half a step in the right direction.
I believe we should discuss this topic in Singapore.

Regards, Benoit (as individual contributor)
>
> Lou
>
> On October 8, 2017 10:59:15 AM Benoit Claise  wrote:
>
>> Dear all,
>>
>> Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049 is 
>> broken. The small problem is: trying to maintain backward compatibility.
>> draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.
>>
>> Let me extend the scope of this email thread from "handling module 
>> incompatibility" to "handling module incompatibility and NMDA 
>> transition".
>> As I mentioned in the past (see "semver.org comparison of two YANG 
>> modules" email in NETMOD), I believe the IETF will have to change its 
>> way of working in terms of backward compatibility. See also the email 
>> "ietf-routing or ietf-routing-2? module naming convention for NMDA 
>> transition. Re: [netmod] upcoming adoptions" in NETMOD.
>>
>> However, we will have to tackle this discussion one day or the other:
>> - we need _an automatic way_ to make the link between the YANG module 
>> in RFC8049 and the YANG module in draft-wu-l3sm-rfc8049bis, or any 
>> non backward compatible YANG modules.
>> - we need _an automatic way_ to make the link between the YANG module 
>> in RFC8022 and the YANG module in draft-acee-netmod-rfc8022bis, or 
>> any new YANG module names used for NMDA transition.
>> Note: actually, we face two different problems. 
>> draft-wu-l3sm-rfc8049bis might be declared backward incompatible with 
>> RFC8049, while RFC8022bis is backward compatible with RFC8022. The 
>> RFC8022bis went for a new YANG module name ietf-routing-2 to avoid to 
>> document the -state tree (as deprecated), based on the argument that 
>> ietf-routing is not yet implemented.
>>
>> Which solutions do we have from here?
>> #1. We keep the same module name and express that the YANG module in 
>> draft-wu-l3sm-rfc8049bis is not backward compatible with the RFC8049 
>> one. This is the openconfig way. See 
>> draft-clacla-netmod-model-catalog (and 
>> draft-openconfig-netmod-model-catalog before)
>>
>>        // extension statements
>>           extension openconfig-version {
>>             argument "semver" {
>>               yin-element false;
>>             }
>>             description
>>               "The OpenConfig version number for the module. This is
>>               expressed as a semantic version number of the form:
>>                 x.y.z
>>                where:
>>                 * x corresponds to the major version,
>>                 * y corresponds to a minor version,
>>                 * z corresponds to a patch version.
>>               This version corresponds to the model file within which it is
>>               defined, and does not cover the whole set of OpenConfig models.
>>               Where several modules are used to build up a single block of
>>               functionality, the same module version is specified across each
>>               file that makes up the module.
>>
>>               A major version number of 0 indicates that this model is still
>>               in development (whether within OpenConfig or with industry
>>               partners), and is potentially subject to change.
>>
>>               Following a release of major version 1, all modules will
>>               increment major revision number where backwards incompatible
>>               changes to the model are made.
>>
>>               The minor version is changed when features are added to the
>>               model that do not impact current clients use of the model.
>>
>>               The patch-level version is incremented when non-feature changes
>>               (such as bugfixes or clarifications to human-readable
>>               descriptions that do not impact model functionality) are made
>>               that maintain backwards compatibility.
>>
>>               The version number is stored in the module meta-data.";
>>           }
>>
>> Similarly, we always keep the same YANG module name in case of NMDA 
>> transition. So ietf-routing-2 should be changed back to ietf-routing.
>> The email thread "[Rtg-dt-yang-arch] ietf-routing or ietf-routing-2? 
>> module naming convention for NMDA transition. Re: [netmod] upcoming 
>> adoptions" seems to go in that direction.
>>
>> #2. Or we have a different module name, let's say ietf-l3vpn-svc-2 or 
>> ietf-routing-2 but then, how do we make the link with the previous 
>> module?
>> Then ...  What? We create extension that will link the 
>> draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? Same 
>> principle as #1, but just more complex.
>> Or we have a new YANG keyword (this implies YANG 2.0)
>>
>>     file"ietf-l3vpn-svc@2017-09-14.yang"
>>     module ietf-l3vpn-svc-2 {
>>       yang-version 1.1;
>>       namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
>>       prefix l3vpn-svc;
>>       *_obsolete|update _*ietf-l3vpn-svc@2017-01-2
>>
>> And whose responsibility is this to warn/push all authors of 
>> ietf-routing YANG modules to move to ietf-routing-2? (*)
>>
>> The following are non solution IMO:
>> - Going from the draft-wu-l3sm-rfc8049bis YANG _module _to the 
>> draft-wu-l3sm-rfc8049bis _document _to lookup the IETF "obsolete" 
>> flag in order to understand that the RFC8049 YANG module is obsolete 
>> is not an automatic solution.
>> - Using the yangcatalog.org might be a solution as we track the 
>> derived semantic, but this is just an offline trick. This is not what 
>> I call "automatic way"
>> - Using the YANG module description field might be interesting, but 
>> again this is not an "automatic way":
>>
>>       description
>>        "This YANG module defines a generic service configuration
>>         model for Layer 3 VPNs. This model is common across all
>>         vendor implementations. This obsoletes the RFC8049 YANG
>>         module, ietf-l3vpn-svc@2017-01-2";
>>       revision 2017-09-14 {
>>        description
>>        
>>     "First revision ofRFC8049 .";
>>        reference
>>         "RFC xxxx: YANG Data Model for L3VPN Service Delivery";
>>
>>
>> In conclusion, I believe openconfig got this right and that solution 
>> #1 is the solution to go ... while waiting for a new YANG keyword in 
>> YANG 2.0
>>
>> (*) If you want to change the module from ietf-routing to 
>> ietf-routing-2, then you should follow with all authors of dependent 
>> modules to make sure they transition to ietf-routing-2
>> In the yangcatalog.org, because I needed the information as OPS AD, 
>> we created a small script to get that authors list for IETF drafts. 
>> For the ietf-routing, this produces the following
>> {
>>     "output": {
>>         "author-email": [
>> "draft-ietf-mpls-static-yang@ietf.org",
>> "draft-ietf-mpls-base-yang@ietf.org",
>> "draft-ietf-ospf-sr-yang@ietf.org",
>> "draft-ietf-pim-yang@ietf.org",
>> "draft-ietf-bier-bier-yang@ietf.org",
>> "draft-zhang-bier-te-yang@ietf.org",
>> "draft-ietf-isis-yang-isis-cfg@ietf.org",
>> "draft-ietf-teas-yang-rsvp-te@ietf.org",
>> "draft-ietf-mpls-mldp-yang@ietf.org",
>> "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",
>> "draft-ietf-isis-sr-yang@ietf.org",
>> "draft-acee-rtgwg-yang-rib-extend@ietf.org",
>> "draft-ietf-pim-igmp-mld-yang@ietf.org",
>> "draft-ietf-i2rs-fb-rib-data-model@ietf.org",
>> "draft-ietf-ospf-yang@ietf.org",
>> "draft-ietf-rtgwg-yang-rip@ietf.org",
>> "draft-ietf-spring-sr-yang@ietf.org",
>> "draft-ietf-teas-yang-rsvp@ietf.org",
>> "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",
>> "draft-ietf-mpls-ldp-yang@ietf.org",
>> "draft-ietf-bfd-yang@ietf.org",
>> "draft-ietf-pim-msdp-yang@ietf.org"
>>         ]
>>     }
>> }
>>
>> Fortunately, we only deal with IETF dependent YANG modules in case of 
>> the ietf-routing. That's an easier case.
>> If we would change ietf-interfaces to ietf-interfaces-2, we would 
>> have an cross SDO issue ... Btw, there are no automatic ways to 
>> extract the authors of YANG modules from different SDOs: it's only a 
>> metadata that that the different SDOs should insert in the 
>> yangcatalog. So we would have to rely on liaisons or direct emails, 
>> assuming we know the authors. Time consuming, believe me.
>>
>> Regards, Benoit
>>> Hi,
>>>
>>>      As part of the my Routing Directorate review of
>>> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
>>> changes being made to the ietf-l3vpn-svc module without changing the
>>> name.  I raised this with the YANG doctors and others involved with the
>>> draft and it surfaced some topics which really should be discussed here
>>> in NetMod.
>>>
>>> The background (as explained off-list by others, so I hope I have it
>>> right)  is that one of the YANG Doctors noted that RFC8049 was broken
>>> and could not be implemented as defined, and therefore a fix was
>>> needed.  L3SM has concluded so the fix is in the individual draft
>>> draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
>>> module could not be implemented, the feeling by the YANG Dr was that
>>> even though the new module is incompatible with the original definition
>>> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
>>> RFC 6020) didn't have to be followed and the same name could be used.
>>>
>>> In the subsequent discussion with the YANG Drs., the general discussion
>>> was heading down the path of using a new module name, and thereby not
>>> violating YANG module update rules.  This lead us back to the a similar
>>> discussion we've been having in the context of 8022bis: how best to
>>> indicate that a whole module is being obsoleted.  RFCs do this by adding
>>> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
>>> help YANG tooling.  For 8022, we have one approach - publishing an
>>> updated rev of the original module marking all nodes as deprecated - but
>>> that doesn't really make sense for rfc8049bis.
>>>
>>> So the discussion for the WG is:
>>>
>>> How do we handle incompatible module changes, notably when one module
>>> 'obsoletes' another module --  from both the process and tooling
>>> perspectives?
>>>
>>> I know Benoit plans to bring in some thoughts/proposals, perhaps there
>>> are others.
>>>
>>> Cheers,
>>>
>>> Lou
>>>
>>> (as contributor/reviewer)
>>>
>>>
>>>
>>>


--------------04E5314780CBCEB69EF6D7BF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Lou,

    

    

      
      

        

          
So circling back
            to the
            original question: what do we do about the non
            backward-compatible module
            being defined in rfc8049bis?

          
While being
            sympathetic to many
            of the comments made below as well as the "do over" concept,
            I find the
            comments about adhering to the rules of 7950 compelling -
            which leads to
            renaming the module in the bis to ietf-l3vpn-svc-2.

          
It would be good
            to ensure that
            this is the consensus of the group before asking the authors
            make this
            change.

        

      

    

    Since this draft is AD sponsored, I'll evaluate the consensus on
    RFC8049bis.

    Moving to ietf-l3vpn-svc-2 is the easy path not to break backward
    compatibility. However, since ietf-l3vpn-svc is unimplementable (it
    has broken XPATH expressions, so a compliant implementation is
    impossible), so technically, ietf-l3vpn-svc does not even exist. 

    

    What NETMOD should focus on is closing on the NMDA transition: the
    ietf-routing versus ietf-routing-2 issue. 

    Way bigger impact in terms of dependent YANG modules

    

    Regards, Benoit (as OPS AD)

    See below.

    

      

        

          
This change course
            doesn't
            solve the versioning issue discussed below, but this is not
            a new issue
            it's just the first time we'll actually executing the steps
            envisioned as
            part of the rules laid out in yang. My personal take away is
            that means
            that we should immediately start work on an extension
            defining along the
            lines of  ' obsolete|update' mentioned below.

        

      

    

    I believe that option 1 is the more pragmatic and complete solution.
    option 2 is just half a step in the right direction. 

    I believe we should discuss this topic in Singapore.

    

    Regards, Benoit (as individual contributor)

    

      

        

          
Lou

          

        

        

          
On
            October 8, 2017 10:59:15 AM Benoit Claise
            <bclaise@cisco.com> wrote:

          

            
Dear all,

              

              Focusing on draft-wu-l3sm-rfc8049bis, the big problem is:
              RFC8049 is broken. The small problem is: trying to
              maintain backward compatibility.

              draft-wu-l3sm-rfc8049bis has rightly focused on the big
              problem.

              

              Let me extend the scope of this email thread from
              "handling module incompatibility" to "handling module
              incompatibility and NMDA transition".

              As I mentioned in the past (see "semver.org comparison of
              two YANG modules" email in NETMOD), I believe the IETF
              will have to change its way of working in terms of
              backward compatibility. See also the email "ietf-routing
              or ietf-routing-2? module naming convention for NMDA
              transition. Re: [netmod] upcoming adoptions" in NETMOD. 

              

              However, we will have to tackle this discussion one day or
              the other: 

              - we need an automatic way to make the link
              between the YANG module in RFC8049 and the YANG module in
              draft-wu-l3sm-rfc8049bis, or any non backward compatible
              YANG modules.

              - we need an automatic way to make the link
              between the YANG module in RFC8022 and the YANG module in
              draft-acee-netmod-rfc8022bis, or any new YANG module names
              used for NMDA transition.

              Note: actually, we face two different problems.
              draft-wu-l3sm-rfc8049bis might be declared backward
              incompatible with RFC8049, while RFC8022bis is backward
              compatible with RFC8022. The RFC8022bis went for a new
              YANG module name ietf-routing-2 to avoid to document the
              -state tree (as deprecated), based on the argument that
              ietf-routing is not yet implemented.

              

              Which solutions do we have from here? 

              #1. We keep the same module name and express that the YANG
              module in draft-wu-l3sm-rfc8049bis is not backward
              compatible with the RFC8049 one. This is the openconfig
              way. See draft-clacla-netmod-model-catalog (and
              draft-openconfig-netmod-model-catalog before)

              
              

                
  // extension statements
     extension openconfig-version {
       argument "semver" {
         yin-element false;
       }
       description
         "The OpenConfig version number for the module. This is
         expressed as a semantic version number of the form:
           x.y.z
          where:
           * x corresponds to the major version,
           * y corresponds to a minor version,
           * z corresponds to a patch version.
         This version corresponds to the model file within which it is
         defined, and does not cover the whole set of OpenConfig models.
         Where several modules are used to build up a single block of
         functionality, the same module version is specified across each
         file that makes up the module.

         A major version number of 0 indicates that this model is still
         in development (whether within OpenConfig or with industry
         partners), and is potentially subject to change.

         Following a release of major version 1, all modules will
         increment major revision number where backwards incompatible
         changes to the model are made.

         The minor version is changed when features are added to the
         model that do not impact current clients use of the model.

         The patch-level version is incremented when non-feature changes
         (such as bugfixes or clarifications to human-readable
         descriptions that do not impact model functionality) are made
         that maintain backwards compatibility.

         The version number is stored in the module meta-data.";
     }

              

              Similarly, we always keep the same YANG module name in
              case of NMDA transition. So ietf-routing-2 should be
              changed back to ietf-routing.

              The email thread "[Rtg-dt-yang-arch] ietf-routing or
              ietf-routing-2? module naming convention for NMDA
              transition. Re: [netmod] upcoming adoptions" seems to go
              in that direction.

              

              #2. Or we have a different module name, let's say
              ietf-l3vpn-svc-2 or ietf-routing-2 but then, how do we
              make the link with the previous module? 

              Then ...  What? We create extension that will link the
              draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG
              module? Same principle as #1, but just more complex. 

              Or we have a new YANG keyword (this implies YANG 2.0)

              

                
<CODE BEGINS>file "ietf-l3vpn-svc@2017-09-14.yang"
module ietf-l3vpn-svc-2 {
 yang-version 1.1;
 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
 prefix l3vpn-svc;
 obsolete|update ietf-l3vpn-svc@2017-01-2


              

              And whose responsibility is this to warn/push all authors
              of ietf-routing YANG modules to move to ietf-routing-2?
              (*)

              

              The following are non solution IMO:

              - Going from the draft-wu-l3sm-rfc8049bis YANG module
              to the draft-wu-l3sm-rfc8049bis document to
              lookup the IETF "obsolete" flag in order to understand
              that the RFC8049 YANG module is obsolete is not an
              automatic solution.

              - Using the yangcatalog.org might be a solution as we
              track the derived semantic, but this is just an offline
              trick. This is not what I call "automatic way"

              - Using the YANG module description field might be
              interesting, but again this is not an "automatic way":

              

                
 description
  "This YANG module defines a generic service configuration
   model for Layer 3 VPNs. This model is common across all
   vendor implementations. This obsoletes the RFC8049 YANG 
   module, ietf-l3vpn-svc@2017-01-2";
 revision 2017-09-14 {
  description
  
"First revision of RFC8049.";
  reference
   "RFC xxxx: YANG Data Model for L3VPN Service Delivery";

              

              

              In conclusion, I believe openconfig got this right and
              that solution #1 is the solution to go ... while waiting
              for a new YANG keyword in YANG 2.0

              

              (*) If you want to change the module from ietf-routing to
              ietf-routing-2, then you should follow with all authors of
              dependent modules to make sure they transition to
              ietf-routing-2

              In the yangcatalog.org, because I needed the information
              as OPS AD, we created a small script to get that authors
              list for IETF drafts. For the ietf-routing, this produces
              the following

              {

                  "output": {

                      "author-email": [

                          "draft-ietf-mpls-static-yang@ietf.org",

                          "draft-ietf-mpls-base-yang@ietf.org",

                          "draft-ietf-ospf-sr-yang@ietf.org",

                          "draft-ietf-pim-yang@ietf.org",

                          "draft-ietf-bier-bier-yang@ietf.org",

                          "draft-zhang-bier-te-yang@ietf.org",

                          "draft-ietf-isis-yang-isis-cfg@ietf.org",

                          "draft-ietf-teas-yang-rsvp-te@ietf.org",

                          "draft-ietf-mpls-mldp-yang@ietf.org",

                          "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",

                          "draft-ietf-isis-sr-yang@ietf.org",

                          "draft-acee-rtgwg-yang-rib-extend@ietf.org",

                          "draft-ietf-pim-igmp-mld-yang@ietf.org",

                          "draft-ietf-i2rs-fb-rib-data-model@ietf.org",

                          "draft-ietf-ospf-yang@ietf.org",

                          "draft-ietf-rtgwg-yang-rip@ietf.org",

                          "draft-ietf-spring-sr-yang@ietf.org",

                          "draft-ietf-teas-yang-rsvp@ietf.org",

                          "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",

                          "draft-ietf-mpls-ldp-yang@ietf.org",

                          "draft-ietf-bfd-yang@ietf.org",

                          "draft-ietf-pim-msdp-yang@ietf.org"

                      ]

                  }

              }

              

              Fortunately, we only deal with IETF dependent YANG modules
              in case of the ietf-routing. That's an easier case.

              If we would change ietf-interfaces to ietf-interfaces-2,
              we would have an cross SDO issue ... Btw, there are no
              automatic ways to extract the authors of YANG modules from
              different SDOs: it's only a metadata that that the
              different SDOs should insert in the yangcatalog. So we
              would have to rely on liaisons or direct emails, assuming
              we know the authors. Time consuming, believe me.

              

              Regards, Benoit

            

            

              
Hi,

    As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name.  I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.

The background (as explained off-list by others, so I hope I have it
right)  is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed.  L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.

In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules.  This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted.  RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling.  For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.

So the discussion for the WG is:

How do we handle incompatible module changes, notably when one module
'obsoletes' another module --  from both the process and tooling
perspectives?

I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.

Cheers,

Lou

(as contributor/reviewer)






            

          

        

      

    

    

  


--------------04E5314780CBCEB69EF6D7BF--


From nobody Thu Oct 12 07:25:41 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5844E13430F; Thu, 12 Oct 2017 07:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.489
X-Spam-Level: 
X-Spam-Status: No, score=-14.489 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_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYf42Tg6JQ93; Thu, 12 Oct 2017 07:25:29 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096BB132D4E; Thu, 12 Oct 2017 07:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=82449; q=dns/txt; s=iport; t=1507818328; x=1509027928; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=wxxz+cSpd04TRlEjDw8lnwIjI+vIcnSpP+kaHQkL9O4=; b=XdCOxwXkq2rnCxrDPZo40YRUfUJUJSN/sPiflOsko6yfA6SRLgYHkULE mgqUdamWkNV8uThruMQ1i6DdLft3zffaEoxhc1vqxnjAV6u5aHiOHP8Ek W5C0UoT55rvR+DD5lKE2gxZxwcik43a2AM0jDb/ftIuunsTBRhnJ+l544 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAQBqet9Z/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvgVJuJ4N6ih90kA4ieYdMhQ6IXIIPAwoYAQqBXoJrTwKEexg?= =?us-ascii?q?BAgEBAQEBAQFrKIUdAQEBAwEBARgBCAQGQRAHBAkCEQMBAQEBIAEGAwICIQYfC?= =?us-ascii?q?QgGAQwGAgEBFgGJawMNCBCMM51ngW06J4cYDYNsAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBHYMtg1iBaisLgj81gl6BfBU2FoJdgmEFihYIhyiHHogkPIdeiBOEeYIUX?= =?us-ascii?q?YUXg1qHLo0AgQuHYIE5HziBDjIhCB0VSYUaHIFoPzYBAQGJFCyCFgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,366,1503360000";  d="scan'208,217";a="656317518"
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; 12 Oct 2017 14:25:25 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9CEPO70002095; Thu, 12 Oct 2017 14:25:24 GMT
To: Xufeng Liu , "'t.petch'" ,  "'Igor Bryskin'" , netconf@ietf.org, netmod@ietf.org
References: <049501d34104$6aa46670$3fed3350$@gmail.com> <59DB9E54.8080805@tail-f.com> <0C72C38E7EBC34499E8A9E7DD007863909CDB234@SJCEML702-CHM.china.huawei.com> <20171009.191347.1897981146275128665.mbj@tail-f.com> <6f8eb6ff-8fc5-4be3-d582-b188bd2337a6@tail-f.com>   <0C72C38E7EBC34499E8A9E7DD007863909CDB9E2@SJCEML702-CHM.china.huawei.com> <42819484-f9b5-4f06-dd58-23d9bc8c1ecc@cisco.com>  <02aa01d34275$192f1840$4001a8c0@gateway.2wire.net>  <06f901d342c0$d368ef60$7a3ace20$@gmail.com>
From: Robert Wilton 
Message-ID: <015b97e0-5da4-2987-8288-aecf55e555a4@cisco.com>
Date: Thu, 12 Oct 2017 15:25:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <06f901d342c0$d368ef60$7a3ace20$@gmail.com>
Content-Type: multipart/alternative; boundary="------------BA72A262AE0C3477D4AAECF1"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf]  Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Oct 2017 14:25:33 -0000

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

Hi Xufeng,

Just a note for clarity: My combined proposal using subtree filtering 
and XPath isn't a valid NETCONF filter today, I was suggesting it as a 
potential future enhancement to NETCONF.  My reading of the NETCONF 
draft is that an XPath filter can only be specified at the top level.

Thanks,
Rob


On 11/10/2017 19:43, Xufeng Liu wrote:
>
> Hi Rob,
>
> Thanks for the proposal. I think that the subtree does help, to a 
> certain extend. The approach is worth mentioning to the implementers, 
> though the remaining XPath is still complicated and could be worse for 
> a more complex model. The good thing about the approach is that this 
> is what we already have today. I agree with Tom on that NETCONF should 
> have a better solution, but that may require protocol changes and need 
> to cover more generic cases as Per described.
>
> Thanks,
>
> - Xufeng
>
> *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Robert 
> Wilton
> *Sent:* Wednesday, October 11, 2017 6:49 AM
> *To:* t.petch ; Igor Bryskin 
> ; netconf@ietf.org; netmod@ietf.org
> *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by 
> leafref
>
> I've also been thinking about this problem a bit more :-)
>
> The XPath solution works, but the expression isn't particularly nice 
> to write, and I suspect that implementations may struggle to implement 
> it efficiently (if they support XPath filtering at all).
>
> A nicer solution here might be to allow the XPath filters to be 
> combined with a subtree filter along the lines of a more advanced type 
> of "Attribute Match Expression" sec 6.2.2 of rfc6241.
>
> E.g. rather than this XPath filter:
>
> /te:te/te:tunnels/te:tunnel[te:name='foo'] |
> /te:te/te:connections/te:connection[te:name=/te:te/te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name]
>
> Here is example of what a subtree filter combined with an XPath filter 
> could potentially look like (which of course isn't valid NETCONF/YANG 
> today):
>
> 
>    
>      
>      
>        
>      
>    
> 
>
>
> Any opinions on whether this would be beneficial or is this just 
> reinventing the wheel?
>
> Thanks,
> Rob
>
> On 11/10/2017 10:41, t.petch wrote:
>
>     Igor
>
>     Thinking laterally, this is a problem that DNS encountered a few decades
>
>     ago and solved, by allowing the server to include additional information
>
>     not specifically requested that the server can see is going to be needed
>
>     for the next step, so if the client asks only about a CNAME, then the
>
>     server can provide the relevant IP address as well.
>
>     I suspect that the current rules for Netconf do not allow the server to
>
>     send anything not explicitly requested, which is a shame (IMO).
>
>     The DNS approach works very well, in fact I do not think we would
>
>     survive without it.
>
>     Tom Petch
>
>     ----- Original Message -----
>
>     From: "Igor Bryskin" 
>
>     Sent: Tuesday, October 10, 2017 2:35 PM
>
>     Hi Rob,
>
>     This helps a lot. What you wrote will work.
>
>     The only difference is that if we would have the "joimt with" clause as
>
>     we proposed, the server would be able to tailor the te-tunnel
>
>     presentation to the client's requirements, e.g. substituting the
>
>     connection pointers with connection bodies, while, according to your
>
>     suggestion, the server will provide the te-tunnel body as is, and then
>
>     augment it with the cobbection information, thus, leaving
>
>     for the client to "shuffle " the received data. But I do agree, this
>
>     would be a minor inconvinience for the client, the important thing is
>
>     that the client will get all the data in one piece.
>
>     Thanks a lot,
>
>     Igor
>
>     c
>
>     From:Robert Wilton
>
>     To:Igor Bryskin,
>
>     Cc:Per Hedeland,netmod@ietf.org,netconf@ietf.org
>     ,
>
>     Date:2017-10-10 06:41:04
>
>     Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
>
>     Hi Igor,
>
>     On 09/10/2017 23:11, Igor Bryskin wrote:
>
>         Hi Per,
>
>         This is a good news, but, please, help us out.
>
>         Consider, we have a node - "te-tunnel" - which among other attributes
>
>     has two key leafref lists:
>
>         1) each member of the 1st list points to a "connection" supporting the
>
>     te-tunnel. All connections supporting all te-tunnels are stored in a
>
>     single list of connections.
>
>         2) each member of the 2nd list points to a supporting "te-tunnel" -
>
>     the te-tunnel in question depends on. All te=tunnels including the
>
>     te-tunnel in question, are stored in a single list of te-tunnels.
>
>         The question: how the client can retrieve via a single request all
>
>     attributes of the te-tunnel in question along with all parameters of all
>
>     connections supporting the te-tunnel, but with just pointers to
>
>     supporting te-tunnels (so that the interested client can use the
>
>     pointers to retrieve full data via subsequent separate requests) ?
>
>     I think that it might be something like this (for tunnel name foo):
>
>         /te/tunnels/tunnel[name='foo'] |
>
>     /te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio
>
>     ns/connection/name]
>
>     E.g. in English, this should equate to something like:
>
>     Return all information for tunnel foo AND ALSO
>
>     Return all information for all connections where the connection name
>
>     matches one of the connections listed in tunnel foo.
>
>         Likewise, how the client can ask for full data of the te-tunnel and
>
>     all supporting te-tunnels and just pointers for supporting connections?
>
>     If my xpath above is right, then this would be something roughly like
>
>     this:
>
>         /te/tunnels/tunnel[name='foo'] |
>
>     /te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel
>
>     s/supporting-tunnel/name]
>
>     I'm an XPath novice, so the expressions might be wrong.
>
>     https://www.freeformatter.com/xpath-tester.html  might be useful. E.g. if
>
>     you can construct a simple XML instance tree of your data, you could
>
>     validate whether the XPath expression works.
>
>     I hope that this is of some help,
>
>     Rob
>
>         I really appreciate your help,
>
>         Igor
>
>         -----Original Message-----
>
>         From: Per Hedeland [mailto:per@tail-f.com]
>
>         Sent: Monday, October 09, 2017 5:21 PM
>
>         To: Igor Bryskin
>
>         Cc:mbj@tail-f.com ;xufeng.liu.ietf@gmail.com ;netconf@ietf.org ;
>
>     netmod@ietf.org 
>
>         Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>
>     leafref
>
>         Just to be clear: what we're suggesting is that you can use the
>
>         already-existing standard NETCONF XPath capability to achieve the
>
>     desired
>
>         result - seehttps://tools.ietf.org/html/rfc6241#section-8.9
>
>         --Per
>
>         On 2017-10-09 21:52, Igor Bryskin wrote:
>
>             I agree. For example, a leafref may point not to a singls entity, but
>
>     to a list of entities, and the client might want to expand all of them
>
>     into the joint get response.
>
>             Igor
>
>             *From:*Per Hedeland
>
>             *To:*Martin Bjorklund,
>
>             *Cc:*Igor
>
>     Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org
>     ,
>
>             *Date:*2017-10-09 15:12:22
>
>             *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>
>     leafref
>
>             On 2017-10-09 19:13, Martin Bjorklund wrote:
>
>                 Igor Bryskin   wrote:
>
>                     Hi Per,
>
>                     Basically, what we need is a way for a client to request something
>
>                     like this:
>
>                     get  joint with 
>
>                 ... which is what Per's expression does!  Note that "|" in XPath
>
>     means
>
>                 "union".
>
>                 But as Per explained, it only works in some cases (when the leafref
>
>                 acts a "single pointer").
>
>             Well, that particular expression works only in that case - but since
>
>     it
>
>             is effectively the client that (perhaps based on the data model)
>
>     decides
>
>             what the leafref-leafs "mean" (in this case the single key of a
>
>     single
>
>             list), other cases can be handled the same way. E.g. multiple
>
>             leafref-to-key leafs that together give the keys of a multi-key list
>
>             just amounts to a slightly hairier XPath filter...
>
>             --Per
>
>                     with a server interpreting the request as follows:
>
>                     if a node pointed by XPath contains a pointer (e.g. key leafref)
>
>                     matching one of the XPath from the "joint with" list, then the
>
>     server
>
>                     must provide the entire body of the node pointed by the pointer,
>
>                     otherwise, just the pointer (as it happens today, that is, when no
>
>                     "joint with" list specified).
>
>                     We think that this would allow for the client to optimize the
>
>     number
>
>                     of request-response iterations depending on application/use case.
>
>                     Regards,
>
>                     Igor
>
>                 /martin
>
>                     -----Original Message-----
>
>                     From: Per Hedeland [mailto:per@tail-f.com]
>
>                     Sent: Monday, October 09, 2017 12:06 PM
>
>                     To: Xufeng Liu
>
>                     Cc: Igor Bryskin;netconf@ietf.org ;netmod@ietf.org 
>
>                     Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
>
>                     leafref
>
>                     I understand your use case, but a leaf of type leafref does not in
>
>                     general identify a single node in the data tree - the leafref path
>
>                     could
>
>                     be for a non-key leaf, and/or the path could traverse list nodes,
>
>                     and/or
>
>                     the "target" list could have multiple keys and thus multiple
>
>                     leafref-leafs be required to identify a specific list entry.
>
>                     Thus it seems to me that your use case is not a reasonable basis
>
>     for a
>
>                     new protocol operation. My XPath foo isn't very good either, but I
>
>     do
>
>                     believe Robert's suggestion of using an XPath filter could be a way
>
>                     forward. I *think* the filter expression would be something along
>
>     the
>
>                     lines of
>
>                         /te/tunnels/tunnel[name='foo'] |
>
>     /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/pat
>
>     hs/path/explicit-path]
>
>                     --Per
>
>                     On 2017-10-09 15:42, Xufeng Liu wrote:
>
>                         Hi Per,
>
>                         *From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
>
>                         *Sent:* Sunday, October 8, 2017 7:04 PM
>
>                         *To:* Igor Bryskin
>                         ;per@tail-f.com ;
>
>                         *xufeng.liu.ietf@gmail.com
>                         
>
>                         *Cc:*netconf@ietf.org ;netmod@ietf.org 
>
>                         *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed
>
>     by
>
>                         *leafref
>
>                         Hi Joel,
>
>                         Thanks, I think I didnt explain our problem correctly.
>
>                         In our case we have a leafref pointing to a te tunnel name, which
>
>                         happens to be a key to lookup the (axilary) tunnel.  We need a way
>
>     to
>
>                         include the entire tunnel body (not just a name) into the get
>
>                         response. This is to optimize the number of iterations between the
>
>                         client and the server. As Xufeng put it something similar to SQL
>
>     join,
>
>                         Igor
>
>                         *From:*Igor Bryskin
>
>                         *To:*per@tail-f.com,xufeng.liu.ietf@gmail.com
>                         ,
>
>                         *Cc:*netconf@ietf.org,netmod@ietf.org ,
>
>                         *Date:*2017-10-08 17:36:47
>
>                         *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>
>                         *leafref
>
>                         Hi Per,
>
>                         In a nutshell we would lika for a netconf client to have a way to
>
>                         instruct the server on whether in response to the get request the
>
>                         server needs to provide the entire body of a datastore node
>
>     pointed
>
>                         to by a leafref or just a pointer to said node, so that the node's
>
>                         body could be retrieved by a subsequent separate request. This is
>
>                         requested by implementors who want to optimise rhe number of
>
>                         interactions between a client and its server.
>
>                         Cheers,
>
>                         Igor
>
>                         *From:*Per Hedeland
>
>                         *To:*Xufeng Liu,
>
>                         *Cc:*netconf@ietf.org,'NetMod WG',
>
>                         *Date:*2017-10-08 14:01:27
>
>                         *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
>
>                         *leafref
>
>                         On 2017-10-06 23:11, Xufeng Liu wrote:
>
>                             During the design team discussion for TE and MPLS YANG modeling,
>
>     we
>
>                             have received a request from implementers: How to minimize the
>
>     number
>
>                             of NETCONF/RESTCONF RPCs to improve operation efficiency?
>
>                             Especially for the case when the operator or client software
>
>     needs to
>
>                             retrieve the object contents pointed by a leafref.
>
>                             For example, given the following simplified TE tunnel model,
>
>                             +--rw te
>
>                                     +--rw explicit-paths
>
>                                     |  +--rw explicit-path* [name]
>
>                                     |     +--rw name                      string
>
>                                     |        +--rw explicit-route-object* [index]
>
>                                     |           +--rw index                   uint32
>
>                                     |           +--rw explicit-route-usage?   identityref
>
>                                     +--rw tunnels
>
>                                     |  +--rw tunnel* [name]
>
>                                     |  |  +--rw name                   string
>
>                                     |  |  +--rw paths
>
>                                     |  |  |  +--rw path* [name]
>
>                             |  |  |     +--rw explicit-path?  ->
>
>                             |  |  |     ../../../../../explicit-paths/explicit-path/name
>
>                             when the client tries to retrieve a tunnels information based on
>
>     the
>
>                             tunnel name, the get operation returns a list of leafrefs
>
>     pointing
>
>                             to the paths of the tunnel.
>
>                         Sorry, I'm afraid I don't follow. Can you explain exactly what
>
>     your
>
>                         "get" request is (protocol and payload), and where the "list of
>
>                         leafref's" (whatever that may be) occurs in the reply?
>
>                         */[Xufeng] The get operation is the NETCONF/RESTCON 
>
>     protocol
>
>                         *operation, or the  operation described in
>
>                         *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01  and the
>
>     GET
>
>                         *operations
>
>                         on {+restconf}/ds/ described in
>
>                         https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*
>
>                         */ /*
>
>                         */We have a list of leafref values because in this example model,
>
>     each
>
>                         *tunnel contains a list of paths, each of them contains a leafref.
>
>     The
>
>                         *get returns a value for each instance of such a leafref,
>
>                         which (as a string value) will be used as a constraint (foreign
>
>     key)
>
>                         to retrieve the instance of an explicit-path in the model above./*
>
>                         JFYI, in case there is some fundamental misunderstanding here: a
>
>     leaf
>
>                         of
>
>                         type leafref has a single value - *one* of those that satisfy the
>
>                         leafref
>
>                         constraint, in case there are multiple "candidates".
>
>                         --Per
>
>                             The client needs to issue at
>
>                             least one more get operation to retrieve the path information
>
>     about
>
>                             the given tunnel. The request is to combine these two operations
>
>     into
>
>                             one.
>
>                             In the RDBMS SQL world, join can be used when SQL select is
>
>                             performed, but NETCONF/YANG currently does not have this
>
>     capability.
>
>                             Wed like to ask whether such a request is considered reasonable.
>
>                             If the request is reasonable, the next question is how to
>
>                             proceed. This seems to be a protocol issue rather than YANG
>
>     modeling
>
>                             issue. Is it acceptable to add a new operation to achieve such a
>
>                              operation with expanded leafrefs?
>
>                             Comments and suggestions are appreciated.
>
>                             Thanks,
>
>                             - Xufeng
>
>                             _______________________________________________
>
>                             netmod mailing list
>
>                             netmod@ietf.org   
>                             
>
>                             https://www.ietf.org/mailman/listinfo/netmod
>
>                         _______________________________________________
>
>                         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
>
>         _______________________________________________
>
>         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
>
>     .
>


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


  
    
  
  
    
Hi Xufeng,

    
Just a note for clarity: My combined proposal using subtree
      filtering and XPath isn't a valid NETCONF filter today, I was
      suggesting it as a potential future enhancement to NETCONF.  My
      reading of the NETCONF draft is that an XPath filter can only be
      specified at the top level.

    Thanks,

    Rob

    

    

    
On 11/10/2017 19:43, Xufeng Liu wrote:

    

    

      
      
      
      

        
Hi Rob,

        
 

        
Thanks for
            the proposal. I think that the subtree does help, to a
            certain extend. The approach is worth mentioning to the
            implementers, though the remaining XPath is still
            complicated and could be worse for a more complex model. The
            good thing about the approach is that this is what we
            already have today. I agree with Tom on that NETCONF should
            have a better solution, but that may require protocol
            changes and need to cover more generic cases as Per
            described.

        
 

        
Thanks,

        
- Xufeng

        
 

        

          

            

              
From: Netconf
                  [mailto:netconf-bounces@ietf.org] On Behalf Of Robert
                  Wilton

                  Sent: Wednesday, October 11, 2017 6:49 AM

                  To: t.petch <ietfc@btconnect.com>; Igor
                  Bryskin <Igor.Bryskin@huawei.com>;
                  netconf@ietf.org; netmod@ietf.org

                  Subject: Re: [Netconf] [netmod] Retrieving
                  Information Pointed by leafref

            

          

          
 

          
I've also been thinking about this problem a bit more :-)

          
The XPath solution works, but the expression isn't
            particularly nice to write, and I suspect that
            implementations may struggle to implement it efficiently (if
            they support XPath filtering at all).

          
A nicer solution here might be to allow the XPath filters
            to be combined with a subtree filter along the lines of a
            more advanced type of "Attribute Match Expression" sec 6.2.2
            of rfc6241.

          
E.g. rather than this XPath filter:

          
/te:te/te:tunnels/te:tunnel[te:name='foo'] |

          
/te:te/te:connections/te:connection[te:name=/te:te/te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name]

          
 

          
Here is example of what a subtree filter combined with an
            XPath filter could potentially look like (which of course
            isn't valid NETCONF/YANG today):

          
<filter type="subtree-xpath">

          
  <te:te xmlns:te="...">

          
    <te:tunnels te:name="foo"/>

          
    <te:connections>

          
      <filter type="xpath" select="te:name = ../te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name)"/>

          
    </te:connections>

          
  </te:te>

          
</filter>

          


            Any opinions on whether this would be beneficial or is this
            just reinventing the wheel?

            

            Thanks,

            Rob

            

            

          

            
On 11/10/2017 10:41, t.petch wrote:

          

          

            
Igor

            
 

            
Thinking laterally, this is a problem that DNS encountered a few decades

            
ago and solved, by allowing the server to include additional information

            
not specifically requested that the server can see is going to be needed

            
for the next step, so if the client asks only about a CNAME, then the

            
server can provide the relevant IP address as well.

            
 

            
I suspect that the current rules for Netconf do not allow the server to

            
send anything not explicitly requested, which is a shame (IMO).

            
 

            
The DNS approach works very well, in fact I do not think we would

            
survive without it.

            
 

            
Tom Petch

            
 

            
----- Original Message -----

            
From: "Igor Bryskin" <Igor.Bryskin@huawei.com>

            
Sent: Tuesday, October 10, 2017 2:35 PM

            
 

            
Hi Rob,

            
 

            
This helps a lot. What you wrote will work.

            
 

            
The only difference is that if we would have the "joimt with" clause as

            
we proposed, the server would be able to tailor the te-tunnel

            
presentation to the client's requirements, e.g. substituting the

            
connection pointers with connection bodies, while, according to your

            
suggestion, the server will provide the te-tunnel body as is, and then

            
augment it with the cobbection information, thus, leaving

            
for the client to "shuffle " the received data. But I do agree, this

            
would be a minor inconvinience for the client, the important thing is

            
that the client will get all the data in one piece.

            
 

            
Thanks a lot,

            
Igor

            
 

            
c

            
 

            
From:Robert Wilton

            
To:Igor Bryskin,

            
Cc:Per Hedeland,netmod@ietf.org,netconf@ietf.org,

            
Date:2017-10-10 06:41:04

            
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

            
 

            
Hi Igor,

            
 

            
On 09/10/2017 23:11, Igor Bryskin wrote:

            

              
Hi Per,

              
 

              
This is a good news, but, please, help us out.

              
Consider, we have a node - "te-tunnel" - which among other attributes

            

            
has two key leafref lists:

            

              
1) each member of the 1st list points to a "connection" supporting the

            

            
te-tunnel. All connections supporting all te-tunnels are stored in a

            
single list of connections.

            

              
2) each member of the 2nd list points to a supporting "te-tunnel" -

            

            
the te-tunnel in question depends on. All te=tunnels including the

            
te-tunnel in question, are stored in a single list of te-tunnels.

            

              
 

              
The question: how the client can retrieve via a single request all

            

            
attributes of the te-tunnel in question along with all parameters of all

            
connections supporting the te-tunnel, but with just pointers to

            
supporting te-tunnels (so that the interested client can use the

            
pointers to retrieve full data via subsequent separate requests) ?

            
I think that it might be something like this (for tunnel name foo):

            
 

            
   /te/tunnels/tunnel[name='foo'] |

            
 

            
/te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio

            
ns/connection/name]

            
 

            
E.g. in English, this should equate to something like:

            
 

            
Return all information for tunnel foo AND ALSO

            
Return all information for all connections where the connection name

            
matches one of the connections listed in tunnel foo.

            
 

            

              
 

              
Likewise, how the client can ask for full data of the te-tunnel and

            

            
all supporting te-tunnels and just pointers for supporting connections?

            
If my xpath above is right, then this would be something roughly like

            
this:

            
 

            
   /te/tunnels/tunnel[name='foo'] |

            
 

            
/te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel

            
s/supporting-tunnel/name]

            
 

            
 

            
I'm an XPath novice, so the expressions might be wrong.

            
 

            
https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if

            
you can construct a simple XML instance tree of your data, you could

            
validate whether the XPath expression works.

            
 

            
I hope that this is of some help,

            
Rob

            
 

            
 

            

              
 

              
I really appreciate your help,

              
 

              
Igor

              
 

              
 

              
-----Original Message-----

              
From: Per Hedeland [mailto:per@tail-f.com]

              
Sent: Monday, October 09, 2017 5:21 PM

              
To: Igor Bryskin

              
Cc: mbj@tail-f.com; xufeng.liu.ietf@gmail.com; netconf@ietf.org;

            

            
netmod@ietf.org

            

              
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by

            

            
leafref

            

              
 

              
Just to be clear: what we're suggesting is that you can use the

              
already-existing standard NETCONF XPath capability to achieve the

            

            
desired

            

              
result - see https://tools.ietf.org/html/rfc6241#section-8.9

              
 

              
--Per

              
 

              
On 2017-10-09 21:52, Igor Bryskin wrote:

              

                
I agree. For example, a leafref may point not to a singls entity, but

              

            

            
to a list of entities, and the client might want to expand all of them

            
into the joint get response.

            

              

                
 

                
Igor

                
 

                
*From:*Per Hedeland

                
*To:*Martin Bjorklund,

                
*Cc:*Igor

              

            

            
Bryskin,xufeng.liu.ietf@gmail.com,netconf@ietf.org,netmod@ietf.org,

            

              

                
*Date:*2017-10-09 15:12:22

                
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by

              

            

            
leafref

            

              

                
 

                
On 2017-10-09 19:13, Martin Bjorklund wrote:

                

                  
Igor Bryskin <Igor.Bryskin@huawei.com> wrote:

                  

                    
Hi Per,

                    
 

                    
Basically, what we need is a way for a client to request something

                    
like this:

                    
 

                    
get <XPath> joint with <XPath1, XPath2, ..., XPathn>

                  

                  
... which is what Per's expression does!  Note that "|" in XPath

                

              

            

            
means

            

              

                

                  
"union".

                  
 

                  
But as Per explained, it only works in some cases (when the leafref

                  
acts a "single pointer").

                

                
Well, that particular expression works only in that case - but since

              

            

            
it

            

              

                
is effectively the client that (perhaps based on the data model)

              

            

            
decides

            

              

                
what the leafref-leafs "mean" (in this case the single key of a

              

            

            
single

            

              

                
list), other cases can be handled the same way. E.g. multiple

                
leafref-to-key leafs that together give the keys of a multi-key list

                
just amounts to a slightly hairier XPath filter...

                
 

                
--Per

                
 

                

                  

                    
with a server interpreting the request as follows:

                    
if a node pointed by XPath contains a pointer (e.g. key leafref)

                    
matching one of the XPath from the "joint with" list, then the

                  

                

              

            

            
server

            

              

                

                  

                    
must provide the entire body of the node pointed by the pointer,

                    
otherwise, just the pointer (as it happens today, that is, when no

                    
"joint with" list specified).

                    
 

                    
We think that this would allow for the client to optimize the

                  

                

              

            

            
number

            

              

                

                  

                    
of request-response iterations depending on application/use case.

                    
 

                    
Regards,

                    
Igor

                  

                  
 

                  
 

                  
/martin

                  
 

                  
 

                  

                    
 

                    
 

                    
 

                    
 

                    
 

                    
-----Original Message-----

                    
From: Per Hedeland [mailto:per@tail-f.com]

                    
Sent: Monday, October 09, 2017 12:06 PM

                    
To: Xufeng Liu

                    
Cc: Igor Bryskin; netconf@ietf.org; netmod@ietf.org

                    
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by

                    
leafref

                    
 

                    
I understand your use case, but a leaf of type leafref does not in

                    
general identify a single node in the data tree - the leafref path

                    
could

                    
be for a non-key leaf, and/or the path could traverse list nodes,

                    
and/or

                    
the "target" list could have multiple keys and thus multiple

                    
leafref-leafs be required to identify a specific list entry.

                    
 

                    
Thus it seems to me that your use case is not a reasonable basis

                  

                

              

            

            
for a

            

              

                

                  

                    
new protocol operation. My XPath foo isn't very good either, but I

                  

                

              

            

            
do

            

              

                

                  

                    
believe Robert's suggestion of using an XPath filter could be a way

                    
forward. I *think* the filter expression would be something along

                  

                

              

            

            
the

            

              

                

                  

                    
lines of

                    
 

                    
   /te/tunnels/tunnel[name='foo'] |

                    
 

                  

                

              

            

            
/te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/pat

            
hs/path/explicit-path]

            

              

                

                  

                    
 

                    
--Per

                    
 

                    
On 2017-10-09 15:42, Xufeng Liu wrote:

                    

                      
Hi Per,

                      
 

                      
 

                      
 

                      
*From:* Igor Bryskin [mailto:Igor.Bryskin@huawei.com]

                      
*Sent:* Sunday, October 8, 2017 7:04 PM

                      
*To:* Igor Bryskin <Igor.Bryskin@huawei.com>; per@tail-f.com;

                      
*xufeng.liu.ietf@gmail.com

                      
*Cc:* netconf@ietf.org; netmod@ietf.org

                      
*Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed

                    

                  

                

              

            

            
by

            

              

                

                  

                    

                      
*leafref

                      
 

                      
 

                      
 

                      
 

                      
Hi Joel,

                      
 

                      
Thanks, I think I didnt explain our problem correctly.

                      
 

                      
In our case we have a leafref pointing to a te tunnel name, which

                      
happens to be a key to lookup the (axilary) tunnel.  We need a way

                    

                  

                

              

            

            
to

            

              

                

                  

                    

                      
include the entire tunnel body (not just a name) into the get

                      
response. This is to optimize the number of iterations between the

                      
client and the server. As Xufeng put it something similar to SQL

                    

                  

                

              

            

            
join,

            

              

                

                  

                    

                      
 

                      
Igor

                      
 

                      
*From:*Igor Bryskin

                      
 

                      
*To:*per@tail-f.com,xufeng.liu.ietf@gmail.com,

                      
 

                      
*Cc:*netconf@ietf.org,netmod@ietf.org,

                      
 

                      
*Date:*2017-10-08 17:36:47

                      
 

                      
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by

                      
*leafref

                      
 

                      
 

                      
 

                      
Hi Per,

                      
 

                      
In a nutshell we would lika for a netconf client to have a way to

                      
instruct the server on whether in response to the get request the

                      
server needs to provide the entire body of a datastore node

                    

                  

                

              

            

            
pointed

            

              

                

                  

                    

                      
to by a leafref or just a pointer to said node, so that the node's

                      
body could be retrieved by a subsequent separate request. This is

                      
requested by implementors who want to optimise rhe number of

                      
interactions between a client and its server.

                      
 

                      
Cheers,

                      
Igor

                      
 

                      
*From:*Per Hedeland

                      
 

                      
*To:*Xufeng Liu,

                      
 

                      
*Cc:*netconf@ietf.org,'NetMod WG',

                      
 

                      
*Date:*2017-10-08 14:01:27

                      
 

                      
*Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by

                      
*leafref

                      
 

                      
 

                      
 

                      
On 2017-10-06 23:11, Xufeng Liu wrote:

                      

                        
During the design team discussion for TE and MPLS YANG modeling,

                      

                    

                  

                

              

            

            
we

            

              

                

                  

                    

                      

                        
have received a request from implementers: How to minimize the

                      

                    

                  

                

              

            

            
number

            

              

                

                  

                    

                      

                        
of NETCONF/RESTCONF RPCs to improve operation efficiency?

                        
Especially for the case when the operator or client software

                      

                    

                  

                

              

            

            
needs to

            

              

                

                  

                    

                      

                        
retrieve the object contents pointed by a leafref.

                        
 

                        
For example, given the following simplified TE tunnel model,

                        
 

                        
+--rw te

                        
 

                        
       +--rw explicit-paths

                        
 

                        
       |  +--rw explicit-path* [name]

                        
 

                        
       |     +--rw name                      string

                        
 

                        
       |        +--rw explicit-route-object* [index]

                        
 

                        
       |           +--rw index                   uint32

                        
 

                        
       |           +--rw explicit-route-usage?   identityref

                        
 

                        
       +--rw tunnels

                        
 

                        
       |  +--rw tunnel* [name]

                        
 

                        
       |  |  +--rw name                   string

                        
 

                        
       |  |  +--rw paths

                        
 

                        
       |  |  |  +--rw path* [name]

                        
 

                        
|  |  |     +--rw explicit-path?  ->

                        
|  |  |     ../../../../../explicit-paths/explicit-path/name

                        
 

                        
when the client tries to retrieve a tunnels information based on

                      

                    

                  

                

              

            

            
the

            

              

                

                  

                    

                      

                        
tunnel name, the get operation returns a list of leafrefs

                      

                    

                  

                

              

            

            
pointing

            

              

                

                  

                    

                      

                        
to the paths of the tunnel.

                      

                      
Sorry, I'm afraid I don't follow. Can you explain exactly what

                    

                  

                

              

            

            
your

            

              

                

                  

                    

                      
"get" request is (protocol and payload), and where the "list of

                      
leafref's" (whatever that may be) occurs in the reply?

                      
 

                      
*/[Xufeng] The get operation is the NETCONF/RESTCON <get>

                    

                  

                

              

            

            
protocol

            

              

                

                  

                    

                      
*operation, or the <get-data> operation described in

                      
*https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the

                    

                  

                

              

            

            
GET

            

              

                

                  

                    

                      
*operations

                      
on {+restconf}/ds/<datastore> described in

                      
https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./*

                      
 

                      
*/ /*

                      
 

                      
*/We have a list of leafref values because in this example model,

                    

                  

                

              

            

            
each

            

              

                

                  

                    

                      
*tunnel contains a list of paths, each of them contains a leafref.

                    

                  

                

              

            

            
The

            

              

                

                  

                    

                      
*get returns a value for each instance of such a leafref,

                      
which (as a string value) will be used as a constraint (foreign

                    

                  

                

              

            

            
key)

            

              

                

                  

                    

                      
to retrieve the instance of an explicit-path in the model above./*

                      
 

                      
 

                      
 

                      
JFYI, in case there is some fundamental misunderstanding here: a

                    

                  

                

              

            

            
leaf

            

              

                

                  

                    

                      
of

                      
type leafref has a single value - *one* of those that satisfy the

                      
leafref

                      
constraint, in case there are multiple "candidates".

                      
 

                      
--Per

                      
 

                      

                        
The client needs to issue at

                        
least one more get operation to retrieve the path information

                      

                    

                  

                

              

            

            
about

            

              

                

                  

                    

                      

                        
the given tunnel. The request is to combine these two operations

                      

                    

                  

                

              

            

            
into

            

              

                

                  

                    

                      

                        
one.

                        
 

                        
In the RDBMS SQL world, join can be used when SQL select is

                        
performed, but NETCONF/YANG currently does not have this

                      

                    

                  

                

              

            

            
capability.

            

              

                

                  

                    

                      

                        
 

                        
Wed like to ask whether such a request is considered reasonable.

                        
 

                        
If the request is reasonable, the next question is how to

                        
proceed. This seems to be a protocol issue rather than YANG

                      

                    

                  

                

              

            

            
modeling

            

              

                

                  

                    

                      

                        
issue. Is it acceptable to add a new operation to achieve such a

                        
<get-data> operation with expanded leafrefs?

                        
 

                        
Comments and suggestions are appreciated.

                        
 

                        
Thanks,

                        
 

                        
- Xufeng

                        
 

                        
 

                        
 

                        
_______________________________________________

                        
netmod mailing list

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

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

                        
 

                      

                      
_______________________________________________

                      
Netconf mailing list

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

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

                      
 

                    

                    
_______________________________________________

                    
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

              
.

              
 

            

            
 

            
 

            
 

            
 

            
------------------------------------------------------------------------

            
--------

            
 

            
 

            

              
_______________________________________________

              
netmod mailing list

              
netmod@ietf.org

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

              
 

            

            
 

            
.

            
 

          

          
 

        

      

    

    

  


--------------BA72A262AE0C3477D4AAECF1--


From nobody Thu Oct 12 07:31:11 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD23134501 for ; Thu, 12 Oct 2017 07:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 a6b24cvbL8rt for ; Thu, 12 Oct 2017 07:31:02 -0700 (PDT)
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 DE0F413432D for ; Thu, 12 Oct 2017 07:31:02 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 566ED215DCD for ; Thu, 12 Oct 2017 08:31:01 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id LeWx1w00j2SSUrH01eX0lh; Thu, 12 Oct 2017 08:31:01 -0600
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=OUXY8nFuAAAA:8 a=AUd_NHdVAAAA:8 a=RpNjiQI2AAAA:8 a=48vgC7mUAAAA:8 a=fgQY2a2vf2jjLDN9BBkA:9 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=QEXdDO2ut3YA:10 a=cAcMbU7R10T-QSRYIcO_:22 a=vJuR_VyAocOa-HWBgGQO: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:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=71WT5/Zs5TX7HlSONaMcQ8j8KlphJwZD4ixrUM3rHJU=; b=1cX7damq7alJ74BHKtbYLqauhd ZK9OE6pC7GjETqBONkt+t/19RluF8+74HSw6LpSdRxWeDJoRCbqrzQlCkB8VZ5CKes4Rt7ygLykb6 jMNypaYLlqCeWyxFYqUraezV/;
Received: from [172.58.184.22] (port=30369 helo=[IPV6:2607:fb90:644a:40a7:0:4d:7e34:b301]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e2eVl-002D4D-Aq; Thu, 12 Oct 2017 08:30:57 -0600
From: Lou Berger 
To: Kent Watsen , Martin Bjorklund , 
CC: , 
Date: Thu, 12 Oct 2017 10:30:55 -0400
Message-ID: <15f10fecd18.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <424B35F1-CA91-44B7-902C-478AFD16008B@juniper.net>
References: <4ad101fa-97b7-4cbe-331c-0697feae797b@cisco.com> <16eda4e4-5612-918c-9d06-eec39f67e88a@cisco.com>  <20171010.121338.957274767620281285.mbj@tail-f.com> <424B35F1-CA91-44B7-902C-478AFD16008B@juniper.net>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.58.184.22
X-Exim-ID: 1e2eVl-002D4D-Aq
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:644a:40a7:0:4d:7e34:b301]) [172.58.184.22]:30369
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] [Rtg-dt-yang-arch] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Oct 2017 14:31:11 -0000

As it was unclear if/that Kent was stating a position as chair: it looks 
like the consensus position of the working group is that we should keep the 
old name and mark nodes that are no longer needed due to nmda as obsolete.

Lou
As co-chair


On October 11, 2017 10:26:29 AM Kent Watsen  wrote:

> I agree - let's keep the module name and mark the nodes obsolete.
>
> Kent // any hat
>
>
>
> Robert Wilton  wrote:
>>
>>
>> On 09/10/2017 22:06, Benoit Claise wrote:
>> > On 10/6/2017 6:01 PM, Robert Wilton wrote:
>> >>
>> >>
>> >> On 06/10/2017 16:32, Martin Bjorklund wrote:
>> >>> Benoit Claise  wrote:
>> >>>> Dear all,
>> >>>>
>> >>>> [including the routing and multicast YANG design teams]
>> >>>> Can we please finalize the discussion regarding ietf-routing versus
>> >>>> ietf-routing-2, sooner than later.
>> >>>>
>> >>>> I care about the NMDA transition strategy.
>> >>>>
>> >>>> Here are all the ietf-routing dependent YANG modules (those modules
>> >>>> that depend on ietf-routing)
>> >>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Drouting-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=PEvVi2dNF5_gICJ7X97iuctNaAyUV5Pgnsr2LiDLFEA&e=
>> >>>> So many YANG modules.
>> >>>>
>> >>>> Look at the difference for ietf-routing-2:
>> >>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Drouting-2D2-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=ISgVe_scuCOokfsF8C62oeiGhfTWMjlAXiS7bnS4cpc&e=
>> >>>> Some dependent modules are compliant with ietf-routing-2, the
>> >>>> multicast YANG modules, but these are the only ones.
>> >>>>
>> >>>> Changing the module name from ietf-routing to ietf-routing-2 implies
>> >>>> that the we have to warn all draft authors of ietf-routing YANG
>> >>>> dependent modules:
>> >>>> Â Â Â Â  1. to make sure they are aware of ietf-routing-2 (publishing a
>> >>>> RFC8022bis mentioning in the module description that this module is
>> >>>> not compatible with the NMDA architecture, and providing a pointer to
>> >>>> ietf-routing-2 ... is not an automatic way... so barely useful)
>> >>>> Â Â Â Â  2. to ask them to change their import to ietf-routing-2
>> >>>> Hopefully, in the routing case, it's mainly the IETF.
>> >>>> I'm glad that we didn't change the ietf-interfaces to
>> >>>> ietf-interfaces-2, we would have to deal with cross
>> >>>> SDO/consortia/opensource project issues
>> >>>> Note:
>> >>>>
>> >>>> Â Â Â  we're in a transition phase today, while we implement the
>> >>>> Â Â Â  soon-to-be-published draft-clacla-netmod-model-catalog-02
>> >>>> Â Â Â  Because of this, the SDO/consortia/opensource dependent YANG
>> >>>> modules
>> >>>> Â Â Â  will only appear in the Impact Analysis tomorrow at
>> >>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Dinterfaces-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=V7trpGHuvRSOwmb0ppL7GoztsKSUJI3yWJ-jxeSHTXs&e=
>> >>>> Â Â Â  In the mean time, you can see all these dependent modules
>> >>>> Â Â Â  Ex:
>> >>>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_module-5Fdetails.php-3Fmodule-3Dietf-2Dinterfaces&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=euRn2n-i8nQZX5Y-ZieREslwccv7DJBS6L8jlNBA3TM&e=
>> >>>> Â Â Â Â  Â Â Â  Â Â Â  => click on "dependents"
>> >>>> Â Â Â  Those dependent modules is a new feature of
>> >>>> Â Â Â  draft-clacla-netmod-model-catalog-02
>> >>>>
>> >>>>
>> >>>> I'm wondering if this NMDA transition hurdle doesn't make a good
>> >>>> justification to keep the same module name!
>> >>>> We could debate whether ietf-routing is implemented or not, but the
>> >>>> point is moot: we don't know what we don't know.
>> >>> Agreed.  I think there are no real reasons for keeping the module name
>> >>> and deprecate the old defintiions.  Yes, it adds some noise to the
>> >>> module but the fact is that we do deprecate all these defintions, and
>> >>> I think we should not hide that.
>> >> This is also my preferred option.
>> >>
>> >> I would like to just deprecate these nodes now, and then (for the
>> >> routing module that is unlikely to have been widely implement) update
>> >> it again in a 1-2 years time to remove the deprecated nodes (we can
>> >> warn now that they will get removed).
>> > According to Acee, there is one ietf-routing implementation (based on
>> > an old draft version). If the point is that we don't want ietf-routing
>> > implementations to implement "deprecated" leaves, can we "obsolete"
>> > them now.
>> > RFC 7950:
>> >
>> >     7.21.2. The "status" Statement
>> >
>> >         The "status" statement takes as an argument one of the strings
>> >         "current", "deprecated", or "obsolete".
>> >
>> >         o  "current" means that the definition is current and valid.
>> >
>> >         o  "deprecated" indicates an obsolete definition, but it permits
>> >            new/continued implementation in order to foster interoperability
>> >            with older/existing implementations.
>> >
>> >         o "obsolete" means that the definition is obsolete and SHOULD NOT be
>> >            implemented and/or can be removed from implementations.
>> >
>> > Advantages:
>> > Â Â Â  - we keep the same ietf-routing YANG module names
>> > Â Â Â  - new implementations don't implement the "obsolete" parts.
>>
>> For 8022bis, I would also support keeping the existing module name,
>> and moving the existing state leaves directly to obsolete.  This is
>> with the justification that this draft has only recently been
>> published, and we do not expect there to be many implementations yet.
>
> This is fine with me as well.
>
>> For RFC 7223, I think that the state leaves should move to deprecated
>> then obsolete in a later revision, because the model is much older and
>> hence likely to be much more established.
>
> Agreed.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw&s=z1FXjDcWCxsDTbtcLAATaD4vb3tJHL5GhZ8ufDlZLIw&e=
>
>
> _______________________________________________
> Rtg-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch



From nobody Thu Oct 12 18:30:38 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F98134580; Thu, 12 Oct 2017 18:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsSzD0i66Bxe; Thu, 12 Oct 2017 18:30:31 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93531344C5; Thu, 12 Oct 2017 18:30:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXP03103; Fri, 13 Oct 2017 01:30:29 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 13 Oct 2017 02:30:28 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.199]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 13 Oct 2017 09:30:23 +0800
From: Qin Wu 
To: Juergen Schoenwaelder , "Robert Wilton" 
CC: Lou Berger , NetMod WG , "rtg-dir@ietf.org" , "draft-wu-l3sm-rfc8049bis.all@ietf.org" 
Thread-Topic: [netmod] handling module incompatibility
Thread-Index: AQHTPqafiD0PunpOs0S5Nqqj+UPebKLWYU8AgAAinACACoL7wA==
Date: Fri, 13 Oct 2017 01:30:24 +0000
Message-ID: 
References:   <20171006165342.syfqsjsdmr2tzgqg@elstar.local>
In-Reply-To: <20171006165342.syfqsjsdmr2tzgqg@elstar.local>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.79.163]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.59E01735.004A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: bd91f92fe245fa5929827f007e35e729
Archived-At: 
Subject: Re: [netmod] handling module incompatibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Oct 2017 01:30:33 -0000

VGhhbmsgTG91IHRvIGhlbHAgYnJpbmcgdXAgdGhpcyBpc3N1ZSwgdGhhbmsgUm9iZXJ0LCBKdWVy
Z2VuLCBUb20sIEtlbnQgdG8gc2hhcmUgeW91ciB2YWx1YWJsZSB0aG91Z2h0cy4NCkp1cmdlbiwg
d2Ugd2lsbCBhZGRyZXNzIHlvdXIgY29uY2VybiBpbiB2LSgwNykgYmFzZWQgb24geW91ciBpbnB1
dCBhbmQgb3RoZXJzJyBmZWVkYmFjay4NCk1hbnkgdGhhbmtzLg0KDQotUWluDQotLS0tLemCruS7
tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmou
c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gDQrlj5HpgIHml7bpl7Q6IDIwMTfl
ubQxMOaciDfml6UgMDo1NA0K5pS25Lu25Lq6OiBSb2JlcnQgV2lsdG9uDQrmioTpgIE6IExvdSBC
ZXJnZXI7IE5ldE1vZCBXRzsgcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQtd3UtbDNzbS1yZmM4MDQ5
YmlzLmFsbEBpZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0gaGFuZGxpbmcgbW9kdWxlIGlu
Y29tcGF0aWJpbGl0eQ0KDQpPbiBGcmksIE9jdCAwNiwgMjAxNyBhdCAwMzo0OTo1MFBNICswMTAw
LCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0KPiBIaSwNCj4gDQo+IE9uIDA2LzEwLzIwMTcgMTQ6MjUs
IExvdSBCZXJnZXIgd3JvdGU6DQo+ID4gSGksDQo+ID4gDQo+ID4gIMKgwqDCoCBBcyBwYXJ0IG9m
IHRoZSBteSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlldyBvZiANCj4gPiBkcmFmdC13dS1sM3Nt
LXJmYzgwNDliaXMgSSBub3RlZCB0aGF0IHRoZXJlIHdlcmUgc2V2ZXJhbCANCj4gPiBpbmNvbXBh
dGlibGUgY2hhbmdlcyBiZWluZyBtYWRlIHRvIHRoZSBpZXRmLWwzdnBuLXN2YyBtb2R1bGUgd2l0
aG91dCANCj4gPiBjaGFuZ2luZyB0aGUgbmFtZS7CoCBJIHJhaXNlZCB0aGlzIHdpdGggdGhlIFlB
TkcgZG9jdG9ycyBhbmQgb3RoZXJzIA0KPiA+IGludm9sdmVkIHdpdGggdGhlIGRyYWZ0IGFuZCBp
dCBzdXJmYWNlZCBzb21lIHRvcGljcyB3aGljaCByZWFsbHkgDQo+ID4gc2hvdWxkIGJlIGRpc2N1
c3NlZCBoZXJlIGluIE5ldE1vZC4NCj4gPiANCj4gPiBUaGUgYmFja2dyb3VuZCAoYXMgZXhwbGFp
bmVkIG9mZi1saXN0IGJ5IG90aGVycywgc28gSSBob3BlIEkgaGF2ZSBpdA0KPiA+IHJpZ2h0KcKg
IGlzIHRoYXQgb25lIG9mIHRoZSBZQU5HIERvY3RvcnMgbm90ZWQgdGhhdCBSRkM4MDQ5IHdhcyAN
Cj4gPiBicm9rZW4gYW5kIGNvdWxkIG5vdCBiZSBpbXBsZW1lbnRlZCBhcyBkZWZpbmVkLCBhbmQg
dGhlcmVmb3JlIGEgZml4IA0KPiA+IHdhcyBuZWVkZWQuwqAgTDNTTSBoYXMgY29uY2x1ZGVkIHNv
IHRoZSBmaXggaXMgaW4gdGhlIGluZGl2aWR1YWwgDQo+ID4gZHJhZnQgZHJhZnQtd3UtbDNzbS1y
ZmM4MDQ5YmlzLsKgIFNpbmNlIHRoZSByZmM4MDQ5IHZlcnNpb24gb2YgDQo+ID4gaWV0Zi1sM3Zw
bi1zdmMgbW9kdWxlIGNvdWxkIG5vdCBiZSBpbXBsZW1lbnRlZCwgdGhlIGZlZWxpbmcgYnkgdGhl
IA0KPiA+IFlBTkcgRHIgd2FzIHRoYXQgZXZlbiB0aG91Z2ggdGhlIG5ldyBtb2R1bGUgaXMgaW5j
b21wYXRpYmxlIHdpdGggdGhlIA0KPiA+IG9yaWdpbmFsIGRlZmluaXRpb24gdGhlIG1vZHVsZSB0
aGUgcnVsZSBkZWZpbmVkIGluIFNlY3Rpb24gMTEgb2YgDQo+ID4gWUFORyAxLjEgKG9yIHNlY3Rp
b24gMTAgb2YgUkZDIDYwMjApIGRpZG4ndCBoYXZlIHRvIGJlIGZvbGxvd2VkIGFuZCB0aGUgc2Ft
ZSBuYW1lIGNvdWxkIGJlIHVzZWQuDQo+IA0KPiBJIHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgdmll
dyB0aGF0IEkgc3VwcG9ydCBhcyB3ZWxsLsKgIElmIHNvbWV0aGluZyBpcyANCj4gY2xlYXJseSBi
cm9rZW4gdGhlbiBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gZml4IGl0IHdpdGhvdXQgcmVxdWly
aW5nIA0KPiBhIG5ldyBtb2R1bGUgbmFtZSwganVzdCBhbiB1cGRhdGVkIHJldmlzaW9uLg0KPg0K
DQpUaGUgaGlkZGVuIHF1ZXN0aW9uIGlzIHdoYXQgaXMgJ2Jyb2tlbicgb3IgJ2NsZWFybHkgYnJv
a2VuJyBhbmQgd2hlbiBhcmUgZGVmaW5pdGlvbnMgaW4gYSBtb2R1bGUgYnJva2VuIGFuZCB3aGVu
IGlzIHRoZSBkYW1hZ2Ugc28gYmlnIHRoYXQgdGhlIHdob2xlIG1vZHVsZSBpcyBicm9rZW4uIERv
ZXMgYSBicm9rZW4geHBhdGggc3RhdGVtZW50IGNhdXNlIHRoZSB3aG9sZSBtb2R1bGUgdG8gYmUg
ZnVuZGFtZW50YWxseSBmbGF3ZWQgc3VjaCB0aGF0IGFuIGltcGxlbWVudGF0aW9uIG9mIHRoZSBy
ZXN0IGlzIGltcG9zc2libGU/DQoNCkl0IGlzIG5vdCB1bmNvbW1vbiB0byBmaW5kIGVycm9ycyBp
biBkYXRhIG1vZGVscyBhbmQgaXQgaXMgdGhlbiBvZnRlbiBhIG1hdHRlciBvZiBhIG5ldyByZXZp
c2lvbiBvciBlcnJhdGEgdG8gYWRkcmVzcyB0aG9zZS4gVGhlIHF1ZXN0aW9uIGhlcmUgaXMgd2hl
biBpcyBhbiBlbnRpcmUgbW9kdWxlIGJyb2tlbiB1cCB0byB0aGUgcG9pbnQgdGhhdCBub2JvZHkg
ZXZlciB3aWxsIGhhdmUgaW1wbGVtZW50ZWQgaXQgb3IgcGFydHMgb2YgaXQuDQoNCkkgZG8gbm90
IGtub3cgdGhlIGFuc3dlciBidXQgSSBzZWUgYSBjZXJ0YWluIHJpc2sgdGhhdCBtaW5vciBidWdz
IHdpbGwgYmUgdXNlZCB0byBhcmd1ZSBub25lIG9mIHRoZSBZQU5HIHVwZGF0ZSBydWxlcyBhcHBs
eS4NCg0KL2pzDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMg
VW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg
Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIw
MCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K


From nobody Fri Oct 13 07:16:11 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7F313295C for ; Fri, 13 Oct 2017 07:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level: 
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1ySdmOK6_Vd for ; Fri, 13 Oct 2017 07:16:08 -0700 (PDT)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 8D0BE1320C9 for ; Fri, 13 Oct 2017 07:16:08 -0700 (PDT)
Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 331F9175B81 for ; Fri, 13 Oct 2017 08:16:08 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id M2G51w00M2SSUrH012G8gG; Fri, 13 Oct 2017 08:16:08 -0600
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=AhxskLKyXD6wq1Zb0SkA: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:References:Cc: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=qlO7WgNVVln/Uz8qyAWyXXgW/pLfiX2aQ72hjHlZ20Q=; b=gqgW1yFQwxzLu1lJFwAIKfU7wQ 7linUOPhCxFH+X0MBGTgmI236WdwaXS95vqCQ6TI+sAvkmbDORZafK+J5nucMt8WNniYvaJPCvo0o M81CIt4bxuUyp/h8rMalgW7lU;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:33534 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e30ku-0023qr-Vf; Fri, 13 Oct 2017 08:16:05 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
References: <9b125d33-1413-00e5-04c2-408a154745e4@labn.net> <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
Message-ID: <945e2b04-9e0d-2bd8-40a8-86e7f7f58342@labn.net>
Date: Fri, 13 Oct 2017 10:16:03 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: 1e30ku-0023qr-Vf
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]:33534
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-rfc7277bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Oct 2017 14:16:10 -0000

All,

This polls is closed (on 10/2).  Authors, please republish the draft as
draft-ietf-netmod-rfc7277bis-00 with the only change being the date and
draft 'filename'.

Thank you,

Lou (and Kent)

On 9/18/2017 3:47 PM, Lou Berger wrote:
> The draft being polled in this thread is
> draft-bjorklund-netmod-rfc7277bis-00
>
> Lou
>
> On 9/18/2017 3:15 PM, Lou Berger wrote:
>> All,
>>
>> This is start of a two week poll on making
>> draft-bjorklund-netmod-rfc7227bis-00 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.
>>
>> The poll ends Oct 2.
>>
>> Thanks,
>>
>> Lou (and Kent)
>>
>> _______________________________________________
>> 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 Oct 13 07:16:41 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE81B13295C for ; Fri, 13 Oct 2017 07:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5drcesG3Mi2B for ; Fri, 13 Oct 2017 07:16:34 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 C34611320C9 for ; Fri, 13 Oct 2017 07:16:33 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id ADE381E0F56 for ; Fri, 13 Oct 2017 08:13:51 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id M2Dn1w0172SSUrH012DqhT; Fri, 13 Oct 2017 08:13:51 -0600
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=I251l077QEUY1vJds0EA: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: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=qYOE0dUCgRTZZXkaKViyHl3l2pzUnax9jYjDtMdwEgc=; b=Bsyo0J99NgOfvg2pK/M26QajlY 0UQPlNWn4oyEiLOxy/KUMs8IYafzKY278FRTvdDPk82L2m5VHbzHq1Helj/ADN86jw7I67NFEMBlt OLBlMTDxI9Xth5xigtbT+t/Fj;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:33456 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e30ih-0023PW-N0; Fri, 13 Oct 2017 08:13:47 -0600
To: NetMod WG 
Cc: NetMod WG Chairs 
References: 
From: Lou Berger 
Message-ID: <429c717e-12a2-f13b-1746-f59881266c84@labn.net>
Date: Fri, 13 Oct 2017 10:13:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1e30ih-0023PW-N0
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]:33456
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Oct 2017 14:16:40 -0000

All,

This polls is closed (on 10/2).  Authors, please republish the draft as
draft-ietf-netmod-rfc7223bis-00 with the only change being the date and
draft 'filename'.

Thank you,

Lou (and Kent)


On 9/18/2017 10:33 AM, Lou Berger wrote:
> All,
> 
> This is start of a two week poll on making
> draft-bjorklund-netmod-rfc7223bis-00 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.
> 
> The poll ends Oct 2.
> 
> Thanks,
> 
> Lou (and Kent)
> 


From nobody Fri Oct 13 07:37:50 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A22120720 for ; Fri, 13 Oct 2017 07:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 eomGsz1QYOtQ for ; Fri, 13 Oct 2017 07:37:47 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0117.outbound.protection.outlook.com [104.47.41.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93E31323F7 for ; Fri, 13 Oct 2017 07:37:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EvnrXxQSqyuPK5WIR/Q7dr2Mzs266CgxGk56FdwT5rE=; b=dHxBnfTEbBJReHtTJ4f+z2pyc7Hi3Q18mVjLXSHUW635JptOBipnRpPnaOCJ0HKBfEZn4fVwjza7ZsygAbvjeWAlnjDf2f0iOdlkbdgl5yRH3aTH58G8eI/iZxT6njzBjywLAY3pctJGx+VzSTnTlbEkUO16BnEBV3mm3LXfyJI=
Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB279.namprd05.prod.outlook.com (10.141.64.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 13 Oct 2017 14:37:30 +0000
Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497%14]) with mapi id 15.20.0077.021; Fri, 13 Oct 2017 14:37:29 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: WG adoption poll draft-acee-netmod-rfc8022bis-03
Thread-Index: AQHTRDDL6dfZtzUXzkCdAPj9I2Iarg==
Date: Fri, 13 Oct 2017 14:37:29 +0000
Message-ID: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN1PR05MB279; 6:Km6yREf9uzrhJa2V8xhn6l6zWEuYsAeA0KKn2dAZF/fSqeFb5F9mFlgRTBjSefcsV7oIZtwAGu1Aq8WVsa1nZ5mKbvPQ1TP1OBNRhtfNvE60XNah1dKufnyRX99PVZq/XGw6N7YJHGiAI99uez3YFkPhDnZ60NjMoGFpwyqhSz49/25uF+s2n094PKEtdcpcgrQmnPjJvY+hNsmKoI/nu2JO6TqGgihOWSpvqr3tWp9QXYgwlNXzH2nVm9fWYuyOPuLbNiwFeuN0uGlIGIry5wP2vDnF2BkhFi9wnjaOwm0f3q+cMV2saFTeYqk+KMQu7XrVLRIDI2EeGRdTV5ZbmA==; 5:fWWc6aTUNud00PBjxCNCVw0gEiXZTrHPmA7k9PRXqt7Bjy/k13caD/IzcBqg5ScVH5xYPVnIJON7/QraaZL8zq1KL/lU78cTA8C/LBKL69TFKUKDfDrZhCHtx1N6LtPZ4a8HBUWJNT2eUaaZEem0wpYpBFM+gljKVQfzSVl6bTE=; 24:7/p2f3eTbEgaINu4fAk14vtvXzTvb6wJxBPUGG60J7eiumf67XUnRwCygmuKBKlrceT7pGFMtZvv1DCcRqGtMA2CxkXt+FdUAcYAGqRUusM=; 7:N/en75S7Q09kBbmAhfw8LOYiy87/LxWJTX8ePPEqwpSmxwqIJuaaglYECHLCNati3ITNBT1DeXt4N4EDGS0wmVBU+shUslIeRiCuZTl7l3KUWgWuYbRIZZnygM3jycIiEyZ07gmBqgw03Xrt9YBcniVmXoFnkSmzi08CKYwpBIvci2dKav8AREn1vpQc1OjM3MCxZDCEef7qQ4Pb4pSVB91oDfbMgBN8vBpQysWnPq4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ce688b35-42c8-4816-b70c-08d51247ee8f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BN1PR05MB279; 
x-ms-traffictypediagnostic: BN1PR05MB279:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB279; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB279; 
x-forefront-prvs: 04599F3534
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(189002)(199003)(316002)(478600001)(105586002)(106356001)(58126008)(5660300001)(189998001)(14454004)(83716003)(36756003)(6486002)(6506006)(5640700003)(68736007)(6916009)(83506001)(81166006)(3846002)(53936002)(8936002)(3280700002)(3660700001)(50986999)(54356999)(6512007)(99286003)(86362001)(82746002)(2351001)(2900100001)(6116002)(66066001)(97736004)(25786009)(7736002)(2906002)(1730700003)(102836003)(8676002)(101416001)(6436002)(2501003)(5250100002)(33656002)(305945005)(230783001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB279; H:BN1PR05MB280.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <57A93A53F021B541A4AE8EFC748FA50C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 14:37:29.4198 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB279
Archived-At: 
Subject: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Oct 2017 14:37:48 -0000

QWxsLA0KDQpOb3cgdGhhdCB3ZSBoYXZlIHJlc29sdmVkIHRoZSBtb2R1bGUgbmFtaW5nIGlzc3Vl
IG9uIHRoZSBsaXN0IChpLmUuIA0KdGhhdCBrZWVwcyB0aGUgb3JpZ2luYWwgcmZjIG1vZHVsZSBu
YW1lcyBhbmQgdXBkYXRlcyB0aGUgdW53YW50ZWQNCmxlZ2FjeSBub2RlcyB0byBoYXZlIHN0YXR1
cyAnb2Jzb2xldGUnKSwgcmF0aGVyIHRoYW4gd2FpdCBmb3IgdGhlDQpjaGFuZ2VzIHRvIGJlIG1h
ZGUgaW4gdGhlIGluZGl2aWR1YWwgZG9jdW1lbnQsIHdlJ2QgbGlrZSB0byBtb3ZlDQphaGVhZCB3
aXRoIHRoZSBhZG9wdGlvbiBub3csIHdpdGggdGhlIHVuZGVyc3RhbmRpbmcgdGhhdCB0aGVzZSAN
CmNoYW5nZXMgd2lsbCBiZSBtYWRlIGluIHRoZSAtMDEgdmVyc2lvbiBvZiB0aGUgYWRvcHRlZCBk
cmFmdC4NCg0KVGhpcyBpcyBzdGFydCBvZiBhIHR3by13ZWVrIHBvbGwgb24gbWFraW5nIGRyYWZ0
LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDMNCmEgd29ya2luZyBncm91cCBkb2N1bWVudC4gIFBs
ZWFzZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgDQoieWVzL3N1cHBvcnQiIG9y
ICJuby9kbyBub3Qgc3VwcG9ydCIuICBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUNCnlv
dXIgcmVzZXJ2YXRpb25zIHdpdGggdGhlIGRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBm
ZWVsIGZyZWUgdG8NCnByb3ZpZGUgY29tbWVudHMgeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2Vk
IG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cNCmRvY3VtZW50Lg0KDQpUaGUgcG9sbCBlbmRzIE9j
dCAyNy4NCg0KVGhhbmtzLA0KS2VudCAoYW5kIExvdSkNCg0K


From nobody Fri Oct 13 07:50:09 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8213307E; Fri, 13 Oct 2017 07:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 r3uLaFnopZ1P; Fri, 13 Oct 2017 07:50:05 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0116.outbound.protection.outlook.com [104.47.40.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3254413306C; Fri, 13 Oct 2017 07:50:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9zM3AX6Hx5D61Dh7SMOSQHGxM5B3Yp5+MftHjTBFEoI=; b=GgLpxF8Ysr82hSq4/F4TgVrU8s+kq2PHQ/KDbheZFg1scnqA1c6i8ZOFs9rZahfpfQP0/7Ul6/icl6hPWZ14ZrpVbORy1vFKm63k6nm7z/W1GPR022gK+QufhUY7wXK/GRWVCNTMwMNt5ceebNNp4nkm5Im05T/kOpHPyHkpGHY=
Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB278.namprd05.prod.outlook.com (10.141.64.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 13 Oct 2017 14:50:02 +0000
Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497%14]) with mapi id 15.20.0077.021; Fri, 13 Oct 2017 14:50:02 +0000
From: Kent Watsen 
To: "netmod@ietf.org" , "netconf@ietf.org" 
Thread-Topic: Liaison letter to IETF Netmod Working Group regarding NMDA modelling
Thread-Index: AdM0mm7JlYR6uPB3Qnifv6k3TIV3XgPdpYKA
Date: Fri, 13 Oct 2017 14:50:02 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
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; BN1PR05MB278; 6:NPJv95lbNR5Rq6fdGi1vCL7mBeXFW1c+25FsAnSzgEjLXOay03PhyThAINj1McYVDha08FT3RwZxoht9E0IBAGao2NKlyPGrqEIYxqM+0wuZ0zNjf/T4H9+3MbSbYDelI0WKclKGMRRMYyq5Afv+mUbK9pw+ca3+gKVTFpA4VIlnOei3PXvNGVqWfd9vRAuqOtsXvXux5s9TCy2EX8DZFb1rp3KlgHwYevIgeKL+tjqz8UNH4P84OClFdPn2eeNS45CC5sHB183qKTzRlfAMCQ2ccOi6kePL58OwoI0dDZfGX7DQAE+dB0EwXFF2ZQeCF3s1jij8YYGz8XMJbx0YiQ==; 5:NORQcFuOdpIzZjhT060R0/ph7DPuOXUhwT1teeFmfg7jBVcKiEi7G67lw4P+RtuP3cVMjY9kxz1kX5bD+QgiEEwyvt3yl8LyVdrXiFTYB1H73l2GAJcGWngX7mx8qsRYOumGzMqSHMjQe7+oydGTyw==; 24:q3VPR2GseD0QhxQwYcTZbyhIDjEabD9pk6pOzL/McxPW7ANmHo8D0isF9tcrVTDwiuVgbIZPHTJvED4aMzkhlw0yzoDrJkpuwqgUoQyfPHI=; 7:OKNxCtueyH1jcUKsmy9zLbIGOvE7F0pUUfE4jSXQ3jp/ZD0qhyYs5tF8d84SFqdmZCD2BkSNzEYxvizW7NBfAr9fxk3gWv1fUpKE7VNFxYYjWTscwUkGBmmNUfk6RGY/Ou6E/8JGQZ7eUc4D+CLErqgFIy63mAd7ctFgFBGGWmkSxDeSg3wVWRJXFqQO4kPZKVUiNHJD8ZO2qw8UT8uxm2S0vH5jadMWHVzzUqMa9Vo=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: bbbf3949-3115-4c3e-c57e-08d51249af29
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075); SRVR:BN1PR05MB278; 
x-ms-traffictypediagnostic: BN1PR05MB278:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB278; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB278; 
x-forefront-prvs: 04599F3534
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(199003)(189002)(97736004)(5890100001)(2501003)(25786009)(36756003)(14454004)(5250100002)(6486002)(83506001)(83716003)(102836003)(6436002)(229853002)(3846002)(2473003)(99286003)(53936002)(6512007)(450100002)(82746002)(6116002)(66066001)(6506006)(5660300001)(189998001)(3280700002)(76176999)(478600001)(33656002)(8676002)(50986999)(54356999)(305945005)(99936001)(2950100002)(8936002)(7736002)(86362001)(316002)(2900100001)(106356001)(2906002)(81156014)(58126008)(110136005)(101416001)(105586002)(3660700001)(68736007)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB278; H:BN1PR05MB280.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_002_D85FFC1A190B4A0BB5E43779D1871FDDjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 14:50:02.2518 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB278
Archived-At: 
Subject: [netmod] FW: Liaison letter to IETF Netmod Working Group regarding NMDA modelling
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Oct 2017 14:50:07 -0000

--_002_D85FFC1A190B4A0BB5E43779D1871FDDjunipernet_
Content-Type: text/plain; charset="utf-8"
Content-ID: <3C7434C2E907C341A05F9B96FA50A089@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

QWxsLA0KDQpXZSByZWNlaXZlZCB0aGlzIGxpYWlzb24gYSBjb3VwbGUgd2Vla3MgYWdvLiAgQWx0
aG91Z2ggaXQgaGFzIG5vdA0KeWV0IGJlZW4gZm9ybWFsbHkgc3VibWl0dGVkLCB3ZSBsaWtlIHRv
IHByb3ZpZGUgYSByZXNwb25zZSBhbnl3YXkuDQpBcyB0aGlzIHJlcXVlc3QgZXF1YWxseSBpbXBh
Y3RzIGJvdGggdGhlIE5FVE1PRCBhbmQgTkVUQ09ORiB3b3JraW5nIA0KZ3JvdXBzLCB3ZSByZXF1
ZXN0IHRoYXQgdGhhdCBib3RoIHdvcmtpbmcgZ3JvdXBzIGNvbGxhYm9yYXRlIG9uDQphIHJlc3Bv
bnNlLg0KDQpUaGFua3MsDQpLZW50IChhbmQgTG91IGFuZCBNYWhlc2gpDQoNCi0tDQoNCkRlYXIg
S2VudCwgTG91LCBCZW5vaXQsIGFuZCBaaXRhbywNCg0KUGxlYXNlIGZpbmQgYXR0YWNoZWQgYSBs
aWFpc29uIGxldHRlciBmcm9tIElFRUUgODAyLjMgdG8gdGhlIElFVEYgTmV0bW9kIFdvcmtpbmcg
R3JvdXAgcmVnYXJkaW5nIE5NREEgbW9kZWxsaW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQogIERhdmlk
DQoNCg0K

--_002_D85FFC1A190B4A0BB5E43779D1871FDDjunipernet_
Content-Type: application/pdf; name="IEEE_802d3_to_IETF_Netmod_0917.pdf"
Content-Description: IEEE_802d3_to_IETF_Netmod_0917.pdf
Content-Disposition: attachment;
	filename="IEEE_802d3_to_IETF_Netmod_0917.pdf"; size=21540;
	creation-date="Fri, 13 Oct 2017 14:50:02 GMT";
	modification-date="Fri, 13 Oct 2017 14:50:02 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu
Zyhlbi1HQikgL1N0cnVjdFRyZWVSb290IDMzIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+
Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDIvS2lkc1sgMyAwIFIgMjcg
MCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291
cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiAyMyAwIFIvRjMgMjUgMCBSPj4vUHJvY1NldFsvUERG
L1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L0Fubm90c1sgNyAwIFIgOCAwIFIgOSAwIFIg
MTAgMCBSIDExIDAgUiAxMiAwIFIgMTMgMCBSIDE0IDAgUiAxNSAwIFIgMTYgMCBSIDE3IDAgUiAx
OCAwIFIgMTkgMCBSIDIwIDAgUiAyMSAwIFIgMjIgMCBSXSAvTWVkaWFCb3hbIDAgMCA1OTUuMzIg
ODQxLjkyXSAvQ29udGVudHMgNCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5
L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDA+Pg0KZW5kb2JqDQo0IDAgb2Jq
DQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDU2MDg+Pg0Kc3RyZWFtDQp4nM09a5PbuJHf
XeX/wI9SaodDPPhKbW2tPTt2fLFzu2fnUomTD7TEeZxnxImkiW/v1193AyABiiAoSnt1u2WNRAHd
jUajX2hAl6+2+/ubarWPvv/+8tV+X63u6nX0+fJT8/SPy0+/PtWXP1e395tqf99sLj8+f9njoz/U
1bre/vBD9Pqnq+j1p5cvLt+wiPHo083LFyxK4H8W8SKLyzzKSxkXRfTp8eWLJLrFl7cvX3xeXCz/
EX36t5cvrqEzAmh7lUlcCrvX50XkbStjXrptmaetSFicsGlwRSJjkbttffSKpIjFCL3/fPnil5cv
ousPV1F0+TPy+MPVu5+i5PJ9tbmNFvXm4s8fl31GyjiRDi9ZIWMgKAXeZBrJOw9BrCjiLHPbXl9f
L1kCdF2IRZFwfB/je0FPrpflYo9v7uotvN3Av5o+R0u5+MvyQi4afP4VH91vbuEtdXu7beDt85OH
DsmSWKQuHd6J5MA9mBwBf0zb9/fV/Q7xNBuD8QroaR7hBf89b+5Xy3RREaUgmz3QyMeSMFtsFDnQ
VLp4bJpommDGsizOYE6VyKR5LDJga5zzaFu/fPGX30UbaGpNJhuaTA2GSwWHe+C0c876c55z6IW9
sziVmtiPyIHnpVhscdSr+vcW8b+QsJ2GkyXAsx7O6ADHL51MwyfGRVzkhlsS1g5AGGMX97CLAGWG
dAKUHkM7L2OeubS/Q+m9Xnb/InxQJMBBHgu1JliOQi5A0JYMGZsvvt6DYG3w0+3yooAm2eIt9iOm
UytH6hVTjqI+60smzzipJ1g06YAmm4HikEE8S+MiPW5y1UrIijKWpZEmFqe+qRXjKwHhpB4wtj7Q
op+VLM6HlOqIGGpSmeCAaYxUOS6FitRhMI66VVJ3FKk8zdC+aFI5jFbKUVpTD60WoFTBGSeWZ0Bl
fhyxWgI4GXM1dSCrXlKzgAQgnMIDJ6gLsxzGq+n+hEuTFqNXCc5EVuQgAC6yqcKXFuiQKKkRLPYx
KQ/IHoARw1CC6s+m+o+g8OoN6Lo9ai9L01XItj2otV298WmZeUSUvE/E1MWgWKcXwwjvisBaILL1
WphMt1kYFt1XYAPuKmAeGgPS/N8pLmadVSEZfIPMJLvyJ2gJnlMB/gkaivUSn/MCmN5nwUnEilzE
3CW2M13LCzBqfft1VvQS7AdLHfRvz4wBHODMHaAyvej5HFre03AJpd9CEqs9+I9P1aYVxfK3FMVM
gMevoiZ8vL017/6D4ic10d+WDF1gWMY/gjj+1/IiBb9Yy+xTvVQyEaNsbuolk7DmnaEdhCVsMC45
WWAzSTxuh3TA426M7fAZRjEs4aiLkriQCbhHiOzmdyP6V1mpVmkJr8fuc9mN8lOWYxhQWAfLNGYm
jGlgFp6j1xBawXzReoS3Pp07E20BjJUO2qlaVzGs07p+jvm8dhtSYYnGRNrNfFu0/59o3pnkGt1r
kTtT984kwGhfiwC/9p2LQ+tfC8cU/TsXm9bAIekd0sDMF3CcSSphIYpiRAs/wGR/qU08rla3Egf4
iCoZG1RfoMEm3tRB7euLSU4VWplh2iM4mqBSFkksZFRI8q5RKfs1sgob0jKNMxPxjaoXX4ijXXkC
lHkADYWOSX506KiJnWA9fEGOVuOa2LnWg4mO9NfGhW/uQf1pPx5eUEeSbN2TF+8zKHMpKWWc9CiZ
aFE0E6dYFF8UZEPK5q9dm/hXS529qaulNhk/AfdaA1Ov0HhQmnPc1nh031xaRQqRe+nS+u+I92fA
+/Hs2ApOXtL4tJ6MJI3Lcpz9Z0YpGSejHBTXQRMSCChPFUNM1mUjSvfL6gGETa/jH+F1hVK5WzXx
qnkMGYxABDJfLMHJYGHaQwYjLUvMVII2EVKGvXhtMyBaEGKCzeC+YMXYDAQkp9uMFGLA9FiboYgN
2wweiDg0sTNtRgorW5odjb/dgzNKpqJqaLm5eR/tnPosxkw6YNWn0qVjqsVQLJxgMXggBtG0z12q
DvG401KvtrXiY+vT/erVXTNx4/5hwVzc37VmXtsgCPKnBDyZP96ZTR6sXQg3HPL8+yRnRi7R3+3x
xhvszEYiQHJ7Ixzd6DkVH+qjcsJKGTJWPBDvnLoCstJsjA4rfJVvQn+UZvx/loyRE9VpGwx67jBO
rLABta/RtlESKmzReCAEmi3HBYtZGR5g0KJleVxwQFDGkk8LgVIe5/bemUh96i0UA/UhSRkwaGka
J56Mm9egKSTdxpef3FAU1IfkJdcYsWPINfKgkFh7aH56Q/GGBSpAsBGGYwhW0iAwVdfWFIA0JoWP
XJ9fqqVhHFJwKy0VFHkg7dFFEidpAh9WnxdXV97ttLkYsaKncDBOl0a0jiahK0Vcel0DnydshHEM
UNi9skn/41LkYBw4elJCLnZeT2omylRQ5YaNco+5zKpFuUeP7h7J2OCzRpEhtKtH9FX4bLtkhXq3
wm/vsDFBeVjyTAFofoshcAnhQ37chJtFqDDq9Tw24yKwVWFDOop4vbZt4r3OIJi/A2fN/PP5DTPp
EjIhT8ym6+L8SNSy6w/+FdpxGiR+UmzY4IbSujLJz/Uuet1U2E59PDdpEpumE4TqfCKA7uf/RxGw
6frNRKA/+E4EMCfZdPMeNbizdWPSZlQp1fwLOVRvN832ULmcKghggFLmEjjZgRa+MPxMIsMkOvd+
/3JX7XC7YKWyYaoMAwVq++uyJN8Zvekam9RxswV23gYcZhGKieeKAdj3zBnQWK5wLhLoEEBy6IEz
jnWlLMnjMuCAaydC5jlGeOEcjfBFV9ocjgIKOhESk3HGW8T8boVhEibx24geJ1/tIjaYFMSPqzuf
cZ5LTUlb6g41E42zxjghUyMCYZwNaUac6hA/Zbt4oPwzev9hyTJSbVc+uZ5LpsglymiYx4MqKlDt
dyrvwItPxipLnuINuIaHcvijfme009mZJgvM9gToo2Alh0gKg5VtUDv6YtRTaU0LjOYsWsOKSxYA
RkRlRtWF0zQXbtym4XpCESgoHIMT1lsZCXO3k0M+36M6IADL6Q8oE5VWZfVhgvQ0GmAJ9WmYqq0U
wnBFoQjsANmAji/kckj/T23hV4c7ticiA0lkwkXmdQ1n48iwftzBsZqhedHroXSgiK6XjCsP6K6t
ojCVagSJanjc4vzBKhv0O7MpVSozxy4xDy4nyOGgRg9s050oYCn8SUcUeoW7A9UjsDxTbK5QqcNK
ZSpd+2XbVOtVg/49rWqdqsWvQ+laGQjC53Ib/MnMGdkE9SpLzE4xwDjVL2QpKuSwXygDe3ejgML6
VQiM6jq/sN7XEVZyoq7d7HCumm9erToTdZng7oODeqpaVRgnOIEyEJrYkOY4Mjbxs8Jzj1ZqN9mu
KdeRubpJFc4PHhvqaaZoWdjnhsbV0kxeSPDmhZwwkUN6SQZ2k06dIA5CJsY8TbQdrYQDQ1EbrVou
Ut1TNaEMQoaijZnjEJnAAVjjmKCGWIGxLEuofnmSHtJ59Ql6yBcZaGUwCiish4Dkwgzzr0up9vlo
IfztDg9c0mx5CwfmIi8OkU/URBrjFE0UCANsSHME3Sb+6HAUVb45kbjy6Ye5FIqMYz+HwpvzI0kR
emAOT0ZSHCChogjS9ruvxMs3DVWa5SMO9lz8EsQ8LycI6qCmDew9niiAAhYRYyOaljbq1bZ8u3lP
tpE+ktkbatJt5pN6rvEZivXEzXwZCKzmT4VUe6ntqMN6WRQ5huosaw+UhDbuMTnJphx6lT733uyb
jgEa2LbH7JE8ctte4wgfe019HrtR42OABjbtjyLWzLvCMeXgayBdb0OadPT1KHK1HEiSlq6M0Fdg
kPr8XSMHCMguhj+oLxjdscecU2lIf7OF1Zf7j77OxcWSJM5dVFMlULGps/9eNgWy7Jr0DtBU0rVA
2rRjkXdFe1GottbR+0ofm/M5MXNxFwmw/Ti+GRFWfLO8GC/jAm6uJt5SpxOpN2vDpn5mVt1cqtBG
Tyq1w5RV1uHTb5PZmT18mTMMhsOTN2TZ00C2/uRJkQTGb9rXVD7eFtuRyX6iDH3YQKchv3gu8ULk
mLmxiJ9goSXVAecpVQtNstCw4gWfYKFTn/tltCUCEkdYaGBFNvWopdGPitgJFtrnNRkdpYidbqGP
IdZMvCJ2ioUO5DY1tUdY6GPI1XLAErwDpb3sJvPQmgUODBAcMQwnbJ5Zhhn4Lh31jMf+6Ei2Ol3k
t9Wz0DJ4lPfQThVFxa/uqh4vwwKJT015dxPNRNK1YNqkv79vT8E0m8FDQifizPKYFS7Oh7PjKPEA
iYOj3oO9yxd0sxaZRTJ/zfBpstPQ8wRCnNRFf9wBgrBNPjfNAloWpUvzYYn/iTh4Hkvm4rD8ibMP
KeVYn3SIjsp9brvCKRT2ze3SmpAPWLCJPuurM9MkhYy5CCmLU3Hk6Ls6ODrhqtFNedA1LiNZxJm4
C4nHj45Shsp28BIiyCm2IxDcEZy5toOXeZwaunHb5+nJSImqpKMdO68BmYebQUtwex3cEw2IZtoE
AxKI9TTlMw1Ij20cq+W4UGXPNb6jlzWWONN+DdVNN+3Hqq2lJs33Dt9dI5TuhdoVCCXBF449Ynwm
WijvsC/VYe9VjsxQQPXVj/iO2n1YysSiStdwAw4q6b7FWf4OQVHjK/xC12ubQm4q2m5UX2jXYeu6
/QmbUN/u2Z/x40d8eeV+wbCv9C3ESTNzcI2dBOeNqcs2ZXe4gKcplevsvbVsM+UAr44QZUiET8VR
4uFiBwexk3j/1MoQfXxc8nLxpZ3kLX4kZvNWhojt+ZmJTFmOJ3Wnr2VnkQ7mFcJKq2B4U+shskME
gzHyQFzFMxFzZuVu6tZako20LjTLTD6iw+vGPnROywGoruJRC83TS5boJDq9vBjAzAu3qb6swdM+
ZzTBXQcqZWNAJa6N5t7Xr0jw1g67X6JWk7eD6HX47B9wkR209Q64KPuE2AOoNmvv9a5g1MHJOxyC
c1LZ01ekGEZOGg0XxUHbccEczH8MCaaUXVAKLjLnypsDqWRSJV4aU827xoei9XWUB221tgMA/Nw6
1zf0sWmLFzDBS2JPOzUE34JAybnuQpCuiMpb6cCGCrD0xb8DBQ6Z51rUYd6LoiA1aTNKZ/AA0VtP
L7zNqN/LTvX1oiSnq0qVOl2JJzs1VLN7jW9XbaE9DuFfyM7aB7bM8GSnA9ZLQlnS9Qp2W2tLEtF8
9fU1ggWjKEzp+xtf2wIi/V7bZruqvSs1KbBYzWmPhXpMl6IQJ7p7iuo1fuMFltGtQQ4wR4SlKBZr
SvEqxlI5x9PSP3OcqytibIh/pRMmKgp6a4RaqGCo2lf4Cdwnio+6cMJqU3cLiKS0vS0HP1FCYee9
7RsL4oVLTn8pIiZyEdtVBSvepL6BhDb57RGUXNDFTTYKr1ChWXWbHmTS3YU6LmCsxHs1FSBizb7G
cyU3emUQxJ1v7qFzXtgwSOVnJSP1HfutL91BbvdTCp9Wh9FSPNOqs8ZMGRUD3ZqvUjk0B/jYVnQe
+YL1yFN35P1lSUpZ0/CmaU+treoxlSPwzEnuAqYIt/pVrwUE98Udg76we7PuBl216sgrBOhA9zB9
f2jJnJ2IbDDJ7ULN0au0oA5vKdxhXojoe/o9vLvEd/RCs/Vtmao3sVlf6kRAAS8JN+UEzfb20jO4
FFxdVLH24GxGdES1BOc4oYylGLCCLyFKmAazOTAk9GBWsv4IPy/E5QqGc9MOh5YDaZP/bk3i3f4R
62QfRt2GwQy960gK8sdtOrrfPvhhxP1ExnS9YI2NuJ/9tsNMbHkiUevm5M6rq3hEy8PDIQ6m9QdY
zYrc7JrRELs1zpTTIfQFWtUOefyVLHI6tOboubLguET1g4qME9kTZbb0OkK4Ff3li92K9MHaeGC1
fm77SZnpRMDvMBQgIfabBckwZWaN7/PiCTF8aY/E4G9i4NImUrWjpM9BEu0KP52E1BQZC2XGvjOE
SeOWbHf3WMO0sXjiwhWOLQhof5anWB6qqN+Zc7vCPrY7pvBQ/0M85EBp3VUkhnGlAGl3fRRSSuGt
BckJHji888ZN4Fjyg55hG1SkuEDsfsoGOe67x4LAqsItNnvcXVGxz3XknGP+3enl94Fod8zFQEVW
1ZaEhbny5IECfgV4CQ6UCcLBS0GbcXa3ho5zk8dOVw2adD9QwnSAs6XFy9IDEejiE2Oo8WkbN9y2
tpfcMio0s5cOdu5v+bgekehJwGe9ffENgaofJwktBPBiM647kxtJ66C6pc2Zx3qzN5RnuXI6u7O5
uz2dcFZzj01S2d1ot7prXc16tX/uGvp4j7sDwqXHO0+Y0e21/fsCoePwfzIbBkjL35dWiQYNgiaJ
7pZ7Xusyjg2N1qvwYIniAS0bW8jnyL2/Y9NBLdG7tqB6fA5zJb3yO3aW46GfNY1W77vO8diTPc+M
ywGCcHsJ3os+yIKNCcZ6W7Vn1H1pkxRcrrRwh+/70Z80SePevFjkePow+mkVL/yOLS3LEkWQwD8T
vB6WJnhzSN/r6YpuzG6MP2rMHSh+BsD6RlfMaavEvi222tVeRDInWzAJUapmxW67bjMfyqfYt5Nf
+wIZnnC6GHwKSu1SWW0dU5XIMdcwH9wxd5NhBaZNnckyrqG2UD7/EANnXrqj8OoO/I0j/yjGsnVY
Mu4QqMkKKoPBLTIXdImZuUFB9QQgWhFkaiF3iQc6mHygCS7kOVSBxJz3RGnBu7Lz3pysd+v+Zftu
5opunJsGXu0+OG036mTeBblxnm5ZhoH7NBQ5JZidtmSyn9Gyretll8skVeJbY0bB+XAeRCSoB/C2
+/bEnh2RGFFRbSCWxk/9RkNKUOTo9rmy5S5gNrqAB3csbUQFkJL1EE1cwGVCiTyrqz/AK8Vh29EA
j2GmHNjJY+4J8C49P/X3utnvm0f/r/29aZp9+2t//wTUwMyUeFomCVfXzOK14IfV+/zwN9g0tWVO
xYQt+4DiRB3qjyb+540XOO78WPCHQLp7Y15iOcvQpe8T25+JbhJK3CNB0Za4CJJY5mVZuLMwkYGO
UI7u0GWxLIZYXBRgOh2q2dCwB34nDzxtrCvAO10L77B7GWocttXB37ZI6GY9p+0n9KoXd7gdtMOK
uWjdqKOA6eIZNB1PcF8NNGqkfhHwAdrVD+jnYuxRLCLwPSCke1JOOWYUlxelgqT67cgx3uMxNvTg
Cwi2L5RKo5bfMCRRiJubMR+Z4w3apUv7HoIt7PLuGgGo7DB+LhJ4y2PEJiIMoPCnFEX7W4osNz45
UPYWh2U2PsDq9Xe4Lt+Iw1mSEG+W6TjTB6dXgh+RM7cjhENA9Bq5oZhfE6ujDUWE+8OftByY0lzG
rAUItkLPoIJE7K229w80QZ5po5Z6qpGUKsIvmx19SxeN3iOYBluYqYJZxRguemc4r1/k4jvrO/2o
/S6iDDDdZqaHXpmQbr0zsWBCsRVRTi/NyiQ78GcnC7O5IDHwwnxys0VMIEsuqgLbJhzeerMVEn8s
tcdBz8+I/i8b56nRDQplbmRzdHJlYW0NCmVuZG9iag0KNSAwIG9iag0KPDwvVHlwZS9Gb250L1N1
YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMS9CYXNlRm9udC9BcmlhbE1UL0VuY29kaW5nL1dpbkFuc2lF
bmNvZGluZy9Gb250RGVzY3JpcHRvciA2IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIyL1dp
ZHRocyAyMzMgMCBSPj4NCmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9G
b250TmFtZS9BcmlhbE1UL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDkwNS9EZXNjZW50
IC0yMTAvQ2FwSGVpZ2h0IDcyOC9BdmdXaWR0aCA0NDEvTWF4V2lkdGggMjY2NS9Gb250V2VpZ2h0
IDQwMC9YSGVpZ2h0IDI1MC9MZWFkaW5nIDMzL1N0ZW1WIDQ0L0ZvbnRCQm94WyAtNjY1IC0yMTAg
MjAwMCA3MjhdID4+DQplbmRvYmoNCjcgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAyNTku
NDUgNjU4LjI4IDM2Ni44NCA2NzMuOTNdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24v
Uy9VUkkvVVJJKG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0KSA+Pi9TdHJ1Y3RQYXJlbnQgMT4+
DQplbmRvYmoNCjggMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAyNTkuNDUgNjI2Ljk4IDM0
OC41IDY0Mi42M10gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkobWFp
bHRvOmxiZXJnZXJAbGFibi5uZXQpID4+L1N0cnVjdFBhcmVudCAyPj4NCmVuZG9iag0KOSAwIG9i
ag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDI1OS40NSA1OTUuNjggMzU4LjI2IDYxMS4zM10gL0JT
PDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkobWFpbHRvOmJjbGFpc2VAY2lz
Y28uY29tKSA+Pi9TdHJ1Y3RQYXJlbnQgMz4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PC9TdWJ0eXBl
L0xpbmsvUmVjdFsgMjU5LjQ1IDU2NC4zOCAzODMuMzQgNTgwLjAzXSAvQlM8PC9XIDA+Pi9GIDQv
QTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShtYWlsdG86d2FuZ3ppdGFvQGh1YXdlaS5jb20pID4+
L1N0cnVjdFBhcmVudCA0Pj4NCmVuZG9iag0KMTEgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0
WyAyNTkuNDUgNTA4Ljk0IDM3MS43MiA1MjQuNTldIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9B
Y3Rpb24vUy9VUkkvVVJJKG1haWx0bzpzYXNlY3JldGFyeUBpZWVlLm9yZykgPj4vU3RydWN0UGFy
ZW50IDU+Pg0KZW5kb2JqDQoxMiAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDI1OS40NSA0
NzcuNjQgMzYwLjczIDQ5My4yOV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VS
SS9VUkkobWFpbHRvOnAubmlrb2xpY2hAaWVlZS5vcmcpID4+L1N0cnVjdFBhcmVudCA2Pj4NCmVu
ZG9iag0KMTMgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAyNTkuNDUgNDQ2LjM0IDQxMC44
NSA0NjEuOTldIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKG1haWx0
bzphZGFtLmhlYWxleUBicm9hZGNvbS5jb20pID4+L1N0cnVjdFBhcmVudCA3Pj4NCmVuZG9iag0K
MTQgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAyNTkuNDUgNDE1LjA0IDM2NS42MSA0MzAu
NjldIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKG1haWx0bzpwYW5z
bG93QGNpZW5hLmNvbSkgPj4vU3RydWN0UGFyZW50IDg+Pg0KZW5kb2JqDQoxNSAwIG9iag0KPDwv
U3VidHlwZS9MaW5rL1JlY3RbIDI1OS40NSAzODMuNzUgNDI2Ljc4IDM5OS40XSAvQlM8PC9XIDA+
Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShtYWlsdG86emh1YW5neWFuLnpodWFuZ0Bo
dWF3ZWkuY29tKSA+Pi9TdHJ1Y3RQYXJlbnQgOT4+DQplbmRvYmoNCjE2IDAgb2JqDQo8PC9TdWJ0
eXBlL0xpbmsvUmVjdFsgMjU5LjQ1IDM0MC45NSAzMzkuOTMgMzU2LjZdIC9CUzw8L1cgMD4+L0Yg
NC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKG1haWx0bzpkbGF3QGhwZS5jb20pID4+L1N0cnVj
dFBhcmVudCAxMD4+DQplbmRvYmoNCjE3IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNDA1
LjU0IDIxNi45MSA1MzQuNiAyMjkuNTZdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24v
Uy9VUkkvVVJJKGh0dHA6Ly93d3cuaWVlZTgwMi5vcmcvJTBiMy9jZi9pbmRleC5odG1sKSA+Pi9T
dHJ1Y3RQYXJlbnQgMTE+Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3Rb
IDY5Ljc1IDE5OC4yNiAxNDUuMTcgMjE2LjkxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0
aW9uL1MvVVJJL1VSSShodHRwOi8vd3d3LmllZWU4MDIub3JnLyUwYjMvY2YvaW5kZXguaHRtbCkg
Pj4vU3RydWN0UGFyZW50IDEyPj4NCmVuZG9iag0KMTkgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9S
ZWN0WyAzNTcuMjYgMTYwLjMxIDUyNS42IDE3Mi45Nl0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBl
L0FjdGlvbi9TL1VSSS9VUkkoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt
bmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wNCkgPj4vU3RydWN0UGFyZW50IDEzPj4NCmVuZG9i
ag0KMjAgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA2OS43NSAxNDcuNjYgMjIwLjk5IDE2
MC4zMV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0w
NCkgPj4vU3RydWN0UGFyZW50IDE0Pj4NCmVuZG9iag0KMjEgMCBvYmoNCjw8L1N1YnR5cGUvTGlu
ay9SZWN0WyAyNjYuNzYgMTQ3LjY2IDUyNS42IDE2MC4zMV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9U
eXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRz
ZHQtbm1kYS1ndWlkZWxpbmVzLTAxKSA+Pi9TdHJ1Y3RQYXJlbnQgMTU+Pg0KZW5kb2JqDQoyMiAw
IG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDY5Ljc1IDEyOS4wMSA4Ni40ODUgMTQ3LjY2XSAv
QlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMtMDEpID4+L1N0cnVjdFBhcmVu
dCAxNj4+DQplbmRvYmoNCjIzIDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9O
YW1lL0YyL0Jhc2VGb250L1RpbWVzTmV3Um9tYW5QU01UL0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu
Zy9Gb250RGVzY3JpcHRvciAyNCAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDMyL1dpZHRocyAy
MzQgMCBSPj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5h
bWUvVGltZXNOZXdSb21hblBTTVQvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgODkxL0Rl
c2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDQwMS9NYXhXaWR0aCAyNTY4L0ZvbnRX
ZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDAvRm9udEJCb3hbIC01Njgg
LTIxNiAyMDAwIDY5M10gPj4NCmVuZG9iag0KMjUgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBl
L1RydWVUeXBlL05hbWUvRjMvQmFzZUZvbnQvQXJpYWwtSXRhbGljTVQvRW5jb2RpbmcvV2luQW5z
aUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDI2IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMzIv
V2lkdGhzIDIzNSAwIFI+Pg0KZW5kb2JqDQoyNiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRv
ci9Gb250TmFtZS9BcmlhbC1JdGFsaWNNVC9GbGFncyAzMi9JdGFsaWNBbmdsZSAtMTIvQXNjZW50
IDkwNS9EZXNjZW50IC0yMDgvQ2FwSGVpZ2h0IDcyOC9BdmdXaWR0aCA0NDEvTWF4V2lkdGggMTg3
Ni9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9MZWFkaW5nIDMzL1N0ZW1WIDQ0L0ZvbnRCQm94
WyAtNTE3IC0yMDggMTM1OSA3MjhdID4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9UeXBlL1BhZ2Uv
UGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUj4+L0V4dEdTdGF0ZTw8L0dT
MjkgMjkgMCBSL0dTMzAgMzAgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9J
bWFnZUldID4+L0Fubm90c1sgMzEgMCBSXSAvTWVkaWFCb3hbIDAgMCA1OTUuMzIgODQxLjkyXSAv
Q29udGVudHMgMjggMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZp
Y2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxNz4+DQplbmRvYmoNCjI4IDAgb2JqDQo8PC9G
aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDEyNTc+Pg0Kc3RyZWFtDQp4nI1XTW/jNhC9G/B/4FEs
Ykr8lFQEAbJJNt1iU2wbFz0Ee1AiRTF2I3ltedP013eGpGTJjmIjsCCRw+Hjm5k3THi+ahaP2UND
Tk/D86bJHp6KnNyF83r5NZy/LovwS1YuqqxZ1FV4u7lvcOi3IsuL1dkZ+XB5QT7Mp5PwIydckPnj
dMJJBH+ciMSwNCZxqliSkPkzGF3fipSU6+kkIqX9lJH/vJ5O7oIZ/Urmv08nV+AQnXae0oilsu/p
LiCjtorBJgNbMWIrI84ifpxfGSkm46HtGF4ZJUy+g/fHdPLndEKubi4ICb8g7zcXny5JFH7OqpIE
RTX7+5bukgtQ1YDfWLBIKBLrlMXC7/IPnQkRFJRL2HAmjApeKNfBgupg/YQjWgQNnamgttMyyL5T
A9NgU9JZElR9m6eCOjdaBc90JoM6h4ECV6z9sLPLYLiB0f6Whd8gRyc/KeduYY27LP1ch8258aPD
vcHfH2BxCb8bypPgnKp2fIWYiocaLC08+ygq+Mwzyj04dF/j2NqvukfP9sQV0lSOBbylV8WMe3Z3
z7JEOnIH1KR2KyTQxMErGtUbmLIg3Xy9oqmjOassBh38h3ZYWvBdMTDTEcRwJLMVZyodAGoDDc4t
l3bH7+A3dzDwFbf5Rmc86lu7HPDfOvFU4vcPxLfBg659SME8265c26V2wL5t1tu5zdJx76eKrX8b
gTGmlZYsHh7sjZCPrE1SlojBWncWDFDWQHSA4EMhllDabZ2CEC5+IvAuL/GlWI+44FwxvuPiBFcR
fHTrnztMNkl8ciuXCLnnSQVLzJC6bNOmWI9tK4RmRg+3ZaO2yZ5tn5E9HeJjOrTLG9csbj1ikLDE
OKSdq+CF1wkcsanwiMP2YSuh8TThvC+dEY61ZnK4W6sRfDwzeKyZMsNln3DZFcUfVMvVO3klIm3l
vr86iSAwAqAAZmVQa6V0RbSicfDNnsFKCpaQP9g1kGBjaUtzOdYwuGSGD3cbbUQ8YXqHjgdbX122
VbjXaMpKAyt3NjvpxaKTb260VZAa1clJCI5q0wuiNc5WeT/ytV/7FqotSYeKMpIsMu35LIy1L5sk
AteIaWkTwNLbaqgvJTDZby5xYruUby3jcUeR7e/eZc0cA/txuwWqVNEpYdsiuSv+eC9BLIN9AmY2
QWbqmAzREZN6iIs5fQYgFmHV1ZiNzPPbtGyVvsxancmxVKuya2TWyabZUN63723VKyF4HIikgdub
Mns11IpiMciRrn7WTrhbXrPXTiTvfdm3aYi0VXmnqA1NxqMrBVb1ANHpvhTeLrOqU0NxSA2FTFii
+07d+Kps3/6yt9unLlPsY4mfv+JbCEcJ8eUFGHA/YJV1vQcZKpATTx6E1wRlKGGNy/CqKbpQdd3G
Ehg6JyO9M4qZTodsWCKLfxGbBfDUgDMDMvBOv5CHGFIo4DsMld2t/2wMnuGoUwN4Yz1OGcXinVTr
J8E2Im20koQpQQQ3TJOIJYqsiunk8Zc3jqeObIcm5izpHe8uuKU+qx+KrqXjHcDeDk/G+paIsE/3
vB1o1/pYfHDNgquK84iXq6y75+Tkc2bV6WUUlLSg+i7eBWWOBQW3Et16vAAo9p8JxGTp8n3J9GVH
+cYNA62aUNea3EzvboCyW3UCQ6hIDomya93myL4tEs5MOjzEHi3/A1O3QE8NCmVuZHN0cmVhbQ0K
ZW5kb2JqDQoyOSAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL2NhIDE+Pg0KZW5k
b2JqDQozMCAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL0NBIDE+Pg0KZW5kb2Jq
DQozMSAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDIzNi4zOSA2ODIuMDMgNDU3LjMyIDcw
MC42OF0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3d3
dy5pZWVlODAyLm9yZy8zL2ludGVyaW1zL2luZGV4Lmh0bWwpID4+L1N0cnVjdFBhcmVudCAxOD4+
DQplbmRvYmoNCjMyIDAgb2JqDQo8PC9UaXRsZShJRUVFIDgwMi4zIEV0aGVybmV0IFdvcmtpbmcg
R3JvdXAgTGlhaXNvbiBDb21tdW5pY2F0aW9uKSAvQXV0aG9yKElFRUUgODAyLjMpIC9TdWJqZWN0
KElFRUUgODAyLjMgRXRoZXJuZXQgV29ya2luZyBHcm91cCBMaWFpc29uIENvbW11bmljYXRpb24p
IC9DcmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABXAG8AcgBkACAAMgAwADEAMykgL0Ny
ZWF0aW9uRGF0ZShEOjIwMTcwOTIzMjEyMDEzKzAxJzAwJykgL01vZERhdGUoRDoyMDE3MDkyMzIx
MjAxMyswMScwMCcpIC9Qcm9kdWNlcij+/wBNAGkAYwByAG8AcwBvAGYAdACuACAAVwBvAHIAZAAg
ADIAMAAxADMpID4+DQplbmRvYmoNCjM5IDAgb2JqDQo8PC9UeXBlL09ialN0bS9OIDE5OS9GaXJz
dCAxNzI4L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjg0Mj4+DQpzdHJlYW0NCnicpVrdbh23
Eb4PkHfgGxzO8B8IArR1grZunMAy0IuiF7J9aqu2JUORgeTt+81yuOc0IrmrY0DQ8uyS8/vNkBzS
JWONdyaQ8WzIsvHBUCjGe8OET2Q4JuOzcQ5dknGZTZAh6CJ/1gS8wAdQCCUbH00MweAvccQHkxK+
JZOdNyGanIOJ1hQwi2xKcSY6YZtNJDxTMdEbIggBGYgKxmZDIkJAP8fexIhnARW89+iHT+TRL2F8
EH7oF200CXQixE9QK4JPgl4JRJM1lIlMBP2c8cT74rJJ2bC1+J7whDDZwgCE9wVPDMrOMDMUCXji
ZY6GHXmTYSgHoTLGeccG9mGPlyDNizzoF8EPluKIjxn0EoxR0C8VvEe/DA9AJS4WpgGdApvCllxy
NiUaZz3eF+MIehWPJ4wClRzDbujiGEKJ75yDicmScR6akEVXL3ay6BtYDAxiAZqRDcZFJ6a3aBRx
PegnMa4FwUxifdDJMAsBB67A/fALGlCEKBpvITQRsCFeIwrACtQXk3m20tmhEcSbABVEFPeiATsR
A0BeHM6CN3wnCOeDuIJBJ8LNBFP7mKQzCCYQAwrQEAkZwMtOOns0sgAEvEoU7gXoFE0hbrCwKTkB
txfQAKcEK5IDLllgBa8HR9IZoxwwTA448zAJweDBC0ScYBlikuA3FKGDTwJxAoZDgiyAIRpiVQmk
LFaVeMhiVcRIKEtIWQkP8EIoRQtihICJ4hkRLpI4TtDMTujgEwMoFCQ+JELAD2CWUYgAL5iHAjHA
JAA7GuICGDSC0BK+MYrfYZGYnHROaIjjwCZmCTEgDG6XWAHlAtAhWBAbEJOiBJPgB7ZOQgPxgzAS
q4Jo4iWyEFBONEV4JSAADYSahyyEzykIfpIEnYQfvJii4AdSpojYIBgrJZbOWRKEk5BEBEoKQryk
XJZgReyJCyT4JEPQElWAOSEWs5iEEISZxSwIgCxZAiGNSBWzZMk5YhaJOcAOUY6gXsAGQ+RQ4x5h
LGCDq/ICNhg9JwCEiuQq4QVRkLSkMygX4QVj5SK8EIrFCioRnVbiWcKXJdEAZkUgL4FQ3PIJEe0l
qSIoC7AqSQYxD3wwrFeCpBUr0Q4zM6ITDKQz6MCYaCBBZCs5GQSz5ChEBNKnJCkQLHAVi+utBSMW
Ja2F0ExLPnDyTgJQ7MTiGyvuZPGA5SDUkmQJBPriZitRKukfKcTLO6EXAHVm4REkt7GMiAAyL6Ed
k7wTbonlXVmyubS8pBQExIJsmIkkb0oLbuclY0AEIzbHCEwwklVEKYkRBJtkLEkvwIY4EbAQgSQd
OBD87rvDLzLWmpeHq8Mvh1e/fz4erh7uv7x5+OHj8dPh+b+M/bc5/PLOOOnz/ffffrMMAbXJEOoO
IR3y6llvjF96dwf6GS++hFcY8rJt4MvuwEVtlag7Ps1kdd0hcS5rHvIqM17+Al7BjngFmvEKl/Di
S32Qqg8W7VWwrshT2MTuEDcXeQibMI2gdAmvNOTV3H71+fr20dDW/fDcZB2ydPn5z39/efj59X9N
BegjqpF2Ui2PBfnHze2Hro1rtMRhZO9WhexpTJ661VaWVB/DON2yfrkQnBV0igeVtUcmhhn/7ohp
ZqFuyp1zkS3AQLxk9zqGuyDLfZAl3kvWPRZlhLK0DJL9ylcr40+Wm+bWVOFV1ZGd0UVeVsEuQFms
8KqQUFm7ms8x003baZ620xgzU5NRN+FuMMtDA+XdSEpdgJY+QLPfSzY/FmUE0LygQDa8X63MKfnm
6YSca0xUdWRrPfLZhv0vnaMr8BQSKmtX8ylmuLv0zHkqcxlipkxNxt0MusVsaKCyF0ncz6Bk+wgt
cS9d91iWEUJLdVcZxvZ+bU4ptLiZuUsNiqqOFGdGCNlwwHglPkdoRZ5iQmXtkZFq0Aw13RwqVaGZ
1LIJH/Kbmo27aXSb39BMUsma8euuXbf5DXPdhlvU3M0MTby+ENOVIOf+oLQh+RCJRHbKr1zEj4a5
UQqA+4LO2X4KoX4KkVrjTsLUkWaURKSoubiMhtPNE1Tis0HzWgN5ZRv0Ocxi284Y1yC2YJuVudXn
OMCpzIToDuFpDnLdssIGn6V2PBKR96Z75/vI4wHyeO/s5UJHmiHyuM5fUur+epXi2aBpLpZae2Wr
wOdJ7thyxqXzmJwFVOaaOHk8lblp1u4Pmcae688Ocz7LkcJQxN2pqV/d0ATTIZz2Ei4daYbIcxr3
buz63Sp5ezZoWrwip4hzCnw/XPRuO+PSWqgcEVUhWJ/jRca8HtsfMo09312tb/BZTpqGIu5NTX6w
YPcD5Pm8l7DrSDNEntY/aVyzfYJK/mzQdD1IviFOgT+uv2474+JFopbhFSNN5q4QgZ+MvHnh2PdX
/HM+ywHkUMS9qcnHPvLCAHm7y6s+daQZIk9rrBTHrt+vUj4bNC2iU2iIU+DH8fpl0xnDFeoW8oIi
Tuu8KnNXiDiHUX+7EOd1aYpjGMWp+UK3lrLNb7yWj9PtV+gn6E1+lxbe1dzNDE28rhBpfpjVPVGk
tDGPpjEc03QqC/3l+ya/8VSW9ub9MFi+x0FCSXunshA60gwTipYJaVzufYJKZ8v3NJ/KtEipWi1X
KIbst5xx8VSmRwmKkSZzV4g8h1F/LZ43UmEewyhPzRf69ZVNfuOEmaenFaGfMDf5jY/PNzyjNXQ1
QxOvK0SZVoZiP/XmjS1hGcOxTHdlsZ96N/ldXPwouiAYV8OpTLEU+yl3rTqPJB5jqUyxFPspd5Pf
xVjSareK1aOw3sF5df3647G/5VloeD1aruis6wE9x9FieSvPtnpXqz60vWBbmbd1UpuVW5prQdUg
0wzTt9n8oLR7C2XV9ce7u4fbu4euumyHs8H8vlKc8+yP6S7qea3Fb806cbAy7162+EOfwVk52711
g5g6Eo8mW66l+eXWXH0OQf0E9fNOO3M9iGjKLRf0RtzXcvsm99I3bPeM9//78OCUjWnvkWyyHYmH
xq/lqeXOYX0OZ/v96ifqq9at/v+hz6BOy7R3/5b4SepnVbvmFeZhiD9BfbcXe/U8pPl2udtZnxoJ
PJxwd12QrEXokwabFec6QI71u85xqwMfUd5aDK+UuSPO0Dvc7HCWES5XardbtIquWi1XX0fs55T8
BWPCBWNif8y6Or++f+gXy+v83RZLGgN64MlWUWlbirBqDn3PmjJ0DmetvrLTRdc5hirjV/fH40vM
sIeXdx+PP11/NlpUhoDH2+Wr0dq0SLeupdavL46/PTw//n66dbJO1y/k3w+3b08/XqHv67vfDlfH
Nw+Hvx6v3x7va1vGtPbfbj/e3B6v3l+LiPLiT7egcP1wc3erv+8fbv5zjcby65939x9e3919ODy7
e/PlE4Ra3vz6/nh8qEb+6frN/d3Z77+8x/+z389urj/evTt7cfXx5u3xrG/lg27v7q8/HX68effl
/qi6vvjy6VeEtmkF/nalkNutL9du1/h2iSGsZ5BxPRNKa40+rzXTcqph2dPuk9ZJkfjUdGu6In9q
hjVpUTw103Kvuy7cWjhVXJzAV7/XeqleLdZbv3ohVy+56v3T9T6lrjarxrW0st6Cqy+TrkTrt7qV
X+8h6fJUr5nUb3W3sF4EUds0w6imul7QCwXteL4dm58d/raVrlpTo+Z0RNfet5WwGmo9SNH3LTq9
0m3lbrWRlrtbOfdUlFR0aFGy1ela/azVtVqVqFVvTjWI3FbeSkexpdvlto1tm8K2WWtboLY16WST
tt5q3zXrrHOhJt82F3LLOo2OztCCoVMqahk7n2fscWr69pv/AQiRiZkNCmVuZHN0cmVhbQ0KZW5k
b2JqDQoyMzMgMCBvYmoNClsgMjc4IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjc4IDMzMyAy
NzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgMCAwIDU1NiA1NTYgMCAyNzggMCA1ODQgMCA1ODQg
MCAxMDE1IDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDAgNjY3IDU1NiA4MzMg
NzIyIDc3OCA2NjcgMCAwIDY2NyA2MTEgNzIyIDY2NyA5NDQgMCA2NjcgNjExIDAgMCAwIDAgMCAw
IDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYg
NTU2IDU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCA1MDBdIA0KZW5kb2Jq
DQoyMzQgMCBvYmoNClsgMjUwXSANCmVuZG9iag0KMjM1IDAgb2JqDQpbIDI3OF0gDQplbmRvYmoN
CjIzNiAwIG9iag0KPDwvVHlwZS9YUmVmL1NpemUgMjM2L1dbIDEgNCAyXSAvUm9vdCAxIDAgUi9J
bmZvIDMyIDAgUi9JRFs8MjQ2MTM3RjhFNjU1RkU0NzlDRkYyMjgzQ0MyOTMxNTY+PDI0NjEzN0Y4
RTY1NUZFNDc5Q0ZGMjI4M0NDMjkzMTU2Pl0gL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDY4
Pj4NCnN0cmVhbQ0KeJw11NVSFlAQAODf7i5SVBBMwE5U7O5usbtb7EbsThS7uwtF38AZn8ALXwJ/
z6fnYr/Z2T0zuzcbiURfSUmpaKwVifwlF+8DpdsFYuYFYividyDuQCA+BUWBhJxAYhkUBhoOxK9A
Un6gUSp+BBrvDjQZFkiuD7WUk4Gm2YHUdPwMpBUHmhkpPQnjkBfI6BHdI7pRWuQLvqIYRfjX8i36
IbPgf3YF5VAapVAWZVAVFVAelVARVVAZMaiOaqiJGmiA+qiFuqiNOqiHZMQiHnFogsZIQBIS0RCN
kIGmSEEaUpGO1miGlmiOFmiFbmiDTLRDW3RFF7RHJ3RAR3RGb2ShO3qiB7LRC8PRF33QH/0wDEMx
AIMxEIMwBJMwAqMwEhMxAaMxDmMwFuMxB5MxFVMwGzmYhpmYjhmYheWYi/mYh2VYigVYjIVYhCXY
hBVYhZXYiA1YjXVYg7VYjx3Ygs3YilxsxzbkYxd2Yg924xDysBcHsA/7cRAncQSHcQxHcQLHcQ6n
cQpncQaXcQHncQkXcRUFuIZC3MV13MYN3MQt3MFL3MMj3McDPMRjPMcTPMUzvMArfMcHvMY7vMFb
vMdHfMLn6DXtnhyucNY6HI9E/gBxz4PeDQplbmRzdHJlYW0NCmVuZG9iag0KeHJlZg0KMCAyMzcN
CjAwMDAwMDAwMzMgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDAwMTI1IDAwMDAw
IG4NCjAwMDAwMDAxODggMDAwMDAgbg0KMDAwMDAwMDU2MyAwMDAwMCBuDQowMDAwMDA2MjQ2IDAw
MDAwIG4NCjAwMDAwMDY0MDggMDAwMDAgbg0KMDAwMDAwNjYzNCAwMDAwMCBuDQowMDAwMDA2Nzkz
IDAwMDAwIG4NCjAwMDAwMDY5NDggMDAwMDAgbg0KMDAwMDAwNzEwNSAwMDAwMCBuDQowMDAwMDA3
MjY2IDAwMDAwIG4NCjAwMDAwMDc0MjcgMDAwMDAgbg0KMDAwMDAwNzU4NyAwMDAwMCBuDQowMDAw
MDA3NzUyIDAwMDAwIG4NCjAwMDAwMDc5MTAgMDAwMDAgbg0KMDAwMDAwODA3NyAwMDAwMCBuDQow
MDAwMDA4MjMwIDAwMDAwIG4NCjAwMDAwMDg0MDUgMDAwMDAgbg0KMDAwMDAwODU4MCAwMDAwMCBu
DQowMDAwMDA4NzgxIDAwMDAwIG4NCjAwMDAwMDg5ODIgMDAwMDAgbg0KMDAwMDAwOTE3MyAwMDAw
MCBuDQowMDAwMDA5MzY0IDAwMDAwIG4NCjAwMDAwMDk1MzcgMDAwMDAgbg0KMDAwMDAwOTc3NCAw
MDAwMCBuDQowMDAwMDA5OTQ0IDAwMDAwIG4NCjAwMDAwMTAxODAgMDAwMDAgbg0KMDAwMDAxMDQ3
NCAwMDAwMCBuDQowMDAwMDExODA3IDAwMDAwIG4NCjAwMDAwMTE4NjEgMDAwMDAgbg0KMDAwMDAx
MTkxNSAwMDAwMCBuDQowMDAwMDEyMDk0IDAwMDAwIG4NCjAwMDAwMDAwMzQgNjU1MzUgZg0KMDAw
MDAwMDAzNSA2NTUzNSBmDQowMDAwMDAwMDM2IDY1NTM1IGYNCjAwMDAwMDAwMzcgNjU1MzUgZg0K
MDAwMDAwMDAzOCA2NTUzNSBmDQowMDAwMDAwMDM5IDY1NTM1IGYNCjAwMDAwMDAwNDAgNjU1MzUg
Zg0KMDAwMDAwMDA0MSA2NTUzNSBmDQowMDAwMDAwMDQyIDY1NTM1IGYNCjAwMDAwMDAwNDMgNjU1
MzUgZg0KMDAwMDAwMDA0NCA2NTUzNSBmDQowMDAwMDAwMDQ1IDY1NTM1IGYNCjAwMDAwMDAwNDYg
NjU1MzUgZg0KMDAwMDAwMDA0NyA2NTUzNSBmDQowMDAwMDAwMDQ4IDY1NTM1IGYNCjAwMDAwMDAw
NDkgNjU1MzUgZg0KMDAwMDAwMDA1MCA2NTUzNSBmDQowMDAwMDAwMDUxIDY1NTM1IGYNCjAwMDAw
MDAwNTIgNjU1MzUgZg0KMDAwMDAwMDA1MyA2NTUzNSBmDQowMDAwMDAwMDU0IDY1NTM1IGYNCjAw
MDAwMDAwNTUgNjU1MzUgZg0KMDAwMDAwMDA1NiA2NTUzNSBmDQowMDAwMDAwMDU3IDY1NTM1IGYN
CjAwMDAwMDAwNTggNjU1MzUgZg0KMDAwMDAwMDA1OSA2NTUzNSBmDQowMDAwMDAwMDYwIDY1NTM1
IGYNCjAwMDAwMDAwNjEgNjU1MzUgZg0KMDAwMDAwMDA2MiA2NTUzNSBmDQowMDAwMDAwMDYzIDY1
NTM1IGYNCjAwMDAwMDAwNjQgNjU1MzUgZg0KMDAwMDAwMDA2NSA2NTUzNSBmDQowMDAwMDAwMDY2
IDY1NTM1IGYNCjAwMDAwMDAwNjcgNjU1MzUgZg0KMDAwMDAwMDA2OCA2NTUzNSBmDQowMDAwMDAw
MDY5IDY1NTM1IGYNCjAwMDAwMDAwNzAgNjU1MzUgZg0KMDAwMDAwMDA3MSA2NTUzNSBmDQowMDAw
MDAwMDcyIDY1NTM1IGYNCjAwMDAwMDAwNzMgNjU1MzUgZg0KMDAwMDAwMDA3NCA2NTUzNSBmDQow
MDAwMDAwMDc1IDY1NTM1IGYNCjAwMDAwMDAwNzYgNjU1MzUgZg0KMDAwMDAwMDA3NyA2NTUzNSBm
DQowMDAwMDAwMDc4IDY1NTM1IGYNCjAwMDAwMDAwNzkgNjU1MzUgZg0KMDAwMDAwMDA4MCA2NTUz
NSBmDQowMDAwMDAwMDgxIDY1NTM1IGYNCjAwMDAwMDAwODIgNjU1MzUgZg0KMDAwMDAwMDA4MyA2
NTUzNSBmDQowMDAwMDAwMDg0IDY1NTM1IGYNCjAwMDAwMDAwODUgNjU1MzUgZg0KMDAwMDAwMDA4
NiA2NTUzNSBmDQowMDAwMDAwMDg3IDY1NTM1IGYNCjAwMDAwMDAwODggNjU1MzUgZg0KMDAwMDAw
MDA4OSA2NTUzNSBmDQowMDAwMDAwMDkwIDY1NTM1IGYNCjAwMDAwMDAwOTEgNjU1MzUgZg0KMDAw
MDAwMDA5MiA2NTUzNSBmDQowMDAwMDAwMDkzIDY1NTM1IGYNCjAwMDAwMDAwOTQgNjU1MzUgZg0K
MDAwMDAwMDA5NSA2NTUzNSBmDQowMDAwMDAwMDk2IDY1NTM1IGYNCjAwMDAwMDAwOTcgNjU1MzUg
Zg0KMDAwMDAwMDA5OCA2NTUzNSBmDQowMDAwMDAwMDk5IDY1NTM1IGYNCjAwMDAwMDAxMDAgNjU1
MzUgZg0KMDAwMDAwMDEwMSA2NTUzNSBmDQowMDAwMDAwMTAyIDY1NTM1IGYNCjAwMDAwMDAxMDMg
NjU1MzUgZg0KMDAwMDAwMDEwNCA2NTUzNSBmDQowMDAwMDAwMTA1IDY1NTM1IGYNCjAwMDAwMDAx
MDYgNjU1MzUgZg0KMDAwMDAwMDEwNyA2NTUzNSBmDQowMDAwMDAwMTA4IDY1NTM1IGYNCjAwMDAw
MDAxMDkgNjU1MzUgZg0KMDAwMDAwMDExMCA2NTUzNSBmDQowMDAwMDAwMTExIDY1NTM1IGYNCjAw
MDAwMDAxMTIgNjU1MzUgZg0KMDAwMDAwMDExMyA2NTUzNSBmDQowMDAwMDAwMTE0IDY1NTM1IGYN
CjAwMDAwMDAxMTUgNjU1MzUgZg0KMDAwMDAwMDExNiA2NTUzNSBmDQowMDAwMDAwMTE3IDY1NTM1
IGYNCjAwMDAwMDAxMTggNjU1MzUgZg0KMDAwMDAwMDExOSA2NTUzNSBmDQowMDAwMDAwMTIwIDY1
NTM1IGYNCjAwMDAwMDAxMjEgNjU1MzUgZg0KMDAwMDAwMDEyMiA2NTUzNSBmDQowMDAwMDAwMTIz
IDY1NTM1IGYNCjAwMDAwMDAxMjQgNjU1MzUgZg0KMDAwMDAwMDEyNSA2NTUzNSBmDQowMDAwMDAw
MTI2IDY1NTM1IGYNCjAwMDAwMDAxMjcgNjU1MzUgZg0KMDAwMDAwMDEyOCA2NTUzNSBmDQowMDAw
MDAwMTI5IDY1NTM1IGYNCjAwMDAwMDAxMzAgNjU1MzUgZg0KMDAwMDAwMDEzMSA2NTUzNSBmDQow
MDAwMDAwMTMyIDY1NTM1IGYNCjAwMDAwMDAxMzMgNjU1MzUgZg0KMDAwMDAwMDEzNCA2NTUzNSBm
DQowMDAwMDAwMTM1IDY1NTM1IGYNCjAwMDAwMDAxMzYgNjU1MzUgZg0KMDAwMDAwMDEzNyA2NTUz
NSBmDQowMDAwMDAwMTM4IDY1NTM1IGYNCjAwMDAwMDAxMzkgNjU1MzUgZg0KMDAwMDAwMDE0MCA2
NTUzNSBmDQowMDAwMDAwMTQxIDY1NTM1IGYNCjAwMDAwMDAxNDIgNjU1MzUgZg0KMDAwMDAwMDE0
MyA2NTUzNSBmDQowMDAwMDAwMTQ0IDY1NTM1IGYNCjAwMDAwMDAxNDUgNjU1MzUgZg0KMDAwMDAw
MDE0NiA2NTUzNSBmDQowMDAwMDAwMTQ3IDY1NTM1IGYNCjAwMDAwMDAxNDggNjU1MzUgZg0KMDAw
MDAwMDE0OSA2NTUzNSBmDQowMDAwMDAwMTUwIDY1NTM1IGYNCjAwMDAwMDAxNTEgNjU1MzUgZg0K
MDAwMDAwMDE1MiA2NTUzNSBmDQowMDAwMDAwMTUzIDY1NTM1IGYNCjAwMDAwMDAxNTQgNjU1MzUg
Zg0KMDAwMDAwMDE1NSA2NTUzNSBmDQowMDAwMDAwMTU2IDY1NTM1IGYNCjAwMDAwMDAxNTcgNjU1
MzUgZg0KMDAwMDAwMDE1OCA2NTUzNSBmDQowMDAwMDAwMTU5IDY1NTM1IGYNCjAwMDAwMDAxNjAg
NjU1MzUgZg0KMDAwMDAwMDE2MSA2NTUzNSBmDQowMDAwMDAwMTYyIDY1NTM1IGYNCjAwMDAwMDAx
NjMgNjU1MzUgZg0KMDAwMDAwMDE2NCA2NTUzNSBmDQowMDAwMDAwMTY1IDY1NTM1IGYNCjAwMDAw
MDAxNjYgNjU1MzUgZg0KMDAwMDAwMDE2NyA2NTUzNSBmDQowMDAwMDAwMTY4IDY1NTM1IGYNCjAw
MDAwMDAxNjkgNjU1MzUgZg0KMDAwMDAwMDE3MCA2NTUzNSBmDQowMDAwMDAwMTcxIDY1NTM1IGYN
CjAwMDAwMDAxNzIgNjU1MzUgZg0KMDAwMDAwMDE3MyA2NTUzNSBmDQowMDAwMDAwMTc0IDY1NTM1
IGYNCjAwMDAwMDAxNzUgNjU1MzUgZg0KMDAwMDAwMDE3NiA2NTUzNSBmDQowMDAwMDAwMTc3IDY1
NTM1IGYNCjAwMDAwMDAxNzggNjU1MzUgZg0KMDAwMDAwMDE3OSA2NTUzNSBmDQowMDAwMDAwMTgw
IDY1NTM1IGYNCjAwMDAwMDAxODEgNjU1MzUgZg0KMDAwMDAwMDE4MiA2NTUzNSBmDQowMDAwMDAw
MTgzIDY1NTM1IGYNCjAwMDAwMDAxODQgNjU1MzUgZg0KMDAwMDAwMDE4NSA2NTUzNSBmDQowMDAw
MDAwMTg2IDY1NTM1IGYNCjAwMDAwMDAxODcgNjU1MzUgZg0KMDAwMDAwMDE4OCA2NTUzNSBmDQow
MDAwMDAwMTg5IDY1NTM1IGYNCjAwMDAwMDAxOTAgNjU1MzUgZg0KMDAwMDAwMDE5MSA2NTUzNSBm
DQowMDAwMDAwMTkyIDY1NTM1IGYNCjAwMDAwMDAxOTMgNjU1MzUgZg0KMDAwMDAwMDE5NCA2NTUz
NSBmDQowMDAwMDAwMTk1IDY1NTM1IGYNCjAwMDAwMDAxOTYgNjU1MzUgZg0KMDAwMDAwMDE5NyA2
NTUzNSBmDQowMDAwMDAwMTk4IDY1NTM1IGYNCjAwMDAwMDAxOTkgNjU1MzUgZg0KMDAwMDAwMDIw
MCA2NTUzNSBmDQowMDAwMDAwMjAxIDY1NTM1IGYNCjAwMDAwMDAyMDIgNjU1MzUgZg0KMDAwMDAw
MDIwMyA2NTUzNSBmDQowMDAwMDAwMjA0IDY1NTM1IGYNCjAwMDAwMDAyMDUgNjU1MzUgZg0KMDAw
MDAwMDIwNiA2NTUzNSBmDQowMDAwMDAwMjA3IDY1NTM1IGYNCjAwMDAwMDAyMDggNjU1MzUgZg0K
MDAwMDAwMDIwOSA2NTUzNSBmDQowMDAwMDAwMjEwIDY1NTM1IGYNCjAwMDAwMDAyMTEgNjU1MzUg
Zg0KMDAwMDAwMDIxMiA2NTUzNSBmDQowMDAwMDAwMjEzIDY1NTM1IGYNCjAwMDAwMDAyMTQgNjU1
MzUgZg0KMDAwMDAwMDIxNSA2NTUzNSBmDQowMDAwMDAwMjE2IDY1NTM1IGYNCjAwMDAwMDAyMTcg
NjU1MzUgZg0KMDAwMDAwMDIxOCA2NTUzNSBmDQowMDAwMDAwMjE5IDY1NTM1IGYNCjAwMDAwMDAy
MjAgNjU1MzUgZg0KMDAwMDAwMDIyMSA2NTUzNSBmDQowMDAwMDAwMjIyIDY1NTM1IGYNCjAwMDAw
MDAyMjMgNjU1MzUgZg0KMDAwMDAwMDIyNCA2NTUzNSBmDQowMDAwMDAwMjI1IDY1NTM1IGYNCjAw
MDAwMDAyMjYgNjU1MzUgZg0KMDAwMDAwMDIyNyA2NTUzNSBmDQowMDAwMDAwMjI4IDY1NTM1IGYN
CjAwMDAwMDAyMjkgNjU1MzUgZg0KMDAwMDAwMDIzMCA2NTUzNSBmDQowMDAwMDAwMjMxIDY1NTM1
IGYNCjAwMDAwMDAyMzIgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDE1Mzk1IDAw
MDAwIG4NCjAwMDAwMTU3MzQgMDAwMDAgbg0KMDAwMDAxNTc2MiAwMDAwMCBuDQowMDAwMDE1Nzkw
IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMjM3L1Jvb3QgMSAwIFIvSW5mbyAzMiAwIFIvSURb
PDI0NjEzN0Y4RTY1NUZFNDc5Q0ZGMjI4M0NDMjkzMTU2PjwyNDYxMzdGOEU2NTVGRTQ3OUNGRjIy
ODNDQzI5MzE1Nj5dID4+DQpzdGFydHhyZWYNCjE2NDYxDQolJUVPRg0KeHJlZg0KMCAwDQp0cmFp
bGVyDQo8PC9TaXplIDIzNy9Sb290IDEgMCBSL0luZm8gMzIgMCBSL0lEWzwyNDYxMzdGOEU2NTVG
RTQ3OUNGRjIyODNDQzI5MzE1Nj48MjQ2MTM3RjhFNjU1RkU0NzlDRkYyMjgzQ0MyOTMxNTY+XSAv
UHJldiAxNjQ2MS9YUmVmU3RtIDE1NzkwPj4NCnN0YXJ0eHJlZg0KMjEzNjANCiUlRU9G

--_002_D85FFC1A190B4A0BB5E43779D1871FDDjunipernet_--


From nobody Fri Oct 13 08:40:03 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCEE126E64 for ; Fri, 13 Oct 2017 08:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts865GJbY6YK for ; Fri, 13 Oct 2017 08:40:00 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90101126B71 for ; Fri, 13 Oct 2017 08:39:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1218; q=dns/txt; s=iport; t=1507909199; x=1509118799; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ksDGgFZMu0li/K/gzmn4WSCX7YhhZfemTAFcEBcLn+U=; b=a56aSyUVJKSciza6igtFj9pvAvubsGMkAZ6zQV9Gp0HgmZuXAbWkOE86 P0tpEDBoqDsAahgY5zuU7b0h6aex0ZII5qEfCthvWStFeID3Bn2vkJVjM X3EKNwWwPNAkHzNPcr99PGLzZ3cKxmwYCFi6HQT3y8Be5bds8NNZ7DwVq M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAABp3eBZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ih90kBIili8QggQKGAuESU8ChRUYAQIBAQEBAQEBayi?= =?us-ascii?q?FHgEBAQMBASEVNhsLDgoCAiYCAicwBgEMBgIBAYoZEKs8gieLPgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEaBYEOgh+DWIIVC4J0hFIBEgGDMoJhBZhkiGKUa4IUhXaDWoc?= =?us-ascii?q?ujg+HYIE5HzhCQVY0IQgdFUmCZIRgPzaIO4I1AQEB?=
X-IronPort-AV: E=Sophos;i="5.43,371,1503360000"; d="scan'208";a="656337917"
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; 13 Oct 2017 15:39:55 +0000
Received: from [10.61.88.2] (ams3-vpn-dhcp6147.cisco.com [10.61.88.2]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9DFdsjN029957; Fri, 13 Oct 2017 15:39:55 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
From: Robert Wilton 
Message-ID: 
Date: Fri, 13 Oct 2017 16:39:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Oct 2017 15:40:02 -0000

Hi,

Support.

I have also reviewed a previous version of this draft, and provided 
comments that I hope can be considered/discussed.

Thanks,
Rob


On 13/10/2017 15:37, Kent Watsen wrote:
> All,
>
> Now that we have resolved the module naming issue on the list (i.e.
> that keeps the original rfc module names and updates the unwanted
> legacy nodes to have status 'obsolete'), rather than wait for the
> changes to be made in the individual document, we'd like to move
> ahead with the adoption now, with the understanding that these
> changes will be made in the -01 version of the adopted draft.
>
> This is start of a two-week poll on making draft-acee-netmod-rfc8022bis-03
> 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.
>
> The poll ends Oct 27.
>
> Thanks,
> Kent (and Lou)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Fri Oct 13 09:34:19 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7971330AD for ; Fri, 13 Oct 2017 09:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFWeUSW6QS2E for ; Fri, 13 Oct 2017 09:34:17 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A125413243A for ; Fri, 13 Oct 2017 09:34:16 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id l68so22858678wmd.5 for ; Fri, 13 Oct 2017 09:34:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=he/auLsYxC/LD/vmDjaFhi+hf9vT4I2iGxUquM4htiE=; b=sa8lmwZnL2uYZfUb/ihYdNX7HdD+tGExtg9+ovK16zNQbIZj9l6MENzN28i20U2YP9 H0Ym3drC0fZj6HZfhMVXnFIIT4x490EzqSyagLDkUSkaRJ94k8KjVdcfU0gaH4u6sv1r wnGliq05724gAFEOamoG/9+H+Pisd0EgFtiUBf4Q5DlxULQCVWCwScXxYlQip44a5erJ knsnkGtpZFlwv50wwY1GI9sAvv2W7fF7qqAve0da+SH4V6v1X45r95nHj6Ds7+sMKsH4 EV4kOoTJ0afzFMgFhG5/IFE4JffIBTRuhfS0tQv850DZzdLEEP54bZlT9y/6SZ1Y/nc6 OCoQ==
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=he/auLsYxC/LD/vmDjaFhi+hf9vT4I2iGxUquM4htiE=; b=i7H/LP9lc9tyWU0WGYywuQpV/rrkaby/i6qlfvBf5/XbtJgqdj1qe5sNCqYPrxBb1M Wz7W/lGHV+iznUEdcjerbmB2/wRspdy3lCJC0mgwqEqRfc9BcFyFUPsKLWJW5kLsdU8d ioQy+Afc3r9qnfoI/25QKQ/uueKqjZKjoJJ090hVQC/9yNs87dYtDh593zUywXz2yDz8 WjDDBQaM0RJy4vjVb/xxqXR/VLfnDofjOypxPW9tDdJxJga1ekoW3LV3+qgdRbXSEE4E 1U1fQzxgvR8fZLHUZRidBPpBMbLUtKJR+8WD/2dfwHug1tUZcZHjZgPsUoz5/EdM1hNf 4uRg==
X-Gm-Message-State: AMCzsaXfg2+GXiBDrxfMhWeXVbkyw3j9qBmpdxiFj6ejL1MgLAI3/bg7 lGLvjsosZmr1HL5LHgbehP579Bc2
X-Google-Smtp-Source: AOwi7QA/mHIbZ8Jul6VTwyHA6/HXw09vlbF9URJi5pyX1gWZEkfH+VXX1/6dZu4o/8GQVHBl+hj2rA==
X-Received: by 10.80.176.225 with SMTP id j88mr2867562edd.25.1507912454764; Fri, 13 Oct 2017 09:34:14 -0700 (PDT)
Received: from [172.16.40.209] (ip-80-113-11-227.ip.prioritytelecom.net. [80.113.11.227]) by smtp.gmail.com with ESMTPSA id x35sm1213487edx.17.2017.10.13.09.34.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 09:34:13 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura 
X-Mailer: iPhone Mail (15A403)
In-Reply-To: 
Date: Fri, 13 Oct 2017 18:34:13 +0200
Cc: "netmod@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net> 
To: Kent Watsen 
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Oct 2017 16:34:19 -0000

Yes/support 

Jeff
>> On 13/10/2017 15:37, Kent Watsen wrote:
>> All,
>> 
>> Now that we have resolved the module naming issue on the list (i.e.
>> that keeps the original rfc module names and updates the unwanted
>> legacy nodes to have status 'obsolete'), rather than wait for the
>> changes to be made in the individual document, we'd like to move
>> ahead with the adoption now, with the understanding that these
>> changes will be made in the -01 version of the adopted draft.
>> 
>> This is start of a two-week poll on making draft-acee-netmod-rfc8022bis-03
>> 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.
>> 
>> The poll ends Oct 27.
>> 
>> Thanks,
>> Kent (and Lou)
>> 
>> _______________________________________________
>> 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 Oct 13 10:04:17 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043F1133200 for ; Fri, 13 Oct 2017 10:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR27j1oOTrdR for ; Fri, 13 Oct 2017 10:04:14 -0700 (PDT)
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 DD5921331F6 for ; Fri, 13 Oct 2017 10:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1630; q=dns/txt; s=iport; t=1507914254; x=1509123854; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=CucmhE7lj8+roLkwLa2p4fzHly3ahlE0RfZ/3T6YSDs=; b=VMktosb3kaSUOyUqoEosiHAOq3cfDRnI1ZCfc3Frfyku03t/WnCnpwZz sedZIK9GuDhgYnd+kkEQqfWI6lZXgqt8vEi97uIttip5droH4UHoQ4+5E saZOB6/NYxRvR/w8jirBRrolMLufECf8xXBasGnY0DadDeNX8oYT3miaz E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAABi8eBZ/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHg3OKH48ymCUQggQKGAuESU8chDw/GAECAQEBAQEBAWs?= =?us-ascii?q?ohR4GAQEhETodAQgODAImAgQlCxUSBAESih0Qq2uCJ4s/AQEBAQEBBAEBAQEBA?= =?us-ascii?q?QEcBYEOgh+CB4ZlhFIBEgEfF4J8gmEFoUYClGmCFIV2iwiVQgIRGQGBOAEfOIE?= =?us-ascii?q?DVnoVSYJkhF92iDuBJIERAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,371,1503360000"; d="scan'208";a="307560018"
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; 13 Oct 2017 17:03:33 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v9DH3VtY013085 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Oct 2017 17:03:31 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 13 Oct 2017 13:03:30 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Fri, 13 Oct 2017 13:03:30 -0400
From: "Acee Lindem (acee)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
Thread-Index: AQHTREUxpoz3v+62/E2UPONcHF59Zw==
Date: Fri, 13 Oct 2017 17:03:30 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.195]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Oct 2017 17:04:16 -0000

QXMgY28tYXV0aG9yLCBJIHN1cHBvcnQgYW5kIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSLg0KVGhh
bmtzLA0KYWNlZSANCg0KT24gMTAvMTMvMTcsIDEwOjM3IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBv
ZiBLZW50IFdhdHNlbiINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dh
dHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5BbGwsDQo+DQo+Tm93IHRoYXQgd2UgaGF2ZSBy
ZXNvbHZlZCB0aGUgbW9kdWxlIG5hbWluZyBpc3N1ZSBvbiB0aGUgbGlzdCAoaS5lLg0KPnRoYXQg
a2VlcHMgdGhlIG9yaWdpbmFsIHJmYyBtb2R1bGUgbmFtZXMgYW5kIHVwZGF0ZXMgdGhlIHVud2Fu
dGVkDQo+bGVnYWN5IG5vZGVzIHRvIGhhdmUgc3RhdHVzICdvYnNvbGV0ZScpLCByYXRoZXIgdGhh
biB3YWl0IGZvciB0aGUNCj5jaGFuZ2VzIHRvIGJlIG1hZGUgaW4gdGhlIGluZGl2aWR1YWwgZG9j
dW1lbnQsIHdlJ2QgbGlrZSB0byBtb3ZlDQo+YWhlYWQgd2l0aCB0aGUgYWRvcHRpb24gbm93LCB3
aXRoIHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlc2UNCj5jaGFuZ2VzIHdpbGwgYmUgbWFkZSBp
biB0aGUgLTAxIHZlcnNpb24gb2YgdGhlIGFkb3B0ZWQgZHJhZnQuDQo+DQo+VGhpcyBpcyBzdGFy
dCBvZiBhIHR3by13ZWVrIHBvbGwgb24gbWFraW5nIGRyYWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJi
aXMtMDMNCj5hIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuICBQbGVhc2Ugc2VuZCBlbWFpbCB0byB0
aGUgbGlzdCBpbmRpY2F0aW5nDQo+Inllcy9zdXBwb3J0IiBvciAibm8vZG8gbm90IHN1cHBvcnQi
LiAgSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlDQo+eW91ciByZXNlcnZhdGlvbnMgd2l0
aCB0aGUgZG9jdW1lbnQuICBJZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0bw0KPnByb3Zp
ZGUgY29tbWVudHMgeW91J2QgbGlrZSB0byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50
IGlzIGEgV0cNCj5kb2N1bWVudC4NCj4NCj5UaGUgcG9sbCBlbmRzIE9jdCAyNy4NCj4NCj5UaGFu
a3MsDQo+S2VudCAoYW5kIExvdSkNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcN
Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo=


From nobody Fri Oct 13 11:43:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E58E134249 for ; Fri, 13 Oct 2017 11:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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 omTxvWPgFy2b for ; Fri, 13 Oct 2017 11:43:49 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00110.outbound.protection.outlook.com [40.107.0.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878F013300C for ; Fri, 13 Oct 2017 11:43:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kXOrY7Z6Txp3WAZCHL3gBJlp7F9pOyyoKieeNl5E8/Q=; b=lRSxxnYFlZkaH2cuu5SmCpP8/dy7QDLzZ5/aTbjs1SxOyRwQaq5Nu+niyho+L291nTo25Z1b66iOp3o+BX45PjxI8SNN3Kty8eo9YI6V2U3OURsRQYpnal2ha7RDhMxKUZTcO5JhWWGmc4h71bb0pefWMCTnIKFK5Dg+wwjKKWc=
Received: from HE1PR07MB0843.eurprd07.prod.outlook.com (10.162.24.16) by HE1PR07MB0842.eurprd07.prod.outlook.com (10.162.24.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 13 Oct 2017 18:43:45 +0000
Received: from HE1PR07MB0843.eurprd07.prod.outlook.com ([fe80::98e6:b6da:7d7d:25b9]) by HE1PR07MB0843.eurprd07.prod.outlook.com ([fe80::98e6:b6da:7d7d:25b9%16]) with mapi id 15.20.0077.021; Fri, 13 Oct 2017 18:43:45 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: "netmod@ietf.org" 
Thread-Topic: leafref to lists that contain system-controlled entries
Thread-Index: AdNETq1mxw6yfiPkS3eq6pji6usdqw==
Date: Fri, 13 Oct 2017 18:43:45 +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=jason.sterne@nokia.com; 
x-originating-ip: [135.245.20.19]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB0842; 6:t4IiZT+6P4u/HBMaDjHUYq7jJs+5sKaeKzZazQhX96zr0Ju7OApEL3QvqJyJRrOQ1IedHw+IZCwSpTBP0JmVl55qhVUFe71Pn0Qi5R1zMjJcaMdIxIDIIOcnFXW/Hu+yDqmu064BwuKI9xlCTYF0h9C/ckg4+oBN/i0053qaVLxsLUt63c3/GrwrMRpUvoHXlB7kfh6qlNbeF4dtORVBCkbIm6yoJdeKtgGOR5dyXBcm0rMrNN4jvxcNTEgogfY7bdi0vaSwE9U3YxNngsygZsg5ArmvkvjmaTwrK+ADg1Rl5BGhI61D32nmdCsRlQmS5HaCXov5/UCX6e0ZsXvdlA==; 5:eMOdBhgXdCr9lUvVoYIGpFmLU5d7WQNHx/9DGuiCjzywtq4XC/o1CgEmJeut52ZsckWMeelexhmVxMMNiH1CdVI09mUslQpM7Pbjs3oICoB9Zz5oG2WXMMX+bqYIL0DALdizIVMQAmyQojHRZP/Mig==; 24:ywLRoOa5BiBsuiRn/Gk8Lo42tt3wbsSoiY/j2VEf0OZdS3pJoVml2rP47mAB7b73Dzuwf3MPS5xcLVv+LN2RxJJkdY3lHKqr2iwJ9QtGIUQ=; 7:srOLUPftiZIzGkpEhFzKMMcQD7JnzRkx7wCS2N1spMLsYvCXHP4nvmKvJMbqXoNZ0Rg32+QYNnb5UFAAJNAz8ata2IryT6C4clEZ3RuAoSeUNyrgengboRQ6lmeHrGoPAtti6Y61JOnrjcEhUbHK4WIcdbKD92UC/jltevAYG8oGNkNXQhJKVa7gB1XOzrPyR6HKI7uGsBw0aHVFmJ+HgHHcmFoGH+eWY4fgyAkg9G8=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b9499e9a-7cae-4f1d-e04a-08d5126a5594
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB0842; 
x-ms-traffictypediagnostic: HE1PR07MB0842:
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB0842; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB0842; 
x-forefront-prvs: 04599F3534
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(53754006)(189002)(199003)(6506006)(6436002)(2351001)(6306002)(236005)(5640700003)(189998001)(790700001)(6116002)(3846002)(102836003)(106356001)(105586002)(53936002)(5660300001)(7696004)(316002)(66066001)(7736002)(74316002)(54896002)(55016002)(3660700001)(99286003)(9686003)(97736004)(19609705001)(606006)(5630700001)(68736007)(33656002)(86362001)(2906002)(81156014)(14454004)(81166006)(1730700003)(8676002)(8936002)(54356999)(478600001)(3280700002)(50986999)(5250100002)(2501003)(2900100001)(6916009)(966005)(101416001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0842; H:HE1PR07MB0843.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)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB08435A124031631CF19E92BE9B480HE1PR07MB0843eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 18:43:45.2102 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0842
Archived-At: 
Subject: [netmod] leafref to lists that contain system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Oct 2017 18:43:51 -0000

--_000_HE1PR07MB08435A124031631CF19E92BE9B480HE1PR07MB0843eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

There are a few threads on the mailing list that touch on the concept of sy=
stem-controlled resources (mostly list entries):

https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0
https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w
https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0

A few drafts & RFCs also refer to the concept:
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
https://tools.ietf.org/html/rfc7223

Several vendor implementations have list entries (instance data) that are p=
opulated by the server and can be referenced (leafref) from other places in=
 the configuration.  These system entries are useful pre-created policies, =
interfaces, etc that can then be used (and referred-to) by operators in the=
ir explicit configuration.

If those entries are only expected to exist in the  datastore,=
 then in theory any references to them in user created configuration will c=
ause a validation problem in the candidate/running (missing leafref target)=
.

One solution discussed in the mailing lists is to change every reference to=
 lists that could contain a system created entry to a "require-instance fal=
se" leafref.  But then some useful validation is lost.  In many cases the m=
odel is more correctly "require-instance true" but the set of targets inclu=
des the system create entries.

Another solution discussed is to have the system created entries appear in =
the  datastore (as part of template/expansion).  That would make =
validation pass on the intended datastore, but then the candidate/running/s=
tartup datastores would not be valid (would be missing leafref targets if a=
ny part of the config refers to system created entries).  THis sounds simil=
ar to the problem that has been discussed in the past about the fact that t=
emplates (in the running) basically mean the running/candidate aren't neces=
sarily valid (until after template expansion, which means only the intended=
 would be valid).

Another approach could be to actually have those system created entries sho=
w up in running/candidate.  That would ensure that references to those entr=
ies are valid.  But if the whole concept of templates just cause the runnin=
g/candidate to not be valid anyways maybe we wouldn't worry about the inval=
id aspect of references to system created list entries ?

Rgds,
Jason


--_000_HE1PR07MB08435A124031631CF19E92BE9B480HE1PR07MB0843eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


There are a few threads on the mailing list that tou=
ch on the concept of system-controlled resources (mostly list entries):


 


https://mailarchive.ietf.org/arch/msg/netm=
od/3fTSHIh_MfHzmuDCoicAGiXA2E0


https://mailarchive.ietf.org/arch/msg/netm=
od/KIsSgKByQWpqYzA4i6Bwc8fuH3w


https://mailarchive.ietf.org/arch/msg/netm=
od/mjLJdiYErtNG41dJ5bJ5ji07cz0


 


A few drafts & RFCs also refer to the concept:


https://tools.ietf.org/html/draft-ietf-netmod-r=
evised-datastores-04


http=
s://tools.ietf.org/html/rfc7223


 


Several vendor implementations have list entries (in=
stance data) that are populated by the server and can be referenced (leafre=
f) from other places in the configuration.  These system entries are u=
seful pre-created policies, interfaces,
 etc that can then be used (and referred-to) by operators in their explicit=
 configuration.


 


If those entries are only expected to exist in the &=
lt;operational> datastore, then in theory any references to them in user=
 created configuration will cause a validation problem in the candidate/run=
ning (missing leafref target).


 


One solution discussed in the mailing lists is to ch=
ange every reference to lists that could contain a system created entry to =
a “require-instance false” leafref.  But then some useful =
validation is lost.  In many cases the model is more
 correctly “require-instance true” but the set of targets inclu=
des the system create entries.


 


Another solution discussed is to have the system cre=
ated entries appear in the <intended> datastore (as part of template/=
expansion).  That would make validation pass on the intended datastore=
, but then the candidate/running/startup datastores
 would not be valid (would be missing leafref targets if any part of the co=
nfig refers to system created entries).  THis sounds similar to the pr=
oblem that has been discussed in the past about the fact that templates (in=
 the running) basically mean the running/candidate
 aren’t necessarily valid (until after template expansion, which mean=
s only the intended would be valid).


 


Another approach could be to actually have those sys=
tem created entries show up in running/candidate.  That would ensure t=
hat references to those entries are valid.  But if the whole concept o=
f templates just cause the running/candidate
 to not be valid anyways maybe we wouldn’t worry about the invalid as=
pect of references to system created list entries ?


 


Rgds,


Jason


 






--_000_HE1PR07MB08435A124031631CF19E92BE9B480HE1PR07MB0843eurp_--


From nobody Fri Oct 13 11:47:17 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458C5134249 for ; Fri, 13 Oct 2017 11:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfgPKKHuTnpE for ; Fri, 13 Oct 2017 11:47:14 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 980EB13300C for ; Fri, 13 Oct 2017 11:47:14 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id x7so11088160pfa.1 for ; Fri, 13 Oct 2017 11:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q37MAinD7+Elb9pvXTMKHRDRhh1qvDU/0IiH0GjDlSA=; b=X7btwIVp+mAni0byWwr7qsScAYPI8L4I51AVerY1SayOC37Pbogm/8oOmEuIJPH9MT 5DufFD9roLs4E3UA2K+GrEF/alpvVnS0bFEm1k8tgwZpHpEY1yNcjRsCXfii26+ZM2IL 88o2fJGV3uYpfu4GH7ih75WvYKTF3XA9ip0lbPwbt6dq5DDeKtbueBzKw5I4QS+RRZrw UjfUqEgDhgQXM0/UWAGYtXceAt+93l/wvh6sTfr6HSxY+ylPF7Ao+uuNs8CAAHi1ycjj 0u2xmBtpOCAP3NFPzlQw0UnLeoE/RKhqOaYiWkDqiC8I7pd7eOMkYFb5pLaPu+N813/p gr3w==
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=Q37MAinD7+Elb9pvXTMKHRDRhh1qvDU/0IiH0GjDlSA=; b=L/EmEFLyxJn/pNufVI8QLYuo2mJf84pKWN0TSOEr1Ea9+MbpFDSr4NvZ4mVpDrcaqY hqjvCo4Um+OVO4xV8zppASWxykA98ZehZIOBVFCcWufphyVEPPUIf0PfheD8WWJXUCsu /0PMetxFvWwX8sZIBu1+K3f3mGXQ+Q5ro+YqwthIbI7qLoBQ98+Um+9jW6rqRMp9yotI 7qE5u0wHsi5Eqi0dcVFxroFWWlcaj4Gy1mUrrmH8KxPRq8PvUcp/ujmUosuAva4fWOZR fuROTfLLwYyE98uZeRbyJDRgVCpNhJ0zhwLlz13Lp6PdbIx3yhS/rCngqSTKBpNY8bjS JeRQ==
X-Gm-Message-State: AMCzsaUqqHtpAWVaBB4PLgRHFJ2bH5/Ysflr/7PN+3CY1lTr1HkPnc30 uXxrS/ocbBZL3cU/aZMXmkdRIMtz
X-Google-Smtp-Source: AOwi7QByvhi9QZhokFiAtipD+FeJGoQSENAEhSBInstgnkMZH8M0pLFaTAliIIi9KyiIta+1n1ugzA==
X-Received: by 10.99.6.18 with SMTP id 18mr1976926pgg.389.1507920433992; Fri, 13 Oct 2017 11:47:13 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1320:e415:8a2e:ba96:546? ([2001:420:30d:1320:e415:8a2e:ba96:546]) by smtp.gmail.com with ESMTPSA id v14sm3537251pgq.72.2017.10.13.11.47.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 Oct 2017 11:47:13 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
Date: Fri, 13 Oct 2017 11:47:21 -0700
Cc: "netmod@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: <9797746B-DB76-4C1D-9184-EEA8B019026F@gmail.com>
References: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
To: Kent Watsen 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Oct 2017 18:47:16 -0000

Support.

> On Oct 13, 2017, at 7:37 AM, Kent Watsen  wrote:
> 
> All,
> 
> Now that we have resolved the module naming issue on the list (i.e. 
> that keeps the original rfc module names and updates the unwanted
> legacy nodes to have status 'obsolete'), rather than wait for the
> changes to be made in the individual document, we'd like to move
> ahead with the adoption now, with the understanding that these 
> changes will be made in the -01 version of the adopted draft.
> 
> This is start of a two-week poll on making draft-acee-netmod-rfc8022bis-03
> 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.
> 
> The poll ends Oct 27.
> 
> Thanks,
> Kent (and Lou)
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Sat Oct 14 12:15:41 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB984133018 for ; Sat, 14 Oct 2017 12:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdVqfz8hvx87 for ; Sat, 14 Oct 2017 12:15:38 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33746132F2C for ; Sat, 14 Oct 2017 12:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3092; q=dns/txt; s=iport; t=1508008538; x=1509218138; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tsA1xILQ6z1yD/QAv1BeJBZZREBJ6tChHhjY12kP84U=; b=abkr70ZChxkRzzf2JF+3s/B3RMfPDRbjFwzbahJ7dAzCno9Uc4L9ZaI5 aYOrJpkWq/+3wvbPePpuIj2X8I1jPv7olLSM3mw8EAicVML2/c5q2JEvy z8xLEUfdu8R7w167/NbbG1LLQRs5/DfF4/dsr0f5AY1OXV+YRlaz4+242 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAADeYeJZ/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHg3OKH48xmCWCFAolhRYCGoQ8PxgBAgEBAQEBAQFrHQu?= =?us-ascii?q?FHgMDIxFDEgIBCBIIAiYCAgIwFQIEAQYDAgQTih0QqySCJ4ssAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR+BDoIfggeDO4MqgzKEZoJhBYofhyiQAQKHXYNiiSqCFF2FGYs?= =?us-ascii?q?MlUICERkBgTgBHziBWXoVH4MOCYRWdgGJXYERAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,378,1503360000"; d="scan'208";a="310877023"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2017 19:15:37 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v9EJFaiB016509 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 14 Oct 2017 19:15:36 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 14 Oct 2017 15:15:36 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Sat, 14 Oct 2017 15:15:35 -0400
From: "Acee Lindem (acee)" 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-acee-netmod-rfc8022bis-05.txt
Thread-Index: AQHTRRqOy7g+2Gkp0EWl8w/yPyu+raLjt1eA
Date: Sat, 14 Oct 2017 19:15:35 +0000
Message-ID: 
References: <150800584724.5122.8866359992581148497.idtracker@ietfa.amsl.com>
In-Reply-To: <150800584724.5122.8866359992581148497.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.195]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] FW: New Version Notification for draft-acee-netmod-rfc8022bis-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: Sat, 14 Oct 2017 19:15:40 -0000

QWxsLCANCg0KRHVlIHRvIHBvcHVsYXIgZGVtYW5kLCB0aGlzIHJldmlzaW9uIHJldGFpbnMgdGhl
IFJGQyA4MDIyIG1vZHVsZSBuYW1lcywNCmluY2x1ZGVzIGFueXRoaW5nIHNjaGVtYSBub2RlcyBv
ZiBhdWdtZW50YXRpb25zIG9mIHJvdXRpbmctc3RhdGUgb3INCmludGVyZmFjZS1zdGF0ZSB3aXRo
IOKAmG9ic29sZXRlJyBzdGF0dXMsIGFuZCByZXN0b3JlcyBvcmRlciB0byB0aGUNCnVuaXZlcnNl
LiBUaGUgV0cgYWRvcHRpb24gcG9sbCBzaG91bGQgYXBwbHkgdG8gdGhpcyByZXZpc2lvbi4NCg0K
VGhhbmtzLA0KQWNlZSANCg0KT24gMTAvMTQvMTcsIDI6MzAgUE0sICJpbnRlcm5ldC1kcmFmdHNA
aWV0Zi5vcmciDQo8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgbmV3
IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLTA1LnR4dA0KPmhh
cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWNlZSBMaW5kZW0gYW5kIHBvc3RlZCB0
byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LWFjZWUtbmV0bW9kLXJm
YzgwMjJiaXMNCj5SZXZpc2lvbjoJMDUNCj5UaXRsZToJCUEgWUFORyBEYXRhIE1vZGVsIGZvciBS
b3V0aW5nIE1hbmFnZW1lbnQgKE5ETUEgVmVyc2lvbikNCj5Eb2N1bWVudCBkYXRlOgkyMDE3LTEw
LTE0DQo+R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczoJCTcyDQo+VVJMOiAg
ICAgICAgICAgIA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1h
Y2VlLW5ldG1vZC1yZmM4MDIyYmlzLTA1LnR4dA0KPlN0YXR1czogICAgICAgICANCj5odHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLw0K
Pkh0bWxpemVkOiAgICAgICANCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWNl
ZS1uZXRtb2QtcmZjODAyMmJpcy0wNQ0KPkh0bWxpemVkOiAgICAgICANCj5odHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDUN
Cj5EaWZmOiAgICAgICAgICAgDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy
YWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDUNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRv
Y3VtZW50IGNvbnRhaW5zIGEgc3BlY2lmaWNhdGlvbiBvZiB0aHJlZSBZQU5HIG1vZHVsZXMgYW5k
IG9uZQ0KPiAgIHN1Ym1vZHVsZS4gIFRvZ2V0aGVyIHRoZXkgZm9ybSB0aGUgY29yZSByb3V0aW5n
IGRhdGEgbW9kZWwgdGhhdA0KPiAgIHNlcnZlcyBhcyBhIGZyYW1ld29yayBmb3IgY29uZmlndXJp
bmcgYW5kIG1hbmFnaW5nIGEgcm91dGluZw0KPiAgIHN1YnN5c3RlbS4gIEl0IGlzIGV4cGVjdGVk
IHRoYXQgdGhlc2UgbW9kdWxlcyB3aWxsIGJlIGF1Z21lbnRlZCBieQ0KPiAgIGFkZGl0aW9uYWwg
WUFORyBtb2R1bGVzIGRlZmluaW5nIGRhdGEgbW9kZWxzIGZvciBjb250cm9sLXBsYW5lDQo+ICAg
cHJvdG9jb2xzLCByb3V0ZSBmaWx0ZXJzLCBhbmQgb3RoZXIgZnVuY3Rpb25zLiAgVGhlIGNvcmUg
cm91dGluZyBkYXRhDQo+ICAgbW9kZWwgcHJvdmlkZXMgY29tbW9uIGJ1aWxkaW5nIGJsb2NrcyBm
b3Igc3VjaCBleHRlbnNpb25zIC0tIHJvdXRlcywNCj4gICBSb3V0aW5nIEluZm9ybWF0aW9uIEJh
c2VzIChSSUJzKSwgYW5kIGNvbnRyb2wtcGxhbmUgcHJvdG9jb2xzLg0KPg0KPiAgIFRoaXMgdmVy
c2lvbiBvZiB0aGVzZSBZQU5HIG1vZHVsZXMgdXNlcyBuZXcgbmFtZXMgZm9yIHRoZXNlIFlBTkcN
Cj4gICBtb2RlbHMuICBUaGUgbWFpbiBkaWZmZXJlbmNlIGZyb20gdGhlIGZpcnN0IHZlcnNpb24g
aXMgdGhhdCB0aGlzDQo+ICAgdmVyc2lvbiBmdWxseSBjb25mb3JtcyB0byB0aGUgTmV0d29yayBN
YW5hZ2VtZW50IERhdGFzdG9yZQ0KPiAgIEFyY2hpdGVjdHVyZSAoTk1EQSkuICBDb25zZXF1ZW50
bHksIHRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIFJGQyA4MDIyLg0KPg0KPiAgICAgICAgICAgICAg
ICAgIA0KPiAgICAgICAgDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv
dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50aWwgdGhl
IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y
Zy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KDQo=


From nobody Sat Oct 14 12:42:19 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D7812426E for ; Sat, 14 Oct 2017 12:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 YuFRDN8fbUb9 for ; Sat, 14 Oct 2017 12:42:15 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 53D6B132C32 for ; Sat, 14 Oct 2017 12:42:15 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id f15so25143054qtf.7 for ; Sat, 14 Oct 2017 12:42:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2dyWgsvdXkTVOeKP8G9gTG2iGuAmfwjrdzUWUcoPLsk=; b=OeEfuBSNSMQe4Rqluq9CN7qhp4YN44DQvrW0tF0FQJvrRgFzJClYE7wZ72fOOGUaVK 5ThfaHXpPPWGH+aGcfk4MC74cIkDlbxj5Hc8qjdK8QiEbQoMROA8BAyh8hEpBIvZn9lJ NoCmmxJ+XycqAy86/SIAIZcu3Kj5c7SfKm4GR80QYgK25qB1HTsqmTiC3yBeWNIXf9ML qd1uvqkdmBdQcbFQRx9PdHahobgDeGWB7IsX4Cfe0ohHjVmWXqvCmaYrqnMeba6jKOwN Ymi3GfdOms9W8ds1wtZF1uySLL59NvNG8zMif6pFjWTvyAd7Ce++3fDG9SZaY56g63to HFVQ==
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=2dyWgsvdXkTVOeKP8G9gTG2iGuAmfwjrdzUWUcoPLsk=; b=G2BiZS6pYYSO6jKonV7xQVCMJ/J9qD88vc1mH67W0KdcYXwhn5mLFGEtuHkgWhGklp NENZwSOcNK8qgkBJbqDK9X2ZXIEM9d239a496FpHLST09igx6ppHj4+Ub6Xn1OTuVGOd b4sPQ0cz0CXw9+v+Aq45xxktHHtGG6c6ZEbZX9jU341izHvTfAwvbVLkljHFesmUkOV4 iZuY6PnCP+dwWl9VJpKyoCFP/TkhvgcbcuyhIqH35GgkpI3CXuSUj/C1fJalBklSGtE9 aYgGrik9erzvullL+qJYcjJPTpQ7rTJ4hWtPoT/TfBkbzwaDyrN2ZqlKxLmdviRyBV2O 4MZw==
X-Gm-Message-State: AMCzsaU+njDAFUy5zzb9PMk2vU2chjzX7d8HntLrnPqJ3wShVWnTi7NB kOv7XGAyUCC/pdaiSKcMYjy62IYJw1fzssMu/P4HaQ==
X-Google-Smtp-Source: AOwi7QB0D6ulcCMMp0C58o7XxBxqH8Uy6PIvt8oXswH0Z0BXgES+AK1DCmBO+kV6UWgDyCB5R0uIDsW+bEck/P+qQek=
X-Received: by 10.200.12.11 with SMTP id k11mr8410268qti.105.1508010134470; Sat, 14 Oct 2017 12:42:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.37.143 with HTTP; Sat, 14 Oct 2017 12:42:13 -0700 (PDT)
In-Reply-To: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
References: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
From: Xufeng Liu 
Date: Sat, 14 Oct 2017 15:42:13 -0400
Message-ID: 
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="089e0822fc0c62043f055b86f805"
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Oct 2017 19:42:17 -0000

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

yes/support.

Thanks.
- Xufeng

On Friday, October 13, 2017, Kent Watsen  wrote:

> All,
>
> Now that we have resolved the module naming issue on the list (i.e.
> that keeps the original rfc module names and updates the unwanted
> legacy nodes to have status 'obsolete'), rather than wait for the
> changes to be made in the individual document, we'd like to move
> ahead with the adoption now, with the understanding that these
> changes will be made in the -01 version of the adopted draft.
>
> This is start of a two-week poll on making draft-acee-netmod-rfc8022bis-03
> 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.
>
> The poll ends Oct 27.
>
> Thanks,
> Kent (and Lou)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod
>

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


yes/support.

Thanks.
- Xufeng
On Friday, October 13, 2017, Kent Watsen <kwatsen@juniper.net> wrote:
All,



Now that we have resolved the module naming issue on the list (i.e.

that keeps the original rfc module names and updates the unwanted

legacy nodes to have status 'obsolete'), rather than wait for the
changes to be made in the individual document, we'd like to move

ahead with the adoption now, with the understanding that these

changes will be made in the -01 version of the adopted draft.



This is start of a two-week poll on making draft-acee-netmod-rfc8022bis-03

a working group document.=C2=A0 Please send email to the list indicating
"yes/support" or "no/do not support".=C2=A0 If indicati=
ng 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<=
br>
document.



The poll ends Oct 27.



Thanks,

Kent (and Lou)



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--089e0822fc0c62043f055b86f805--


From nobody Sat Oct 14 13:11:28 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1702C127005 for ; Sat, 14 Oct 2017 13:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level: 
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 iLcH7PR8twDk for ; Sat, 14 Oct 2017 13:11:25 -0700 (PDT)
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 3274612426E for ; Sat, 14 Oct 2017 13:11:25 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id d10so12993579lfg.11 for ; Sat, 14 Oct 2017 13:11:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YoIs4a4zBeNLUNUr/81VU6oQvNT38bPDvDuJa/yokwY=; b=Y6pFd5L5LpoBRogdSUGAbPRviBXUlJPtj2ULoeLSuxdlNd2aq6XtC5XlxYW7v9rMmH AktuG5p0VRtD8DcCNVOxq7o4q8Mydkvt2IEQya7u8YOOzIdHSP8FiwOm5GHKwsxFhAdo O5xIvhGaCDVbNjHlERiyFhIr/4GBNeqOZ7PHanicSPK9T/H/GnvZHSUUk6g4JTDEMlVu jk9vJtvgVfjOpOHQqBJaVM/eSWDr/Vl9zM2z8bu87isFUEdGZxUFdw5AFPHuZdoJhTkB JwWcMRVY9DDcfQp+uQFGEKYr0RyidkCo9Rk4TG+d0iUwgGDuP8qC3XW3J/AlXnYvCklW vKPw==
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=YoIs4a4zBeNLUNUr/81VU6oQvNT38bPDvDuJa/yokwY=; b=S/Unv3wpQcywFxe92y+PYVDUuHGJTuKEeW9Y9MTAcIlzKla6r5JgaGSHMdsu6fK8LS W9dWJwqGyftiFgqeAuXrAS/2ytGnLxbmwaHgVE+K1d3GDVqGkWB/W3EiMxiE1vQgyetX 4vlggirUL6kRl2U/WnZ2DVKw06zd38JJi5SEdMvitFMBeFDsy2y+F/qHdksfAx0mK+Ny BgefZy8667CBIhgOVPv98lUJ7UNHOkJ33AAfvL+TM7ZGLfMBaoSlH64++37cMnSBeUGb igCqdrc1DpzgujVt32jpaCh/3Zl5X23dG6voBehwvlbOhgpjwFZoc5H06IEKcgYlWMJe gFng==
X-Gm-Message-State: AMCzsaWFzRK24Gd9pIqgvy1Vb6XwpkQxxajQZ/Wy/sP1PCxV+ZbsnNOJ l6P8DUNsbnrZMhNqSywYGnLPOwqVPJ/VLAamj9Wac9YX
X-Google-Smtp-Source: ABhQp+SMTXs5j8/lDmcCRq1JDOSJ/bwr0DoSGkAps4fkkPAxXfiSJRb4a2y47EIoYhW3DN6AicLzXoihXAIssvf4KsE=
X-Received: by 10.46.15.18 with SMTP id 18mr2031083ljp.151.1508011883073; Sat, 14 Oct 2017 13:11:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Sat, 14 Oct 2017 13:11:22 -0700 (PDT)
From: Andy Bierman 
Date: Sat, 14 Oct 2017 13:11:22 -0700
Message-ID: 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1cfe569ba3eb055b8760d4"
Archived-At: 
Subject: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 14 Oct 2017 20:11:27 -0000

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

Hi,

RFC 7950 has no text at all that addresses this specific point:

module if-aug {
  yang-version 1.1;
  namespace "http://netconfcentral.org/ns/if-aug";
  prefix ifa;
  import ietf-interfaces { prefix if; }
  revision "2017-10-14";

  augment "/if:interfaces-state/if:interface" {
    action reset {
      description "Reset this interface";
    }
  }
}

Both pyang and yangdump-pro accept this module with no warnings or errors.
Sec. 12 should address this issue.


Andy

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


Hi,

RFC 7950 has no text at all that ad=
dresses this specific point:

module if-aug {<=
/div>
=C2=A0 yang-version 1.1;
=C2=A0 prefix ifa;
=C2=A0 import ietf-inte=
rfaces { prefix if; }
=C2=A0 revision "2017-10-14";

=C2=A0 augment "/if:interfaces-state/if:interfac=
e" {
=C2=A0 =C2=A0 action reset {
=C2=A0 =C2=A0 =
=C2=A0 description "Reset this interface";
=C2=A0 =C2=
=A0 }
=C2=A0 }
}

Both py=
ang and yangdump-pro accept this module with no warnings or errors.
Sec. 12 should address this issue.


Andy



--94eb2c1cfe569ba3eb055b8760d4--


From nobody Sun Oct 15 00:52:12 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9641326F6 for ; Sun, 15 Oct 2017 00:52:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr6fLKomryH2 for ; Sun, 15 Oct 2017 00:52:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D778B124207 for ; Sun, 15 Oct 2017 00:52:09 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 1BC881AE012C; Sun, 15 Oct 2017 09:52:07 +0200 (CEST)
Date: Sun, 15 Oct 2017 09:52:06 +0200 (CEST)
Message-Id: <20171015.095206.5556973134711466.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Oct 2017 07:52:11 -0000

Andy Bierman  wrote:
> Hi,
> 
> RFC 7950 has no text at all that addresses this specific point:
> 
> module if-aug {
>   yang-version 1.1;
>   namespace "http://netconfcentral.org/ns/if-aug";
>   prefix ifa;
>   import ietf-interfaces { prefix if; }
>   revision "2017-10-14";
> 
>   augment "/if:interfaces-state/if:interface" {
>     action reset {
>       description "Reset this interface";
>     }
>   }
> }
> 
> Both pyang and yangdump-pro accept this module with no warnings or errors.
> Sec. 12 should address this issue.

The intention was that this is legal, but as you note, for some reason
there is no explicit text in 7950 about this.

This was issue Y60, see
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-61.


/martin


From nobody Sun Oct 15 01:50:03 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35631132A89 for ; Sun, 15 Oct 2017 01:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbZF3b6_mdBD for ; Sun, 15 Oct 2017 01:49:59 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101BF13263F for ; Sun, 15 Oct 2017 01:49:58 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQR01900; Sun, 15 Oct 2017 08:49:57 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 15 Oct 2017 09:49:56 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001;  Sun, 15 Oct 2017 01:49:43 -0700
From: Yingzhen Qu 
To: "Acee Lindem (acee)" , Kent Watsen ,  "netmod@ietf.org" 
Thread-Topic: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
Thread-Index: AQHTREUx6dfZtzUXzkCdAPj9I2IarqLknH+g
Date: Sun, 15 Oct 2017 08:49:43 +0000
Message-ID: <594D005A3CB0724DB547CF3E9A9E810BF1FE78@sjceml521-mbx.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.212.245.141]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59E32135.004D, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 73b32041fdc40ca513124528d90ee22b
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Oct 2017 08:50:01 -0000

As co-author, I support and am not aware of any IPR.

Thanks,
Yingzhen

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Acee Lindem (ace=
e)
Sent: Friday, October 13, 2017 10:04 AM
To: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03

As co-author, I support and am not aware of any IPR.
Thanks,
acee=20

On 10/13/17, 10:37 AM, "netmod on behalf of Kent Watsen"
 wrote:

>All,
>
>Now that we have resolved the module naming issue on the list (i.e.
>that keeps the original rfc module names and updates the unwanted=20
>legacy nodes to have status 'obsolete'), rather than wait for the=20
>changes to be made in the individual document, we'd like to move ahead=20
>with the adoption now, with the understanding that these changes will=20
>be made in the -01 version of the adopted draft.
>
>This is start of a two-week poll on making=20
>draft-acee-netmod-rfc8022bis-03 a working group document.  Please send=20
>email to the list indicating "yes/support" or "no/do not support".  If=20
>indicating no, please state your reservations with the document.  If=20
>yes, please also feel free to provide comments you'd like to see=20
>addressed once the document is a WG document.
>
>The poll ends Oct 27.
>
>Thanks,
>Kent (and Lou)
>
>_______________________________________________
>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 Oct 15 09:26:51 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A66A133047; Sun, 15 Oct 2017 09:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 A8L9t9oTqqjZ; Sun, 15 Oct 2017 09:26:40 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F58C132F2E; Sun, 15 Oct 2017 09:26:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34225; q=dns/txt; s=iport; t=1508084800; x=1509294400; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to; bh=OGnrVNSkqIK+AIR1/zMxHig7Xhyfdr6Y6Oa+fOXfXzU=; b=DnelOSiZz3kqP15xw4fPGsbh28uzSZFtpwf/nw6vE/r7Ho190hZg2j20 V7wa+UjQCe6Qf3Vgw5Xr+9QX39qlCwnLdIVevkfKycfzGrIjfxueFFYyQ sP/+ZGIk7n3LtgMGHtgiXjzYVEz3JAqqP0YmlTk/8O6xLa3DqmF2IIv/c U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAAApi+NZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9CgRJuJ4N6ih90kDOWLxCCBAolhRYChRUYAQIBAQEBAQEBayi?= =?us-ascii?q?FHgEFGglOCBAJAg4KIAEJAgJXBgEMBgIBAReKAhCMYp1ngicmiwIBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgy2DWIFqK4J/hE0FARECAYMxgmEFih+CHIUMkAGHX4N?= =?us-ascii?q?iiSqCFF2Ic4cyiiKDbYdggTkfOIEDVjQhCB0VSYJkCYJTHIFpPjYBilsBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,383,1503360000";  d="scan'208,217";a="698031719"
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; 15 Oct 2017 16:26:36 +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 v9FGQaI0004063; Sun, 15 Oct 2017 16:26:36 GMT
From: Benoit Claise 
To: Lou Berger , NetMod WG 
Cc: rtg-dir@ietf.org, draft-acee-netmod-rfc8022bis@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
References:  <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com>
Message-ID: 
Date: Sun, 15 Oct 2017 18:26:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com>
Content-Type: multipart/alternative; boundary="------------86328339758D90C1C732FFA1"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [RTG-DIR] handling module incompatibility => handling module transition
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Oct 2017 16:26:44 -0000

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

On 10/12/2017 3:30 PM, Benoit Claise wrote:
> Hi Lou,
>>
>> So circling back to the original question: what do we do about the 
>> non backward-compatible module being defined in rfc8049bis?
>>
>> While being sympathetic to many of the comments made below as well as 
>> the "do over" concept, I find the comments about adhering to the 
>> rules of 7950 compelling - which leads to renaming the module in the 
>> bis to ietf-l3vpn-svc-2.
>>
>> It would be good to ensure that this is the consensus of the group 
>> before asking the authors make this change.
>>
> Since this draft is AD sponsored, I'll evaluate the consensus on 
> RFC8049bis.
> Moving to ietf-l3vpn-svc-2 is the easy path not to break backward 
> compatibility. However, since ietf-l3vpn-svc is unimplementable (it 
> has broken XPATH expressions, so a compliant implementation is 
> impossible), so technically, ietf-l3vpn-svc does not even exist.
See my message on this topic, as the IETF LC follow up.
https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html
If a follow up is required, I propose that we use a single public email 
thread: the ietf@ietf.org

Regards, Benoit
>
> What NETMOD should focus on is closing on the NMDA transition: the 
> ietf-routing versus ietf-routing-2 issue.
> Way bigger impact in terms of dependent YANG modules
>
> Regards, Benoit (as OPS AD)
> See below.
>>
>> This change course doesn't solve the versioning issue discussed 
>> below, but this is not a new issue it's just the first time we'll 
>> actually executing the steps envisioned as part of the rules laid out 
>> in yang. My personal take away is that means that we should 
>> immediately start work on an extension defining along the lines of  ' 
>> *_obsolete|update_*' mentioned below.
>>
> I believe that option 1 is the more pragmatic and complete solution. 
> option 2 is just half a step in the right direction.
> I believe we should discuss this topic in Singapore.
>
> Regards, Benoit (as individual contributor)
>>
>> Lou
>>
>> On October 8, 2017 10:59:15 AM Benoit Claise  wrote:
>>
>>> Dear all,
>>>
>>> Focusing on draft-wu-l3sm-rfc8049bis, the big problem is: RFC8049 is 
>>> broken. The small problem is: trying to maintain backward compatibility.
>>> draft-wu-l3sm-rfc8049bis has rightly focused on the big problem.
>>>
>>> Let me extend the scope of this email thread from "handling module 
>>> incompatibility" to "handling module incompatibility and NMDA 
>>> transition".
>>> As I mentioned in the past (see "semver.org comparison of two YANG 
>>> modules" email in NETMOD), I believe the IETF will have to change 
>>> its way of working in terms of backward compatibility. See also the 
>>> email "ietf-routing or ietf-routing-2? module naming convention for 
>>> NMDA transition. Re: [netmod] upcoming adoptions" in NETMOD.
>>>
>>> However, we will have to tackle this discussion one day or the other:
>>> - we need _an automatic way_ to make the link between the YANG 
>>> module in RFC8049 and the YANG module in draft-wu-l3sm-rfc8049bis, 
>>> or any non backward compatible YANG modules.
>>> - we need _an automatic way_ to make the link between the YANG 
>>> module in RFC8022 and the YANG module in 
>>> draft-acee-netmod-rfc8022bis, or any new YANG module names used for 
>>> NMDA transition.
>>> Note: actually, we face two different problems. 
>>> draft-wu-l3sm-rfc8049bis might be declared backward incompatible 
>>> with RFC8049, while RFC8022bis is backward compatible with RFC8022. 
>>> The RFC8022bis went for a new YANG module name ietf-routing-2 to 
>>> avoid to document the -state tree (as deprecated), based on the 
>>> argument that ietf-routing is not yet implemented.
>>>
>>> Which solutions do we have from here?
>>> #1. We keep the same module name and express that the YANG module in 
>>> draft-wu-l3sm-rfc8049bis is not backward compatible with the RFC8049 
>>> one. This is the openconfig way. See 
>>> draft-clacla-netmod-model-catalog (and 
>>> draft-openconfig-netmod-model-catalog before)
>>>
>>>        // extension statements
>>>           extension openconfig-version {
>>>             argument "semver" {
>>>               yin-element false;
>>>             }
>>>             description
>>>               "The OpenConfig version number for the module. This is
>>>               expressed as a semantic version number of the form:
>>>                 x.y.z
>>>                where:
>>>                 * x corresponds to the major version,
>>>                 * y corresponds to a minor version,
>>>                 * z corresponds to a patch version.
>>>               This version corresponds to the model file within which it is
>>>               defined, and does not cover the whole set of OpenConfig models.
>>>               Where several modules are used to build up a single block of
>>>               functionality, the same module version is specified across each
>>>               file that makes up the module.
>>>
>>>               A major version number of 0 indicates that this model is still
>>>               in development (whether within OpenConfig or with industry
>>>               partners), and is potentially subject to change.
>>>
>>>               Following a release of major version 1, all modules will
>>>               increment major revision number where backwards incompatible
>>>               changes to the model are made.
>>>
>>>               The minor version is changed when features are added to the
>>>               model that do not impact current clients use of the model.
>>>
>>>               The patch-level version is incremented when non-feature changes
>>>               (such as bugfixes or clarifications to human-readable
>>>               descriptions that do not impact model functionality) are made
>>>               that maintain backwards compatibility.
>>>
>>>               The version number is stored in the module meta-data.";
>>>           }
>>>
>>> Similarly, we always keep the same YANG module name in case of NMDA 
>>> transition. So ietf-routing-2 should be changed back to ietf-routing.
>>> The email thread "[Rtg-dt-yang-arch] ietf-routing or ietf-routing-2? 
>>> module naming convention for NMDA transition. Re: [netmod] upcoming 
>>> adoptions" seems to go in that direction.
>>>
>>> #2. Or we have a different module name, let's say ietf-l3vpn-svc-2 
>>> or ietf-routing-2 but then, how do we make the link with the 
>>> previous module?
>>> Then ...  What? We create extension that will link the 
>>> draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG module? 
>>> Same principle as #1, but just more complex.
>>> Or we have a new YANG keyword (this implies YANG 2.0)
>>>
>>>     file"ietf-l3vpn-svc@2017-09-14.yang"
>>>     module ietf-l3vpn-svc-2 {
>>>       yang-version 1.1;
>>>       namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
>>>       prefix l3vpn-svc;
>>>       *_obsolete|update _*ietf-l3vpn-svc@2017-01-2
>>>
>>> And whose responsibility is this to warn/push all authors of 
>>> ietf-routing YANG modules to move to ietf-routing-2? (*)
>>>
>>> The following are non solution IMO:
>>> - Going from the draft-wu-l3sm-rfc8049bis YANG _module _to the 
>>> draft-wu-l3sm-rfc8049bis _document _to lookup the IETF "obsolete" 
>>> flag in order to understand that the RFC8049 YANG module is obsolete 
>>> is not an automatic solution.
>>> - Using the yangcatalog.org might be a solution as we track the 
>>> derived semantic, but this is just an offline trick. This is not 
>>> what I call "automatic way"
>>> - Using the YANG module description field might be interesting, but 
>>> again this is not an "automatic way":
>>>
>>>       description
>>>        "This YANG module defines a generic service configuration
>>>         model for Layer 3 VPNs. This model is common across all
>>>         vendor implementations. This obsoletes the RFC8049 YANG
>>>         module, ietf-l3vpn-svc@2017-01-2";
>>>       revision 2017-09-14 {
>>>        description
>>>        
>>>     "First revision ofRFC8049 .";
>>>        reference
>>>         "RFC xxxx: YANG Data Model for L3VPN Service Delivery";
>>>
>>>
>>> In conclusion, I believe openconfig got this right and that solution 
>>> #1 is the solution to go ... while waiting for a new YANG keyword in 
>>> YANG 2.0
>>>
>>> (*) If you want to change the module from ietf-routing to 
>>> ietf-routing-2, then you should follow with all authors of dependent 
>>> modules to make sure they transition to ietf-routing-2
>>> In the yangcatalog.org, because I needed the information as OPS AD, 
>>> we created a small script to get that authors list for IETF drafts. 
>>> For the ietf-routing, this produces the following
>>> {
>>>     "output": {
>>>         "author-email": [
>>> "draft-ietf-mpls-static-yang@ietf.org",
>>> "draft-ietf-mpls-base-yang@ietf.org",
>>> "draft-ietf-ospf-sr-yang@ietf.org",
>>> "draft-ietf-pim-yang@ietf.org",
>>> "draft-ietf-bier-bier-yang@ietf.org",
>>> "draft-zhang-bier-te-yang@ietf.org",
>>> "draft-ietf-isis-yang-isis-cfg@ietf.org",
>>> "draft-ietf-teas-yang-rsvp-te@ietf.org",
>>> "draft-ietf-mpls-mldp-yang@ietf.org",
>>> "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",
>>> "draft-ietf-isis-sr-yang@ietf.org",
>>> "draft-acee-rtgwg-yang-rib-extend@ietf.org",
>>> "draft-ietf-pim-igmp-mld-yang@ietf.org",
>>> "draft-ietf-i2rs-fb-rib-data-model@ietf.org",
>>> "draft-ietf-ospf-yang@ietf.org",
>>> "draft-ietf-rtgwg-yang-rip@ietf.org",
>>> "draft-ietf-spring-sr-yang@ietf.org",
>>> "draft-ietf-teas-yang-rsvp@ietf.org",
>>> "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",
>>> "draft-ietf-mpls-ldp-yang@ietf.org",
>>> "draft-ietf-bfd-yang@ietf.org",
>>> "draft-ietf-pim-msdp-yang@ietf.org"
>>>         ]
>>>     }
>>> }
>>>
>>> Fortunately, we only deal with IETF dependent YANG modules in case 
>>> of the ietf-routing. That's an easier case.
>>> If we would change ietf-interfaces to ietf-interfaces-2, we would 
>>> have an cross SDO issue ... Btw, there are no automatic ways to 
>>> extract the authors of YANG modules from different SDOs: it's only a 
>>> metadata that that the different SDOs should insert in the 
>>> yangcatalog. So we would have to rely on liaisons or direct emails, 
>>> assuming we know the authors. Time consuming, believe me.
>>>
>>> Regards, Benoit
>>>> Hi,
>>>>
>>>>      As part of the my Routing Directorate review of
>>>> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
>>>> changes being made to the ietf-l3vpn-svc module without changing the
>>>> name.  I raised this with the YANG doctors and others involved with the
>>>> draft and it surfaced some topics which really should be discussed here
>>>> in NetMod.
>>>>
>>>> The background (as explained off-list by others, so I hope I have it
>>>> right)  is that one of the YANG Doctors noted that RFC8049 was broken
>>>> and could not be implemented as defined, and therefore a fix was
>>>> needed.  L3SM has concluded so the fix is in the individual draft
>>>> draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
>>>> module could not be implemented, the feeling by the YANG Dr was that
>>>> even though the new module is incompatible with the original definition
>>>> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
>>>> RFC 6020) didn't have to be followed and the same name could be used.
>>>>
>>>> In the subsequent discussion with the YANG Drs., the general discussion
>>>> was heading down the path of using a new module name, and thereby not
>>>> violating YANG module update rules.  This lead us back to the a similar
>>>> discussion we've been having in the context of 8022bis: how best to
>>>> indicate that a whole module is being obsoleted.  RFCs do this by adding
>>>> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
>>>> help YANG tooling.  For 8022, we have one approach - publishing an
>>>> updated rev of the original module marking all nodes as deprecated - but
>>>> that doesn't really make sense for rfc8049bis.
>>>>
>>>> So the discussion for the WG is:
>>>>
>>>> How do we handle incompatible module changes, notably when one module
>>>> 'obsoletes' another module --  from both the process and tooling
>>>> perspectives?
>>>>
>>>> I know Benoit plans to bring in some thoughts/proposals, perhaps there
>>>> are others.
>>>>
>>>> Cheers,
>>>>
>>>> Lou
>>>>
>>>> (as contributor/reviewer)
>>>>
>>>>
>>>>
>>>>
>


--------------86328339758D90C1C732FFA1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10/12/2017 3:30 PM, Benoit Claise
      wrote:

    

    

      
      
Hi Lou,

      

      

        

          

            
So circling back
              to the original question: what do we do about the non
              backward-compatible module being defined in rfc8049bis?

            
While being
              sympathetic to many of the comments made below as well as
              the "do over" concept, I find the comments about adhering
              to the rules of 7950 compelling - which leads to renaming
              the module in the bis to ietf-l3vpn-svc-2.

            
It would be good
              to ensure that this is the consensus of the group before
              asking the authors make this change.

          

        

      

      Since this draft is AD sponsored, I'll evaluate the consensus on
      RFC8049bis.

      Moving to ietf-l3vpn-svc-2 is the easy path not to break backward
      compatibility. However, since ietf-l3vpn-svc is unimplementable
      (it has broken XPATH expressions, so a compliant implementation is
      impossible), so technically, ietf-l3vpn-svc does not even exist. 

    

    See my message on this topic, as the IETF LC follow up.

       
https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html

    If a follow up is required, I propose that we use a single public
    email thread: the ietf@ietf.org

    

    Regards, Benoit

    
 

      What NETMOD should focus on is closing on the NMDA transition: the
      ietf-routing versus ietf-routing-2 issue. 

      Way bigger impact in terms of dependent YANG modules

      

      Regards, Benoit (as OPS AD)

      See below.

      

        

          

            
This change
              course doesn't solve the versioning issue discussed below,
              but this is not a new issue it's just the first time we'll
              actually executing the steps envisioned as part of the
              rules laid out in yang. My personal take away is that
              means that we should immediately start work on an
              extension defining along the lines of  ' obsolete|update'
              mentioned below.

          

        

      

      I believe that option 1 is the more pragmatic and complete
      solution. option 2 is just half a step in the right direction. 

      I believe we should discuss this topic in Singapore.

      

      Regards, Benoit (as individual contributor)

      

        

          

            
Lou

            

          

          

            
On October 8, 2017 10:59:15
              AM Benoit Claise <bclaise@cisco.com>
              wrote:

            

              
Dear all,

                

                Focusing on draft-wu-l3sm-rfc8049bis, the big problem
                is: RFC8049 is broken. The small problem is: trying to
                maintain backward compatibility.

                draft-wu-l3sm-rfc8049bis has rightly focused on the big
                problem.

                

                Let me extend the scope of this email thread from
                "handling module incompatibility" to "handling module
                incompatibility and NMDA transition".

                As I mentioned in the past (see "semver.org comparison
                of two YANG modules" email in NETMOD), I believe the
                IETF will have to change its way of working in terms of
                backward compatibility. See also the email "ietf-routing
                or ietf-routing-2? module naming convention for NMDA
                transition. Re: [netmod] upcoming adoptions" in NETMOD.
                

                

                However, we will have to tackle this discussion one day
                or the other: 

                - we need an automatic way to make the link
                between the YANG module in RFC8049 and the YANG module
                in draft-wu-l3sm-rfc8049bis, or any non backward
                compatible YANG modules.

                - we need an automatic way to make the link
                between the YANG module in RFC8022 and the YANG module
                in draft-acee-netmod-rfc8022bis, or any new YANG module
                names used for NMDA transition.

                Note: actually, we face two different problems.
                draft-wu-l3sm-rfc8049bis might be declared backward
                incompatible with RFC8049, while RFC8022bis is backward
                compatible with RFC8022. The RFC8022bis went for a new
                YANG module name ietf-routing-2 to avoid to document the
                -state tree (as deprecated), based on the argument that
                ietf-routing is not yet implemented.

                

                Which solutions do we have from here? 

                #1. We keep the same module name and express that the
                YANG module in draft-wu-l3sm-rfc8049bis is not backward
                compatible with the RFC8049 one. This is the openconfig
                way. See draft-clacla-netmod-model-catalog (and
                draft-openconfig-netmod-model-catalog before)

                
                

                  
  // extension statements
     extension openconfig-version {
       argument "semver" {
         yin-element false;
       }
       description
         "The OpenConfig version number for the module. This is
         expressed as a semantic version number of the form:
           x.y.z
          where:
           * x corresponds to the major version,
           * y corresponds to a minor version,
           * z corresponds to a patch version.
         This version corresponds to the model file within which it is
         defined, and does not cover the whole set of OpenConfig models.
         Where several modules are used to build up a single block of
         functionality, the same module version is specified across each
         file that makes up the module.

         A major version number of 0 indicates that this model is still
         in development (whether within OpenConfig or with industry
         partners), and is potentially subject to change.

         Following a release of major version 1, all modules will
         increment major revision number where backwards incompatible
         changes to the model are made.

         The minor version is changed when features are added to the
         model that do not impact current clients use of the model.

         The patch-level version is incremented when non-feature changes
         (such as bugfixes or clarifications to human-readable
         descriptions that do not impact model functionality) are made
         that maintain backwards compatibility.

         The version number is stored in the module meta-data.";
     }

                

                Similarly, we always keep the same YANG module name in
                case of NMDA transition. So ietf-routing-2 should be
                changed back to ietf-routing.

                The email thread "[Rtg-dt-yang-arch] ietf-routing or
                ietf-routing-2? module naming convention for NMDA
                transition. Re: [netmod] upcoming adoptions" seems to go
                in that direction.

                

                #2. Or we have a different module name, let's say
                ietf-l3vpn-svc-2 or ietf-routing-2 but then, how do we
                make the link with the previous module? 

                Then ...  What? We create extension that will link the
                draft-wu-l3sm-rfc8049bis YANG module to the RFC8049 YANG
                module? Same principle as #1, but just more complex. 

                Or we have a new YANG keyword (this implies YANG 2.0)

                

                  
<CODE BEGINS>file "ietf-l3vpn-svc@2017-09-14.yang"
module ietf-l3vpn-svc-2 {
 yang-version 1.1;
 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
 prefix l3vpn-svc;
 obsolete|update ietf-l3vpn-svc@2017-01-2


                

                And whose responsibility is this to warn/push all
                authors of ietf-routing YANG modules to move to
                ietf-routing-2? (*)

                

                The following are non solution IMO:

                - Going from the draft-wu-l3sm-rfc8049bis YANG module
                to the draft-wu-l3sm-rfc8049bis document to
                lookup the IETF "obsolete" flag in order to understand
                that the RFC8049 YANG module is obsolete is not an
                automatic solution.

                - Using the yangcatalog.org might be a solution as we
                track the derived semantic, but this is just an offline
                trick. This is not what I call "automatic way"

                - Using the YANG module description field might be
                interesting, but again this is not an "automatic way":

                

                  
 description
  "This YANG module defines a generic service configuration
   model for Layer 3 VPNs. This model is common across all
   vendor implementations. This obsoletes the RFC8049 YANG 
   module, ietf-l3vpn-svc@2017-01-2";
 revision 2017-09-14 {
  description
  
"First revision of RFC8049.";
  reference
   "RFC xxxx: YANG Data Model for L3VPN Service Delivery";

                

                

                In conclusion, I believe openconfig got this right and
                that solution #1 is the solution to go ... while waiting
                for a new YANG keyword in YANG 2.0

                

                (*) If you want to change the module from ietf-routing
                to ietf-routing-2, then you should follow with all
                authors of dependent modules to make sure they
                transition to ietf-routing-2

                In the yangcatalog.org, because I needed the information
                as OPS AD, we created a small script to get that authors
                list for IETF drafts. For the ietf-routing, this
                produces the following

                {

                    "output": {

                        "author-email": [

                            "draft-ietf-mpls-static-yang@ietf.org",

                            "draft-ietf-mpls-base-yang@ietf.org",

                            "draft-ietf-ospf-sr-yang@ietf.org",

                            "draft-ietf-pim-yang@ietf.org",

                            "draft-ietf-bier-bier-yang@ietf.org",

                            "draft-zhang-bier-te-yang@ietf.org",

                            "draft-ietf-isis-yang-isis-cfg@ietf.org",

                            "draft-ietf-teas-yang-rsvp-te@ietf.org",

                            "draft-ietf-mpls-mldp-yang@ietf.org",

                            "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",

                            "draft-ietf-isis-sr-yang@ietf.org",

                            "draft-acee-rtgwg-yang-rib-extend@ietf.org",

                            "draft-ietf-pim-igmp-mld-yang@ietf.org",

                            "draft-ietf-i2rs-fb-rib-data-model@ietf.org",

                            "draft-ietf-ospf-yang@ietf.org",

                            "draft-ietf-rtgwg-yang-rip@ietf.org",

                            "draft-ietf-spring-sr-yang@ietf.org",

                            "draft-ietf-teas-yang-rsvp@ietf.org",

                            "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",

                            "draft-ietf-mpls-ldp-yang@ietf.org",

                            "draft-ietf-bfd-yang@ietf.org",

                            "draft-ietf-pim-msdp-yang@ietf.org"

                        ]

                    }

                }

                

                Fortunately, we only deal with IETF dependent YANG
                modules in case of the ietf-routing. That's an easier
                case.

                If we would change ietf-interfaces to ietf-interfaces-2,
                we would have an cross SDO issue ... Btw, there are no
                automatic ways to extract the authors of YANG modules
                from different SDOs: it's only a metadata that that the
                different SDOs should insert in the yangcatalog. So we
                would have to rely on liaisons or direct emails,
                assuming we know the authors. Time consuming, believe
                me.

                

                Regards, Benoit

              

              

                
Hi,

    As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name.  I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.

The background (as explained off-list by others, so I hope I have it
right)  is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed.  L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis.  Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.

In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules.  This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted.  RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling.  For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.

So the discussion for the WG is:

How do we handle incompatible module changes, notably when one module
'obsoletes' another module --  from both the process and tooling
perspectives?

I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.

Cheers,

Lou

(as contributor/reviewer)






              

            

          

        

      

      

    

    

  


--------------86328339758D90C1C732FFA1--


From nobody Sun Oct 15 12:56:48 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01ED81331DC for ; Sun, 15 Oct 2017 12:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f6PdK5tCQ_H for ; Sun, 15 Oct 2017 12:56:45 -0700 (PDT)
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 BF6F21331E3 for ; Sun, 15 Oct 2017 12:56:44 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id 75so14748982lfx.1 for ; Sun, 15 Oct 2017 12:56:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=swIwJHJTapN7zi/KOqUoXYghs1VUZAXDQXQRh811KDs=; b=M743Okb6bI5GLoidp6u9ZOmaOQP0kmcph1YoPLm1wkOXvwn1CrYH/kJOLOBqMsMM2W 3OYS06Avhg3iktmBeMTu/xLA5y/DcPgBjBK2ZagvgOSF5O8VbTtAElHEzgwjkIOBq0mg RqJoBl/uRvklQsKoVDQRNlwdxKR3LXEiIPVlJnuwdx9mDK8Cq7N+Oztd3RfHhjyIFy/a fHo3+iUgtKo2U0l5Rc/F+Ldpr3Pufyv24HJlIfUkRIYrClwmpWlGd1bKVeZzHUlt/eX8 81pERtCkhXaHVVsyN28QWWe+26E/HQT6X1BHihE8Q3I52xRRIcBQqlrV26aPqcqtQV4k iTLQ==
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=swIwJHJTapN7zi/KOqUoXYghs1VUZAXDQXQRh811KDs=; b=d46tjkZZike76mmCk3GoMhMJJswRkhmNINM008y2wzr71wORO2ZUdS4DILDKQQqPV0 zRt5ODZpw0tpFD19zhrhSc3r90dIC0bokx2jjk9XZ8WpC1qe3hVNOCiDNSER8iYa6Gbf 1G0oX0rM+TeryX7DVFPjaEn5wKorAeXnBWtGGr+wx9a+2LeWMw5tDmc+kAICJaF6i5M1 zrVoAS8CuYCczOQ41LFGXU4yCdmOJRYVnx6x0u3bhNhSmv8Hh0jj5QOhEqjArR2Ziq7k T3nENJKZih+iVFRvyTd3zTOF4KnWegWvmTKn/eAnWxlS5NTHJLUustPRPDRIn00brDLe POEw==
X-Gm-Message-State: AMCzsaWwuTiyq5mzkoKLkwYUUZtKDtbHtfWi6Zu5nqqVDOqzoMOJ+Dbd cn+s5y9veZqZjs1mA3IopVFQWp/ZNT+qM1f1yw2gEVOd
X-Google-Smtp-Source: ABhQp+SBzPPodECEYC7+UHop+GwT+DhMqpNX+VDTytGgIGs9E6y55uHDNhM/zW4yPjwDGCSkT9d0qAH7cJF7bFei3wE=
X-Received: by 10.46.101.4 with SMTP id z4mr2918937ljb.42.1508097402752; Sun, 15 Oct 2017 12:56:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Sun, 15 Oct 2017 12:56:42 -0700 (PDT)
In-Reply-To: <20171015.095206.5556973134711466.mbj@tail-f.com>
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>
From: Andy Bierman 
Date: Sun, 15 Oct 2017 12:56:42 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114d31eafa603f055b9b499f"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Oct 2017 19:56:47 -0000

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

On Sun, Oct 15, 2017 at 12:52 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > Hi,
> >
> > RFC 7950 has no text at all that addresses this specific point:
> >
> > module if-aug {
> >   yang-version 1.1;
> >   namespace "http://netconfcentral.org/ns/if-aug";
> >   prefix ifa;
> >   import ietf-interfaces { prefix if; }
> >   revision "2017-10-14";
> >
> >   augment "/if:interfaces-state/if:interface" {
> >     action reset {
> >       description "Reset this interface";
> >     }
> >   }
> > }
> >
> > Both pyang and yangdump-pro accept this module with no warnings or
> errors.
> > Sec. 12 should address this issue.
>
> The intention was that this is legal, but as you note, for some reason
> there is no explicit text in 7950 about this.
>
>

that's what I thought.

Can you spot the NMDA problem above?
Actually, it exists for in-line definitions, not just augment.

Once you collapse the interfaces-state tree into /interfaces, there is no
way to
specify whether an action is intended for  or a configuration
datastore,
or all datastores.

The parent container or list may be config=true just because the foo-state
tree
was taken away, and the moved action effectively changed from config=false
to config=true.

There is no way for the YANG action-stmt to specify a datastore (or
config-stmt)
There is no way for the  operation to specify a datastore.


This was issue Y60, see
> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-61.
>
>
> /martin
>


Andy

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




On Sun, Oct 15, 2017 at 12:52 AM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Andy B=
ierman <andy@yumaworks.com>=
 wrote:

> Hi,

>

> RFC 7950 has no text at all that addresses this specific point:

>

> module if-aug {

>=C2=A0 =C2=A0yang-version 1.1;

>=C2=A0 =C2=A0namespace "http://netconfcentral.org/ns/if-aug";

>=C2=A0 =C2=A0prefix ifa;

>=C2=A0 =C2=A0import ietf-interfaces { prefix if; }

>=C2=A0 =C2=A0revision "2017-10-14";

>

>=C2=A0 =C2=A0augment "/if:interfaces-state/if:interface"=
 {

>=C2=A0 =C2=A0 =C2=A0action reset {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0description "Reset this interface"=
;

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

>=C2=A0 =C2=A0}

> }

>

> Both pyang and yangdump-pro accept this module with no warnings or err=
ors.

> Sec. 12 should address this issue.



The intention was that this is legal, but as you note, for some reason

there is no explicit text in 7950 about this.




that's what I thoug=
ht.

Can you spot the NMDA problem above?
Actually, it exists for in-line definitions, not just augment.
<=
br>
Once you collapse the interfaces-state tree into /interfaces,=
 there is no way to
specify whether an action is intended for=
 <operational> or a configuration datastore,
or all datasto=
res.

The parent container or list may be config=3D=
true just because the foo-state tree
was taken away, and the move=
d action effectively changed from config=3Dfalse to config=3Dtrue.

There is no way for the YANG action-stmt to specify a data=
store (or config-stmt)
There is no way for the <action>=
 operation to specify a datastore.



This was issue Y60, see

http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-61.





/martin




<=
/div>
Andy



--001a114d31eafa603f055b9b499f--


From nobody Sun Oct 15 23:20:47 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC0B1342E8; Sun, 15 Oct 2017 23:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.819
X-Spam-Level: 
X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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, 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 oY4WCZ_U8HXt; Sun, 15 Oct 2017 23:20:43 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5811342EB; Sun, 15 Oct 2017 23:20:42 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXU51401; Mon, 16 Oct 2017 06:20:39 +0000 (GMT)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 16 Oct 2017 07:20:38 +0100
Received: from DGGEML504-MBX.china.huawei.com ([169.254.12.200]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Mon, 16 Oct 2017 14:20:33 +0800
From: wangzitao 
To: "netmod@ietf.org" , "netmod-chairs@ietf.org" 
Thread-Topic: Netmod IETF 100 Slot Requests - Singapore
Thread-Index: AdNGRruvF1ZMKrj/TPeolXDVSpZXww==
Date: Mon, 16 Oct 2017 06:20:33 +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: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2B888C08DGGEML504MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59E44FB8.00B0, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.12.200, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 5dd2813a06885bb6850120925a76854b
Archived-At: 
Subject: [netmod] Netmod IETF 100 Slot Requests - Singapore
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Oct 2017 06:20:45 -0000

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2B888C08DGGEML504MBXchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Netmod WG,

It's that time again!

The IETF 100 Preliminary Agenda has been published; you can find it at http=
s://datatracker.ietf.org/meeting/100/agenda.html
NETMOD will be meeting: 13:30-15:00 and 15:20-16:50 on Wednesday.
If you'd like a slot to present some documents, please send a request to Ch=
airs and me.
Kindly reminder, the deadline for draft submission is UTC 23:59 on 2017-10-=
30 (Monday).

Best Regards!

-Michael


--_000_E6BC9BBCBCACC246846FC685F9FF41EA2B888C08DGGEML504MBXchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear Netmod WG,


 


It's that time agai=
n!


The IETF 100 Pre=
liminary Agenda has been published; you can find it at
htt=
ps://datatracker.ietf.org/meeting/100/agenda.html


NETMOD will be meet=
ing: 13:30-15:00 and 15:20-16:50 on Wednesday.


If you'd like a slo=
t to present some documents, please send a request to Chairs and me.



Kindly reminder, th=
e deadline for draft submission is UTC 23:59 on
2017-10-30 (Monday).


 


Best Regards!<=
/o:p>


 


-Michael 


 






--_000_E6BC9BBCBCACC246846FC685F9FF41EA2B888C08DGGEML504MBXchi_--


From nobody Sun Oct 15 23:32:00 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878611342F3 for ; Sun, 15 Oct 2017 23:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.5
X-Spam-Level: *
X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_SORBS_WEB=1.5, 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 TyKclgmdeanS for ; Sun, 15 Oct 2017 23:31:58 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C78911321DF for ; Sun, 15 Oct 2017 23:31:57 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 0300C1820F78; Mon, 16 Oct 2017 08:31:36 +0200 (CEST)
Received: from localhost (ip-213-135-236-32.static.luxdsl.pt.lu [213.135.236.32]) by trail.lhotka.name (Postfix) with ESMTPSA id 43B941820E70; Mon, 16 Oct 2017 08:31:32 +0200 (CEST)
From: Ladislav Lhotka 
To: Kent Watsen , "netmod\@ietf.org" 
In-Reply-To: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
References: <88288A22-2EF7-4491-A93A-2181ADACF994@juniper.net>
Mail-Followup-To: Kent Watsen , "netmod\@ietf.org" 
Date: Mon, 16 Oct 2017 08:32:43 +0200
Message-ID: <874lqz61ro.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Oct 2017 06:31:59 -0000

As a co-author, I support the adoption.

Lada

Kent Watsen  writes:

> All,
>
> Now that we have resolved the module naming issue on the list (i.e. 
> that keeps the original rfc module names and updates the unwanted
> legacy nodes to have status 'obsolete'), rather than wait for the
> changes to be made in the individual document, we'd like to move
> ahead with the adoption now, with the understanding that these 
> changes will be made in the -01 version of the adopted draft.
>
> This is start of a two-week poll on making draft-acee-netmod-rfc8022bis-03
> 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.
>
> The poll ends Oct 27.
>
> Thanks,
> Kent (and Lou)
>
> _______________________________________________
> 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 Sun Oct 15 23:57:31 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47CF13431D for ; Sun, 15 Oct 2017 23:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tsn6lwcZRvAo for ; Sun, 15 Oct 2017 23:57:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 066E3134316 for ; Sun, 15 Oct 2017 23:57:27 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C8661AE02A7; Mon, 16 Oct 2017 08:57:26 +0200 (CEST)
Date: Mon, 16 Oct 2017 08:55:59 +0200 (CEST)
Message-Id: <20171016.085559.1980566759403577584.mbj@tail-f.com>
To: jason.sterne@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] leafref to lists that contain system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Oct 2017 06:57:30 -0000

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Hi all,
> 
> There are a few threads on the mailing list that touch on the concept
> of system-controlled resources (mostly list entries):
> 
> https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0
> https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w
> https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0
> 
> A few drafts & RFCs also refer to the concept:
> https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
> https://tools.ietf.org/html/rfc7223
> 
> Several vendor implementations have list entries (instance data) that
> are populated by the server and can be referenced (leafref) from other
> places in the configuration.  These system entries are useful
> pre-created policies, interfaces, etc that can then be used (and
> referred-to) by operators in their explicit configuration.
> 
> If those entries are only expected to exist in the 
> datastore, then in theory any references to them in user created
> configuration will cause a validation problem in the candidate/running
> (missing leafref target).
> 
> One solution discussed in the mailing lists is to change every
> reference to lists that could contain a system created entry to a
> "require-instance false" leafref.  But then some useful validation is
> lost.  In many cases the model is more correctly "require-instance
> true" but the set of targets includes the system create entries.
> 
> Another solution discussed is to have the system created entries
> appear in the  datastore (as part of template/expansion).
> That would make validation pass on the intended datastore, but then
> the candidate/running/startup datastores would not be valid (would be
> missing leafref targets if any part of the config refers to system
> created entries).  THis sounds similar to the problem that has been
> discussed in the past about the fact that templates (in the running)
> basically mean the running/candidate aren't necessarily valid (until
> after template expansion, which means only the intended would be
> valid).
> 
> Another approach could be to actually have those system created
> entries show up in running/candidate.  That would ensure that
> references to those entries are valid.

This works if the "system created entries" behave just like any other
entry, i.e., a client (with proper access rigths) can modify and
delete them.

If this is not the case, the next question is what happens if the
client creates its own entry with the same name as a system created
entry?  Is this illegal, or will the user created entry override the
system created entry?

Another question to think about is what happpens with user config that
refers to such a system created entry if a new software image is
loaded where the system created entry is no longer present?


/martin


From nobody Mon Oct 16 03:39:42 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB80133347 for ; Mon, 16 Oct 2017 03:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, 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 zXMgoxqjb7DU for ; Mon, 16 Oct 2017 03:39:38 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD61D1270AB for ; Mon, 16 Oct 2017 03:39:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16404; q=dns/txt; s=iport; t=1508150377; x=1509359977; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=lz+fSCQPGHfejmmHTLWSd2xF3gjM25v12utwkkC2SP8=; b=ZKDyCYmS2DWhmx3Lwf+AFg1xnOF5nrYZQHWjFUqmF33IAMDED4GqziL2 AGn3zButdwdfDmFZZraAht5WJfi/26U1r3UkklU/ZeuT5TNA891Cb1jB7 F/GS+wbTaXiZWoskm/ZmQPULdiClxXMk8YfhQlPNfEW0iUQmCHNn8AsIS k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAADdi+RZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9CgRJuJ44ZdI4LggUikHCFP4IUChgBDIRHTwKFFRgBAgEBAQE?= =?us-ascii?q?BAQFrKIUdAQEBAwEBAStBEAsLEgYuJyIOBgEMBgIBAReJeggQA6xGJosLAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDLYNYghULgj81gkWCKoYKBYoflymHX40MAot?= =?us-ascii?q?ihzKOD4dggTkfOIFZNCEIHRVJgmSEYD82iBMsghYBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,386,1503360000";  d="scan'208,217";a="655475244"
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; 16 Oct 2017 10:39:35 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9GAdZgS012958; Mon, 16 Oct 2017 10:39:35 GMT
To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" 
References: 
From: Robert Wilton 
Message-ID: <63575583-0baa-b0eb-c729-9772988b4f22@cisco.com>
Date: Mon, 16 Oct 2017 11:39:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------30B16A4F56AE45121781F8F5"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] leafref to lists that contain system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Oct 2017 10:39:40 -0000

This is a multi-part message in MIME format.
--------------30B16A4F56AE45121781F8F5
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jason,


On 13/10/2017 19:43, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>
> Hi all,
>
> There are a few threads on the mailing list that touch on the concept 
> of system-controlled resources (mostly list entries):
>
> https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0
>
> https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w
>
> https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0
>
> A few drafts & RFCs also refer to the concept:
>
> https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
>
> https://tools.ietf.org/html/rfc7223
>
> Several vendor implementations have list entries (instance data) that 
> are populated by the server and can be referenced (leafref) from other 
> places in the configuration.  These system entries are useful 
> pre-created policies, interfaces, etc that can then be used (and 
> referred-to) by operators in their explicit configuration.
>
> If those entries are only expected to exist in the  
> datastore, then in theory any references to them in user created 
> configuration will cause a validation problem in the candidate/running 
> (missing leafref target).
>
> One solution discussed in the mailing lists is to change every 
> reference to lists that could contain a system created entry to a 
> “require-instance false” leafref. But then some useful validation is 
> lost.  In many cases the model is more correctly “require-instance 
> true” but the set of targets includes the system create entries.
>

I agree that this is not a good general solution for system created 
configuration that is always expected to exist on the device because 
some of the useful validation is lost.

But I think that this solution does work well were the system created 
entries are truly dynamic in nature, e.g. it seems to work well for the 
topology YANG module where the topology may be explicitly configured, 
but would more normally be learned dynamically from protocol 
interactions, or perhaps be configured via a dynamic configuration protocol.

> Another solution discussed is to have the system created entries 
> appear in the  datastore (as part of template/expansion).  
> That would make validation pass on the intended datastore, but then 
> the candidate/running/startup datastores would not be valid (would be 
> missing leafref targets if any part of the config refers to system 
> created entries).  THis sounds similar to the problem that has been 
> discussed in the past about the fact that templates (in the running) 
> basically mean the running/candidate aren’t necessarily valid (until 
> after template expansion, which means only the intended would be valid).
>

I think that this solution is OK, but not necessarily ideal.

As you say, it means that // may not be 
valid, which I see as quite a big down side.  Longer term, I think that 
it would be a good aim to allow the configuration to be validated off 
the device, if a client desired to do so.


> Another approach could be to actually have those system created 
> entries show up in running/candidate. That would ensure that 
> references to those entries are valid. But if the whole concept of 
> templates just cause the running/candidate to not be valid anyways 
> maybe we wouldn’t worry about the invalid aspect of references to 
> system created list entries ?
>

I know that quite a few implementations do this today, but I'm generally 
not a fan of the system modifying .  It seems that an overall 
architecture is much cleaner if  has a single source of truth 
and hence can be exclusively controlled by the client.

But I also like the approach where the client (rather than the device) 
explicitly writes these default entries into the configuration, if they 
are referenced elsewhere by the configuration, to make the configuration 
"complete".  E.g. if part of the configuration references the loopback0 
interface then also explicitly add the necessary loopback0 configuration 
to instantiate the "loopback0" interface.  When this configuration is 
pushed to the device (i.e. using merge or replace operation semantics) 
then the system should silently accept/ignore the explicit configuration 
to create the loopback0 interface if it already exists on the system.


At the moment, IETF, and other SDOs are busy defining standard YANG 
models, but for those models to end up being truly generic they also 
need to have consistency about which bits of configuration are always 
expected to implicitly exist on the device.  E.g. considering the 
example above of configuration referencing loopback0: if some systems 
automatically create a loopback0 interface and others do not, then a 
generic configuration needs to handle both scenarios.

If IETF standardizes YANG configuration templates, then perhaps it would 
be good to investigate whether some of these "useful default system 
properties" could instead be embodied into one or more standard device 
templates?  These templates could then be explicitly referenced in the 
 configuration.  This may allow  to be small, but 
still allow it to be "complete" and able to be validated off the box.

Thanks,
Rob


> Rgds,
>
> Jason
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------30B16A4F56AE45121781F8F5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Jason,

    

    

    
On 13/10/2017 19:43, Sterne, Jason
      (Nokia - CA/Ottawa) wrote:

    

    

      
      
      
      

        
Hi all,

        
 

        
There are a few threads on the mailing list
          that touch on the concept of system-controlled resources
          (mostly list entries):

        
 

        
https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0

        
https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w

        
https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0

        
 

        
A few drafts & RFCs also refer to the
          concept:

        
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04

        
https://tools.ietf.org/html/rfc7223

        
 

        
Several vendor implementations have list
          entries (instance data) that are populated by the server and
          can be referenced (leafref) from other places in the
          configuration.  These system entries are useful pre-created
          policies, interfaces, etc that can then be used (and
          referred-to) by operators in their explicit configuration.

        
 

        
If those entries are only expected to exist
          in the <operational> datastore, then in theory any
          references to them in user created configuration will cause a
          validation problem in the candidate/running (missing leafref
          target).

        
 

        
One solution discussed in the mailing lists
          is to change every reference to lists that could contain a
          system created entry to a “require-instance false” leafref. 
          But then some useful validation is lost.  In many cases the
          model is more correctly “require-instance true” but the set of
          targets includes the system create entries.

      

    

    

    I agree that this is not a good general solution for system created
    configuration that is always expected to exist on the device because
    some of the useful validation is lost.

    

    But I think that this solution does work well were the system
    created entries are truly dynamic in nature, e.g. it seems to work
    well for the topology YANG module where the topology may be
    explicitly configured, but would more normally be learned
    dynamically from protocol interactions, or perhaps be configured via
    a dynamic configuration protocol.

    

    

      

        

        
 

        
Another solution discussed is to have the
          system created entries appear in the <intended>
          datastore (as part of template/expansion).  That would make
          validation pass on the intended datastore, but then the
          candidate/running/startup datastores would not be valid (would
          be missing leafref targets if any part of the config refers to
          system created entries).  THis sounds similar to the problem
          that has been discussed in the past about the fact that
          templates (in the running) basically mean the
          running/candidate aren’t necessarily valid (until after
          template expansion, which means only the intended would be
          valid).

      

    

    

    I think that this solution is OK, but not necessarily ideal.

    

    As you say, it means that
    <running>/<candidate>/<startup> may not be valid,
    which I see as quite a big down side.  Longer term, I think that it
    would be a good aim to allow the configuration to be validated off
    the device, if a client desired to do so.

    

    

    

      

        

        
 

        
Another approach could be to actually have
          those system created entries show up in running/candidate. 
          That would ensure that references to those entries are valid. 
          But if the whole concept of templates just cause the
          running/candidate to not be valid anyways maybe we wouldn’t
          worry about the invalid aspect of references to system created
          list entries ?

      

    

    

    I know that quite a few implementations do this today, but I'm
    generally not a fan of the system modifying <running>.  It
    seems that an overall architecture is much cleaner if
    <running> has a single source of truth and hence can be
    exclusively controlled by the client.

    

    But I also like the approach where the client (rather than the
    device) explicitly writes these default entries into the
    configuration, if they are referenced elsewhere by the
    configuration, to make the configuration "complete".  E.g. if part
    of the configuration references the loopback0 interface then also
    explicitly add the necessary loopback0 configuration to instantiate
    the "loopback0" interface.  When this configuration is pushed to the
    device (i.e. using merge or replace operation semantics) then the
    system should silently accept/ignore the explicit configuration to
    create the loopback0 interface if it already exists on the system.

    

    

    At the moment, IETF, and other SDOs are busy defining standard YANG
    models, but for those models to end up being truly generic they also
    need to have consistency about which bits of configuration are
    always expected to implicitly exist on the device.  E.g. considering
    the example above of configuration referencing loopback0: if some
    systems automatically create a loopback0 interface and others do
    not, then a generic configuration needs to handle both scenarios.

    

    If IETF standardizes YANG configuration templates, then perhaps it
    would be good to investigate whether some of these "useful default
    system properties" could instead be embodied into one or more
    standard device templates?  These templates could then be explicitly
    referenced in the <running> configuration.  This may allow
    <running> to be small, but still allow it to be "complete" and
    able to be validated off the box.

    

    Thanks,

    Rob

    

    

    

      

        

        
 

        
Rgds,

        
Jason

        
 

      

      

      

      

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


    

    

  


--------------30B16A4F56AE45121781F8F5--


From nobody Mon Oct 16 04:11:49 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA431344B0; Mon, 16 Oct 2017 04:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 k-W4G7POcXmO; Mon, 16 Oct 2017 04:11:47 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612EB128D0D; Mon, 16 Oct 2017 04:11:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4785; q=dns/txt; s=iport; t=1508152306; x=1509361906; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=N9sEdAKO64xdQgGBt05+msOB3U5FCx0RH20lRuyBsiw=; b=eK0/NolEBoOXlcpNJyvRzMNZi2BGmPAul6RBLhtNwEC0/BHX0KFg75Zs +QXkskTW9g16eWNC20FJTdvWMUdYZ+mlL7prFARuzA0ajaiaQmeojAMEr SCtblnhQMTEjxQ6EbXXHI41bcaYjozoPb//rO7UILVcY+9XV26j+hG8Ju w=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAAAek+RZ/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRDbieDeoofdJAQIohFjWoQggQHAxgLhElPAoUVGAECAQEBAQE?= =?us-ascii?q?BAWsohR0BAQEDAQEBIQRHCxALDgoqAgIhBjAGAQwGAgEBigEDDQgQqiqBbTqHP?= =?us-ascii?q?A2DaAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4Pgy2FQisLgnSCXlSBKRKDK4JhAQS?= =?us-ascii?q?YZYgnPIQ9giGBAYgThHkCghJdhRmDWocyjQOIbIE5HziBWTQhCB0VHyqCZAmEW?= =?us-ascii?q?D42ilUBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,386,1503360000";  d="asc'?scan'208";a="658107550"
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 Oct 2017 11:11:44 +0000
Received: from [10.61.172.199] ([10.61.172.199]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9GBBhqi014188; Mon, 16 Oct 2017 11:11:43 GMT
To: Mahesh Jethanandani , internet-drafts@ietf.org
Cc: netmod@ietf.org, i-d-announce@ietf.org
References: <150706796848.30662.11163600742801874248@ietfa.amsl.com> 
From: Eliot Lear 
Message-ID: <74221838-60a7-9088-87c3-3055e2416c8e@cisco.com>
Date: Mon, 16 Oct 2017 13:11:42 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Uhn8r1qmf0E2O2VWc1Urtg32BsLkb55IX"
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-14.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, 16 Oct 2017 11:11:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Uhn8r1qmf0E2O2VWc1Urtg32BsLkb55IX
Content-Type: multipart/mixed; boundary="cD5uEXXFJKcLK1eLIfowPXIRw1dJtI48w";
 protected-headers="v1"
From: Eliot Lear 
To: Mahesh Jethanandani , internet-drafts@ietf.org
Cc: netmod@ietf.org, i-d-announce@ietf.org
Message-ID: <74221838-60a7-9088-87c3-3055e2416c8e@cisco.com>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-14.txt
References: <150706796848.30662.11163600742801874248@ietfa.amsl.com>
 
In-Reply-To: 

--cD5uEXXFJKcLK1eLIfowPXIRw1dJtI48w
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US



On 10/4/17 10:22 PM, Mahesh Jethanandani wrote:
> This version of the drafts addresses the remaining comments we received=
 on the document. In particular, this version of the draft adds support f=
or configuring ACLs under and interface, adds an ability to support stati=
stics under that interface and under ACE, and changed forwarding actions =
from a choice to an identity to enable implementations to add their own.
>
> At this time, we believe the document is ready for LC.

Yes please.

Eliot


>
> Thanks.
>
>> On Oct 3, 2017, at 2:59 PM, internet-drafts@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
>> This draft is a work item of the Network Modeling WG of the IETF.
>>
>>        Title           : Network Access Control List (ACL) YANG Data M=
odel
>>        Authors         : Mahesh Jethanandani
>>                          Lisa Huang
>>                          Sonal Agarwal
>>                          Dana Blair
>> 	Filename        : draft-ietf-netmod-acl-model-14.txt
>> 	Pages           : 55
>> 	Date            : 2017-10-03
>>
>> 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-14
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-14
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-14
>>
>>
>> Please note that it may take a couple of minutes from the time of subm=
ission
>> 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
>



--cD5uEXXFJKcLK1eLIfowPXIRw1dJtI48w--

--Uhn8r1qmf0E2O2VWc1Urtg32BsLkb55IX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ5JPvAAoJEIe2a0bZ0nozHS4IALw0YpA2AqC0YNEb3ASrXCqx
P2lCuhdVCfua2CrGG8jKu9lJD49Ur+QOT6HiZ9MNGedfqKlkSW36gWhdeij4lIio
UOjFi+M7vDSn9JdwPCEU1ibcuA1gz6ClagUQomfhE327TekhefwFS22ZeI9u/bnB
3A3QkuulVtE+oiVcupHLlgYcBF9GXl/zaq3g6vWLWNL+hBLx4RR3/7ObBCXQOlk3
zkwKq7nxakWVKmop8w0STQdz+W4BwV0L0Sh15chvotPNtl4BFWhj8ryo8MM1oDCY
g7Xy0kipCwfAO7USYD9W7gRPs8C9eUD/QkZaP+lYixWUeLQfc3ARu+FT9bTAg5E=
=Hla9
-----END PGP SIGNATURE-----

--Uhn8r1qmf0E2O2VWc1Urtg32BsLkb55IX--


From nobody Mon Oct 16 06:14:26 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B17D132F7C; Mon, 16 Oct 2017 06:14:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150815966458.462.13694909481110247994@ietfa.amsl.com>
Date: Mon, 16 Oct 2017 06:14:24 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-entity-05.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, 16 Oct 2017 13:14:25 -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 Hardware Management
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Jie Dong
                          Dan Romascanu
	Filename        : draft-ietf-netmod-entity-05.txt
	Pages           : 38
	Date            : 2017-10-16

Abstract:
   This document defines a YANG data model for the management of
   hardware on a single server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-05
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-05


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Oct 16 06:18:37 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08AD1344EC for ; Mon, 16 Oct 2017 06:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rJzl3kQQJCOd for ; Mon, 16 Oct 2017 06:18:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E4A9D1344E9 for ; Mon, 16 Oct 2017 06:18:33 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id C6A0D1AE02A7 for ; Mon, 16 Oct 2017 15:18:32 +0200 (CEST)
Date: Mon, 16 Oct 2017 15:17:05 +0200 (CEST)
Message-Id: <20171016.151705.215041201688340226.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <150815966458.462.13694909481110247994@ietfa.amsl.com>
References: <150815966458.462.13694909481110247994@ietfa.amsl.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-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: Mon, 16 Oct 2017 13:18:36 -0000

Hi,

This version fixes some terminology, and addresses the issue about
parent-rel-pos according to the proposal in the email thread "What is
the best way to HW identities".

I think that this document is now ready for WGLC.


/martin


internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Modeling WG of the IETF.
> 
>         Title           : A YANG Data Model for Hardware Management
>         Authors         : Andy Bierman
>                           Martin Bjorklund
>                           Jie Dong
>                           Dan Romascanu
> 	Filename        : draft-ietf-netmod-entity-05.txt
> 	Pages           : 38
> 	Date            : 2017-10-16
> 
> Abstract:
>    This document defines a YANG data model for the management of
>    hardware on a single server.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-entity-05
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Mon Oct 16 06:24:25 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD371344DB; Mon, 16 Oct 2017 06:24:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150816026378.438.5678127415431643103@ietfa.amsl.com>
Date: Mon, 16 Oct 2017 06:24:23 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7277bis-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, 16 Oct 2017 13:24:24 -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 IP Management
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-rfc7277bis-00.txt
	Pages           : 32
	Date            : 2017-10-15

Abstract:
   This document defines a YANG data model for management of IP
   implementations.  The data model includes configuration and system
   state.  This document obsoletes RFC 7277.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc7277bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7277bis-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 Oct 16 06:25:20 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7721344DB; Mon, 16 Oct 2017 06:25:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150816031335.361.5502199125107554231@ietfa.amsl.com>
Date: Mon, 16 Oct 2017 06:25:13 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-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, 16 Oct 2017 13:25: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           : A YANG Data Model for Interface Management
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-rfc7223bis-00.txt
	Pages           : 47
	Date            : 2017-10-15

Abstract:
   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface-type-specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes definitions for configuration and system
   state (status information and counters for the collection of
   statistics).  This document obsoletes RFC 7223.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-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 Oct 16 12:04:53 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EBF134563 for ; Mon, 16 Oct 2017 12:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxLwMSN42HAz for ; Mon, 16 Oct 2017 12:04:51 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A2413456C for ; Mon, 16 Oct 2017 12:04:51 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5FA26B80E0F; Mon, 16 Oct 2017 12:04:31 -0700 (PDT)
To: mbj@tail-f.com, bclaise@cisco.com, warren@kumari.net, kwatsen@juniper.net,  lberger@labn.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: andy@yumaworks.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20171016190431.5FA26B80E0F@rfc-editor.org>
Date: Mon, 16 Oct 2017 12:04:31 -0700 (PDT)
Archived-At: 
Subject: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Oct 2017 19:04:52 -0000

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5157

--------------------------------------
Type: Technical
Reported by: Andy Bierman 

Section: 14

Original Text
-------------
  key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string

Corrected Text
--------------
  key-predicate-expr  = node-identifier *WSP "=" *WSP 
        (quoted-string / integer-value / decimal-value)

Notes
-----
An instance identifier is forced to specify every key value to be a string
even though the YANG key leaf type could be a numeric type.
XPath does not require a quoted string here, just YANG.

Old:  /top/list[idx="4"]
New: /top/list[idx=4]

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Mon Oct 16 22:12:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9C132949 for ; Mon, 16 Oct 2017 22:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMrWZOdkyxoT for ; Mon, 16 Oct 2017 22:12:48 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312B3132924 for ; Mon, 16 Oct 2017 22:12:47 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQT93382; Tue, 17 Oct 2017 05:12:44 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 06:12:43 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.105]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 17 Oct 2017 13:04:56 +0800
From: Qin Wu 
To: NetMod WG 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTRl0k7vUwulvIVEqGWP7/9n94aaLnavqg
Date: Tue, 17 Oct 2017 05:04:56 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.79.163]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9ABF4F91nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59E5914D.0078, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 5fcc494bb5ef979f6997c9a15e26cdc5
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 05:12:50 -0000

--_000_B8F9A780D330094D99AF023C5877DABA9ABF4F91nkgeml513mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have reviewed this draft and have the following comments to this draft:

1.      I want to understand the relationship between draft-dsdt-nmda-guide=
lines-01 and draft-ietf-netmod-rfc6087bis-14, it looks some of pieces have =
been merged into draft-ietf-netmod-rfc6087bis-14 and some of pieces have be=
en moved to draft-ietf-netmod-revised-datastores-04, Would you like to clar=
ify this in details.

2.      Section 4.6.5, 1st paragraph, 1st sentence

Have difficulty to parse this sentence, what it is emphasize here is when c=
ombined with several modules, the XPATH expression being evaluated is diffe=
rent from one that has been evaluated within a single module, am I correct?=
 If the answer is yes, I believe this sentence needs to be improved.

3.      Section 4.6.5

s/ when /foo/services/*/active/" when /foo/services/*/active"

4.      Section 4.11.4

What the second version is referred to? Correct one?

5.      Section 4.11.5

"When used within a list key, only one value can (and must)

exist for this key leaf.  The type "empty" SHOULD NOT be used for a

key leaf since it is pointless."

It looks these two sentences contradict with each other? The first sentence=
 says 'empty' data type could be used as a list key(The confusion is what o=
ne value is is not clear),

The second sentence says the 'empty' data type should not be used as list k=
ey. Could you give an example on how to use 'empty' data type with a list k=
ey leaf.

6.      Section 4.12.2

s/-top-level/top-level

Can not parse the first paragraph.

7.      Section 4.23.2, 2nd paragraph

What the value set is referred to? Take admin-state leaf and oper-state lea=
f as an example, if both admin-state and oper-state are set to uint32, do y=
ou mean values range set for admin-state

e.g.,range "0..100" is different from value range set for oper-state, e.g.,=
"101..200", Do you mean "admin-state" value set is configured value set?

8. Section 4.23.2 3rd paragraph, 4th paragraph

    How the 4th  paragraph is related to 3nd paragraph?

In 3nd paragraph, it discuss two list have two different key

In 4th paragraph, it discusses two list have keys with same type

9.      Section 4.23.3.1

Why there is no example for Temporary non-NMDA Modules?

10.  Section 4.23.3.1, 2nd paragraph

s/ the deprecated 

operation/with the deprecated  operation

11.  Section 4.23.3.1 3rd paragraph

when we need to create temporary non-NMDA model from NMDA model? Since when=
 we transition to NMDA model, why we should transition back to temporary No=
n-NMDA model?

How temporary non-NMDA Modules is different from temporary NMDA modules? Th=
is is something I feel very confused.

12.  Section 4.23.3.1 said:
"   o  Retain or create only the top-level nodes that have a "config"
      statement value "false".  These subtrees represent config=3Dfalse
      data nodes that were combined into the configuration subtree, and
      therefore not available to non-NMDA aware clients.  Set the
      "status" statement to "deprecated" for each new node.

"

Where  these subtrees are defined? It is not clear to me by reading the fir=
st sentence in this bullet.

13.  Section 4.23.3.4

How "create a Temporary NMDA Module" is different from "Convert an old Non-=
NMDA Module" described in section 4.23.3.3

When do we need to create a temporary NMDA module?

14.  Section 4.26.4
s/access access control/access control

-Qin
-------- Forwarded Message --------
Subject:

[netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

Date:

Tue, 12 Sep 2017 18:21:49 +0000

From:

Kent Watsen 

To:

netmod@ietf.org 

CC:

netmod-chairs@ietf.org , draft-ietf-netmod-rfc6087bis@ietf.org 



This starts a two-week working group last call on:



    Guidelines for Authors and Reviewers of YANG Data Model Documents

    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14



Please send email to the list indicating your support or concerns.



We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.

  * I have reviewed this draft and found the following issues: ...





Thank you,

NETMOD WG Chairs







_______________________________________________

netmod mailing list

netmod@ietf.org

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

.



________________________________

--_000_B8F9A780D330094D99AF023C5877DABA9ABF4F91nkgeml513mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













I have =
reviewed this draft and have the following comments to this draft:



1.     
I want to understand the relationship between draft-dsdt-nmda-guidelines-0=
1 and draft-ietf-netmod-rfc6087bis-14, it looks some of pieces have been me=
rged into draft-ietf-netmod-rfc6087bis-14
 and some of pieces have been moved to draft-ietf-netmod-revised-datastores=
-04, Would you like to clarify this in details.



2.     
Section 4.6.5, 1st paragraph, 1st sentence


=
Have difficulty to parse this =
sentence, what it is emphasize here is when combined with several modules, =
the XPATH expression being evaluated is
 different from one that has been evaluated within a single module, am I co=
rrect? If the answer is yes, I believe this sentence needs to be improved.<=
o:p>



3.     
Section 4.6.5


=
s/ when /foo/services/*/active=
/” when /foo/services/*/active”



4.     
Section 4.11.4


=
What the second version is ref=
erred to? Correct one?



5.     
Section 4.11.5


=
“When used within a list=
 key, only one value can (and must)


=
exist for this key leaf. =
 The type "empty" SHOULD NOT be used for a


=
key leaf since it is pointless=
.”


It looks these two sentences contradict with eac=
h other? The first sentence says ‘empty’ data type could be
 used as a list key(The confusion is what one value is is not clear), =



The second sentence says the ‘empty’=
 data type should not be used as list key. Could you give an example on
 how to use ‘empty’ data type with a list key leaf.<=
/span>



6.     
Section 4.12.2


s/-top-level/top-level


Can not parse the first paragraph.



7.     
Section 4.23.2, 2nd paragraph


What the value set is referred to? Take admin-st=
ate leaf and oper-state leaf as an example, if both admin-state
 and oper-state are set to uint32, do you mean values range set for admin-s=
tate


e.g.,range “0..100” is different fro=
m value range set for oper-state, e.g.,”101..200”, Do you mean =
“admin-state”
 value set is configured value set?


8.=
 Section 4.23.2 3rd paragraph, 4th paragraph


&n=
bsp;   How the 4th  paragraph is related to 3nd paragraph?


In 3nd paragraph, it discuss two list have two d=
ifferent key


In 4th paragraph, it discusses two list have key=
s with same type



9.     
Section 4.23.3.1


Why there is no example for Temporary non-NMDA M=
odules?



10. 
Section 4.23.3.1, 2nd paragraph


=
s/ the deprecated <get><=
o:p>


operation/with the deprecated <get> operat=
ion



11. 
Section 4.23.3.1 3rd paragraph


when we need to create temporary non-NMDA model =
from NMDA model? Since when we transition to NMDA model, why
 we should transition back to temporary Non-NMDA model?

How temporary non-NMDA Modules is different from=
 temporary NMDA modules? This is something I feel very confused.=




12. 
Section 4.23.3.1 said:


“=
   o  Retain or create only the top-level nodes that have a =
"config"


 &=
nbsp;    statement value "false".  These subt=
rees represent config=3Dfalse


 &=
nbsp;    data nodes that were combined into the configuratio=
n subtree, and


 &=
nbsp;    therefore not available to non-NMDA aware clients.&=
nbsp; Set the


 &=
nbsp;    "status" statement to "deprecated&qu=
ot; for each new node.


”


Wh=
ere  these subtrees are defined? It is not clear to me by reading the =
first sentence in this bullet.



13. 
Section 4.23.3.4


How “create a Temporary NMDA Module”=
 is different from “Convert an old Non-NMDA Module” described i=
n section
 4.23.3.3


=
When do we need to create a te=
mporary NMDA module?



14. 
Section 4.26.4


s/acces=
s access control/access control


&n=
bsp;


-Qin

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








Subject:





[netmod] WG Last Call: draft-ie=
tf-netmod-rfc6087bis-14








Date:





Tue, 12 Sep 2017 18:21:49 +=
0000








From:





Kent Watsen 
<kwatsen@juniper.net>








To:





netmod@ietf.org
<netmod@ietf.org>








CC:





netmod-chairs@ietf.org
<netmod-chairs@ietf.org>, 
draft-ietf-netmod-rfc6087bis@ietf.org 
<draft-ietf-netmod-rfc6087bis@ietf.org>








=
 


This starts a two-week working group last call on=
:


 


    Guidelines for Authors and Rev=
iewers of YANG Data Model Documents


    https://tools.ietf.org/html/draft=
-ietf-netmod-rfc6087bis-14


 


Please send email to the list indicating your sup=
port or concerns.


 


We are particularly interested in statements of t=
he form:


  * I have reviewed this draft and found no =
issues.


  * I have reviewed this draft and found the=
 following issues: ...


 


 


Thank you,


NETMOD WG Chairs


 


 


 


_______________________________________________


netmod mailing list


netmod@ietf.or=
g


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

.


 














--_000_B8F9A780D330094D99AF023C5877DABA9ABF4F91nkgeml513mbxchi_--


From nobody Mon Oct 16 22:48:28 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A0A1320CF; Mon, 16 Oct 2017 22:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Level: 
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 ZT3e0o5VplfF; Mon, 16 Oct 2017 22:48:26 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 E2EAF132924; Mon, 16 Oct 2017 22:48:25 -0700 (PDT)
Received: from LAPTOPR7T053C2 ([73.71.191.170]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LZfxK-1dNKPL162W-00lTGw;  Tue, 17 Oct 2017 07:48:23 +0200
From: "Alexander Clemm" 
To: "'Kent Watsen'" , 
Cc: , 
References: 
In-Reply-To: 
Date: Mon, 16 Oct 2017 22:48:27 -0700
Message-ID: <001701d3470b$8f473fe0$add5bfa0$@clemm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQKaYVkzfTaR4o9Av0E1iNvM3K8NkaFZVEYg
X-Provags-ID: V03:K0:zGPiDHcd+Rik8PuAn5pIhohpcka7FmcUL2X/ThLmZj/7OrSce6u k1d/Ji4YdR/f2Y7d0fkOiLQbdiJ9S6+B4OLEkYCMRgdT3pBu8WliNW078prjeez8w5nQQsG Q8UWT4rErhS6agCdFpc3raaMmWQjdolfRLznfqodtDDj9Qz/INndjWjONNNA6lwj5CXWG2U 7kn7gdqn8iffwPxeQdQ7w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:L8vGny+83CI=:lzSTbyCVL6HUDsbd1Qhxl/ z2Ydem9Fu6x5PKGawWuYMSRWH8e1CWsiftkHeoOrShNrT9oEWGxjnQiXA6PJc5Q7OsyWPboLr rYcyWaQSMVVbH1NlR/TYJrsAjzCy8BZwU21VckuvqazE1X9naTnt8ipakkJ0WIA3VzSoeQvXt XeyJLSM+Z673AxEBvSp/uG3tAQU4uQMHqIlaaduVXBUe4S9IV7xpFThcJkSff7sTDZ9kosibC 5Jtr03mp3NvXBSUKgNoZozfblVWjtEG1s2pmguBKeyiTMZRI0krgER/pqmuWe9NKIiPX+C7a3 QNKwoh/94/r2/n4qPBXMVeRztJjxP+OtOwT9bk74htYYhu5kUuusCXrkxTs5F/WbroZdArYFt DlQNAogwEZy4+g5qf/i8o8GawSib5V1TZJVhGPvs2c5ACLiPkCY/SRcx6x+recy4nM6KvLXJh qRZb5iZd4t2F0rkevGT6kvyvxsVF4cli5/SfYq/HYR0E34lzgDuunnFgaylTUUAFkQCxDwMNB ZXIZrRPgYORZwjnYmC51DtHFFZ0bz14n+q6tolawzQVNKqf8Y9EyJvn8xPIXU5AFAf0Y8ntjS dXFS4kc6g6psB4H8bce+to89kshfdMLUkKGw39KiyUrsRwoeX1QCNPE6e7jzmPTdRSXUn5YAW OucYW08FugdNXwKn9in58nWWiXs/wCOTj/OpJUH+QQSESjUzMzrDkoszsK0XjFwc57v3ktHOl km56OEdNRaUg2YDp9XNuZm8G2u/KxpEyfJ7B/bE5wq1CWsPHGaeckNjfUx4=
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 05:48:27 -0000

(Resending, apologies in case of duplicates)

I have reviewed some parts of the draft and have just a few comments as
well:

-	One area where guidelines are missing, but where guidance would be
needed, concerns how to model return values from RPCs, as well as how to
model the handling of RPC error conditions.  This is an area where I think
YANG itself could need some improvement, and in its absence good guidelines
would be even more important.  
-	It would be also useful to provide guidelines regarding how to
augment/extend groupings.  This is a common scenario and what to do is not
necessarily intuitive, so I am sure many users would appreciate guidelines
here.  
-	Section 3.4: It would be good to provide a guideline regarding lines
that exceed 70 columns (from the pyang tree output), at least mention that
authors need to manually address this issue  
-	Section 3.7: Personally, I think the security considerations as
currently stated, while well-intended, introduce a bit too much red tape.
Specifically, this concerns having to list nodes individually - this can
lead to defining many "trees" while missing the "forest".  The guidelines
are a bit "rubbery" here, by the way, stating that data nodes MUST be
individually listed and discussed, at the same time only if they "could be
especially disruptive" - what does that mean - so maybe the requirement
should simply be a "SHOULD" here?  
-	Observation: there is no mention/guideline canonical order of YANG
statements.  

Thanks
--- Alex

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, September 12, 2017 11:22 AM
To: netmod@ietf.org
Cc: netmod-chairs@ietf.org; draft-ietf-netmod-rfc6087bis@ietf.org
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14


This starts a two-week working group last call on:

    Guidelines for Authors and Reviewers of YANG Data Model Documents
    https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs



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


From nobody Tue Oct 17 01:35:15 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F18813304A for ; Tue, 17 Oct 2017 01:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 jDXMLI95WwTL for ; Tue, 17 Oct 2017 01:35:12 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA4B126C0F for ; Tue, 17 Oct 2017 01:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8859; q=dns/txt; s=iport; t=1508229312; x=1509438912; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=o97AJyZ3m0g0akc7s9YpCkpOSBmDkmfQwZvanU3t3fY=; b=j1SDySxL2eTXaAu1bAF4n39k3Bdnhc67CaJdnTujpkTfFwd31wK16O5C a1Nc8JXRptsoFsfxH8kTOXWiRYaHQhRrORQGVLXNprusHrNJL8aipXf7f DYKumbgd0RfzeOamrLxXeohfKN8wBmrxOOWGc9/7nqHRyVs93onerNbPL k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAAC/v+VZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+BVG4ng3qKH3SQOZBwhT8QggQKI4UYAoUjGAECAQEBAQEBAWs?= =?us-ascii?q?ohR4BBSNmCw4KJwMCAkYRBgEMBgIBARCKCRCpbIInJosXAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWDLYNYghWCf4RNg0uCYQWhSYdfjQyCFIlRhzKKIoNuh2CBOR8?= =?us-ascii?q?4gVk0IQgdFYMthGE+NotFAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,389,1503360000";  d="scan'208,217";a="698063144"
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; 17 Oct 2017 08:35:07 +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 v9H8Z7cc000996; Tue, 17 Oct 2017 08:35:07 GMT
To: Kent Watsen , NETMOD Working Group 
References:  
From: Benoit Claise 
Message-ID: <05f83ee0-4091-4941-e130-b42102521062@cisco.com>
Date: Tue, 17 Oct 2017 10:35:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B56BCD2D59ED479F5E0A8224"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 08:35:14 -0000

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

Hi Kent,
>
> Hi Benoit,
>
> BCP seems right, but I wonder if there is some sort of stability 
> metric that applies to BCPs.
>
    The BCP subseries of the RFC series is designed to be a way to
    standardize practices and the results of community deliberations.

https://tools.ietf.org/html/rfc2026#section-5
>
> YANG still seems to be evolving, so I can only imagine yet another 
> update to this document
>
> in the not too distant future.  Does that disqualify it in any way?
>
I don't think so. Implicitly, this says:

    The BCP subseries of the RFC series is designed to be a way to
    standardize practices and the results of community_current _deliberations.


If the YANG use and knowledge spread, this document will evolve in the 
future.

The problem to be solved, which I faced: "RFC6087 is informational (as 
opposed to BCP), so I don't feel like I should follow it"

Regards, Benoit
>
> Kent
>
> On 9/11/17, 10:16 AM, "netmod on behalf of Benoit Claise" 
>  on behalf of 
> bclaise@cisco.com > wrote:
>
> Dear all,
>
> I'm wondering if it's not time to classify 
> draft-ietf-netmod-rfc6087bis as a BCP, as opposed to informational
>
> This text would need to change:
>
>         This document is similar to the Structure of Management
>
>         Information
>
>         version 2 (SMIv2) usage guidelines specification [RFC4181] in intent
>
>         and structure.  However, since that document was written a decade
>
>         after SMIv2 modules had been in use, it was published as a 'Best
>
>         Current Practice' (BCP).  This document is not a BCP, but rather an
>
>         informational reference, intended to promote consistency in documents
>
>         containing YANG modules.
>
> Indeed, it seems to me that the consistency in YANG modules is a 
> pretty important topic.
>
> Feedback?
>
> Regards, Benoit
>


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


  
    
  
  
    
Hi Kent,

    

    

      
      
      
      
      
      

        
Hi
            Benoit,

        
 

        
BCP seems
            right, but I wonder if there is some sort of stability
            metric that applies to BCPs. 
          

      

    

    
   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.



    https://tools.ietf.org/html/rfc2026#section-5

    

      

        

        
YANG
            still seems to be evolving, so I can only imagine yet
            another update to this document

        
in the
            not too distant future.  Does that disqualify it in any way?

      

    

    I don't think so. Implicitly, this says:

    
   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community current deliberations.


    

    If the YANG use and knowledge spread, this document will evolve in
    the future.

    

    The problem to be solved, which I faced: "RFC6087 is informational
    (as opposed to BCP), so I don't feel like I should follow it"

    

    Regards, Benoit

    

      

        

        
 

        
Kent

        
 

        
 

        

          

            
On 9/11/17, 10:16 AM, "netmod on behalf
              of Benoit Claise" <netmod-bounces@ietf.org on
              behalf of
              bclaise@cisco.com>
              wrote:

          

        

        

          
 

        

        
Dear all,

          

          I'm wondering if it's not time to classify
          draft-ietf-netmod-rfc6087bis as a BCP, as opposed to
          informational

          

          This text would need to change:

        

          
   This document is similar to the Structure of Management

          
   Information

          
   version 2 (SMIv2) usage guidelines specification [RFC4181] in intent

          
   and structure.  However, since that document was written a decade

          
   after SMIv2 modules had been in use, it was published as a 'Best

          
   Current Practice' (BCP).  This document is not a BCP, but rather an

          
   informational reference, intended to promote consistency in documents

          
   containing YANG modules.

          
 

        

        
Indeed, it seems to me that the consistency
          in YANG modules is a pretty important topic.

          

          Feedback?

          

          Regards, Benoit

      

    

    

  


--------------B56BCD2D59ED479F5E0A8224--


From nobody Tue Oct 17 10:45:30 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583AA1321C9 for ; Tue, 17 Oct 2017 10:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.031
X-Spam-Level: 
X-Spam-Status: No, score=-0.031 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_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=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 VqdywQBuBXDI for ; Tue, 17 Oct 2017 10:45:26 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0127.outbound.protection.outlook.com [104.47.33.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9461F13304D for ; Tue, 17 Oct 2017 10:45:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hzNGArR72ZqS5RR77TdavJGn9nyCLI8enMO4lJZpxPQ=; b=Y6ILciQGPYNUKJKQZRRcrXLqjySS4F2+oCQ4BO/oZWQeJ1A9/qzy5CkTLR6dLpjNq/IM7RdEHx+QhA2PSpgT0sHoeVFkSoIHNmtY5SmY5n36wWQ/RbLkSPVpIp0T1QmV3sq+WCZ/N/VFrExUMAVHUZpLzMxHrEHVESdlJtEqVLs=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB274.namprd05.prod.outlook.com (10.141.22.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Tue, 17 Oct 2017 17:45:24 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0156.004; Tue, 17 Oct 2017 17:45:24 +0000
From: Kent Watsen 
To: Benoit Claise , NETMOD Working Group 
Thread-Topic: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
Thread-Index: AQHTKwidsbGmXJI3xUq38jMsPZskJKKxUSYAgDaedICAAFawgA==
Date: Tue, 17 Oct 2017 17:45:24 +0000
Message-ID: 
References:   <05f83ee0-4091-4941-e130-b42102521062@cisco.com>
In-Reply-To: <05f83ee0-4091-4941-e130-b42102521062@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:eqvqQCHjY4V22EJQqdfAloSAHS5C/xE9aFpB7HRge5H7Q5EYhvdbf5HoLj54YHbqRpEh1CaqD0GJKau3piaTP8WC0JZxzQ/ypNDPrtsS4lJaWKu6b2McbpOfrSeEmE47uasXO0+JPElKDsU/ayzQ2t107b9AaUmYiE+e4Iz460uyiT30ts7s+a5ApICDziz7o0EzOfDe1gUBdgBwrylZzg50442WP67UF+GK6HCdW24fbmcPdWzQBDPUUfmmJvGzdwCBw5i8yu8D7cipSgNoqcFfTxUdqrNlAsitzulOWO42C97vIH4Nuzgxmozv008T0Wb62GP9pfsmOzknvWLg9Q==; 5:4QrJhescTo/im3VKCjqEv3fexmji/p1y3VF3n+w2Ih9Q70/qhnOPFtHGNQvq4bbRvbiVluXVu2m0Q1+LFWkk1Wzw8YoJytimxwhXimMfHL4Siy8HuCp4PNMJ2SCYKul8wyTy22h53ZIMBLAjYavadKqEzAW4O+B9bbw6U1oqFNw=; 24:XDGhAgGUqOUgutphUdlTngywi9ZRoRzNpkFxfh/DLuugCmXHduTzjLW6OWcY7f/Lu7OFzvmdbMuWTVBdMrPkX0l1gEOzws3+tXwRZuT6XYU=; 7:3pFEyznlqO7lqjiBEehQfgld4cQEk26BchnyHnoizc6czUjYaH0PcpcJFNdI4Bw/i3I2PpyaaJjrV0yTAzqOliRYOj3CN2SS4ABUGX/pPczcSvpwQa9XyXt053tTg/oTdHGRJx59BDwcfMtkfGvUfvqLlvZJ1oVmyjvRXyOPlAj2GRpj3WTi2jGs2zfUcs/7c0m7s6glxCdquZPFsuJO3JCbITDXCtU6FbHSqkfePOc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 9a8a4183-e0de-4c2a-1005-08d51586d876
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB274; 
x-ms-traffictypediagnostic: BLUPR05MB274:
x-exchange-antispam-report-test: UriScan:(10436049006162)(100405760836317)(95692535739014)(21748063052155); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB274; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB274; 
x-forefront-prvs: 04631F8F77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(377454003)(189002)(199003)(24454002)(54094003)(36756003)(2900100001)(2906002)(82746002)(561944003)(33656002)(101416001)(68736007)(66066001)(3660700001)(77096006)(6246003)(54356999)(6486002)(229853002)(3280700002)(6436002)(76176999)(6506006)(189998001)(53936002)(97736004)(53546010)(606006)(50986999)(230783001)(2950100002)(102836003)(6116002)(54896002)(6306002)(7736002)(6512007)(3846002)(83506001)(5660300001)(236005)(86362001)(25786009)(966005)(105586002)(316002)(478600001)(106356001)(8936002)(83716003)(8676002)(99286003)(81166006)(81156014)(14454004)(58126008)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB274; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_A1EF591A445944B182DBC5C0000AC4C8junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a8a4183-e0de-4c2a-1005-08d51586d876
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 17:45:24.3272 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB274
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 17:45:29 -0000

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

SGkgQmVub2l0LCBldCBhbC4sDQoNCkFzIGEgY29udHJpYnV0b3IsIEkgc3VwcG9ydCB5b3VyIHBy
b3Bvc2FsIHRvIG1vdmUgcmZjNjA4N2JpcyB0byBCQ1AsIGFuZCBJIGtub3cgdGhhdCBMb3UgZG9l
cyBhcyB3ZWxsIChJIGp1c3QgYXNrZWQgaGltKS4gIEFzIGNvLWNoYWlyLCByZWFkaW5nIFNlY3Rp
b24gNi4xLjEgb2YgUkZDIDIwMjYsIEkgZmVlbCB0aGF0IHdlIG5lZWQgdG8gZm9ybWFsbHkgcnVu
IHRoZSBkZWNpc2lvbiBwYXN0IHRoZSBXRy4gIFNvLCB3aXRob3V0IGZ1cnRoZXIgYWRvOg0KDQpU
aGlzIGlzIHRoZSBzdGFydCBvZiAxLXdlZWsgcG9sbCB0byBnYXVnZSBXRyBjb25zZW5zdXMgb24g
dGhlIHByb3Bvc2FsIHRvIHByb21vdGUgcmZjNjA4N2JpcyB0byBCQ1AuICBXZSdkIGxpa2UgdG8g
aGVhciAieWVzL3N1cHBvcnQiIG9yICJuby9kb24ndCBzdXBwb3J0Iiwgd2l0aCBhbiBleHBsYW5h
dGlvbiBmb3Igd2h5LiAgUGxlYXNlIHJlc3BvbmQgYnkgT2N0IDI0LiAgIChiZXR0ZXIsIGhpdCB0
aGUgcmVwbHktYWxsIGJ1dHRvbiBub3chKQ0KDQpUaGFua3MsDQpLZW50IChhbmQgTG91KQ0KDQoN
Cg0KDQpPbiAxMC8xNy8xNywgNDozNSBBTSwgIkJlbm9pdCBDbGFpc2UiIDxiY2xhaXNlQGNpc2Nv
LmNvbTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkgS2VudCwNCkhpIEJl
bm9pdCwNCg0KQkNQIHNlZW1zIHJpZ2h0LCBidXQgSSB3b25kZXIgaWYgdGhlcmUgaXMgc29tZSBz
b3J0IG9mIHN0YWJpbGl0eSBtZXRyaWMgdGhhdCBhcHBsaWVzIHRvIEJDUHMuDQoNCiAgIFRoZSBC
Q1Agc3Vic2VyaWVzIG9mIHRoZSBSRkMgc2VyaWVzIGlzIGRlc2lnbmVkIHRvIGJlIGEgd2F5IHRv
DQoNCiAgIHN0YW5kYXJkaXplIHByYWN0aWNlcyBhbmQgdGhlIHJlc3VsdHMgb2YgY29tbXVuaXR5
IGRlbGliZXJhdGlvbnMuDQoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIwMjYj
c2VjdGlvbi01PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw
cy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmMyMDI2LTIzc2VjdGlvbi0yRDUmZD1Ed01EYVEm
Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpV
dlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWRMMlN6ZXZQckM0QWstTFlKWTc3
TTBjQXJJSEZzTTNzdk96MlgwNmp5dFkmcz1PX0duWEdRRGtrQUc0aEdubWRuNnVkQTBzNW9yTnhq
a0tZWVdEb08tTW5NJmU9Pg0KDQpZQU5HIHN0aWxsIHNlZW1zIHRvIGJlIGV2b2x2aW5nLCBzbyBJ
IGNhbiBvbmx5IGltYWdpbmUgeWV0IGFub3RoZXIgdXBkYXRlIHRvIHRoaXMgZG9jdW1lbnQNCmlu
IHRoZSBub3QgdG9vIGRpc3RhbnQgZnV0dXJlLiAgRG9lcyB0aGF0IGRpc3F1YWxpZnkgaXQgaW4g
YW55IHdheT8NCkkgZG9uJ3QgdGhpbmsgc28uIEltcGxpY2l0bHksIHRoaXMgc2F5czoNCg0KICAg
VGhlIEJDUCBzdWJzZXJpZXMgb2YgdGhlIFJGQyBzZXJpZXMgaXMgZGVzaWduZWQgdG8gYmUgYSB3
YXkgdG8NCg0KICAgc3RhbmRhcmRpemUgcHJhY3RpY2VzIGFuZCB0aGUgcmVzdWx0cyBvZiBjb21t
dW5pdHkgY3VycmVudCBkZWxpYmVyYXRpb25zLg0KDQpJZiB0aGUgWUFORyB1c2UgYW5kIGtub3ds
ZWRnZSBzcHJlYWQsIHRoaXMgZG9jdW1lbnQgd2lsbCBldm9sdmUgaW4gdGhlIGZ1dHVyZS4NCg0K
VGhlIHByb2JsZW0gdG8gYmUgc29sdmVkLCB3aGljaCBJIGZhY2VkOiAiUkZDNjA4NyBpcyBpbmZv
cm1hdGlvbmFsIChhcyBvcHBvc2VkIHRvIEJDUCksIHNvIEkgZG9uJ3QgZmVlbCBsaWtlIEkgc2hv
dWxkIGZvbGxvdyBpdCINCg0KUmVnYXJkcywgQmVub2l0DQoNCg0KS2VudA0KDQoNCk9uIDkvMTEv
MTcsIDEwOjE2IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBCZW5vaXQgQ2xhaXNlIiA8bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh
bGYgb2YgYmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4gd3JvdGU6
DQoNCkRlYXIgYWxsLA0KDQpJJ20gd29uZGVyaW5nIGlmIGl0J3Mgbm90IHRpbWUgdG8gY2xhc3Np
ZnkgZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2JpcyBhcyBhIEJDUCwgYXMgb3Bwb3NlZCB0byBp
bmZvcm1hdGlvbmFsDQoNClRoaXMgdGV4dCB3b3VsZCBuZWVkIHRvIGNoYW5nZToNCg0KICAgVGhp
cyBkb2N1bWVudCBpcyBzaW1pbGFyIHRvIHRoZSBTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudA0KDQog
ICBJbmZvcm1hdGlvbg0KDQogICB2ZXJzaW9uIDIgKFNNSXYyKSB1c2FnZSBndWlkZWxpbmVzIHNw
ZWNpZmljYXRpb24gW1JGQzQxODFdIGluIGludGVudA0KDQogICBhbmQgc3RydWN0dXJlLiAgSG93
ZXZlciwgc2luY2UgdGhhdCBkb2N1bWVudCB3YXMgd3JpdHRlbiBhIGRlY2FkZQ0KDQogICBhZnRl
ciBTTUl2MiBtb2R1bGVzIGhhZCBiZWVuIGluIHVzZSwgaXQgd2FzIHB1Ymxpc2hlZCBhcyBhICdC
ZXN0DQoNCiAgIEN1cnJlbnQgUHJhY3RpY2UnIChCQ1ApLiAgVGhpcyBkb2N1bWVudCBpcyBub3Qg
YSBCQ1AsIGJ1dCByYXRoZXIgYW4NCg0KICAgaW5mb3JtYXRpb25hbCByZWZlcmVuY2UsIGludGVu
ZGVkIHRvIHByb21vdGUgY29uc2lzdGVuY3kgaW4gZG9jdW1lbnRzDQoNCiAgIGNvbnRhaW5pbmcg
WUFORyBtb2R1bGVzLg0KDQoNCkluZGVlZCwgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgY29uc2lz
dGVuY3kgaW4gWUFORyBtb2R1bGVzIGlzIGEgcHJldHR5IGltcG9ydGFudCB0b3BpYy4NCg0KRmVl
ZGJhY2s/DQoNClJlZ2FyZHMsIEJlbm9pdA0KDQoNCg==

--_000_A1EF591A445944B182DBC5C0000AC4C8junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <5B1582B82E57AF4EBE0C45C41EE6C6BC@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
cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5k
b3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9u
ZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQt
dmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJh
bnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGln
bjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y
OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29s
b3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIEJlbm9pdCwgZXQgYWwuLDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+QXMgYSBjb250cmlidXRvciwgSSBzdXBw
b3J0IHlvdXIgcHJvcG9zYWwgdG8gbW92ZSByZmM2MDg3YmlzIHRvIEJDUCwgYW5kIEkga25vdyB0
aGF0IExvdSBkb2VzIGFzIHdlbGwgKEkganVzdCBhc2tlZCBoaW0pLiZuYnNwOyBBcyBjby1jaGFp
ciwgcmVhZGluZyBTZWN0aW9uIDYuMS4xIG9mIFJGQyAyMDI2LCBJIGZlZWwgdGhhdCB3ZSBuZWVk
IHRvIGZvcm1hbGx5DQogcnVuIHRoZSBkZWNpc2lvbiBwYXN0IHRoZSBXRy4mbmJzcDsgU28sIHdp
dGhvdXQgZnVydGhlciBhZG86PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj5UaGlzIGlzIHRoZSBzdGFydCBvZiAxLXdlZWsgcG9sbCB0byBnYXVnZSBXRyBj
b25zZW5zdXMgb24gdGhlIHByb3Bvc2FsIHRvIHByb21vdGUgcmZjNjA4N2JpcyB0byBCQ1AuJm5i
c3A7IFdlJ2QgbGlrZSB0byBoZWFyICZxdW90O3llcy9zdXBwb3J0JnF1b3Q7IG9yICZxdW90O25v
L2Rvbid0IHN1cHBvcnQmcXVvdDssIHdpdGggYW4gZXhwbGFuYXRpb24gZm9yIHdoeS4mbmJzcDsg
UGxlYXNlIHJlc3BvbmQNCiBieSBPY3QgMjQuICZuYnNwOyZuYnNwOyhiZXR0ZXIsIGhpdCB0aGUg
cmVwbHktYWxsIGJ1dHRvbiBub3chKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LZW50IChhbmQgTG91
KSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiAxMC8xNy8xNywgNDozNSBBTSwgJnF1b3Q7QmVub2l0IENsYWlzZSZxdW90OyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj5iY2xhaXNlQGNpc2NvLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkhpIEtlbnQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIEJlbm9pdCw8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkJDUCBzZWVt
cyByaWdodCwgYnV0IEkgd29uZGVyIGlmIHRoZXJlIGlzIHNvbWUgc29ydCBvZiBzdGFiaWxpdHkg
bWV0cmljIHRoYXQgYXBwbGllcyB0byBCQ1BzLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDtUaGUgQkNQIHN1YnNlcmll
cyBvZiB0aGUgUkZDIHNlcmllcyBpcyBkZXNpZ25lZCB0byBiZSBhIHdheSB0bzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzdGFuZGFyZGl6ZSBwcmFjdGljZXMgYW5kIHRoZSBy
ZXN1bHRzIG9mIGNvbW11bml0eSBkZWxpYmVyYXRpb25zLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJo
dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xz
LmlldGYub3JnX2h0bWxfcmZjMjAyNi0yM3NlY3Rpb24tMkQ1JmFtcDtkPUR3TURhUSZhbXA7Yz1I
QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5K
VXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209ZEwyU3pldlByQzRBay1M
WUpZNzdNMGNBcklIRnNNM3N2T3oyWDA2anl0WSZhbXA7cz1PX0duWEdRRGtrQUc0aEdubWRuNnVk
QTBzNW9yTnhqa0tZWVdEb08tTW5NJmFtcDtlPSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L3JmYzIwMjYjc2VjdGlvbi01PC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+WUFORyBz
dGlsbCBzZWVtcyB0byBiZSBldm9sdmluZywgc28gSSBjYW4gb25seSBpbWFnaW5lIHlldCBhbm90
aGVyIHVwZGF0ZSB0byB0aGlzIGRvY3VtZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPmluIHRoZSBu
b3QgdG9vIGRpc3RhbnQgZnV0dXJlLiZuYnNwOyBEb2VzIHRoYXQgZGlzcXVhbGlmeSBpdCBpbiBh
bnkgd2F5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgc28uIEltcGxpY2l0bHksIHRoaXMgc2F5czo8bzpwPjwv
bzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBCQ1Agc3Vic2VyaWVzIG9mIHRoZSBSRkMg
c2VyaWVzIGlzIGRlc2lnbmVkIHRvIGJlIGEgd2F5IHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7IHN0YW5kYXJkaXplIHByYWN0aWNlcyBhbmQgdGhlIHJlc3VsdHMgb2YgY29t
bXVuaXR5IDx1PmN1cnJlbnQgPC91PmRlbGliZXJhdGlvbnMuPG86cD48L286cD48L3ByZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCklmIHRoZSBZQU5HIHVzZSBhbmQga25vd2xlZGdlIHNw
cmVhZCwgdGhpcyBkb2N1bWVudCB3aWxsIGV2b2x2ZSBpbiB0aGUgZnV0dXJlLjxicj4NCjxicj4N
ClRoZSBwcm9ibGVtIHRvIGJlIHNvbHZlZCwgd2hpY2ggSSBmYWNlZDogJnF1b3Q7UkZDNjA4NyBp
cyBpbmZvcm1hdGlvbmFsIChhcyBvcHBvc2VkIHRvIEJDUCksIHNvIEkgZG9uJ3QgZmVlbCBsaWtl
IEkgc2hvdWxkIGZvbGxvdyBpdCZxdW90Ozxicj4NCjxicj4NClJlZ2FyZHMsIEJlbm9pdDxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQ8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
T24gOS8xMS8xNywgMTA6MTYgQU0sICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgQmVub2l0IENs
YWlzZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5u
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86
YmNsYWlzZUBjaXNjby5jb20iPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFs
bCw8YnI+DQo8YnI+DQpJJ20gd29uZGVyaW5nIGlmIGl0J3Mgbm90IHRpbWUgdG8gY2xhc3NpZnkg
ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2JpcyBhcyBhIEJDUCwgYXMgb3Bwb3NlZCB0byBpbmZv
cm1hdGlvbmFsPGJyPg0KPGJyPg0KVGhpcyB0ZXh0IHdvdWxkIG5lZWQgdG8gY2hhbmdlOjxvOnA+
PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGlzIHNpbWlsYXIg
dG8gdGhlIFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7IEluZm9ybWF0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
IHZlcnNpb24gMiAoU01JdjIpIHVzYWdlIGd1aWRlbGluZXMgc3BlY2lmaWNhdGlvbiBbUkZDNDE4
MV0gaW4gaW50ZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFuZCBzdHJ1
Y3R1cmUuJm5ic3A7IEhvd2V2ZXIsIHNpbmNlIHRoYXQgZG9jdW1lbnQgd2FzIHdyaXR0ZW4gYSBk
ZWNhZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYWZ0ZXIgU01JdjIgbW9k
dWxlcyBoYWQgYmVlbiBpbiB1c2UsIGl0IHdhcyBwdWJsaXNoZWQgYXMgYSAnQmVzdDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBDdXJyZW50IFByYWN0aWNlJyAoQkNQKS4mbmJz
cDsgVGhpcyBkb2N1bWVudCBpcyBub3QgYSBCQ1AsIGJ1dCByYXRoZXIgYW48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW5mb3JtYXRpb25hbCByZWZlcmVuY2UsIGludGVuZGVk
IHRvIHByb21vdGUgY29uc2lzdGVuY3kgaW4gZG9jdW1lbnRzPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IGNvbnRhaW5pbmcgWUFORyBtb2R1bGVzLjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JbmRlZWQsIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGNvbnNpc3RlbmN5IGlu
IFlBTkcgbW9kdWxlcyBpcyBhIHByZXR0eSBpbXBvcnRhbnQgdG9waWMuPGJyPg0KPGJyPg0KRmVl
ZGJhY2s/PGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0PG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_A1EF591A445944B182DBC5C0000AC4C8junipernet_--


From nobody Tue Oct 17 10:55:23 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B665213301F for ; Tue, 17 Oct 2017 10:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level: 
X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkpajYWo1YZz for ; Tue, 17 Oct 2017 10:55:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D8132D4E for ; Tue, 17 Oct 2017 10:55:18 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQV19770; Tue, 17 Oct 2017 17:55:16 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 18:55:15 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001;  Tue, 17 Oct 2017 10:55:11 -0700
From: Alexander Clemm 
To: Kent Watsen , Benoit Claise , NETMOD Working Group 
Thread-Topic: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
Thread-Index: AQHTKwinz8b16Al03k2EB25gLpBWaaKyCYyAgDZbZ4CAAJm/AP//i9kA
Date: Tue, 17 Oct 2017 17:55:10 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C09@sjceml521-mbx.china.huawei.com>
References:   <05f83ee0-4091-4941-e130-b42102521062@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.110]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C09sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59E64405.0032, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7d703a634d23a5eb0bac363d3d4ea5f3
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 17:55:22 -0000

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

SW50dWl0aXZlbHksIEJDUCBzZWVtcyB0aGUgcmlnaHQgY2hvaWNlIHRvIG1lLiAgQWxzbywgSSB0
aGluayBpdCBpcyBmaW5lIHRvIGlzc3VlIGFuIFJGQyBub3cgZXZlbiBpZiBpdCBpcyBjbGVhciBp
dCB3aWxsIG5lZWQgdXBkYXRpbmcgbGF0ZXIuICBJRVRGIHJlYWxseSBuZWVkcyB0byBnZXQgYmV0
dGVyIGF0IHJlbGVhc2luZyBkb2N1bWVudHMgZmFzdGVyLCBpdOKAmXMgbm90IGFzIGlmIHRoZXJl
IGlzIGEgc2hvcnRhZ2Ugb2YgaW50ZWdlcnMgYW5kIHBvdGVudGlhbCBjaHVybiBpcyBhdCB0aGlz
IHBvaW50IGxlc3Mgb2YgYSBjb25jZXJuIHRoYW4gdGltZWxpbmVzcy4gICBTbywgb24gdGhvc2Ug
Z3JvdW5kcywgeWVzL3N1cHBvcnQuDQoNCi0tLSBBbGV4DQoNCkZyb206IG5ldG1vZCBbbWFpbHRv
Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4NClNlbnQ6
IFR1ZXNkYXksIE9jdG9iZXIgMTcsIDIwMTcgMTA6NDUgQU0NClRvOiBCZW5vaXQgQ2xhaXNlIDxi
Y2xhaXNlQGNpc2NvLmNvbT47IE5FVE1PRCBXb3JraW5nIEdyb3VwIDxuZXRtb2RAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2JpcyBhcyBh
IEJDUD8NCg0KSGkgQmVub2l0LCBldCBhbC4sDQoNCkFzIGEgY29udHJpYnV0b3IsIEkgc3VwcG9y
dCB5b3VyIHByb3Bvc2FsIHRvIG1vdmUgcmZjNjA4N2JpcyB0byBCQ1AsIGFuZCBJIGtub3cgdGhh
dCBMb3UgZG9lcyBhcyB3ZWxsIChJIGp1c3QgYXNrZWQgaGltKS4gIEFzIGNvLWNoYWlyLCByZWFk
aW5nIFNlY3Rpb24gNi4xLjEgb2YgUkZDIDIwMjYsIEkgZmVlbCB0aGF0IHdlIG5lZWQgdG8gZm9y
bWFsbHkgcnVuIHRoZSBkZWNpc2lvbiBwYXN0IHRoZSBXRy4gIFNvLCB3aXRob3V0IGZ1cnRoZXIg
YWRvOg0KDQpUaGlzIGlzIHRoZSBzdGFydCBvZiAxLXdlZWsgcG9sbCB0byBnYXVnZSBXRyBjb25z
ZW5zdXMgb24gdGhlIHByb3Bvc2FsIHRvIHByb21vdGUgcmZjNjA4N2JpcyB0byBCQ1AuICBXZSdk
IGxpa2UgdG8gaGVhciAieWVzL3N1cHBvcnQiIG9yICJuby9kb24ndCBzdXBwb3J0Iiwgd2l0aCBh
biBleHBsYW5hdGlvbiBmb3Igd2h5LiAgUGxlYXNlIHJlc3BvbmQgYnkgT2N0IDI0LiAgIChiZXR0
ZXIsIGhpdCB0aGUgcmVwbHktYWxsIGJ1dHRvbiBub3chKQ0KDQpUaGFua3MsDQpLZW50IChhbmQg
TG91KQ0KDQoNCg0KDQpPbiAxMC8xNy8xNywgNDozNSBBTSwgIkJlbm9pdCBDbGFpc2UiIDxiY2xh
aXNlQGNpc2NvLmNvbTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkgS2Vu
dCwNCkhpIEJlbm9pdCwNCg0KQkNQIHNlZW1zIHJpZ2h0LCBidXQgSSB3b25kZXIgaWYgdGhlcmUg
aXMgc29tZSBzb3J0IG9mIHN0YWJpbGl0eSBtZXRyaWMgdGhhdCBhcHBsaWVzIHRvIEJDUHMuDQoN
CiAgIFRoZSBCQ1Agc3Vic2VyaWVzIG9mIHRoZSBSRkMgc2VyaWVzIGlzIGRlc2lnbmVkIHRvIGJl
IGEgd2F5IHRvDQoNCiAgIHN0YW5kYXJkaXplIHByYWN0aWNlcyBhbmQgdGhlIHJlc3VsdHMgb2Yg
Y29tbXVuaXR5IGRlbGliZXJhdGlvbnMuDQoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L3JmYzIwMjYjc2VjdGlvbi01PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmMyMDI2LTIzc2VjdGlvbi0yRDUm
ZD1Ed01EYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9
OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWRMMlN6ZXZQckM0
QWstTFlKWTc3TTBjQXJJSEZzTTNzdk96MlgwNmp5dFkmcz1PX0duWEdRRGtrQUc0aEdubWRuNnVk
QTBzNW9yTnhqa0tZWVdEb08tTW5NJmU9Pg0KWUFORyBzdGlsbCBzZWVtcyB0byBiZSBldm9sdmlu
Zywgc28gSSBjYW4gb25seSBpbWFnaW5lIHlldCBhbm90aGVyIHVwZGF0ZSB0byB0aGlzIGRvY3Vt
ZW50DQppbiB0aGUgbm90IHRvbyBkaXN0YW50IGZ1dHVyZS4gIERvZXMgdGhhdCBkaXNxdWFsaWZ5
IGl0IGluIGFueSB3YXk/DQpJIGRvbid0IHRoaW5rIHNvLiBJbXBsaWNpdGx5LCB0aGlzIHNheXM6
DQoNCiAgIFRoZSBCQ1Agc3Vic2VyaWVzIG9mIHRoZSBSRkMgc2VyaWVzIGlzIGRlc2lnbmVkIHRv
IGJlIGEgd2F5IHRvDQoNCiAgIHN0YW5kYXJkaXplIHByYWN0aWNlcyBhbmQgdGhlIHJlc3VsdHMg
b2YgY29tbXVuaXR5IGN1cnJlbnQgZGVsaWJlcmF0aW9ucy4NCg0KSWYgdGhlIFlBTkcgdXNlIGFu
ZCBrbm93bGVkZ2Ugc3ByZWFkLCB0aGlzIGRvY3VtZW50IHdpbGwgZXZvbHZlIGluIHRoZSBmdXR1
cmUuDQoNClRoZSBwcm9ibGVtIHRvIGJlIHNvbHZlZCwgd2hpY2ggSSBmYWNlZDogIlJGQzYwODcg
aXMgaW5mb3JtYXRpb25hbCAoYXMgb3Bwb3NlZCB0byBCQ1ApLCBzbyBJIGRvbid0IGZlZWwgbGlr
ZSBJIHNob3VsZCBmb2xsb3cgaXQiDQoNClJlZ2FyZHMsIEJlbm9pdA0KDQpLZW50DQoNCg0KT24g
OS8xMS8xNywgMTA6MTYgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEJlbm9pdCBDbGFpc2UiIDxu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9u
IGJlaGFsZiBvZiBiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+PiB3
cm90ZToNCg0KRGVhciBhbGwsDQoNCkknbSB3b25kZXJpbmcgaWYgaXQncyBub3QgdGltZSB0byBj
bGFzc2lmeSBkcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzIGFzIGEgQkNQLCBhcyBvcHBvc2Vk
IHRvIGluZm9ybWF0aW9uYWwNCg0KVGhpcyB0ZXh0IHdvdWxkIG5lZWQgdG8gY2hhbmdlOg0KDQog
ICBUaGlzIGRvY3VtZW50IGlzIHNpbWlsYXIgdG8gdGhlIFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50
DQoNCiAgIEluZm9ybWF0aW9uDQoNCiAgIHZlcnNpb24gMiAoU01JdjIpIHVzYWdlIGd1aWRlbGlu
ZXMgc3BlY2lmaWNhdGlvbiBbUkZDNDE4MV0gaW4gaW50ZW50DQoNCiAgIGFuZCBzdHJ1Y3R1cmUu
ICBIb3dldmVyLCBzaW5jZSB0aGF0IGRvY3VtZW50IHdhcyB3cml0dGVuIGEgZGVjYWRlDQoNCiAg
IGFmdGVyIFNNSXYyIG1vZHVsZXMgaGFkIGJlZW4gaW4gdXNlLCBpdCB3YXMgcHVibGlzaGVkIGFz
IGEgJ0Jlc3QNCg0KICAgQ3VycmVudCBQcmFjdGljZScgKEJDUCkuICBUaGlzIGRvY3VtZW50IGlz
IG5vdCBhIEJDUCwgYnV0IHJhdGhlciBhbg0KDQogICBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSwg
aW50ZW5kZWQgdG8gcHJvbW90ZSBjb25zaXN0ZW5jeSBpbiBkb2N1bWVudHMNCg0KICAgY29udGFp
bmluZyBZQU5HIG1vZHVsZXMuDQoNCg0KSW5kZWVkLCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBj
b25zaXN0ZW5jeSBpbiBZQU5HIG1vZHVsZXMgaXMgYSBwcmV0dHkgaW1wb3J0YW50IHRvcGljLg0K
DQpGZWVkYmFjaz8NCg0KUmVnYXJkcywgQmVub2l0DQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1
IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2
aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9y
bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglm
b250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsNCgl0ZXh0
LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwt
YWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC12YXJpYW50
Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06
bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2Vs
aW5lO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE
ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkludHVpdGl2
ZWx5LCBCQ1Agc2VlbXMgdGhlIHJpZ2h0IGNob2ljZSB0byBtZS4mbmJzcDsgQWxzbywgSSB0aGlu
ayBpdCBpcyBmaW5lIHRvIGlzc3VlIGFuIFJGQyBub3cgZXZlbiBpZiBpdCBpcyBjbGVhciBpdCB3
aWxsIG5lZWQgdXBkYXRpbmcgbGF0ZXIuICZuYnNwO0lFVEYgcmVhbGx5IG5lZWRzDQogdG8gZ2V0
IGJldHRlciBhdCByZWxlYXNpbmcgZG9jdW1lbnRzIGZhc3RlciwgaXTigJlzIG5vdCBhcyBpZiB0
aGVyZSBpcyBhIHNob3J0YWdlIG9mIGludGVnZXJzIGFuZCBwb3RlbnRpYWwgY2h1cm4gaXMgYXQg
dGhpcyBwb2ludCBsZXNzIG9mIGEgY29uY2VybiB0aGFuIHRpbWVsaW5lc3MuJm5ic3A7ICZuYnNw
O1NvLCBvbiB0aG9zZSBncm91bmRzLCB5ZXMvc3VwcG9ydC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w
cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRtb2Qg
W21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2Vu
dCBXYXRzZW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAxNywgMjAxNyAxMDo0
NSBBTTxicj4NCjxiPlRvOjwvYj4gQmVub2l0IENsYWlzZSAmbHQ7YmNsYWlzZUBjaXNjby5jb20m
Z3Q7OyBORVRNT0QgV29ya2luZyBHcm91cCAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2JpcyBh
cyBhIEJDUD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5I
aSBCZW5vaXQsIGV0IGFsLiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5B
cyBhIGNvbnRyaWJ1dG9yLCBJIHN1cHBvcnQgeW91ciBwcm9wb3NhbCB0byBtb3ZlIHJmYzYwODdi
aXMgdG8gQkNQLCBhbmQgSSBrbm93IHRoYXQgTG91IGRvZXMgYXMgd2VsbCAoSSBqdXN0IGFza2Vk
IGhpbSkuJm5ic3A7IEFzIGNvLWNoYWlyLCByZWFkaW5nIFNlY3Rpb24gNi4xLjEgb2YgUkZDIDIw
MjYsIEkgZmVlbCB0aGF0IHdlIG5lZWQNCiB0byBmb3JtYWxseSBydW4gdGhlIGRlY2lzaW9uIHBh
c3QgdGhlIFdHLiZuYnNwOyBTbywgd2l0aG91dCBmdXJ0aGVyIGFkbzo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHRoZSBzdGFydCBvZiAxLXdlZWsgcG9sbCB0
byBnYXVnZSBXRyBjb25zZW5zdXMgb24gdGhlIHByb3Bvc2FsIHRvIHByb21vdGUgcmZjNjA4N2Jp
cyB0byBCQ1AuJm5ic3A7IFdlJ2QgbGlrZSB0byBoZWFyICZxdW90O3llcy9zdXBwb3J0JnF1b3Q7
IG9yICZxdW90O25vL2Rvbid0IHN1cHBvcnQmcXVvdDssIHdpdGggYW4gZXhwbGFuYXRpb24gZm9y
IHdoeS4mbmJzcDsgUGxlYXNlDQogcmVzcG9uZCBieSBPY3QgMjQuICZuYnNwOyZuYnNwOyhiZXR0
ZXIsIGhpdCB0aGUgcmVwbHktYWxsIGJ1dHRvbiBub3chKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj5LZW50IChhbmQgTG91KQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5PbiAxMC8xNy8xNywgNDozNSBBTSwgJnF1b3Q7QmVub2l0IENsYWlzZSZxdW90OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj5iY2xhaXNlQGNpc2NvLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkhpIEtlbnQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+SGkgQmVub2l0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkJDUCBzZWVtcyByaWdodCwgYnV0IEkgd29uZGVyIGlmIHRoZXJlIGlzIHNvbWUgc29y
dCBvZiBzdGFiaWxpdHkgbWV0cmljIHRoYXQgYXBwbGllcyB0byBCQ1BzLiZuYnNwOw0KPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDtU
aGUgQkNQIHN1YnNlcmllcyBvZiB0aGUgUkZDIHNlcmllcyBpcyBkZXNpZ25lZCB0byBiZSBhIHdh
eSB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzdGFuZGFyZGl6ZSBwcmFj
dGljZXMgYW5kIHRoZSByZXN1bHRzIG9mIGNvbW11bml0eSBkZWxpYmVyYXRpb25zLjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm
ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRt
bF9yZmMyMDI2LTIzc2VjdGlvbi0yRDUmYW1wO2Q9RHdNRGFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2
U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZ
aHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1kTDJTemV2UHJDNEFrLUxZSlk3N00wY0FySUhG
c00zc3ZPejJYMDZqeXRZJmFtcDtzPU9fR25YR1FEa2tBRzRoR25tZG42dWRBMHM1b3JOeGprS1lZ
V0RvTy1Nbk0mYW1wO2U9Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjAyNiNzZWN0
aW9uLTU8L2E+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPllBTkcgc3Rp
bGwgc2VlbXMgdG8gYmUgZXZvbHZpbmcsIHNvIEkgY2FuIG9ubHkgaW1hZ2luZSB5ZXQgYW5vdGhl
ciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPmluIHRoZSBub3QgdG9vIGRpc3RhbnQgZnV0dXJlLiZuYnNwOyBEb2VzIHRo
YXQgZGlzcXVhbGlmeSBpdCBpbiBhbnkgd2F5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgc28uIEltcGxpY2l0
bHksIHRoaXMgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBCQ1Ag
c3Vic2VyaWVzIG9mIHRoZSBSRkMgc2VyaWVzIGlzIGRlc2lnbmVkIHRvIGJlIGEgd2F5IHRvPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHN0YW5kYXJkaXplIHByYWN0aWNlcyBh
bmQgdGhlIHJlc3VsdHMgb2YgY29tbXVuaXR5IDx1PmN1cnJlbnQgPC91PmRlbGliZXJhdGlvbnMu
PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90
dG9tOjEyLjBwdCI+PGJyPg0KSWYgdGhlIFlBTkcgdXNlIGFuZCBrbm93bGVkZ2Ugc3ByZWFkLCB0
aGlzIGRvY3VtZW50IHdpbGwgZXZvbHZlIGluIHRoZSBmdXR1cmUuPGJyPg0KPGJyPg0KVGhlIHBy
b2JsZW0gdG8gYmUgc29sdmVkLCB3aGljaCBJIGZhY2VkOiAmcXVvdDtSRkM2MDg3IGlzIGluZm9y
bWF0aW9uYWwgKGFzIG9wcG9zZWQgdG8gQkNQKSwgc28gSSBkb24ndCBmZWVsIGxpa2UgSSBzaG91
bGQgZm9sbG93IGl0JnF1b3Q7PGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0PG86cD48L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPktlbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPk9uIDkvMTEvMTcsIDEwOjE2IEFNLCAmcXVvdDtuZXRtb2Qgb24gYmVo
YWxmIG9mIEJlbm9pdCBDbGFpc2UmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0K
PGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj5iY2xhaXNlQGNpc2NvLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+RGVhciBhbGwsPGJyPg0KPGJyPg0KSSdtIHdvbmRlcmluZyBpZiBpdCdzIG5vdCB0
aW1lIHRvIGNsYXNzaWZ5IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwODdiaXMgYXMgYSBCQ1AsIGFz
IG9wcG9zZWQgdG8gaW5mb3JtYXRpb25hbDxicj4NCjxicj4NClRoaXMgdGV4dCB3b3VsZCBuZWVk
IHRvIGNoYW5nZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1
bWVudCBpcyBzaW1pbGFyIHRvIHRoZSBTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBJbmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyB2ZXJzaW9uIDIgKFNNSXYyKSB1c2FnZSBndWlkZWxpbmVzIHNwZWNp
ZmljYXRpb24gW1JGQzQxODFdIGluIGludGVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyBhbmQgc3RydWN0dXJlLiZuYnNwOyBIb3dldmVyLCBzaW5jZSB0aGF0IGRvY3VtZW50
IHdhcyB3cml0dGVuIGEgZGVjYWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
IGFmdGVyIFNNSXYyIG1vZHVsZXMgaGFkIGJlZW4gaW4gdXNlLCBpdCB3YXMgcHVibGlzaGVkIGFz
IGEgJ0Jlc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQ3VycmVudCBQcmFj
dGljZScgKEJDUCkuJm5ic3A7IFRoaXMgZG9jdW1lbnQgaXMgbm90IGEgQkNQLCBidXQgcmF0aGVy
IGFuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uYWwgcmVm
ZXJlbmNlLCBpbnRlbmRlZCB0byBwcm9tb3RlIGNvbnNpc3RlbmN5IGluIGRvY3VtZW50czxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjb250YWluaW5nIFlBTkcgbW9kdWxlcy48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW5kZWVkLCBpdCBzZWVtcyB0byBtZSB0aGF0IHRo
ZSBjb25zaXN0ZW5jeSBpbiBZQU5HIG1vZHVsZXMgaXMgYSBwcmV0dHkgaW1wb3J0YW50IHRvcGlj
Ljxicj4NCjxicj4NCkZlZWRiYWNrPzxicj4NCjxicj4NClJlZ2FyZHMsIEJlbm9pdDxvOnA+PC9v
OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C09sjceml521mbxchi_--


From nobody Tue Oct 17 11:30:20 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88F3132D4E; Tue, 17 Oct 2017 11:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 xjMq6h0jw8z5; Tue, 17 Oct 2017 11:30:16 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0108.outbound.protection.outlook.com [104.47.37.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C401323F7; Tue, 17 Oct 2017 11:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xGdmBjshv1GhU7PnokPxOmxTIO4jSF0r4hoOpRV937s=; b=jh9AMfjjo328aE51SNfE4i81keoxa4vWw9jX//hYJXuTrqyoBBfjPvAzmMywYowrmMMjEC/pneLU2rk9fs3OK7raXKeDogDUsXDH2jfr8ZZ3JOgZnGXq92zWec4u3jTinS0egzeiYoA7UukvaZUYxQydzhG8MtMhYYz5it3ThwY=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB274.namprd05.prod.outlook.com (10.141.22.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Tue, 17 Oct 2017 18:30:13 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0156.004; Tue, 17 Oct 2017 18:30:13 +0000
From: Kent Watsen 
To: Alexander Clemm , "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" , "draft-ietf-netmod-rfc6087bis@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QA8+mcxSk5vUmECY2lUkQ4OqLnvzOAgACRx4A=
Date: Tue, 17 Oct 2017 18:30:13 +0000
Message-ID: 
References:  <001701d3470b$8f473fe0$add5bfa0$@clemm.org>
In-Reply-To: <001701d3470b$8f473fe0$add5bfa0$@clemm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:o0G5vdMEZNZ+gpuLggDQJqzs6YeV9nDxHj0RPcB/jMgcq3eRvQwR/8bSWOn3pBblogugZ9/bxuWgBTm5Rt9mOfNVt9VaN5hqVAhjVBKW/fPpngO/xVTTwkbl0B8+Go4gAln6PVpc9k88Ioq10tmL97nevRVnVSBNqg956AYdhbsR/gyRwCNuYREnZJ/u1gmeamQyOIhUnXMT0tNsjU5jY0XpUnrkcxGHU+l7OlFac8iRUTElzzQhARh1qcijnwg1eZxum1M/5f3MWWoXGr7/OcbKdiph9ShF9xWN/OvNKMLYhaXE1D0hDWuJYvY0HIfLRxC+h4XwhwxEEK/Tk0lX2g==; 5:0YG4v4qP+oi5jDL12XHJSqe4y/tRjpS8CKkttGl5jBVexQI4fglKfjsqgLBKsYEPm3zxvZzFiJOxX0F7mZGpDRCvTMUu3/VOHC0hqmTr45IKDYePHMFuSJbE5J/+hqnbUlhEvgQGdfahR+6Ji4hq6w==; 24:kYffnsvI5I8HQ3QQfxNt1Q0jPZ0ABETawNtFDYVRO6EPxMsAMmTe+2rvgoH2bQd/vH14/dXTQZq6n2mFgNfXeMVyrUiP2K3ZBp2ssGagO3A=; 7:H1rA8ttZOtnbOytc+wsYj4CH2vRHmGvpMVxxoQffQ2C+BqXR4LbSL7GQK7L08a/tTmWoz9VoVkeBe+a/vLYnmSjx7lmPEEXooUvQLVOrqVacvircZ+pbHqvipIhHXPgR3mLtkPH8fjHNqdU3bm4BfGEhsopm/jH2PMKZTJt7SJn9IaguoNg0ajbnACVguGCvCoOIfWKY5Kftj+XVY4w+Fq0yNfZBaMfG1ziCxu3IwgU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3e20e19d-4907-40fe-cb12-08d5158d1b67
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB274; 
x-ms-traffictypediagnostic: BLUPR05MB274:
x-exchange-antispam-report-test: UriScan:(10436049006162)(166708455590820)(192374486261705); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB274; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB274; 
x-forefront-prvs: 04631F8F77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(76104003)(13464003)(199003)(377454003)(189002)(51444003)(4326008)(2501003)(7736002)(305945005)(6512007)(6306002)(2950100002)(102836003)(6116002)(5660300001)(83506001)(3846002)(99286003)(106356001)(8676002)(83716003)(8936002)(54906003)(14454004)(58126008)(110136005)(1720100001)(478600001)(81166006)(81156014)(25786009)(575784001)(86362001)(316002)(105586002)(966005)(33656002)(82746002)(101416001)(66066001)(3660700001)(68736007)(77096006)(36756003)(2906002)(2900100001)(6246003)(97736004)(53936002)(53546010)(189998001)(230783001)(50986999)(229853002)(3280700002)(54356999)(6486002)(76176999)(6506006)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB274; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <2B6B66AD295AC54FA08127D5F6620860@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e20e19d-4907-40fe-cb12-08d5158d1b67
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 18:30:13.6058 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB274
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 18:30:18 -0000

SGkgQWxleCwNCg0KPiAoUmVzZW5kaW5nLCBhcG9sb2dpZXMgaW4gY2FzZSBvZiBkdXBsaWNhdGVz
KQ0KDQpSZXNlbmRpbmc/IFRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgSSdtIHNlZWluZyB0aGVzZS4g
IERpZCB5b3Ugc2VuZCANCnRoZW0gd2hlbiB0aGUgTGFzdCBDYWxsIHdhcyBvcGVuIGJlZm9yZT8g
IFRoZSBMYXN0IENhbGwgY2xvc2VkIGEgDQpjb3VwbGUgd2Vla3MgYWdvICA7KQ0KDQpJIGRvbid0
IHdhbnQgdG8gcmVvcGVuIHJmYzYwODdiaXMgZm9yIGFueXRoaW5nIGxlc3MgdGhhbiBFcnJhdGEg
YXQNCnRoaXMgcG9pbnQgKG9yIHByb21vdGluZyBpdCB0byBhIEJDUCwgYnV0IHRoYXQncyBhIGRp
ZmZlcmVudCB0aGluZw0KYWx0b2dldGhlcikuICBJdCBzZWVtcyB0aGF0IHNvbWUgb2YgeW91ciBz
dWdnZXN0aW9ucyBjb3VsZCBnbyBpbnRvDQp0aGUgbmV3ICJndWlkZWxpbmVzLW5leHQiIGlzc3Vl
IHRyYWNrZXIgWzFdLiAgV2UgbWF5IGFsc28gY29uc2lkZXINCmFkZGluZyBpbmZvcm1hdGlvbiB0
byB0aGUgRkFRIFsyXS4gIFJlZ2FyZGluZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywNCkkgdGhp
bmsgdGhhdCBhICJub2RlIiBjYW4gYmUgdGhlIHJvb3Qgb2YgYSBzdWJ0cmVlLCBhbmQgdGhlIHJ1
YmJlcnktDQpuZXNzIGlzIGxpa2VseSBmcm9tIFszXSBhbmQgY2FuIGJlIGFkZHJlc3NlZCBzZXBh
cmF0ZWx5Lg0KDQpbMV0gaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9ndWlkZWxpbmVzLW5l
eHQvaXNzdWVzDQpbMl0gaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9GQVEvd2lraQ0KWzNd
IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvb3BzL3RyYWMvd2lraS95YW5nLXNlY3Vy
aXR5LWd1aWRlbGluZXMNCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCktlbnQgLy8gc2hlcGhlcmQN
Cg0KDQoNCkkgaGF2ZSByZXZpZXdlZCBzb21lIHBhcnRzIG9mIHRoZSBkcmFmdCBhbmQgaGF2ZSBq
dXN0IGEgZmV3IGNvbW1lbnRzIGFzDQp3ZWxsOg0KDQotCU9uZSBhcmVhIHdoZXJlIGd1aWRlbGlu
ZXMgYXJlIG1pc3NpbmcsIGJ1dCB3aGVyZSBndWlkYW5jZSB3b3VsZCBiZQ0KbmVlZGVkLCBjb25j
ZXJucyBob3cgdG8gbW9kZWwgcmV0dXJuIHZhbHVlcyBmcm9tIFJQQ3MsIGFzIHdlbGwgYXMgaG93
IHRvDQptb2RlbCB0aGUgaGFuZGxpbmcgb2YgUlBDIGVycm9yIGNvbmRpdGlvbnMuICBUaGlzIGlz
IGFuIGFyZWEgd2hlcmUgSSB0aGluaw0KWUFORyBpdHNlbGYgY291bGQgbmVlZCBzb21lIGltcHJv
dmVtZW50LCBhbmQgaW4gaXRzIGFic2VuY2UgZ29vZCBndWlkZWxpbmVzDQp3b3VsZCBiZSBldmVu
IG1vcmUgaW1wb3J0YW50LiAgDQotCUl0IHdvdWxkIGJlIGFsc28gdXNlZnVsIHRvIHByb3ZpZGUg
Z3VpZGVsaW5lcyByZWdhcmRpbmcgaG93IHRvDQphdWdtZW50L2V4dGVuZCBncm91cGluZ3MuICBU
aGlzIGlzIGEgY29tbW9uIHNjZW5hcmlvIGFuZCB3aGF0IHRvIGRvIGlzIG5vdA0KbmVjZXNzYXJp
bHkgaW50dWl0aXZlLCBzbyBJIGFtIHN1cmUgbWFueSB1c2VycyB3b3VsZCBhcHByZWNpYXRlIGd1
aWRlbGluZXMNCmhlcmUuICANCi0JU2VjdGlvbiAzLjQ6IEl0IHdvdWxkIGJlIGdvb2QgdG8gcHJv
dmlkZSBhIGd1aWRlbGluZSByZWdhcmRpbmcgbGluZXMNCnRoYXQgZXhjZWVkIDcwIGNvbHVtbnMg
KGZyb20gdGhlIHB5YW5nIHRyZWUgb3V0cHV0KSwgYXQgbGVhc3QgbWVudGlvbiB0aGF0DQphdXRo
b3JzIG5lZWQgdG8gbWFudWFsbHkgYWRkcmVzcyB0aGlzIGlzc3VlICANCi0JU2VjdGlvbiAzLjc6
IFBlcnNvbmFsbHksIEkgdGhpbmsgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFzDQpjdXJy
ZW50bHkgc3RhdGVkLCB3aGlsZSB3ZWxsLWludGVuZGVkLCBpbnRyb2R1Y2UgYSBiaXQgdG9vIG11
Y2ggcmVkIHRhcGUuDQpTcGVjaWZpY2FsbHksIHRoaXMgY29uY2VybnMgaGF2aW5nIHRvIGxpc3Qg
bm9kZXMgaW5kaXZpZHVhbGx5IC0gdGhpcyBjYW4NCmxlYWQgdG8gZGVmaW5pbmcgbWFueSAidHJl
ZXMiIHdoaWxlIG1pc3NpbmcgdGhlICJmb3Jlc3QiLiAgVGhlIGd1aWRlbGluZXMNCmFyZSBhIGJp
dCAicnViYmVyeSIgaGVyZSwgYnkgdGhlIHdheSwgc3RhdGluZyB0aGF0IGRhdGEgbm9kZXMgTVVT
VCBiZQ0KaW5kaXZpZHVhbGx5IGxpc3RlZCBhbmQgZGlzY3Vzc2VkLCBhdCB0aGUgc2FtZSB0aW1l
IG9ubHkgaWYgdGhleSAiY291bGQgYmUNCmVzcGVjaWFsbHkgZGlzcnVwdGl2ZSIgLSB3aGF0IGRv
ZXMgdGhhdCBtZWFuIC0gc28gbWF5YmUgdGhlIHJlcXVpcmVtZW50DQpzaG91bGQgc2ltcGx5IGJl
IGEgIlNIT1VMRCIgaGVyZT8gIA0KLQlPYnNlcnZhdGlvbjogdGhlcmUgaXMgbm8gbWVudGlvbi9n
dWlkZWxpbmUgY2Fub25pY2FsIG9yZGVyIG9mIFlBTkcNCnN0YXRlbWVudHMuICANCg0KVGhhbmtz
DQotLS0gQWxleA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIFtt
YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0K
U2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDEyLCAyMDE3IDExOjIyIEFNDQpUbzogbmV0bW9kQGll
dGYub3JnDQpDYzogbmV0bW9kLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRtb2QtcmZj
NjA4N2Jpc0BpZXRmLm9yZw0KU3ViamVjdDogW25ldG1vZF0gV0cgTGFzdCBDYWxsOiBkcmFmdC1p
ZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTE0DQoNCg0KVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3Jr
aW5nIGdyb3VwIGxhc3QgY2FsbCBvbjoNCg0KICAgIEd1aWRlbGluZXMgZm9yIEF1dGhvcnMgYW5k
IFJldmlld2VycyBvZiBZQU5HIERhdGEgTW9kZWwgRG9jdW1lbnRzDQogICAgaHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o
dG1sX2RyYWZ0LTJEaWV0Zi0yRG5ldG1vZC0yRHJmYzYwODdiaXMtMkQxNCZkPUR3SUNBZyZjPUhB
a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdK
OUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09aVI3bTFmYmp4dUg0SFcwV3M3U1MtaldC
bEhzRklWQ1pFYkcydnhNdG1ubyZzPW1RUnR4Q1lWc04wdHRtZXRzOHctOGEtVkJoM3ZoOXJKal9O
SlZodEdhNGsmZT0NCg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyB5
b3VyIHN1cHBvcnQgb3IgY29uY2VybnMuDQoNCldlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3Rl
ZCBpbiBzdGF0ZW1lbnRzIG9mIHRoZSBmb3JtOg0KICAqIEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRy
YWZ0IGFuZCBmb3VuZCBubyBpc3N1ZXMuDQogICogSSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQg
YW5kIGZvdW5kIHRoZSBmb2xsb3dpbmcgaXNzdWVzOiAuLi4NCg0KDQpUaGFuayB5b3UsDQpORVRN
T0QgV0cgQ2hhaXJzDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczov
L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y
Z19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgw
VWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFH
VHZqSVNsYUpkY1pvJm09aVI3bTFmYmp4dUg0SFcwV3M3U1MtaldCbEhzRklWQ1pFYkcydnhNdG1u
byZzPU5lRkYwMmNSMThaV0x4Qlgwa1NzakFvbHgwUVVXTjRDaEYzX0dKYzlXTWMmZT0NCg0KDQoN
Cg==


From nobody Tue Oct 17 11:33:31 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BA5133020 for ; Tue, 17 Oct 2017 11:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level: 
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 fi8oCmI52TZt for ; Tue, 17 Oct 2017 11:33:27 -0700 (PDT)
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 387A71323F7 for ; Tue, 17 Oct 2017 11:33:27 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id w21so3084011lfc.6 for ; Tue, 17 Oct 2017 11:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F1TcWQjopxwyqpzIMvbmidEgPWlYxVbRML+IOMpXR+k=; b=yhOpke3vGUDeUykIi+nbdNPTghR0CPBMfLdbGK3jY1sGWb7CJ8A9mbG2G1QI4XYQ6A yo0m/yF5zJEoFZmEvkWs0zoS0/ZDGzTeLUrZjqWWACO84pKBhEahGIdj9Zr/rdpvo+2t 6tnmqvXTyJ5g47pjeUK2Pcp8hHsyOB1AbbMrICICaB4lsn53jDLgM/yVWmOgogwUvb4e 1+S+2HWwMrR2NE7QiDjUzlm1DDv8Np7iCK/K/sFGUZh03YEHdg/xSSGTcRvT13xIEmUe 86PsNm0jAt6NsxHoxgvuBUBqhX4y6d6iHRcybCaw3v2Ta1mKcNFkdzTcu4arDvH2yEXY 2CWg==
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=F1TcWQjopxwyqpzIMvbmidEgPWlYxVbRML+IOMpXR+k=; b=Y5n/r5WXijDwPgRVZjxHPjD5uiFvbsOTZsJYdyQa1jdiSH2LiisKFEFpEyOCNlIOh3 eZWYh0vCTEElVFnZgIfdy30y1jwlSPYANLC1mwq4JGhhxhoJXiIqelgqC5Mpn6Vx/aqP 4VXBpUgxhk6SnLCIgGRhjcjV0XhQsojMyN0OqmJhd9n6sbqmKBwIuBs+fK4RoDm8KTYj fArqypJbpWJxUPp04W+KyNPOretZH2YVIrPgSXnftIBrgjoMNE1KZcFdSKYTlKJj2eaF Hav1bwZKObTzejmGOt+1qmkivss5EzplOdRXPQ4DOBGYDecgG3OTuw/lHzbWJvI85RpH 3R1Q==
X-Gm-Message-State: AMCzsaXAgB98YjDI3Iak6wtWBK2E8ofqBXHSkxwE67jGKsTzKYhNjoc+ iT1rWsr9oQrIYDXc8IQtaL7VnygVokP126PzlPtxTw==
X-Google-Smtp-Source: ABhQp+Ruqkrro3eHmFYZgO2LPYb1O/pSgAAaV9rC9cXdhazw/niVCONQ/V7GrQ4i6+gBMgBDiolhdvXmDAhfCUWuFP0=
X-Received: by 10.25.23.165 with SMTP id 37mr4539989lfx.202.1508265205451; Tue, 17 Oct 2017 11:33:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Tue, 17 Oct 2017 11:33:24 -0700 (PDT)
In-Reply-To: 
References:   <05f83ee0-4091-4941-e130-b42102521062@cisco.com> 
From: Andy Bierman 
Date: Tue, 17 Oct 2017 11:33:24 -0700
Message-ID: 
To: Kent Watsen 
Cc: Benoit Claise , NETMOD Working Group 
Content-Type: multipart/alternative; boundary="001a11401a04cc68c0055bc25b0b"
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 18:33:30 -0000

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

Hi,

I support BCP status.
This is consistent with RFC 4181, which RFC 6087 was modeled after.

Andy


On Tue, Oct 17, 2017 at 10:45 AM, Kent Watsen  wrote:

> Hi Benoit, et al.,
>
>
>
> As a contributor, I support your proposal to move rfc6087bis to BCP, and =
I
> know that Lou does as well (I just asked him).  As co-chair, reading
> Section 6.1.1 of RFC 2026, I feel that we need to formally run the decisi=
on
> past the WG.  So, without further ado:
>
>
>
> This is the start of 1-week poll to gauge WG consensus on the proposal to
> promote rfc6087bis to BCP.  We'd like to hear "yes/support" or "no/don't
> support", with an explanation for why.  Please respond by Oct 24.
>   (better, hit the reply-all button now!)
>
>
>
> Thanks,
>
> Kent (and Lou)
>
>
>
>
>
>
>
>
>
> On 10/17/17, 4:35 AM, "Benoit Claise"  wrote:
>
>
>
> Hi Kent,
>
> Hi Benoit,
>
>
>
> BCP seems right, but I wonder if there is some sort of stability metric
> that applies to BCPs.
>
>    The BCP subseries of the RFC series is designed to be a way to
>
>    standardize practices and the results of community deliberations.
>
>
>
> https://tools.ietf.org/html/rfc2026#section-5
> 
>
> YANG still seems to be evolving, so I can only imagine yet another update
> to this document
>
> in the not too distant future.  Does that disqualify it in any way?
>
> I don't think so. Implicitly, this says:
>
>    The BCP subseries of the RFC series is designed to be a way to
>
>    standardize practices and the results of community *current *deliberat=
ions.
>
>
> If the YANG use and knowledge spread, this document will evolve in the
> future.
>
> The problem to be solved, which I faced: "RFC6087 is informational (as
> opposed to BCP), so I don't feel like I should follow it"
>
> Regards, Benoit
>
>
>
> Kent
>
>
>
>
>
> On 9/11/17, 10:16 AM, "netmod on behalf of Benoit Claise" <
> netmod-bounces@ietf.org on behalf of bclaise@cisco.com> wrote:
>
>
>
> Dear all,
>
> I'm wondering if it's not time to classify draft-ietf-netmod-rfc6087bis a=
s
> a BCP, as opposed to informational
>
> This text would need to change:
>
>    This document is similar to the Structure of Management
>
>    Information
>
>    version 2 (SMIv2) usage guidelines specification [RFC4181] in intent
>
>    and structure.  However, since that document was written a decade
>
>    after SMIv2 modules had been in use, it was published as a 'Best
>
>    Current Practice' (BCP).  This document is not a BCP, but rather an
>
>    informational reference, intended to promote consistency in documents
>
>    containing YANG modules.
>
>
>
> Indeed, it seems to me that the consistency in YANG modules is a pretty
> important topic.
>
> Feedback?
>
> Regards, Benoit
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Hi,

I support BCP status.
Thi=
s is consistent with RFC 4181, which RFC 6087 was modeled after.
=

Andy


On Tue, Oct 17, 2017 at 10:45 AM, Kent Watsen <kwatsen@=
juniper.net> wrote:













Hi Benoit, et al=
.,


=C2=A0=



As a contributor=
, I support your proposal to move rfc6087bis to BCP, and I know that Lou do=
es as well (I just asked him).=C2=A0 As co-chair, reading Section 6.1.1 of =
RFC 2026, I feel that we need to formally
 run the decision past the WG.=C2=A0 So, without further ado:=



=C2=A0=



This is the star=
t of 1-week poll to gauge WG consensus on the proposal to promote rfc6087bi=
s to BCP.=C2=A0 We'd like to hear "yes/support" or "no/d=
on't support", with an explanation for why.=C2=A0 Please respond
 by Oct 24. =C2=A0=C2=A0(better, hit the reply-all button now!)


=C2=A0=



Thanks,


Kent (and Lou) <=
u>


=C2=A0=



=C2=A0=



=C2=A0=



=C2=A0=







On 10/17/17, 4:35 AM, "Benoit Claise" <=
bclaise@cisco.com> wrote:








=C2=A0






Hi Kent,






Hi Benoit,


=C2=A0=



BCP seems right,=
 but I wonder if there is some sort of stability metric that applies to BCP=
s.=C2=A0





=C2=A0=C2=A0=C2=A0The BCP subseries of the RFC series is designed to b=
e a way to


=C2=A0=C2=A0 standardize practices and the results of community delibe=
rations.


=C2=A0


https://tools.ietf.org/html/rfc2026#section-5








YANG still seems=
 to be evolving, so I can only imagine yet another update to this document<=
/span>


in the not too d=
istant future.=C2=A0 Does that disqualify it in any way?




I don't think so. Implicitly, this says:<=
u>


=C2=A0=C2=A0 The BCP subseries of the RFC series is designed to be a w=
ay to


=C2=A0=C2=A0 standardize practices and the results of community cur=
rent deliberations.




If the YANG use and knowledge spread, this document will evolve in the futu=
re.



The problem to be solved, which I faced: "RFC6087 is informational (as=
 opposed to BCP), so I don't feel like I should follow it"



Regards, Benoit








=C2=A0=



Kent


=C2=A0=



=C2=A0=







On 9/11/17, 10:16 AM, "netmod on behalf of Beno=
it Claise" <netmod-bounces@ietf.org on behalf of
bclaise@cisco.com> wrote:








=C2=A0




Dear all,



I'm wondering if it's not time to classify draft-ietf-netmod-rfc608=
7bis as a BCP, as opposed to informational



This text would need to change:




=C2=A0=C2=A0 This document is similar to the Structure of Management


=C2=A0=C2=A0 Information


=C2=A0=C2=A0 version 2 (SMIv2) usage guidelines specification [RFC4181=
] in intent


=C2=A0=C2=A0 and structure.=C2=A0 However, since that document was wri=
tten a decade


=C2=A0=C2=A0 after SMIv2 modules had been in use, it was published as =
a 'Best


=C2=A0=C2=A0 Current Practice' (BCP).=C2=A0 This document is not a=
 BCP, but rather an


=C2=A0=C2=A0 informational reference, intended to promote consistency =
in documents


=C2=A0=C2=A0 containing YANG modules.


=C2=A0




Indeed, it seems to me that the consistency in YANG =
modules is a pretty important topic.



Feedback?



Regards, Benoit
















_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a11401a04cc68c0055bc25b0b--


From nobody Tue Oct 17 12:49:40 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6F513292A; Tue, 17 Oct 2017 12:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv4-Iu3VKNnV; Tue, 17 Oct 2017 12:49:36 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A07D132705; Tue, 17 Oct 2017 12:49:35 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQV30202; Tue, 17 Oct 2017 19:49:32 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 20:49:31 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001;  Tue, 17 Oct 2017 12:49:27 -0700
From: Alexander Clemm 
To: Kent Watsen , Alexander Clemm , "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" , "draft-ietf-netmod-rfc6087bis@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QA8+mcxSk5vUmECY2lUkQ4OqLoNIuAgADU1oD//56TYA==
Date: Tue, 17 Oct 2017 19:49:26 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com>
References:  <001701d3470b$8f473fe0$add5bfa0$@clemm.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59E65ECD.0075, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 5fcc494bb5ef979f6997c9a15e26cdc5
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 19:49:38 -0000

Hi Kent

Two quick replies, inline, 

Thanks
--- Alex

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
> Sent: Tuesday, October 17, 2017 11:30 AM
> To: Alexander Clemm ; netmod@ietf.org
> Cc: netmod-chairs@ietf.org; draft-ietf-netmod-rfc6087bis@ietf.org
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
>=20
> Hi Alex,
>=20
> > (Resending, apologies in case of duplicates)
>=20
> Resending? This is the first time I'm seeing these.  Did you send them wh=
en
> the Last Call was open before?  The Last Call closed a couple weeks ago  =
;)

 I suspected there was a problem with my mailer.  So I am glad I rese=
nt them. No, the comments are "fresh", not from weeks ago


>=20
> I don't want to reopen rfc6087bis for anything less than Errata at this p=
oint (or
> promoting it to a BCP, but that's a different thing altogether).  It seem=
s that
> some of your suggestions could go into the new "guidelines-next" issue
> tracker [1].  We may also consider adding information to the FAQ [2].
> Regarding Security Considerations, I think that a "node" can be the root =
of a
> subtree, and the rubbery- ness is likely from [3] and can be addressed
> separately.

 I saw other comments on the list just yesterday, and was encouraged =
off-line to send my comments and also to review more documents;-)  so I jus=
t went ahead and did.  Sure, I have no problems to not hold up the draft - =
as commented on the other thread, I would like to see drafts progress faste=
r, not slower, even if it means some churn further down the road.  That sai=
d, I do think that guidelines re: RPC modeling, and extending/augmenting gr=
oupings are currently lacking and needing improvement at some point. =20

Re: rubbery-ness, no, this is taken from this draft, not from 6087. =20

--- Alex


>=20
> [1] https://github.com/netmod-wg/guidelines-next/issues
> [2] https://github.com/netmod-wg/FAQ/wiki
> [3] http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guideline=
s
>=20
> What do you think?
>=20
> Kent // shepherd
>=20
>=20
>=20
> I have reviewed some parts of the draft and have just a few comments as
> well:
>=20
> -	One area where guidelines are missing, but where guidance would
> be
> needed, concerns how to model return values from RPCs, as well as how to
> model the handling of RPC error conditions.  This is an area where I thin=
k
> YANG itself could need some improvement, and in its absence good
> guidelines would be even more important.
> -	It would be also useful to provide guidelines regarding how to
> augment/extend groupings.  This is a common scenario and what to do is no=
t
> necessarily intuitive, so I am sure many users would appreciate guideline=
s
> here.
> -	Section 3.4: It would be good to provide a guideline regarding lines
> that exceed 70 columns (from the pyang tree output), at least mention tha=
t
> authors need to manually address this issue
> -	Section 3.7: Personally, I think the security considerations as
> currently stated, while well-intended, introduce a bit too much red tape.
> Specifically, this concerns having to list nodes individually - this can =
lead to
> defining many "trees" while missing the "forest".  The guidelines are a b=
it
> "rubbery" here, by the way, stating that data nodes MUST be individually
> listed and discussed, at the same time only if they "could be especially
> disruptive" - what does that mean - so maybe the requirement should simpl=
y
> be a "SHOULD" here?
> -	Observation: there is no mention/guideline canonical order of YANG
> statements.
>=20
> Thanks
> --- Alex
>=20
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
> Sent: Tuesday, September 12, 2017 11:22 AM
> To: netmod@ietf.org
> Cc: netmod-chairs@ietf.org; draft-ietf-netmod-rfc6087bis@ietf.org
> Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
>=20
>=20
> This starts a two-week working group last call on:
>=20
>     Guidelines for Authors and Reviewers of YANG Data Model Documents
>     https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-
> 2D14&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> =3DiR7m1fbjxuH4HW0Ws7SS-
> jWBlHsFIVCZEbG2vxMtmno&s=3DmQRtxCYVsN0ttmets8w-8a-
> VBh3vh9rJj_NJVhtGa4k&e=3D
>=20
> Please send email to the list indicating your support or concerns.
>=20
> We are particularly interested in statements of the form:
>   * I have reviewed this draft and found no issues.
>   * I have reviewed this draft and found the following issues: ...
>=20
>=20
> Thank you,
> NETMOD WG Chairs
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuh
> r6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> =3DiR7m1fbjxuH4HW0Ws7SS-
> jWBlHsFIVCZEbG2vxMtmno&s=3DNeFF02cR18ZWLxBX0kSsjAolx0QUWN4ChF3_
> GJc9WMc&e=3D
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Oct 17 13:43:43 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892BA1330AF for ; Tue, 17 Oct 2017 13:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 NNnczZXnqgcL for ; Tue, 17 Oct 2017 13:43:41 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0132.outbound.protection.outlook.com [104.47.36.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA07132331 for ; Tue, 17 Oct 2017 13:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WcCOVscnHAf/56eeJo0Q333KgrEYPsw7UlLHk1jQ5kU=; b=VHAaMwxjNtKtkohrI5l9dvyt2dRqfnu7qlKsQj0v1oGAEJcSVGWLx61cyRUTqBsRzc/OH5ihgH3bC0ssjX0d0cCTKDw09tAdGM3baryh6J1aZF20TPSviGdGGckDOJkDPxYvfM11+p32hlTjrLZlfvfd47DbSBTyX2IsGPp3y/Q=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB274.namprd05.prod.outlook.com (10.141.22.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Tue, 17 Oct 2017 20:43:39 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0156.004; Tue, 17 Oct 2017 20:43:39 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: can a 'must' statement point to a 'choice' node?
Thread-Index: AQHTR4icwUSa9YanyUOWmcXwY5xHbg==
Date: Tue, 17 Oct 2017 20:43:39 +0000
Message-ID: <5A9EB15B-469A-4A63-8884-C97F935F31FB@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:3ccoOn08aD2mgbHH4cxKQopEtmi1uR4t31gvL+Khr1Bgc7oErqySCulrKOzQTpHaaFcPdYRE7tXioBok4AzlOR152FCcAtfTya5v96Ox4J9TrhnU+fU4JmaejfXXa82jKlzvs8qnWVmVPTKeTeTqMvjwErQM90Lotr6xbv/gnbg9vfyhqsn95/+2cqee+nKrF0N7KLcA5tZknSUZPoYDkpVT4gUN3lGSRvJkgdI8cWMkLIhiS7f56sZN0BkEPcH35a88cyX2QC0SKrhLmjqu11OuwlXu9fehCJO11DYiXIZHlM/dXev+Ba/YlWAs/+z52jVZruQJKvF8LdGz3BN91g==; 5:KR2FJNTvt4oWwZ61ShknducEUzYlnE/PdQytdRzx2Q7UMrwtCd+gzo/nA3d1rTEqsGSc863VWNHcVjl26Qh9JOaRcF+8CZHHJZWazPqufuP1Jtp7oarVYdRAe/PX0/A9g215EBes+CbyiAyp63ioyGu6NNsck6QrOuxhVDDygtY=; 24:zFK7Wa1RbwoS+nsK84NBW7Hx/fHtVtqypejRAO6JcFeWhMGFdhYRLj3q1cLs/18GZzmJkyIuksdLlt0/I6vmMdp12uUrA9vueLC/pBsdbmg=; 7:PRMSbT+860hU8A+xDEGlgzOkZEuqNprQK8LyZzk4724q0Jv+h+2ZfI9hBBC8YxtDruRecv70ntW81qZzuDtV0jdQy8eSs0PsCFF6VUVJkOFS3s6dvgcgjvHKygsCU798XgOUdnIBE9ZcWChOL22ngYXlCqXEL0rzjTGRwnNTmzW2vQYtIBp1evFyJLGAqVmbyA2Hr1U/4kDAcHeQpbJcJtLBzzNRuxN/WaFSFbMEmrA=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 40538529-053b-4452-2845-08d5159fbf25
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB274; 
x-ms-traffictypediagnostic: BLUPR05MB274:
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB274; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB274; 
x-forefront-prvs: 04631F8F77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(199003)(189002)(2501003)(7736002)(6916009)(305945005)(6512007)(102836003)(6116002)(3846002)(83506001)(5660300001)(99286003)(106356001)(8676002)(83716003)(58126008)(478600001)(1730700003)(81156014)(81166006)(14454004)(25786009)(86362001)(2351001)(316002)(105586002)(8936002)(33656002)(82746002)(101416001)(66066001)(3660700001)(68736007)(77096006)(5640700003)(2900100001)(2906002)(97736004)(53936002)(189998001)(36756003)(50986999)(3280700002)(54356999)(6486002)(6506006)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB274; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 40538529-053b-4452-2845-08d5159fbf25
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 20:43:39.2409 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB274
Archived-At: 
Subject: [netmod] can a 'must' statement point to a 'choice' node?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 20:43:42 -0000

DQpJJ20gZ2V0dGluZyBtaXhlZCByZXN1bHRzIGZyb20gcHlhbmcgYW5kIHlhbmdsaW50LiAgQ2Fu
IHRoZSBYUGF0aCB1c2VkDQppbiBhICdtdXN0JyBzdGF0ZW1lbnQgcG9pbnQgdG8gYSAnY2hvaWNl
JyBub2RlPyAgDQoNCkluIHRoZSBiZWxvdyBZQU5HIHNuaXBwZXQgZnJvbSB0aGUgemVyb3RvdWNo
IGRyYWZ0LCB0aGUgaWRlYSBpcyB0aGF0LCBpZg0KYXQgbGVhc3Qgb25lIFVSSSBpcyBzcGVjaWZp
ZWQsIHRoZW4gYSBoYXNoIG5lZWRzIHRvIGJlIHByZXNlbnQgYXMgd2VsbCwgDQpidXQgYW55IGhh
c2ggaXMgb2theSwgaW5jbHVkaW5nIGhhc2gtdHlwZXMgdGhhdCBhcmUgYXVnbWVudGVkIGludG8g
dGhlDQpjaG9pY2Ugbm9kZSBpbiB0aGUgZnV0dXJlLg0KDQpLLiAgLy8gY29udHJpYnV0b3INCg0K
DQogICAgICAgIGNvbnRhaW5lciBib290LWltYWdlIHsNCg0KICAgICAgICAgIGxlYWYtbGlzdCB1
cmkgew0KICAgICAgICAgICAgdHlwZSBpbmV0OnVyaTsNCiAgICAgICAgICAgIG11c3QgJy4uL2hh
c2gtYWxnb3JpdGhtJyB7ICAgICA8LS0tLS0tLSBUSElTIE9ORSBIRVJFDQogICAgICAgICAgICAg
IGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgIkEgaGFzaCBpcyBuZWVkZWQgaW4gb3JkZXIg
dG8gdmFsaWRhdGUgdGhlIGRvd25sb2FkZWQNCiAgICAgICAgICAgICAgICAgaW1hZ2UuIjsNCiAg
ICAgICAgICAgIH0NCiAgICAgICAgICAgIG9yZGVyZWQtYnkgdXNlcjsNCiAgICAgICAgICAgIGRl
c2NyaXB0aW9uDQogICAgICAgICAgICAgICJBbiBvcmRlcmVkIGxpc3Qgb2YgVVJJcyB0byB3aGVy
ZSB0aGUgYm9vdC1pbWFnZSBmaWxlDQogICAgICAgICAgICAgICBNQVkgYmUgb2J0YWluZWQuICBE
ZXBsb3ltZW50cyBNVVNUIGtub3cgaW4gd2hpY2ggVVJJDQogICAgICAgICAgICAgICBzY2hlbWVz
IChodHRwLCBmdHAsIGV0Yy4pIGEgZGV2aWNlIHN1cHBvcnRzLiAgSWYgYQ0KICAgICAgICAgICAg
ICAgc2VjdXJlIHNjaGVtZSAoZS5nLiwgaHR0cHMpIGlzIHByb3ZpZGVkLCBhIGRldmljZSBNQVkN
CiAgICAgICAgICAgICAgIGVzdGFibGlzaCBhIHByb3Zpc2lvbmFsIGNvbm5lY3Rpb24gdG8gdGhl
IHNlcnZlciwgYnkNCiAgICAgICAgICAgICAgIGJsaW5kbHkgYWNjZXB0aW5nIHRoZSBzZXJ2ZXIn
cyBjcmVkZW50aWFscyAoZS5nLiwgaXRzDQogICAgICAgICAgICAgICBUTFMgY2VydGlmaWNhdGUp
IjsNCiAgICAgICAgICB9DQoNCiAgICAgICAgICBjaG9pY2UgaGFzaC1hbGdvcml0aG0gew0KICAg
ICAgICAgICAgbXVzdCAnLi4vdXJpJyB7ICA8LS0tLS0gRE9FUyBUSElTIEdFTkVSQVRFIEEgQ0lS
Q1VMQVIgRVZBTD8NCiAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAi
QSB1cmkgaXMgbmVlZGVkIGluIG9yZGVyIHRvIGRvd25sb2FkZWQgYW4gaW1hZ2UgdG8NCiAgICAg
ICAgICAgICAgICAgdmFsaWRhdGUuIjsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGRlc2Ny
aXB0aW9uDQogICAgICAgICAgICAgICJJZGVudGlmaWVzIHRoZSBoYXNoIGFsZ29yaXRobSB1c2Vk
LiI7DQogICAgICAgICAgICBsZWFmIHNoYTI1NiB7DQogICAgICAgICAgICAgIHR5cGUgeWFuZzpo
ZXgtc3RyaW5nOw0KICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICJU
aGUgaGV4LWVuY29kZWQgU0hBLTI1NiBoYXNoIG92ZXIgdGhlIGJvb3QgaW1hZ2UNCiAgICAgICAg
ICAgICAgICAgZmlsZS4gIFRoaXMgaXMgdXNlZCBieSB0aGUgZGV2aWNlIHRvIHZlcmlmeSBhIA0K
ICAgICAgICAgICAgICAgICBkb3dubG9hZGVkIGJvb3QgaW1hZ2UgZmlsZS4iOw0KICAgICAgICAg
ICAgICByZWZlcmVuY2UgIlJGQyA2MjM0OiBVUyBTZWN1cmUgSGFzaCBBbGdvcml0aG1zLiI7DQog
ICAgICAgICAgICB9DQogICAgICAgICAgfQ0KICAgICAgICB9DQoNCg0K


From nobody Tue Oct 17 16:06:49 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE437132396; Tue, 17 Oct 2017 16:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU05T9rrDiet; Tue, 17 Oct 2017 16:06:46 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADEE112426E; Tue, 17 Oct 2017 16:06:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=834; q=dns/txt; s=iport; t=1508281606; x=1509491206; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2HcAHl/U+mzX0a9AP/aeNRcgRWe+xbOOt2vi6acz/I0=; b=gbJC6eQO3DmKbRSLJl5jVmE7xSleN5STa169IwFW1AZuzzd+4GB0D1G0 hIqZDuNLEDNXlFf2/WXRWwnwHFPyx1nPt6/zCN8QxoZ4ae6X+Eg3yFZAc gQm78CGCngkFUWeIXDHYZq7qL+gDG41s4bW6O+84E27QiSLxbn0GzYuMC 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAACZjOZZ/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1+BUi6OEo83mCuCFAqFOwKEbD8YAQIBAQEBAQEBax0LhR4GOj8?= =?us-ascii?q?QAgEINhAyJQIEDg2KFaxxizoBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgy6CB4FRh?= =?us-ascii?q?RWKeQWhSwKUYJMhlUMCERkBgTgBHziBWXoVgy6EXokgLIEFgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,392,1503360000"; d="scan'208";a="309052249"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2017 23:06:45 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v9HN6jGG017380 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2017 23:06:45 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Oct 2017 19:06:44 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Tue, 17 Oct 2017 19:06:44 -0400
From: "Eric Voit (evoit)" 
To: "draft-ietf-netmod-rfc6087bis@ietf.org" 
CC: "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QAeOXxoJMMEUGe5/uottVNQaLoNIuAgADU1oD//56TYIAAL14w
Date: Tue, 17 Oct 2017 23:06:44 +0000
Message-ID: <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com>
References:  <001701d3470b$8f473fe0$add5bfa0$@clemm.org>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Oct 2017 23:06:48 -0000

I was also encouraged to provide comments.  A couple (new?) minor ones...

Section 3.4:
- If a tree diagram is included for an augmented model, it SHOULD contain t=
he integrated of the augmented model.  I.e., use the pyang -f command to ge=
nerate the tree so that you can explicitly see the schema elements imported=
=20

Side comment: if a YANG module contains extension structures (like YANG-Dat=
a) these should also be shown in the tree, but I understand why you might n=
ot want to make that a requirement of this document.

Section 3.10: There should be a normative set of YANG validation tools whic=
h are run on upload of an Internet draft.   Errors and warnings found later=
 (and perhaps through tools a user doesn't have) should not result in a mod=
ule being given an error designation.

Thanks,
Eric



From nobody Tue Oct 17 23:22:38 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEC4132F2C; Tue, 17 Oct 2017 23:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-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 JhwLi0Q5PA7t; Tue, 17 Oct 2017 23:22:31 -0700 (PDT)
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 108B213243A; Tue, 17 Oct 2017 23:22:31 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 470076AD; Wed, 18 Oct 2017 08:22:29 +0200 (CEST)
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 9yMCZw_6gUB6; Wed, 18 Oct 2017 08:22:29 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Oct 2017 08:22:29 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33356200FD; Wed, 18 Oct 2017 08:22:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DIO9BepHFET0; Wed, 18 Oct 2017 08:22:29 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D00A8200FC; Wed, 18 Oct 2017 08:22:28 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 904FE4130C03; Wed, 18 Oct 2017 08:22:28 +0200 (CEST)
Date: Wed, 18 Oct 2017 08:22:28 +0200
From: Juergen Schoenwaelder 
To: "Eric Voit (evoit)" 
Cc: "draft-ietf-netmod-rfc6087bis@ietf.org" ,  "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Message-ID: <20171018062228.dx7etbayhuslswkx@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Eric Voit (evoit)" , "draft-ietf-netmod-rfc6087bis@ietf.org" ,  "netmod-chairs@ietf.org" , "netmod@ietf.org" 
References:  <001701d3470b$8f473fe0$add5bfa0$@clemm.org>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com> <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 06:22:33 -0000

On Tue, Oct 17, 2017 at 11:06:44PM +0000, Eric Voit (evoit) wrote:
> 
> Section 3.10: There should be a normative set of YANG validation tools which are run on upload of an Internet draft.   Errors and warnings found later (and perhaps through tools a user doesn't have) should not result in a module being given an error designation.
>

I disagree. An error is an error regardless when or how it was
detected.

/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 Oct 17 23:35:33 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4326B1321F5 for ; Tue, 17 Oct 2017 23:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Dl82p2dMX5Un for ; Tue, 17 Oct 2017 23:35:29 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A074D1241F3 for ; Tue, 17 Oct 2017 23:35:29 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id AFAE41AE030A; Wed, 18 Oct 2017 08:35:25 +0200 (CEST)
Date: Wed, 18 Oct 2017 08:33:58 +0200 (CEST)
Message-Id: <20171018.083358.809136696875122578.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <5A9EB15B-469A-4A63-8884-C97F935F31FB@juniper.net>
References: <5A9EB15B-469A-4A63-8884-C97F935F31FB@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] can a 'must' statement point to a 'choice' node?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 06:35:31 -0000

Kent Watsen  wrote:
> 
> I'm getting mixed results from pyang and yanglint.  Can the XPath used
> in a 'must' statement point to a 'choice' node?  

No, since the choice node is not present in the data tree.  And note
that pyang doesn't validate XPath expressions (except for syntax).

> In the below YANG snippet from the zerotouch draft, the idea is that, if
> at least one URI is specified, then a hash needs to be present as well, 
> but any hash is okay, including hash-types that are augmented into the
> choice node in the future.

This can't be expressed, unless you also add a container 'hash', or
make the hash a single leaf of type identityref.


/martin


> 
> K.  // contributor
> 
> 
>         container boot-image {
> 
>           leaf-list uri {
>             type inet:uri;
>             must '../hash-algorithm' {     <------- THIS ONE HERE
>               description
>                 "A hash is needed in order to validate the downloaded
>                  image.";
>             }
>             ordered-by user;
>             description
>               "An ordered list of URIs to where the boot-image file
>                MAY be obtained.  Deployments MUST know in which URI
>                schemes (http, ftp, etc.) a device supports.  If a
>                secure scheme (e.g., https) is provided, a device MAY
>                establish a provisional connection to the server, by
>                blindly accepting the server's credentials (e.g., its
>                TLS certificate)";
>           }
> 
>           choice hash-algorithm {
>             must '../uri' {  <----- DOES THIS GENERATE A CIRCULAR EVAL?
>               description
>                 "A uri is needed in order to downloaded an image to
>                  validate.";
>             }
>             description
>               "Identifies the hash algorithm used.";
>             leaf sha256 {
>               type yang:hex-string;
>               description
>                 "The hex-encoded SHA-256 hash over the boot image
>                  file.  This is used by the device to verify a 
>                  downloaded boot image file.";
>               reference "RFC 6234: US Secure Hash Algorithms.";
>             }
>           }
>         }
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Oct 17 23:45:44 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2631321F5; Tue, 17 Oct 2017 23:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8CFNU_lduG7E; Tue, 17 Oct 2017 23:45:42 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 136D41320CF; Tue, 17 Oct 2017 23:45:42 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 102D91AE030A; Wed, 18 Oct 2017 08:45:40 +0200 (CEST)
Date: Wed, 18 Oct 2017 08:44:14 +0200 (CEST)
Message-Id: <20171018.084414.1757301754342626778.mbj@tail-f.com>
To: evoit@cisco.com
Cc: draft-ietf-netmod-rfc6087bis@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com>
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com> <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 06:45:43 -0000

Hi,

"Eric Voit (evoit)"  wrote:
> I was also encouraged to provide comments.  A couple (new?) minor ones...
> 
> Section 3.4:
> - If a tree diagram is included for an augmented model, it SHOULD
> contain the integrated of the augmented model.  I.e., use the pyang
> -f command to generate the tree so that you can explicitly see the
> schema elements imported  

I agree that it would be good if 3.4 talks about this case.

But I think that the recommendation should be that the "imported tree"
just shows the structure (containers and lists), but not all other
nodes.  For an example of what I mean, see Section 2 of RFC 7277.



/martin


From nobody Wed Oct 18 05:35:43 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1E1321CB; Wed, 18 Oct 2017 05:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS7LLd_Lhfvr; Wed, 18 Oct 2017 05:35:39 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56721320C9; Wed, 18 Oct 2017 05:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1092; q=dns/txt; s=iport; t=1508330138; x=1509539738; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z2JrWXcmZxbwG8EjCt/fYxYQDLxcCrl2s9mYEAww5uo=; b=baSq3wf8sMFl1hTBf830Bin0gkzT0co6EkbNE1MMR7g81W+7wvEn/NLg PVv48+q2r8k7wc2XIu20YDiqrhvMUGftJP378UmfFK8W3w13CWTiM06Fp b8A+sfB0DrpAiW9nXJQ+JoNZruqfbNXFxJvbPemx+iqyKdDjkEJmcteYP 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAADTSedZ/49dJa1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNfZG4ujhKPOIF4ljOCFAofhRwChHk/GAECAQEBAQEBAWsohR0?= =?us-ascii?q?BAQEDATo/BQkCAgEIDgIFAx4QGxclAgQODROJfQisbos5AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHQWDKoIHgVGFF4UmJoUtBaFLApRhkyGVRgIRGQGBOAEfOIFbehW?= =?us-ascii?q?DLgiEVokbLIEFgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,396,1503360000"; d="scan'208";a="18130131"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2017 12:35:37 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v9ICZb0K019549 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Oct 2017 12:35:37 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 18 Oct 2017 08:35:36 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1320.000; Wed, 18 Oct 2017 08:35:36 -0400
From: "Eric Voit (evoit)" 
To: Juergen Schoenwaelder 
CC: "draft-ietf-netmod-rfc6087bis@ietf.org" , "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QAeOXxoJMMEUGe5/uottVNQaLoNIuAgADU1oD//56TYIAAL14wgADGxQCAAB2HcA==
Date: Wed, 18 Oct 2017 12:35:36 +0000
Message-ID: 
References:  <001701d3470b$8f473fe0$add5bfa0$@clemm.org>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com> <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com> <20171018062228.dx7etbayhuslswkx@elstar.local>
In-Reply-To: <20171018062228.dx7etbayhuslswkx@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 12:35:41 -0000

> From: Juergen Schoenwaelder, October 18, 2017 2:22 AM
>=20
> On Tue, Oct 17, 2017 at 11:06:44PM +0000, Eric Voit (evoit) wrote:
> >
> > Section 3.10: There should be a normative set of YANG validation tools =
which
> are run on upload of an Internet draft.   Errors and warnings found later=
 (and
> perhaps through tools a user doesn't have) should not result in a module =
being
> given an error designation.
> >
>=20
> I disagree. An error is an error regardless when or how it was detected.

What I am trying to avoid is YANG errors being discovered via validation to=
ols for which the model author has no access to before a submitted draft is=
 accepted.   However this can be accomplished is fine with me.

One solution is to ensure the RFC upload process has access to all tools cu=
rrently used for model validation. =20

Eric

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


From nobody Wed Oct 18 06:55:23 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBF213420D; Wed, 18 Oct 2017 06:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zXr_URXch8W; Wed, 18 Oct 2017 06:55:19 -0700 (PDT)
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 07FA21332E4; Wed, 18 Oct 2017 06:55:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CEE60F34; Wed, 18 Oct 2017 15:55:17 +0200 (CEST)
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 5QEARIiXJSTZ; Wed, 18 Oct 2017 15:55:18 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Oct 2017 15:55:17 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB3EA200FC; Wed, 18 Oct 2017 15:55:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zwMxbiu5_Z8R; Wed, 18 Oct 2017 15:55:17 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A18F200F1; Wed, 18 Oct 2017 15:55:17 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2860241320A7; Wed, 18 Oct 2017 15:55:16 +0200 (CEST)
Date: Wed, 18 Oct 2017 15:55:15 +0200
From: Juergen Schoenwaelder 
To: "Eric Voit (evoit)" 
Cc: "draft-ietf-netmod-rfc6087bis@ietf.org" ,  "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Message-ID: <20171018135515.vukzcysvrfxn2m3p@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Eric Voit (evoit)" , "draft-ietf-netmod-rfc6087bis@ietf.org" ,  "netmod-chairs@ietf.org" , "netmod@ietf.org" 
References:  <001701d3470b$8f473fe0$add5bfa0$@clemm.org>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com> <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com> <20171018062228.dx7etbayhuslswkx@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 13:55:22 -0000

On Wed, Oct 18, 2017 at 12:35:36PM +0000, Eric Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, October 18, 2017 2:22 AM
> > 
> > On Tue, Oct 17, 2017 at 11:06:44PM +0000, Eric Voit (evoit) wrote:
> > >
> > > Section 3.10: There should be a normative set of YANG validation tools which
> > are run on upload of an Internet draft.   Errors and warnings found later (and
> > perhaps through tools a user doesn't have) should not result in a module being
> > given an error designation.
> > >
> > 
> > I disagree. An error is an error regardless when or how it was detected.
> 
> What I am trying to avoid is YANG errors being discovered via validation tools for which the model author has no access to before a submitted draft is accepted.   However this can be accomplished is fine with me.
>

I think this generally can't be avoided but then this should also not
be a common problem as things are getting more stable.

> One solution is to ensure the RFC upload process has access to all tools currently used for model validation.

This is a reasonable request to make for the tool makers. Having a
notion of normative YANG validation tools (with specific versions -
this will come next) is, however, an idea that should be avoided.

/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 Oct 18 07:09:27 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FD21326ED; Wed, 18 Oct 2017 07:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.3
X-Spam-Level: 
X-Spam-Status: No, score=-17.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcEnzIfDUVCn; Wed, 18 Oct 2017 07:09:23 -0700 (PDT)
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 8BDE91270AB; Wed, 18 Oct 2017 07:09:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2448; q=dns/txt; s=iport; t=1508335763; x=1509545363; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ONseO6QtooqDJKICd/+xEVs4OByaITsdGXH/6Yc4K9o=; b=PMgAUHQK02ICQw2lqDsH+mipobjIijYaYDcnzD+lODyU+2hzr0Uw6TQL +eHA/oqJCg1BTkjtjDxOcUra61MkmQL8qu9F23PCV7IAJFQ9avjW3Oj8E mplTKyWRGyf9F/9zGuG/W7XUMfpE3WBc+l8jWNsVEni6QoY7y1v+kU1hM A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAAAuYOdZ/51dJa1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNfZG4nB4Nzih+POIF4ljOCFAoYC4RJTwIahF8/GAECAQEBAQE?= =?us-ascii?q?BAWsohR0BAQEDAQEBIRE6Cw4CAgEIEAUDAgImAgICGQwLFRACBAENBRuJfQgQq?= =?us-ascii?q?lCCJ4s5AQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBCoIgggeGaIUFFwomgkyCYQW?= =?us-ascii?q?hSwKUapMYlUYCERkBgTgBHziBW3oVSYJkCYRWdoglLIEFgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,397,1503360000"; d="scan'208";a="307464802"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2017 14:09:22 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v9IE9MAQ009188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Oct 2017 14:09:22 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 18 Oct 2017 10:09:21 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 18 Oct 2017 10:09:21 -0400
From: "Acee Lindem (acee)" 
To: "Eric Voit (evoit)" , Juergen Schoenwaelder 
CC: "netmod-chairs@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-rfc6087bis@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QA8+mcxSk5vUmECY2lUkQ4OqLoAkGAgADU1oCAABYiAIAANyAAgAB5vgCAAGhAAP//1wyA
Date: Wed, 18 Oct 2017 14:09:21 +0000
Message-ID: 
References:  <001701d3470b$8f473fe0$add5bfa0$@clemm.org>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com> <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com> <20171018062228.dx7etbayhuslswkx@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.195]
Content-Type: text/plain; charset="utf-8"
Content-ID: <018B7B8ECFF9654389D8C21AC6DBA7F3@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 14:09:25 -0000

DQoNCk9uIDEwLzE4LzE3LCA4OjM1IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBFcmljIFZvaXQg
KGV2b2l0KSINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZXZvaXRAY2lz
Y28uY29tPiB3cm90ZToNCg0KPj4gRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBPY3RvYmVy
IDE4LCAyMDE3IDI6MjIgQU0NCj4+IA0KPj4gT24gVHVlLCBPY3QgMTcsIDIwMTcgYXQgMTE6MDY6
NDRQTSArMDAwMCwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6DQo+PiA+DQo+PiA+IFNlY3Rpb24g
My4xMDogVGhlcmUgc2hvdWxkIGJlIGEgbm9ybWF0aXZlIHNldCBvZiBZQU5HIHZhbGlkYXRpb24N
Cj4+dG9vbHMgd2hpY2gNCj4+IGFyZSBydW4gb24gdXBsb2FkIG9mIGFuIEludGVybmV0IGRyYWZ0
LiAgIEVycm9ycyBhbmQgd2FybmluZ3MgZm91bmQNCj4+bGF0ZXIgKGFuZA0KPj4gcGVyaGFwcyB0
aHJvdWdoIHRvb2xzIGEgdXNlciBkb2Vzbid0IGhhdmUpIHNob3VsZCBub3QgcmVzdWx0IGluIGEN
Cj4+bW9kdWxlIGJlaW5nDQo+PiBnaXZlbiBhbiBlcnJvciBkZXNpZ25hdGlvbi4NCj4+ID4NCj4+
IA0KPj4gSSBkaXNhZ3JlZS4gQW4gZXJyb3IgaXMgYW4gZXJyb3IgcmVnYXJkbGVzcyB3aGVuIG9y
IGhvdyBpdCB3YXMgZGV0ZWN0ZWQuDQo+DQo+V2hhdCBJIGFtIHRyeWluZyB0byBhdm9pZCBpcyBZ
QU5HIGVycm9ycyBiZWluZyBkaXNjb3ZlcmVkIHZpYSB2YWxpZGF0aW9uDQo+dG9vbHMgZm9yIHdo
aWNoIHRoZSBtb2RlbCBhdXRob3IgaGFzIG5vIGFjY2VzcyB0byBiZWZvcmUgYSBzdWJtaXR0ZWQN
Cj5kcmFmdCBpcyBhY2NlcHRlZC4gICBIb3dldmVyIHRoaXMgY2FuIGJlIGFjY29tcGxpc2hlZCBp
cyBmaW5lIHdpdGggbWUuDQo+DQo+T25lIHNvbHV0aW9uIGlzIHRvIGVuc3VyZSB0aGUgUkZDIHVw
bG9hZCBwcm9jZXNzIGhhcyBhY2Nlc3MgdG8gYWxsIHRvb2xzDQo+Y3VycmVudGx5IHVzZWQgZm9y
IG1vZGVsIHZhbGlkYXRpb24uDQoNClJpZ2h0IG5vdyBZQU5HIHZhbGlkYXRpb24gZXJyb3JzIGFu
ZCB3YXJuaW5ncyBkbyBub3QgYmxvY2sgc3VibWl0dGFsLiBUaGlzDQpnb29kIHNpbmNlIHRoZXJl
IGFyZSBzb21lIHZlcnkgYW5ub3lpbmcgZmFsc2UgcG9zaXRpdmVzIGluIHRoZSBkcmFmdCBZQU5H
DQp2YWxpZGF0aW9uLiBGb3IgZXhhbXBsZSwgc3VibW9kdWxlIHZhbGlkYXRpb24gaXMgYnJva2Vu
IGV2ZW4gaWYgdGhlIG1vZHVsZQ0KYW5kIHN1Ym1vZHVsZSBhcmUgaW4gdGhlIHNhbWUgZHJhZnQu
IEFkZGl0aW9uYWxseSwgdGhlIHN0YXR1cyB2YWxpZGF0aW9uDQpzcG91dHMgb3V0IGZhbHNlIHdh
cm5pbmdzLiBJIHJlcG9ydGVkIHRoZSBmaXJzdCBwcm9ibGVtIGFuZCBpdCB3YXMgYmxvd24NCm9m
Zi4gDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KDQoNCj4NCj5FcmljDQo+DQo+PiAvanMNCj4+IA0K
Pj4gLS0NCj4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNp
dHkgQnJlbWVuIGdHbWJIDQo+PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1
cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+PiBGYXg6ICAgKzQ5IDQyMSAyMDAg
MzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWls
aW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZA0KDQo=


From nobody Wed Oct 18 07:36:57 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85D21342D6 for ; Wed, 18 Oct 2017 07:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYoG6IZzeOFS for ; Wed, 18 Oct 2017 07:36:55 -0700 (PDT)
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 3F6CC13420D for ; Wed, 18 Oct 2017 07:36:55 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 17C86F69; Wed, 18 Oct 2017 16:36:54 +0200 (CEST)
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 N2ZSUcIwqPsV; Wed, 18 Oct 2017 16:36:54 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Oct 2017 16:36:54 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 046B9200FC; Wed, 18 Oct 2017 16:36:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CtYi73DPwV6D; Wed, 18 Oct 2017 16:36:53 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B22B200F1; Wed, 18 Oct 2017 16:36:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 41CAD413233F; Wed, 18 Oct 2017 16:36:52 +0200 (CEST)
Date: Wed, 18 Oct 2017 16:36:51 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20171018143651.kdsf77r65ptlu4mq@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" 
References:  <20171015.095206.5556973134711466.mbj@tail-f.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 14:36:57 -0000

On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
> > >
> > >   augment "/if:interfaces-state/if:interface" {
> > >     action reset {
> > >       description "Reset this interface";
> > >     }
> 
> Can you spot the NMDA problem above?
> Actually, it exists for in-line definitions, not just augment.
> 
> Once you collapse the interfaces-state tree into /interfaces, there
> is no way to specify whether an action is intended for 
> or a configuration datastore, or all datastores.
 
I think operations (both RPCs and actions) by default always execute
in the context of the operational state datastore. This is consistent
with the way we define the xpath context. An operation that operates
on other datastores needs to carry this information in its semantics
and typically requires special arguments to select the datastores
affected. This is how  and  work. Hence, a
reset action defined for an interface by default applies to the
operational state datastore. And this default makes likely sense for
most actions and RPCs.

If an action or RPC is expected to operate on a different datastore,
the description must explain this and there may be a need to pass a
datastore identifier to the operation. [Yes, in retrospect, one might
have designed the protocol differently so that there would always be a
datastore parameter at the protocol level but its too late for that.]

/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 Oct 18 09:29:45 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7697F1321CB for ; Wed, 18 Oct 2017 09:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7w31tZxmX-K for ; Wed, 18 Oct 2017 09:29:40 -0700 (PDT)
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 3467B13304E for ; Wed, 18 Oct 2017 09:29:40 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id 90so6488020lfs.13 for ; Wed, 18 Oct 2017 09:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=N2d/9zWeGS7WQyYSsL3Pq/9xAZVM9Ndm8ZwSrZiGALw=; b=H3tHAklajGc75DFxkQ+5LKqrWbUUvjprPaqV3enmpUvhJX6ThqQfZHJzfllQua9Axr SZNVlVcNW5K4Q8hO/Oh93UQbdo8JW4GB/b0BtU0bESN033oP/xLXhWYL5Sghy+loiyla IFd9JRc4b8koeDiagSYDFLUWdEMtCdeE4Sswl8XyaDKpUpOKdxxYDzYYo3XytWw6vbBY R1rbeAVI73vDAB2oWczIg4JfsoSopTk3JHYNe1sR4TuUTvUFIjwtcJIPjVstxN3d2A0x xnHDw2tqOLdEkaAla/2tmR4frfVN89pX7woaFNeDS7M8P1Cz/J59qoUDAqfFjc0hhWqV PLSw==
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=N2d/9zWeGS7WQyYSsL3Pq/9xAZVM9Ndm8ZwSrZiGALw=; b=OZOzXAmdiExLTNUXUi9NLzdCgNZzuo05LbVzID9IkNTzMbJTEjkIkys5YiEWqYuDwH zaUwg4zwiCEbbD6eu7FSWS7a5ixyaO+7j9r8aJN4MeITVDx5XP2Obqbbg412AqJisqy7 FSlExEdgbZJ/H1YFKTUbDoaAPVTKEIoSx6JQ/gKQJIa8le/mWrIqVfB2XywC6s1pI092 PsRAZERwFRCRXh9UnUvD4dvbWtUD/9TW9xSLjXXu7bvHijSVu8/Y2EJ//s/pDpySV1MG Ln+/8E8mZfthutda6TflyLzxZ8D5N2+WPKOHXkMv1+1ddvvuoPjBOnHE6fnr2JKy+88+ q54w==
X-Gm-Message-State: AMCzsaX9eHER1O9KS0BdEvxh8zttcBIIJNOc69//+H1y0mXZdL2y74FI O4hRZ/NG9dGOe6k/xAHLofZpYqQLxRTOA5lLMzulQg==
X-Google-Smtp-Source: ABhQp+RtFT8G5K+/N+0h0mq/ZFOWyq9u+NdCt7ffD3HKQCRx0z0wu4moT1oLgeir0LyqkgtRsOaXQywx30HWFDco3+A=
X-Received: by 10.46.83.25 with SMTP id h25mr217768ljb.158.1508344178316; Wed, 18 Oct 2017 09:29:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 18 Oct 2017 09:29:37 -0700 (PDT)
In-Reply-To: <20171018143651.kdsf77r65ptlu4mq@elstar.local>
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>
From: Andy Bierman 
Date: Wed, 18 Oct 2017 09:29:37 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f40304360142f2bc3b055bd4be72"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 16:29:42 -0000

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

On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
> > > >
> > > >   augment "/if:interfaces-state/if:interface" {
> > > >     action reset {
> > > >       description "Reset this interface";
> > > >     }
> >
> > Can you spot the NMDA problem above?
> > Actually, it exists for in-line definitions, not just augment.
> >
> > Once you collapse the interfaces-state tree into /interfaces, there
> > is no way to specify whether an action is intended for 
> > or a configuration datastore, or all datastores.
>
> I think operations (both RPCs and actions) by default always execute
> in the context of the operational state datastore. This is consistent
> with the way we define the xpath context. An operation that operates
> on other datastores needs to carry this information in its semantics
> and typically requires special arguments to select the datastores
> affected. This is how  and  work. Hence, a
> reset action defined for an interface by default applies to the
> operational state datastore. And this default makes likely sense for
> most actions and RPCs.
>


OK -- seems correct


>
> If an action or RPC is expected to operate on a different datastore,
> the description must explain this and there may be a need to pass a
> datastore identifier to the operation. [Yes, in retrospect, one might
> have designed the protocol differently so that there would always be a
> datastore parameter at the protocol level but its too late for that.]
>
>

 A top-level RPC can also be used if a datastore parameter is needed,
or an  wrapper can be defined.

The draft should be clear that the ability to invoke an action (within
a config=true parent data node) is removed. This is under-specified
in YANG so it is not really breaking anything.


/js
>

Andy


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

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




On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierm=
an wrote:

> > >

> > >=C2=A0 =C2=A0augment "/if:interfaces-state/if:inter=
face" {

> > >=C2=A0 =C2=A0 =C2=A0action reset {

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0description "Reset this inter=
face";

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

>

> Can you spot the NMDA problem above?

> Actually, it exists for in-line definitions, not just augment.

>

> Once you collapse the interfaces-state tree into /interfaces, there
> is no way to specify whether an action is intended for <operational=
>

> or a configuration datastore, or all datastores.



I think operations (both RPCs and actions) by default always execute

in the context of the operational state datastore. This is consistent

with the way we define the xpath context. An operation that operates

on other datastores needs to carry this information in its semantics

and typically requires special arguments to select the datastores

affected. This is how <get-config> and <edit-config> work. Henc=
e, a

reset action defined for an interface by default applies to the

operational state datastore. And this default makes likely sense for

most actions and RPCs.


O=
K -- seems correct
=C2=A0



If an action or RPC is expected to operate on a different datastore,

the description must explain this and there may be a need to pass a

datastore identifier to the operation. [Yes, in retrospect, one might

have designed the protocol differently so that there would always be a

datastore parameter at the protocol level but its too late for that.]




=C2=A0A top-level RPC can also be use=
d if a datastore parameter is needed,
or an <action2> wrapp=
er can be defined.

The draft should be clear that =
the ability to invoke an action (within
a config=3Dtrue parent da=
ta node) is removed. This is under-specified
in YANG so it is not=
 really breaking anything.



/js

Andy
=C2=A0=




--

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

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

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





--f40304360142f2bc3b055bd4be72--


From nobody Wed Oct 18 09:38:33 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2871321CB; Wed, 18 Oct 2017 09:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 CbIpHcUr-4rI; Wed, 18 Oct 2017 09:38:28 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BF6132031; Wed, 18 Oct 2017 09:38:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11454; q=dns/txt; s=iport; t=1508344708; x=1509554308; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ra71NrQ7+7U7GtGUl/e1iO8keJFU+alAdwRG/kw07k0=; b=irgQOglkXLkIIu1z8BHm+u8MExz3B+tP+BIatLmVa/XgDWD87VSwbmgw nRNL/baZoNIqPSanZP1frjjTeb/UmKUdRard0PYjRJnsjv9FbxE2Pf5pO 92vMzKR15A246qa6g2A9F9LlKmL+8IL68pL1pOcOzOuRz28gykmpvs5DS k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAABVgudZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ih90kD2WM4IUChgLgV6Ca08ChTgYAQIBAQEBAQEBayi?= =?us-ascii?q?FHQEBAQQBASEPAQU2BAcMBAsRBAEBAQICJgICJygIBgEMBgIBAReKBRCqb4Ini?= =?us-ascii?q?ykBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgiCDWIIVgwSIGIJhBaFLlG2CFIV?= =?us-ascii?q?2g1wkhw6OEYdigTkfOIFbNCEIHRVJgmSEYD82iw0BAQE?=
X-IronPort-AV: E=Sophos;i="5.43,397,1503360000"; d="scan'208";a="655522871"
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; 18 Oct 2017 16:38:23 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9IGcNHL029116; Wed, 18 Oct 2017 16:38:23 GMT
To: "t.petch" , netmod WG , Lou Berger 
Cc: netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <00bd01d32caf$4eb28e60$4001a8c0@gateway.2wire.net> <92a410a9-e479-2321-7420-4bd2d9dbed38@labn.net> <011e01d32d77$c980dca0$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: 
Date: Wed, 18 Oct 2017 17:38:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <011e01d32d77$c980dca0$4001a8c0@gateway.2wire.net>
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-revised-datastores-04 duplicaiton
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 16:38:32 -0000

Hi Tom,

Juergen has tweaked your proposed text into an additional objectives 
section before terminology with the following text:

2.  Objectives

    Network management data objects can often take two different values,
    the value configured by the user or an application (configuration)
    and the value that the device is actually using (operational state).
    These two values may be different for a number of reasons, e.g.,
    system internal interactions with hardware, interaction with
    protocols or other devices, or simply the time it takes to propagate
    a configuration change to the software and hardware components of a
    system.  Furthermore, configuration and operational state data
    objects may have different lifetimes.

    The original model of datastores required these data objects to be
    modeled twice in the YANG schema, as "config true" objects and as
    "config false" objects.  The convention adopted by the interfaces
    data model ([RFC7223]) and the IP data model ([RFC7277]) was using
    two separate branches rooted at the root of the data tree, one branch
    for configuration data objects and one branch for operational state
    data objects.

    The duplication of definitions and the ad-hoc separation of
    operational state data from configuration data leads to a number of
    problems.  Having configuration and operational state data in
    separate branches in the data model is operationally complicated and
    impacts the readability of module definitions. Furthermore, the
    relationship between the branches is not machine readable and filter
    expressions operating on configuration and on related operational
    state are different.

    With the revised architectural model of datastores defined in this
    document, the data objects are defined only once in the YANG schema
    but independent instantiations can appear in two different
    datastores, one for configured values and one for operational state
    values.  This provides a more elegant and simpler solution to the
    problem.

    The revised architectural model of datastores supports additional
    datastores for systems that support more advanced processing chains
    converting configuration to operational state.  For example, some
    systems support configuration that is not currently used (so called
    inactive configuration) or they support configuration templates that
    are used to expand configuration data via a common template.

This also removes the following, now repetitive, paragraph from the 
Background Section:

  Furthermore, separating operational state from configuration
  in a separate branch in the data model has been found operationally
  complicated, and typically impacts the readability of module
  definitions due to overuse of groupings.  The relationship between the
  branches is not machine readable and filter expressions operating on
  configuration and on related operational state are

OK?

We should provide an updated draft with all the last call review markups 
applied soon, which may make it easier to review this text in context.

Thanks,
Rob


On 14/09/2017 17:37, t.petch wrote:
> Lou
>
> I am proposing that the text I included would go more or less as is into
> the beginning of section 3.  I think that it makes sense even before we
> get into the historic definitions of configuration etc.  I want to spell
> out the problem - two different values of the one conceptual object,
> originally handled with two schema nodes in one store of data, now
> handled with one schema node in two datastores.  Thus start section 3
> with
>
> NEW
>
> Some data objects can take two different values, the one configured by
> the user (configuration), the other the one that the device is using
> (operational state),
> perhaps as a result of interactions with hardware, with protocols, with
> other devices and so on.
>
>   The original model of datastores
> required these data objects to be modelled twice, as configuration false
> and as configuration true, and, since there could be many of them, and
> the rules of YANG require them to be in separate trees, this led to a
> twin-trees approach, such as can be seen in RFC7277 or RFC7223.
>
> This duplication of definitions and separation of operationsl state from
> configuration leads to a number of problems.  Having them in
>   separate branches in the data model is operationally
> complicated and impacts the readability of module
>   definitions.  The relationship between
>   the branches is not machine readable and filter expressions operating
> on configuration and on related operational state are different.
>
> With revised datastores,  the data object appears once in the model
> but can appear in two datastores, one for the
> configured value, one for the operational state value.
>
>   Instead of two YANG data nodes there is one data node in two
> datastores, a more elegant and simpler solution to the problem.
>
> /NEW
>
> I would make minor changes to the last three paragraphs of Section 3
> mostly excising where I have already included that material
>
> Tom Petch
>
>>> The problem that is hinted at but never explicitly stated is that
> data
>>> objects can appear both as configuration and as state, e.g. when
> learned
>>> by other means or at other times.  The original model of datastores
>>> required these data objects to be modelled twice, as configuration
> false
>>> and as configuration true, and since there could be many of them,
> and
>>> the rules of YANG require them to be in separate trees, this led to
> a
>>> twin-trees approach such as can be seen in RFC7277 or RFC7223.
>>>
>>> Amongst other problems, this separation of operational state from
>>> configuration in a
>>>     separate branch in the data model has been found to be
> operationally
>>>     complicated and impacts the readability of module
>>>     definitions.  The relationship between
>>>     the branches is not machine readable and filter expressions
> operating
>>>     on configuration and on related operational state are different.
>>>
>>> With revised datastores, there is a single data object to model both
>>> values  but this now appears in two datastores, one for the
>>> configuration value, one for the operational state value.
>>>
>>> Instead of two YANG data nodes there is one data node in two
> datastores,
>>> a more elegant and simpler solution to the problem.
>>>
>>>
> ta
>>> objects can appear both as configuration and as state, e.g. when
> learned
>>> by other means or at other times.  The original model of datastores
>>> required these data objects to be modelled twice, as configuration
> false
>>> and as configuration true, and since there could be many of them,
> and
>>> the rules of YANG require them to be in separate trees, this led to
> a
>>> twin-trees approach such as can be seen in RFC7277 or RFC7223.
>>>
>>> Amongst other problems, this separation of operational state from
>>> configuration in a
>>>     separate branch in the data model has been found to be
> operationally
>>>     complicated and impacts the readability of module
>>>     definitions.  The relationship between
>>>     the branches is not machine readable and filter expressions
> operating
>>>     on configuration and on related operational state are different.
>>>
>>> With revised datastores, there is a single data object to model both
>>> values  but this now appears in two datastores, one for the
>>> configuration value, one for the operational state value.
>>>
>>> Instead of two YANG data nodes there is one data node in two
> datastores,
>>> a more elegant and simpler solution to the problem.
>>>
>>>
> Tom Petch
>
> ----- Original Message -----
> From: "Lou Berger" 
> To: "t.petch" ; "netmod WG" 
> Cc: ;
> 
> Sent: Wednesday, September 13, 2017 5:56 PM
> Subject: Re: [netmod] WG Last Call:
> draft-ietf-netmod-revised-datastores-04 duplicaiton
>
>
>>> I believe that text such as this would make the I-D much easier to
>>> follow.  As it stands, you have to read between the lines and
> speculate.
>> Tom,
>>
>> Thank you for the comments. Do you have a specific change in mind,
>> or could your propose text, that would address this?
>>
>> Thanks,
>> Lou
>>
>> On 9/13/2017 12:42 PM, t.petch wrote:
>>> I think that in one respect, perhaps the key respect, this I-D fails
> to
>>> state the obvious (or at least what is likely obvious to those who
> have
>>> been at this for a while:-).
>>>
>>> The problem that is hinted at but never explicitly stated is that
> data
>>> objects can appear both as configuration and as state, e.g. when
> learned
>>> by other means or at other times.  The original model of datastores
>>> required these data objects to be modelled twice, as configuration
> false
>>> and as configuration true, and since there could be many of them,
> and
>>> the rules of YANG require them to be in separate trees, this led to
> a
>>> twin-trees approach such as can be seen in RFC7277 or RFC7223.
>>>
>>> Amongst other problems, this separation of operational state from
>>> configuration in a
>>>     separate branch in the data model has been found to be
> operationally
>>>     complicated and impacts the readability of module
>>>     definitions.  The relationship between
>>>     the branches is not machine readable and filter expressions
> operating
>>>     on configuration and on related operational state are different.
>>>
>>> With revised datastores, there is a single data object to model both
>>> values  but this now appears in two datastores, one for the
>>> configuration value, one for the operational state value.
>>>
>>> Instead of two YANG data nodes there is one data node in two
> datastores,
>>> a more elegant and simpler solution to the problem.
>>>
>>>
>>> I believe that text such as this would make the I-D much easier to
>>> follow.  As it stands, you have to read between the lines and
> speculate.
>>> Tom Petch
>>>
>>>
>>> ----- Original Message -----
>>> From: "Lou Berger" 
>>> To: "netmod WG" 
>>> Cc: ;
>>> 
>>> Sent: Friday, September 01, 2017 10:02 PM
>>>
>>>> All,
>>>>
>>>> This starts a two week working group last call on
>>>> draft-ietf-netmod-revised-datastores-04.
>>>>
>>>> The working group last call ends on September 17.
>>>> Please send your comments to the netmod mailing list.
>>>>
>>>> Positive comments, e.g., "I've reviewed this document and
>>>> believe it is ready for publication", are welcome!
>>>> This is useful and important, even from authors.
>>>>
>>>> Thank you,
>>>> Netmod Chairs
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Oct 18 09:48:46 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6141329B5 for ; Wed, 18 Oct 2017 09:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 haKXtBVwBvDT for ; Wed, 18 Oct 2017 09:48:43 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1CC132031 for ; Wed, 18 Oct 2017 09:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4380; q=dns/txt; s=iport; t=1508345322; x=1509554922; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=/HiI3gKdq0XayW/RCGe457dwlH0UPeCAh0F3bSFlkvg=; b=RM/IfPN6NJWyAxHmoPYoJTUv+Hz9Y2KBfT5RTjJLdrni7r2yWYgKP4zj wesqPfJSRFfHkDPhWwfKv8RrgJPLbMXQ+oNXcxT+vFS9gumvgLdnXaeUf pZp8UDS6+bteFH69KffSBpA9jzoL6L0i3na9wOnCb1sdHNvwwWtwsPzxY g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAAD8hOdZ/xbLJq1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRDbieDeoofdJAYJZYzEIIEChgLhElPAoU4GAECAQEBAQEBAWs?= =?us-ascii?q?ohR0BAQEEAQEhDwEFNhcCAgkCEAUBAgICJgICGwwwBgEMBgIBAYocEI0RnWeCJ?= =?us-ascii?q?4snAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBCoIgg1iCFQuCeYRtOSaCTIJhBZh?= =?us-ascii?q?PiHyUbYIUhXaDXIFUhV6OEYdigTkfOIFbNCEIHRVJgmQJhFc/NohLLIIWAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,397,1503360000"; d="scan'208";a="656427311"
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; 18 Oct 2017 16:48:38 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9IGmcmf027788; Wed, 18 Oct 2017 16:48:38 GMT
To: "t.petch" , netmod WG 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net> <20170915170959.q5bfwoqoaqaq4o5b@elstar.local> <009e01d32ff4$345b4a00$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: <83feada1-5e1e-5389-ec61-6724bd1fd183@cisco.com>
Date: Wed, 18 Oct 2017 17:48:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <009e01d32ff4$345b4a00$4001a8c0@gateway.2wire.net>
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-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 16:48:45 -0000

Hi Tom,

Regarding the issue on the definition of inactive configuration, in the 
end we think that we don't need to define it for the following reasons:

1) Juergen's new objectives contains a brief description of inactive 
configuration (without defining it).
2) Inactive has been removed from the normative text, instead the 
normative text more generically refers to "configuration 
transformations" and just uses inactive as an example of such a 
transformation.
3) Configuration transformation is defined as:

    o  configuration transformation: The addition, modification or
       removal of configuration between the  and 
       datastores.  Examples of configuration transformations include the
       removal of inactive configuration and the configuration produced
       through the expansion of templates.

OK?

Validating that this is sufficient to address your concern maybe easier 
when we post an updated revision with all WG LC markups applied.

Thanks,
Rob


On 17/09/2017 21:21, t.petch wrote:
> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> Sent: Friday, September 15, 2017 6:09 PM
>
>
>> Two comments:
>>
>> - Obviously, inactive can be in  and I would not rule out
>>    that inactive configuration can be in any other or future
>>    configuration datastores.
>>
>> - Whether protocols support inactive or not does not belong into a
>>    definition of what inactive configuration is. The same for backwards
>>    compatibility considerations etc.
>>
>> So if we define inactive configuration, the definition should be
>> something like this:
>>
>> * inactive configuration: Configuration held in a configuration
>>    datastore that is marked to be inactive. Inactive configuration is
>>    ignored during validation and never applied and actively used by
>>    a device.
>>
>> Yes, we should use 'inactive configuration' everywhere to be
> consistent.
>
> Juergen
>
> Yes, your definition is better than mine; let's add it.
>
> Tom Petch
>
>> /js
>>
>> On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:
>>> Inactive appears a dozen times but is not defined, except in the
> course
>>> of those appearances it effectively is, but is sometimes 'inactive',
>>> sometimes 'inactive configuration', sometimes 'inactive data'.
>>>
>>> I would find it clearer if the term was used consistently and if
> there
>>> was an explicit definition amongst the other definitions in section
> 2
>>> such as
>>>
>>> inactve configuration: Configuration that is present in 
> which
>>> is not in use by the device and which plays no part in validation.
> It
>>> cannot appear in any other datastore.  The protocols that are
> currently
>>> standardised do not support inactive configuration but a number of
>>> proprietary protocols do. Inactive configuration is only exposed to
>>> clients that indicate support for inactive configuration; clients
> not
>>> indicating support for  inactive configuration receive the contents
> of
>>>  with the inactive configuration removed.
>>>
>>> This would put a stake in the ground for as and when the concept is
>>> standardised and may reduce the proliferation of the term with
> multiple
>>> meanings.
>>>
>>> Tom Petch
>>>
>>>
>>> ----- Original Message -----
>>> From: "Lou Berger" 
>>> Sent: Friday, September 01, 2017 10:02 PM
>>>
>>>> This starts a two week working group last call on
>>>> draft-ietf-netmod-revised-datastores-04.
>>>>
>>>> The working group last call ends on September 17.
>>>> Please send your comments to the netmod mailing list.
>>>>
>>>> Positive comments, e.g., "I've reviewed this document and
>>>> believe it is ready for publication", are welcome!
>>>> This is useful and important, even from authors.
>>>>
>>>> Thank you,
>>>> Netmod Chairs
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> 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 Oct 18 13:26:37 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB37C133055 for ; Wed, 18 Oct 2017 13:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdXaPVHQ8M5s for ; Wed, 18 Oct 2017 13:26:34 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9465D132620 for ; Wed, 18 Oct 2017 13:26:33 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id w21so7211735lfc.6 for ; Wed, 18 Oct 2017 13:26:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KNWFebKMVDxQ3rMBDGSTXC35XBadCGgvWJTMm5T7nbk=; b=z6l+GM1rOMh3UY2v29h/Jo4NUWPN81SOuTHVPl3lNljU9wJVnjboRYMMmqENJhbhRQ f2khF91LIlvMdbFoJZT/DC8OR0erZAFMHvbc7UiCqZLuqOU//ECsg65CET3AsTg13FX/ w6dgtN4Lu3hXv9+bhfJvxXVW6ubbKXS2ZvIGZgTqz3dAss9bkN65V7Zohc4dGhZedCGP SS2o/EooYprR+zei04ZBXlu41ah9ePvMJYcbK0nZpdBEUde/izuYXPXvQS3jCJhkuo0r lICAHI+ar1TxvE+HRcoYgEgUTUXlgaZZynPQrkda718HrP4OfhkngK33dyhG2C21udIg B2Bw==
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=KNWFebKMVDxQ3rMBDGSTXC35XBadCGgvWJTMm5T7nbk=; b=mWR33VBEUw2sOf+pvA/p6cHrGLuV3uJPHLLyWZlx3s3ApcZrFaczIObhhNh55kn1q9 5vqeTtuyWQNeAaWUzC6WJ4Yx+ME5g8SdlOzUcu4ylxMKYblJcR9hSWEGar6a2OvbdZbf vHgMy3U8LxUzobLjSaVxqQbRTZxI+Wa3he8Ge1toSrFJM3ecm6XtrbbnfeHWl5SL+WoM kNTpRflo7HhV4IX3bazupYzDmCYH5K2mOO48u5EJSWLmSU2JGeL+U/UoO+ml9wdvIcXL ky4bYSs93/O5E4OWpopS7TDONaRmCmNFxNXoQVp17ry+PK5hjwM3EG/d72vAK4FFdICm nnYA==
X-Gm-Message-State: AMCzsaXrkKszkrm142Otr0cqBakWah1oprb7BddYqcjT2OeVjduPG+so y6NL3AEy13YNr97+uvE00TCFVdtU76Btp0tFz6l7Sg==
X-Google-Smtp-Source: ABhQp+TO57HfmMtRIgqLLaSBj3jpzBeftQpqOBGYB3cBzBSZBbpjmgaw9uAtkIHZnjwqMpWGBRQzWxFe1Ve+s17smR8=
X-Received: by 10.25.204.81 with SMTP id c78mr6462709lfg.49.1508358391804; Wed, 18 Oct 2017 13:26:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 18 Oct 2017 13:26:30 -0700 (PDT)
In-Reply-To: <20171018143651.kdsf77r65ptlu4mq@elstar.local>
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>
From: Andy Bierman 
Date: Wed, 18 Oct 2017 13:26:30 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1a17c4234cc8055bd80ed5"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 20:26:36 -0000

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

On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
> > > >
> > > >   augment "/if:interfaces-state/if:interface" {
> > > >     action reset {
> > > >       description "Reset this interface";
> > > >     }
> >
> > Can you spot the NMDA problem above?
> > Actually, it exists for in-line definitions, not just augment.
> >
> > Once you collapse the interfaces-state tree into /interfaces, there
> > is no way to specify whether an action is intended for 
> > or a configuration datastore, or all datastores.
>
> I think operations (both RPCs and actions) by default always execute
> in the context of the operational state datastore. This is consistent
> with the way we define the xpath context. An operation that operates
> on other datastores needs to carry this information in its semantics
> and typically requires special arguments to select the datastores
> affected. This is how  and  work. Hence, a
> reset action defined for an interface by default applies to the
> operational state datastore. And this default makes likely sense for
> most actions and RPCs.
>
> If an action or RPC is expected to operate on a different datastore,
> the description must explain this and there may be a need to pass a
> datastore identifier to the operation. [Yes, in retrospect, one might
> have designed the protocol differently so that there would always be a
> datastore parameter at the protocol level but its too late for that.]
>
>

IMO this needs to be simple and deterministic.
All YANG actions in an NMDA server are invoked against .


/js
>
>
Andy



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

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




On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierm=
an wrote:

> > >

> > >=C2=A0 =C2=A0augment "/if:interfaces-state/if:inter=
face" {

> > >=C2=A0 =C2=A0 =C2=A0action reset {

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0description "Reset this inter=
face";

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

>

> Can you spot the NMDA problem above?

> Actually, it exists for in-line definitions, not just augment.

>

> Once you collapse the interfaces-state tree into /interfaces, there
> is no way to specify whether an action is intended for <operational=
>

> or a configuration datastore, or all datastores.



I think operations (both RPCs and actions) by default always execute

in the context of the operational state datastore. This is consistent

with the way we define the xpath context. An operation that operates

on other datastores needs to carry this information in its semantics

and typically requires special arguments to select the datastores

affected. This is how <get-config> and <edit-config> work. Henc=
e, a

reset action defined for an interface by default applies to the

operational state datastore. And this default makes likely sense for

most actions and RPCs.



If an action or RPC is expected to operate on a different datastore,

the description must explain this and there may be a need to pass a

datastore identifier to the operation. [Yes, in retrospect, one might

have designed the protocol differently so that there would always be a

datastore parameter at the protocol level but its too late for that.]




IMO this needs to be simple and deter=
ministic.
All YANG actions in an NMDA server are invoked against =
<operational>.



/js



Andy

=C2=A0

--

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

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

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





--94eb2c1a17c4234cc8055bd80ed5--


From nobody Wed Oct 18 14:32:39 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3F13314B for ; Wed, 18 Oct 2017 14:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A32fziEEGrEX for ; Wed, 18 Oct 2017 14:32:35 -0700 (PDT)
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 C6EDC13292A for ; Wed, 18 Oct 2017 14:32:35 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 98698F69; Wed, 18 Oct 2017 23:32:34 +0200 (CEST)
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 oJ6m7reN6B_6; Wed, 18 Oct 2017 23:32:34 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Oct 2017 23:32:34 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8493F200FC; Wed, 18 Oct 2017 23:32:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0kF0lYpJThHV; Wed, 18 Oct 2017 23:32:34 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04B9E200F1; Wed, 18 Oct 2017 23:32:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id EAA5641329E3; Wed, 18 Oct 2017 23:32:33 +0200 (CEST)
Date: Wed, 18 Oct 2017 23:32:33 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20171018213233.m2srzgpxeaaf4c65@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" 
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 21:32:38 -0000

On Wed, Oct 18, 2017 at 09:29:37AM -0700, Andy Bierman wrote:
> >
> > If an action or RPC is expected to operate on a different datastore,
> > the description must explain this and there may be a need to pass a
> > datastore identifier to the operation. [Yes, in retrospect, one might
> > have designed the protocol differently so that there would always be a
> > datastore parameter at the protocol level but its too late for that.]
> >
> 
> A top-level RPC can also be used if a datastore parameter is needed,
> or an  wrapper can be defined.
> 
> The draft should be clear that the ability to invoke an action (within
> a config=true parent data node) is removed. This is under-specified
> in YANG so it is not really breaking anything.
>

I do not know what 'within a config=true parent data node' means since
a config=true schema node can exist in different datastores. I assume
you mean 'a config=true data node in a configuration datastore".

Yes, it is not really defined in YANG today what an action under a
config=true schema node means (i.e., what you really act upon) but I
would rather leave it to an update of the YANG specification to
clarify 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 Wed Oct 18 14:36:08 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F4813445B for ; Wed, 18 Oct 2017 14:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h0newQCDwJn for ; Wed, 18 Oct 2017 14:36:05 -0700 (PDT)
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 164AC13445C for ; Wed, 18 Oct 2017 14:36:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D97FFF69; Wed, 18 Oct 2017 23:36:02 +0200 (CEST)
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 jSV3wdO7hRef; Wed, 18 Oct 2017 23:36:03 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Oct 2017 23:36:02 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5DD9200FC; Wed, 18 Oct 2017 23:36:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XM6CnIaHTYCk; Wed, 18 Oct 2017 23:36:02 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5351A200F1; Wed, 18 Oct 2017 23:36:02 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1356A4132A28; Wed, 18 Oct 2017 23:36:02 +0200 (CEST)
Date: Wed, 18 Oct 2017 23:36:01 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20171018213601.hdkt2qtqsno6vr4u@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" 
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 21:36:07 -0000

On Wed, Oct 18, 2017 at 01:26:30PM -0700, Andy Bierman wrote:
> On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
> > > > >
> > > > >   augment "/if:interfaces-state/if:interface" {
> > > > >     action reset {
> > > > >       description "Reset this interface";
> > > > >     }
> > >
> > > Can you spot the NMDA problem above?
> > > Actually, it exists for in-line definitions, not just augment.
> > >
> > > Once you collapse the interfaces-state tree into /interfaces, there
> > > is no way to specify whether an action is intended for 
> > > or a configuration datastore, or all datastores.
> >
> > I think operations (both RPCs and actions) by default always execute
> > in the context of the operational state datastore. This is consistent
> > with the way we define the xpath context. An operation that operates
> > on other datastores needs to carry this information in its semantics
> > and typically requires special arguments to select the datastores
> > affected. This is how  and  work. Hence, a
> > reset action defined for an interface by default applies to the
> > operational state datastore. And this default makes likely sense for
> > most actions and RPCs.
> >
> > If an action or RPC is expected to operate on a different datastore,
> > the description must explain this and there may be a need to pass a
> > datastore identifier to the operation. [Yes, in retrospect, one might
> > have designed the protocol differently so that there would always be a
> > datastore parameter at the protocol level but its too late for that.]
> >
> >
> 
> IMO this needs to be simple and deterministic.
> All YANG actions in an NMDA server are invoked against .
>

Well, yes, like all RPC operations - except that we have RPC
operations that do act on other datastores. ;-) But the generic
mechanism including any xpath contexts is against operational.  If the
semantics of the operation that say 'interpret parameter 5 as a
datastore name and act on that datastore', well then this is what the
designer wanted. This is how edit-config and friends work today.

/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 Oct 18 15:16:10 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55B2133090 for ; Wed, 18 Oct 2017 15:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4D1aLyfVVrTE for ; Wed, 18 Oct 2017 15:16:07 -0700 (PDT)
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 9FEE613292A for ; Wed, 18 Oct 2017 15:16:06 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id d10so7461631lfg.11 for ; Wed, 18 Oct 2017 15:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qXXBw1SNxvKZ9o7DVfD0S4Gy3qB6DUCju62qZ1a7dgg=; b=jRCxsKmuxgw+vA+kPRUzYizHO8QMLCSV06xgfAi6unhtITz6rV0jE79eyWQpVpV3ec sJrea8Le3nlqGWkJWorWMoELPIKJsUEri2KywYydJ2Um8rL82SwBveosIHRebH4DSnB6 HguzwHUFIdVlq9J0ZfuP/smulsseyQjvf11pFR85O8nbvW+NrtiJ2xLLV4/+rRBa7Jri A80Fb3zBYc3PmwUonK/4MbETCKA/X3+gozN3j1CCqvh6QRGaeKqI0he9e30t4k33ZqwO 0Y0pqzB3jrnVzZIWFKE5exdq1AaxY1+C4cfdhKaX0uZjKblIypJsKTO34T1Cahrwl+t6 GgNg==
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=qXXBw1SNxvKZ9o7DVfD0S4Gy3qB6DUCju62qZ1a7dgg=; b=WZmD3RiEF9EyHDhzgo+0nvuy5zjj/Y4osQDmVN8VGmXNUX1PzlVtMZikDr9kvNdsOp l2AZoa+Bjmim3ZdIs4ZA99lvryA/wTBqVT3LXfRCNyTQiHVbTWRGsdExKuNwVMJCTNEJ /Sx5paqOHmUbtKx63tj8mV6X5gGIW0pAIKwLp1og6iI9mnoRnB/ceK8+cuwbiWH2IOWh jjGzh2uYI594+bovSlflgBCD6reKdWP643cH2yP9i0Uap4cJpdnZJk4R2qGggkZOHeSG JQ+fwhL/HoHhQbS9bHMSjVPFkxlprhI8KuxwyWMzV9LQVphfCZQO/LY/ADHhioMR6Ist HpiQ==
X-Gm-Message-State: AMCzsaXPi5SKIZW17kPm1PKkckPR+kHpY2t5HYZpFHrTBOAbY4loGPA0 gRfpidJB73HwscZGWJzymvHcWWaxiZgSebvmH8iGfg==
X-Google-Smtp-Source: ABhQp+S+1BN0CK55qx1PD4ac7vx9GrQMDbwN9kSpucDY5X8TnC8k7XGWIR6hzOpN66EKU76UfBFj4vpMMhJkJFCPeqU=
X-Received: by 10.25.22.194 with SMTP id 63mr8233lfw.205.1508364964708; Wed, 18 Oct 2017 15:16:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 18 Oct 2017 15:16:03 -0700 (PDT)
In-Reply-To: <20171018213601.hdkt2qtqsno6vr4u@elstar.local>
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>
From: Andy Bierman 
Date: Wed, 18 Oct 2017 15:16:03 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f2092e9d68d055bd9959e"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Oct 2017 22:16:09 -0000

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

On Wed, Oct 18, 2017 at 2:36 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Oct 18, 2017 at 01:26:30PM -0700, Andy Bierman wrote:
> > On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
> > > > > >
> > > > > >   augment "/if:interfaces-state/if:interface" {
> > > > > >     action reset {
> > > > > >       description "Reset this interface";
> > > > > >     }
> > > >
> > > > Can you spot the NMDA problem above?
> > > > Actually, it exists for in-line definitions, not just augment.
> > > >
> > > > Once you collapse the interfaces-state tree into /interfaces, there
> > > > is no way to specify whether an action is intended for 
> > > > or a configuration datastore, or all datastores.
> > >
> > > I think operations (both RPCs and actions) by default always execute
> > > in the context of the operational state datastore. This is consistent
> > > with the way we define the xpath context. An operation that operates
> > > on other datastores needs to carry this information in its semantics
> > > and typically requires special arguments to select the datastores
> > > affected. This is how  and  work. Hence, a
> > > reset action defined for an interface by default applies to the
> > > operational state datastore. And this default makes likely sense for
> > > most actions and RPCs.
> > >
> > > If an action or RPC is expected to operate on a different datastore,
> > > the description must explain this and there may be a need to pass a
> > > datastore identifier to the operation. [Yes, in retrospect, one might
> > > have designed the protocol differently so that there would always be a
> > > datastore parameter at the protocol level but its too late for that.]
> > >
> > >
> >
> > IMO this needs to be simple and deterministic.
> > All YANG actions in an NMDA server are invoked against .
> >
>
> Well, yes, like all RPC operations - except that we have RPC
> operations that do act on other datastores. ;-) But the generic
> mechanism including any xpath contexts is against operational.  If the
> semantics of the operation that say 'interpret parameter 5 as a
> datastore name and act on that datastore', well then this is what the
> designer wanted. This is how edit-config and friends work today.
>
>

Except this approach is ad-hoc and sub-optimal.
That's why NMDA  is better (because it is extensible yet not
ad-hoc).
IMO an  wrapper would be a good addition for a YANG update

  
     rd:running
     
         
           
               ...
          
        
   
  

It is better to keep the YANG model decoupled from datastores,
and use a protocol parameter to make it explicit.


/js
>


Andy


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

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




On Wed, Oct 18, 2017 at 2:36 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Oct 18, 2017 at 01:26:30PM -0700, Andy Bierm=
an wrote:

> On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <

> j.schoenwaelde=
r@jacobs-university.de> wrote:

>

> > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:

> > > > >

> > > > >=C2=A0 =C2=A0augment "/if:interfaces-state/if:=
interface" {

> > > > >=C2=A0 =C2=A0 =C2=A0action reset {

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0description "Reset =
this interface";

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

> > >

> > > Can you spot the NMDA problem above?

> > > Actually, it exists for in-line definitions, not just augmen=
t.

> > >

> > > Once you collapse the interfaces-state tree into /interfaces=
, there

> > > is no way to specify whether an action is intended for <o=
perational>

> > > or a configuration datastore, or all datastores.

> >

> > I think operations (both RPCs and actions) by default always exec=
ute

> > in the context of the operational state datastore. This is consis=
tent

> > with the way we define the xpath context. An operation that opera=
tes

> > on other datastores needs to carry this information in its semant=
ics

> > and typically requires special arguments to select the datastores=


> > affected. This is how <get-config> and <edit-config> =
work. Hence, a

> > reset action defined for an interface by default applies to the
> > operational state datastore. And this default makes likely sense =
for

> > most actions and RPCs.

> >

> > If an action or RPC is expected to operate on a different datasto=
re,

> > the description must explain this and there may be a need to pass=
 a

> > datastore identifier to the operation. [Yes, in retrospect, one m=
ight

> > have designed the protocol differently so that there would always=
 be a

> > datastore parameter at the protocol level but its too late for th=
at.]

> >

> >

>

> IMO this needs to be simple and deterministic.

> All YANG actions in an NMDA server are invoked against <operational=
>.

>



Well, yes, like all RPC operations - except that we have RPC

operations that do act on other datastores. ;-) But the generic

mechanism including any xpath contexts is against operational.=C2=A0 If the=


semantics of the operation that say 'interpret parameter 5 as a

datastore name and act on that datastore', well then this is what the
designer wanted. This is how edit-config and friends work today.




Except this approach is ad-hoc and su=
b-optimal.
That's why NMDA <get-data> is better (becaus=
e it is extensible yet not ad-hoc).
IMO an <action2> wrappe=
r would be a good addition for a YANG update

=C2=
=A0 <action2>
=C2=A0 =C2=A0 =C2=A0<datastore>rd:runni=
ng</datastore>
=C2=A0 =C2=A0 =C2=A0<top>
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<foo>
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0<test-action>
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 </test-action>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </foo=
>
=C2=A0 =C2=A0</top>
=C2=A0 </action2><=
/div>

It is better to keep the YANG model decoupled from=
 datastores,
and use a protocol parameter to make it explicit.



/js


Andy
=C2=A0
=



--

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

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

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





--001a113f2092e9d68d055bd9959e--


From nobody Fri Oct 20 02:02:12 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC20D1320BD; Fri, 20 Oct 2017 02:02:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150849012465.26854.7027729638769888685@ietfa.amsl.com>
Date: Fri, 20 Oct 2017 02:02:04 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-05.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, 20 Oct 2017 09:02:05 -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 Management Datastore Architecture
        Authors         : Martin Bjorklund
                          Juergen Schoenwaelder
                          Phil Shafer
                          Kent Watsen
                          Robert Wilton
	Filename        : draft-ietf-netmod-revised-datastores-05.txt
	Pages           : 38
	Date            : 2017-10-20

Abstract:
   Datastores are a fundamental concept binding the data models written
   in the YANG data modeling language to network management protocols
   such as NETCONF and RESTCONF.  This document defines an architectural
   framework for datastores based on the experience gained with the
   initial simpler model, addressing requirements that were not well
   supported in the initial model.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-05
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-05


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Oct 20 02:12:01 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A96D13209C; Fri, 20 Oct 2017 02:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 GBFkcC9T_HCb; Fri, 20 Oct 2017 02:11:58 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1797127517; Fri, 20 Oct 2017 02:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1829; q=dns/txt; s=iport; t=1508490717; x=1509700317; h=from:subject:to:cc:message-id:date:mime-version: content-transfer-encoding; bh=5agvls+mNC2dqDkMHHPPECiZRfKmQ6FE0Xz6kwuwbc0=; b=ezHX5vepz/DWv3Sna/AV+hLtAShUSZKEWTCbwnyZql6fyx2W+iY5N71A TGpXTHmXWDgLz3/lV7j4RUMOlljPUgpLmO78txmU/oHT2rteUnVjY324b mm1mfu9n5KEwzAdWm/rOevCcDofZKFX2O1r26lIlLqRyNuwI82DipkM+J M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAwDcvOlZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhENuhCGLE5AflluCEQojhQ4KhQgXAQIBAQEBAQEBayiFRw8BBToHNQI?= =?us-ascii?q?mAl8BDAgBAYocEKpegieEFQGHCgEBAQEBAQEDAQEBAQEBARwFgQ+CH4NXgWkpC?= =?us-ascii?q?4sPgmEFoVyBboV1g2OJK4IVhXiDXIcziiSDcIdigTkhAjRCgRk0IQgdFYMuhCM?= =?us-ascii?q?BOz+LDgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,405,1503360000"; d="scan'208";a="656463957"
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; 20 Oct 2017 09:11:55 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9K9Bs2x015079; Fri, 20 Oct 2017 09:11:55 GMT
From: Robert Wilton 
To: Andy Bierman , Lou Berger , "t.petch" , Balazs Lengyel , "Sterne, Jason (Jason)" , "netmod@ietf.org" , "netmod-chairs@ietf.org" 
Cc: draft-ietf-netmod-revised-datastores.authors@ietf.org
Message-ID: 
Date: Fri, 20 Oct 2017 10:11:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] Updated version of NMDA Datastores draft with WG LC comments addressed.
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 09:12:00 -0000

Hi,

I've just posted an updated version of the NMDA datastores draft 
(draft-ietf-netmod-revised-datastores-05.txt).  The authors believe that 
this should address all of the issues raised during the WG LC.  The 
issues themselves have been tracked at 
https://github.com/netmod-wg/datastore-dt/issues

Note, there has been a recent (post WG LC) issue raised by Andy 
concerning the handling of Action statements.  A further update to the 
draft may be required depending on the conclusion of that discussion.

Please may I thank you for reviewing the draft and providing comments.  
Please may I also ask that if you raised an issue that you check the 
latest draft/diff to ensure that all of your comments have been 
addressed satisfactorily.

In addition, I would like to summarize what I perceive are the main 
changes made to the draft since WG LC version (-04) so that those 
particular areas can be reviewed as appropriate:

1. There is a new "objectives" section added after the short 
introduction to address Tom's request of a better overview.

2. We have introduced the notion of a "configuration transformation" to 
describe the possible changes between running and intended, hence 
allowing inactive config and templating to be used only as examples and 
not in any normative text.

3. The conventional datastores sections have been moved to a more 
intuitive order, which is a minor change, but causes a slightly larger 
diff when diffing the -04 and -05 versions.

4. The description of  and  datastores have both been 
updated, hopefully better explaining the relationship between these 
datastores and .

Finally, I'll leave it to the WG Chairs to specify what the appropriate 
next steps are in the WG LC process.

Many thanks,
Rob


From nobody Fri Oct 20 02:59:03 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA88132F65 for ; Fri, 20 Oct 2017 02:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jCERKd1Qllqg for ; Fri, 20 Oct 2017 02:59:00 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 DC64D132D54 for ; Fri, 20 Oct 2017 02:59:00 -0700 (PDT)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v9K9uPDd004040 for ; Fri, 20 Oct 2017 05:58:59 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 2dq5xyyssj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 20 Oct 2017 05:58:58 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v9K9wvfk013450 for ; Fri, 20 Oct 2017 05:58:57 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v9K9wnCa013391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 20 Oct 2017 05:58:52 -0400
Received: from gbcdccas01.intl.att.com (gbcdccas01.intl.att.com [135.76.180.9]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Fri, 20 Oct 2017 09:58:30 GMT
Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas01.intl.att.com ([135.76.180.9]) with mapi id 14.03.0361.001; Fri, 20 Oct 2017 10:58:29 +0100
From: "Ivory, William" 
To: "'netmod@ietf.org'" 
Thread-Topic: Clarification wanted regarding applicability of YANG 1.1 issues list to YANG 1.0 implementations
Thread-Index: AdNJidZIVklg+cddQzm1fkS6JNKTVA==
Date: Fri, 20 Oct 2017 09:57:27 +0000
Deferred-Delivery: Fri, 20 Oct 2017 09:58:27 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.160.174.78]
Content-Type: multipart/alternative; boundary="_000_E3378E0605547F4E854DEE0CB1116AB025DD28gbcdcmbx03intlatt_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-20_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710200145
Archived-At: 
Subject: [netmod] Clarification wanted regarding applicability of YANG 1.1 issues list to YANG 1.0 implementations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 09:59:02 -0000

--_000_E3378E0605547F4E854DEE0CB1116AB025DD28gbcdcmbx03intlatt_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I've asked about evaluating must statements on unconfigured non-presence co=
ntainers here before, but realise I never got a definitive answer on whethe=
r the clarification in the YANG 1.1 issues list actually applies to YANG 1.=
0, or only YANG 1.1:

YANG 1.0 XPATH context: https://tools.ietf.org/html/rfc6020#section-6.4.1

  *   No mention of non-presence containers

YANG 1.0 errata: https://www.rfc-editor.org/errata_search.php?rfc=3D6020

  *   No mention of non-presence containers

YANG 1.1 Issues list: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issu=
es.html#sec-42

  *   Clarification of handling of non-presence containers for XPATH contex=
t / validation

YANG 1.1 XPATH context: https://tools.ietf.org/html/rfc7950#section-6.4.1

  *   'If a node that exists in the accessible tree has a non-presence cont=
ainer as a child, then the non-presence container also exists in the access=
ible tree.'

As you can see from the links above, the errata for YANG 1.0 does NOT inclu=
de the clarification, whereas the text of YANG 1.1 (RFC 7950) does.

Thanks,

William

--_000_E3378E0605547F4E854DEE0CB1116AB025DD28gbcdcmbx03intlatt_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I’ve asked about evaluati=
ng must statements on unconfigured non-presence containers here before, but=
 realise I never got a definitive answer on whether the clarification in th=
e YANG 1.1 issues list actually applies to
 YANG 1.0, or only YANG 1.1:


 


YANG 1.0 XPATH context: 
https://tools.ietf.org/html/rfc6020#section-6.4.1


    

  • <=
span lang=3D"EN-US">No mention of non-presence containers=



 


YANG 1.0 errata: 
https://www.rfc-editor.org/errata_search.php?rfc=3D6020


    

  • <=
span lang=3D"EN-US">No mention of non-presence containers=



 


YANG 1.1 Issues list: 
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-42


    

  • <=
span lang=3D"EN-US">Clarification of handling of non-presence containers fo=
r XPATH context / validation


 


YANG 1.1 XPATH context: 
https://tools.ietf.org/html/rfc7950#section-6.4.1


    

  • =
‘If a node that exists in the accessible tree has a non-presence cont=
ainer as a child, then the non-presence container also
 exists in the accessible tree.’


 


As you can see from the links a=
bove, the errata for YANG 1.0 does NOT include the clarification, whereas t=
he text of YANG 1.1 (RFC 7950) does.


 


Thanks,


 


William






--_000_E3378E0605547F4E854DEE0CB1116AB025DD28gbcdcmbx03intlatt_--


From nobody Fri Oct 20 03:13:38 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1511B133023 for ; Fri, 20 Oct 2017 03:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.101
X-Spam-Level: 
X-Spam-Status: No, score=-13.101 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z499evipuKzN for ; Fri, 20 Oct 2017 03:13:35 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2254E1321DF for ; Fri, 20 Oct 2017 03:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=526; q=dns/txt; s=iport; t=1508494415; x=1509704015; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=qmS4eg8GlOv/eiGV0/LbeLPHxIUgmrYhKCJ5dNT/pkM=; b=I8GDbIGuNKgu1OCYsyErLMSE6uVBSwkmx1ya35i3wKsJXFoPRxHaNpql f6Vxd/BndzKryDgxXLPVP34Gwz11dJS9yoCf0rREU8/1xjcmha+8ukyyM /Vgw0jgALpj/Ok3R9x5MiXcYdwEHbvMUVip64guWM/ejGYYk3GXDe6dzT Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAAD6yulZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhTGEIYofdKZ6ghEKijoYAQIBAQEBAQEBax0LhUcPAQV2AiYCXw0IAQG?= =?us-ascii?q?KHKlvgieLIAELJoEPgh+DV4ISixqCYQWhXJRxgXyJbYczjhSHYoE5HzhCgRk0I?= =?us-ascii?q?QgdFYMuhF8/iw4BAQE?=
X-IronPort-AV: E=Sophos;i="5.43,405,1503360000"; d="scan'208";a="656465212"
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; 20 Oct 2017 10:13:33 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9KADX2S002763 for ; Fri, 20 Oct 2017 10:13:33 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: 
Date: Fri, 20 Oct 2017 11:13:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 10:13:37 -0000

Hi,

XPATH 1.0 defines the following three node-type tests:

1) comment()
2) processing-instruction()
3) text()

My assumption is that a YANG tree doesn't contain any nodes of type 
'comment' or 'processing-instruction' and hence these filters would 
never match any nodes.

However, it wasn't clear to me from reading 7950 or rfc6087bis-14 
whether text() matches anything.  In particular, does a YANG leaf node 
(except of type empty) always parent a text node that holds its value?

Thanks,
Rob




From nobody Fri Oct 20 05:51:08 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E2E133011; Fri, 20 Oct 2017 05:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqLJpVQYyqwW; Fri, 20 Oct 2017 05:51:04 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D0B132944; Fri, 20 Oct 2017 05:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1814; q=dns/txt; s=iport; t=1508503864; x=1509713464; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=obpCEASMK0Le+n9GI5aACJ487SMxCdqWFdbLrPp9r8E=; b=HYxl98W59RYYlOHDUSHX7KTOlgwlgl6m3eCFDEiDqK0UqOUOt8IongH/ 6YHtDoL1lFyseAJhp1Pg9YXFte7hLuVqMAqA/UZUe2+fHgxKrB1rcUFPa jdJ/JdiY7BpnxqB0+f/IVvTN5vDVryk+ScJHB2/EGXpmB9fje70hcfXg0 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAQDe7+lZ/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHhj+XEoF6hCcBApILEIIBChgLhElPAoQ5QBcBAgEBAQE?= =?us-ascii?q?BAQFrKIUdAQEBBAEBbAsQAgEIEQQBAQolDxgLHQgCBAENBYogEKwSiyABAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYMuggeBUIUThG0YhXUFkhmPQwKUb5MclUkCERk?= =?us-ascii?q?BgTgBIAE2gVt6FUmCZIRfdogWLIEFgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,405,1503360000"; d="scan'208";a="304019680"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2017 12:51:03 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v9KCp3bA001011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Oct 2017 12:51:03 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Oct 2017 07:51:02 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Fri, 20 Oct 2017 07:51:02 -0500
From: "Reshad Rahman (rrahman)" 
To: "Eric Voit (evoit)" , "draft-ietf-netmod-rfc6087bis@ietf.org" 
CC: "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QA8+mcxSk5vUmECY2lUkQ4OqLoEwSAgADU1oCAABYiAIAANyAAgAO1vdA=
Date: Fri, 20 Oct 2017 12:51:02 +0000
Message-ID: <1508503864559.35322@cisco.com>
References:  <001701d3470b$8f473fe0$add5bfa0$@clemm.org>  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB6C8C@sjceml521-mbx.china.huawei.com>, <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com>
In-Reply-To: <4862029103bb46d7b56013331d9e2d3c@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.245.114]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 12:51:06 -0000

Regarding validation, section 3.10 refers to pyang tool. Since the set of t=
ools might change in the future, shouldn't the reference be to the yangvali=
dator url or something along those lines (instead of an exhaustive list whi=
ch may change)?=0A=
=0A=
I think there is a nit in section 2.4, the '.' after [I-D.ietf-netmod-revis=
ed-datastores] should be removed or replaced by a comma.=0A=
=0A=
Regards,=0A=
Reshad.=0A=
________________________________________=0A=
From: netmod  on behalf of Eric Voit (evoit)=0A=
Sent: Tuesday, October 17, 2017 7:06 PM=0A=
To: draft-ietf-netmod-rfc6087bis@ietf.org=0A=
Cc: netmod-chairs@ietf.org; netmod@ietf.org=0A=
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14=0A=
=0A=
I was also encouraged to provide comments.  A couple (new?) minor ones...=
=0A=
=0A=
Section 3.4:=0A=
- If a tree diagram is included for an augmented model, it SHOULD contain t=
he integrated of the augmented model.  I.e., use the pyang -f command to ge=
nerate the tree so that you can explicitly see the schema elements imported=
=0A=
=0A=
Side comment: if a YANG module contains extension structures (like YANG-Dat=
a) these should also be shown in the tree, but I understand why you might n=
ot want to make that a requirement of this document.=0A=
=0A=
Section 3.10: There should be a normative set of YANG validation tools whic=
h are run on upload of an Internet draft.   Errors and warnings found later=
 (and perhaps through tools a user doesn't have) should not result in a mod=
ule being given an error designation.=0A=
=0A=
Thanks,=0A=
Eric=0A=
=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Fri Oct 20 06:18:37 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936861332E4 for ; Fri, 20 Oct 2017 06:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbydd8V_mKK1 for ; Fri, 20 Oct 2017 06:18:35 -0700 (PDT)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727C41332D5 for ; Fri, 20 Oct 2017 06:18:35 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 3BC1B402F5 for ; Fri, 20 Oct 2017 07:18:34 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id PpJW1w00T2SSUrH01pJZpl; Fri, 20 Oct 2017 07:18:34 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=NEAV23lmAAAA:8 a=9WoIrv4_HOcAcAN11loA:9 a=evzEvkg60KY7PLwM:21 a=-mkOH4IP9o81OTFC:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From: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=8XJBKoClANsrBdFyBVZhq5go+sDAx2cDpNhmBgNiRqk=; b=R6cOP2hQrEvIt/Fthyvo3sK3k8 TJC1DM8AEfcXACqZMzNoAniVAF80KIqCiP1cARq0Rq5sGEa1nh+D+yhtdeW/djRBUBddKGbZe7MYw crzHuYifrcNYXrYBcFt7Y9eHi;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:60994 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e5XC2-003fff-7a; Fri, 20 Oct 2017 07:18:30 -0600
To: Robert Wilton , Andy Bierman , "t.petch" , Balazs Lengyel , "Sterne, Jason (Jason)" , "netmod@ietf.org" , "netmod-chairs@ietf.org" 
Cc: draft-ietf-netmod-revised-datastores.authors@ietf.org
References: 
From: Lou Berger 
Message-ID: <9026a2f7-27f8-d36b-60fd-c99bfd57115e@labn.net>
Date: Fri, 20 Oct 2017 09:18:28 -0400
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
Content-Language: en-US
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: 1e5XC2-003fff-7a
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:60994
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Updated version of NMDA Datastores draft with WG LC comments addressed.
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 13:18:36 -0000

Rob/Authors/All,

Thank you for putting in the effort to update the draft based on LC
comments received.  Please let the WG know when you think all open
issues are addressed and we will do a 1 or 2 week 2nd LC depending on
timing relative to IETF100

WG,

Please don't wait for the 2nd LC -- review this document and confirm
that your previous comments have been addressed, and let the WG know if
you have comments on the other changes.

Thank you,
Lou

Co-Chair/Shepherd


On 10/20/2017 05:11 AM, Robert Wilton wrote:
> Hi,
> 
> I've just posted an updated version of the NMDA datastores draft
> (draft-ietf-netmod-revised-datastores-05.txt).  The authors believe that
> this should address all of the issues raised during the WG LC.  The
> issues themselves have been tracked at
> https://github.com/netmod-wg/datastore-dt/issues
> 
> Note, there has been a recent (post WG LC) issue raised by Andy
> concerning the handling of Action statements.  A further update to the
> draft may be required depending on the conclusion of that discussion.
> 
> Please may I thank you for reviewing the draft and providing comments. 
> Please may I also ask that if you raised an issue that you check the
> latest draft/diff to ensure that all of your comments have been
> addressed satisfactorily.
> 
> In addition, I would like to summarize what I perceive are the main
> changes made to the draft since WG LC version (-04) so that those
> particular areas can be reviewed as appropriate:
> 
> 1. There is a new "objectives" section added after the short
> introduction to address Tom's request of a better overview.
> 
> 2. We have introduced the notion of a "configuration transformation" to
> describe the possible changes between running and intended, hence
> allowing inactive config and templating to be used only as examples and
> not in any normative text.
> 
> 3. The conventional datastores sections have been moved to a more
> intuitive order, which is a minor change, but causes a slightly larger
> diff when diffing the -04 and -05 versions.
> 
> 4. The description of  and  datastores have both been
> updated, hopefully better explaining the relationship between these
> datastores and .
> 
> Finally, I'll leave it to the WG Chairs to specify what the appropriate
> next steps are in the WG LC process.
> 
> Many thanks,
> Rob
> 
> 


From nobody Fri Oct 20 08:26:41 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAB613219C for ; Fri, 20 Oct 2017 08:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Gv86pVCJHLS for ; Fri, 20 Oct 2017 08:26:37 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 87C00133343 for ; Fri, 20 Oct 2017 08:26:36 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 1E5C11820F78; Fri, 20 Oct 2017 17:26:23 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 8ED2E1820E6E; Fri, 20 Oct 2017 17:26:20 +0200 (CEST)
From: Ladislav Lhotka 
To: Robert Wilton , "netmod\@ietf.org" 
In-Reply-To: 
References: 
Mail-Followup-To: Robert Wilton , "netmod\@ietf.org" 
Date: Fri, 20 Oct 2017 17:27:27 +0200
Message-ID: <87h8utg7q8.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 15:26:40 -0000

Hi Rob,

Robert Wilton  writes:

> Hi,
>
> XPATH 1.0 defines the following three node-type tests:
>
> 1) comment()
> 2) processing-instruction()
> 3) text()

For completeness, node() is the fourth one.

>
> My assumption is that a YANG tree doesn't contain any nodes of type=20
> 'comment' or 'processing-instruction' and hence these filters would=20
> never match any nodes.

Yes. FWIW, Yangson library raises NotSupported exception upon
encountering these.

>
> However, it wasn't clear to me from reading 7950 or rfc6087bis-14=20
> whether text() matches anything.=C2=A0 In particular, does a YANG leaf no=
de=20
> (except of type empty) always parent a text node that holds its value?

I believe this is how it should be interpreted. According to XPath 1.0
spec, comparisons like

    xyz =3D 'foo'

use string-value of xyz node, which is defined as the concatenation of
the string-values of all text node descendants of xyz.

Lada

>
> Thanks,
> Rob
>
>
>
> _______________________________________________
> 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 Oct 20 09:24:48 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C5F1342CE for ; Fri, 20 Oct 2017 09:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 uFVGG_Rwrc1b for ; Fri, 20 Oct 2017 09:24:45 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8661330AE for ; Fri, 20 Oct 2017 09:24:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1574; q=dns/txt; s=iport; t=1508516684; x=1509726284; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=LRj5uskWQ8NmjWUqeL96+mFZqyqBhGxo1EOkqytc6E0=; b=ARsj9heq24bU0WMbSB09FtDbmNddDTmX/E4zMzYDa8H8GjfcyV66H6n3 KCl9Gpm/L896V4W/lzN68HfPwihRP79CNLNN0pJzuJIBT5ffc8oWcgDRa /h/kzBrymri6zk2qaR8B3TtsQnWEaYX8nCa+YlF/xzEa7pU1QjrCjCI8w Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAAAlIupZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEM5NSeDeoofdJAeJpY3ghEKGAuESU8ChHoYAQIBAQEBAQEBax0?= =?us-ascii?q?LhR0BAQEBAgEBASEPAQU2GwsYAgImAgInMAYNBgIBAYoUCBCqWYInix8BAQEBA?= =?us-ascii?q?QEBAwEBAQEBAQEcBYEPgh+DV4FpKQuCdogZgmEFoV+UcYtqhzWOF4djgTkfOIF?= =?us-ascii?q?bNCEIHRVJgmSEYD82imABAQE?=
X-IronPort-AV: E=Sophos;i="5.43,405,1503360000"; d="scan'208";a="656473480"
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; 20 Oct 2017 16:24:41 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9KGOfNo013042 for ; Fri, 20 Oct 2017 16:24:41 GMT
To: "netmod@ietf.org" 
References:  <87h8utg7q8.fsf@nic.cz>
From: Robert Wilton 
Message-ID: <4b74f390-4817-9154-e427-cd879e0ceeb9@cisco.com>
Date: Fri, 20 Oct 2017 17:24:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <87h8utg7q8.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] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 16:24:47 -0000

Hi Lada,

Thanks for the explanation, that makes sense.


On 20/10/2017 16:27, Ladislav Lhotka wrote:
> Hi Rob,
>
> Robert Wilton  writes:
>
>> Hi,
>>
>> XPATH 1.0 defines the following three node-type tests:
>>
>> 1) comment()
>> 2) processing-instruction()
>> 3) text()
> For completeness, node() is the fourth one.
>
>> My assumption is that a YANG tree doesn't contain any nodes of type
>> 'comment' or 'processing-instruction' and hence these filters would
>> never match any nodes.
> Yes. FWIW, Yangson library raises NotSupported exception upon
> encountering these.
>
>> However, it wasn't clear to me from reading 7950 or rfc6087bis-14
>> whether text() matches anything.  In particular, does a YANG leaf node
>> (except of type empty) always parent a text node that holds its value?
> I believe this is how it should be interpreted. According to XPath 1.0
> spec, comparisons like
>
>      xyz = 'foo'
>
> use string-value of xyz node, which is defined as the concatenation of
> the string-values of all text node descendants of xyz.
Yes.  I don't think that I've ever come across for XPath usage in YANG 
where the "concatenation of the string-values of all text node 
descendants " is actually useful (particularly as the children nodes are 
likely to not be consistently ordered).

Thanks,
Rob


>
> Lada
>
>> Thanks,
>> Rob
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Oct 20 09:55:33 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B68E1342E3 for ; Fri, 20 Oct 2017 09:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNjngvNtdwC9 for ; Fri, 20 Oct 2017 09:55:30 -0700 (PDT)
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 9DC9413235C for ; Fri, 20 Oct 2017 09:55:29 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id r129so13872002lff.8 for ; Fri, 20 Oct 2017 09:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1J7j0GfsqnYvMGVuLoqFEmS5bZnPmw+6UXHbblrsgoc=; b=La5VunVXfhG8jCk7OC/5U4TotJweQAMQSobsTagEvxE9rO/+6HYlBqMLgnRmHhDCo3 8MouGtQBGnR+zmbrIjcfswPNgtIwMfOxP/zQ/tA1+pFw5NOB81T7I/xWG6A3qQeEmnE6 MZwPOMFHH2gTOflqvPvs7IH3gE3nFc/Da35cercR/LUPmKYysVyWuUnj+Qm985oreFYM 4HO9Q76jiAvVql4N5OB1m1sSCE5fEdESTzAIFFIrSaXdVZFD+NGqfJns0dWxqY4F6QvZ nxInWC9tXQzvW60gVt3Y71RMdgDB4GidSRawMZ9UbDNG4kq9++1FSURcml/7xCZI5T3x iL4w==
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=1J7j0GfsqnYvMGVuLoqFEmS5bZnPmw+6UXHbblrsgoc=; b=P3rY/ndD9bRw6/OTcGzEjU4V9hQ6ewIknEfXfyQe3GGQJxe4teC3LGxgo84rrlIz8L NTWdgEOoKmhfg+3EkZotOJh7BDRh8IlwD/aUNaHfSwrzd871sBjcQT99xW0NnmrPQiZ/ AQs23IfAjSax9LsEnB4N0RxwENDveN5M2z8EereSY1eHo7SkvqUO1r1YSxqE84G5QOpd nJTqj73MKavUIiP1pQQiZfHthY0MqJTd5A+QUT/3NcSN9gVdFQ/xO0QqvHGlGcT24iUo a5JVmWZwI1muY5BtB3TCEF+wwyppkXyVhqk0QgGA2N/Dyq698WwEie/XDW9KokGReOzi 2ndQ==
X-Gm-Message-State: AMCzsaUVRbaRCURKMbmSlPyvZQVvxmoMdlgPcxUgC7afrqjw7Hg2UEy0 KB7hLqra7tsAG8L+k+nxu5N5Y6+ipOTMqxPH13/4O/Ao
X-Google-Smtp-Source: ABhQp+QoSTaNYVTF3CjTniYoriYb5D6mNE3OlhkP9VkjnpaSisBUCHxjWSUiVjzly4/OVeMj+LajmCcgYdbqCEfdLVw=
X-Received: by 10.46.83.25 with SMTP id h25mr2389912ljb.158.1508518527945; Fri, 20 Oct 2017 09:55:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Fri, 20 Oct 2017 09:55:27 -0700 (PDT)
In-Reply-To: <4b74f390-4817-9154-e427-cd879e0ceeb9@cisco.com>
References:  <87h8utg7q8.fsf@nic.cz> <4b74f390-4817-9154-e427-cd879e0ceeb9@cisco.com>
From: Andy Bierman 
Date: Fri, 20 Oct 2017 09:55:27 -0700
Message-ID: 
To: Robert Wilton 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f40304360142fee11c055bfd560b"
Archived-At: 
Subject: Re: [netmod] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 16:55:32 -0000

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

On Fri, Oct 20, 2017 at 9:24 AM, Robert Wilton  wrote:

> Hi Lada,
>
> Thanks for the explanation, that makes sense.
>
>
> On 20/10/2017 16:27, Ladislav Lhotka wrote:
>
>> Hi Rob,
>>
>> Robert Wilton  writes:
>>
>> Hi,
>>>
>>> XPATH 1.0 defines the following three node-type tests:
>>>
>>> 1) comment()
>>> 2) processing-instruction()
>>> 3) text()
>>>
>> For completeness, node() is the fourth one.
>>
>> My assumption is that a YANG tree doesn't contain any nodes of type
>>> 'comment' or 'processing-instruction' and hence these filters would
>>> never match any nodes.
>>>
>> Yes. FWIW, Yangson library raises NotSupported exception upon
>> encountering these.
>>
>

But a server or client should ignore PIs, not reject the XML.

I think text() and node() are just filter tests.

  /foo/*[text()] would return all the child nodes of /foo that are leaf or
leaf-list

text() returns a boolean (0 or 1).  Do not use it for value testing:

  /foo/*[text() = 'fred']  // wrong!

  /foo/*[. = 'fred']  // correct

[7]    NodeTest    ::=    NameTest

| NodeType  '('
')'
| 'processing-instruction' '(' Literal
 ')'


>> However, it wasn't clear to me from reading 7950 or rfc6087bis-14
>>> whether text() matches anything.  In particular, does a YANG leaf node
>>> (except of type empty) always parent a text node that holds its value?
>>>
>> I believe this is how it should be interpreted. According to XPath 1.0
>> spec, comparisons like
>>
>>      xyz = 'foo'
>>
>> use string-value of xyz node, which is defined as the concatenation of
>> the string-values of all text node descendants of xyz.
>>
> Yes.  I don't think that I've ever come across for XPath usage in YANG
> where the "concatenation of the string-values of all text node descendants
> " is actually useful (particularly as the children nodes are likely to not
> be consistently ordered).
>
>


I think text() and node() are just filter tests.

  /foo/*[text()] would return all the child nodes of /foo that are leaf or
leaf-list

text() returns a boolean (0 or 1).


[7]    NodeTest    ::=    NameTest

| NodeType  '('
')'
| 'processing-instruction' '(' Literal
 ')'




[38]    NodeType    ::=    'comment'
| 'text'
| 'processing-instruction'
| 'node'




The node test text() is true for any text node. For example, child::text() will
select the text node children of the context node. Similarly, the node test
comment() is true for any comment node, and the node test
processing-instruction() is true for any processing instruction. The
processing-instruction() test may have an argument that is Literal
; in this case,
it is true for any processing instruction that has a name equal to the
value of the Literal
.


Thanks,
> Rob
>
>
>
>> Lada
>>
>>

Andy



> Thanks,
>>> Rob
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>

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




On Fri, Oct 20, 2017 at 9:24 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:
Hi L=
ada,



Thanks for the explanation, that makes sense.





On 20/10/2017 16:27, Ladislav Lhotka wrote:



Hi Rob,



Robert Wilton <rw=
ilton@cisco.com> writes:





Hi,



XPATH 1.0 defines the following three node-type tests:



1) comment()

2) processing-instruction(<opt arg>)

3) text()



For completeness, node() is the fourth one.





My assumption is that a YANG tree doesn't contain any nodes of type

'comment' or 'processing-instruction' and hence these filte=
rs would

never match any nodes.



Yes. FWIW, Yangson library raises NotSupported exception upon

encountering these.


But a server or client should ignore PIs, not reject the XML.

I think text() and node() are just filter tests.
=


=C2=A0 /foo/*[text()] would return all the child nodes =
of /foo that are leaf or leaf-list

text() returns =
a boolean (0 or 1).=C2=A0 Do not use it for value testing:

=C2=A0 /foo/*[text() =3D 'fred'] =C2=A0// wrong!

=C2=A0 /foo/*[. =3D 'fred'] =C2=A0// correct

<=
td style=3D"font-family:sans-serif">
[7]=C2=A0=C2=A0=C2=A0NodeTest=C2=A0=
=C2=A0=C2=A0::=3D=C2=A0=C2=A0=C2=A0NameTest
|=C2=A0NodeType=C2=A0'(' ')'
| 'processing=
-instruction' '('=C2=A0Literal=C2=A0')'






However, it wasn't clear to me from reading 7950 or rfc6087bis-14

whether text() matches anything.=C2=A0 In particular, does a YANG leaf node=


(except of type empty) always parent a text node that holds its value?



I believe this is how it should be interpreted. According to XPath 1.0

spec, comparisons like



=C2=A0 =C2=A0 =C2=A0xyz =3D 'foo'



use string-value of xyz node, which is defined as the concatenation of

the string-values of all text node descendants of xyz.



Yes.=C2=A0 I don't think that I've ever come across for XPath usage=
 in YANG where the "concatenation of the string-values of all text nod=
e descendants " is actually useful (particularly as the children nodes=
 are likely to not be consistently ordered).



=C2=A0

I think text() and node() are just filter tests.

=C2=A0 /foo/*[text()] would return all the child no=
des of /foo that are leaf or leaf-list

text() retu=
rns a boolean (0 or 1).


=C2=A0=C2=A0=C2=A0::=3D=C2=A0=C2=A0=C2=
=A0
[7]=
=C2=A0=C2=A0=C2=A0NodeTestNameTest
|=C2=A0NodeType=C2=A0'('=
 ')'
| 'processing-instruction' '('=
=C2=A0Literal=
=C2=A0')'



=

[38]=C2=A0=C2=A0=C2=A0NodeType=C2=A0=C2=A0=C2=
=A0::=3D=C2=A0=C2=A0=C2=A0'co=
mment'
| 'text'
| 'processing-ins=
truction'
| 'node'




The node test=C2=A0text()=C2=A0is true fo=
r any text node. For example,=C2=A0child::text()=C2=A0will sel=
ect the text node children of the context node. Similarly, the node test=C2=
=A0comment()=C2=A0is true for any comment node, and the node t=
est=C2=A0processing-instruction()=C2=A0is true for any process=
ing instruction. The=C2=A0processing-instruction()=C2=A0test m=
ay have an argument that is=C2=A0Literal; in this case, it is true for any processing in=
struction that has a name equal to the value of the=C2=A0Literal.



Thanks,

Rob









Lada




Andy
=


=C2=A0



Thanks,

Rob







_______________________________________________

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




--f40304360142fee11c055bfd560b--


From nobody Fri Oct 20 14:37:09 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50F8134321 for ; Fri, 20 Oct 2017 14:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 jxlTiIY4zXKh for ; Fri, 20 Oct 2017 14:37:06 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0109.outbound.protection.outlook.com [104.47.38.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 0B357134315 for ; Fri, 20 Oct 2017 14:37:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qL7AYsTAAfFUFVKtxRbIzMFEwqLNyap61BpTVsjlhkA=; b=VBeGCoLbfUILjfEdUMoeXyJWBVOSsvzbT/km+ZWZLE9Fo0yUXwk+8H9d1ppOV2ZtvKFRGYD8bGjeIeE0evUUoXAT9iSfMwB1A8rEDrVROUEO7TyvtKuJ6gTfjyjDC+ftsSOreLBxcUzjL1DE7nvajRvjkoMPvM1YGrA5h6by3Ms=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB274.namprd05.prod.outlook.com (10.141.22.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Fri, 20 Oct 2017 21:37:04 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0156.005; Fri, 20 Oct 2017 21:37:04 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
CC: "mjethanandani@gmail.com" , "lyihuang16@gmail.com" , "agarwaso@cisco.com" , "dblair@cisco.com" 
Thread-Topic: WG Last Call: draft-ietf-netmod-acl-model-14
Thread-Index: AQHTSeuS4R9mVwyDOkCxkCX5K2HeVg==
Date: Fri, 20 Oct 2017 21:37:04 +0000
Message-ID: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:U+rkEZ9MhQpiiP8DkFvu+LGXZkeqwT/6lg8M6ZsQLUHD6Zv3xUKMS2iOh/Ov65jvBK2OG7Px5bUGaDbH0rO9Vcx58EYf9dIH5W3ZMbHaXNo0NurY8bHO0shhsIsGrgS17ilgGERRWDctrVtmKVapCaQyW4DX9QeZ74QbiGrtP2eynmGp7BzC/TmqSFVmoEGdT+Xjy8ODXMNiIXGxioVy8I7LBil7HCTzBw/MKM7HgNzg3jibKDJjERtNVkAdib4TDNMI9H8MgGtHhMmPXRfXBMmSO4DCoTFLjGthli8srvxFvYXOAhfKGryF5RqQZoOBh4Dp28JXLPk/a0YMIJKQ/A==; 5:QhassWNqUpCZp6u+EKvsiM/5cxIJF1cPYxf5lKnKSSH/eTztEBi5U7ij9wVSNkATfFyKQFSXzZBS2PorhP73nhwkla8MomppOgEqc6/4Fp6xVLQq4tG6q7ayipZTRbt0HMHtroSRDAiOgHV+5dPc7Q==; 24:YG8xzgWeic/0Z+Oc1FGtB3q/2oJ6s4QOHQy03ddPPfAo6pP9No77PzkP1GEeAVKAUXKqzBBxp34Zl/jl1NfViOHCmNyHVauTk8UYb0M5Csk=; 7:aqc2H0TBT94JGy7BwYcXPszYJGndnU55WMp2ZHjfCAciixpn3aPK52WZWuuFSbz4LvQ9r2qj4ep8yUWK66E3eao6oxJmbV1Gl/CxkbprhRuRyWePFdsvPyudrjgE+uLIQXobv+9xQQG1LJyM3VD9d8awfle+u1QjMeuCvRXe8C6ZrkFCI8cX7DxwUBnG9XozGOcrQePchJZs5e20D/H525+zLSv6tmA7PY1kIZ5B+xE=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: e3ff14ba-84f3-4c36-c5f9-08d51802b4d3
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BLUPR05MB274; 
x-ms-traffictypediagnostic: BLUPR05MB274:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(3231020)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB274; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB274; 
x-forefront-prvs: 0466CA5A45
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(7736002)(81156014)(99286003)(1730700003)(6512007)(8936002)(8676002)(101416001)(68736007)(6116002)(189998001)(81166006)(102836003)(305945005)(53936002)(25786009)(39060400002)(50986999)(2900100001)(54356999)(3846002)(33656002)(36756003)(3660700001)(3280700002)(2906002)(106356001)(478600001)(105586002)(58126008)(82746002)(2351001)(54906003)(316002)(66066001)(230783001)(83716003)(6916009)(14454004)(2501003)(86362001)(77096006)(6486002)(5660300001)(6506006)(83506002)(6436002)(5640700003)(97736004)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB274; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3ACC3F2412C20743A2300A1DE1FB3C91@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: e3ff14ba-84f3-4c36-c5f9-08d51802b4d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 21:37:04.4322 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB274
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 21:37:08 -0000

DQpBbGwsDQoNClRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwg
b24NCmRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNC4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAg
bGFzdCBjYWxsIGVuZHMgb24gTm92ZW1iZXIgMy4NClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMg
dG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3QuDQoNClBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAi
SSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50DQphbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3Ig
cHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENClRoaXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQs
IGV2ZW4gZnJvbSBhdXRob3JzLg0KDQpDb3VsZCB0aGUgYXV0aG9ycywgZXhwbGljaXRseSBDQy1l
ZCBvbiB0aGlzIGVtYWlsLCBwbGVhc2UNCmFsc28gY29uZmlybSBhdCB0aGlzIHRpbWUgdGhhdCB0
aGV5IGFyZSB1bmF3YXJlIG9mIGFueSANCklQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQoNClRo
YW5rIHlvdSwNCk5ldG1vZCBDaGFpcnMNCg0KDQo=


From nobody Fri Oct 20 14:37:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8A1320C9 for ; Fri, 20 Oct 2017 14:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 qINlm8oht43X for ; Fri, 20 Oct 2017 14:37:31 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0098.outbound.protection.outlook.com [104.47.37.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E7C134320 for ; Fri, 20 Oct 2017 14:37:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1a8o/pjZgi/f7jedCzYbdAhairJL4ZPJ9KEnH2lFuO4=; b=YT9a6vYL4EfzDKsLJzsGFnQRJVh7WjwoRNDdqioP3+j/+3xa5jFjRirk9ctpwo/qfu2UW6jcr8ShRllc8ZPUKNT4NIo4EPKiXLOeV1aoNb8MJHV5X3f/azYQ0IZFbxF0j4L0cPZqTjgGKxWURnyOyXIFoK7JohifE48U3Ua4P9o=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB274.namprd05.prod.outlook.com (10.141.22.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Fri, 20 Oct 2017 21:37:30 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0156.005; Fri, 20 Oct 2017 21:37:30 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-schema-mount-07
Thread-Index: AQHTSeuhw0xDu0vOR0WJhy7BMtYgnA==
Date: Fri, 20 Oct 2017 21:37:30 +0000
Message-ID: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:SvrdAHgl5XHxwJZYTnDC6WsUgo39Oai4GS98gaTOsiDA1Tr/KKuGRdoYKXPPyhGAJvnxHbyZgvFTfNol/baLu1j6u/yXqU4Z32W3QdxK90YwHRxUxs/i/I8Pd6IRb4CUojqweRbBwhbWloXKLCagjNDa+n9Pb1Xr4r+1JOAr4hr65KQTCooAxx5REVb8XSTVAA04J6IZJQgQqBX0YsPVIo4DpOtbyIlxjcDsmMZDbG7BHYMIKcxX0abD0709WYkHq486czRsMiMDCSUw8+JeD7TWqGnc2XmfSP91YvZiprf3s4+f9e9/PnGoE8fSZaYLagJaFv5x/CFgf3bL4GPivQ==; 5:R8FRiMItRMu+hpIGMOplstEiOiaQhJLodaHQ+pHTJ/YPJE9UbXRMUVrqnQzwDJ18T/+8ROs6g66TWg8F7uKnI6xfi7hxnIvHQDusjQYyaVc869gta/ND9XyRqDHO1dSgwOnJVgWLC32sFBsNDVTQnw==; 24:aPijh+yFZiVXfRh7oXIClvOd7Op7Y7PjMkK0ClwpMHD5xhgWc+zF3asJKTRvX4lT+Sc+nvxwuGXO+L9W4u8cSfX5bohWJ2oRYqheYGK970M=; 7:k0qY0rp3g/ttoUqgessFVyISIMypPd3lHOH2fgbVEmdXy+uBErpa++OFR78hJyNFQrL4i6Vb0ukUPfy3gLcbH3b2aIfsWC8hMgfNb16fHaSJZLw1RVKFmBOpAMIcV8G/iSaNwHICWims75XqZGUJMC7thlmUbFytItYRXULYEnYfdLkKYtzmn9p2i/lgXd6GM8L6232F9y/Dw2PgPISXLFrwd/ClP1BTn/bp1D8L21k=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ad2be7ca-a44c-4af9-e2ba-08d51802c44b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BLUPR05MB274; 
x-ms-traffictypediagnostic: BLUPR05MB274:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(3231020)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB274; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB274; 
x-forefront-prvs: 0466CA5A45
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(7736002)(81156014)(99286003)(1730700003)(6512007)(8936002)(8676002)(101416001)(68736007)(6116002)(189998001)(81166006)(102836003)(305945005)(53936002)(25786009)(50986999)(2900100001)(54356999)(3846002)(33656002)(36756003)(3660700001)(3280700002)(2906002)(106356001)(478600001)(105586002)(58126008)(82746002)(2351001)(54906003)(316002)(66066001)(230783001)(83716003)(6916009)(14454004)(2501003)(86362001)(77096006)(6486002)(5660300001)(6506006)(83506002)(6436002)(5640700003)(97736004)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB274; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: ad2be7ca-a44c-4af9-e2ba-08d51802c44b
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 21:37:30.4320 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB274
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 21:37:33 -0000

QWxsLA0KDQpUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u
DQpkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQtMDcuDQoNClRoZSB3b3JraW5nIGdyb3Vw
IGxhc3QgY2FsbCBlbmRzIG9uIE5vdmVtYmVyIDMuDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRz
IHRvIHRoZSBuZXRtb2QgbWFpbGluZyBsaXN0Lg0KDQpQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwg
IkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCANCmFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZv
ciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFu
dCwgZXZlbiBmcm9tIGF1dGhvcnMuDQoNCkNvdWxkIHRoZSBhdXRob3JzLCBleHBsaWNpdGx5IEND
LWVkIG9uIHRoaXMgZW1haWwsIA0KcGxlYXNlIGFsc28gY29uZmlybSBvbmUgbW9yZSB0aW1lIHRo
YXQgdGhleSBhcmUgDQp1bmF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0K
DQpUaGFuayB5b3UsDQpOZXRtb2QgQ2hhaXJzDQoNCg0K


From nobody Fri Oct 20 14:59:27 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48258133055 for ; Fri, 20 Oct 2017 14:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP9wBbswo-uM for ; Fri, 20 Oct 2017 14:59:24 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 E9E5A12ECEC for ; Fri, 20 Oct 2017 14:59:23 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id i5so12851729pfe.6 for ; Fri, 20 Oct 2017 14:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wIwdVe2mtA/VevNST5sKdPCPgsF9tGZ8vJs0MnGtfs8=; b=L/Ls10D3517+NKpKGguSe4V5jo2fiIu6IaHLIopyu+zX1LcBTRPAF9cieE9FqDrIiI usUNLT8IE+tWYsT4/SiAd2FMVvabbWDKANrufTvJamhf8Yxcsy2NgCt5C/HhKWjA1+Qt EnvtN5StUpWDyYFdFSdW+dWQf5NKHB0WjQyWH7XezWHAuJhqwMHtqqXk4gMKcUBXVDU8 nLhYGmEHL8QCtv1Cp0XOxuTfNtDioHtY+nosIqTUeLf/SJMAOnspI4RkXkMadScYD8pM u5msh43PkQ6tGKns4TVupTbn86/jcE9I90dOx6giXpQWRF6kopypxSytnVAVcjnHW9ov hzQg==
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=wIwdVe2mtA/VevNST5sKdPCPgsF9tGZ8vJs0MnGtfs8=; b=XpwbboVGOLl5Cl7LZItpuJHLXNbcHuDJxUMmPN/UExrAMz6NUqe7zZ6INOwpmpKLEh wYtHGY0O8qty2VOsgQJvbGDBz3ERyWudP7c+/83ESljd/xn6j5RRiRvOYpP2qJAvgpoh cPsVL7KsjhtymOUpHU9YXvOOUd5jnO6WP5nvYPj9eIOcupsUnD5AYbUAVmcEZbMYccz+ 42FNqem7yw1t5L2if2Fz72/JAIFxAOJ7XgXUzbf4fWZ69BeC2Ir4zqjgABwrySgqXmSy gWVcVpA4lCefwcA8kQ0AbW4z53HJnXPMMAOWbcrfgzQavy12Bcj+63vez5lHPULC9RcV d+bQ==
X-Gm-Message-State: AMCzsaUFTA8EK6dhDZr8fFFz4ZwS35F/UR+evyWNnOBqwCbWbIzPsSWA 4hlDWGr20rbrzfPQrjFAooQ=
X-Google-Smtp-Source: ABhQp+RxV4OZFcHfQkrtLGJqU7tHiVpvwTgZ/DpYTw0KvhJpDe58Y4VharazjLdKUB+kfN8VMWn1KA==
X-Received: by 10.84.241.5 with SMTP id a5mr4987024pll.81.1508536763489; Fri, 20 Oct 2017 14:59:23 -0700 (PDT)
Received: from [10.24.100.130] ([128.107.241.174]) by smtp.gmail.com with ESMTPSA id t85sm3210973pfe.138.2017.10.20.14.59.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Oct 2017 14:59:22 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
Date: Fri, 20 Oct 2017 17:59:33 -0400
Cc: "netmod@ietf.org" , "lyihuang16@gmail.com" , Sonal Agarwal , "dblair@cisco.com" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
To: Kent Watsen 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Oct 2017 21:59:25 -0000

I am not aware of any IPRs related to the draft.

Thanks.

> On Oct 20, 2017, at 5:37 PM, Kent Watsen  wrote:
> 
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-14.
> 
> The working group last call ends on November 3.
> 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.
> 
> Could the authors, explicitly CC-ed on this email, please
> also confirm at this time that they are unaware of any 
> IPR related to this draft.
> 
> Thank you,
> Netmod Chairs
> 
> 

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Fri Oct 20 17:26:05 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB70A134479; Fri, 20 Oct 2017 17:24:15 -0700 (PDT)
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.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150854545589.20809.5547671104138737306.idtracker@ietfa.amsl.com>
Date: Fri, 20 Oct 2017 17:24:15 -0700
Archived-At: 
Subject: [netmod] netmod - Requested sessions have been scheduled for IETF 100
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, 21 Oct 2017 00:24:16 -0000

Dear Lou Berger,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

netmod Session 1 (1:30:00)
    Wednesday, Afternoon Session II 1520-1650
    Room Name: Sophia size: 200
    ---------------------------------------------
    netmod Session 2 (1:30:00)
    Wednesday, Afternoon Session I 1330-1500
    Room Name: Padang size: 300
    ---------------------------------------------
    


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):  1.5 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
  Benoit Claise
  Kent Watsen

Resources Requested:

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


From nobody Sat Oct 21 00:29:01 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2958E1329B5 for ; Sat, 21 Oct 2017 00:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eifpbc3AkLm8 for ; Sat, 21 Oct 2017 00:28:58 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E07D126BF3 for ; Sat, 21 Oct 2017 00:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1766; q=dns/txt; s=iport; t=1508570938; x=1509780538; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=HvBvaCIDQDN3B+Qd2gGuY2/mj5OxVuM6nboix8EOrgA=; b=ZGB6X9zUqSk6npntJs4xPo6Msc+o37GIdD4BeluTMTIXyqId9g5ZdtPU mQCESLZWkVvKhakFt7GiHSDYCu1oOaMEAbibM18hDZyJtQ+FIH9KwXjJB E7CTLFX1zS72WnKglhttDXW/bptJXrVdfHRgEMMUkq3RRio4A3XAH3rFu I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAAC89upZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ih90kBeWaBCCAQojhRgChHoYAQIBAQEBAQEBayiFHgY?= =?us-ascii?q?jFUEQCxoCJgICVwcMBgIBAYocEKtAgieLJAEBAQEBAQEBAQEBAQEBAQEBIYEPg?= =?us-ascii?q?h+DV4FpKYMBgTyDEYNMgmEFih4ViQiOKJRzghWFeoNdhzWOGIQ+gyWBOR84gVs?= =?us-ascii?q?0IQgdFR8qgmQJgl+BeT42h1IsghYBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,409,1503360000"; d="scan'208";a="656488660"
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; 21 Oct 2017 07:28:56 +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 v9L7StV1025181; Sat, 21 Oct 2017 07:28:56 GMT
To: mbj@tail-f.com, warren@kumari.net, kwatsen@juniper.net, lberger@labn.net
Cc: andy@yumaworks.com, netmod@ietf.org
References: <20171016190431.5FA26B80E0F@rfc-editor.org>
From: Benoit Claise 
Message-ID: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>
Date: Sat, 21 Oct 2017 09:28:56 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171016190431.5FA26B80E0F@rfc-editor.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Oct 2017 07:29:00 -0000

Dear all,

Shall I validate this one?

Regards, Benoit
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5157
>
> --------------------------------------
> Type: Technical
> Reported by: Andy Bierman 
>
> Section: 14
>
> Original Text
> -------------
>    key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string
>
> Corrected Text
> --------------
>    key-predicate-expr  = node-identifier *WSP "=" *WSP
>          (quoted-string / integer-value / decimal-value)
>
> Notes
> -----
> An instance identifier is forced to specify every key value to be a string
> even though the YANG key leaf type could be a numeric type.
> XPath does not require a quoted string here, just YANG.
>
> Old:  /top/list[idx="4"]
> New: /top/list[idx=4]
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --------------------------------------
> Title               : The YANG 1.1 Data Modeling Language
> Publication Date    : August 2016
> Author(s)           : M. Bjorklund, Ed.
> Category            : PROPOSED STANDARD
> Source              : NETCONF Data Modeling Language
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> .
>


From nobody Sat Oct 21 06:48:57 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBAF124B18; Sat, 21 Oct 2017 06:48:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150859372964.3123.17654248163501009673@ietfa.amsl.com>
Date: Sat, 21 Oct 2017 06:48:49 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-schema-mount-08.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, 21 Oct 2017 13:48:50 -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 Schema Mount
        Authors         : Martin Bjorklund
                          Ladislav Lhotka
	Filename        : draft-ietf-netmod-schema-mount-08.txt
	Pages           : 27
	Date            : 2017-10-21

Abstract:
   This document defines a mechanism to combine YANG modules into the
   schema defined in other YANG modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-08
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-08


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 Sat Oct 21 07:10:36 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37404126D3F for ; Sat, 21 Oct 2017 07:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.121
X-Spam-Level: 
X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=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 oc1z_zXm_0UC for ; Sat, 21 Oct 2017 07:10:33 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0122.outbound.protection.outlook.com [104.47.42.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85BD124B18 for ; Sat, 21 Oct 2017 07:10:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9kRucPnrjvK+LPM/dqWyrCljPJ3DNovOTsPXGRECPTA=; b=Lsn1cqDSKlCcg1HYNQ+DSaHbpvmMbCcndfMal5Xk4k9fn50MXc70ozvxP2vy5NECTdaALYxzLpdJgv2D2f07AHINg2n7O2MaR5lLB/H/uZGdJ7jwJXNuSNLTC2eRNN34w/wt+SviFFF1fnLWsccGeIL8cJnNVuiH0VkvQVC1bUQ=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB274.namprd05.prod.outlook.com (10.141.22.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Sat, 21 Oct 2017 14:10:32 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0178.003; Sat, 21 Oct 2017 14:10:32 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-08
Thread-Index: AQHTSnZblpFyoLN8ekG6ibtU7APGZw==
Date: Sat, 21 Oct 2017 14:10:32 +0000
Message-ID: <173F7830-9C40-4AF8-8E10-94C82677F245@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:8KHQq0MjNA/HeHcBj6RIbpUkZ19ytmUpvgAejzCEU7FEDsSB/rR/lo/W1TXYmSXbXDgvAmHXv7GOOTr6mjkYW5gc64g1ibz6gnJHjNSgntnpCbogy5eFIlLf559bmaK1Un9mivzRYtLW3dv2VqFbNe3pxo6GcMzl53AFaYvD+hAej0ErG+RlyD/WHaHMWaU9q/WHddqSKGj6RgClJbuKHV75TWyA3u2qcPUviweUbErru9duWBBsBB2ssmqRGsw8JYuwySSqEk9MR31MO4OZ8+JIfuhPCTOA9sngK04Utd42O+M6hOjSYHxMOOwXp16D2PyDL/ifG4Yi8pyKfFB80ImaXkSEUEAXoXCG8B+gFxc=; 5:l+DnFKK+SlLTsuFhvLUfVJaJ1/ZTs3ZKOKJIIm7K6zYFIkxJvhcy1OYoDRAi9WD9xHPO6CF/eZvbFe2PMsRmQFyLeLAjWX2YVpLfLaPeBL+zUvjOymTiIGiHD2CT/+djVvl17giTh61offHTcf9NPTTg3eUupJ5olyjUKh2x3RY=; 24:v9sG4aNJgHsoU8TXCiPpsQyJcbg59jJjHLG68r+ill3EL/g8R5QHQrxKEjQL/vLpaM2lrjZy6BEBYobvFaKo7vrwndX/Y1RXCEM2Tvx+7rU=; 7:AIxc0C6D7NKKQWUyGcZk/U6ijikRWgCm13y3ivKk1Aed8u245ZnVR7NiINw5Mn1eeQ2vUiMXJHkwN20h/1hUxWAjYoMoPj+ybSD5hqOnAiwd1aAPBqsKYHPxJDgtVFCpko5h+/Q9EgZ48G6pMhWBJ0Ntd7MOWSPk0yu2EoTBYsnA5m0sjxO8yDtUHRj0j/GS933bVFg8m/pHegIfJL04ByqhxT2pHgW8gbpg0XCk9vg5WNKtfnh5r1EuE9biqvbc
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 30516d3c-b7bc-4b88-eddf-08d5188d7de4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BLUPR05MB274; 
x-ms-traffictypediagnostic: BLUPR05MB274:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(3231020)(6055026)(6041248)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB274; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB274; 
x-forefront-prvs: 046753C63C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(199003)(189002)(230783001)(6512007)(58126008)(106356001)(83506002)(2351001)(33656002)(99286003)(53936002)(14454004)(6246003)(81156014)(8676002)(2900100001)(8936002)(83716003)(5660300001)(81166006)(25786009)(105586002)(316002)(1730700003)(86362001)(478600001)(50986999)(54356999)(101416001)(82746002)(3280700002)(36756003)(3660700001)(2501003)(6916009)(68736007)(6436002)(5640700003)(189998001)(229853002)(305945005)(7736002)(3846002)(102836003)(97736004)(6116002)(66066001)(2906002)(6486002)(77096006)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB274; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 30516d3c-b7bc-4b88-eddf-08d5188d7de4
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2017 14:10:32.3778 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB274
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Oct 2017 14:10:35 -0000

W2NoYW5naW5nIHN1YmplY3QgbGluZV0NCg0KQWxsLA0KDQpQbGVhc2UgdXNlIHRoZSBqdXN0LXBv
c3RlZCAtMDggdmVyc2lvbiBpbnN0ZWFkLg0KDQpJbiBhZGRpdGlvbiB0byBjaGFuZ2luZyB0aGUg
c3ViamVjdCBsaW5lLCBJIGFsc28gY2hhbmdlZA0KdGhlIHRleHQgYmVsb3cuICBUaGUgZW5kIGRh
dGUgcmVtYWlucyB1bmNoYW5nZWQuDQoNClJlZ2FyZHMsDQpLZW50IC8vIGNvLWNoYWlyDQoNCi0t
DQoNCkFsbCwNCg0KVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs
bCBvbg0KZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTA4Lg0KDQpUaGUgd29ya2luZyBn
cm91cCBsYXN0IGNhbGwgZW5kcyBvbiBOb3ZlbWJlciAzLg0KUGxlYXNlIHNlbmQgeW91ciBjb21t
ZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCg0KUG9zaXRpdmUgY29tbWVudHMsIGUu
Zy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgDQphbmQgYmVsaWV2ZSBpdCBpcyByZWFk
eSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENClRoaXMgaXMgdXNlZnVsIGFuZCBpbXBv
cnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KDQpDb3VsZCB0aGUgYXV0aG9ycywgZXhwbGljaXRs
eSBDQy1lZCBvbiB0aGlzIGVtYWlsLCANCnBsZWFzZSBhbHNvIGNvbmZpcm0gb25lIG1vcmUgdGlt
ZSB0aGF0IHRoZXkgYXJlIA0KdW5hd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFm
dC4NCg0KVGhhbmsgeW91LA0KTmV0bW9kIENoYWlycw0KDQoNCg0K


From nobody Sat Oct 21 11:16:46 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A30E13219B for ; Sat, 21 Oct 2017 11:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 9NuMhdOc7wal for ; Sat, 21 Oct 2017 11:16:43 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038A11241F3 for ; Sat, 21 Oct 2017 11:16:42 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id n69so16192837lfn.2 for ; Sat, 21 Oct 2017 11:16:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i0ykerLWoQwL6SsOvhIOd3qwlY0k6oNLdqhT8tNJe18=; b=nxp22MqRy7kT/kZOpv7NVbIHpWJUSv0EAwwpSoxUUT+F8Aj6pxCdtqJrBcjgMRlt2o KEafd7qiz3lfeP5GSM+iVAq8CdwbZipUZTaySx21wRnZyjy1mQBhGTW0x31um/yjN3jJ HHokneUoDOUekl+lXMu/Fea3xzzYI3aKH3ej5ZEGjz/G8sZ1919PLKvS2ramuEM04B0x 82D6M11R1Y8X/xhVHL1xMKWfLednPG6njFnY2ehjXeySYx3Iye57HCDXDh/QisI+pIhY 5hlHpfRsclBcx/qkT7f5BE2kWzb2RthWd3c7k2BAl8vltG9xi752ysqm/YobCEGfOmBK 8emw==
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=i0ykerLWoQwL6SsOvhIOd3qwlY0k6oNLdqhT8tNJe18=; b=fDGGNwtebOhoHc8zzz/7H4W0Qr9YLJJD3v3rH2ytGCzooiNaZ8MVCg3tDYPGGOHVBN pDU4KNq7I4V9tCgQWGEde0dryVhEuu/5Z/wvGYuTNcpZCfEFUmT3+OJ0FSRaAz57gBjq daj/D7l/T8Zwq3MYApPoFB8vmhzA3zkQiY6K8UE9oLlk2hi6cJZS+1+xlyefztyiuvZh iJij9+KqhDLUqEIn3wIzEuMpWeVmPPN27FcyZrsNQekMD+tS4D33e0kviKfLYZKrkytQ TFifi4y252J5342fuzjw3c9JbwgM4QLuqryZNPS1Fk62aPWze3zlfhVI0S8ltnrFrgUk VMNA==
X-Gm-Message-State: AMCzsaUXyVu9zUsAzi+m8FDc8yl7hWxOBBzpKMBBqycYL5hPMxIZrjYQ SbFDWNX8P0H5bG+T4G/1I5DNqvMK+uWr3yB3G3wWoA==
X-Google-Smtp-Source: ABhQp+RzQ5RZXzMw2jKxRDHl5Srjb2t+/dyf67dTbgo3RLDdRz6x/iNGIT/Y7nGDi1sMUXZRI1DvVb3sLF0UEsZcGMI=
X-Received: by 10.46.117.24 with SMTP id q24mr3325678ljc.14.1508609801233; Sat, 21 Oct 2017 11:16:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Sat, 21 Oct 2017 11:16:40 -0700 (PDT)
In-Reply-To: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>
References: <20171016190431.5FA26B80E0F@rfc-editor.org> <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>
From: Andy Bierman 
Date: Sat, 21 Oct 2017 11:16:40 -0700
Message-ID: 
To: Benoit Claise 
Cc: Martin Bjorklund , Warren Kumari , Kent Watsen ,  Berger Lou , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="089e082f63e04ebadd055c129752"
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Oct 2017 18:16:45 -0000

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

On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise  wrote:

> Dear all,
>
> Shall I validate this one?
>
>

To add more context, this relates to the the RESTCONF JSON vs. XML
discussions in the NETCONF WG.

  leaf broken {
      type union {
        type int32;
        type string;
     }
  }

If all values of key leaf "broken" are sent as strings in an
instance-identifier,
then the int32 value may not match in all implementations, instead of the
string.
Allowing numbers as literals in addition to quoted strings allows the sender
to be specific, and all implementations to be consistent.




> Regards, Benoit
>


Andy


> The following errata report has been submitted for RFC7950,
>> "The YANG 1.1 Data Modeling Language".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5157
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Andy Bierman 
>>
>> Section: 14
>>
>> Original Text
>> -------------
>>    key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string
>>
>> Corrected Text
>> --------------
>>    key-predicate-expr  = node-identifier *WSP "=" *WSP
>>          (quoted-string / integer-value / decimal-value)
>>
>> Notes
>> -----
>> An instance identifier is forced to specify every key value to be a string
>> even though the YANG key leaf type could be a numeric type.
>> XPath does not require a quoted string here, just YANG.
>>
>> Old:  /top/list[idx="4"]
>> New: /top/list[idx=4]
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>> --------------------------------------
>> Title               : The YANG 1.1 Data Modeling Language
>> Publication Date    : August 2016
>> Author(s)           : M. Bjorklund, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : NETCONF Data Modeling Language
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
>> .
>>
>>
>

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




On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise <<=
a href=3D"mailto:bclaise@cisco.com" target=3D"_blank">bclaise@cisco.com=
> wrote:
Dear all,



Shall I validate this one?




To add more context, th=
is relates to the the RESTCONF JSON vs. XML
discussions in the NE=
TCONF WG.

=C2=A0 leaf broken {
=C2=A0 =
=C2=A0 =C2=A0 type union {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32=
;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=
=A0 =C2=A0}
=C2=A0 }

If all values of ke=
y leaf "broken" are sent as strings in an instance-identifier,
then the int32 value may not match in all implementations, instead =
of the string.
Allowing numbers as literals in addition to quoted=
 strings allows the sender
to be specific, and all implementation=
s to be consistent.


=C2=A0

Regards, Benoit


Andy
=C2=A0



The following errata report has been submitted for RFC7950,

"The YANG 1.1 Data Modeling Language".



--------------------------------------

You may review the report below and at:

http://www.rfc-editor.org/errata/eid5157



--------------------------------------

Type: Technical

Reported by: Andy Bierman <andy@yumaworks.com>



Section: 14



Original Text

-------------

=C2=A0 =C2=A0key-predicate-expr=C2=A0 =3D node-identifier *WSP "=3D&qu=
ot; *WSP quoted-string



Corrected Text

--------------

=C2=A0 =C2=A0key-predicate-expr=C2=A0 =3D node-identifier *WSP "=3D&qu=
ot; *WSP

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(quoted-string / integer-value / decimal-=
value)



Notes

-----

An instance identifier is forced to specify every key value to be a string<=
br>
even though the YANG key leaf type could be a numeric type.

XPath does not require a quoted string here, just YANG.



Old:=C2=A0 /top/list[idx=3D"4"]

New: /top/list[idx=3D4]



Instructions:

-------------

This erratum is currently posted as "Reported". If necessary, ple=
ase

use "Reply All" to discuss whether it should be verified or

rejected. When a decision is reached, the verifying party

can log in to change the status and edit the report, if necessary.



--------------------------------------

RFC7950 (draft-ietf-netmod-rfc6020bis-14)

--------------------------------------

Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The YANG 1.1 =
Data Modeling Language

Publication Date=C2=A0 =C2=A0 : August 2016

Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bjorklund, Ed.

Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD

Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : NETCONF Data Model=
ing Language

Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an=
d Management

Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF

Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

.











--089e082f63e04ebadd055c129752--


From nobody Sat Oct 21 14:55:58 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2393113364C for ; Sat, 21 Oct 2017 14:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 jJ9RD96Jk_-L for ; Sat, 21 Oct 2017 14:55:55 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 C2C0F133648 for ; Sat, 21 Oct 2017 14:55:55 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id 15so4394014pgc.12 for ; Sat, 21 Oct 2017 14:55:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x93CclLY+T6VuhgRzu88aI6D5BCNBCC6BYV4ZL8bjWg=; b=eOU1XL0Ndo1zuC9Af15mgPLUuKAAbQ1smsbJqcJkes4JHDD1Ydt6YThzZucZc4JZHd uu/2wmVOnTBL9be72YxLKrwRrCd4i5LGXxW02eyDhnhR/cp74L9n9V/XfpTfG02p2LS/ RJQss7I0MySbdwLieinYudoN/Py4umsW0MOqvLUJxoOjvTuQv1TAglei43Um8SN4jrWY HrZTbBxxU+ocxyjylWkz++vTFWVUOW5c/wm31hIROINzqOXNEwZQw6AcQZD9CyaxDgH7 X/r3XH/PYyFfpkU/X4RKmIJXjjHI9HW6IXm2b6vYOOJUyOHFVQpqW14VL4XCjlYA1b8/ Z9vw==
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=x93CclLY+T6VuhgRzu88aI6D5BCNBCC6BYV4ZL8bjWg=; b=XkkexN1PlN8Gl53n4bDnAlDw+kdSkaanySQrrFrRP6Lekvvt1I665PTtpVvUZN7XTA z5Lb3J/GJfu/zh5Bu/1yVWAteiH9EUU6G3xY0atdYdzckDEy6p9HobX0nrCklMeUNdZf guYqo02OugKPLNoVoc46lt05bO6VbxBtQBrsXgZtUiAXVpk3R5v6im/HzP9iFPqJHkwa xfZPPRCa+oxdof07gFAKre7zMEIaBcb/puL+OKpUXZOi8dxwk21a/jbWIydwuuFpYMue NqhoF7cWLvZMtR27jq+VikpvRBjpcz6KIcGzUB1bNSPVdzVzYk611kJ9QkZWi5qxHHsV H/RA==
X-Gm-Message-State: AMCzsaV/Q1CeEMKCt21jL0VA0EoMIRHWUFxVVIZjIiz8C9DLox3LYwhF uE60a5DNbTtOITe9pvUbMqGhbnJw
X-Google-Smtp-Source: ABhQp+Qb8Ij5ErWC3eaAGknMaVOQyaWno8FANmN81r+mbOO9jw27Tgw4vX8YImJ78yYqWYMTXZ2FgA==
X-Received: by 10.98.105.199 with SMTP id e190mr8739538pfc.275.1508622955114;  Sat, 21 Oct 2017 14:55:55 -0700 (PDT)
Received: from ?IPv6:2607:fb90:850f:5e8b:39f4:43c8:3dea:2672? ([2607:fb90:850f:5e8b:39f4:43c8:3dea:2672]) by smtp.gmail.com with ESMTPSA id o22sm6730518pfi.85.2017.10.21.14.55.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Oct 2017 14:55:54 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura 
X-Mailer: iPhone Mail (15A432)
In-Reply-To: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net>
Date: Sat, 21 Oct 2017 14:55:52 -0700
Cc: "netmod@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net>
To: Kent Watsen 
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Oct 2017 21:55:57 -0000

Yes/support!
Very important work with many other drafts depending on.

Regards,
Jeff

> On Oct 20, 2017, at 14:37, Kent Watsen  wrote:
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-schema-mount-07.
> 
> The working group last call ends on November 3.
> 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.
> 
> Could the authors, explicitly CC-ed on this email, 
> please also confirm one more 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


From nobody Sat Oct 21 16:33:10 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CBE133DD4 for ; Sat, 21 Oct 2017 16:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.601
X-Spam-Level: 
X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yn7Q6WdLiQe for ; Sat, 21 Oct 2017 16:33:07 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E15B133DCD for ; Sat, 21 Oct 2017 16:33:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1648; q=dns/txt; s=iport; t=1508628787; x=1509838387; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0KftGVP0M1kX6s+3d++UlUFBWcnJQ53n0uU5cKgOCXc=; b=kHNinrR6nheQ7tDgvSAm11RdwvkI6p0+VTNFNCODUXvG2MLr1T/sYfZI DBmA7HywmtWiUYxWwWJyLYfx5LAGXoYC/WOTgJmic3QdbawyAXv3NVbtz DwRYZr35Ke/4+oxnJXs94p5ZQnb+Aet6zY8Kh8gnj3ldH2QfN80xaP4JR o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AAD11+tZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHg3OKH48+mDMQggEKGAuESU8CGoQiPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUeAgEDAQEhETobAgEIDgwCJgICAiULFRACBAESiiAQqwSCJ4sVAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARoFgQ+CH4IHhmOEUgESAR8Xgn2CYQWhZgKUcoIVhXqEAYc?= =?us-ascii?q?RlU8CERkBgTgBHziBA1h6FUmCZIRfdogugSSBEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,413,1503360000"; d="scan'208";a="308837796"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2017 23:33:06 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v9LNX5Xq017915 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 21 Oct 2017 23:33:06 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 21 Oct 2017 19:33:05 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Sat, 21 Oct 2017 19:33:05 -0400
From: "Acee Lindem (acee)" 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-08
Thread-Index: AQHTSnZblpFyoLN8ekG6ibtU7APGZ6Lu9NmA
Date: Sat, 21 Oct 2017 23:33:04 +0000
Message-ID: 
References: <173F7830-9C40-4AF8-8E10-94C82677F245@juniper.net>
In-Reply-To: <173F7830-9C40-4AF8-8E10-94C82677F245@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.195]
Content-Type: text/plain; charset="utf-8"
Content-ID: <37704CA902F4C540AE2DFB7A85A19D39@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Oct 2017 23:33:09 -0000

SSBoYXZlIHJldmlld2VkIHByaW9yIHZlcnNpb25zIG9mIHRoZSBkcmFmdCBhbmQgcmVhZCB0aGlz
IHZlcnNpb24uIEkNCnVuZXF1aXZvY2FsbHkgc3VwcG9ydCBwdWJsaWNhdGlvbi4NClRoYW5rcywN
CkFjZWUgDQoNCk9uIDEwLzIxLzE3LCAxMDoxMCBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgS2Vu
dCBXYXRzZW4iDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGt3YXRzZW5A
anVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+W2NoYW5naW5nIHN1YmplY3QgbGluZV0NCj4NCj5BbGws
DQo+DQo+UGxlYXNlIHVzZSB0aGUganVzdC1wb3N0ZWQgLTA4IHZlcnNpb24gaW5zdGVhZC4NCj4N
Cj5JbiBhZGRpdGlvbiB0byBjaGFuZ2luZyB0aGUgc3ViamVjdCBsaW5lLCBJIGFsc28gY2hhbmdl
ZA0KPnRoZSB0ZXh0IGJlbG93LiAgVGhlIGVuZCBkYXRlIHJlbWFpbnMgdW5jaGFuZ2VkLg0KPg0K
PlJlZ2FyZHMsDQo+S2VudCAvLyBjby1jaGFpcg0KPg0KPi0tDQo+DQo+QWxsLA0KPg0KPlRoaXMg
c3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj5kcmFmdC1pZXRm
LW5ldG1vZC1zY2hlbWEtbW91bnQtMDguDQo+DQo+VGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs
IGVuZHMgb24gTm92ZW1iZXIgMy4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBu
ZXRtb2QgbWFpbGluZyBsaXN0Lg0KPg0KPlBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSBy
ZXZpZXdlZCB0aGlzIGRvY3VtZW50DQo+YW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1Ymxp
Y2F0aW9uIiwgYXJlIHdlbGNvbWUhDQo+VGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZl
biBmcm9tIGF1dGhvcnMuDQo+DQo+Q291bGQgdGhlIGF1dGhvcnMsIGV4cGxpY2l0bHkgQ0MtZWQg
b24gdGhpcyBlbWFpbCwNCj5wbGVhc2UgYWxzbyBjb25maXJtIG9uZSBtb3JlIHRpbWUgdGhhdCB0
aGV5IGFyZQ0KPnVuYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQo+DQo+
VGhhbmsgeW91LA0KPk5ldG1vZCBDaGFpcnMNCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRt
b2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KDQo=


From nobody Sat Oct 21 17:25:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7251344DC for ; Sat, 21 Oct 2017 17:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 yJpCzEag482R for ; Sat, 21 Oct 2017 17:25:30 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D615B1344D6 for ; Sat, 21 Oct 2017 17:25:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B76281404004; Sun, 22 Oct 2017 02:25:27 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JnJxse_D1gSq; Sun, 22 Oct 2017 02:25:27 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 8DA44140396D; Sun, 22 Oct 2017 02:25:27 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uCR9y29yzmCl; Sun, 22 Oct 2017 02:25:27 +0200 (CEST)
Received: from [192.168.2.191] (cm-84.211.71.154.getinternet.no [84.211.71.154]) by mail.transpacket.com (Postfix) with ESMTPSA id 631D51403896; Sun, 22 Oct 2017 02:25:27 +0200 (CEST)
To: Andy Bierman 
References: <20171016190431.5FA26B80E0F@rfc-editor.org> <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com> 
Cc: "netmod@ietf.org" 
From: Vladimir Vassilev 
Message-ID: <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com>
Date: Sun, 22 Oct 2017 02:25:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Oct 2017 00:25:33 -0000

Hello,

I would like to use the occasion of this Errata report to point out some 
additional issues with the instance-identifier type definition.

IMO the instance-identifier built-in type has 2 additional problems that 
can be addressed with alternative and significantly more radical errata 
or fixed in a new version of YANG.:

Problem 1: The obvious limitation inherited from Xpath 1.0 - inability 
to escape single or double quote characters. In Xpath world this 
limitation is worked around by use of concat() which is not available in 
the YANG 1.1 instance-identifier definition. 2 examples of this limitation:

1. It is impossible to create value of type instance-identifier 
referencing nodes in lists with key string values containing both a 
single and a double quote characters e.g. ..."It's 
valid string!".

2. Another example of the same problem would be a leaf of type 
instance-identifier referencing another leaf of type 
instance-identifier. With 2 references it works provided one is encoded 
with single quotes and the other with double but it is impossible to 
create third e.g.

YANG:

     list id-list {
       key "id";

       leaf id {
           type instance-identifier;
       }
     }

Data:

* /top/id-list[id="/top/list[idx='4']"]

* /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"] 

* 

Problem 2: The instance-identifier type lacks canonical form (which 
makes it the only data type with implementation dependent representation 
at the data level ... think of the integer types allowing optional 
spaces between the digits). This is in fact the only built-in data type 
that allows the server implementation to change the configuration data 
replacing double quotes with single or the other way around. Inserting 
white spaces where you did not have them when the configuration was 
submitted. You can not simply read a configuration and use fast data 
comparison without schema support just because of this type. This is 
useless flexibility for simple data type.

And this can be fixed if:

1. white spaces in instance-identifiers are prohibited

2. list key predicates are required in alphabetical order

3. strict quotation convention with escape option is added. (only 3. 
contradicts the sec. 9.13 ".. instance-identifier is a subset of the 
XPath ..")

Vladimir

On 10/21/2017 08:16 PM, Andy Bierman wrote:
>
>
> On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise  > wrote:
>
>     Dear all,
>
>     Shall I validate this one?
>
>
>
> To add more context, this relates to the the RESTCONF JSON vs. XML
> discussions in the NETCONF WG.
>
>   leaf broken {
>       type union {
>         type int32;
>         type string;
>      }
>   }
>
> If all values of key leaf "broken" are sent as strings in an 
> instance-identifier,
> then the int32 value may not match in all implementations, instead of 
> the string.
> Allowing numbers as literals in addition to quoted strings allows the 
> sender
> to be specific, and all implementations to be consistent.
>
>
>     Regards, Benoit
>
>
>
> Andy
>
>         The following errata report has been submitted for RFC7950,
>         "The YANG 1.1 Data Modeling Language".
>
>         --------------------------------------
>         You may review the report below and at:
>         http://www.rfc-editor.org/errata/eid5157
>         
>
>         --------------------------------------
>         Type: Technical
>         Reported by: Andy Bierman          >
>
>         Section: 14
>
>         Original Text
>         -------------
>            key-predicate-expr  = node-identifier *WSP "=" *WSP
>         quoted-string
>
>         Corrected Text
>         --------------
>            key-predicate-expr  = node-identifier *WSP "=" *WSP
>                  (quoted-string / integer-value / decimal-value)
>
>         Notes
>         -----
>         An instance identifier is forced to specify every key value to
>         be a string
>         even though the YANG key leaf type could be a numeric type.
>         XPath does not require a quoted string here, just YANG.
>
>         Old:  /top/list[idx="4"]
>         New: /top/list[idx=4]
>
>         Instructions:
>         -------------
>         This erratum is currently posted as "Reported". If necessary,
>         please
>         use "Reply All" to discuss whether it should be verified or
>         rejected. When a decision is reached, the verifying party
>         can log in to change the status and edit the report, if necessary.
>
>         --------------------------------------
>         RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>         --------------------------------------
>         Title               : The YANG 1.1 Data Modeling Language
>         Publication Date    : August 2016
>         Author(s)           : M. Bjorklund, Ed.
>         Category            : PROPOSED STANDARD
>         Source              : NETCONF Data Modeling Language
>         Area                : Operations and Management
>         Stream              : IETF
>         Verifying Party     : IESG
>         .
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Oct 23 01:36:47 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF1013F084 for ; Mon, 23 Oct 2017 01:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMUdYmbS9Gog for ; Mon, 23 Oct 2017 01:36:44 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEED13F081 for ; Mon, 23 Oct 2017 01:36:44 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id A3EF51AE012C; Mon, 23 Oct 2017 10:36:39 +0200 (CEST)
Date: Mon, 23 Oct 2017 10:35:13 +0200 (CEST)
Message-Id: <20171023.103513.1336510497564838401.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: warren@kumari.net, kwatsen@juniper.net, lberger@labn.net, andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>
References: <20171016190431.5FA26B80E0F@rfc-editor.org> <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 08:36:46 -0000

Benoit Claise  wrote:
> Dear all,
> 
> Shall I validate this one?

No I don't think this is correct.  We choose a quoted string to be
able to correctly represent all YANG integer and decimal64 values.
Note that XPath doesn't have integers, just 64-bit floats.  This means
that not all 64-bit integers can be expressed as numbers in XPath.


/martin


> 
> Regards, Benoit
> > The following errata report has been submitted for RFC7950,
> > "The YANG 1.1 Data Modeling Language".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5157
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Andy Bierman 
> >
> > Section: 14
> >
> > Original Text
> > -------------
> >    key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string
> >
> > Corrected Text
> > --------------
> >    key-predicate-expr  = node-identifier *WSP "=" *WSP
> >          (quoted-string / integer-value / decimal-value)
> >
> > Notes
> > -----
> > An instance identifier is forced to specify every key value to be a
> > string
> > even though the YANG key leaf type could be a numeric type.
> > XPath does not require a quoted string here, just YANG.
> >
> > Old:  /top/list[idx="4"]
> > New: /top/list[idx=4]
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > --------------------------------------
> > Title               : The YANG 1.1 Data Modeling Language
> > Publication Date    : August 2016
> > Author(s)           : M. Bjorklund, Ed.
> > Category            : PROPOSED STANDARD
> > Source              : NETCONF Data Modeling Language
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> > .
> >
> 


From nobody Mon Oct 23 01:39:39 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4991B13F0D1 for ; Mon, 23 Oct 2017 01:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7U2ACg5XvxN for ; Mon, 23 Oct 2017 01:39:36 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E00C113F0D0 for ; Mon, 23 Oct 2017 01:39:35 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 1739C1AE012C; Mon, 23 Oct 2017 10:39:35 +0200 (CEST)
Date: Mon, 23 Oct 2017 10:38:09 +0200 (CEST)
Message-Id: <20171023.103809.730636049643361231.mbj@tail-f.com>
To: william.ivory@intl.att.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] Clarification wanted regarding applicability of YANG 1.1 issues list to YANG 1.0 implementations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 08:39:37 -0000

Hi,

The problem is that this behavior was underspecified in YANG 1.  Fixed
in YANG 1.1, but it means that you can't expect the behavior for YANG
1 modules to be the same in different servers.


/martin


"Ivory, William"  wrote:
> Hi,
> 
> I've asked about evaluating must statements on unconfigured
> non-presence containers here before, but realise I never got a
> definitive answer on whether the clarification in the YANG 1.1 issues
> list actually applies to YANG 1.0, or only YANG 1.1:
> 
> YANG 1.0 XPATH context:
> https://tools.ietf.org/html/rfc6020#section-6.4.1
> 
>   *   No mention of non-presence containers
> 
> YANG 1.0 errata: https://www.rfc-editor.org/errata_search.php?rfc=6020
> 
>   *   No mention of non-presence containers
> 
> YANG 1.1 Issues list:
> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-42
> 
>   *   Clarification of handling of non-presence containers for XPATH context
>   *   / validation
> 
> YANG 1.1 XPATH context:
> https://tools.ietf.org/html/rfc7950#section-6.4.1
> 
>   *   'If a node that exists in the accessible tree has a non-presence
>   *   container as a child, then the non-presence container also exists in
>   *   the accessible tree.'
> 
> As you can see from the links above, the errata for YANG 1.0 does NOT
> include the clarification, whereas the text of YANG 1.1 (RFC 7950)
> does.
> 
> Thanks,
> 
> William


From nobody Mon Oct 23 02:12:14 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB2413F3A0 for ; Mon, 23 Oct 2017 02:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENRsUa0mvAcl for ; Mon, 23 Oct 2017 02:12:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD2613F398 for ; Mon, 23 Oct 2017 02:12:09 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 1CF541AE012C; Mon, 23 Oct 2017 11:12:07 +0200 (CEST)
Date: Mon, 23 Oct 2017 11:10:41 +0200 (CEST)
Message-Id: <20171023.111041.247783860756995497.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <87h8utg7q8.fsf@nic.cz> <4b74f390-4817-9154-e427-cd879e0ceeb9@cisco.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 09:12:13 -0000

Andy Bierman  wrote:
> On Fri, Oct 20, 2017 at 9:24 AM, Robert Wilton  wrote:
> 
> > Hi Lada,
> >
> > Thanks for the explanation, that makes sense.
> >
> >
> > On 20/10/2017 16:27, Ladislav Lhotka wrote:
> >
> >> Hi Rob,
> >>
> >> Robert Wilton  writes:
> >>
> >> Hi,
> >>>
> >>> XPATH 1.0 defines the following three node-type tests:
> >>>
> >>> 1) comment()
> >>> 2) processing-instruction()
> >>> 3) text()
> >>>
> >> For completeness, node() is the fourth one.
> >>
> >> My assumption is that a YANG tree doesn't contain any nodes of type
> >>> 'comment' or 'processing-instruction' and hence these filters would
> >>> never match any nodes.
> >>>
> >> Yes. FWIW, Yangson library raises NotSupported exception upon
> >> encountering these.
> >>
> >
> 
> But a server or client should ignore PIs, not reject the XML.
> 
> I think text() and node() are just filter tests.
> 
>   /foo/*[text()] would return all the child nodes of /foo that are leaf or
> leaf-list
> 
> text() returns a boolean (0 or 1).  Do not use it for value testing:

No.  text() will select the text node children of the context node.

>   /foo/*[text() = 'fred']  // wrong!

This actually works.  text() selects all text nodes (just one for a
leaf), and then that text node is compared to the string 'fred'.



/martin




>   /foo/*[. = 'fred']  // correct
> 
> [7]    NodeTest    ::=    NameTest
> 
> | NodeType  '('
> ')'
> | 'processing-instruction' '(' Literal
>  ')'
> 
> 
> >> However, it wasn't clear to me from reading 7950 or rfc6087bis-14
> >>> whether text() matches anything.  In particular, does a YANG leaf node
> >>> (except of type empty) always parent a text node that holds its value?
> >>>
> >> I believe this is how it should be interpreted. According to XPath 1.0
> >> spec, comparisons like
> >>
> >>      xyz = 'foo'
> >>
> >> use string-value of xyz node, which is defined as the concatenation of
> >> the string-values of all text node descendants of xyz.
> >>
> > Yes.  I don't think that I've ever come across for XPath usage in YANG
> > where the "concatenation of the string-values of all text node descendants
> > " is actually useful (particularly as the children nodes are likely to not
> > be consistently ordered).
> >
> >
> 
> 
> I think text() and node() are just filter tests.
> 
>   /foo/*[text()] would return all the child nodes of /foo that are leaf or
> leaf-list
> 
> text() returns a boolean (0 or 1).
> 
> 
> [7]    NodeTest    ::=    NameTest
> 
> | NodeType  '('
> ')'
> | 'processing-instruction' '(' Literal
>  ')'
> 
> 
> 
> 
> [38]    NodeType    ::=    'comment'
> | 'text'
> | 'processing-instruction'
> | 'node'
> 
> 
> 
> 
> The node test text() is true for any text node. For example, child::text() will
> select the text node children of the context node. Similarly, the node test
> comment() is true for any comment node, and the node test
> processing-instruction() is true for any processing instruction. The
> processing-instruction() test may have an argument that is Literal
> ; in this case,
> it is true for any processing instruction that has a name equal to the
> value of the Literal
> .
> 
> 
> Thanks,
> > Rob
> >
> >
> >
> >> Lada
> >>
> >>
> 
> Andy
> 
> 
> 
> > Thanks,
> >>> Rob
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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 Oct 23 03:06:05 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2B713F3A9 for ; Mon, 23 Oct 2017 03:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS5OyML7l7eQ for ; Mon, 23 Oct 2017 03:06:01 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD5813F3AB for ; Mon, 23 Oct 2017 03:06:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5289; q=dns/txt; s=iport; t=1508753161; x=1509962761; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=J+/usBvPeoqIJc0M2DTGtaKmaqqX/tDkL8QPmLyq6+0=; b=cUu8DE577ZAIM8zJuggfDYXht/PU4QZKBtAJSWrjs2yl1CUL/gf3nsaF dFtDM9F4vN0n1yNnvF55rUwisqJXre97Sb8mo8ynWC1wvzEim606+2vM5 GZVBJOasq/rIIzQF3QihugY+g2INQmfQCy+F6LgpD2pxBOTSqK9xbpyAk M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQA9vu1Z/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEM5NSeDeosTkEd7lT6CEQoYC4RJTwKFChYBAgEBAQEBAQFrKIU?= =?us-ascii?q?eAQEBAwEBIRU2CxALDgoCAiYCAicwBgEMBgIBAYocEKtdgieLHQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGQWBD4Ifg1eBaSmCTDWEb4MqgmEFkVCQFpR0i2yHNY4Zh2O?= =?us-ascii?q?BOSYMJYFbNCEIHRVJgmSEYD82i3oBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,422,1503360000"; d="scan'208";a="656530738"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2017 10:05:59 +0000
Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9NA5wEn025830; Mon, 23 Oct 2017 10:05:58 GMT
To: Martin Bjorklund , andy@yumaworks.com
Cc: netmod@ietf.org
References: <87h8utg7q8.fsf@nic.cz> <4b74f390-4817-9154-e427-cd879e0ceeb9@cisco.com>  <20171023.111041.247783860756995497.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <93844bdb-dcd9-758e-f58a-4cad047d4fd7@cisco.com>
Date: Mon, 23 Oct 2017 11:05:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171023.111041.247783860756995497.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 10:06:04 -0000

On 23/10/2017 10:10, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> On Fri, Oct 20, 2017 at 9:24 AM, Robert Wilton  wrote:
>>
>>> Hi Lada,
>>>
>>> Thanks for the explanation, that makes sense.
>>>
>>>
>>> On 20/10/2017 16:27, Ladislav Lhotka wrote:
>>>
>>>> Hi Rob,
>>>>
>>>> Robert Wilton  writes:
>>>>
>>>> Hi,
>>>>> XPATH 1.0 defines the following three node-type tests:
>>>>>
>>>>> 1) comment()
>>>>> 2) processing-instruction()
>>>>> 3) text()
>>>>>
>>>> For completeness, node() is the fourth one.
>>>>
>>>> My assumption is that a YANG tree doesn't contain any nodes of type
>>>>> 'comment' or 'processing-instruction' and hence these filters would
>>>>> never match any nodes.
>>>>>
>>>> Yes. FWIW, Yangson library raises NotSupported exception upon
>>>> encountering these.
>>>>
>> But a server or client should ignore PIs, not reject the XML.
>>
>> I think text() and node() are just filter tests.
>>
>>    /foo/*[text()] would return all the child nodes of /foo that are leaf or
>> leaf-list
>>
>> text() returns a boolean (0 or 1).  Do not use it for value testing:
> No.  text() will select the text node children of the context node.
This is presumably because text() is evaluated as "child::text()".

>
>>    /foo/*[text() = 'fred']  // wrong!
> This actually works.  text() selects all text nodes (just one for a
> leaf), and then that text node is compared to the string 'fred'.
For clarity, am I right in my interpretation that a leaf is not itself a 
text node, but instead a leaf is an element node that contains a direct 
child text node?

Presumably, it is only leaf and leaf-list element nodes that can have 
these direct child text nodes.

I can see how this make sense for a XML document, but it does feel a bit 
non intuitive for a YANG data tree, and it may be helpful if this is 
documented somewhat ...

   /foo/*[. = 'fred']  // correct

Presumably this test isn't quite the same, since child container and 
list nodes would also be included in the comparison (i.e. by 
concatenating all their descendant leaf values together into a single 
string), whereas the expression with the text() check will only include 
the values of direct child leaf and leaf-list nodes (as YANG is 
currently defined today).

Thanks,
Rob


>
>
>
> /martin
>
>
>
>
>>    /foo/*[. = 'fred']  // correct
>>
>> [7]    NodeTest    ::=    NameTest
>> 
>> | NodeType  '('
>> ')'
>> | 'processing-instruction' '(' Literal
>>  ')'
>>
>>
>>>> However, it wasn't clear to me from reading 7950 or rfc6087bis-14
>>>>> whether text() matches anything.  In particular, does a YANG leaf node
>>>>> (except of type empty) always parent a text node that holds its value?
>>>>>
>>>> I believe this is how it should be interpreted. According to XPath 1.0
>>>> spec, comparisons like
>>>>
>>>>       xyz = 'foo'
>>>>
>>>> use string-value of xyz node, which is defined as the concatenation of
>>>> the string-values of all text node descendants of xyz.
>>>>
>>> Yes.  I don't think that I've ever come across for XPath usage in YANG
>>> where the "concatenation of the string-values of all text node descendants
>>> " is actually useful (particularly as the children nodes are likely to not
>>> be consistently ordered).
>>>
>>>
>>
>> I think text() and node() are just filter tests.
>>
>>    /foo/*[text()] would return all the child nodes of /foo that are leaf or
>> leaf-list
>>
>> text() returns a boolean (0 or 1).
>>
>>
>> [7]    NodeTest    ::=    NameTest
>> 
>> | NodeType  '('
>> ')'
>> | 'processing-instruction' '(' Literal
>>  ')'
>>
>>
>>
>>
>> [38]    NodeType    ::=    'comment'
>> | 'text'
>> | 'processing-instruction'
>> | 'node'
>>
>>
>>
>>
>> The node test text() is true for any text node. For example, child::text() will
>> select the text node children of the context node. Similarly, the node test
>> comment() is true for any comment node, and the node test
>> processing-instruction() is true for any processing instruction. The
>> processing-instruction() test may have an argument that is Literal
>> ; in this case,
>> it is true for any processing instruction that has a name equal to the
>> value of the Literal
>> .
>>
>>
>> Thanks,
>>> Rob
>>>
>>>
>>>
>>>> Lada
>>>>
>>>>
>> Andy
>>
>>
>>
>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Oct 23 03:39:06 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3178513F0AD for ; Mon, 23 Oct 2017 03:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jD8Oi6hO52A for ; Mon, 23 Oct 2017 03:39:02 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9C83613E167 for ; Mon, 23 Oct 2017 03:39:02 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id AD8FE1AE012C; Mon, 23 Oct 2017 12:39:00 +0200 (CEST)
Date: Mon, 23 Oct 2017 12:37:34 +0200 (CEST)
Message-Id: <20171023.123734.1274882060625273119.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <93844bdb-dcd9-758e-f58a-4cad047d4fd7@cisco.com>
References:  <20171023.111041.247783860756995497.mbj@tail-f.com> <93844bdb-dcd9-758e-f58a-4cad047d4fd7@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 10:39:04 -0000

Robert Wilton  wrote:
> 
> 
> On 23/10/2017 10:10, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> >> On Fri, Oct 20, 2017 at 9:24 AM, Robert Wilton 
> >> wrote:
> >>
> >>> Hi Lada,
> >>>
> >>> Thanks for the explanation, that makes sense.
> >>>
> >>>
> >>> On 20/10/2017 16:27, Ladislav Lhotka wrote:
> >>>
> >>>> Hi Rob,
> >>>>
> >>>> Robert Wilton  writes:
> >>>>
> >>>> Hi,
> >>>>> XPATH 1.0 defines the following three node-type tests:
> >>>>>
> >>>>> 1) comment()
> >>>>> 2) processing-instruction()
> >>>>> 3) text()
> >>>>>
> >>>> For completeness, node() is the fourth one.
> >>>>
> >>>> My assumption is that a YANG tree doesn't contain any nodes of type
> >>>>> 'comment' or 'processing-instruction' and hence these filters would
> >>>>> never match any nodes.
> >>>>>
> >>>> Yes. FWIW, Yangson library raises NotSupported exception upon
> >>>> encountering these.
> >>>>
> >> But a server or client should ignore PIs, not reject the XML.
> >>
> >> I think text() and node() are just filter tests.
> >>
> >>    /foo/*[text()] would return all the child nodes of /foo that are leaf
> >>    or
> >> leaf-list
> >>
> >> text() returns a boolean (0 or 1).  Do not use it for value testing:
> > No.  text() will select the text node children of the context node.
> This is presumably because text() is evaluated as "child::text()".

Yes.

> >>    /foo/*[text() = 'fred']  // wrong!
> > This actually works.  text() selects all text nodes (just one for a
> > leaf), and then that text node is compared to the string 'fred'.
> For clarity, am I right in my interpretation that a leaf is not itself
> a text node, but instead a leaf is an element node that contains a
> direct child text node?

Yes.

> Presumably, it is only leaf and leaf-list element nodes that can have
> these direct child text nodes.

Yes.

> I can see how this make sense for a XML document, but it does feel a
> bit non intuitive for a YANG data tree

Maybe, but since we use XPath, we need to conform to the data model
used by XPath (see section 5 of the xpath spec).

> and it may be helpful if this
> is documented somewhat ...

RFC 7950 refers to the data model of XPath (See section 6.4 of RFC
7950), but I agree that it could have had more text.  Specifically, it
could have stated how nodes are mapped to elements, that only
leaf/leaf-list have text nodes; that annotations are mapped to
attribute nodes (ok, not really in 7950...); that there are no
processing-instruction and comment nodes.

> 
>   /foo/*[. = 'fred']  // correct
> 
> Presumably this test isn't quite the same, since child container and
> list nodes would also be included in the comparison (i.e. by
> concatenating all their descendant leaf values together into a single
> string)
> whereas the expression with the text() check will only
> include the values of direct child leaf and leaf-list nodes (as YANG
> is currently defined today).

Yes.


/martin


From nobody Mon Oct 23 04:32:41 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCE713F3C7 for ; Mon, 23 Oct 2017 04:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 JhctRmxRA7fX for ; Mon, 23 Oct 2017 04:32:38 -0700 (PDT)
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 D7FBB13F3C1 for ; Mon, 23 Oct 2017 04:32:37 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:29c8:f93b:f52b:6626] (unknown [IPv6:2a01:5e0:29:ffff:29c8:f93b:f52b:6626]) by mail.nic.cz (Postfix) with ESMTPSA id 2F17C60114; Mon, 23 Oct 2017 13:32:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1508758355; bh=PAScexyxsO0daiz4BmOzFrRR59JTcv6AxTClFRBf9es=; h=From:Date:To; b=wSrzpZo/Mj4v2k2hdkzGZbYkRh7N911pdr2pAHJbOOmLJWfToHGjf3xu539MEdpk0 PgKkaXLgCj0r4Ry0ULNjF7fglnFuJ/vCObZJJeJO1pKmJKG8GeXw4LVaT0B/9mixKA zif+VP0osj0SFjzjMrP6llUUJya+5dnjb3z+9XJY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ladislav Lhotka 
In-Reply-To: <20171023.123734.1274882060625273119.mbj@tail-f.com>
Date: Mon, 23 Oct 2017 13:33:12 +0200
Cc: Robert Wilton , netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20171023.111041.247783860756995497.mbj@tail-f.com> <93844bdb-dcd9-758e-f58a-4cad047d4fd7@cisco.com> <20171023.123734.1274882060625273119.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3273)
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 11:32:40 -0000

> On 23 Oct 2017, at 12:37, Martin Bjorklund  wrote:
>=20
> Robert Wilton  wrote:
>>=20
>>=20
>> On 23/10/2017 10:10, Martin Bjorklund wrote:
>>> Andy Bierman  wrote:
>>>> On Fri, Oct 20, 2017 at 9:24 AM, Robert Wilton 
>>>> wrote:
>>>>=20
>>>>> Hi Lada,
>>>>>=20
>>>>> Thanks for the explanation, that makes sense.
>>>>>=20
>>>>>=20
>>>>> On 20/10/2017 16:27, Ladislav Lhotka wrote:
>>>>>=20
>>>>>> Hi Rob,
>>>>>>=20
>>>>>> Robert Wilton  writes:
>>>>>>=20
>>>>>> Hi,
>>>>>>> XPATH 1.0 defines the following three node-type tests:
>>>>>>>=20
>>>>>>> 1) comment()
>>>>>>> 2) processing-instruction()
>>>>>>> 3) text()
>>>>>>>=20
>>>>>> For completeness, node() is the fourth one.
>>>>>>=20
>>>>>> My assumption is that a YANG tree doesn't contain any nodes of =
type
>>>>>>> 'comment' or 'processing-instruction' and hence these filters =
would
>>>>>>> never match any nodes.
>>>>>>>=20
>>>>>> Yes. FWIW, Yangson library raises NotSupported exception upon
>>>>>> encountering these.
>>>>>>=20
>>>> But a server or client should ignore PIs, not reject the XML.
>>>>=20
>>>> I think text() and node() are just filter tests.
>>>>=20
>>>>   /foo/*[text()] would return all the child nodes of /foo that are =
leaf
>>>>   or
>>>> leaf-list
>>>>=20
>>>> text() returns a boolean (0 or 1).  Do not use it for value =
testing:
>>> No.  text() will select the text node children of the context node.
>> This is presumably because text() is evaluated as "child::text()".
>=20
> Yes.
>=20
>>>>   /foo/*[text() =3D 'fred']  // wrong!
>>> This actually works.  text() selects all text nodes (just one for a
>>> leaf), and then that text node is compared to the string 'fred'.
>> For clarity, am I right in my interpretation that a leaf is not =
itself
>> a text node, but instead a leaf is an element node that contains a
>> direct child text node?
>=20
> Yes.

In principle, there could be multiple text nodes (in XML processing this =
is quite common).

Lada

>=20
>> Presumably, it is only leaf and leaf-list element nodes that can have
>> these direct child text nodes.
>=20
> Yes.
>=20
>> I can see how this make sense for a XML document, but it does feel a
>> bit non intuitive for a YANG data tree
>=20
> Maybe, but since we use XPath, we need to conform to the data model
> used by XPath (see section 5 of the xpath spec).
>=20
>> and it may be helpful if this
>> is documented somewhat ...
>=20
> RFC 7950 refers to the data model of XPath (See section 6.4 of RFC
> 7950), but I agree that it could have had more text.  Specifically, it
> could have stated how nodes are mapped to elements, that only
> leaf/leaf-list have text nodes; that annotations are mapped to
> attribute nodes (ok, not really in 7950...); that there are no
> processing-instruction and comment nodes.
>=20
>>=20
>>  /foo/*[. =3D 'fred']  // correct
>>=20
>> Presumably this test isn't quite the same, since child container and
>> list nodes would also be included in the comparison (i.e. by
>> concatenating all their descendant leaf values together into a single
>> string)
>> whereas the expression with the text() check will only
>> include the values of direct child leaf and leaf-list nodes (as YANG
>> is currently defined today).
>=20
> Yes.
>=20
>=20
> /martin
>=20
> _______________________________________________
> 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 Oct 23 04:37:30 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C8A13F3C3 for ; Mon, 23 Oct 2017 04:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z0zqEmSqbWig for ; Mon, 23 Oct 2017 04:37:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA2F138A98 for ; Mon, 23 Oct 2017 04:37:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 726BC1AE012C; Mon, 23 Oct 2017 13:37:25 +0200 (CEST)
Date: Mon, 23 Oct 2017 13:35:59 +0200 (CEST)
Message-Id: <20171023.133559.470792369996870413.mbj@tail-f.com>
To: vladimir@transpacket.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com>
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 11:37:29 -0000

Vladimir Vassilev  wrote:
> Hello,
> 
> I would like to use the occasion of this Errata report to point out
> some additional issues with the instance-identifier type definition.
> 
> IMO the instance-identifier built-in type has 2 additional problems
> that can be addressed with alternative and significantly more radical
> errata or fixed in a new version of YANG.:
> 
> Problem 1: The obvious limitation inherited from Xpath 1.0 - inability
> to escape single or double quote characters. In Xpath world this
> limitation is worked around by use of concat() which is not available
> in the YANG 1.1 instance-identifier definition. 2 examples of this
> limitation:
> 
> 1. It is impossible to create value of type instance-identifier
> referencing nodes in lists with key string values containing both a
> single and a double quote characters e.g. ..."It's
> valid string!".
> 
> 2. Another example of the same problem would be a leaf of type
> instance-identifier referencing another leaf of type
> instance-identifier. With 2 references it works provided one is
> encoded with single quotes and the other with double but it is
> impossible to create third e.g.
> 
> YANG:
> 
>     list id-list {
>       key "id";
> 
>       leaf id {
>           type instance-identifier;
>       }
>     }
> 
> Data:
> 
> * /top/id-list[id="/top/list[idx='4']"]
> 
> * /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"]  * proposed errata is also in effect>
> 
> * 
> 
> Problem 2: The instance-identifier type lacks canonical form (which
> makes it the only data type with implementation dependent
> representation at the data level ... think of the integer types
> allowing optional spaces between the digits). This is in fact the only
> built-in data type that allows the server implementation to change the
> configuration data replacing double quotes with single or the other
> way around. Inserting white spaces where you did not have them when
> the configuration was submitted. You can not simply read a
> configuration and use fast data comparison without schema support just
> because of this type. This is useless flexibility for simple data
> type.
> 
> And this can be fixed if:
> 
> 1. white spaces in instance-identifiers are prohibited
> 
> 2. list key predicates are required in alphabetical order

Or perhaps use the order the keys are defined in the data model (the
"keys" statement").

> 3. strict quotation convention with escape option is added. (only
> 3. contradicts the sec. 9.13 ".. instance-identifier is a subset of
> the XPath ..")

I would like to change one more thing - I think it is unfortunate that
the lexical representation depends on the lexical context;
specifically that prefixes declared in the XML instance document is
used.  This applies also to identityref.  YANG 2.0 should use the same
encoding as JSON does for these datatypes.



/martin



> 
> Vladimir
> 
> On 10/21/2017 08:16 PM, Andy Bierman wrote:
> >
> >
> > On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise  > > wrote:
> >
> >     Dear all,
> >
> >     Shall I validate this one?
> >
> >
> >
> > To add more context, this relates to the the RESTCONF JSON vs. XML
> > discussions in the NETCONF WG.
> >
> >   leaf broken {
> >       type union {
> >         type int32;
> >         type string;
> >      }
> >   }
> >
> > If all values of key leaf "broken" are sent as strings in an
> > instance-identifier,
> > then the int32 value may not match in all implementations, instead of
> > the string.
> > Allowing numbers as literals in addition to quoted strings allows the
> > sender
> > to be specific, and all implementations to be consistent.
> >
> >
> >     Regards, Benoit
> >
> >
> >
> > Andy
> >
> >         The following errata report has been submitted for RFC7950,
> >         "The YANG 1.1 Data Modeling Language".
> >
> >         --------------------------------------
> >         You may review the report below and at:
> >         http://www.rfc-editor.org/errata/eid5157
> >         
> >
> >         --------------------------------------
> >         Type: Technical
> >         Reported by: Andy Bierman  >         >
> >
> >         Section: 14
> >
> >         Original Text
> >         -------------
> >            key-predicate-expr  = node-identifier *WSP "=" *WSP
> >         quoted-string
> >
> >         Corrected Text
> >         --------------
> >            key-predicate-expr  = node-identifier *WSP "=" *WSP
> >                  (quoted-string / integer-value / decimal-value)
> >
> >         Notes
> >         -----
> >         An instance identifier is forced to specify every key value to
> >         be a string
> >         even though the YANG key leaf type could be a numeric type.
> >         XPath does not require a quoted string here, just YANG.
> >
> >         Old:  /top/list[idx="4"]
> >         New: /top/list[idx=4]
> >
> >         Instructions:
> >         -------------
> >         This erratum is currently posted as "Reported". If necessary,
> >         please
> >         use "Reply All" to discuss whether it should be verified or
> >         rejected. When a decision is reached, the verifying party
> >         can log in to change the status and edit the report, if necessary.
> >
> >         --------------------------------------
> >         RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> >         --------------------------------------
> >         Title               : The YANG 1.1 Data Modeling Language
> >         Publication Date    : August 2016
> >         Author(s)           : M. Bjorklund, Ed.
> >         Category            : PROPOSED STANDARD
> >         Source              : NETCONF Data Modeling Language
> >         Area                : Operations and Management
> >         Stream              : IETF
> >         Verifying Party     : IESG
> >         .
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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 Oct 23 04:38:20 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF88B13F3C7 for ; Mon, 23 Oct 2017 04:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H432G7Jk_fUX for ; Mon, 23 Oct 2017 04:38:17 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 427D413F3C3 for ; Mon, 23 Oct 2017 04:38:17 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 41EDE1AE012C; Mon, 23 Oct 2017 13:38:16 +0200 (CEST)
Date: Mon, 23 Oct 2017 13:36:50 +0200 (CEST)
Message-Id: <20171023.133650.1291300163395090798.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <93844bdb-dcd9-758e-f58a-4cad047d4fd7@cisco.com> <20171023.123734.1274882060625273119.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] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 11:38:19 -0000

Ladislav Lhotka  wrote:
> 
> > On 23 Oct 2017, at 12:37, Martin Bjorklund  wrote:
> > 
> > Robert Wilton  wrote:
> >> 
> >> 
> >> On 23/10/2017 10:10, Martin Bjorklund wrote:
> >>> Andy Bierman  wrote:
> >>>> On Fri, Oct 20, 2017 at 9:24 AM, Robert Wilton 
> >>>> wrote:
> >>>> 
> >>>>> Hi Lada,
> >>>>> 
> >>>>> Thanks for the explanation, that makes sense.
> >>>>> 
> >>>>> 
> >>>>> On 20/10/2017 16:27, Ladislav Lhotka wrote:
> >>>>> 
> >>>>>> Hi Rob,
> >>>>>> 
> >>>>>> Robert Wilton  writes:
> >>>>>> 
> >>>>>> Hi,
> >>>>>>> XPATH 1.0 defines the following three node-type tests:
> >>>>>>> 
> >>>>>>> 1) comment()
> >>>>>>> 2) processing-instruction()
> >>>>>>> 3) text()
> >>>>>>> 
> >>>>>> For completeness, node() is the fourth one.
> >>>>>> 
> >>>>>> My assumption is that a YANG tree doesn't contain any nodes of type
> >>>>>>> 'comment' or 'processing-instruction' and hence these filters would
> >>>>>>> never match any nodes.
> >>>>>>> 
> >>>>>> Yes. FWIW, Yangson library raises NotSupported exception upon
> >>>>>> encountering these.
> >>>>>> 
> >>>> But a server or client should ignore PIs, not reject the XML.
> >>>> 
> >>>> I think text() and node() are just filter tests.
> >>>> 
> >>>>   /foo/*[text()] would return all the child nodes of /foo that are leaf
> >>>>   or
> >>>> leaf-list
> >>>> 
> >>>> text() returns a boolean (0 or 1).  Do not use it for value testing:
> >>> No.  text() will select the text node children of the context node.
> >> This is presumably because text() is evaluated as "child::text()".
> > 
> > Yes.
> > 
> >>>>   /foo/*[text() = 'fred']  // wrong!
> >>> This actually works.  text() selects all text nodes (just one for a
> >>> leaf), and then that text node is compared to the string 'fred'.
> >> For clarity, am I right in my interpretation that a leaf is not itself
> >> a text node, but instead a leaf is an element node that contains a
> >> direct child text node?
> > 
> > Yes.
> 
> In principle, there could be multiple text nodes

Do you mean for a YANG leaf?


/martin

> (in XML processing
> this is quite common).
> 
> Lada
> 
> > 
> >> Presumably, it is only leaf and leaf-list element nodes that can have
> >> these direct child text nodes.
> > 
> > Yes.
> > 
> >> I can see how this make sense for a XML document, but it does feel a
> >> bit non intuitive for a YANG data tree
> > 
> > Maybe, but since we use XPath, we need to conform to the data model
> > used by XPath (see section 5 of the xpath spec).
> > 
> >> and it may be helpful if this
> >> is documented somewhat ...
> > 
> > RFC 7950 refers to the data model of XPath (See section 6.4 of RFC
> > 7950), but I agree that it could have had more text.  Specifically, it
> > could have stated how nodes are mapped to elements, that only
> > leaf/leaf-list have text nodes; that annotations are mapped to
> > attribute nodes (ok, not really in 7950...); that there are no
> > processing-instruction and comment nodes.
> > 
> >> 
> >>  /foo/*[. = 'fred']  // correct
> >> 
> >> Presumably this test isn't quite the same, since child container and
> >> list nodes would also be included in the comparison (i.e. by
> >> concatenating all their descendant leaf values together into a single
> >> string)
> >> whereas the expression with the text() check will only
> >> include the values of direct child leaf and leaf-list nodes (as YANG
> >> is currently defined today).
> > 
> > Yes.
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > 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 Oct 23 04:52:51 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3894D13F3C1 for ; Mon, 23 Oct 2017 04:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbaARneS6d6U for ; Mon, 23 Oct 2017 04:52:48 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F12C13F3A5 for ; Mon, 23 Oct 2017 04:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2449; q=dns/txt; s=iport; t=1508759568; x=1509969168; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=uQyntP0+oJpOGOs7ywT5TRfytdAVbQwxwOfQwIYdyjQ=; b=PitIeICGxQhm9/kLJ8UmYa2ZyEToCV3iDLZTAOx1FvXynKOXB1akF+Hz 6FSqRy50eqJCQzrzVdAMSlNaUl/aq68bPjQNiLNhWODg4ZQq6hBL5k/RD gbPdwqzgu8KVCko4CiO51NV4w2fwC2e5wy0T2FsjrIk5IyNp003OvdSIr A=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.43,422,1503360000";  d="asc'?scan'208";a="658259217"
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; 23 Oct 2017 11:52:46 +0000
Received: from [10.61.78.84] (ams3-vpn-dhcp3668.cisco.com [10.61.78.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9NBqkrZ026539; Mon, 23 Oct 2017 11:52:46 GMT
To: Kent Watsen , "netmod@ietf.org" 
Cc: "agarwaso@cisco.com" 
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
From: Eliot Lear 
Message-ID: <0d7df5fd-4507-cde0-328e-0bc8a5448487@cisco.com>
Date: Mon, 23 Oct 2017 13:52:45 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gmg5HefMITovlUpIxjJP8O8770DvvdaeF"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 11:52:50 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gmg5HefMITovlUpIxjJP8O8770DvvdaeF
Content-Type: multipart/mixed; boundary="Q4V5IW8Vs5rmOgmiu5606njeXAQ5SboeN";
 protected-headers="v1"
From: Eliot Lear 
To: Kent Watsen , "netmod@ietf.org" 
Cc: "agarwaso@cisco.com" 
Message-ID: <0d7df5fd-4507-cde0-328e-0bc8a5448487@cisco.com>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
In-Reply-To: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>

--Q4V5IW8Vs5rmOgmiu5606njeXAQ5SboeN
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

I've reviewed this draft.=C2=A0 It is NOT perfect.=C2=A0 It *is* good eno=
ugh.=C2=A0
Please let's move it along.

Eliot


On 10/20/17 11:37 PM, Kent Watsen wrote:
> All,
>
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-14.
>
> The working group last call ends on November 3.
> 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.
>
> Could the authors, explicitly CC-ed on this email, please
> also confirm at this time that they are unaware of any=20
> IPR related to this draft.
>
> Thank you,
> Netmod Chairs
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



--Q4V5IW8Vs5rmOgmiu5606njeXAQ5SboeN--

--gmg5HefMITovlUpIxjJP8O8770DvvdaeF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ7dgNAAoJEIe2a0bZ0noz8hkIANGuDylQIa7dje+j/Q40sau4
4rQwm+9WSLUPqcWZMsRMpefWJRF956LlPfC+DXvmPptEcmKhYxqsxiy7N5Z3XUGZ
uvdo6NMmD4ylTMo+TIM/CT7suL2UvDTyQ/vyZ8LcHcxxPFVtEctNHhElcUGdKc0v
ZQ5GAnEYegv8EGCIYvD/gW4R64Bp7dzEJ/+5Khlvhu9ZL2drqtn6T9vOzNgRkOqw
IdZBUCk+WDkIr6UL9lL8bGwCzQTuSYGzdAvrOZPG/Y3bnODb5yFfKUK8Jm08QWem
F+hrrZtnzEvV40mLdHgpowG65HjJ6QpGUlWWfE0rluA1RYb+XJD6gQ7ChR0+RNI=
=t5iA
-----END PGP SIGNATURE-----

--gmg5HefMITovlUpIxjJP8O8770DvvdaeF--


From nobody Mon Oct 23 04:58:05 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8266913F3C9 for ; Mon, 23 Oct 2017 04:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV_NB1d-R7nT for ; Mon, 23 Oct 2017 04:57:58 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A557D13F3CA for ; Mon, 23 Oct 2017 04:57:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id ABFE41405A86; Mon, 23 Oct 2017 13:57:54 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id IkahAwcqP9m5; Mon, 23 Oct 2017 13:57:54 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7321D1405A88; Mon, 23 Oct 2017 13:57:54 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8iW35PGw-ahP; Mon, 23 Oct 2017 13:57:54 +0200 (CEST)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 3D5B91405A84; Mon, 23 Oct 2017 13:57:54 +0200 (CEST)
To: Martin Bjorklund 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>
Cc: andy@yumaworks.com, netmod@ietf.org
From: Vladimir Vassilev 
Message-ID: 
Date: Mon, 23 Oct 2017 13:57:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <20171023.133559.470792369996870413.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 11:58:03 -0000

On 10/23/2017 01:35 PM, Martin Bjorklund wrote:

> Vladimir Vassilev  wrote:
>> Hello,
>>
>> I would like to use the occasion of this Errata report to point out
>> some additional issues with the instance-identifier type definition.
>>
>> IMO the instance-identifier built-in type has 2 additional problems
>> that can be addressed with alternative and significantly more radical
>> errata or fixed in a new version of YANG.:
>>
>> Problem 1: The obvious limitation inherited from Xpath 1.0 - inability
>> to escape single or double quote characters. In Xpath world this
>> limitation is worked around by use of concat() which is not available
>> in the YANG 1.1 instance-identifier definition. 2 examples of this
>> limitation:
>>
>> 1. It is impossible to create value of type instance-identifier
>> referencing nodes in lists with key string values containing both a
>> single and a double quote characters e.g. ..."It's
>> valid string!".
>>
>> 2. Another example of the same problem would be a leaf of type
>> instance-identifier referencing another leaf of type
>> instance-identifier. With 2 references it works provided one is
>> encoded with single quotes and the other with double but it is
>> impossible to create third e.g.
>>
>> YANG:
>>
>>      list id-list {
>>        key "id";
>>
>>        leaf id {
>>            type instance-identifier;
>>        }
>>      }
>>
>> Data:
>>
>> * /top/id-list[id="/top/list[idx='4']"]
>>
>> * /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"] > * proposed errata is also in effect>
>>
>> * 
>>
>> Problem 2: The instance-identifier type lacks canonical form (which
>> makes it the only data type with implementation dependent
>> representation at the data level ... think of the integer types
>> allowing optional spaces between the digits). This is in fact the only
>> built-in data type that allows the server implementation to change the
>> configuration data replacing double quotes with single or the other
>> way around. Inserting white spaces where you did not have them when
>> the configuration was submitted. You can not simply read a
>> configuration and use fast data comparison without schema support just
>> because of this type. This is useless flexibility for simple data
>> type.
>>
>> And this can be fixed if:
>>
>> 1. white spaces in instance-identifiers are prohibited
>>
>> 2. list key predicates are required in alphabetical order
> Or perhaps use the order the keys are defined in the data model (the
> "keys" statement").
This is an option but then the e.g. xpath2instid() function 
implementations will need schema support.

Vladimir
>
>> 3. strict quotation convention with escape option is added. (only
>> 3. contradicts the sec. 9.13 ".. instance-identifier is a subset of
>> the XPath ..")
> I would like to change one more thing - I think it is unfortunate that
> the lexical representation depends on the lexical context;
> specifically that prefixes declared in the XML instance document is
> used.  This applies also to identityref.  YANG 2.0 should use the same
> encoding as JSON does for these datatypes.
>
>
>
> /martin
>
>
>
>> Vladimir
>>
>> On 10/21/2017 08:16 PM, Andy Bierman wrote:
>>>
>>> On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise >> > wrote:
>>>
>>>      Dear all,
>>>
>>>      Shall I validate this one?
>>>
>>>
>>>
>>> To add more context, this relates to the the RESTCONF JSON vs. XML
>>> discussions in the NETCONF WG.
>>>
>>>    leaf broken {
>>>        type union {
>>>          type int32;
>>>          type string;
>>>       }
>>>    }
>>>
>>> If all values of key leaf "broken" are sent as strings in an
>>> instance-identifier,
>>> then the int32 value may not match in all implementations, instead of
>>> the string.
>>> Allowing numbers as literals in addition to quoted strings allows the
>>> sender
>>> to be specific, and all implementations to be consistent.
>>>
>>>
>>>      Regards, Benoit
>>>
>>>
>>>
>>> Andy
>>>
>>>          The following errata report has been submitted for RFC7950,
>>>          "The YANG 1.1 Data Modeling Language".
>>>
>>>          --------------------------------------
>>>          You may review the report below and at:
>>>          http://www.rfc-editor.org/errata/eid5157
>>>          
>>>
>>>          --------------------------------------
>>>          Type: Technical
>>>          Reported by: Andy Bierman >>          >
>>>
>>>          Section: 14
>>>
>>>          Original Text
>>>          -------------
>>>             key-predicate-expr  = node-identifier *WSP "=" *WSP
>>>          quoted-string
>>>
>>>          Corrected Text
>>>          --------------
>>>             key-predicate-expr  = node-identifier *WSP "=" *WSP
>>>                   (quoted-string / integer-value / decimal-value)
>>>
>>>          Notes
>>>          -----
>>>          An instance identifier is forced to specify every key value to
>>>          be a string
>>>          even though the YANG key leaf type could be a numeric type.
>>>          XPath does not require a quoted string here, just YANG.
>>>
>>>          Old:  /top/list[idx="4"]
>>>          New: /top/list[idx=4]
>>>
>>>          Instructions:
>>>          -------------
>>>          This erratum is currently posted as "Reported". If necessary,
>>>          please
>>>          use "Reply All" to discuss whether it should be verified or
>>>          rejected. When a decision is reached, the verifying party
>>>          can log in to change the status and edit the report, if necessary.
>>>
>>>          --------------------------------------
>>>          RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>>>          --------------------------------------
>>>          Title               : The YANG 1.1 Data Modeling Language
>>>          Publication Date    : August 2016
>>>          Author(s)           : M. Bjorklund, Ed.
>>>          Category            : PROPOSED STANDARD
>>>          Source              : NETCONF Data Modeling Language
>>>          Area                : Operations and Management
>>>          Stream              : IETF
>>>          Verifying Party     : IESG
>>>          .
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Oct 23 05:59:05 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B87913F4D7 for ; Mon, 23 Oct 2017 05:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 a3DB_TV80NrY for ; Mon, 23 Oct 2017 05:59:01 -0700 (PDT)
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 DFB3B13F5B8 for ; Mon, 23 Oct 2017 05:56:29 -0700 (PDT)
Received: from birdie44 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 0A1CB61CF9 for ; Mon, 23 Oct 2017 14:56:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1508763388; bh=gXDZZzHin9sNZ5r9XIso5DHxFNOD7x/fwUAVzeSKYEI=; h=From:To:Date; b=p0TKNf+tiV1siqrVHAE7AD+NRcik8UzWrK+146zN8fsF6Mc5eYub7phEzrYHBWsTr QfnwMM6OGp6iBmM2Y8CRI7k2AWKDzr9pzIsP5OlaQHO+2Xwu9P2dILnonykQlSquPC O+umbe8Y+0i47BtMfnxJnvTP4fpmy94dhcSThdXQ=
Message-ID: <1508763445.18248.13.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Mon, 23 Oct 2017 14:57:25 +0200
In-Reply-To: <20171023.103513.1336510497564838401.mbj@tail-f.com>
References: <20171016190431.5FA26B80E0F@rfc-editor.org> <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com> <20171023.103513.1336510497564838401.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.1 
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] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 12:59:03 -0000

On Mon, 2017-10-23 at 10:35 +0200, Martin Bjorklund wrote:
> Benoit Claise  wrote:
> > Dear all,
> > 
> > Shall I validate this one?
> 
> No I don't think this is correct.  We choose a quoted string to be
> able to correctly represent all YANG integer and decimal64 values.
> Note that XPath doesn't have integers, just 64-bit floats.  This means
> that not all 64-bit integers can be expressed as numbers in XPath.

I agree this would be a change in the spec, not an erratum. On the other hand,
it would be possible to use the JSON representation of scalar values as defined
in RFC 7951, which addresses the problems with 64-bit numbers.

Lada

> 
> 
> /martin
> 
> 
> > 
> > Regards, Benoit
> > > The following errata report has been submitted for RFC7950,
> > > "The YANG 1.1 Data Modeling Language".
> > > 
> > > --------------------------------------
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata/eid5157
> > > 
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Andy Bierman 
> > > 
> > > Section: 14
> > > 
> > > Original Text
> > > -------------
> > >    key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string
> > > 
> > > Corrected Text
> > > --------------
> > >    key-predicate-expr  = node-identifier *WSP "=" *WSP
> > >          (quoted-string / integer-value / decimal-value)
> > > 
> > > Notes
> > > -----
> > > An instance identifier is forced to specify every key value to be a
> > > string
> > > even though the YANG key leaf type could be a numeric type.
> > > XPath does not require a quoted string here, just YANG.
> > > 
> > > Old:  /top/list[idx="4"]
> > > New: /top/list[idx=4]
> > > 
> > > Instructions:
> > > -------------
> > > This erratum is currently posted as "Reported". If necessary, please
> > > use "Reply All" to discuss whether it should be verified or
> > > rejected. When a decision is reached, the verifying party
> > > can log in to change the status and edit the report, if necessary.
> > > 
> > > --------------------------------------
> > > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > > --------------------------------------
> > > Title               : The YANG 1.1 Data Modeling Language
> > > Publication Date    : August 2016
> > > Author(s)           : M. Bjorklund, Ed.
> > > Category            : PROPOSED STANDARD
> > > Source              : NETCONF Data Modeling Language
> > > Area                : Operations and Management
> > > Stream              : IETF
> > > Verifying Party     : IESG
> > > .
> > > 
> 
> _______________________________________________
> 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 Oct 23 07:26:39 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995CD1389A0 for ; Mon, 23 Oct 2017 07:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 p5FVS7IRUTEH for ; Mon, 23 Oct 2017 07:26:36 -0700 (PDT)
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 3E8F7138F9C for ; Mon, 23 Oct 2017 07:26:36 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id b190so20321585lfg.9 for ; Mon, 23 Oct 2017 07:26:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vQOy/Xe/mbrnDHzBaCOaxe2OzdUNQIxvbJ5VA5CQccI=; b=0d1eyj7NuScHwc6gciBxIyqHQqgeXMRu+Z48rlS/udIfDZmEqEDtNJsEgRACaFbDyY WsqTUnpriwKhE1lSCDC94BJwK29DSqXzyLJ3NH2ZgIkbLBJddRV4bn9gjjBnMMNLqMhG 0OB55ZL65NQFchrF2wi4d/rji26+YPjcwiE02brQrNbALcrpvUwPzSre+KD7zg0dbeCl PBuJ5wIULGRzlDZGr6cjFcc2ljND/aWYqe0odsjHF5w0kAUhJhu0t2I1KZAmFbBDQsj/ zIVT6WReoQ32qbszxWsXvyZgea/594kOkqNKGmTPztIibeLxYDVdJMol3Z04N3Ey6Te2 KkZA==
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=vQOy/Xe/mbrnDHzBaCOaxe2OzdUNQIxvbJ5VA5CQccI=; b=CHkelObMSDBkOEf2MbxVtI3ojbw1+dkUP55gqc4Cg/MULnJ0sGOtd9wDBxeecR7fOB dfSWs68dSLp9E0Fim0/+bWcX3fPWm4oUzn2rBIHOrPigndYP5R+cfqG/Rym3t2YFi2vs 4Ora1aSuEF4UmtbI5DrgqLsLgACIrio0eQX9cXOdz2QEizsCJQ9Tv2eBYx5HStpY1z0r RucxgtcNQl9IprS0abbjtSldWiDwKFjgBlRBY+/ZQ0BCC2forjq9IwdWhvu5TPCWdggO rjkiJeI1BKUbmumHLfxhJB7r1vnzHXdGf5JmG0NkEkEWRsQec/tLN6A7zLlL699RX/2c gUHg==
X-Gm-Message-State: AMCzsaXU9aeBqVXrRj3IgopjvXcNktuWUnKZXz14tJui7VaAzeBegHIS 7eRxSaHEkD8f7nSvLh3z1VBRyXFXAhoyG4totNXdlQ==
X-Google-Smtp-Source: ABhQp+TQvMaEdK+vRWqKvPsr9LUqN1rKZn3sOvHpANdkAgpnCNetQ95fIy1m3hb5ZCz0850ObirrjaPr/I/YkZW/VYo=
X-Received: by 10.25.22.194 with SMTP id 63mr4436300lfw.205.1508768794447; Mon, 23 Oct 2017 07:26:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Mon, 23 Oct 2017 07:26:33 -0700 (PDT)
In-Reply-To: <20171023.103513.1336510497564838401.mbj@tail-f.com>
References: <20171016190431.5FA26B80E0F@rfc-editor.org> <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com> <20171023.103513.1336510497564838401.mbj@tail-f.com>
From: Andy Bierman 
Date: Mon, 23 Oct 2017 07:26:33 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Benoit Claise , Warren Kumari ,  Kent Watsen , Berger Lou ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f20920aa0b9055c379c75"
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 14:26:38 -0000

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

On Mon, Oct 23, 2017 at 1:35 AM, Martin Bjorklund  wrote:

> Benoit Claise  wrote:
> > Dear all,
> >
> > Shall I validate this one?
>
> No I don't think this is correct.  We choose a quoted string to be
> able to correctly represent all YANG integer and decimal64 values.
> Note that XPath doesn't have integers, just 64-bit floats.  This means
> that not all 64-bit integers can be expressed as numbers in XPath.
>
>
It's OK to leave this out since it requires a code change.


Read sec. 2.3 again:

The node test text() is true for any text node.




>
> /martin
>
>

Andy


>
> >
> > Regards, Benoit
> > > The following errata report has been submitted for RFC7950,
> > > "The YANG 1.1 Data Modeling Language".
> > >
> > > --------------------------------------
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata/eid5157
> > >
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Andy Bierman 
> > >
> > > Section: 14
> > >
> > > Original Text
> > > -------------
> > >    key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string
> > >
> > > Corrected Text
> > > --------------
> > >    key-predicate-expr  = node-identifier *WSP "=" *WSP
> > >          (quoted-string / integer-value / decimal-value)
> > >
> > > Notes
> > > -----
> > > An instance identifier is forced to specify every key value to be a
> > > string
> > > even though the YANG key leaf type could be a numeric type.
> > > XPath does not require a quoted string here, just YANG.
> > >
> > > Old:  /top/list[idx="4"]
> > > New: /top/list[idx=4]
> > >
> > > Instructions:
> > > -------------
> > > This erratum is currently posted as "Reported". If necessary, please
> > > use "Reply All" to discuss whether it should be verified or
> > > rejected. When a decision is reached, the verifying party
> > > can log in to change the status and edit the report, if necessary.
> > >
> > > --------------------------------------
> > > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > > --------------------------------------
> > > Title               : The YANG 1.1 Data Modeling Language
> > > Publication Date    : August 2016
> > > Author(s)           : M. Bjorklund, Ed.
> > > Category            : PROPOSED STANDARD
> > > Source              : NETCONF Data Modeling Language
> > > Area                : Operations and Management
> > > Stream              : IETF
> > > Verifying Party     : IESG
> > > .
> > >
> >
>

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




On Mon, Oct 23, 2017 at 1:35 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Benoit =
Claise <bclaise@cisco.com> w=
rote:

> Dear all,

>

> Shall I validate this one?



No I don't think this is correct.=C2=A0 We choose a quoted string to be=


able to correctly represent all YANG integer and decimal64 values.

Note that XPath doesn't have integers, just 64-bit floats.=C2=A0 This m=
eans

that not all 64-bit integers can be expressed as numbers in XPath.



It's OK to leave this out since it=
 requires a code change.


Read sec. =
2.3 again:

The node test=C2=A0text()=C2=A0is true for any text node.
<=
div>

=C2=A0



/martin




Andy
=C2=A0



>

> Regards, Benoit

> > The following errata report has been submitted for RFC7950,

> > "The YANG 1.1 Data Modeling Language".

> >

> > --------------------------------------

> > You may review the report below and at:

> > http://www.rfc-editor.org/errata/eid5157<=
br>
> >

> > --------------------------------------

> > Type: Technical

> > Reported by: Andy Bierman <andy@yumaworks.com>

> >

> > Section: 14

> >

> > Original Text

> > -------------

> >=C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node-identifier *WSP &q=
uot;=3D" *WSP quoted-string

> >

> > Corrected Text

> > --------------

> >=C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node-identifier *WSP &q=
uot;=3D" *WSP

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (quoted-string / integer-value =
/ decimal-value)

> >

> > Notes

> > -----

> > An instance identifier is forced to specify every key value to be=
 a

> > string

> > even though the YANG key leaf type could be a numeric type.

> > XPath does not require a quoted string here, just YANG.

> >

> > Old:=C2=A0 /top/list[idx=3D"4"]

> > New: /top/list[idx=3D4]

> >

> > Instructions:

> > -------------

> > This erratum is currently posted as "Reported". If nece=
ssary, please

> > use "Reply All" to discuss whether it should be verifie=
d or

> > rejected. When a decision is reached, the verifying party

> > can log in to change the status and edit the report, if necessary=
.

> >

> > --------------------------------------

> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)

> > --------------------------------------

> > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The=
 YANG 1.1 Data Modeling Language

> > Publication Date=C2=A0 =C2=A0 : August 2016

> > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bjorklund,=
 Ed.

> > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STAN=
DARD

> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : NETCONF =
Data Modeling Language

> > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Ope=
rations and Management

> > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF

> > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

> > .

> >

>





--001a113f20920aa0b9055c379c75--


From nobody Mon Oct 23 07:32:12 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F2313EF48 for ; Mon, 23 Oct 2017 07:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tafiBc4VJHi for ; Mon, 23 Oct 2017 07:32:06 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5D40C138BB5 for ; Mon, 23 Oct 2017 07:32:06 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 283341AE012C; Mon, 23 Oct 2017 16:32:05 +0200 (CEST)
Date: Mon, 23 Oct 2017 16:30:39 +0200 (CEST)
Message-Id: <20171023.163039.1034668943501669872.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: bclaise@cisco.com, warren@kumari.net, kwatsen@juniper.net, lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com> <20171023.103513.1336510497564838401.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] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 14:32:11 -0000

Andy Bierman  wrote:
> On Mon, Oct 23, 2017 at 1:35 AM, Martin Bjorklund  wrote:
> 
> > Benoit Claise  wrote:
> > > Dear all,
> > >
> > > Shall I validate this one?
> >
> > No I don't think this is correct.  We choose a quoted string to be
> > able to correctly represent all YANG integer and decimal64 values.
> > Note that XPath doesn't have integers, just 64-bit floats.  This means
> > that not all 64-bit integers can be expressed as numbers in XPath.
> >
> >
> It's OK to leave this out since it requires a code change.
> 
> 
> Read sec. 2.3 again:

Wrong thread?

> The node test text() is true for any text node.

Sure, but a node test is not a predicate!


/martin



> 
> 
> 
> 
> >
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> > >
> > > Regards, Benoit
> > > > The following errata report has been submitted for RFC7950,
> > > > "The YANG 1.1 Data Modeling Language".
> > > >
> > > > --------------------------------------
> > > > You may review the report below and at:
> > > > http://www.rfc-editor.org/errata/eid5157
> > > >
> > > > --------------------------------------
> > > > Type: Technical
> > > > Reported by: Andy Bierman 
> > > >
> > > > Section: 14
> > > >
> > > > Original Text
> > > > -------------
> > > >    key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string
> > > >
> > > > Corrected Text
> > > > --------------
> > > >    key-predicate-expr  = node-identifier *WSP "=" *WSP
> > > >          (quoted-string / integer-value / decimal-value)
> > > >
> > > > Notes
> > > > -----
> > > > An instance identifier is forced to specify every key value to be a
> > > > string
> > > > even though the YANG key leaf type could be a numeric type.
> > > > XPath does not require a quoted string here, just YANG.
> > > >
> > > > Old:  /top/list[idx="4"]
> > > > New: /top/list[idx=4]
> > > >
> > > > Instructions:
> > > > -------------
> > > > This erratum is currently posted as "Reported". If necessary, please
> > > > use "Reply All" to discuss whether it should be verified or
> > > > rejected. When a decision is reached, the verifying party
> > > > can log in to change the status and edit the report, if necessary.
> > > >
> > > > --------------------------------------
> > > > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > > > --------------------------------------
> > > > Title               : The YANG 1.1 Data Modeling Language
> > > > Publication Date    : August 2016
> > > > Author(s)           : M. Bjorklund, Ed.
> > > > Category            : PROPOSED STANDARD
> > > > Source              : NETCONF Data Modeling Language
> > > > Area                : Operations and Management
> > > > Stream              : IETF
> > > > Verifying Party     : IESG
> > > > .
> > > >
> > >
> >


From nobody Mon Oct 23 08:22:06 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15D8139428 for ; Mon, 23 Oct 2017 08:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq3GSi30Cqg9 for ; Mon, 23 Oct 2017 08:22:01 -0700 (PDT)
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 45757139432 for ; Mon, 23 Oct 2017 08:22:01 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id a69so20572669lfe.5 for ; Mon, 23 Oct 2017 08:22:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPBpqutwShsFjcjPx3jQy3C3GHG7mQaRaaBcl2kn/tY=; b=IrygZh4gggOxKfn9pm7NdcrwdQxumue/cTDbbHahpxVy/Nr2hyTmwlKjGGDIy339nc S+ClsRDp+hCgFOWcstysMefsijplzP2SAwKmgPPxQVbN746w/JKJ0QdEUiFncc/izraX 4gsT24SuFgfnNMlq01JMcY+gQQZlBwi8knH8BKZ3U4ILDJUAuNWxHdE5DKkgeSZAttMk 2sLz9s9tCelZBj29o6M3YBfoHsMz2a0ggbVybri26ygT5xw9PSJBrpD53PGxmCX11pQH Gnuxf+AlSDe0P+rciJ6CYLTIqXIryIBTTOsytO52ryf1QWCoLMqjiF49gK6aG/2AufhT A4JQ==
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=kPBpqutwShsFjcjPx3jQy3C3GHG7mQaRaaBcl2kn/tY=; b=aFxR1C/fD8FAih1s+ZM4zCsQMiHFDQUt5QERUPPC7+6nFWkNxuuyjlZLqcMy+xkm/p zqvvOcXhi3bpBQUcVGXhsy27+Bf4bHv44M6HVnxCh+PsZ04OWZersO98z8QRslt0YLSO 14/0pyHfnuQkQHrybvnCqnsdp7NCajynh/QH055QqJUdM9UBnzolPG7i5dP6VagUSOzw NPoksfBHF5YBn2UGqZpjC7oFpJEKm2bCsd5UfvJV5skqvXQdM3iETEeYAhZzkIhtHHg3 rK+ja4YoNQc9Kk6J/3QV7IuajonLkyQT+0SvtzkSukdSGmr5R8rUwbuyUuG0udO3RRDo eKgw==
X-Gm-Message-State: AMCzsaXoqaNi7RWJh7eIhtOq8zTlEQ4fZ4b2wlG+cVhghEHRForDPXpg l1JM+QzgUSY6qVP1/jY5IYBMI8RGhNdFA5JFHh0WEg==
X-Google-Smtp-Source: ABhQp+RVOwfeRvmoo34of3fBWKsecSwdIpeO3R9vMAqGVuCZTbR8zI85Gft/QKkM/UP4OX17A0gzpXwWWuRBZhnYpLU=
X-Received: by 10.46.85.136 with SMTP id g8mr5251851lje.84.1508772119408; Mon, 23 Oct 2017 08:21:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Mon, 23 Oct 2017 08:21:58 -0700 (PDT)
In-Reply-To: <20171023.163039.1034668943501669872.mbj@tail-f.com>
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com> <20171023.103513.1336510497564838401.mbj@tail-f.com>  <20171023.163039.1034668943501669872.mbj@tail-f.com>
From: Andy Bierman 
Date: Mon, 23 Oct 2017 08:21:58 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Benoit Claise , Warren Kumari ,  Kent Watsen , Berger Lou ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1cdc4439b60d055c386258"
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 15:22:04 -0000

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

On Mon, Oct 23, 2017 at 7:30 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Mon, Oct 23, 2017 at 1:35 AM, Martin Bjorklund 
> wrote:
> >
> > > Benoit Claise  wrote:
> > > > Dear all,
> > > >
> > > > Shall I validate this one?
> > >
> > > No I don't think this is correct.  We choose a quoted string to be
> > > able to correctly represent all YANG integer and decimal64 values.
> > > Note that XPath doesn't have integers, just 64-bit floats.  This means
> > > that not all 64-bit integers can be expressed as numbers in XPath.
> > >
> > >
> > It's OK to leave this out since it requires a code change.
> >
> >
> > Read sec. 2.3 again:
>
> Wrong thread?
>

No -- customers who know XPath report this YANG-ism as a bug.
It would require 2 lines of code to be changed in our code to accept
numbers.
I don't think an errata should require a code change.


>
> > The node test text() is true for any text node.
>
> Sure, but a node test is not a predicate!
>

But it returns true/false, not a node-set.
The expression /foo[text() = 'fred'] is not the same as /foo[. = 'fred']



>
>
> /martin
>
>
Andy


>
>
> >
> >
> >
> >
> > >
> > > /martin
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > > >
> > > > Regards, Benoit
> > > > > The following errata report has been submitted for RFC7950,
> > > > > "The YANG 1.1 Data Modeling Language".
> > > > >
> > > > > --------------------------------------
> > > > > You may review the report below and at:
> > > > > http://www.rfc-editor.org/errata/eid5157
> > > > >
> > > > > --------------------------------------
> > > > > Type: Technical
> > > > > Reported by: Andy Bierman 
> > > > >
> > > > > Section: 14
> > > > >
> > > > > Original Text
> > > > > -------------
> > > > >    key-predicate-expr  = node-identifier *WSP "=" *WSP
> quoted-string
> > > > >
> > > > > Corrected Text
> > > > > --------------
> > > > >    key-predicate-expr  = node-identifier *WSP "=" *WSP
> > > > >          (quoted-string / integer-value / decimal-value)
> > > > >
> > > > > Notes
> > > > > -----
> > > > > An instance identifier is forced to specify every key value to be a
> > > > > string
> > > > > even though the YANG key leaf type could be a numeric type.
> > > > > XPath does not require a quoted string here, just YANG.
> > > > >
> > > > > Old:  /top/list[idx="4"]
> > > > > New: /top/list[idx=4]
> > > > >
> > > > > Instructions:
> > > > > -------------
> > > > > This erratum is currently posted as "Reported". If necessary,
> please
> > > > > use "Reply All" to discuss whether it should be verified or
> > > > > rejected. When a decision is reached, the verifying party
> > > > > can log in to change the status and edit the report, if necessary.
> > > > >
> > > > > --------------------------------------
> > > > > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > > > > --------------------------------------
> > > > > Title               : The YANG 1.1 Data Modeling Language
> > > > > Publication Date    : August 2016
> > > > > Author(s)           : M. Bjorklund, Ed.
> > > > > Category            : PROPOSED STANDARD
> > > > > Source              : NETCONF Data Modeling Language
> > > > > Area                : Operations and Management
> > > > > Stream              : IETF
> > > > > Verifying Party     : IESG
> > > > > .
> > > > >
> > > >
> > >
>

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




On Mon, Oct 23, 2017 at 7:30 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Mon, Oct 23, 2017 at 1:35 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Benoit Claise <bclaise@ci=
sco.com> wrote:

> > > Dear all,

> > >

> > > Shall I validate this one?

> >

> > No I don't think this is correct.=C2=A0 We choose a quoted st=
ring to be

> > able to correctly represent all YANG integer and decimal64 values=
.

> > Note that XPath doesn't have integers, just 64-bit floats.=C2=
=A0 This means

> > that not all 64-bit integers can be expressed as numbers in XPath=
.

> >

> >

> It's OK to leave this out since it requires a code change.

>

>

> Read sec. 2.3 again:



Wrong thread?

No -- customers who know =
XPath report this YANG-ism as a bug.
It would require 2 lines of =
code to be changed in our code to accept numbers.
I don't thi=
nk an errata should require a code change.
=C2=A0



> The node test text() is true for any text node.



Sure, but a node test is not a predicate!

But it returns true/false, not a node-set.
The expression /foo=
[text() =3D 'fred'] is not the same as /foo[. =3D 'fred']

=C2=A0





/martin



Andy
=C2=A0





>

>

>

>

> >

> > /martin

> >

> >

>

> Andy

>

>

> >

> > >

> > > Regards, Benoit

> > > > The following errata report has been submitted for RFC7=
950,

> > > > "The YANG 1.1 Data Modeling Language".

> > > >

> > > > --------------------------------------

> > > > You may review the report below and at:

> > > > http://www.rfc-editor.org/errata/ei=
d5157

> > > >

> > > > --------------------------------------

> > > > Type: Technical

> > > > Reported by: Andy Bierman <andy@yumaworks.com>

> > > >

> > > > Section: 14

> > > >

> > > > Original Text

> > > > -------------

> > > >=C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node-identifi=
er *WSP "=3D" *WSP quoted-string

> > > >

> > > > Corrected Text

> > > > --------------

> > > >=C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node-identifi=
er *WSP "=3D" *WSP

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (quoted-string / inte=
ger-value / decimal-value)

> > > >

> > > > Notes

> > > > -----

> > > > An instance identifier is forced to specify every key v=
alue to be a

> > > > string

> > > > even though the YANG key leaf type could be a numeric t=
ype.

> > > > XPath does not require a quoted string here, just YANG.=


> > > >

> > > > Old:=C2=A0 /top/list[idx=3D"4"]

> > > > New: /top/list[idx=3D4]

> > > >

> > > > Instructions:

> > > > -------------

> > > > This erratum is currently posted as "Reported"=
;. If necessary, please

> > > > use "Reply All" to discuss whether it should =
be verified or

> > > > rejected. When a decision is reached, the verifying par=
ty

> > > > can log in to change the status and edit the report, if=
 necessary.

> > > >

> > > > --------------------------------------

> > > > RFC7950 (draft-ietf-netmod-rfc6020bis-14)

> > > > --------------------------------------

> > > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0: The YANG 1.1 Data Modeling Language

> > > > Publication Date=C2=A0 =C2=A0 : August 2016

> > > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. =
Bjorklund, Ed.

> > > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PRO=
POSED STANDARD

> > > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
: NETCONF Data Modeling Language

> > > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 : Operations and Management

> > > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
: IETF

> > > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

> > > > .

> > > >

> > >

> >





--94eb2c1cdc4439b60d055c386258--


From nobody Mon Oct 23 09:35:49 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEBA139561 for ; Mon, 23 Oct 2017 09:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 P69GuJqOSfSK for ; Mon, 23 Oct 2017 09:35:46 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0133.outbound.protection.outlook.com [104.47.42.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F352113955E for ; Mon, 23 Oct 2017 09:35:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KCt7bicF8M1jfgazu4M56YIqqs2+BWgSKqNZnsFsKqg=; b=hhNrftiaIqXm1RyIUudmJyTwYhZy670x3kWEYJhoX1ytSTl4VM6P6d+HxMk6kFGnSAPFu3SutD0vrf3qns66td7yN6JuM47vxyl9xrPuPAvJIpDkTYiigmFISP7k1LwynFcM8pWMgc6Sr28C7w3xMEI89misV65teCh4d0y/+tw=
Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 16:35:45 +0000
Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497%14]) with mapi id 15.20.0178.003; Mon, 23 Oct 2017 16:35:44 +0000
From: Kent Watsen 
To: Eliot Lear , "netmod@ietf.org" 
CC: "agarwaso@cisco.com" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
Thread-Index: AQHTSeuS4R9mVwyDOkCxkCX5K2HeVqLxVwmAgAAMBwA=
Date: Mon, 23 Oct 2017 16:35:44 +0000
Message-ID: <203D24AF-6876-4B74-8C1C-8CE3CBA10E0D@juniper.net>
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <0d7df5fd-4507-cde0-328e-0bc8a5448487@cisco.com>
In-Reply-To: <0d7df5fd-4507-cde0-328e-0bc8a5448487@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN1PR05MB280; 6:5/DNfa3SQkzpn40V3Nt5FrlqtvuENlDfvZzmzZd8T/VZz0cH9sBJrNVY9IRCXnGcOA6WXv+hJaK+AQNxrWNyeo6g6/4Zdjwt+j08tRHkxcBQN2WcNLrRahEP/uHk/M581wFexAzrmOFZl9MTCqHOuTD+aFzyw2B4LXtKEuoz7RPZ6Mwbjr0FG30oNxbzWYUgHVFWIsnoOkJh9Tv112O2Fw4MUI3mnnt0Uba+INT2iRfBsa3trEO23jffaJR7f6B6zEkjFGG776/vy23eKtSi5mT8pJYW2uUEDC3soqOC+eOEWALdGiC91Mr7uAR2GfCbACJE11xxpnz8S0rjDca/HX2Yj2+EEGPVnsQXnmomI/k=; 5:oZ6++FEhCv1BcpLXhcL3QHkYQuvF5Z4djRxz/+CDZLBrYD7uraaC0LzC5qUqMtS5e5Pc1eoMNkTD644MwfwhnNhjdm1mfHZVY0agJdP4GEGs9ESIqgYgwRhxCFtp3kPOm7lfgySgfgAmQyXLeAEdC4Cadeddya91jy8CEO2WnNk=; 24:w0dA6pmbKWiK807s/+9F24ABzDO6kQDrUbXSCjJmIDZ5qo/ARCFnZtRWS3wtHGgJ88q5Ta4vCIX8H0eLfZ+vuxWdJXx56SeQfmM3HZtKktw=; 7:SBAyLJkm2hpuRcAhOdTAAt3iCWYYA+z+pLouy4EfxjVMg4E5zzjFtf/noCPS7jX4FD1aLiXjA8D1XfUFDLQ2OEHZG26oJngW1KxtJ1OwAmQbrvQ3WlFetkYxPdcEicgNSkQOElBc1Q+gG8mfSL2/vdZ+DHtcr5fs9rI9FqLPxcF/U6v0q/qYE0LLA76y2KZCDvXJzW+q2bmptQwpaieChNolBwjc4ejYdgrWVf9/fWXr1QO+oNpZ1U36qgT6qmkZ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 7a05a584-9fe8-4470-bbae-08d51a341bcc
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN1PR05MB280; 
x-ms-traffictypediagnostic: BN1PR05MB280:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB280; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB280; 
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(24454002)(189002)(199003)(5660300001)(478600001)(68736007)(101416001)(230783001)(2900100001)(50986999)(76176999)(54356999)(8936002)(2906002)(14454004)(8676002)(966005)(3660700001)(81166006)(53546010)(81156014)(106356001)(105586002)(3280700002)(33656002)(36756003)(82746002)(316002)(189998001)(6306002)(6512007)(99286003)(7736002)(110136005)(5250100002)(53936002)(58126008)(6246003)(305945005)(229853002)(83716003)(6486002)(6436002)(6506006)(97736004)(83506002)(66066001)(102836003)(4326008)(86362001)(2950100002)(3846002)(6116002)(2501003)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB280; H:BN1PR05MB280.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a05a584-9fe8-4470-bbae-08d51a341bcc
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 16:35:44.9348 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB280
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 16:35:48 -0000

VGhhbmtzIEVsbGlvdC4NCg0KQ2FuIHlvdSBzYXkgc29tZSBtb3JlIGFib3V0IHdoYXQncyBub3Qg
cGVyZmVjdCBhYm91dCBpdD8NCg0KS2VudCAgLy8gc2hlcGhlcmQNCg0KDQotLQ0KDQpJJ3ZlIHJl
dmlld2VkIHRoaXMgZHJhZnQuICBJdCBpcyBOT1QgcGVyZmVjdC4gIEl0ICppcyogZ29vZCBlbm91
Z2guIA0KUGxlYXNlIGxldCdzIG1vdmUgaXQgYWxvbmcuDQoNCkVsaW90DQoNCg0KT24gMTAvMjAv
MTcgMTE6MzcgUE0sIEtlbnQgV2F0c2VuIHdyb3RlOg0KPiBBbGwsDQo+DQo+IFRoaXMgc3RhcnRz
IGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj4gZHJhZnQtaWV0Zi1uZXRt
b2QtYWNsLW1vZGVsLTE0Lg0KPg0KPiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBv
biBOb3ZlbWJlciAzLg0KPiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBuZXRtb2Qg
bWFpbGluZyBsaXN0Lg0KPg0KPiBQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3
ZWQgdGhpcyBkb2N1bWVudA0KPiBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRp
b24iLCBhcmUgd2VsY29tZSENCj4gVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBm
cm9tIGF1dGhvcnMuDQo+DQo+IENvdWxkIHRoZSBhdXRob3JzLCBleHBsaWNpdGx5IENDLWVkIG9u
IHRoaXMgZW1haWwsIHBsZWFzZQ0KPiBhbHNvIGNvbmZpcm0gYXQgdGhpcyB0aW1lIHRoYXQgdGhl
eSBhcmUgdW5hd2FyZSBvZiBhbnkgDQo+IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQo+DQo+
IFRoYW5rIHlvdSwNCj4gTmV0bW9kIENoYWlycw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5l
dG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KPg0KDQoNCg0KDQo=


From nobody Mon Oct 23 10:14:51 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C53138A38; Mon, 23 Oct 2017 10:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8KXbpLC1h7C; Mon, 23 Oct 2017 10:14:48 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262F81380DB; Mon, 23 Oct 2017 10:14:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10533; q=dns/txt; s=iport; t=1508778888; x=1509988488; h=from:to:subject:date:message-id:mime-version; bh=HLwalDL4LFx073ZoeSm5L+M2+LC/uyF0gYN/FMCDuz4=; b=fATqRhDOTRRdbXK134Mlxd7xeogzaTYVSvDnOqNavor1VmSad3uWXxj+ XxHACN8UGhNcCNm+wJ8KEY6FLBGvKjNGa0bPr8Ov1qDuWdGjnX16cEWa4 /C4ySYWC/QGwNJjce6TEDLhpIgixUwlwf7WyVO/n/kSBTv8en4cQFH70n A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAACMIu5Z/5tdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9wZG4nB4Nzih+PQoF6kHeFQhCCAQojhRgCGoQ6PxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUdAQYjCl4BCBEDAQIoAwIEMBQJCgQBEok8ZBCnDIIniyABAQEBAQEEA?= =?us-ascii?q?QEBAQEBAQEbBYMuggeGY4E8gxFYFoJegmEFix2NVIh1AodijRCCFYV6ixKKJYs?= =?us-ascii?q?qAhEZAYE4AR84gVt6FYMtCYJfgXd2AYsdgREBAQE?=
X-IronPort-AV: E=Sophos; i="5.43,424,1503360000"; d="scan'208,217"; a="20373785"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2017 17:14:47 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9NHElwC028815 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Oct 2017 17:14:47 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 23 Oct 2017 13:14:46 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Mon, 23 Oct 2017 13:14:46 -0400
From: "Acee Lindem (acee)" 
To: wangzitao , "netmod@ietf.org" , "netmod-chairs@ietf.org" 
Thread-Topic: [netmod] Netmod IETF 100 Slot Requests - Singapore
Thread-Index: AQHTTCJsbZmkuVEKpEqfNNgfC6tDOw==
Date: Mon, 23 Oct 2017 17:14:46 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.195]
Content-Type: multipart/alternative; boundary="_000_D6139AA6D10A7aceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Netmod IETF 100 Slot Requests - Singapore
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 17:14:51 -0000

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

SGkgTWljaGFlbCwNClRoZSBhdXRob3JzIG9mIFJGQyAgODAyMiBCSVMgd291bGQgbGlrZSBhIDEw
LTE1IG1pbnV0ZSBzbG90IGZvciBhbiB1cGRhdGUgb24gdGhlIGRvY3VtZW50Lg0KDQpodHRwczov
L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLTA1LnR4dA0KDQpO
b3RlIHRoYXQgYnkgSUVURiAxMDAgaXQgd2lsbCBtb3N0IGxpa2VseSBiZSBhIFdHIGRvY3VtZW50
Lg0KDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5v
cmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIHdhbmd6aXRh
byA8d2FuZ3ppdGFvQGh1YXdlaS5jb208bWFpbHRvOndhbmd6aXRhb0BodWF3ZWkuY29tPj4NCkRh
dGU6IE1vbmRheSwgT2N0b2JlciAxNiwgMjAxNyBhdCAyOjIwIEFNDQpUbzogIm5ldG1vZEBpZXRm
Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPj4sICJuZXRtb2QtY2hhaXJzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtY2hh
aXJzQGlldGYub3JnPiIgPG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1jaGFp
cnNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW25ldG1vZF0gTmV0bW9kIElFVEYgMTAwIFNsb3QgUmVx
dWVzdHMgLSBTaW5nYXBvcmUNCg0KRGVhciBOZXRtb2QgV0csDQoNCkl0J3MgdGhhdCB0aW1lIGFn
YWluIQ0KDQpUaGUgSUVURiAxMDAgUHJlbGltaW5hcnkgQWdlbmRhIGhhcyBiZWVuIHB1Ymxpc2hl
ZDsgeW91IGNhbiBmaW5kIGl0IGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu
Zy8xMDAvYWdlbmRhLmh0bWwNCk5FVE1PRCB3aWxsIGJlIG1lZXRpbmc6IDEzOjMwLTE1OjAwIGFu
ZCAxNToyMC0xNjo1MCBvbiBXZWRuZXNkYXkuDQpJZiB5b3UnZCBsaWtlIGEgc2xvdCB0byBwcmVz
ZW50IHNvbWUgZG9jdW1lbnRzLCBwbGVhc2Ugc2VuZCBhIHJlcXVlc3QgdG8gQ2hhaXJzIGFuZCBt
ZS4NCktpbmRseSByZW1pbmRlciwgdGhlIGRlYWRsaW5lIGZvciBkcmFmdCBzdWJtaXNzaW9uIGlz
IFVUQyAyMzo1OSBvbiAyMDE3LTEwLTMwIChNb25kYXkpLg0KDQpCZXN0IFJlZ2FyZHMhDQoNCi1N
aWNoYWVsDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw
KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K
SGkgTWljaGFlbCwmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7
IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NClRo
ZSBhdXRob3JzIG9mIFJGQyAmbmJzcDs4MDIyIEJJUyB3b3VsZCBsaWtlIGEgMTAtMTUgbWludXRl
IHNsb3QgZm9yIGFuIHVwZGF0ZSBvbiB0aGUgZG9jdW1lbnQuICZuYnNwOzwvZGl2Pg0KPGRpdiBz
dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy
aWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh
bGlicmksc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt
YWNlZS1uZXRtb2QtcmZjODAyMmJpcy0wNS50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2Ry
YWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDUudHh0PC9hPjwvZm9udD48L2Rpdj4NCjxkaXY+
PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2
Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+Tm90ZSB0aGF0IGJ5IElFVEYgMTAwIGl0
IHdpbGwgbW9zdCBsaWtlbHkgYmUgYSBXRyBkb2N1bWVudC4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8
ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu
cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv
bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250
LXNpemU6IDE0cHg7Ij4NClRoYW5rcyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg
MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7
Ij4NCkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N
CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJn
YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog
MTRweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7
IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l
OyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkct
TEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNv
bGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFu
IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+bmV0bW9kICZsdDs8YSBocmVm
PSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn
PC9hPiZndDsgb24gYmVoYWxmIG9mIHdhbmd6aXRhbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmd6
aXRhb0BodWF3ZWkuY29tIj53YW5neml0YW9AaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25kYXksIE9jdG9iZXIgMTYs
IDIwMTcgYXQgMjoyMCBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog
PC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRm
Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1v
ZEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWNoYWlyc0Bp
ZXRmLm9yZyI+bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h
aWx0bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnIj5uZXRtb2QtY2hhaXJzQGlldGYub3JnPC9hPiZn
dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltu
ZXRtb2RdIE5ldG1vZCBJRVRGIDEwMCBTbG90IFJlcXVlc3RzIC0gU2luZ2Fwb3JlPGJyPg0KPC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ
QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQ
QURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hl
bWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t
Om9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl
OndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQv
MTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEg
bmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVk
aXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpcNUI4Qlw0RjUzOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJcQFw1QjhCXDRGNTMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyog
U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O
b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl
OjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw
YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0Mx
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy
bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu
VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6Ilw3RUFGXDY1ODdcNjcyQyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv
bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6
d2luZG93dGV4dDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Ilw3RUFGXDY1ODdcNjcy
QyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6XDdFQUZc
NjU4N1w2NzJDOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBE
ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky
LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0i
IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Ik9MRV9MSU5LMSI+PC9hPjxhIG5hbWU9Ik9MRV9M
SU5LMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgTmV0bW9kIFdHLDxvOnA+
PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkl0J3MgdGhhdCB0aW1l
IGFnYWluITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgSUVURiAxMDAgUHJlbGltaW5hcnkgQWdl
bmRhIGhhcyBiZWVuIHB1Ymxpc2hlZDsgeW91IGNhbiBmaW5kIGl0IGF0DQo8L3NwYW4+PGEgaHJl
Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMC9hZ2VuZGEuaHRtbCI+
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMC9hZ2VuZGEuaHRtbDwvYT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5FVE1PRCB3
aWxsIGJlIG1lZXRpbmc6IDEzOjMwLTE1OjAwIGFuZCAxNToyMC0xNjo1MCBvbiBXZWRuZXNkYXku
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPklmIHlvdSdkIGxpa2UgYSBzbG90IHRvIHByZXNlbnQgc29tZSBk
b2N1bWVudHMsIHBsZWFzZSBzZW5kIGEgcmVxdWVzdCB0byBDaGFpcnMgYW5kIG1lLg0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPktpbmRseSByZW1pbmRlciwgdGhlIGRlYWRsaW5lIGZvciBkcmFmdCBzdWJt
aXNzaW9uIGlzIFVUQyAyMzo1OSBvbg0KPGI+MjAxNy0xMC0zMCAoTW9uZGF5KS48L2I+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CZXN0IFJlZ2FyZHMhPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tTWljaGFlbCA8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D6139AA6D10A7aceeciscocom_--


From nobody Mon Oct 23 10:21:57 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778CB1397EF for ; Mon, 23 Oct 2017 10:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-VAnNXhuOtk for ; Mon, 23 Oct 2017 10:21:52 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717C91396DD for ; Mon, 23 Oct 2017 10:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2998; q=dns/txt; s=iport; t=1508779312; x=1509988912; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Zc8YEaSfolYMBQM/+fam1kOVNz15aX6HoCA69Ok9n9U=; b=X2FrSOSQiXsNbqiLvQ4i90dfdMMxRQBEV7BFN7/zmYN5Ciw2uG14x3KK 1KBnnym8QfKgfAEJbaw/tgicmyAsEs9HeXdqlIzSe0FIP2W64JUbFoDNy G1ofVOL9LOcXWY2MLLSBeNEE8NHDUH66IuNy6di57/hSkj8Usl8s1ic95 k=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.43,424,1503360000";  d="asc'?scan'208";a="655633491"
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; 23 Oct 2017 17:21:50 +0000
Received: from [10.61.78.84] (ams3-vpn-dhcp3668.cisco.com [10.61.78.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9NHLoRW005679; Mon, 23 Oct 2017 17:21:50 GMT
To: Kent Watsen , "netmod@ietf.org" 
Cc: "agarwaso@cisco.com" 
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <0d7df5fd-4507-cde0-328e-0bc8a5448487@cisco.com> <203D24AF-6876-4B74-8C1C-8CE3CBA10E0D@juniper.net>
From: Eliot Lear 
Message-ID: 
Date: Mon, 23 Oct 2017 19:21:49 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <203D24AF-6876-4B74-8C1C-8CE3CBA10E0D@juniper.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wIG4AhapOM9whW14NJq6IJWqhomniwmjx"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 17:21:55 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wIG4AhapOM9whW14NJq6IJWqhomniwmjx
Content-Type: multipart/mixed; boundary="jknao9NrrsxP607kth54UOWQvwqd1weMR";
 protected-headers="v1"
From: Eliot Lear 
To: Kent Watsen , "netmod@ietf.org" 
Cc: "agarwaso@cisco.com" 
Message-ID: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
 <0d7df5fd-4507-cde0-328e-0bc8a5448487@cisco.com>
 <203D24AF-6876-4B74-8C1C-8CE3CBA10E0D@juniper.net>
In-Reply-To: <203D24AF-6876-4B74-8C1C-8CE3CBA10E0D@juniper.net>

--jknao9NrrsxP607kth54UOWQvwqd1weMR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Honestly, I'd just assume got with what's there than have a lengthy
discussion about how to make it perfect in Eliot's eyes.=C2=A0 We must do=

models quicker, and I will be quite happy to enjoy this one's
imperfections just to prove that point.


On 10/23/17 6:35 PM, Kent Watsen wrote:
> Thanks Elliot.
>
> Can you say some more about what's not perfect about it?
>
> Kent  // shepherd
>
>
> --
>
> I've reviewed this draft.  It is NOT perfect.  It *is* good enough.=20
> Please let's move it along.
>
> Eliot
>
>
> On 10/20/17 11:37 PM, Kent Watsen wrote:
>> All,
>>
>> This starts a two-week working group last call on
>> draft-ietf-netmod-acl-model-14.
>>
>> The working group last call ends on November 3.
>> 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.
>>
>> Could the authors, explicitly CC-ed on this email, please
>> also confirm at this time that they are unaware of any=20
>> IPR related to this draft.
>>
>> Thank you,
>> Netmod Chairs
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>



--jknao9NrrsxP607kth54UOWQvwqd1weMR--

--wIG4AhapOM9whW14NJq6IJWqhomniwmjx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ7iUuAAoJEIe2a0bZ0nozWYoH/0oyK/ZYhFg3+uiQgcz+Bsxr
6mPdvcpWkCQtnHKkJIujAHrWS6RIr8QiDVrJf9Cun90OSlDBVTVnEtK+SQkbSPq4
R9RA7oxEQgVFX1U0Fr9UOVpFVaDqwhGBCfkzv7iTfuS1SHRGKbxc+5Gm+xar4Cbr
wTR8vQvuEgtjInW/cV5WHnvOEXDcvZuvb5shevDR2BQu386eojF44CfBJyK2ldw1
FOJjzPUeNsh1suiJMWAavtb4RSy2fftF3ZkcFgjtc+cq3FcsjqYYNlUcTiFyJiCV
cPyjidfWtX/gR/+NIiax3kZR0Al2SSgxY7EXiw3Gz5lo4xfReL7GzDCv2kU8wGI=
=hJyZ
-----END PGP SIGNATURE-----

--wIG4AhapOM9whW14NJq6IJWqhomniwmjx--


From nobody Mon Oct 23 10:41:55 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BAC137C4A for ; Mon, 23 Oct 2017 10:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUDeMleGG3ln for ; Mon, 23 Oct 2017 10:41:51 -0700 (PDT)
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 3018F13968C for ; Mon, 23 Oct 2017 10:41:51 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id p184so21009496lfe.12 for ; Mon, 23 Oct 2017 10:41:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y/Y3a4jMIzsHGl0yyu7QEg2j/IzQCdkozzwYEeOigUM=; b=z0HREheT1/v/58C2SKos6/Ye7Xm0Ry+xQlLVVxyE4o09Y8DOPitK9K7n7cii+v+JHH 0N7LNzJkdLgJrSN8XUEGSxChKHsnBHTBBdD90kFlAYLZsZTZ4/zTBfoxXCzcUkYChIG3 8+gceWJ4faru30Frgw54CiyUEhuFx7cDgmqakkKvDU/brM11o8bY4HhbD8wImBzDgyoB b0Avcdc+9g1dPUNlU7/iiykYNNB7+daU77fVpk0aCw+r3iTKXkMuypQ2DRkTxHMMmY5H eynqcFGI/piu2GNiYBBa50X5egBwXry2QsJ/cCuJen+6YZrClPuzqPTO75awEs4LAYz+ qNMA==
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=Y/Y3a4jMIzsHGl0yyu7QEg2j/IzQCdkozzwYEeOigUM=; b=NtVMZhjf+ew6SOUqA5gayz8ad6VJl1n/jXYYZ9hpRzks/1+rneBCAueCcr3GsYcbcA rD+8PZsCgtPrKwUfGXKttdx2+g28onkbwdCV0yjIK2J/DwiRllLhORd1BM43paF7jWfe 24tX5Y+TgLQr5V8RPE8CEKk05hamAJNRwNk5ZKHTi/iddyBm+QHSin0VJTh7ehwSpW9W YzCllufCgF8G/gO1/ASMihvN6qT15VTYTc2CJ1p62k93JLuKHq6EWYWUrbkK8Ni1NQBG nI1/KyBHECOGhuu6eRN73kW/rKbCT3cqGvj3zI67ueGcOtgTLuoToVob4W1NUDklQAOn Blxg==
X-Gm-Message-State: AMCzsaVrXa9HlD+SU0Z08JD3Hx+b5uMIKWMpEt/hdUZC0/HpsQ+mHj1o LHiyw2WwIN7SmwP106cGaXapo6oByWpTTfXE/8Wz/Q==
X-Google-Smtp-Source: ABhQp+QG1lvYrbd8Hb4ulgxzp4Hfj2bBg+ZM4zcY+P6IN3B32t+QM2JEO21wc46rO64wF9J8aIwsURbIUo9rfLDK9dU=
X-Received: by 10.25.104.21 with SMTP id d21mr2288903lfc.45.1508780509335; Mon, 23 Oct 2017 10:41:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Mon, 23 Oct 2017 10:41:48 -0700 (PDT)
In-Reply-To: <20171023.163039.1034668943501669872.mbj@tail-f.com>
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com> <20171023.103513.1336510497564838401.mbj@tail-f.com>  <20171023.163039.1034668943501669872.mbj@tail-f.com>
From: Andy Bierman 
Date: Mon, 23 Oct 2017 10:41:48 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Benoit Claise , Warren Kumari ,  Kent Watsen , Berger Lou ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045e56164dac9a055c3a56b7"
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 17:41:54 -0000

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

Hi,

To be clear, I am withdrawing this errata because existing implementations
may not accept a numeric literal in an instance-identifier.
I think this should be addressed in YANG 2.0 and this thread should be
recorded in the yang-next issue trac ker.

Andy


On Mon, Oct 23, 2017 at 7:30 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Mon, Oct 23, 2017 at 1:35 AM, Martin Bjorklund 
> wrote:
> >
> > > Benoit Claise  wrote:
> > > > Dear all,
> > > >
> > > > Shall I validate this one?
> > >
> > > No I don't think this is correct.  We choose a quoted string to be
> > > able to correctly represent all YANG integer and decimal64 values.
> > > Note that XPath doesn't have integers, just 64-bit floats.  This means
> > > that not all 64-bit integers can be expressed as numbers in XPath.
> > >
> > >
> > It's OK to leave this out since it requires a code change.
> >
> >
> > Read sec. 2.3 again:
>
> Wrong thread?
>
> > The node test text() is true for any text node.
>
> Sure, but a node test is not a predicate!
>
>
> /martin
>
>
>
> >
> >
> >
> >
> > >
> > > /martin
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > > >
> > > > Regards, Benoit
> > > > > The following errata report has been submitted for RFC7950,
> > > > > "The YANG 1.1 Data Modeling Language".
> > > > >
> > > > > --------------------------------------
> > > > > You may review the report below and at:
> > > > > http://www.rfc-editor.org/errata/eid5157
> > > > >
> > > > > --------------------------------------
> > > > > Type: Technical
> > > > > Reported by: Andy Bierman 
> > > > >
> > > > > Section: 14
> > > > >
> > > > > Original Text
> > > > > -------------
> > > > >    key-predicate-expr  = node-identifier *WSP "=" *WSP
> quoted-string
> > > > >
> > > > > Corrected Text
> > > > > --------------
> > > > >    key-predicate-expr  = node-identifier *WSP "=" *WSP
> > > > >          (quoted-string / integer-value / decimal-value)
> > > > >
> > > > > Notes
> > > > > -----
> > > > > An instance identifier is forced to specify every key value to be a
> > > > > string
> > > > > even though the YANG key leaf type could be a numeric type.
> > > > > XPath does not require a quoted string here, just YANG.
> > > > >
> > > > > Old:  /top/list[idx="4"]
> > > > > New: /top/list[idx=4]
> > > > >
> > > > > Instructions:
> > > > > -------------
> > > > > This erratum is currently posted as "Reported". If necessary,
> please
> > > > > use "Reply All" to discuss whether it should be verified or
> > > > > rejected. When a decision is reached, the verifying party
> > > > > can log in to change the status and edit the report, if necessary.
> > > > >
> > > > > --------------------------------------
> > > > > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > > > > --------------------------------------
> > > > > Title               : The YANG 1.1 Data Modeling Language
> > > > > Publication Date    : August 2016
> > > > > Author(s)           : M. Bjorklund, Ed.
> > > > > Category            : PROPOSED STANDARD
> > > > > Source              : NETCONF Data Modeling Language
> > > > > Area                : Operations and Management
> > > > > Stream              : IETF
> > > > > Verifying Party     : IESG
> > > > > .
> > > > >
> > > >
> > >
>

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


Hi,

To be clear, I am withdrawing this =
errata because existing implementations
may not accept a numeric =
literal in an instance-identifier.
I think this should be address=
ed in YANG 2.0 and this thread should be
recorded in the yang-nex=
t issue trac ker.

Andy

<=
div class=3D"gmail_extra">
On Mon, Oct 23, 20=
17 at 7:30 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Mon, Oct 23, 2017 at 1:35 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Benoit Claise <bclaise@ci=
sco.com> wrote:

> > > Dear all,

> > >

> > > Shall I validate this one?

> >

> > No I don't think this is correct.=C2=A0 We choose a quoted st=
ring to be

> > able to correctly represent all YANG integer and decimal64 values=
.

> > Note that XPath doesn't have integers, just 64-bit floats.=C2=
=A0 This means

> > that not all 64-bit integers can be expressed as numbers in XPath=
.

> >

> >

> It's OK to leave this out since it requires a code change.

>

>

> Read sec. 2.3 again:



Wrong thread?



> The node test text() is true for any text node.



Sure, but a node test is not a predicate!





/martin







>

>

>

>

> >

> > /martin

> >

> >

>

> Andy

>

>

> >

> > >

> > > Regards, Benoit

> > > > The following errata report has been submitted for RFC7=
950,

> > > > "The YANG 1.1 Data Modeling Language".

> > > >

> > > > --------------------------------------

> > > > You may review the report below and at:

> > > > http://www.rfc-editor.org/errata/ei=
d5157

> > > >

> > > > --------------------------------------

> > > > Type: Technical

> > > > Reported by: Andy Bierman <andy@yumaworks.com>

> > > >

> > > > Section: 14

> > > >

> > > > Original Text

> > > > -------------

> > > >=C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node-identifi=
er *WSP "=3D" *WSP quoted-string

> > > >

> > > > Corrected Text

> > > > --------------

> > > >=C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node-identifi=
er *WSP "=3D" *WSP

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (quoted-string / inte=
ger-value / decimal-value)

> > > >

> > > > Notes

> > > > -----

> > > > An instance identifier is forced to specify every key v=
alue to be a

> > > > string

> > > > even though the YANG key leaf type could be a numeric t=
ype.

> > > > XPath does not require a quoted string here, just YANG.=


> > > >

> > > > Old:=C2=A0 /top/list[idx=3D"4"]

> > > > New: /top/list[idx=3D4]

> > > >

> > > > Instructions:

> > > > -------------

> > > > This erratum is currently posted as "Reported"=
;. If necessary, please

> > > > use "Reply All" to discuss whether it should =
be verified or

> > > > rejected. When a decision is reached, the verifying par=
ty

> > > > can log in to change the status and edit the report, if=
 necessary.

> > > >

> > > > --------------------------------------

> > > > RFC7950 (draft-ietf-netmod-rfc6020bis-14)

> > > > --------------------------------------

> > > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0: The YANG 1.1 Data Modeling Language

> > > > Publication Date=C2=A0 =C2=A0 : August 2016

> > > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. =
Bjorklund, Ed.

> > > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PRO=
POSED STANDARD

> > > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
: NETCONF Data Modeling Language

> > > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 : Operations and Management

> > > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
: IETF

> > > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

> > > > .

> > > >

> > >

> >





--f403045e56164dac9a055c3a56b7--


From nobody Mon Oct 23 10:52:07 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987A51397F3 for ; Mon, 23 Oct 2017 10:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level: 
X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 0AxNVvd7l3Ir for ; Mon, 23 Oct 2017 10:52:03 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0132.outbound.protection.outlook.com [104.47.38.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D51137C4A for ; Mon, 23 Oct 2017 10:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VqYLYkbbCKFpDIRxocm62cVKx3vgN7tAtMPwdrwPArY=; b=K8ZttWdM9aD5ZbsN6r2572Witoyc08OSZ4u1ZaEwGDY8hVWVo+8NDmSOuIs6UCN6QO8VNou5A+GEGi/mWD51e521d9hRGOLRL/l8OdJq6xerqPmvUyb7b9dyAoVoIiBEzOpFzI46SL8FViLOSLKWuLd8CHPsG/jkA/xsEt+YFv8=
Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB278.namprd05.prod.outlook.com (10.141.64.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 17:52:00 +0000
Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497%14]) with mapi id 15.20.0178.003; Mon, 23 Oct 2017 17:52:00 +0000
From: Kent Watsen 
To: Andy Bierman , Martin Bjorklund 
CC: Benoit Claise , Warren Kumari , Berger Lou , "netmod@ietf.org" 
Thread-Topic: [Technical Errata Reported] RFC7950 (5157)
Thread-Index: AQHTRrGnHd+5aLr6G0SoL0OtwQRLyqLt7x4AgAM3LoCAAGIqgIAAASWAgAA1aAD//7/QAA==
Date: Mon, 23 Oct 2017 17:52:00 +0000
Message-ID: <0EAFE79B-CA28-4292-9E68-5AC87CA9957A@juniper.net>
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com> <20171023.103513.1336510497564838401.mbj@tail-f.com>  <20171023.163039.1034668943501669872.mbj@tail-f.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; BN1PR05MB278; 6:Q7TbDkRv8OXs8b8kmW3TwzEG19ubIIi3ie740XEhfUGEsm4wNgMGW7R9JyhmnhskJTTUFWNo3jnmAVYJPO5d19rdBQmlnxImAzhGpX4oheNZzJ6oCUSM650o5w1BqM+iw0vNDtwtA/jk/yT44IBwgg9K0apsT2qOFls2twu3qeW2X4+EJowBKbQXIb/kEKad1IAdvq/IYGzCivK2NQJE6YPh9nb+FgizEDXniHqHaLAd/KMm9NYmU4T83IP03warZZPK9zO/cvZDOVFFa5ZQlDV5e9YirSZlZFC3UqlxzRyGjSCHFmiSYjsblgf8I6Kv/n/OVyqJVhPbEKhvctcR6upzZw7+UNquaJTMf27tu1A=; 5:EiMhCv4Upa1JMGBuSbsPcUx2hyiuTuwdlzU45hhoDW9WGe3tyB3/YVoCv4E4UtB6WPpaLgWnYFQnXcQbD4fwDLm6Tkwn9Q1PkFO0mSxkR3DTjuzgxfDZVeVnjRY77dE1UH8A56Zl17qWx20i961kO2P7gQRseffcbtpetmdCVdg=; 24:XbhkvI5UK7spWvhkLCPQASqGMduE2QX3ePfmyZmqvIx7H5Nse+3g1FP82s5ReizkYRI2Czr6mqSEnxYbAvL1W1q9RZ5Sk9NKRL5ClJk06js=; 7:mEXzcMgKGxoacZwg7KEA7uWOYAUwP7q9ds0sELibpnucOESPyHDCdNJgM2XznsqPQt9WIiRt/+xlqymXuqCD6Umocp944xKc+71j1kwhBh11Mq2vfTntratuzm2ioemIF8I8L/cssybiNvF2ys/zhKBQ5Y4P95/uarVFc8ZQKvXVC3cDZijPQBxO6eY9j0Od5DFoxVJtbVuWEzyY87PRXY3Jd6Byr8hiaXDMckA1LAmAVGXlyHzUJrCSP1tP9VSc
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: f59f2576-9d21-4a42-f6fd-08d51a3ec302
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:BN1PR05MB278; 
x-ms-traffictypediagnostic: BN1PR05MB278:
x-exchange-antispam-report-test: UriScan:(10436049006162)(166708455590820)(95692535739014)(21748063052155); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231020)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB278; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB278; 
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(199003)(189002)(24454002)(966005)(2900100001)(3846002)(66066001)(101416001)(6116002)(102836003)(50986999)(76176999)(54356999)(2950100002)(33656002)(105586002)(68736007)(106356001)(3660700001)(81156014)(7736002)(8676002)(81166006)(3280700002)(8936002)(189998001)(478600001)(2906002)(5660300001)(99286003)(53546010)(606006)(6246003)(83506002)(58126008)(36756003)(110136005)(54906003)(93886005)(4326008)(6486002)(53936002)(6436002)(6306002)(5250100002)(97736004)(83716003)(6506006)(25786009)(14454004)(82746002)(54896002)(236005)(229853002)(316002)(6512007)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB278; H:BN1PR05MB280.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)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_0EAFE79BCA2842929E685AC87CA9957Ajunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f59f2576-9d21-4a42-f6fd-08d51a3ec302
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 17:52:00.3276 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB278
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 17:52:05 -0000

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

QWRkZWQuICBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXMvMzAN
Cg0KSy4NCg0KT24gMTAvMjMvMTcsIDE6NDEgUE0sICJBbmR5IEJpZXJtYW4iIDxhbmR5QHl1bWF3
b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KVG8g
YmUgY2xlYXIsIEkgYW0gd2l0aGRyYXdpbmcgdGhpcyBlcnJhdGEgYmVjYXVzZSBleGlzdGluZyBp
bXBsZW1lbnRhdGlvbnMNCm1heSBub3QgYWNjZXB0IGEgbnVtZXJpYyBsaXRlcmFsIGluIGFuIGlu
c3RhbmNlLWlkZW50aWZpZXIuDQpJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbiBZ
QU5HIDIuMCBhbmQgdGhpcyB0aHJlYWQgc2hvdWxkIGJlDQpyZWNvcmRlZCBpbiB0aGUgeWFuZy1u
ZXh0IGlzc3VlIHRyYWMga2VyLg0KDQpBbmR5DQoNCg0KT24gTW9uLCBPY3QgMjMsIDIwMTcgYXQg
NzozMCBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWls
LWYuY29tPj4gd3JvdGU6DQpBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86
YW5keUB5dW1hd29ya3MuY29tPj4gd3JvdGU6DQo+IE9uIE1vbiwgT2N0IDIzLCAyMDE3IGF0IDE6
MzUgQU0sIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1m
LmNvbT4+IHdyb3RlOg0KPg0KPiA+IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPG1h
aWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+ID4gRGVhciBhbGwsDQo+ID4gPg0K
PiA+ID4gU2hhbGwgSSB2YWxpZGF0ZSB0aGlzIG9uZT8NCj4gPg0KPiA+IE5vIEkgZG9uJ3QgdGhp
bmsgdGhpcyBpcyBjb3JyZWN0LiAgV2UgY2hvb3NlIGEgcXVvdGVkIHN0cmluZyB0byBiZQ0KPiA+
IGFibGUgdG8gY29ycmVjdGx5IHJlcHJlc2VudCBhbGwgWUFORyBpbnRlZ2VyIGFuZCBkZWNpbWFs
NjQgdmFsdWVzLg0KPiA+IE5vdGUgdGhhdCBYUGF0aCBkb2Vzbid0IGhhdmUgaW50ZWdlcnMsIGp1
c3QgNjQtYml0IGZsb2F0cy4gIFRoaXMgbWVhbnMNCj4gPiB0aGF0IG5vdCBhbGwgNjQtYml0IGlu
dGVnZXJzIGNhbiBiZSBleHByZXNzZWQgYXMgbnVtYmVycyBpbiBYUGF0aC4NCj4gPg0KPiA+DQo+
IEl0J3MgT0sgdG8gbGVhdmUgdGhpcyBvdXQgc2luY2UgaXQgcmVxdWlyZXMgYSBjb2RlIGNoYW5n
ZS4NCj4NCj4NCj4gUmVhZCBzZWMuIDIuMyBhZ2FpbjoNCg0KV3JvbmcgdGhyZWFkPw0KDQo+IFRo
ZSBub2RlIHRlc3QgdGV4dCgpIGlzIHRydWUgZm9yIGFueSB0ZXh0IG5vZGUuDQoNClN1cmUsIGJ1
dCBhIG5vZGUgdGVzdCBpcyBub3QgYSBwcmVkaWNhdGUhDQoNCg0KL21hcnRpbg0KDQoNCg0KPg0K
Pg0KPg0KPg0KPiA+DQo+ID4gL21hcnRpbg0KPiA+DQo+ID4NCj4NCj4gQW5keQ0KPg0KPg0KPiA+
DQo+ID4gPg0KPiA+ID4gUmVnYXJkcywgQmVub2l0DQo+ID4gPiA+IFRoZSBmb2xsb3dpbmcgZXJy
YXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzc5NTAsDQo+ID4gPiA+ICJUaGUg
WUFORyAxLjEgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSIuDQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+IFlvdSBtYXkgcmV2aWV3
IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Og0KPiA+ID4gPiBodHRwOi8vd3d3LnJmYy1lZGl0b3Iu
b3JnL2VycmF0YS9laWQ1MTU3PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwLTNBX193d3cucmZjLTJEZWRpdG9yLm9yZ19lcnJhdGFfZWlkNTE1NyZkPUR3TUZh
USZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhu
SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09aXFwaFRNa3A1MWRMckNNLVV6
bHJFeXd1SmU5WHRST3hPOHBuU1JOMEE3QSZzPXV3Wk0zQVYxVUFIZFQ1N2JhLWJXQ05HUmNHdFEt
MTc1OGM0bDl0dFFSVU0mZT0+DQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+IFR5cGU6IFRlY2huaWNhbA0KPiA+ID4gPiBSZXBv
cnRlZCBieTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVt
YXdvcmtzLmNvbT4+DQo+ID4gPiA+DQo+ID4gPiA+IFNlY3Rpb246IDE0DQo+ID4gPiA+DQo+ID4g
PiA+IE9yaWdpbmFsIFRleHQNCj4gPiA+ID4gLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiAgICBrZXkt
cHJlZGljYXRlLWV4cHIgID0gbm9kZS1pZGVudGlmaWVyICpXU1AgIj0iICpXU1AgcXVvdGVkLXN0
cmluZw0KPiA+ID4gPg0KPiA+ID4gPiBDb3JyZWN0ZWQgVGV4dA0KPiA+ID4gPiAtLS0tLS0tLS0t
LS0tLQ0KPiA+ID4gPiAgICBrZXktcHJlZGljYXRlLWV4cHIgID0gbm9kZS1pZGVudGlmaWVyICpX
U1AgIj0iICpXU1ANCj4gPiA+ID4gICAgICAgICAgKHF1b3RlZC1zdHJpbmcgLyBpbnRlZ2VyLXZh
bHVlIC8gZGVjaW1hbC12YWx1ZSkNCj4gPiA+ID4NCj4gPiA+ID4gTm90ZXMNCj4gPiA+ID4gLS0t
LS0NCj4gPiA+ID4gQW4gaW5zdGFuY2UgaWRlbnRpZmllciBpcyBmb3JjZWQgdG8gc3BlY2lmeSBl
dmVyeSBrZXkgdmFsdWUgdG8gYmUgYQ0KPiA+ID4gPiBzdHJpbmcNCj4gPiA+ID4gZXZlbiB0aG91
Z2ggdGhlIFlBTkcga2V5IGxlYWYgdHlwZSBjb3VsZCBiZSBhIG51bWVyaWMgdHlwZS4NCj4gPiA+
ID4gWFBhdGggZG9lcyBub3QgcmVxdWlyZSBhIHF1b3RlZCBzdHJpbmcgaGVyZSwganVzdCBZQU5H
Lg0KPiA+ID4gPg0KPiA+ID4gPiBPbGQ6ICAvdG9wL2xpc3RbaWR4PSI0Il0NCj4gPiA+ID4gTmV3
OiAvdG9wL2xpc3RbaWR4PTRdDQo+ID4gPiA+DQo+ID4gPiA+IEluc3RydWN0aW9uczoNCj4gPiA+
ID4gLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3Rl
ZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0KPiA+ID4gPiB1c2UgIlJlcGx5
IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPiA+ID4g
PiByZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFy
dHkNCj4gPiA+ID4gY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUg
cmVwb3J0LCBpZiBuZWNlc3NhcnkuDQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+IFJGQzc5NTAgKGRyYWZ0LWlldGYtbmV0bW9k
LXJmYzYwMjBiaXMtMTQpDQo+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+ID4gPiA+IFRpdGxlICAgICAgICAgICAgICAgOiBUaGUgWUFORyAxLjEgRGF0YSBN
b2RlbGluZyBMYW5ndWFnZQ0KPiA+ID4gPiBQdWJsaWNhdGlvbiBEYXRlICAgIDogQXVndXN0IDIw
MTYNCj4gPiA+ID4gQXV0aG9yKHMpICAgICAgICAgICA6IE0uIEJqb3JrbHVuZCwgRWQuDQo+ID4g
PiA+IENhdGVnb3J5ICAgICAgICAgICAgOiBQUk9QT1NFRCBTVEFOREFSRA0KPiA+ID4gPiBTb3Vy
Y2UgICAgICAgICAgICAgIDogTkVUQ09ORiBEYXRhIE1vZGVsaW5nIExhbmd1YWdlDQo+ID4gPiA+
IEFyZWEgICAgICAgICAgICAgICAgOiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50DQo+ID4gPiA+
IFN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQo+ID4gPiA+IFZlcmlmeWluZyBQYXJ0eSAgICAg
OiBJRVNHDQo+ID4gPiA+IC4NCj4gPiA+ID4NCj4gPiA+DQo+ID4NCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkFkZGVkLiZu
YnNwOyBodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXMvMzA8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPksuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTAvMjMvMTcsIDE6NDEgUE0sICZxdW90O0FuZHkgQmll
cm1hbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5
dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gYmUgY2xlYXIsIEkgYW0gd2l0aGRyYXdpbmcg
dGhpcyBlcnJhdGEgYmVjYXVzZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnM8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1heSBub3QgYWNjZXB0IGEg
bnVtZXJpYyBsaXRlcmFsIGluIGFuIGluc3RhbmNlLWlkZW50aWZpZXIuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMgc2hvdWxk
IGJlIGFkZHJlc3NlZCBpbiBZQU5HIDIuMCBhbmQgdGhpcyB0aHJlYWQgc2hvdWxkIGJlPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWNvcmRlZCBp
biB0aGUgeWFuZy1uZXh0IGlzc3VlIHRyYWMga2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBPY3QgMjMsIDIwMTcgYXQg
NzozMCBBTSwgTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5IEJpZXJtYW4g
Jmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgT24gTW9uLCBPY3QgMjMsIDIwMTcgYXQgMTozNSBB
TSwgTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5t
YmpAdGFpbC1mLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgQmVu
b2l0IENsYWlzZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj5iY2xhaXNl
QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7IERlYXIgYWxsLDxi
cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2hhbGwgSSB2YWxpZGF0ZSB0
aGlzIG9uZT88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTm8gSSBkb24ndCB0aGluayB0
aGlzIGlzIGNvcnJlY3QuJm5ic3A7IFdlIGNob29zZSBhIHF1b3RlZCBzdHJpbmcgdG8gYmU8YnI+
DQomZ3Q7ICZndDsgYWJsZSB0byBjb3JyZWN0bHkgcmVwcmVzZW50IGFsbCBZQU5HIGludGVnZXIg
YW5kIGRlY2ltYWw2NCB2YWx1ZXMuPGJyPg0KJmd0OyAmZ3Q7IE5vdGUgdGhhdCBYUGF0aCBkb2Vz
bid0IGhhdmUgaW50ZWdlcnMsIGp1c3QgNjQtYml0IGZsb2F0cy4mbmJzcDsgVGhpcyBtZWFuczxi
cj4NCiZndDsgJmd0OyB0aGF0IG5vdCBhbGwgNjQtYml0IGludGVnZXJzIGNhbiBiZSBleHByZXNz
ZWQgYXMgbnVtYmVycyBpbiBYUGF0aC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7IEl0J3MgT0sgdG8gbGVhdmUgdGhpcyBvdXQgc2luY2UgaXQgcmVxdWlyZXMgYSBjb2Rl
IGNoYW5nZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgUmVhZCBzZWMuIDIuMyBhZ2Fp
bjo8YnI+DQo8YnI+DQpXcm9uZyB0aHJlYWQ/PGJyPg0KPGJyPg0KJmd0OyBUaGUgbm9kZSB0ZXN0
IHRleHQoKSBpcyB0cnVlIGZvciBhbnkgdGV4dCBub2RlLjxicj4NCjxicj4NClN1cmUsIGJ1dCBh
IG5vZGUgdGVzdCBpcyBub3QgYSBwcmVkaWNhdGUhPGJyPg0KPGJyPg0KPGJyPg0KL21hcnRpbjxi
cj4NCjxicj4NCjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8
YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgL21hcnRpbjxicj4NCiZndDsgJmd0Ozxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEFuZHk8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi
cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmVn
YXJkcywgQmVub2l0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZm9sbG93aW5nIGVycmF0
YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM3OTUwLDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJnF1b3Q7VGhlIFlBTkcgMS4xIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UmcXVvdDsu
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Ojxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHAtM0FfX3d3dy5yZmMtMkRlZGl0b3Iub3JnX2VycmF0YV9laWQ1MTU3JmFtcDtkPUR3
TUZhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFt
cDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209aXFw
aFRNa3A1MWRMckNNLVV6bHJFeXd1SmU5WHRST3hPOHBuU1JOMEE3QSZhbXA7cz11d1pNM0FWMVVB
SGRUNTdiYS1iV0NOR1JjR3RRLTE3NThjNGw5dHRRUlVNJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi
Pg0KaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTE1NzwvYT48YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVHlwZTogVGVj
aG5pY2FsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSZXBvcnRlZCBieTogQW5keSBCaWVybWFu
ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5j
b208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7IFNlY3Rpb246IDE0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgT3JpZ2luYWwgVGV4dDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0t
LS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGtleS1wcmVkaWNhdGUt
ZXhwciZuYnNwOyA9IG5vZGUtaWRlbnRpZmllciAqV1NQICZxdW90Oz0mcXVvdDsgKldTUCBxdW90
ZWQtc3RyaW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgQ29ycmVjdGVkIFRleHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0t
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsga2V5LXByZWRpY2F0ZS1leHBy
Jm5ic3A7ID0gbm9kZS1pZGVudGlmaWVyICpXU1AgJnF1b3Q7PSZxdW90OyAqV1NQPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKHF1b3Rl
ZC1zdHJpbmcgLyBpbnRlZ2VyLXZhbHVlIC8gZGVjaW1hbC12YWx1ZSk8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBOb3Rlczxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuIGluc3RhbmNlIGlkZW50
aWZpZXIgaXMgZm9yY2VkIHRvIHNwZWNpZnkgZXZlcnkga2V5IHZhbHVlIHRvIGJlIGE8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7IHN0cmluZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZXZlbiB0
aG91Z2ggdGhlIFlBTkcga2V5IGxlYWYgdHlwZSBjb3VsZCBiZSBhIG51bWVyaWMgdHlwZS48YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFhQYXRoIGRvZXMgbm90IHJlcXVpcmUgYSBxdW90ZWQgc3Ry
aW5nIGhlcmUsIGp1c3QgWUFORy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyBPbGQ6Jm5ic3A7IC90b3AvbGlzdFtpZHg9JnF1b3Q7NCZxdW90O108YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5ldzogL3RvcC9saXN0W2lkeD00XTxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEluc3RydWN0aW9uczo8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICZxdW90O1JlcG9ydGVkJnF1b3Q7
LiBJZiBuZWNlc3NhcnksIHBsZWFzZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdXNlICZxdW90
O1JlcGx5IEFsbCZxdW90OyB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVk
IG9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyByZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlz
IHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNh
biBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVj
ZXNzYXJ5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyBSRkM3OTUwIChkcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDIwYmlzLTE0KTxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogVGhlIFlBTkcgMS4xIERhdGEgTW9kZWxpbmcg
TGFuZ3VhZ2U8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFB1YmxpY2F0aW9uIERhdGUmbmJzcDsg
Jm5ic3A7IDogQXVndXN0IDIwMTY8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEF1dGhvcihzKSZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBNLiBCam9ya2x1bmQsIEVk
Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQ2F0ZWdvcnkmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyA6IFBST1BPU0VEIFNUQU5EQVJEPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyBTb3VyY2UmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgOiBORVRDT05GIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2U8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7IEFyZWEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IDogT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgU3RyZWFtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IDogSUVURjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVmVyaWZ5aW5nIFBhcnR5Jm5ic3A7
ICZuYnNwOyAmbmJzcDs6IElFU0c8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IC48YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_0EAFE79BCA2842929E685AC87CA9957Ajunipernet_--


From nobody Mon Oct 23 11:02:46 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C0D1398CF for ; Mon, 23 Oct 2017 11:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXtNlMAMFNVX for ; Mon, 23 Oct 2017 11:02:35 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23BF13982B for ; Mon, 23 Oct 2017 11:02:34 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id k123so23092033qke.3 for ; Mon, 23 Oct 2017 11:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OOsCEmT8ucLCaX8SWXZ7gwWByYDu6yf0bZ95ZzMCnXY=; b=YIfZPIFhl0fDirSQhO2iKy4Xvcv7YXH2kM4Hzb3IevgLbQxTFVJGyWdIOSCYDIxgVl Wr2Na5QuzYJVjYdd1AK6/OAtjs7uQfNeVOhXgbvEXLAe3OtNjfes+dyPQWgMwkr9zzA2 5rg2nwvAaqub9OvlWNu9Zv3jq6I9yckTzgW4sLK+p6JTusSCiKq7gB1BXAO89EUNJn6z zWcmIs+ymqsNwaSTMOHvs74X4YNk3xDy3lyHAgYFx7ppU8WCK0CgyENwdxvb+46wdFkl wwcTdDhwvb+CZyIlfnzH42BKMyNzM0pcyEfYvfflU+EF05NCILaB59swqVniUTjqI0eF CZlw==
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=OOsCEmT8ucLCaX8SWXZ7gwWByYDu6yf0bZ95ZzMCnXY=; b=QyRDhC6DRL+2YcVz1BaEK4L5Sf61Dr+DXDGb5Sv1DfXkZY8YBsJR4j8d3mojEy+w75 dZjE4hYTIpX8AQfbk1Ka4EaaLlIAyotqKYts8/ateP7B4JEz3uV6QIGPiwhLX7FA/1y/ D0pWmpsv1N1W2Oq8Vl9EdJTVdCD38pVknW0Mgqsk4jd/PmGlZcsS2RfBLTIdqrRo63BI WpgVbgh+7geaiZ29AV+VL+bJJTG17KUm2SyWxa6DYGe2QLyBqrYo/llDsiRLreXXiALS 82qhHbZin18/QDyORqBtlXAcqwmM6xv7/pKzjWwqQezp3zc/wIC+VdmcNXQj8LGL/FzE rJQg==
X-Gm-Message-State: AMCzsaWkB9Yjplqag2Zm2zsTgjm1A6XVB/PT7IWaQVuDisg5U0mob88q 7zoLTrNfu0avXfTBn88H0XRjvCoS7CJR9Xcwmy4=
X-Google-Smtp-Source: ABhQp+SuOV/58pvIgdMsz112KLhauiznPBZi/Vxg6k8LOy+puqozZ53/zT6jfBuZGTGDv6SCIfVnF3w6qRVHS7RIRyk=
X-Received: by 10.55.93.7 with SMTP id r7mr20447812qkb.35.1508781753972; Mon, 23 Oct 2017 11:02:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.109.136 with HTTP; Mon, 23 Oct 2017 11:02:33 -0700 (PDT)
In-Reply-To: 
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <0d7df5fd-4507-cde0-328e-0bc8a5448487@cisco.com> <203D24AF-6876-4B74-8C1C-8CE3CBA10E0D@juniper.net> 
From: Sonal Agarwal 
Date: Mon, 23 Oct 2017 11:02:33 -0700
Message-ID: 
To: Eliot Lear 
Cc: Kent Watsen , "netmod@ietf.org" ,  "agarwaso@cisco.com" 
Content-Type: multipart/alternative; boundary="001a114c93b07d3d95055c3aa0ce"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 18:02:37 -0000

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

Hi Eliiot,

I'd be very interested in understanding the technical issues that you see
with the model. Could you please elaborate?

Kind regards,
Sonal.


On Mon, Oct 23, 2017 at 10:21 AM, Eliot Lear  wrote:

> Honestly, I'd just assume got with what's there than have a lengthy
> discussion about how to make it perfect in Eliot's eyes.  We must do
> models quicker, and I will be quite happy to enjoy this one's
> imperfections just to prove that point.
>
>
> On 10/23/17 6:35 PM, Kent Watsen wrote:
> > Thanks Elliot.
> >
> > Can you say some more about what's not perfect about it?
> >
> > Kent  // shepherd
> >
> >
> > --
> >
> > I've reviewed this draft.  It is NOT perfect.  It *is* good enough.
> > Please let's move it along.
> >
> > Eliot
> >
> >
> > On 10/20/17 11:37 PM, Kent Watsen wrote:
> >> All,
> >>
> >> This starts a two-week working group last call on
> >> draft-ietf-netmod-acl-model-14.
> >>
> >> The working group last call ends on November 3.
> >> 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.
> >>
> >> Could the authors, explicitly CC-ed on this email, please
> >> also 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
> >>
> >
> >
> >
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Hi Eliiot,

I'd be very interested i=
n understanding the technical issues that you see with the model. Could you=
 please elaborate?

Kind regards,
Sonal.<=
/div>


On Mon, Oct 23, 2017 at 10:21 AM, Eliot Lear <=
;lear@cisco.com>=
 wrote:
Honestly, I'd just ass=
ume got with what's there than have a lengthy

discussion about how to make it perfect in Eliot's eyes.=C2=A0 We must =
do

models quicker, and I will be quite happy to enjoy this one's

imperfections just to prove that point.






On 10/23/17 6:35 PM, Kent Watsen wrote:

> Thanks Elliot.

>

> Can you say some more about what's not perfect about it?

>

> Kent=C2=A0 // shepherd

>

>

> --

>

> I've reviewed this draft.=C2=A0 It is NOT perfect.=C2=A0 It *is* g=
ood enough.

> Please let's move it along.

>

> Eliot

>

>

> On 10/20/17 11:37 PM, Kent Watsen wrote:

>> All,

>>

>> This starts a two-week working group last call on

>> draft-ietf-netmod-acl-model-14.

>>

>> The working group last call ends on November 3.

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

>>

>> Could the authors, explicitly CC-ed on this email, please

>> also 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/netm=
od

>>

>

>

>







_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a114c93b07d3d95055c3aa0ce--


From nobody Mon Oct 23 14:45:49 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA4013A64D; Mon, 23 Oct 2017 14:45:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HK5P6VHtvFjI; Mon, 23 Oct 2017 14:45:47 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92D813A41A; Mon, 23 Oct 2017 14:45:47 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id D810BB813C8; Mon, 23 Oct 2017 14:45:45 -0700 (PDT)
To: andy@yumaworks.com, mbj@tail-f.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: bclaise@cisco.com, iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20171023214545.D810BB813C8@rfc-editor.org>
Date: Mon, 23 Oct 2017 14:45:45 -0700 (PDT)
Archived-At: 
Subject: [netmod] [Errata Rejected] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 21:45:49 -0000

The following errata report has been rejected for RFC7950,
"The YANG 1.1 Data Modeling Language".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5157

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Andy Bierman 
Date Reported: 2017-10-16
Rejected by: Benoit Claise (IESG)

Section: 14

Original Text
-------------
  key-predicate-expr  = node-identifier *WSP "=" *WSP quoted-string

Corrected Text
--------------
  key-predicate-expr  = node-identifier *WSP "=" *WSP 
        (quoted-string / integer-value / decimal-value)

Notes
-----
An instance identifier is forced to specify every key value to be a string
even though the YANG key leaf type could be a numeric type.
XPath does not require a quoted string here, just YANG.

Old:  /top/list[idx="4"]
New: /top/list[idx=4]
 --VERIFIER NOTES-- 
 Hi,

To be clear, I am withdrawing this errata because existing implementations
may not accept a numeric literal in an instance-identifier.
I think this should be addressed in YANG 2.0 and this thread should be
recorded in the yang-next issue trac ker.

Andy

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Mon Oct 23 16:46:24 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4FA13AB3E for ; Mon, 23 Oct 2017 16:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 gPBdueqbhvcd for ; Mon, 23 Oct 2017 16:46:20 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0138.outbound.protection.outlook.com [104.47.0.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FA513A6D5 for ; Mon, 23 Oct 2017 16:46:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wGfs5IwZ0IkaC1rQyzZML/Gv2/A/gy7hdVty4DRqPBU=; b=oMg/D/VYU59OE4g5pzcda4YpijlmEO6K6mx+GW9nJaWjO05nH35OupDzDnkQi/bZ4EBmkZ3dgRqWmMW3VlwlGyXwKcruBw9FmGix/QY7eSKXBwv3bybfXc3AIeNQ8tIquO0jR04QgK4wtfas6tRMnH6vZpwKOsrnHm3TmiMpsX4=
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com (10.163.187.158) by AM3PR07MB1121.eurprd07.prod.outlook.com (10.163.187.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 23:46:17 +0000
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527]) by AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527%14]) with mapi id 15.20.0178.003; Mon, 23 Oct 2017 23:46:17 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] leafref to lists that contain system-controlled entries
Thread-Index: AdNETq1mxw6yfiPkS3eq6pji6usdqwB/ST6AAYLPhLA=
Date: Mon, 23 Oct 2017 23:46:16 +0000
Message-ID: 
References:  <20171016.085559.1980566759403577584.mbj@tail-f.com>
In-Reply-To: <20171016.085559.1980566759403577584.mbj@tail-f.com>
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=jason.sterne@nokia.com; 
x-originating-ip: [45.72.204.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1121; 6:W0WS9c5BRnH0RtVwiQwOZPkLKALwkIrt8ON1qpqmAspI3c5cKhCg6WPBQ6+r9mWwYWeZu89bs1Huz07JQiXaRRyzPj0rkc++x5M5PZ+e3OxvIPdJnvobBOgcn2b+VtNL3FAggXDGKzN6+3DpNSMvqDosyN5Q7LQrR424+IVNR/RWRxt+d8gxpJnjzlXZxXkw4xtEDiOIGro5eXSG2m627VDeLxpfv0R9xwbB17+aeFJvF2ZKHnXVlw5RXrJIPKEWHcij7/ra9KQLlT3aKwiBBS3B524PmMUE4yZaL4sxNUQWRlOuRkO6gGwnhMbZ3K9d5KbEzlcS8FbB90Py/6U3OycxOc9q3cpjHDwomoK+EfA=; 5:om4nipazJfYin5Yd5vD+tDpTDyQ2AuqCujdFEWJ9bP6RIqo54Lu48Bmw5rRuxlTdkmymRmOJU/yE7MEuJmIcxaU6TBRZHnD5B9jBFjbg/aLnpTxXR3Q1lYsJtVi+ucR0qDdBHYMYUGINlhCAgqeQH3SqT9tS9aO9VspoDLCMsso=; 24:bPZdzY3N5Z0OSAQRhFmmC0uBtiSjOWnWVX9MfZnOQQYKTy+yV6zNm56HHMUWdwFW05PZw5Gj4lORY6vkI0LPul8sUBFNIOq/u2+QFXL6fYU=; 7:FIB/IJnmxc2T4XEtjFlp1T8pUlDZQ2Y7bevPRIYBnCU9Y3F0uEZ0hwv6mDC5IjLhmVoCX8QxYEg0hOzIdHJ1uUvJHhvLAT6EWIngv6qEAYA2rjhuwKi57hi0FIMK2z2otEAv0lNW5dNjGwg6mbtEw8ZouG2gLHRn85LQh/MQ5W78arASEjJnG8F7a3VuqNWQOP9BUXsbDZLiUpPEUlGGqne3Qwh04Ej1iSUxp8+YWnV2xOMmY0cohViyoLJKuADF
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: f4e7f2bd-2bbf-468c-79e8-08d51a7040ef
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1121; 
x-ms-traffictypediagnostic: AM3PR07MB1121:
x-exchange-antispam-report-test: UriScan:(82608151540597);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231020)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1121; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1121; 
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(13464003)(24454002)(199003)(189002)(6436002)(66066001)(5660300001)(14454004)(316002)(2906002)(3660700001)(5250100002)(478600001)(4326008)(53546010)(99286003)(189998001)(55016002)(9686003)(6246003)(86362001)(53936002)(6506006)(3280700002)(229853002)(2900100001)(76176999)(74316002)(97736004)(7736002)(50986999)(305945005)(54356999)(81156014)(102836003)(81166006)(33656002)(8676002)(101416001)(7696004)(2950100002)(8936002)(25786009)(3846002)(6116002)(105586002)(6916009)(106356001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1121; H:AM3PR07MB1124.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)
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: f4e7f2bd-2bbf-468c-79e8-08d51a7040ef
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 23:46:16.9951 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1121
Archived-At: 
Subject: Re: [netmod] leafref to lists that contain system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 23:46:23 -0000

Thanks Martin.  Pls see below.
Jason

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Monday, October 16, 2017 2:56
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] leafref to lists that contain system-controlled ent=
ries
>=20
> "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
...snip...
> >
> > Another approach could be to actually have those system created
> > entries show up in running/candidate.  That would ensure that
> > references to those entries are valid.
>=20
> This works if the "system created entries" behave just like any other ent=
ry,
> i.e., a client (with proper access rigths) can modify and delete them.

[>>JTS] I think there are 2 classes of these "system created entries":
1) deletable entries
2) non-deletable entries

For deletable entries we had old discussions about those a few years ago on=
 the list where it was proposed these are modelled as "default startup data=
store" entries (i.e. instantiated by the system at startup time if there is=
 no startup datastore present).  They can then be deleted or modified by a =
client (and then a subsequent startup would not have those entries).

I'm more concerned here with non-deletable entries.  The entries themselves=
 would always be present (or perhaps only be present if some other part of =
the config is actually referencing them).   Some types of entrie may be mod=
ifiable (i.e. their leafs or other descendants can be changed) and some may=
 not be modifiable.

My responses below are based on non-deletable entries.

>=20
> If this is not the case, the next question is what happens if the client =
creates
> its own entry with the same name as a system created entry?  Is this ille=
gal,
> or will the user created entry override the system created entry?

[>>JTS] I think creation of an entry by a client would just be silently acc=
epted (and wouldn't affect what a client sees in a  since it wa=
s already present).  Similarly a deletion of an entry would be silently acc=
epted but the entry would still be there in a  response.
As mentioned above, some entries may have modifiable leafs and descendants.=
  Some may not (would return an error if attempting to set the value of a l=
eaf/descendant).

>=20
> Another question to think about is what happpens with user config that
> refers to such a system created entry if a new software image is loaded
> where the system created entry is no longer present?

[>>JTS] A few options:
1) only use this for entries that are never really expected to be obsoleted=
 (which may actually be a pretty likely case from what I've seen of these t=
ypes of entries)
2) have the startup config/datastore contain these entries (so they would b=
e created as explicit user entries if they don't exist as system created in=
 the future)
3) have upgrade code that accepts references to "old" entries and auto-conv=
ert them to some new entry (assuming one exists)

>=20
>=20
> /martin


From nobody Mon Oct 23 16:58:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844313AAC7 for ; Mon, 23 Oct 2017 16:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.69
X-Spam-Level: 
X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 (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 jTnSYQMngo4j for ; Mon, 23 Oct 2017 16:58:30 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0096.outbound.protection.outlook.com [104.47.1.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D6213A5BC for ; Mon, 23 Oct 2017 16:58:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JdjWBo3yWNZrC0QYndwNhr61ztdzrNIRL1F8ynZKfZI=; b=lbhQTbG7qJg4t4+7jO7+CkMU3fGXkqlbiXNe3GJjKu3lKrpfmrphUdSkvTFdxb3mwQ89jVVEK36+yEgIi7sxXu70ZM0WJXo3NXkSmBSTJ4p1vCIP1lKTUj9Gpp6IKBgpQHhMESiRhWYB9B+ZJwJ5wvfdwRqgsYmkY/3kl5vLHHY=
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com (10.163.187.158) by AM3PR07MB1121.eurprd07.prod.outlook.com (10.163.187.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 23:58:27 +0000
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527]) by AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527%14]) with mapi id 15.20.0178.003; Mon, 23 Oct 2017 23:58:27 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] leafref to lists that contain system-controlled entries
Thread-Index: AdNETq1mxw6yfiPkS3eq6pji6usdqwCHGGKAAXuDgKA=
Date: Mon, 23 Oct 2017 23:58:27 +0000
Message-ID: 
References:  <63575583-0baa-b0eb-c729-9772988b4f22@cisco.com>
In-Reply-To: <63575583-0baa-b0eb-c729-9772988b4f22@cisco.com>
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=jason.sterne@nokia.com; 
x-originating-ip: [45.72.204.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1121; 6:U/d4QKZSGThZT0GjqSbsFPV/TBQog4zpr2/4YvDP7UDq5NznBqs99xAaBSRC463wwWWdkybF9QK5L/eNloAi+caTjSVhp+ZWAo5tQP9FT7kHlUwJzm2H4l9gPAMOxXzyc09/tqiIto2y7+9d0uIJyybGcESQAIyvPLQoFZdFmGLOyQmrmraqUPxv1MsUkfL0490+yFXOPjfuziluCOLIWHOW9Z702zwIJOQ6fc0S+ykQncVTogSy3C1cSvNDAV3xMCgRvRPzDtZAvATtlKrCkDdGbSzbdE2X4cGhRs9uvbAbXe5MM5aX/sPIBUUUK6kb6zwqAAd0+gYDO0cUiBUZJG38DZ6ufPTEpOr+BDUqwhA=; 5:dg6O+ELd2oLtQuRvcncUFVifuUaWzIxHqVtWN2eZDqS05CaJL/1BHBRMAk6yw+ujdOHRrdyCDaGmEj0DUYaDHllMKyU/atALzXk6pUYd+lB8BNYavRx0klJbB3boezoRHaO1We7FSlbV8wCccQyZx3c3J6vzyI3ERQbyV6lzb/4=; 24:DtzrPOKClR0dGYSZOWrZaW39jt5c+IqmFWqtz1cAehtBfV+Epj/m/KiA0c9vBS/sKDHsxN58KLxanAWEyWkHdJqFtLcFGS5F5qL5X+oauSI=; 7:X0D4U0aptdBNswQXL9eVGd3xrwa6pPQ021aUpevzfwRJ9G5rqcgRZfje0MCslYi5QZmF6rnzaIQoHxk5IbFsfe4gc7h4uCKR8XCBVsjRoA7nIrd2Ab5zCCCjal/RlUadk1PohHheoYnOBcIpoQG1K39G/Q/9cF3OkUcesDIMWLK8tXN11P+LO6leJrlqwgsaNwIKBBJUtUO5ld3yHYtsfGbolxOfNRr9n9uhskLDeUniV5w2AXHnYkn3Xc8UDey4
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 6f0027f8-20a2-4724-2490-08d51a71f418
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1121; 
x-ms-traffictypediagnostic: AM3PR07MB1121:
x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(788757137089)(95692535739014)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1121; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1121; 
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(53754006)(199003)(51444003)(189002)(24454002)(8676002)(81156014)(102836003)(33656002)(81166006)(101416001)(229853002)(7736002)(50986999)(54356999)(97736004)(2900100001)(76176999)(74316002)(606006)(3846002)(6116002)(25786009)(8936002)(106356001)(68736007)(105586002)(7696004)(2950100002)(53546010)(790700001)(2501003)(189998001)(9686003)(55016002)(99286003)(6306002)(966005)(54896002)(236005)(316002)(5250100002)(2906002)(3660700001)(5660300001)(6436002)(66066001)(14454004)(478600001)(110136005)(6506006)(3280700002)(6246003)(53936002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1121; H:AM3PR07MB1124.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)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM3PR07MB112441E99B994BEFF00CF1809B460AM3PR07MB1124eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f0027f8-20a2-4724-2490-08d51a71f418
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 23:58:27.0861 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1121
Archived-At: 
Subject: Re: [netmod] leafref to lists that contain system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Oct 2017 23:58:33 -0000

--_000_AM3PR07MB112441E99B994BEFF00CF1809B460AM3PR07MB1124eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Rob.  Please see below.
Jason

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: Monday, October 16, 2017 6:40
To: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf=
.org
Subject: Re: [netmod] leafref to lists that contain system-controlled entri=
es


Hi Jason,

On 13/10/2017 19:43, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Hi all,

There are a few threads on the mailing list that touch on the concept of sy=
stem-controlled resources (mostly list entries):

https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0
https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w
https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0

A few drafts & RFCs also refer to the concept:
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
https://tools.ietf.org/html/rfc7223

Several vendor implementations have list entries (instance data) that are p=
opulated by the server and can be referenced (leafref) from other places in=
 the configuration.  These system entries are useful pre-created policies, =
interfaces, etc that can then be used (and referred-to) by operators in the=
ir explicit configuration.

If those entries are only expected to exist in the  datastore,=
 then in theory any references to them in user created configuration will c=
ause a validation problem in the candidate/running (missing leafref target)=
.

One solution discussed in the mailing lists is to change every reference to=
 lists that could contain a system created entry to a "require-instance fal=
se" leafref.  But then some useful validation is lost.  In many cases the m=
odel is more correctly "require-instance true" but the set of targets inclu=
des the system create entries.

I agree that this is not a good general solution for system created configu=
ration that is always expected to exist on the device because some of the u=
seful validation is lost.

But I think that this solution does work well were the system created entri=
es are truly dynamic in nature, e.g. it seems to work well for the topology=
 YANG module where the topology may be explicitly configured, but would mor=
e normally be learned dynamically from protocol interactions, or perhaps be=
 configured via a dynamic configuration protocol.

[>>JTS] OK - I think I follow you here.  You're saying that if there are re=
ferences to truly dynamic entries, then since those entries will come and g=
o (vs static bootup-time system entries that are always there), references =
to them will more likely be "require-instance false".   But that does mean =
the system has to allow references to non-existent entries, and you lose va=
lidation. You also risk errors like referencing a name that is just 1 char =
different from what you really wanted but the system can't tell you that yo=
u got it wrong.

Another solution discussed is to have the system created entries appear in =
the  datastore (as part of template/expansion).  That would make =
validation pass on the intended datastore, but then the candidate/running/s=
tartup datastores would not be valid (would be missing leafref targets if a=
ny part of the config refers to system created entries).  THis sounds simil=
ar to the problem that has been discussed in the past about the fact that t=
emplates (in the running) basically mean the running/candidate aren't neces=
sarily valid (until after template expansion, which means only the intended=
 would be valid).

I think that this solution is OK, but not necessarily ideal.

As you say, it means that // may not be valid,=
 which I see as quite a big down side.  Longer term, I think that it would =
be a good aim to allow the configuration to be validated off the device, if=
 a client desired to do so.




Another approach could be to actually have those system created entries sho=
w up in running/candidate.  That would ensure that references to those entr=
ies are valid.  But if the whole concept of templates just cause the runnin=
g/candidate to not be valid anyways maybe we wouldn't worry about the inval=
id aspect of references to system created list entries ?

I know that quite a few implementations do this today, but I'm generally no=
t a fan of the system modifying .  It seems that an overall archit=
ecture is much cleaner if  has a single source of truth and hence =
can be exclusively controlled by the client.

But I also like the approach where the client (rather than the device) expl=
icitly writes these default entries into the configuration, if they are ref=
erenced elsewhere by the configuration, to make the configuration "complete=
".  E.g. if part of the configuration references the loopback0 interface th=
en also explicitly add the necessary loopback0 configuration to instantiate=
 the "loopback0" interface.  When this configuration is pushed to the devic=
e (i.e. using merge or replace operation semantics) then the system should =
silently accept/ignore the explicit configuration to create the loopback0 i=
nterface if it already exists on the system.

[>>JTS] Yes - that is another option and I like it.  If I follow you correc=
tly, the server would never return these system entries in a  u=
nless the client/operator had already explicitly 'created' them.
So the operator has the option to make the system entries visible or not.

I think the server should still accept references to the system entries eve=
n if the client/operator hasn't explicitly created them.  The whole point i=
s that those system entries are there and waiting for operators to use them=
 from the start (without *having* to explicitly create or define them).   I=
n that case the references would be 'dangling' (unresolved) as far as an of=
fline validation is concerned (but a client could select to fix that by exp=
licitly defining any entries they want to reference).



At the moment, IETF, and other SDOs are busy defining standard YANG models,=
 but for those models to end up being truly generic they also need to have =
consistency about which bits of configuration are always expected to implic=
itly exist on the device.  E.g. considering the example above of configurat=
ion referencing loopback0: if some systems automatically create a loopback0=
 interface and others do not, then a generic configuration needs to handle =
both scenarios.

If IETF standardizes YANG configuration templates, then perhaps it would be=
 good to investigate whether some of these "useful default system propertie=
s" could instead be embodied into one or more standard device templates?  T=
hese templates could then be explicitly referenced in the  configu=
ration.  This may allow  to be small, but still allow it to be "co=
mplete" and able to be validated off the box.
[>>JTS] I'm not clear on this approach.
How would the templates be referenced in the  ?  Can you give me a=
n example ? (is this different than a direct reference to a system created =
entry that I am talking about ?)
How would this allow  to be small ? Do the templates contain the f=
ull definition of the system created entries ?


Thanks,
Rob




Rgds,
Jason





_______________________________________________

netmod mailing list

netmod@ietf.org

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


--_000_AM3PR07MB112441E99B994BEFF00CF1809B460AM3PR07MB1124eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thanks Rob.  P=
lease see below.


Jason


 








From:=
 Robert Wilton [mailto:rwilton@cisco.com]


Sent: Monday, October 16, 2017 6:40

To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>=
; netmod@ietf.org

Subject: Re: [netmod] leafref to lists that contain system-controlle=
d entries






 


Hi Jason,


 




On 13/10/2017 19:43, Sterne, Jason (Nokia - CA/Ottaw=
a) wrote:






Hi all,


 


There are a few threads on the mailing list that tou=
ch on the concept of system-controlled resources (mostly list entries):


 


https://mailarchive.ietf.org/arch/msg/netm=
od/3fTSHIh_MfHzmuDCoicAGiXA2E0


https://mailarchive.ietf.org/arch/msg/netm=
od/KIsSgKByQWpqYzA4i6Bwc8fuH3w


https://mailarchive.ietf.org/arch/msg/netm=
od/mjLJdiYErtNG41dJ5bJ5ji07cz0


 


A few drafts & RFCs also refer to the concept:


https://tools.ietf.org/html/draft-ietf-netmod-r=
evised-datastores-04


http=
s://tools.ietf.org/html/rfc7223


 


Several vendor implementations have list entries (in=
stance data) that are populated by the server and can be referenced (leafre=
f) from other places in the configuration.  These system entries are u=
seful pre-created policies, interfaces,
 etc that can then be used (and referred-to) by operators in their explicit=
 configuration.


 


If those entries are only expected to exist in the &=
lt;operational> datastore, then in theory any references to them in user=
 created configuration will cause a validation problem in the candidate/run=
ning (missing leafref target).


 


One solution discussed in the mailing lists is to ch=
ange every reference to lists that could contain a system created entry to =
a “require-instance false” leafref.  But then some useful =
validation is lost.  In many cases the model is more
 correctly “require-instance true” but the set of targets inclu=
des the system create entries.






I agree that this is not a good general solution for system created configu=
ration that is always expected to exist on the device because some of the u=
seful validation is lost.



But I think that this solution does work well were the system created entri=
es are truly dynamic in nature, e.g. it seems to work well for the topology=
 YANG module where the topology may be explicitly configured, but would mor=
e normally be learned dynamically
 from protocol interactions, or perhaps be configured via a dynamic configu=
ration protocol.


 


[>>JTS]=
 OK – I think I follow you here.  You’re saying that if th=
ere are references to truly dynamic entries, then since those entries will =
come and go (vs static bootup-time system entries that are
 always there), references to them will more likely be “require-insta=
nce false”.   But that does mean the system has to allow re=
ferences to non-existent entries, and you lose validation. You also risk er=
rors like referencing a name that is just 1 char different
 from what you really wanted but the system can’t tell you that you g=
ot it wrong.




 


Another solution discussed is to have the system cre=
ated entries appear in the <intended> datastore (as part of template/=
expansion).  That would make validation pass on the intended datastore=
, but then the candidate/running/startup datastores
 would not be valid (would be missing leafref targets if any part of the co=
nfig refers to system created entries).  THis sounds similar to the pr=
oblem that has been discussed in the past about the fact that templates (in=
 the running) basically mean the running/candidate
 aren’t necessarily valid (until after template expansion, which mean=
s only the intended would be valid).






I think that this solution is OK, but not necessarily ideal.



As you say, it means that <running>/<candidate>/<startup>=
 may not be valid, which I see as quite a big down side.  Longer term,=
 I think that it would be a good aim to allow the configuration to be valid=
ated off the device, if a client desired to do so.












 


Another approach could be to actually have those sys=
tem created entries show up in running/candidate.  That would ensure t=
hat references to those entries are valid.  But if the whole concept o=
f templates just cause the running/candidate
 to not be valid anyways maybe we wouldn’t worry about the invalid as=
pect of references to system created list entries ?






I know that quite a few implementations do this today, but I'm generally no=
t a fan of the system modifying <running>.  It seems that an ove=
rall architecture is much cleaner if <running> has a single source of=
 truth and hence can be exclusively controlled by
 the client.



But I also like the approach where the client (rather than the device) expl=
icitly writes these default entries into the configuration, if they are ref=
erenced elsewhere by the configuration, to make the configuration "com=
plete".  E.g. if part of the configuration
 references the loopback0 interface then also explicitly add the necessary =
loopback0 configuration to instantiate the "loopback0" interface.=
  When this configuration is pushed to the device (i.e. using merge or=
 replace operation semantics) then the system should
 silently accept/ignore the explicit configuration to create the loopback0 =
interface if it already exists on the system.


 


[>>JTS]=
 Yes – that is another option and I like it.  If I follow you co=
rrectly, the server would never return these system entries in a <get-co=
nfig> unless the client/operator had already explicitly
 ‘created’ them.   


So the operat=
or has the option to make the system entries visible or not.


 


I think the s=
erver should still accept references to the system entries even if the clie=
nt/operator hasn’t explicitly created them.  The whole point is =
that those system entries are there and waiting
 for operators to use them from the start (without *having* to explicitly c=
reate or define them).   In that case the references would be =
216;dangling’ (unresolved) as far as an offline validation is concern=
ed (but a client could select to fix that by explicitly
 defining any entries they want to reference).







At the moment, IETF, and other SDOs are busy defining standard YANG models,=
 but for those models to end up being truly generic they also need to have =
consistency about which bits of configuration are always expected to implic=
itly exist on the device.  E.g.
 considering the example above of configuration referencing loopback0: if s=
ome systems automatically create a loopback0 interface and others do not, t=
hen a generic configuration needs to handle both scenarios.



If IETF standardizes YANG configuration templates, then perhaps it would be=
 good to investigate whether some of these "useful default system prop=
erties" could instead be embodied into one or more standard device tem=
plates?  These templates could then be explicitly
 referenced in the <running> configuration.  This may allow <=
running> to be small, but still allow it to be "complete" and =
able to be validated off the box.


[>>JTS]=
 I’m not clear on this approach. 



How would the=
 templates be referenced in the <running> ?  Can you give me an =
example ? (is this different than a direct reference to a system created en=
try that I am talking about ?)


How would thi=
s allow <running> to be small ? Do the templates contain the full def=
inition of the system created entries ?






Thanks,

Rob












 


Rgds,


Jason


 











_______________________________________________


netmod mailing list


netmod@ietf.org

https://www.i=
etf.org/mailman/listinfo/netmod




 








--_000_AM3PR07MB112441E99B994BEFF00CF1809B460AM3PR07MB1124eurp_--


From nobody Mon Oct 23 18:42:56 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D1313AEFD for ; Mon, 23 Oct 2017 18:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnwsphhT917J for ; Mon, 23 Oct 2017 18:42:51 -0700 (PDT)
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 0C77B138BE2 for ; Mon, 23 Oct 2017 18:42:51 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id a16so22154541lfk.0 for ; Mon, 23 Oct 2017 18:42:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ovKfygR5RhQVOPeoL6SwNmzwLQhMcHi5jMKIjgJP/ck=; b=UKYPSzwzKyVp2dTlZOHHfFfS/VvIoZscD1v9uohwFwEXzu64dRoqP/Hs5qjvjZPsGp 6ZNJnoc4vnpnoYrGTGH4Fq7sUvTcPYNvmXVVnss/1XwIe1Rk4yyaB5h98N8/leJ57sSE wewM923DgOs10gpcgfKbEdTwb0bGtH2OhXTag9fC4SHGyVI8kzAg9VeWMUrbDR/8Lcf4 0k9UxHkYw5sDyFVriLsX17qjOBH75s5Eq1GMLd4Rw4u7FJqzq4yMP/XJlwiw0HD0fBy9 laNfgdXjFucUCulHNMCu2uoYLKzPzrppfVUZU55X9sMSkwwfUDbKeRQVw+SNL7H98KsY htTA==
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=ovKfygR5RhQVOPeoL6SwNmzwLQhMcHi5jMKIjgJP/ck=; b=UsFwzSJyZFI2VCOMEQHQMRkA5x4LCHGEK3d+D776XhbEX2SmBeW8qwPXCQ7pZ0EYmH JCOJhHrUlOsHj5eEifosrXmYcyS0lkE1q9XjHj/Py6AcfwF1F6kxV/bXI0L+rWF8gkIv TF3PvFOenlfip2iIvHeXD4Pph8swrwsmiKjZUYMYSYHOBLNZhL6Ffj5gHavKrDRE6cvG aVK5KW9woiXI1uLhqWGspIzyN/9+c+6cx1MDohE1Sm7rDO7pIAtZ+eF6IZQ5lNQREDUw APAhLDsFfKfr5+O4BhjRcos54nc/QcPjAntZ0wkfl8lCYZxd3e3fW3HrZIQrnrDz1Isg W70A==
X-Gm-Message-State: AMCzsaV3FbyeJex6pOxNkuHdWjAqDiqWiZDqGScJe+XTUi64IoS7ZzQ0 bcP1jv0QcVJZDyfHBLIUAzyVY9f3Vic0BLeyaLBLiA==
X-Google-Smtp-Source: ABhQp+TpJkgEo01w6t10swLRnDKBTv9jiGM+t2FEjqfD5/C4+dOqiSuUsL61ie4ZHv4MvlKPaC9Smy26ImrhHSrOV6o=
X-Received: by 10.25.156.66 with SMTP id f63mr4936761lfe.194.1508809369151; Mon, 23 Oct 2017 18:42:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Mon, 23 Oct 2017 18:42:48 -0700 (PDT)
In-Reply-To: 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com> 
From: Andy Bierman 
Date: Mon, 23 Oct 2017 18:42:48 -0700
Message-ID: 
To: Vladimir Vassilev 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11411bc67b81b1055c410eec"
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 01:42:55 -0000

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

On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev  wrote:

> On 10/23/2017 01:35 PM, Martin Bjorklund wrote:
>
> Vladimir Vassilev  wrote:
>>
>>> Hello,
>>>
>>> I would like to use the occasion of this Errata report to point out
>>> some additional issues with the instance-identifier type definition.
>>>
>>> IMO the instance-identifier built-in type has 2 additional problems
>>> that can be addressed with alternative and significantly more radical
>>> errata or fixed in a new version of YANG.:
>>>
>>> Problem 1: The obvious limitation inherited from Xpath 1.0 - inability
>>> to escape single or double quote characters. In Xpath world this
>>> limitation is worked around by use of concat() which is not available
>>> in the YANG 1.1 instance-identifier definition. 2 examples of this
>>> limitation:
>>>
>>> 1. It is impossible to create value of type instance-identifier
>>> referencing nodes in lists with key string values containing both a
>>> single and a double quote characters e.g. ..."It's
>>> valid string!".
>>>
>>> 2. Another example of the same problem would be a leaf of type
>>> instance-identifier referencing another leaf of type
>>> instance-identifier. With 2 references it works provided one is
>>> encoded with single quotes and the other with double but it is
>>> impossible to create third e.g.
>>>
>>> YANG:
>>>
>>>      list id-list {
>>>        key "id";
>>>
>>>        leaf id {
>>>            type instance-identifier;
>>>        }
>>>      }
>>>
>>>


Although the instance-identifier is problematic, it is rarely used at all,
let alone using it as a list key.

The XPath mixed-quotes problem is well-known, and the suggested
solution seems to be use the "concat" function

   /foo/bar[name=concat("It's a", ' "valid" string')]

Not very user friendly, is it?




> Data:
>>>
>>> * /top/id-list[id="/top/list[idx='4']"]
>>>
>>> * /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"] >> * proposed errata is also in effect>
>>>
>>> * 
>>>
>>> Problem 2: The instance-identifier type lacks canonical form (which
>>> makes it the only data type with implementation dependent
>>> representation at the data level ... think of the integer types
>>> allowing optional spaces between the digits). This is in fact the only
>>> built-in data type that allows the server implementation to change the
>>> configuration data replacing double quotes with single or the other
>>> way around. Inserting white spaces where you did not have them when
>>> the configuration was submitted. You can not simply read a
>>> configuration and use fast data comparison without schema support just
>>> because of this type. This is useless flexibility for simple data
>>> type.
>>>
>>> And this can be fixed if:
>>>
>>> 1. white spaces in instance-identifiers are prohibited
>>>
>>>

> 2. list key predicates are required in alphabetical order
>>>
>> Or perhaps use the order the keys are defined in the data model (the
>> "keys" statement").
>>
> This is an option but then the e.g. xpath2instid() function
> implementations will need schema support.
>
>

All the YANG tools I have seen generate the predicates in YANG key order.
The issue of canonical instance-identifier has been discussed many times,
and it is not possible to require the usage of specific prefixes in XML.
(Note that Lada fixed this for JSON in RFC 7951)

Only the string + expanded names can be properly compared in XML, not the
literal string
representing the XPath expression.


Vladimir
>


Andy



>
>> 3. strict quotation convention with escape option is added. (only
>>> 3. contradicts the sec. 9.13 ".. instance-identifier is a subset of
>>> the XPath ..")
>>>
>> I would like to change one more thing - I think it is unfortunate that
>> the lexical representation depends on the lexical context;
>> specifically that prefixes declared in the XML instance document is
>> used.  This applies also to identityref.  YANG 2.0 should use the same
>> encoding as JSON does for these datatypes.
>>
>>
>>
>> /martin
>>
>>
>>
>> Vladimir
>>>
>>> On 10/21/2017 08:16 PM, Andy Bierman wrote:
>>>
>>>>
>>>> On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise >>> > wrote:
>>>>
>>>>      Dear all,
>>>>
>>>>      Shall I validate this one?
>>>>
>>>>
>>>>
>>>> To add more context, this relates to the the RESTCONF JSON vs. XML
>>>> discussions in the NETCONF WG.
>>>>
>>>>    leaf broken {
>>>>        type union {
>>>>          type int32;
>>>>          type string;
>>>>       }
>>>>    }
>>>>
>>>> If all values of key leaf "broken" are sent as strings in an
>>>> instance-identifier,
>>>> then the int32 value may not match in all implementations, instead of
>>>> the string.
>>>> Allowing numbers as literals in addition to quoted strings allows the
>>>> sender
>>>> to be specific, and all implementations to be consistent.
>>>>
>>>>
>>>>      Regards, Benoit
>>>>
>>>>
>>>>
>>>> Andy
>>>>
>>>>          The following errata report has been submitted for RFC7950,
>>>>          "The YANG 1.1 Data Modeling Language".
>>>>
>>>>          --------------------------------------
>>>>          You may review the report below and at:
>>>>          http://www.rfc-editor.org/errata/eid5157
>>>>          
>>>>
>>>>          --------------------------------------
>>>>          Type: Technical
>>>>          Reported by: Andy Bierman >>>          >
>>>>
>>>>          Section: 14
>>>>
>>>>          Original Text
>>>>          -------------
>>>>             key-predicate-expr  = node-identifier *WSP "=" *WSP
>>>>          quoted-string
>>>>
>>>>          Corrected Text
>>>>          --------------
>>>>             key-predicate-expr  = node-identifier *WSP "=" *WSP
>>>>                   (quoted-string / integer-value / decimal-value)
>>>>
>>>>          Notes
>>>>          -----
>>>>          An instance identifier is forced to specify every key value to
>>>>          be a string
>>>>          even though the YANG key leaf type could be a numeric type.
>>>>          XPath does not require a quoted string here, just YANG.
>>>>
>>>>          Old:  /top/list[idx="4"]
>>>>          New: /top/list[idx=4]
>>>>
>>>>          Instructions:
>>>>          -------------
>>>>          This erratum is currently posted as "Reported". If necessary,
>>>>          please
>>>>          use "Reply All" to discuss whether it should be verified or
>>>>          rejected. When a decision is reached, the verifying party
>>>>          can log in to change the status and edit the report, if
>>>> necessary.
>>>>
>>>>          --------------------------------------
>>>>          RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>>>>          --------------------------------------
>>>>          Title               : The YANG 1.1 Data Modeling Language
>>>>          Publication Date    : August 2016
>>>>          Author(s)           : M. Bjorklund, Ed.
>>>>          Category            : PROPOSED STANDARD
>>>>          Source              : NETCONF Data Modeling Language
>>>>          Area                : Operations and Management
>>>>          Stream              : IETF
>>>>          Verifying Party     : IESG
>>>>          .
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>

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




On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev &l=
t;vladimir@tr=
anspacket.com> wrote:
On 10=
/23/2017 01:35 PM, Martin Bjorklund wrote:





Vladimir Vassilev <vladimir@transpacket.com> wrote:



Hello,



I would like to use the occasion of this Errata report to point out

some additional issues with the instance-identifier type definition.



IMO the instance-identifier built-in type has 2 additional problems

that can be addressed with alternative and significantly more radical

errata or fixed in a new version of YANG.:



Problem 1: The obvious limitation inherited from Xpath 1.0 - inability

to escape single or double quote characters. In Xpath world this

limitation is worked around by use of concat() which is not available

in the YANG 1.1 instance-identifier definition. 2 examples of this

limitation:



1. It is impossible to create value of type instance-identifier

referencing nodes in lists with key string values containing both a

single and a double quote characters e.g. ...<interface><name>&=
quot;It's

valid string!"</name></interface>.



2. Another example of the same problem would be a leaf of type

instance-identifier referencing another leaf of type

instance-identifier. With 2 references it works provided one is

encoded with single quotes and the other with double but it is

impossible to create third e.g.



YANG:



=C2=A0 =C2=A0 =C2=A0list id-list {

=C2=A0 =C2=A0 =C2=A0 =C2=A0key "id";



=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf id {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type instance-identifier;

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

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





Although the instance-identifier is problematic, it is ra=
rely used at all,
let alone using it as a list key.
The XPath mixed-quotes problem is well-known, and the suggested=

solution seems to be use the "concat" function

=C2=A0 =C2=A0/foo/bar[name=3Dconcat("It's a"=
;, ' "valid" string')]

Not very =
user friendly, is it?


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

Data:



* /top/id-list[id=3D"/top/list[idx=3D'4']"]



* /top/id-list[id=3D"/top/id-list[idx=3D'/top/list[idx=3D4]&#=
39;"] <assuming the

* proposed errata is also in effect>



* <next reference not possible with YANG 1.1>



Problem 2: The instance-identifier type lacks canonical form (which

makes it the only data type with implementation dependent

representation at the data level ... think of the integer types

allowing optional spaces between the digits). This is in fact the only

built-in data type that allows the server implementation to change the

configuration data replacing double quotes with single or the other

way around. Inserting white spaces where you did not have them when

the configuration was submitted. You can not simply read a

configuration and use fast data comparison without schema support just

because of this type. This is useless flexibility for simple data

type.



And this can be fixed if:



1. white spaces in instance-identifiers are prohibited


=C2=A0

2. list key predicates are required in alphabetical order



Or perhaps use the order the keys are defined in the data model (the

"keys" statement").



This is an option but then the e.g. xpath2instid() function implementations=
 will need schema support.




All the YANG tools I ha=
ve seen generate the predicates in YANG key order.
The issue of c=
anonical instance-identifier has been discussed many times,
and i=
t is not possible to require the usage of specific prefixes in XML.
(Note that Lada fixed this for JSON in RFC 7951)

Only the string + expanded names can be properly compared in XML, not the=
 literal string
representing the XPath expression.

=



Vladimir


Andy
=

=C2=A0







3. strict quotation convention with escape option is added. (only

3. contradicts the sec. 9.13 ".. instance-identifier is a subset of
the XPath ..")



I would like to change one more thing - I think it is unfortunate that

the lexical representation depends on the lexical context;

specifically that prefixes declared in the XML instance document is

used.=C2=A0 This applies also to identityref.=C2=A0 YANG 2.0 should use the=
 same

encoding as JSON does for these datatypes.







/martin









Vladimir



On 10/21/2017 08:16 PM, Andy Bierman wrote:





On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise <bclaise@cisco.com

<mailto:bclaise@c=
isco.com>> wrote:



=C2=A0 =C2=A0 =C2=A0Dear all,



=C2=A0 =C2=A0 =C2=A0Shall I validate this one?







To add more context, this relates to the the RESTCONF JSON vs. XML

discussions in the NETCONF WG.



=C2=A0 =C2=A0leaf broken {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type union {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

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

=C2=A0 =C2=A0}



If all values of key leaf "broken" are sent as strings in an

instance-identifier,

then the int32 value may not match in all implementations, instead of

the string.

Allowing numbers as literals in addition to quoted strings allows the

sender

to be specific, and all implementations to be consistent.





=C2=A0 =C2=A0 =C2=A0Regards, Benoit







Andy



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The following errata report has been subm=
itted for RFC7950,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The YANG 1.1 Data Modeling Language=
".



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------------------=
--

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0You may review the report below and at:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.rfc-editor.org/=
errata/eid5157

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.rfc-editor.=
org/errata/eid5157>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------------------=
--

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Type: Technical

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reported by: Andy Bierman <andy@yumaworks.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:andy@yumaworks.com>>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section: 14



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Original Text

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node=
-identifier *WSP "=3D" *WSP

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0quoted-string



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Corrected Text

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node=
-identifier *WSP "=3D" *WSP

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (quoted-stri=
ng / integer-value / decimal-value)



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Notes

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An instance identifier is forced to speci=
fy every key value to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be a string

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0even though the YANG key leaf type could =
be a numeric type.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0XPath does not require a quoted string he=
re, just YANG.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Old:=C2=A0 /top/list[idx=3D"4"]=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0New: /top/list[idx=3D4]



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Instructions:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This erratum is currently posted as "=
;Reported". If necessary,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0please

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use "Reply All" to discuss whet=
her it should be verified or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rejected. When a decision is reached, the=
 verifying party

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can log in to change the status and edit =
the report, if necessary.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------------------=
--

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC7950 (draft-ietf-netmod-rfc6020bis-14)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------------------------------------=
--

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0: The YANG 1.1 Data Modeling Language

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Publication Date=C2=A0 =C2=A0 : August 20=
16

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0: M. Bjorklund, Ed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 : PROPOSED STANDARD

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 : NETCONF Data Modeling Language

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 : Operations and Management

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 : IETF

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG=


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











_______________________________________________

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










--001a11411bc67b81b1055c410eec--


From nobody Tue Oct 24 02:03:11 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D669913DBC8 for ; Tue, 24 Oct 2017 02:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, 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 LMzodZIFQZWI for ; Tue, 24 Oct 2017 02:03:07 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603C413C2F9 for ; Tue, 24 Oct 2017 02:03:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8851; q=dns/txt; s=iport; t=1508835786; x=1510045386; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=h/umZ5uDijfHNgIPkPNNzlPnaquXZczcCcN9Hf0H/hE=; b=QTilhCkaD2oLK6fT05TaTxJg3zWabGohamG6e60BweiXdYVLrwWLqDZH +Sz/dM/81C7cv27ufznleOiyK6Apx0Pfp9+XdGskzkhYYQ8W4x2XCsVdi ls0QaQ2OWrZexvP+EL4exlkdnbouKFvjbYcg7UGXxdtJfjlSQNp5wwSOg w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQAHAe9Z/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTEng3qLE5AnJpB4hUKCEQqFOwKFHBcBAgEBAQEBAQFrKIUeAQU?= =?us-ascii?q?jVhAJAhgnAwICRhEGAQwGAgEBF4oFimGdZ4InJosAAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYMug1eCEguCdoE8hl2CYQWKJIcskB2UdYQJh2OHOI4ah2WBOSABNoF?= =?us-ascii?q?bNCEIHRVJgmSCXAwQgWg/Nos3AQEB?=
X-IronPort-AV: E=Sophos;i="5.43,427,1503360000";  d="scan'208,217";a="658276929"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 09:03:04 +0000
Received: from [10.63.23.81] (dhcp-ensft1-uk-vla370-10-63-23-81.cisco.com [10.63.23.81]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9O933JD001909; Tue, 24 Oct 2017 09:03:04 GMT
To: Andy Bierman , Vladimir Vassilev 
Cc: "netmod@ietf.org" 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>  
From: Robert Wilton 
Message-ID: <228b6545-0310-8e62-d80b-e9888fc0ba5a@cisco.com>
Date: Tue, 24 Oct 2017 10:03:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------FBF7E99435D85940D06469C2"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 09:03:10 -0000

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



On 24/10/2017 02:42, Andy Bierman wrote:
>
>
> On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev 
> > wrote:
>
>     On 10/23/2017 01:35 PM, Martin Bjorklund wrote:
>
>         Vladimir Vassilev          > wrote:
>
>             Hello,
>
>             I would like to use the occasion of this Errata report to
>             point out
>             some additional issues with the instance-identifier type
>             definition.
>
>             IMO the instance-identifier built-in type has 2 additional
>             problems
>             that can be addressed with alternative and significantly
>             more radical
>             errata or fixed in a new version of YANG.:
>
>             Problem 1: The obvious limitation inherited from Xpath 1.0
>             - inability
>             to escape single or double quote characters. In Xpath
>             world this
>             limitation is worked around by use of concat() which is
>             not available
>             in the YANG 1.1 instance-identifier definition. 2 examples
>             of this
>             limitation:
>
>             1. It is impossible to create value of type
>             instance-identifier
>             referencing nodes in lists with key string values
>             containing both a
>             single and a double quote characters e.g.
>             ..."It's
>             valid string!".
>
>             2. Another example of the same problem would be a leaf of type
>             instance-identifier referencing another leaf of type
>             instance-identifier. With 2 references it works provided
>             one is
>             encoded with single quotes and the other with double but it is
>             impossible to create third e.g.
>
>             YANG:
>
>                  list id-list {
>                    key "id";
>
>                    leaf id {
>                        type instance-identifier;
>                    }
>                  }
>
>
>
>
> Although the instance-identifier is problematic, it is rarely used at all,
> let alone using it as a list key.
>
> The XPath mixed-quotes problem is well-known, and the suggested
> solution seems to be use the "concat" function
>
>    /foo/bar[name=concat("It's a", ' "valid" string')]
>
> Not very user friendly, is it?

I suspect that this is unlikely to be popular, but I think that it would 
be nice if there was a plan to move away from XPath, and define a YANG 
specific equivalent instead.  Broadly it could follow the same format as 
XPath but be defined against a YANG data tree, and bind to YANG's 
types.  We could get rid of the bits of XPath that aren't really helpful 
or meaningful for YANG, and add in some new functionality/fixes that are 
helpful to solve the YANG specific problems related to path expressions.

Rob


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


  
    
  
  
    


    

    

    
On 24/10/2017 02:42, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Oct 23, 2017 at 4:57 AM,
            Vladimir Vassilev <vladimir@transpacket.com>
            wrote:

            
On
              10/23/2017 01:35 PM, Martin Bjorklund wrote:

              

              

                Vladimir Vassilev <vladimir@transpacket.com>
                wrote:

                

                  Hello,

                  

                  I would like to use the occasion of this Errata report
                  to point out

                  some additional issues with the instance-identifier
                  type definition.

                  

                  IMO the instance-identifier built-in type has 2
                  additional problems

                  that can be addressed with alternative and
                  significantly more radical

                  errata or fixed in a new version of YANG.:

                  

                  Problem 1: The obvious limitation inherited from Xpath
                  1.0 - inability

                  to escape single or double quote characters. In Xpath
                  world this

                  limitation is worked around by use of concat() which
                  is not available

                  in the YANG 1.1 instance-identifier definition. 2
                  examples of this

                  limitation:

                  

                  1. It is impossible to create value of type
                  instance-identifier

                  referencing nodes in lists with key string values
                  containing both a

                  single and a double quote characters e.g.
                  ...<interface><name>"It's

                  valid string!"</name></interface>.

                  

                  2. Another example of the same problem would be a leaf
                  of type

                  instance-identifier referencing another leaf of type

                  instance-identifier. With 2 references it works
                  provided one is

                  encoded with single quotes and the other with double
                  but it is

                  impossible to create third e.g.

                  

                  YANG:

                  

                       list id-list {

                         key "id";

                  

                         leaf id {

                             type instance-identifier;

                         }

                       }

                  

                

              

            

            


            

            


            

            


            

            
Although the instance-identifier is problematic, it is
              rarely used at all,

            
let alone using it as a list key.

            


            

            
The XPath mixed-quotes problem is well-known, and the
              suggested

            
solution seems to be use the "concat" function

            


            

            
   /foo/bar[name=concat("It's a", ' "valid" string')]

            


            

            
Not very user friendly, is it?

          

        

      

    

    

    I suspect that this is unlikely to be popular, but I think that it
    would be nice if there was a plan to move away from XPath, and
    define a YANG specific equivalent instead.  Broadly it could follow
    the same format as XPath but be defined against a YANG data tree,
    and bind to YANG's types.  We could get rid of the bits of XPath
    that aren't really helpful or meaningful for YANG, and add in some
    new functionality/fixes that are helpful to solve the YANG specific
    problems related to path expressions.

    

    Rob

    

  


--------------FBF7E99435D85940D06469C2--


From nobody Tue Oct 24 03:41:23 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106F313F3A3 for ; Tue, 24 Oct 2017 03:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgo2ecJV4lrf for ; Tue, 24 Oct 2017 03:41:22 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0789813DD35 for ; Tue, 24 Oct 2017 03:41:21 -0700 (PDT)
Received: from [10.147.40.122] (unknown [173.38.220.50]) by mail.tail-f.com (Postfix) with ESMTPSA id 8CABA1AE0426; Tue, 24 Oct 2017 12:41:19 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jan Lindblad 
In-Reply-To: <228b6545-0310-8e62-d80b-e9888fc0ba5a@cisco.com>
Date: Tue, 24 Oct 2017 12:41:16 +0200
Cc: Andy Bierman , Vladimir Vassilev , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>   <228b6545-0310-8e62-d80b-e9888fc0ba5a@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 10:41:23 -0000

Rob,

>> The XPath mixed-quotes problem is well-known, and the suggested
>> solution seems to be use the "concat" function
>>=20
>>    /foo/bar[name=3Dconcat("It's a", ' "valid" string')]
>>=20
>> Not very user friendly, is it?
>=20
> I suspect that this is unlikely to be popular, but I think that it =
would be nice if there was a plan to move away from XPath, and define a =
YANG specific equivalent instead.  Broadly it could follow the same =
format as XPath but be defined against a YANG data tree, and bind to =
YANG's types.  We could get rid of the bits of XPath that aren't really =
helpful or meaningful for YANG, and add in some new functionality/fixes =
that are helpful to solve the YANG specific problems related to path =
expressions.

The idea has some merit, and I understand the background for this =
sentiment. Trying not to be on either side at this point, I would just =
like to point out that this would mean a considerable amount of work. =
Both for the WG to define this language, and later, for implementors to =
implement it.

/jan


From nobody Tue Oct 24 03:57:05 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ECA13F3AE for ; Tue, 24 Oct 2017 03:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, 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 KiZ7h12V-RJv for ; Tue, 24 Oct 2017 03:57:02 -0700 (PDT)
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 2E2F513F3AB for ; Tue, 24 Oct 2017 03:57:01 -0700 (PDT)
Received: from birdie44 (unknown [IPv6:2001:1488:fffe:6:60f4:58ff:febf:c637]) by mail.nic.cz (Postfix) with ESMTPSA id 497D1600BA for ; Tue, 24 Oct 2017 12:56:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1508842618; bh=EDTDUp1cci7Wr9V4EVkMpWTl8VWLmNcvz/eAxkwNZyk=; h=From:To:Date; b=ns7JY4tRTRemsUi3vgy6YjsEI2RAO1JhUUCnHO3EO1LdJeB/Jo3Hp3lQOry/B5DVB ioO8635gWG8Qq06+IaEHTcqj4SCrOvnIfBCq4wO9MUJGaut4flOGpcirgJKQVPzc7F MWo6ByEdsxwSk4Jcxy8k2ouenwU36/TT7e82LBGg=
Message-ID: <1508842677.31338.21.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 24 Oct 2017 12:57:57 +0200
In-Reply-To: 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>   <228b6545-0310-8e62-d80b-e9888fc0ba5a@cisco.com> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.1 
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] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 10:57:04 -0000

On Tue, 2017-10-24 at 12:41 +0200, Jan Lindblad wrote:
> Rob,
> 
> > > The XPath mixed-quotes problem is well-known, and the suggested
> > > solution seems to be use the "concat" function
> > > 
> > >    /foo/bar[name=concat("It's a", ' "valid" string')]
> > > 
> > > Not very user friendly, is it?
> > 
> > I suspect that this is unlikely to be popular, but I think that it would be nice if there was a plan to move away from XPath, and define a YANG specific equivalent instead.  Broadly it could follow the same format as XPath but be defined against a YANG data tree, and bind to YANG's types.  We could get rid of the bits of XPath that aren't really helpful or meaningful for YANG, and add in some new functionality/fixes that are helpful to solve the YANG specific problems related to path expressions.
> 
> The idea has some merit, and I understand the background for this sentiment. Trying not to be on either side at this point, I would just like to point out that this would mean a considerable amount of work. Both for the WG to define this language, and later, for implementors to implement it.

I agree, it is not a low-hanging fruit, and IETF isn't the right place to
develop such things.

It is actually a shame that so many clever technologies are sort of wasted
because they are tightly connected to XML (instead of being applicable to
general tree-like data).

It is perhaps also worth noting that XPath 1.0 spec now includes a note that
basically declares it deprecated and unmaintained.

Lada

> 
> /jan
> 
> _______________________________________________
> 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 Oct 24 04:10:02 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A9D13F3A3 for ; Tue, 24 Oct 2017 04:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1Fj40DG4h14 for ; Tue, 24 Oct 2017 04:09:59 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D1137A70 for ; Tue, 24 Oct 2017 04:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2410; q=dns/txt; s=iport; t=1508843398; x=1510052998; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WbPBvn+01D/Aivqs3p5iDb6S0k2vaaw0SaKSUMXZxmE=; b=HiPqlYhLSlYRZNxZkA8wYW9KpzF35Crd4RWKEFu/NqV/n4K0jIYFZAQL KSEtyEgFndEwVQ8Wpgjefya0xy96Bv1jVLUdmaJ6pR7ZZpFnevMqjBnlA GCTVX1ekN5MrUgjjUR9ZxuX0/SL1+WwGk3lG/3UgG1Dc7jhyux2Wj9+U3 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQC8Hu9Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTGEIYsTkE2YSwqFOwKFIRUBAgEBAQEBAQFrKIUeAQUjDwEFQRA?= =?us-ascii?q?LGAICJgICVwYNCAEBF4oFp2+CJ4sjAQEBAQEBAQEBAQEBAQEBAQEhgQ+CH4NXg?= =?us-ascii?q?hKCTDWBPIZdgmEFkVCQHZR1i2yHOI4ah2WBOTUigVs0IQgdFYMuglsMEIFoP4t?= =?us-ascii?q?tAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,427,1503360000"; d="scan'208";a="655648481"
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; 24 Oct 2017 11:09:56 +0000
Received: from [10.63.23.81] (dhcp-ensft1-uk-vla370-10-63-23-81.cisco.com [10.63.23.81]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9OB9uwO011771; Tue, 24 Oct 2017 11:09:56 GMT
To: Jan Lindblad 
Cc: Andy Bierman , Vladimir Vassilev , "netmod@ietf.org" 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>   <228b6545-0310-8e62-d80b-e9888fc0ba5a@cisco.com> 
From: Robert Wilton 
Message-ID: <82b9ceac-83e0-b468-893a-8338973a766d@cisco.com>
Date: Tue, 24 Oct 2017 12:09:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 11:10:00 -0000

Hi Jan,

On 24/10/2017 11:41, Jan Lindblad wrote:
> Rob,
>
>>> The XPath mixed-quotes problem is well-known, and the suggested
>>> solution seems to be use the "concat" function
>>>
>>>     /foo/bar[name=concat("It's a", ' "valid" string')]
>>>
>>> Not very user friendly, is it?
>> I suspect that this is unlikely to be popular, but I think that it would be nice if there was a plan to move away from XPath, and define a YANG specific equivalent instead.  Broadly it could follow the same format as XPath but be defined against a YANG data tree, and bind to YANG's types.  We could get rid of the bits of XPath that aren't really helpful or meaningful for YANG, and add in some new functionality/fixes that are helpful to solve the YANG specific problems related to path expressions.
> The idea has some merit, and I understand the background for this sentiment. Trying not to be on either side at this point, I would just like to point out that this would mean a considerable amount of work. Both for the WG to define this language, and later, for implementors to implement it.
Yes, definitely agree to both of these.

To ease implementation, then possibly a mapping (ideally supported with 
an open source conversion tool) could be defined between XPath and a new 
YANG path language.  How successfully this would be depends on how much 
a YANG path language differs/evolves beyond XPath.

One example of this was the NETMOD discussion [Retrieving Information 
Pointed by leafref].  It is possible to come up with an XPath expression 
that returns the required entries, but it required union operators at 
the top level of the expression, which is probably harder to implement 
efficiently (i.e. it is fine if you can determine that the two branches 
don't return overlapping entries, otherwise you have to collate and 
remove duplicates before returning them).  If it was possible to move 
the union operator further down the expression path then that might more 
closely map to an efficient implementation.

E.g. something more like this:

   /te/tunnels/(tunnel[name='foo'] | 
tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnels/supporting-tunnel/name]) 


Instead of this:

   /te/tunnels/tunnel[name='foo'] |
/te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnels/supporting-tunnel/name]

Thanks,
Rob

>
> /jan
>
> .
>


From nobody Tue Oct 24 05:26:32 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B6C13F741 for ; Tue, 24 Oct 2017 05:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.489
X-Spam-Level: 
X-Spam-Status: No, score=-14.489 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_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_B8eJwckIPv for ; Tue, 24 Oct 2017 05:26:28 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2534B13F746 for ; Tue, 24 Oct 2017 05:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36818; q=dns/txt; s=iport; t=1508847987; x=1510057587; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=0vrb2CP6ovwV2wBeOB6PTtfv2N0RUkIauerF6+hQPPg=; b=dTrr6C3zzAFXBDO9lUGuGwPcJFOa7+wZzb/cJik5ATduwW0QCyyAMkz4 lf7U4qhXgxDTFSyWVLB4EX+x0/U046CoqVQt6jsyXU8qFqRMJrl4b54Az AwBxLpz8ZMj6UrUs1AQjKAzBllcGavI9Y6nMw777IBLy+dkSGyK1iuG+o Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAAB6MO9Z/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9CgRJuJ44ZdI4iggUme5U/EIF+AwoYAQyER08ChR4YAQIBAQE?= =?us-ascii?q?BAQEBayiFHQEBAQEDAQEYE0EbCxEBAwEBASABBgcnHwMGCAYBDAYCAQEXigUQA?= =?us-ascii?q?6k/Jop9AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMug1eBaSkLgkE1gkSCKQJMhT8?= =?us-ascii?q?FiiaHKocjiHqHZY0QghWFeoNdhziOGodlgTkfOIFbNCEIHRVJgmQJhFc/Noh1L?= =?us-ascii?q?IIWAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,427,1503360000";  d="scan'208,217";a="698218568"
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; 24 Oct 2017 12:26:24 +0000
Received: from [10.63.23.81] (dhcp-ensft1-uk-vla370-10-63-23-81.cisco.com [10.63.23.81]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9OCQOr9020027; Tue, 24 Oct 2017 12:26:24 GMT
To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" 
References:  <63575583-0baa-b0eb-c729-9772988b4f22@cisco.com> 
From: Robert Wilton 
Message-ID: <2e520b70-9f5b-3101-d0fa-ae83dfe34fb6@cisco.com>
Date: Tue, 24 Oct 2017 13:26:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------73D9F6E840F3CA1D76EBC198"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] leafref to lists that contain system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 12:26:31 -0000

This is a multi-part message in MIME format.
--------------73D9F6E840F3CA1D76EBC198
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jason,

Please see further comments inline ...


On 24/10/2017 00:58, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>
> Thanks Rob. Please see below.
>
> Jason
>
> *From:*Robert Wilton [mailto:rwilton@cisco.com]
> *Sent:* Monday, October 16, 2017 6:40
> *To:* Sterne, Jason (Nokia - CA/Ottawa) ; 
> netmod@ietf.org
> *Subject:* Re: [netmod] leafref to lists that contain 
> system-controlled entries
>
> Hi Jason,
>
> On 13/10/2017 19:43, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>
>     Hi all,
>
>     There are a few threads on the mailing list that touch on the
>     concept of system-controlled resources (mostly list entries):
>
>     https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0
>
>     https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w
>
>     https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0
>
>     A few drafts & RFCs also refer to the concept:
>
>     https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
>
>     https://tools.ietf.org/html/rfc7223
>
>     Several vendor implementations have list entries (instance data)
>     that are populated by the server and can be referenced (leafref)
>     from other places in the configuration.  These system entries are
>     useful pre-created policies, interfaces, etc that can then be used
>     (and referred-to) by operators in their explicit configuration.
>
>     If those entries are only expected to exist in the 
>     datastore, then in theory any references to them in user created
>     configuration will cause a validation problem in the
>     candidate/running (missing leafref target).
>
>     One solution discussed in the mailing lists is to change every
>     reference to lists that could contain a system created entry to a
>     “require-instance false” leafref.  But then some useful validation
>     is lost. In many cases the model is more correctly
>     “require-instance true” but the set of targets includes the system
>     create entries.
>
>
> I agree that this is not a good general solution for system created 
> configuration that is always expected to exist on the device because 
> some of the useful validation is lost.
>
> But I think that this solution does work well were the system created 
> entries are truly dynamic in nature, e.g. it seems to work well for 
> the topology YANG module where the topology may be explicitly 
> configured, but would more normally be learned dynamically from 
> protocol interactions, or perhaps be configured via a dynamic 
> configuration protocol.
>
> *//*
>
> */[>>JTS] OK – I think I follow you here.  You’re saying that if there 
> are references to truly dynamic entries, then since those entries will 
> come and go (vs static bootup-time system entries that are always 
> there), references to them will more likely be “require-instance 
> false”.   But that does mean the system has to allow references to 
> non-existent entries, and you lose validation. You also risk errors 
> like referencing a name that is just 1 char different from what you 
> really wanted but the system can’t tell you that you got it wrong./*
>

Yes.  I don't think that you can solve this during existing YANG 
datastore validation, as it is defined today.

But I also think that NETCONF/YANG is potentially missing an RPC that is 
a step beyond validation, but before actually applying configuration.

YANG and the NMDA datastores draft makes it clear that both  
and  are always valid datastores. This means that the 
validation rules for these datastores really should not depend on the 
current hardware in a device if that hardware could be removed or 
change.  Otherwise, if you allow validation to depend on the current 
hardware capabilities, then if someone pulls out a linecard, that would 
cause a previously valid configuration to immediately become invalid, 
violating the rule that / are always valid.

I think that a potential solution to this problem, is that a new NETCONF 
RPC could be defined that is a "" 
operation.   Processing during this new RPC would be able to check 
against current system resources, current hardware capabilities, etc, 
and would be designed to indicate whether the system expects (but does 
not guarantee) that the configuration would completely apply 
successfully without any errors or unapplied configuration.  
Configuration datastores would not have to always conform to this 
constraint, so that if an operator changed or removed a linecard, the 
configuration would still be "valid" (as per NMDA and RFC7950 rules) but 
would fail a subsequent "should-successfully-apply" check.



> *//*
>
>     Another solution discussed is to have the system created entries
>     appear in the  datastore (as part of
>     template/expansion).  That would make validation pass on the
>     intended datastore, but then the candidate/running/startup
>     datastores would not be valid (would be missing leafref targets if
>     any part of the config refers to system created entries).  THis
>     sounds similar to the problem that has been discussed in the past
>     about the fact that templates (in the running) basically mean the
>     running/candidate aren’t necessarily valid (until after template
>     expansion, which means only the intended would be valid).
>
>
> I think that this solution is OK, but not necessarily ideal.
>
> As you say, it means that // may not be 
> valid, which I see as quite a big down side.  Longer term, I think 
> that it would be a good aim to allow the configuration to be validated 
> off the device, if a client desired to do so.
>
>
>
>     Another approach could be to actually have those system created
>     entries show up in running/candidate.  That would ensure that
>     references to those entries are valid.  But if the whole concept
>     of templates just cause the running/candidate to not be valid
>     anyways maybe we wouldn’t worry about the invalid aspect of
>     references to system created list entries ?
>
>
> I know that quite a few implementations do this today, but I'm 
> generally not a fan of the system modifying .  It seems that 
> an overall architecture is much cleaner if  has a single 
> source of truth and hence can be exclusively controlled by the client.
>
> But I also like the approach where the client (rather than the device) 
> explicitly writes these default entries into the configuration, if 
> they are referenced elsewhere by the configuration, to make the 
> configuration "complete".  E.g. if part of the configuration 
> references the loopback0 interface then also explicitly add the 
> necessary loopback0 configuration to instantiate the "loopback0" 
> interface. When this configuration is pushed to the device (i.e. using 
> merge or replace operation semantics) then the system should silently 
> accept/ignore the explicit configuration to create the loopback0 
> interface if it already exists on the system.
>
> *//*
>
> */[>>JTS] Yes – that is another option and I like it.  If I follow you 
> correctly, the server would never return these system entries in a 
>  unless the client/operator had already explicitly 
> ‘created’ them. /*
>
> */So the operator has the option to make the system entries visible or 
> not./*
>
Yes, exactly.

/*
*/
>
> *//*
>
> *//*
>
> */I think the server should still accept references to the system 
> entries even if the client/operator hasn’t explicitly created them.  
> The whole point is that those system entries are there and waiting for 
> operators to use them from the start (without *having* to explicitly 
> create or define them).   In that case the references would be 
> ‘dangling’ (unresolved) as far as an offline validation is concerned 
> (but a client could select to fix that by explicitly defining any 
> entries they want to reference)./*
>
I think that this is OK.

Effectively, I see that being like a static system provided template for 
configuration that is merged with  to form , which is 
then validated.


> *//*
>
>
>
>
> At the moment, IETF, and other SDOs are busy defining standard YANG 
> models, but for those models to end up being truly generic they also 
> need to have consistency about which bits of configuration are always 
> expected to implicitly exist on the device.  E.g. considering the 
> example above of configuration referencing loopback0: if some systems 
> automatically create a loopback0 interface and others do not, then a 
> generic configuration needs to handle both scenarios.
>
> If IETF standardizes YANG configuration templates, then perhaps it 
> would be good to investigate whether some of these "useful default 
> system properties" could instead be embodied into one or more standard 
> device templates?  These templates could then be explicitly referenced 
> in the  configuration.  This may allow  to be small, 
> but still allow it to be "complete" and able to be validated off the box.
>
> */[>>JTS] I’m not clear on this approach. /*
>
OK, so this is just an idea:

1) Assume a YANG extension is defined to allow templates to be defined.
2) Further, assume that there is a way to store, and uniquely name some 
of those templates in a standard place.

So, perhaps IETF could define a template like this, which is stored as a 
well defined place:



Now, when it comes to the configuration file for your device, it could 
look like this:
   
http://yang-templates.ietf.org/ietf-basic-router-v1

     ... rest of config as normal.
   

So, the expanded configuration would include the explicit configuration 
for Loopback0 and Null0 interfaces, but that would be pulled via use of 
a remote template (the contents of which is probably already cached on 
the device).


> *//*
>
> */How would the templates be referenced in the  ?  Can you 
> give me an example ? (is this different than a direct reference to a 
> system created entry that I am talking about ?)/*
>
The above is just an idea.  Normally I would expect configuration 
templates to be defined in the running configuration.  But here I was 
considering the idea that a template is predefined in some way, and then 
referenced, so that it doesn't have to be provided inline in the running 
configuration.


> *//*
>
> */How would this allow  to be small ? Do the templates 
> contain the full definition of the system created entries ?/*
>
Yes, I was assuming that the template could contain what might normally 
be represented as system created entries today.  Standard templates 
could either be defined by SDOs, vendors, or operators, as long as there 
is a way to reference them.

Thanks,
Rob


> *//*
>
>
>
> Thanks,
> Rob
>
>
>
>     Rgds,
>
>     Jason
>
>
>
>
>     _______________________________________________
>
>     netmod mailing list
>
>     netmod@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/netmod
>


--------------73D9F6E840F3CA1D76EBC198
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Jason,

    
Please see further comments inline ...

    

    

    
On 24/10/2017 00:58, Sterne, Jason
      (Nokia - CA/Ottawa) wrote:

    

    

      
      
      
      

        
Thanks Rob. 
            Please see below.

        
Jason

        
 

        

          

            

              
From: Robert Wilton
                  [mailto:rwilton@cisco.com]
                  

                  Sent: Monday, October 16, 2017 6:40

                  To: Sterne, Jason (Nokia - CA/Ottawa)
                  <jason.sterne@nokia.com>; netmod@ietf.org

                  Subject: Re: [netmod] leafref to lists that
                  contain system-controlled entries

            

          

          
 

          
Hi Jason,

          
 

          

            
On 13/10/2017 19:43, Sterne, Jason
              (Nokia - CA/Ottawa) wrote:

          

          

            
Hi all,

            
 

            
There are a few threads on the mailing
              list that touch on the concept of system-controlled
              resources (mostly list entries):

            
 

            
https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0

            
https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w

            
https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0

            
 

            
A few drafts & RFCs also refer to
              the concept:

            
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04

            
https://tools.ietf.org/html/rfc7223

            
 

            
Several vendor implementations have
              list entries (instance data) that are populated by the
              server and can be referenced (leafref) from other places
              in the configuration.  These system entries are useful
              pre-created policies, interfaces, etc that can then be
              used (and referred-to) by operators in their explicit
              configuration.

            
 

            
If those entries are only expected to
              exist in the <operational> datastore, then in theory
              any references to them in user created configuration will
              cause a validation problem in the candidate/running
              (missing leafref target).

            
 

            
One solution discussed in the mailing
              lists is to change every reference to lists that could
              contain a system created entry to a “require-instance
              false” leafref.  But then some useful validation is lost. 
              In many cases the model is more correctly
              “require-instance true” but the set of targets includes
              the system create entries.

          

          


            I agree that this is not a good general solution for system
            created configuration that is always expected to exist on
            the device because some of the useful validation is lost.

            

            But I think that this solution does work well were the
            system created entries are truly dynamic in nature, e.g. it
            seems to work well for the topology YANG module where the
            topology may be explicitly configured, but would more
            normally be learned dynamically from protocol interactions,
            or perhaps be configured via a dynamic configuration
            protocol.

          
 

          
[>>JTS]
                  OK – I think I follow you here.  You’re saying that if
                  there are references to truly dynamic entries, then
                  since those entries will come and go (vs static
                  bootup-time system entries that are always there),
                  references to them will more likely be
                  “require-instance false”.   But that does mean the
                  system has to allow references to non-existent
                  entries, and you lose validation. You also risk errors
                  like referencing a name that is just 1 char different
                  from what you really wanted but the system can’t tell
                  you that you got it wrong.

        

      

    

    

    Yes.  I don't think that you can solve this during existing YANG
    datastore validation, as it is defined today.

    

    But I also think that NETCONF/YANG is potentially missing an RPC
    that is a step beyond validation, but before actually applying
    configuration.

    

    YANG and the NMDA datastores draft makes it clear that both
    <running> and <intended> are always valid datastores.
    This means that the validation rules for these datastores really
    should not depend on the current hardware in a device if that
    hardware could be removed or change.  Otherwise, if you allow
    validation to depend on the current hardware capabilities, then if
    someone pulls out a linecard, that would cause a previously valid
    configuration to immediately become invalid, violating the rule that
    <running>/<intended> are always valid.

    

    I think that a potential solution to this problem, is that a new
    NETCONF RPC could be defined that is a
    "<should-successfully-apply>" operation.   Processing during
    this new RPC would be able to check against current system
    resources, current hardware capabilities, etc, and would be designed
    to indicate whether the system expects (but does not guarantee) that
    the configuration would completely apply successfully without any
    errors or unapplied configuration.  Configuration datastores would
    not have to always conform to this constraint, so that if an
    operator changed or removed a linecard, the configuration would
    still be "valid" (as per NMDA and RFC7950 rules) but would fail a
    subsequent "should-successfully-apply" check.

    

    

    

    

      

        

          

          

            
 

            
Another solution discussed is to have
              the system created entries appear in the <intended>
              datastore (as part of template/expansion).  That would
              make validation pass on the intended datastore, but then
              the candidate/running/startup datastores would not be
              valid (would be missing leafref targets if any part of the
              config refers to system created entries).  THis sounds
              similar to the problem that has been discussed in the past
              about the fact that templates (in the running) basically
              mean the running/candidate aren’t necessarily valid (until
              after template expansion, which means only the intended
              would be valid).

          

          


            I think that this solution is OK, but not necessarily ideal.

            

            As you say, it means that
            <running>/<candidate>/<startup> may not be
            valid, which I see as quite a big down side.  Longer term, I
            think that it would be a good aim to allow the configuration
            to be validated off the device, if a client desired to do
            so.

            

            

            

            

          

            
 

            
Another approach could be to actually
              have those system created entries show up in
              running/candidate.  That would ensure that references to
              those entries are valid.  But if the whole concept of
              templates just cause the running/candidate to not be valid
              anyways maybe we wouldn’t worry about the invalid aspect
              of references to system created list entries ?

          

          


            I know that quite a few implementations do this today, but
            I'm generally not a fan of the system modifying
            <running>.  It seems that an overall architecture is
            much cleaner if <running> has a single source of truth
            and hence can be exclusively controlled by the client.

            

            But I also like the approach where the client (rather than
            the device) explicitly writes these default entries into the
            configuration, if they are referenced elsewhere by the
            configuration, to make the configuration "complete".  E.g.
            if part of the configuration references the loopback0
            interface then also explicitly add the necessary loopback0
            configuration to instantiate the "loopback0" interface. 
            When this configuration is pushed to the device (i.e. using
            merge or replace operation semantics) then the system should
            silently accept/ignore the explicit configuration to create
            the loopback0 interface if it already exists on the system.

          
 

          
[>>JTS]
                  Yes – that is another option and I like it.  If I
                  follow you correctly, the server would never return
                  these system entries in a <get-config> unless
                  the client/operator had already explicitly ‘created’
                  them.   

          
So
                  the operator has the option to make the system entries
                  visible or not.

        

      

    

    Yes, exactly.

    

    

      
    

      

        

          

          
 

          
I
                  think the server should still accept references to the
                  system entries even if the client/operator hasn’t
                  explicitly created them.  The whole point is that
                  those system entries are there and waiting for
                  operators to use them from the start (without *having*
                  to explicitly create or define them).   In that case
                  the references would be ‘dangling’ (unresolved) as far
                  as an offline validation is concerned (but a client
                  could select to fix that by explicitly defining any
                  entries they want to reference).

        

      

    

    I think that this is OK.

    

    Effectively, I see that being like a static system provided template
    for configuration that is merged with <running> to form
    <intended>, which is then validated.

    

    

    

      

        

          

          


            

            

            At the moment, IETF, and other SDOs are busy defining
            standard YANG models, but for those models to end up being
            truly generic they also need to have consistency about which
            bits of configuration are always expected to implicitly
            exist on the device.  E.g. considering the example above of
            configuration referencing loopback0: if some systems
            automatically create a loopback0 interface and others do
            not, then a generic configuration needs to handle both
            scenarios.

            

            If IETF standardizes YANG configuration templates, then
            perhaps it would be good to investigate whether some of
            these "useful default system properties" could instead be
            embodied into one or more standard device templates?  These
            templates could then be explicitly referenced in the
            <running> configuration.  This may allow
            <running> to be small, but still allow it to be
            "complete" and able to be validated off the box.

          
[>>JTS]
                  I’m not clear on this approach. 
                

        

      

    

    OK, so this is just an idea:

    

    1) Assume a YANG extension is defined to allow templates to be
    defined.

    2) Further, assume that there is a way to store, and uniquely name
    some of those templates in a standard place.

    

    So, perhaps IETF could define a template like this, which is stored
    as a well defined place:

    

    <template>

      <name>ietf-basic-router-v1</name>

      <config>

        <interfaces>

          <interface>

            <name>Loopback0</name>

            <type>ianaift:loopback</type>

          </interface>

          <interface>

            <name>Null0</name>

            <type>ianaift:null</type>

          </interface>

        </interfaces> 

      </config>

    </template>

    

    Now, when it comes to the configuration file for your device, it
    could look like this:

      <config>

         
<use-remote-template>http://yang-templates.ietf.org/ietf-basic-router-v1</use-remote-template>

      

          ... rest of config as normal.

    
      </config>

    

    So, the expanded configuration would include the explicit
    configuration for Loopback0 and Null0 interfaces, but that would be
    pulled via use of a remote template (the contents of which is
    probably already cached on the device).

    

    

    

      

        

          

          
How
                  would the templates be referenced in the
                  <running> ?  Can you give me an example ? (is
                  this different than a direct reference to a system
                  created entry that I am talking about ?)

        

      

    

    The above is just an idea.  Normally I would expect configuration
    templates to be defined in the running configuration.  But here I
    was considering the idea that a template is predefined in some way,
    and then referenced, so that it doesn't have to be provided inline
    in the running configuration.

    

    

    

      

        

          

          
How
                  would this allow <running> to be small ? Do the
                  templates contain the full definition of the system
                  created entries ?

        

      

    

    Yes, I was assuming that the template could contain what might
    normally be represented as system created entries today.  Standard
    templates could either be defined by SDOs, vendors, or operators, as
    long as there is a way to reference them.

    

    Thanks,

    Rob

    

    

    

      

        

          

          


            

            Thanks,

            Rob

            

            

            

            

          

            
 

            
Rgds,

            
Jason

            
 

            


              

              

              

            
_______________________________________________

            
netmod mailing list

            
netmod@ietf.org

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

          

          
 

        

      

    

    

  


--------------73D9F6E840F3CA1D76EBC198--


From nobody Tue Oct 24 05:27:20 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8D313F745 for ; Tue, 24 Oct 2017 05:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FUJRP45Ntuqg for ; Tue, 24 Oct 2017 05:27:16 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDCF13F741 for ; Tue, 24 Oct 2017 05:27:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 34AD31405B58; Tue, 24 Oct 2017 14:27:14 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ReUaglt1c80i; Tue, 24 Oct 2017 14:27:14 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 03F021405B55; Tue, 24 Oct 2017 14:27:14 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jmGXHYV3b8GV; Tue, 24 Oct 2017 14:27:13 +0200 (CEST)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id C9CFB1405B51; Tue, 24 Oct 2017 14:27:13 +0200 (CEST)
To: Andy Bierman 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>  
From: Vladimir Vassilev 
Cc: "netmod@ietf.org" 
Message-ID: 
Date: Tue, 24 Oct 2017 14:27:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 12:27:19 -0000

On 10/24/2017 03:42 AM, Andy Bierman wrote:

>
>
> On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev 
> > wrote:
>
>     On 10/23/2017 01:35 PM, Martin Bjorklund wrote:
>
>         Vladimir Vassilev          > wrote:
>
>             Hello,
>
>             I would like to use the occasion of this Errata report to
>             point out
>             some additional issues with the instance-identifier type
>             definition.
>
>             IMO the instance-identifier built-in type has 2 additional
>             problems
>             that can be addressed with alternative and significantly
>             more radical
>             errata or fixed in a new version of YANG.:
>
>             Problem 1: The obvious limitation inherited from Xpath 1.0
>             - inability
>             to escape single or double quote characters. In Xpath
>             world this
>             limitation is worked around by use of concat() which is
>             not available
>             in the YANG 1.1 instance-identifier definition. 2 examples
>             of this
>             limitation:
>
>             1. It is impossible to create value of type
>             instance-identifier
>             referencing nodes in lists with key string values
>             containing both a
>             single and a double quote characters e.g.
>             ..."It's
>             valid string!".
>
>             2. Another example of the same problem would be a leaf of type
>             instance-identifier referencing another leaf of type
>             instance-identifier. With 2 references it works provided
>             one is
>             encoded with single quotes and the other with double but it is
>             impossible to create third e.g.
>
>             YANG:
>
>                  list id-list {
>                    key "id";
>
>                    leaf id {
>                        type instance-identifier;
>                    }
>                  }
>
>
>
>
> Although the instance-identifier is problematic, it is rarely used at all,
> let alone using it as a list key.
It is used as a key in ietf-alarms /alarms/alarm-list/alarm.
>
> The XPath mixed-quotes problem is well-known, and the suggested
> solution seems to be use the "concat" function
>
>    /foo/bar[name=concat("It's a", ' "valiid" string')]
>
> Not very user friendly, is it?
I think people naming their interfaces "It's a valid string!" can take 
it. Prettier escaping solutions are available e.g. C string but it will 
require more work then a line in the next YANG version RFC. IMO solution 
is needed either concat or an alternative one.

Practical reason: YANG 1.1 can not create instance-identifier to the 
alarm /alarms/alarm-list/alarm[... 
resource="/interfaces/interface[name='eth0']"]. And this is not the 
"That's a valid string!" named interface. The "That's a valid string!" 
interface alarms can not be reported as a valid ietf-alarms 
instance-identifier based resource alarm at all.

>
>
>             Data:
>
>             * /top/id-list[id="/top/list[idx='4']"]
>
>             * /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"]
>                          * proposed errata is also in effect>
>
>             * 
>
>             Problem 2: The instance-identifier type lacks canonical
>             form (which
>             makes it the only data type with implementation dependent
>             representation at the data level ... think of the integer
>             types
>             allowing optional spaces between the digits). This is in
>             fact the only
>             built-in data type that allows the server implementation
>             to change the
>             configuration data replacing double quotes with single or
>             the other
>             way around. Inserting white spaces where you did not have
>             them when
>             the configuration was submitted. You can not simply read a
>             configuration and use fast data comparison without schema
>             support just
>             because of this type. This is useless flexibility for
>             simple data
>             type.
>
>             And this can be fixed if:
>
>             1. white spaces in instance-identifiers are prohibited
>
>
>             2. list key predicates are required in alphabetical order
>
>         Or perhaps use the order the keys are defined in the data
>         model (the
>         "keys" statement").
>
>     This is an option but then the e.g. xpath2instid() function
>     implementations will need schema support.
>
>
>
> All the YANG tools I have seen generate the predicates in YANG key order.
Yes.

If Xpath came with a canonical form definition (prohibiting spaces, 
redundant duplication of namespace prefixes in children, order of 
predicates, canonical quotation rule, and some flexibility as of the 
node prefix semantics) we would not need to have this discussion. Seems 
no other modeling language of hierarchical data has reusable 
instance-identifier datatype with the necessary properties and I can see 
this as something that can go in separate RFC specifying generic data 
type making canonic definition from Xpath that YANG can reuse. In that 
case the alphabetic order makes sense moving some constraints into the 
generic definition of the type one can validate without the context 
schema but it is not of significant importance.

> The issue of canonical instance-identifier has been discussed many times,
> and it is not possible to require the usage of specific prefixes in XML.
> (Note that Lada fixed this for JSON in RFC 7951)
Yes.
>
> Only the string + expanded names can be properly compared in XML, not 
> the literal string
> representing the XPath expression.
Yes.

I do not see the need of major rework just making the Xpath subset rules 
stricter with canonical requirement and either allowing concat() (also 
with canonic rule producing predictable result e.g. to be used only for 
escaping single quotes and prohibiting double quotes in predicates 
otherwise). Even with RFC7951 prefix rules added in the 
instance-identifier can still be a valid Xpath subset requiring trivial 
prefix replacements so that it can be used with non-YANG aware XML tools 
keeping that option open.

Vladimir
>
>
>     Vladimir
>
>
>
> Andy
>
>
>             3. strict quotation convention with escape option is
>             added. (only
>             3. contradicts the sec. 9.13 ".. instance-identifier is a
>             subset of
>             the XPath ..")
>
>         I would like to change one more thing - I think it is
>         unfortunate that
>         the lexical representation depends on the lexical context;
>         specifically that prefixes declared in the XML instance
>         document is
>         used.  This applies also to identityref.  YANG 2.0 should use
>         the same
>         encoding as JSON does for these datatypes.
>
>
>
>         /martin
>
>
>
>             Vladimir
>
>             On 10/21/2017 08:16 PM, Andy Bierman wrote:
>
>
>                 On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise
>                 
>                 >>
>                 wrote:
>
>                      Dear all,
>
>                      Shall I validate this one?
>
>
>
>                 To add more context, this relates to the the RESTCONF
>                 JSON vs. XML
>                 discussions in the NETCONF WG.
>
>                    leaf broken {
>                        type union {
>                          type int32;
>                          type string;
>                       }
>                    }
>
>                 If all values of key leaf "broken" are sent as strings
>                 in an
>                 instance-identifier,
>                 then the int32 value may not match in all
>                 implementations, instead of
>                 the string.
>                 Allowing numbers as literals in addition to quoted
>                 strings allows the
>                 sender
>                 to be specific, and all implementations to be consistent.
>
>
>                      Regards, Benoit
>
>
>
>                 Andy
>
>                          The following errata report has been
>                 submitted for RFC7950,
>                          "The YANG 1.1 Data Modeling Language".
>
>                          --------------------------------------
>                          You may review the report below and at:
>                 http://www.rfc-editor.org/errata/eid5157
>                 
>                                           >
>
>                          --------------------------------------
>                          Type: Technical
>                          Reported by: Andy Bierman                  
>                                           >>
>
>                          Section: 14
>
>                          Original Text
>                          -------------
>                             key-predicate-expr  = node-identifier *WSP
>                 "=" *WSP
>                          quoted-string
>
>                          Corrected Text
>                          --------------
>                             key-predicate-expr  = node-identifier *WSP
>                 "=" *WSP
>                                   (quoted-string / integer-value /
>                 decimal-value)
>
>                          Notes
>                          -----
>                          An instance identifier is forced to specify
>                 every key value to
>                          be a string
>                          even though the YANG key leaf type could be a
>                 numeric type.
>                          XPath does not require a quoted string here,
>                 just YANG.
>
>                          Old:  /top/list[idx="4"]
>                          New: /top/list[idx=4]
>
>                          Instructions:
>                          -------------
>                          This erratum is currently posted as
>                 "Reported". If necessary,
>                          please
>                          use "Reply All" to discuss whether it should
>                 be verified or
>                          rejected. When a decision is reached, the
>                 verifying party
>                          can log in to change the status and edit the
>                 report, if necessary.
>
>                          --------------------------------------
>                          RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>                          --------------------------------------
>                          Title               : The YANG 1.1 Data
>                 Modeling Language
>                          Publication Date    : August 2016
>                          Author(s)           : M. Bjorklund, Ed.
>                          Category            : PROPOSED STANDARD
>                          Source              : NETCONF Data Modeling
>                 Language
>                          Area                : Operations and Management
>                          Stream              : IETF
>                          Verifying Party     : IESG
>                          .
>
>
>
>
>
>                 _______________________________________________
>                 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 Oct 24 08:35:00 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656EB138BE7 for ; Tue, 24 Oct 2017 08:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, 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 5EwelFxf5NAk for ; Tue, 24 Oct 2017 08:34:57 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DF71385A7 for ; Tue, 24 Oct 2017 08:34:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14968; q=dns/txt; s=iport; t=1508859296; x=1510068896; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=uns8O4kjrKVSEZRtrQc36xiER5obhuVygJVa4/JIIos=; b=JoKv7WZ7kmwh75KyhuEibyAgQ33qyiotgJkOqRMezorwEI+r9wvOddkn a+C252Olo6bftEOv+h4BfGPE9mEOAQaOIXzeF1lXVgzZyfZEwnRUAtrLc Ild8uvWgZ5dvg2C31/9XRh/UPlc+1Z3jI9WywujNDjtGZI6VdHLsPD2gM s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAABQXe9Z/xbLJq1XAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRDbieDeoofdJBPkHiFQhCCAQoYAQqDOoEPTwKFHxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUeAQEBAwEBIUsZAgkCEAgnAwICGwwfEQYBDAYCAQEXigUQiVKdZ4InJ?= =?us-ascii?q?op9AQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWDKYNXgWkpgwGEbgE3JoJNgmEFkVC?= =?us-ascii?q?QHZR1ghWJV4c5iiWDdYdlgTkfOIFbNCEIHRVJgmQJghqCPT82i3EBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,428,1503360000";  d="scan'208,217";a="698221801"
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; 24 Oct 2017 15:34:54 +0000
Received: from [10.63.23.81] (dhcp-ensft1-uk-vla370-10-63-23-81.cisco.com [10.63.23.81]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9OFYrnt002792; Tue, 24 Oct 2017 15:34:54 GMT
To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" 
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local> 
From: Robert Wilton 
Message-ID: 
Date: Tue, 24 Oct 2017 16:34:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------EEB144B6AC48AA5386884A10"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 15:34:59 -0000

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

Hi Andy,

To try and formally close this issue: We propose that no changes are 
made to the NMDA draft.

I think that you have raised two issues in this thread:


(1) All YANG actions in an NMDA server are invoked against .

We generally agree that module defined actions, and module defined RPCs 
and notifications, will generally apply to the operational state of a 
system, but this won't necessarily universally hold.  In particular it 
may not hold for any YANG modules that are defining generic behaviour 
(e.g. inactive configuration, templating solutions, I2RS, etc).  We 
don't think that this needs to be specified in the NMDA datastores 
draft, but would be better documented in a future revision of YANG.


(2) Define :

I'm not convinced that this is really required/helpful, given that most 
actions are likely to only apply to operational.  If it turns out that 
this is particularly useful then I would propose that this is deferred 
until a future revision of NETCONF, particularly because we are trying 
to keep the NETCONF NMDA and RESTCONF NMDA drafts as small as possible.

Is this OK?

Thanks,
Rob


On 18/10/2017 23:16, Andy Bierman wrote:
>
>
> On Wed, Oct 18, 2017 at 2:36 PM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Wed, Oct 18, 2017 at 01:26:30PM -0700, Andy Bierman wrote:
>     > On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <
>     > j.schoenwaelder@jacobs-university.de
>     > wrote:
>     >
>     > > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
>     > > > > >
>     > > > > >   augment "/if:interfaces-state/if:interface" {
>     > > > > >     action reset {
>     > > > > >       description "Reset this interface";
>     > > > > >     }
>     > > >
>     > > > Can you spot the NMDA problem above?
>     > > > Actually, it exists for in-line definitions, not just augment.
>     > > >
>     > > > Once you collapse the interfaces-state tree into
>     /interfaces, there
>     > > > is no way to specify whether an action is intended for
>     
>     > > > or a configuration datastore, or all datastores.
>     > >
>     > > I think operations (both RPCs and actions) by default always
>     execute
>     > > in the context of the operational state datastore. This is
>     consistent
>     > > with the way we define the xpath context. An operation that
>     operates
>     > > on other datastores needs to carry this information in its
>     semantics
>     > > and typically requires special arguments to select the datastores
>     > > affected. This is how  and  work.
>     Hence, a
>     > > reset action defined for an interface by default applies to the
>     > > operational state datastore. And this default makes likely
>     sense for
>     > > most actions and RPCs.
>     > >
>     > > If an action or RPC is expected to operate on a different
>     datastore,
>     > > the description must explain this and there may be a need to
>     pass a
>     > > datastore identifier to the operation. [Yes, in retrospect,
>     one might
>     > > have designed the protocol differently so that there would
>     always be a
>     > > datastore parameter at the protocol level but its too late for
>     that.]
>     > >
>     > >
>     >
>     > IMO this needs to be simple and deterministic.
>     > All YANG actions in an NMDA server are invoked against
>     .
>     >
>
>     Well, yes, like all RPC operations - except that we have RPC
>     operations that do act on other datastores. ;-) But the generic
>     mechanism including any xpath contexts is against operational.  If the
>     semantics of the operation that say 'interpret parameter 5 as a
>     datastore name and act on that datastore', well then this is what the
>     designer wanted. This is how edit-config and friends work today.
>
>
>
> Except this approach is ad-hoc and sub-optimal.
> That's why NMDA  is better (because it is extensible yet not 
> ad-hoc).
> IMO an  wrapper would be a good addition for a YANG update
>
>   
>      rd:running
>      
>          
>            
>                ...
>           
>         
>    
>   
>
> It is better to keep the YANG model decoupled from datastores,
> and use a protocol parameter to make it explicit.
>
>
>     /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


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


  
    
  
  
    
Hi Andy,

    
To try and formally close this issue: We propose that no changes
      are made to the NMDA draft.

    
I think that you have raised two issues in this thread:

    


    

    
(1) All YANG actions in an NMDA server are invoked against
      <operational>.

    
We generally agree that module defined actions, and module
      defined RPCs and notifications, will generally apply to the
      operational state of a system, but this won't necessarily
      universally hold.  In particular it may not hold for any YANG
      modules that are defining generic behaviour (e.g. inactive
      configuration, templating solutions, I2RS, etc).  We don't think
      that this needs to be specified in the NMDA datastores draft, but
      would be better documented in a future revision of YANG.

    


    

    
(2) Define <action2>:

    
I'm not convinced that this is really required/helpful, given
      that most actions are likely to only apply to operational.  If it
      turns out that this is particularly useful then I would propose
      that this is deferred until a future revision of NETCONF,
      particularly because we are trying to keep the NETCONF NMDA and
      RESTCONF NMDA drafts as small as possible.

    
Is this OK?

    
Thanks,

      Rob

    


    

    
On 18/10/2017 23:16, Andy Bierman
      wrote:

    

    

      
      


        


          
On Wed, Oct 18, 2017 at 2:36 PM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
On Wed,
              Oct 18, 2017 at 01:26:30PM -0700, Andy Bierman wrote:

              > On Wed, Oct 18, 2017 at 7:36 AM, Juergen
              Schoenwaelder <

              > j.schoenwaelder@jacobs-university.de>
              wrote:

              >

              > > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy
              Bierman wrote:

              > > > > >

              > > > > >   augment
              "/if:interfaces-state/if:interface" {

              > > > > >     action reset {

              > > > > >       description "Reset this
              interface";

              > > > > >     }

              > > >

              > > > Can you spot the NMDA problem above?

              > > > Actually, it exists for in-line
              definitions, not just augment.

              > > >

              > > > Once you collapse the interfaces-state tree
              into /interfaces, there

              > > > is no way to specify whether an action is
              intended for <operational>

              > > > or a configuration datastore, or all
              datastores.

              > >

              > > I think operations (both RPCs and actions) by
              default always execute

              > > in the context of the operational state
              datastore. This is consistent

              > > with the way we define the xpath context. An
              operation that operates

              > > on other datastores needs to carry this
              information in its semantics

              > > and typically requires special arguments to
              select the datastores

              > > affected. This is how <get-config> and
              <edit-config> work. Hence, a

              > > reset action defined for an interface by default
              applies to the

              > > operational state datastore. And this default
              makes likely sense for

              > > most actions and RPCs.

              > >

              > > If an action or RPC is expected to operate on a
              different datastore,

              > > the description must explain this and there may
              be a need to pass a

              > > datastore identifier to the operation. [Yes, in
              retrospect, one might

              > > have designed the protocol differently so that
              there would always be a

              > > datastore parameter at the protocol level but
              its too late for that.]

              > >

              > >

              >

              > IMO this needs to be simple and deterministic.

              > All YANG actions in an NMDA server are invoked
              against <operational>.

              >

              

              Well, yes, like all RPC operations - except that we have
              RPC

              operations that do act on other datastores. ;-) But the
              generic

              mechanism including any xpath contexts is against
              operational.  If the

              semantics of the operation that say 'interpret parameter 5
              as a

              datastore name and act on that datastore', well then this
              is what the

              designer wanted. This is how edit-config and friends work
              today.

              

                

            


            

            


            

            
Except this approach is ad-hoc and sub-optimal.

            
That's why NMDA <get-data> is better (because it
              is extensible yet not ad-hoc).

            
IMO an <action2> wrapper would be a good addition
              for a YANG update

            


            

            
  <action2>

            
     <datastore>rd:running</datastore>

            
     <top>

            
         <foo>

            
           <test-action>

            
               ...

            
          </test-action>

            
        </foo>

            
   </top>

            
  </action2>

            


            

            
It is better to keep the YANG model decoupled from
              datastores,

            
and use a protocol parameter to make it explicit.

            


            

            


            

            

                  /js

                

            


            

            


            

            
Andy

            
 

            

                  

                  --

                  Juergen Schoenwaelder           Jacobs University
                  Bremen gGmbH

                  Phone: +49 421 200 3587         Campus Ring 1 | 28759
                  Bremen | Germany

                  Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

                

          

          

        

      

      

      

      

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


    

    

  


--------------EEB144B6AC48AA5386884A10--


From nobody Tue Oct 24 10:06:58 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E42C138FA0 for ; Tue, 24 Oct 2017 10:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3ZoODf-iQII for ; Tue, 24 Oct 2017 10:06:54 -0700 (PDT)
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 4A451138103 for ; Tue, 24 Oct 2017 10:06:54 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id a2so2729178lfh.11 for ; Tue, 24 Oct 2017 10:06:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/o4eaNoTpV9+gDuLTIM9Vq1Fy/kdaFkDLaIr5N/escQ=; b=HC/0qk8tdgE3wszk0wvRzHl6xQ/PaYtJBOGlG3cewAYtpp50ecVzFP//TzwD5W9OOc Viwc/ujna0zTrTB+EEcUVZjD2yHQcBXpUwfdnMew7nH/L5g1khTl+7d+7cepT24t4iob BACLWEQXPa2n+sVQUHhbdLqHk6sk9vo1ZYqvxX/HdbbXOGWNSZIaY67kVZIINsCLFF1Q r4QaI9zHF+ariWvRYfEygIdn0pg83J3crhiytHzqNPXx8rlc0NgFzR3ehBlLqS75+Me/ db6h8WiUvV7TumzGT8BOu2lD76/2y4RYQAyQ2ZAsiSxn3y+kMjP/huzo0qrse8qMTw1D VSog==
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=/o4eaNoTpV9+gDuLTIM9Vq1Fy/kdaFkDLaIr5N/escQ=; b=CeKXvMh0tQjF2QhcT7knEbiU/aJ51uYpAlcMh+pjrVwvVaAzxepLOFNePnxZVhpbUr otZS6OZmqE04U1uQt3on7bYWVnFBUZ0xB4Wd29BmWCtrHJeiNL+CwZL9NCrUY4oDYxhL clAY4cE+ckn9psp+Z+xWH8YaZkuIxpIuPO2bRvh5HQhPq3nZnPY7Q/omaAHECbYeYPkh nVKbv4Yefs0XqzMfj7bXeCSbmWOO1C8fkMZPUf4tM5AHE+Bww/o0MkqY0I4et1HeZ35Z GzIm2nojuSvc7lSAUYLin0nYl08k14BBqDR3TdNdcoxAUcELJhTqtPWEo//Ux76OtLO7 icpQ==
X-Gm-Message-State: AMCzsaVwdvDR+47CIORBxxtVvXaxB2U0H5YVgcszFJ1xR3Kqww0t/Xyw jZ5Te9/nVvmnuiLRfG8H1rgIXG5m+kv7wgDobcbfHQ==
X-Google-Smtp-Source: ABhQp+Th93GNX82UuXHP/4kChurTiZOrwPIGtpiiRxA195qy+qsMow2TbHFIENzU8PVcCZnHHcPYHFAh8X3qfFhPy8Q=
X-Received: by 10.25.211.73 with SMTP id k70mr5956681lfg.51.1508864812347; Tue, 24 Oct 2017 10:06:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Tue, 24 Oct 2017 10:06:51 -0700 (PDT)
In-Reply-To: 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>   
From: Andy Bierman 
Date: Tue, 24 Oct 2017 10:06:51 -0700
Message-ID: 
To: Vladimir Vassilev 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114188aa278f14055c4df7a8"
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 17:06:57 -0000

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

On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev  wrote:

> On 10/24/2017 03:42 AM, Andy Bierman wrote:
>
>
>>
>> On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev <
>> vladimir@transpacket.com > wrote:
>>
>>     On 10/23/2017 01:35 PM, Martin Bjorklund wrote:
>>
>>         Vladimir Vassilev >         > wrote:
>>
>>             Hello,
>>
>>             I would like to use the occasion of this Errata report to
>>             point out
>>             some additional issues with the instance-identifier type
>>             definition.
>>
>>             IMO the instance-identifier built-in type has 2 additional
>>             problems
>>             that can be addressed with alternative and significantly
>>             more radical
>>             errata or fixed in a new version of YANG.:
>>
>>             Problem 1: The obvious limitation inherited from Xpath 1.0
>>             - inability
>>             to escape single or double quote characters. In Xpath
>>             world this
>>             limitation is worked around by use of concat() which is
>>             not available
>>             in the YANG 1.1 instance-identifier definition. 2 examples
>>             of this
>>             limitation:
>>
>>             1. It is impossible to create value of type
>>             instance-identifier
>>             referencing nodes in lists with key string values
>>             containing both a
>>             single and a double quote characters e.g.
>>             ..."It's
>>             valid string!".
>>
>>             2. Another example of the same problem would be a leaf of type
>>             instance-identifier referencing another leaf of type
>>             instance-identifier. With 2 references it works provided
>>             one is
>>             encoded with single quotes and the other with double but it is
>>             impossible to create third e.g.
>>
>>             YANG:
>>
>>                  list id-list {
>>                    key "id";
>>
>>                    leaf id {
>>                        type instance-identifier;
>>                    }
>>                  }
>>
>>
>>
>>
>> Although the instance-identifier is problematic, it is rarely used at all,
>> let alone using it as a list key.
>>
> It is used as a key in ietf-alarms /alarms/alarm-list/alarm.
>
>>
>> The XPath mixed-quotes problem is well-known, and the suggested
>> solution seems to be use the "concat" function
>>
>>    /foo/bar[name=concat("It's a", ' "valiid" string')]
>>
>> Not very user friendly, is it?
>>
> I think people naming their interfaces "It's a valid string!" can take it.
> Prettier escaping solutions are available e.g. C string but it will require
> more work then a line in the next YANG version RFC. IMO solution is needed
> either concat or an alternative one.
>
> Practical reason: YANG 1.1 can not create instance-identifier to the alarm
> /alarms/alarm-list/alarm[... resource="/interfaces/interface[name='eth0']"].
> And this is not the "That's a valid string!" named interface. The "That's a
> valid string!" interface alarms can not be reported as a valid ietf-alarms
> instance-identifier based resource alarm at all.
>



Actually the XPath designers made a reasonable trade-off by using concat as
the solution to
a problem that rarely happens.   It is up to the IETF to define YANG in a
way that does
not ignore the XPath solutions.


Andy



>
>>
>>             Data:
>>
>>             * /top/id-list[id="/top/list[idx='4']"]
>>
>>             * /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"]
>>             >             * proposed errata is also in effect>
>>
>>             * 
>>
>>             Problem 2: The instance-identifier type lacks canonical
>>             form (which
>>             makes it the only data type with implementation dependent
>>             representation at the data level ... think of the integer
>>             types
>>             allowing optional spaces between the digits). This is in
>>             fact the only
>>             built-in data type that allows the server implementation
>>             to change the
>>             configuration data replacing double quotes with single or
>>             the other
>>             way around. Inserting white spaces where you did not have
>>             them when
>>             the configuration was submitted. You can not simply read a
>>             configuration and use fast data comparison without schema
>>             support just
>>             because of this type. This is useless flexibility for
>>             simple data
>>             type.
>>
>>             And this can be fixed if:
>>
>>             1. white spaces in instance-identifiers are prohibited
>>
>>
>>             2. list key predicates are required in alphabetical order
>>
>>         Or perhaps use the order the keys are defined in the data
>>         model (the
>>         "keys" statement").
>>
>>     This is an option but then the e.g. xpath2instid() function
>>     implementations will need schema support.
>>
>>
>>
>> All the YANG tools I have seen generate the predicates in YANG key order.
>>
> Yes.
>
> If Xpath came with a canonical form definition (prohibiting spaces,
> redundant duplication of namespace prefixes in children, order of
> predicates, canonical quotation rule, and some flexibility as of the node
> prefix semantics) we would not need to have this discussion. Seems no other
> modeling language of hierarchical data has reusable instance-identifier
> datatype with the necessary properties and I can see this as something that
> can go in separate RFC specifying generic data type making canonic
> definition from Xpath that YANG can reuse. In that case the alphabetic
> order makes sense moving some constraints into the generic definition of
> the type one can validate without the context schema but it is not of
> significant importance.
>
> The issue of canonical instance-identifier has been discussed many times,
>> and it is not possible to require the usage of specific prefixes in XML.
>> (Note that Lada fixed this for JSON in RFC 7951)
>>
> Yes.
>
>>
>> Only the string + expanded names can be properly compared in XML, not the
>> literal string
>> representing the XPath expression.
>>
> Yes.
>
> I do not see the need of major rework just making the Xpath subset rules
> stricter with canonical requirement and either allowing concat() (also with
> canonic rule producing predictable result e.g. to be used only for escaping
> single quotes and prohibiting double quotes in predicates otherwise). Even
> with RFC7951 prefix rules added in the instance-identifier can still be a
> valid Xpath subset requiring trivial prefix replacements so that it can be
> used with non-YANG aware XML tools keeping that option open.
>
> Vladimir
>
>>
>>
>>     Vladimir
>>
>>
>>
>> Andy
>>
>>
>>             3. strict quotation convention with escape option is
>>             added. (only
>>             3. contradicts the sec. 9.13 ".. instance-identifier is a
>>             subset of
>>             the XPath ..")
>>
>>         I would like to change one more thing - I think it is
>>         unfortunate that
>>         the lexical representation depends on the lexical context;
>>         specifically that prefixes declared in the XML instance
>>         document is
>>         used.  This applies also to identityref.  YANG 2.0 should use
>>         the same
>>         encoding as JSON does for these datatypes.
>>
>>
>>
>>         /martin
>>
>>
>>
>>             Vladimir
>>
>>             On 10/21/2017 08:16 PM, Andy Bierman wrote:
>>
>>
>>                 On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise
>>                 
>>                 >>
>>                 wrote:
>>
>>                      Dear all,
>>
>>                      Shall I validate this one?
>>
>>
>>
>>                 To add more context, this relates to the the RESTCONF
>>                 JSON vs. XML
>>                 discussions in the NETCONF WG.
>>
>>                    leaf broken {
>>                        type union {
>>                          type int32;
>>                          type string;
>>                       }
>>                    }
>>
>>                 If all values of key leaf "broken" are sent as strings
>>                 in an
>>                 instance-identifier,
>>                 then the int32 value may not match in all
>>                 implementations, instead of
>>                 the string.
>>                 Allowing numbers as literals in addition to quoted
>>                 strings allows the
>>                 sender
>>                 to be specific, and all implementations to be consistent.
>>
>>
>>                      Regards, Benoit
>>
>>
>>
>>                 Andy
>>
>>                          The following errata report has been
>>                 submitted for RFC7950,
>>                          "The YANG 1.1 Data Modeling Language".
>>
>>                          --------------------------------------
>>                          You may review the report below and at:
>>                 http://www.rfc-editor.org/errata/eid5157
>>                 
>>                          >                 >
>>
>>                          --------------------------------------
>>                          Type: Technical
>>                          Reported by: Andy Bierman >                 
>>                          >                 >>
>>
>>                          Section: 14
>>
>>                          Original Text
>>                          -------------
>>                             key-predicate-expr  = node-identifier *WSP
>>                 "=" *WSP
>>                          quoted-string
>>
>>                          Corrected Text
>>                          --------------
>>                             key-predicate-expr  = node-identifier *WSP
>>                 "=" *WSP
>>                                   (quoted-string / integer-value /
>>                 decimal-value)
>>
>>                          Notes
>>                          -----
>>                          An instance identifier is forced to specify
>>                 every key value to
>>                          be a string
>>                          even though the YANG key leaf type could be a
>>                 numeric type.
>>                          XPath does not require a quoted string here,
>>                 just YANG.
>>
>>                          Old:  /top/list[idx="4"]
>>                          New: /top/list[idx=4]
>>
>>                          Instructions:
>>                          -------------
>>                          This erratum is currently posted as
>>                 "Reported". If necessary,
>>                          please
>>                          use "Reply All" to discuss whether it should
>>                 be verified or
>>                          rejected. When a decision is reached, the
>>                 verifying party
>>                          can log in to change the status and edit the
>>                 report, if necessary.
>>
>>                          --------------------------------------
>>                          RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>>                          --------------------------------------
>>                          Title               : The YANG 1.1 Data
>>                 Modeling Language
>>                          Publication Date    : August 2016
>>                          Author(s)           : M. Bjorklund, Ed.
>>                          Category            : PROPOSED STANDARD
>>                          Source              : NETCONF Data Modeling
>>                 Language
>>                          Area                : Operations and Management
>>                          Stream              : IETF
>>                          Verifying Party     : IESG
>>                          .
>>
>>
>>
>>
>>
>>                 _______________________________________________
>>                 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
>>             
>>
>>
>>
>>
>

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




On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev &l=
t;vladimir@tr=
anspacket.com> wrote:
On 10=
/24/2017 03:42 AM, Andy Bierman wrote:









On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev <vladimir@transpacket.com <=
mailto:vladim=
ir@transpacket.com>> wrote:



=C2=A0 =C2=A0 On 10/23/2017 01:35 PM, Martin Bjorklund wrote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Vladimir Vassilev <vladimir@transpacket.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vladimir@transpacket.com>> wrote:<=
br>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hello,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I would like to use the occasion =
of this Errata report to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point out

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 some additional issues with the i=
nstance-identifier type

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMO the instance-identifier built=
-in type has 2 additional

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 problems

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that can be addressed with altern=
ative and significantly

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 more radical

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 errata or fixed in a new version =
of YANG.:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Problem 1: The obvious limitation=
 inherited from Xpath 1.0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - inability

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to escape single or double quote =
characters. In Xpath

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 world this

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitation is worked around by us=
e of concat() which is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not available

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the YANG 1.1 instance-identifi=
er definition. 2 examples

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of this

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitation:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. It is impossible to create val=
ue of type

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identifier

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 referencing nodes in lists with k=
ey string values

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 containing both a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single and a double quote charact=
ers e.g.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<interface><name>&=
quot;It's

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid string!"</name>&=
lt;/interface>.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Another example of the same pr=
oblem would be a leaf of type

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identifier referencing a=
nother leaf of type

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identifier. With 2 refer=
ences it works provided

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 one is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encoded with single quotes and th=
e other with double but it is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 impossible to create third e.g.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list id-list =
{

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key &q=
uot;id";



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf i=
d {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0type instance-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 =C2=A0 =C2=A0}









Although the instance-identifier is problematic, it is rarely used at all,<=
br>
let alone using it as a list key.



It is used as a key in ietf-alarms /alarms/alarm-list/alarm.





The XPath mixed-quotes problem is well-known, and the suggested

solution seems to be use the "concat" function



=C2=A0 =C2=A0/foo/bar[name=3Dconcat("It's a", ' "val=
iid" string')]



Not very user friendly, is it?



I think people naming their interfaces "It's a valid string!"=
 can take it. Prettier escaping solutions are available e.g. C string but i=
t will require more work then a line in the next YANG version RFC. IMO solu=
tion is needed either concat or an alternative one.



Practical reason: YANG 1.1 can not create instance-identifier to the alarm =
/alarms/alarm-list/alarm[... resource=3D"/interfaces/interface[na=
me=3D'eth0']"]. And this is not the "That's a valid s=
tring!" named interface. The "That's a valid string!" in=
terface alarms can not be reported as a valid ietf-alarms instance-identifi=
er based resource alarm at all.



Actually the XPath designers made a reasonable trade=
-off by using concat as the solution to
a problem that rarely hap=
pens. =C2=A0 It is up to the IETF to define YANG in a way that does
not ignore the XPath solutions.


=
Andy











=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Data:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * /top/id-list[id=3D"/top/li=
st[idx=3D'4']"]



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * /top/id-list[id=3D"/top/id=
-list[idx=3D'/top/list[idx=3D4]'"]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <assuming the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * proposed errata is also in effe=
ct>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * <next reference not possible=
 with YANG 1.1>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Problem 2: The instance-identifie=
r type lacks canonical

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 form (which

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 makes it the only data type with =
implementation dependent

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 representation at the data level =
... think of the integer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 types

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allowing optional spaces between =
the digits). This is in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fact the only

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 built-in data type that allows th=
e server implementation

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to change the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration data replacing doub=
le quotes with single or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the other

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 way around. Inserting white space=
s where you did not have

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 them when

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the configuration was submitted. =
You can not simply read a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration and use fast data c=
omparison without schema

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 support just

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 because of this type. This is use=
less flexibility for

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 simple data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 And this can be fixed if:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. white spaces in instance-ident=
ifiers are prohibited





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. list key predicates are requir=
ed in alphabetical order



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Or perhaps use the order the keys are defined i=
n the data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 model (the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "keys" statement").



=C2=A0 =C2=A0 This is an option but then the e.g. xpath2instid() function
=C2=A0 =C2=A0 implementations will need schema support.







All the YANG tools I have seen generate the predicates in YANG key order.


Yes.



If Xpath came with a canonical form definition (prohibiting spaces, redunda=
nt duplication of namespace prefixes in children, order of predicates, cano=
nical quotation rule, and some flexibility as of the node prefix semantics)=
 we would not need to have this discussion. Seems no other modeling languag=
e of hierarchical data has reusable instance-identifier datatype with the n=
ecessary properties and I can see this as something that can go in separate=
 RFC specifying generic data type making canonic definition from Xpath that=
 YANG can reuse. In that case the alphabetic order makes sense moving some =
constraints into the generic definition of the type one can validate withou=
t the context schema but it is not of significant importance.





The issue of canonical instance-identifier has been discussed many times,
and it is not possible to require the usage of specific prefixes in XML.
(Note that Lada fixed this for JSON in RFC 7951)



Yes.





Only the string + expanded names can be properly compared in XML, not the l=
iteral string

representing the XPath expression.



Yes.



I do not see the need of major rework just making the Xpath subset rules st=
ricter with canonical requirement and either allowing concat() (also with c=
anonic rule producing predictable result e.g. to be used only for escaping =
single quotes and prohibiting double quotes in predicates otherwise). Even =
with RFC7951 prefix rules added in the instance-identifier can still be a v=
alid Xpath subset requiring trivial prefix replacements so that it can be u=
sed with non-YANG aware XML tools keeping that option open.



Vladimir







=C2=A0 =C2=A0 Vladimir







Andy





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3. strict quotation convention wi=
th escape option is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 added. (only

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3. contradicts the sec. 9.13 &quo=
t;.. instance-identifier is a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 subset of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the XPath ..")



=C2=A0 =C2=A0 =C2=A0 =C2=A0 I would like to change one more thing - I think=
 it is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 unfortunate that

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the lexical representation depends on the lexic=
al context;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 specifically that prefixes declared in the XML =
instance

=C2=A0 =C2=A0 =C2=A0 =C2=A0 document is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 used.=C2=A0 This applies also to identityref.=
=C2=A0 YANG 2.0 should use

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the same

=C2=A0 =C2=A0 =C2=A0 =C2=A0 encoding as JSON does for these datatypes.







=C2=A0 =C2=A0 =C2=A0 =C2=A0 /martin







=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Vladimir



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 10/21/2017 08:16 PM, Andy Bier=
man wrote:





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Sat, Oct 21, 201=
7 at 12:28 AM, Benoit Claise

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <bclaise@cisco.com <mailto:bclaise@cisco.com&=
gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:bclaise@cisco.com <m=
ailto:bclaise@cisco.=
com>>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Dear all,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Shall I validate this one?







=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To add more context=
, this relates to the the RESTCONF

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSON vs. XML

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 discussions in the =
NETCONF WG.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf b=
roken {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0type 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=A0type int32;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0type string;

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

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



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If all values of ke=
y leaf "broken" are sent as strings

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in an

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identifier=
,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then the int32 valu=
e may not match in all

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementations, in=
stead of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the string.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allowing numbers as=
 literals in addition to quoted

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 strings allows the<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sender

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to be specific, and=
 all implementations to be consistent.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Regards, Benoit







=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Andy



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0The following errata report has been

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 submitted for RFC79=
50,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0"The YANG 1.1 Data Modeling Language".



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0--------------------------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0You may review the report below and at:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http=
://www.rfc-editor.org/errata/eid5157

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
http://www.rfc-editor.org/errata/eid5157>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0<http://www.rfc-editor.org/errata/e=
id5157

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
http://www.rfc-editor.org/errata/eid5157>>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0--------------------------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Type: Technical

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Reported by: Andy Bierman <andy@yumaworks.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:andy@yumaworks.com>=


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0<mailto:andy@yumaworks.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:andy@yumaworks.com>=
>>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Section: 14



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Original Text

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0-------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node-identifier *WSP<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=3D" *WS=
P

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0quoted-string



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Corrected Text

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0--------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D node-identifier *WSP<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=3D" *WS=
P

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (quoted-string / integer-valu=
e /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 decimal-value)



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Notes

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0-----

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0An instance identifier is forced to specify

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 every key value to<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0be a string

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0even though the YANG key leaf type could be a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 numeric type.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0XPath does not require a quoted string here,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 just YANG.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Old:=C2=A0 /top/list[idx=3D"4"]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0New: /top/list[idx=3D4]



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Instructions:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0-------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0This erratum is currently posted as

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Reported"=
;. If necessary,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0please

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0use "Reply All" to discuss whether it should

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be verified or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0rejected. When a decision is reached, the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 verifying party

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0can log in to change the status and edit the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 report, if necessar=
y.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0--------------------------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0RFC7950 (draft-ietf-netmod-rfc6020bis-14)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0--------------------------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: The YANG 1.1 Data

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Modeling Language
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Publication Date=C2=A0 =C2=A0 : August 2016

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Bjo=
rklund, Ed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOS=
ED STANDARD

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : N=
ETCONF Data Modeling

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Language

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 : Operations and Management

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : I=
ETF

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

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











=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________=
____________________________

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 netmod mailing list=


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

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

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



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 netmod mailing list

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ie=
tf.org/mailman/listinfo/netmod

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://ww=
w.ietf.org/mailman/listinfo/netmod>















--001a114188aa278f14055c4df7a8--


From nobody Tue Oct 24 10:13:42 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAB213946F for ; Tue, 24 Oct 2017 10:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU8WtfNcoJGK for ; Tue, 24 Oct 2017 10:13:39 -0700 (PDT)
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 9679F1394EB for ; Tue, 24 Oct 2017 10:13:38 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id k40so24832290lfi.4 for ; Tue, 24 Oct 2017 10:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s1PqMVYKpxrP5/XmwZly4PRXnO4Q1mJcb0qZtZRTkxU=; b=Cbq3KeTW5401lPJ4czp78Yo+J4rPkpd1iMf4WBfMnIbo5Ir2cNBy0rjLFCYRgXUoPN pW0glUFIBmNBuBbWBbBugY+QKr0UsRanGn1ZgcjgNOQyfg0PPv72KYy5Zod8/ghJCtpw cBf/AYchl7gYi9k1RL9bamVXE0RDM56efk+f4MOqxIb2XXp7R+hhJSbHtiqDHqiUkeRj KKA8McCugc60tm9rqJT2HmHpC2OUor2RlY3W5TcCwU7c6BTG4aL+1OQBCzSaKRW/UNAv ZsUMbKRZxRjXefpw4vzZhq/4ScXqenDHYzEmeigTH2qFvLDyGxK4JJhYLj2FwFehfoPr ecpQ==
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=s1PqMVYKpxrP5/XmwZly4PRXnO4Q1mJcb0qZtZRTkxU=; b=FMtoTELaQYT3Pfc+JeSJRsKr2BL7HbKZrS+RuMdjA7u4C7bndtk3Ib4vAA18+pBr4J vLRfi4T4HoBizSIDp20R741hJjb4rNNDxX8XTr1xupGSTJcvSkV8zIu/+l1cLR8ABjFE Pi5+Zp3LCYrwy7b6+zLo2JLeHQDJ8KKKqJOjKBmmSbNh5X0+QR3oX9DHHPqXQ4Oa6Ro6 pPKWtUaIbIXYDjZ/G1kYRh7ZaJePBpYHfw8m7j3RnPOMLz/7cP0m00IVsQeGYaUMToxv mTE6Vdik/zGpdmjPgAGT49tT6nH4vKejGq6ZaWRrS6M+sSlSZYN0o1M4jaSnz2DRLBMs GFjA==
X-Gm-Message-State: AMCzsaXeID8ScK/6k2gwpaB0smkbeC4qb6FOg4KOB1yP3pHIKYMToo9u JELJtOc/84NAjSs9ENgX+vkmlOL0TTJGQikuMNPjbw==
X-Google-Smtp-Source: ABhQp+QSWZ+2gvaxEjOwYaZ6Umtf9aDSBU51FYdQ2JpE2JdjZBz6PSAOuse+mJl/y4hInjN5Zsju7x4jZZ1kbpSapBs=
X-Received: by 10.46.117.24 with SMTP id q24mr6819359ljc.14.1508865216912; Tue, 24 Oct 2017 10:13:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Tue, 24 Oct 2017 10:13:35 -0700 (PDT)
In-Reply-To: 
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>  
From: Andy Bierman 
Date: Tue, 24 Oct 2017 10:13:35 -0700
Message-ID: 
To: Robert Wilton 
Cc: Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="089e082f63e044d676055c4e0f81"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 17:13:41 -0000

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

On Tue, Oct 24, 2017 at 8:34 AM, Robert Wilton  wrote:

> Hi Andy,
>
> To try and formally close this issue: We propose that no changes are made
> to the NMDA draft.
>
> I think that you have raised two issues in this thread:
>
>
> (1) All YANG actions in an NMDA server are invoked against .
>
> We generally agree that module defined actions, and module defined RPCs
> and notifications, will generally apply to the operational state of a
> system, but this won't necessarily universally hold.  In particular it may
> not hold for any YANG modules that are defining generic behaviour (e.g.
> inactive configuration, templating solutions, I2RS, etc).  We don't think
> that this needs to be specified in the NMDA datastores draft, but would be
> better documented in a future revision of YANG.
>
>
>

IMO the more complex NMDA is to implement, the less likely it will be
implemented.
If you want the tools to figure out the correct datastore(s) from
description-stmts
instead of something deterministic and machine-usable, NMDA is less likely
to be implemented.

Given that the same objects can be defined differently in each datastore in
NMDA,
it is especially useful to know which set of YANG modules applies, before
parsing instance
data against those modules.

(2) Define :
>
> I'm not convinced that this is really required/helpful, given that most
> actions are likely to only apply to operational.  If it turns out that this
> is particularly useful then I would propose that this is deferred until a
> future revision of NETCONF, particularly because we are trying to keep the
> NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
>
> Is this OK?
>

The NMDA theme has been to declare things that are possible in pre-NMDA
but not supported in post-NMDA to be not useful, so this can be left to
vendors I guess.



> Thanks,
> Rob
>
>
>

Andy


> On 18/10/2017 23:16, Andy Bierman wrote:
>
>
>
> On Wed, Oct 18, 2017 at 2:36 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Wed, Oct 18, 2017 at 01:26:30PM -0700, Andy Bierman wrote:
>> > On Wed, Oct 18, 2017 at 7:36 AM, Juergen Schoenwaelder <
>> > j.schoenwaelder@jacobs-university.de> wrote:
>> >
>> > > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy Bierman wrote:
>> > > > > >
>> > > > > >   augment "/if:interfaces-state/if:interface" {
>> > > > > >     action reset {
>> > > > > >       description "Reset this interface";
>> > > > > >     }
>> > > >
>> > > > Can you spot the NMDA problem above?
>> > > > Actually, it exists for in-line definitions, not just augment.
>> > > >
>> > > > Once you collapse the interfaces-state tree into /interfaces, there
>> > > > is no way to specify whether an action is intended for 
>> > > > or a configuration datastore, or all datastores.
>> > >
>> > > I think operations (both RPCs and actions) by default always execute
>> > > in the context of the operational state datastore. This is consistent
>> > > with the way we define the xpath context. An operation that operates
>> > > on other datastores needs to carry this information in its semantics
>> > > and typically requires special arguments to select the datastores
>> > > affected. This is how  and  work. Hence, a
>> > > reset action defined for an interface by default applies to the
>> > > operational state datastore. And this default makes likely sense for
>> > > most actions and RPCs.
>> > >
>> > > If an action or RPC is expected to operate on a different datastore,
>> > > the description must explain this and there may be a need to pass a
>> > > datastore identifier to the operation. [Yes, in retrospect, one might
>> > > have designed the protocol differently so that there would always be a
>> > > datastore parameter at the protocol level but its too late for that.]
>> > >
>> > >
>> >
>> > IMO this needs to be simple and deterministic.
>> > All YANG actions in an NMDA server are invoked against .
>> >
>>
>> Well, yes, like all RPC operations - except that we have RPC
>> operations that do act on other datastores. ;-) But the generic
>> mechanism including any xpath contexts is against operational.  If the
>> semantics of the operation that say 'interpret parameter 5 as a
>> datastore name and act on that datastore', well then this is what the
>> designer wanted. This is how edit-config and friends work today.
>>
>>
>
> Except this approach is ad-hoc and sub-optimal.
> That's why NMDA  is better (because it is extensible yet not
> ad-hoc).
> IMO an  wrapper would be a good addition for a YANG update
>
>   
>      rd:running
>      
>          
>            
>                ...
>           
>         
>    
>   
>
> It is better to keep the YANG model decoupled from datastores,
> and use a protocol parameter to make it explicit.
>
>
> /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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>

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




On Tue, Oct 24, 2017 at 8:34 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Andy,

    
To try and formally close this issue: We propose that no changes
      are made to the NMDA draft.

    
I think that you have raised two issues in this thread:

    


    

    
(1) All YANG actions in an NMDA server are invoked against
      <operational>.

    
We generally agree that module defined actions, and module
      defined RPCs and notifications, will generally apply to the
      operational state of a system, but this won't necessarily
      universally hold.=C2=A0 In particular it may not hold for any YANG
      modules that are defining generic behaviour (e.g. inactive
      configuration, templating solutions, I2RS, etc).=C2=A0 We don't t=
hink
      that this needs to be specified in the NMDA datastores draft, but
      would be better documented in a future revision of YANG.

    



IMO th=
e more complex NMDA is to implement, the less likely it will be implemented=
.
If you want the tools to figure out the correct datastore(s) fr=
om description-stmts
instead of something deterministic and machi=
ne-usable, NMDA is less likely to be implemented.

=
Given that the same objects can be defined differently in each datastore in=
 NMDA,
it is especially useful to know which set of YANG modules =
applies, before parsing instance
data against those modules.


    

    
(2) Define <action2>:

    
I'm not convinced that this is really required/helpful, given
      that most actions are likely to only apply to operational.=C2=A0 If i=
t
      turns out that this is particularly useful then I would propose
      that this is deferred until a future revision of NETCONF,
      particularly because we are trying to keep the NETCONF NMDA and
      RESTCONF NMDA drafts as small as possible.

    
Is this OK?

The NMDA theme=
 has been to declare things that are possible in pre-NMDA
but not=
 supported in post-NMDA to be not useful, so this can be left to vendors I =
guess.

=C2=A0
=


    
Thanks,

      Rob

    



Andy
=C2=A0

    

    
On 18/10/2017 23:16=
, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Wed, Oct 18, 2017 at 2:36 PM,
            Juergen Schoenwaelder <j.schoenwaelder@jaco=
bs-university.de>
            wrote:

            
On Wed,
              Oct 18, 2017 at 01:26:30PM -0700, Andy Bierman wrote:

              > On Wed, Oct 18, 2017 at 7:36 AM, Juergen
              Schoenwaelder <

              > j.schoenwaelder@jacobs-university.de>
              wrote:

              >

              > > On Sun, Oct 15, 2017 at 12:56:42PM -0700, Andy
              Bierman wrote:

              > > > > >

              > > > > >=C2=A0 =C2=A0augment
              "/if:interfaces-state/if:interface" {

              > > > > >=C2=A0 =C2=A0 =C2=A0action reset {
              > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0descriptio=
n "Reset this
              interface";

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

              > > >

              > > > Can you spot the NMDA problem above?

              > > > Actually, it exists for in-line
              definitions, not just augment.

              > > >

              > > > Once you collapse the interfaces-state tree
              into /interfaces, there

              > > > is no way to specify whether an action is
              intended for <operational>

              > > > or a configuration datastore, or all
              datastores.

              > >

              > > I think operations (both RPCs and actions) by
              default always execute

              > > in the context of the operational state
              datastore. This is consistent

              > > with the way we define the xpath context. An
              operation that operates

              > > on other datastores needs to carry this
              information in its semantics

              > > and typically requires special arguments to
              select the datastores

              > > affected. This is how <get-config> and
              <edit-config> work. Hence, a

              > > reset action defined for an interface by default
              applies to the

              > > operational state datastore. And this default
              makes likely sense for

              > > most actions and RPCs.

              > >

              > > If an action or RPC is expected to operate on a
              different datastore,

              > > the description must explain this and there may
              be a need to pass a

              > > datastore identifier to the operation. [Yes, in
              retrospect, one might

              > > have designed the protocol differently so that
              there would always be a

              > > datastore parameter at the protocol level but
              its too late for that.]

              > >

              > >

              >

              > IMO this needs to be simple and deterministic.

              > All YANG actions in an NMDA server are invoked
              against <operational>.

              >

              

              Well, yes, like all RPC operations - except that we have
              RPC

              operations that do act on other datastores. ;-) But the
              generic

              mechanism including any xpath contexts is against
              operational.=C2=A0 If the

              semantics of the operation that say 'interpret parameter =
5
              as a

              datastore name and act on that datastore', well then this
              is what the

              designer wanted. This is how edit-config and friends work
              today.

              

                

            


            

            


            

            
Except this approach is ad-hoc and sub-optimal.

            
That's why NMDA <get-data> is better (because it
              is extensible yet not ad-hoc).

            
IMO an <action2> wrapper would be a good addition
              for a YANG update

            


            

            
=C2=A0 <action2>

            
=C2=A0 =C2=A0 =C2=A0<datastore>rd:running</d=
atastore>

            
=C2=A0 =C2=A0 =C2=A0<top>

            
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<foo>

            
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<test-action&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 </test-action>
            
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </foo>

            
=C2=A0 =C2=A0</top>

            
=C2=A0 </action2>

            


            

            
It is better to keep the YANG model decoupled from
              datastores,

            
and use a protocol parameter to make it explicit.

            


            

            


            

            

                  /js

                

            


            

            


            

            
Andy

            
=C2=A0

            

                  

                  --

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

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

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

                

          

          

        

      

      

      

      

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


    

    

  






--089e082f63e044d676055c4e0f81--


From nobody Tue Oct 24 10:22:56 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9C41391C3 for ; Tue, 24 Oct 2017 10:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 AwFClns7BSdY for ; Tue, 24 Oct 2017 10:22:53 -0700 (PDT)
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 4D784138103 for ; Tue, 24 Oct 2017 10:22:53 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1F18BEFF; Tue, 24 Oct 2017 19:22:52 +0200 (CEST)
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 QrwnYKc8g_dj; Tue, 24 Oct 2017 19:22:49 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Oct 2017 19:22:52 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AD3320108; Tue, 24 Oct 2017 19:22:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2im-sGu1tqI7; Tue, 24 Oct 2017 19:22:51 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82F81200FC; Tue, 24 Oct 2017 19:22:51 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id AB41B413B10A; Tue, 24 Oct 2017 19:21:25 +0200 (CEST)
Date: Tue, 24 Oct 2017 19:21:25 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Robert Wilton , Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20171024172125.l6l3yhocakfkcoh2@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Robert Wilton , Martin Bjorklund , "netmod@ietf.org" 
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 17:22:55 -0000

On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
> 
> IMO the more complex NMDA is to implement, the less likely it will
> be implemented.  If you want the tools to figure out the correct
> datastore(s) from description-stmts instead of something
> deterministic and machine-usable, NMDA is less likely to be
> implemented.

There is nothing machine readable today that tells you which argument
of get-config identifies the datastore that is being accessed by
get-config. Our reasoning is that for most actions that default is
going to do the right thing. If there is a need to have further
language support to handle the cases where operations may relate to
datastores different than operational, then this should be taken up by
a future version of YANG.

> Given that the same objects can be defined differently in each
> datastore in NMDA, it is especially useful to know which set of YANG
> modules applies, before parsing instance data against those modules.

I am not sure I parse this correctly.

> (2) Define :
> >
> > I'm not convinced that this is really required/helpful, given that most
> > actions are likely to only apply to operational.  If it turns out that this
> > is particularly useful then I would propose that this is deferred until a
> > future revision of NETCONF, particularly because we are trying to keep the
> > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
> >
> > Is this OK?
> >
> 
> The NMDA theme has been to declare things that are possible in pre-NMDA
> but not supported in post-NMDA to be not useful, so this can be left to
> vendors I guess.

Not sure I understand this either.

If you have a concrete change proposal, perhaps the discussion becomes
more concrete and productive.

/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 Oct 24 11:22:01 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF7A1386F3 for ; Tue, 24 Oct 2017 11:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBfJg38VdoWH for ; Tue, 24 Oct 2017 11:21:58 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D57137ED6 for ; Tue, 24 Oct 2017 11:21:57 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id a132so25044554lfa.7 for ; Tue, 24 Oct 2017 11:21:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mRhU013cjtosCkE144kdPsPpKGIM22Is2fl8FKAFJAk=; b=N0MKNDBdkfjvCf9q9Vn0KG6VNOxsSxWcqmjSmqcoBBY90ovoQYEaz+HIC2Ye2QgUcc kzpDG+S2nNZ5RLN6mF3xK8XvW/QRzp0uJIY3sWJl1rUiwTwSKL4vXkE3nPHPMsOt3oqk dS+YlBN9+XYG/XPEdmg7DhteiRJybiTAnIXaB8rtNUQdBC/YMIGrLaZOG4CBO+0dSHhk PgbdmItFesL0k89H35iqxmlhAz9VSOw/hzLqtYCVbDYiDu7V0C6OY9LLHeBiXPodoaH1 tcxGp6mujTfUCVqOR9eeAAeFLMQw4iZTqHWdxKP54PMughTiS+7khxFQZCMlpWcU2LMl h0PA==
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=mRhU013cjtosCkE144kdPsPpKGIM22Is2fl8FKAFJAk=; b=G+L+Ydtwrb6VUlI+1Q4/yTs9vFix2BohBj2bARVyAWHwPB6s7d0n6D6yE/QmsJ73r2 afvoaGm761iIwR95pUwclyoIIpsPRNrt83owuB7xVHfRSHPZ7Fvndi0RPMDzLVsEsWj0 vJknnE6E3YfoIs8JzVXaq1/reXbQfJHJBec2yTweGtv9N2B/zQL6KiQ3wuQ3qO+HpcDD DMNHFLjx6sFul3IOJAs4XaG1jK6LOZL3YjKzSwSnkZ/d372SinTQMIS5qDecQTO/g1CR r5znLwgNlunLHGZW9vADpzKA+JrVeRLgCwhq+q4Qn39QoXuZrA6/sVoUcAzMRj+TPRgN nFSA==
X-Gm-Message-State: AMCzsaUIVQSCqei/JxX00nfw3BHhz6lGKZJIxS2FVIyAGXJXrY3HFsqg UXHTwg6m6SQeEDvDCVE+HFv1eVvJ+uSmrr4ct5CJJQ==
X-Google-Smtp-Source: ABhQp+RbJpa2U4SuSCUDg/4sZpAbfTdwo7uMPQI8DvKyKhsluN0OqWnduFJc529a1U0g6O2XD5KYTpb5pQv9X3UZmG0=
X-Received: by 10.25.23.165 with SMTP id 37mr5927110lfx.202.1508869315745; Tue, 24 Oct 2017 11:21:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Tue, 24 Oct 2017 11:21:54 -0700 (PDT)
In-Reply-To: <20171024172125.l6l3yhocakfkcoh2@elstar.local>
References:  <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local>
From: Andy Bierman 
Date: Tue, 24 Oct 2017 11:21:54 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Robert Wilton , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11401a0493f1b6055c4f03f7"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Oct 2017 18:22:00 -0000

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

On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
> >
> > IMO the more complex NMDA is to implement, the less likely it will
> > be implemented.  If you want the tools to figure out the correct
> > datastore(s) from description-stmts instead of something
> > deterministic and machine-usable, NMDA is less likely to be
> > implemented.
>
> There is nothing machine readable today that tells you which argument
> of get-config identifies the datastore that is being accessed by
> get-config. Our reasoning is that for most actions that default is
> going to do the right thing. If there is a need to have further
> language support to handle the cases where operations may relate to
> datastores different than operational, then this should be taken up by
> a future version of YANG.
>
>
There is only 1 schema tree now in pre-NMDA so it is easy to parse
instance data against the one and only set of modules.



> > Given that the same objects can be defined differently in each
> > datastore in NMDA, it is especially useful to know which set of YANG
> > modules applies, before parsing instance data against those modules.
>
> I am not sure I parse this correctly.
>

The new YANG library requires the implementation to know the datastore
to pick the correct set of modules for the datastore used in the operation.
Module sets are allowed to overlap, so the same module can be different
in  vs. .

Developers unaware of the new NMDA complexities should read the drafts
again.



>
> > (2) Define :
> > >
> > > I'm not convinced that this is really required/helpful, given that most
> > > actions are likely to only apply to operational.  If it turns out that
> this
> > > is particularly useful then I would propose that this is deferred
> until a
> > > future revision of NETCONF, particularly because we are trying to keep
> the
> > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
> > >
> > > Is this OK?
> > >
> >
> > The NMDA theme has been to declare things that are possible in pre-NMDA
> > but not supported in post-NMDA to be not useful, so this can be left to
> > vendors I guess.
>
> Not sure I understand this either.
>
> If you have a concrete change proposal, perhaps the discussion becomes
> more concrete and productive.
>


I already said to declare that  is invoked in . Period.
No description-stmt exceptions.

If another datastore is needed, use rpc-stmt instead of action-stmt.




>
> /js
>
>

Andy


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

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




On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bier=
man wrote:

>

> IMO the more complex NMDA is to implement, the less likely it will

> be implemented.=C2=A0 If you want the tools to figure out the correct<=
br>
> datastore(s) from description-stmts instead of something

> deterministic and machine-usable, NMDA is less likely to be

> implemented.



There is nothing machine readable today that tells you which argument

of get-config identifies the datastore that is being accessed by

get-config. Our reasoning is that for most actions that default is

going to do the right thing. If there is a need to have further

language support to handle the cases where operations may relate to

datastores different than operational, then this should be taken up by

a future version of YANG.



There is only 1 schema tree now in pre=
-NMDA so it is easy to parse
instance data against the one and on=
ly set of modules.

=C2=A0

> Given that the same objects can be defined differently in each

> datastore in NMDA, it is especially useful to know which set of YANG
> modules applies, before parsing instance data against those modules.


I am not sure I parse this correctly.

T=
he new YANG library requires the implementation to know the datastore
=

to pick the correct set of modules for the datastore used in the opera=
tion.
Module sets are allowed to overlap, so the same module can =
be different
in <running> vs. <operational>.

Developers unaware of the new NMDA complexities should rea=
d the drafts again.

=C2=A0



> (2) Define <action2>:

> >

> > I'm not convinced that this is really required/helpful, given=
 that most

> > actions are likely to only apply to operational.=C2=A0 If it turn=
s out that this

> > is particularly useful then I would propose that this is deferred=
 until a

> > future revision of NETCONF, particularly because we are trying to=
 keep the

> > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.

> >

> > Is this OK?

> >

>

> The NMDA theme has been to declare things that are possible in pre-NMD=
A

> but not supported in post-NMDA to be not useful, so this can be left t=
o

> vendors I guess.



Not sure I understand this either.



If you have a concrete change proposal, perhaps the discussion becomes

more concrete and productive.


I already said to declare that <action> is invoked in <opera=
tional>. Period.
No description-stmt exceptions.
If another datastore is needed, use rpc-stmt instead of action-=
stmt.


=C2=A0



/js




Andy
=C2=A0

--

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

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

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





--001a11401a0493f1b6055c4f03f7--


From nobody Tue Oct 24 23:47:25 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABA913AB12 for ; Tue, 24 Oct 2017 23:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRZPJh1U8nuV for ; Tue, 24 Oct 2017 23:47:19 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553B6139436 for ; Tue, 24 Oct 2017 23:47:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 3862914043FC; Wed, 25 Oct 2017 08:47:17 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id lthts3hvP1rS; Wed, 25 Oct 2017 08:47:17 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 0E5BF14043F5; Wed, 25 Oct 2017 08:47:17 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Io6avS-mLktS; Wed, 25 Oct 2017 08:47:16 +0200 (CEST)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id DA26614032DC; Wed, 25 Oct 2017 08:47:16 +0200 (CEST)
To: Andy Bierman 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>    
Cc: "netmod@ietf.org" 
From: Vladimir Vassilev 
Message-ID: 
Date: Wed, 25 Oct 2017 08:47:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------221BBF821BE966444964574B"
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 06:47:23 -0000

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

On 10/24/2017 07:06 PM, Andy Bierman wrote:

>
>
> On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev 
> > wrote:
>
>     On 10/24/2017 03:42 AM, Andy Bierman wrote:
>
>
>
>         On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev
>         
>                  >> wrote:
>
>             On 10/23/2017 01:35 PM, Martin Bjorklund wrote:
>
>                 Vladimir Vassilev          
>                          >> wrote:
>
>                     Hello,
>
>                     I would like to use the occasion of this Errata
>         report to
>                     point out
>                     some additional issues with the
>         instance-identifier type
>                     definition.
>
>                     IMO the instance-identifier built-in type has 2
>         additional
>                     problems
>                     that can be addressed with alternative and
>         significantly
>                     more radical
>                     errata or fixed in a new version of YANG.:
>
>                     Problem 1: The obvious limitation inherited from
>         Xpath 1.0
>                     - inability
>                     to escape single or double quote characters. In Xpath
>                     world this
>                     limitation is worked around by use of concat()
>         which is
>                     not available
>                     in the YANG 1.1 instance-identifier definition. 2
>         examples
>                     of this
>                     limitation:
>
>                     1. It is impossible to create value of type
>                     instance-identifier
>                     referencing nodes in lists with key string values
>                     containing both a
>                     single and a double quote characters e.g.
>                     ..."It's
>                     valid string!".
>
>                     2. Another example of the same problem would be a
>         leaf of type
>                     instance-identifier referencing another leaf of type
>                     instance-identifier. With 2 references it works
>         provided
>                     one is
>                     encoded with single quotes and the other with
>         double but it is
>                     impossible to create third e.g.
>
>                     YANG:
>
>                          list id-list {
>                            key "id";
>
>                            leaf id {
>                                type instance-identifier;
>                            }
>                          }
>
>
>
>
>         Although the instance-identifier is problematic, it is rarely
>         used at all,
>         let alone using it as a list key.
>
>     It is used as a key in ietf-alarms /alarms/alarm-list/alarm.
>
>
>         The XPath mixed-quotes problem is well-known, and the suggested
>         solution seems to be use the "concat" function
>
>            /foo/bar[name=concat("It's a", ' "valiid" string')]
>
>         Not very user friendly, is it?
>
>     I think people naming their interfaces "It's a valid string!" can
>     take it. Prettier escaping solutions are available e.g. C string
>     but it will require more work then a line in the next YANG version
>     RFC. IMO solution is needed either concat or an alternative one.
>
>     Practical reason: YANG 1.1 can not create instance-identifier to
>     the alarm /alarms/alarm-list/alarm[...
>     resource="/interfaces/interface[name='eth0']"]. And this is not
>     the "That's a valid string!" named interface. The "That's a valid
>     string!" interface alarms can not be reported as a valid
>     ietf-alarms instance-identifier based resource alarm at all.
>
>
>
>
> Actually the XPath designers made a reasonable trade-off by using 
> concat as the solution to
> a problem that rarely happens.   It is up to the IETF to define YANG 
> in a way that does
> not ignore the XPath solutions.
Yes. How about some proper rules mandating th use of quotes and concat 
like: 1. Only allow use of double quotes when there is single quote 
present. 2. Only use concat when there is both single and double quotes 
present to split the string into 1 char single quote strings and the rest.

Then  /foo/bar[name=concat('It',"'",'s a valid string!"')] is the only 
possible canonic representation for all implementations and the solution 
is solving the rare problem without reinventing the wheel.

Vladimir
>
>
> Andy
>
>
>
>
>
>                     Data:
>
>                     * /top/id-list[id="/top/list[idx='4']"]
>
>                     *
>         /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"]
>                                          * proposed errata is also in effect>
>
>                     * 
>
>                     Problem 2: The instance-identifier type lacks
>         canonical
>                     form (which
>                     makes it the only data type with implementation
>         dependent
>                     representation at the data level ... think of the
>         integer
>                     types
>                     allowing optional spaces between the digits). This
>         is in
>                     fact the only
>                     built-in data type that allows the server
>         implementation
>                     to change the
>                     configuration data replacing double quotes with
>         single or
>                     the other
>                     way around. Inserting white spaces where you did
>         not have
>                     them when
>                     the configuration was submitted. You can not
>         simply read a
>                     configuration and use fast data comparison without
>         schema
>                     support just
>                     because of this type. This is useless flexibility for
>                     simple data
>                     type.
>
>                     And this can be fixed if:
>
>                     1. white spaces in instance-identifiers are prohibited
>
>
>                     2. list key predicates are required in
>         alphabetical order
>
>                 Or perhaps use the order the keys are defined in the data
>                 model (the
>                 "keys" statement").
>
>             This is an option but then the e.g. xpath2instid() function
>             implementations will need schema support.
>
>
>
>         All the YANG tools I have seen generate the predicates in YANG
>         key order.
>
>     Yes.
>
>     If Xpath came with a canonical form definition (prohibiting
>     spaces, redundant duplication of namespace prefixes in children,
>     order of predicates, canonical quotation rule, and some
>     flexibility as of the node prefix semantics) we would not need to
>     have this discussion. Seems no other modeling language of
>     hierarchical data has reusable instance-identifier datatype with
>     the necessary properties and I can see this as something that can
>     go in separate RFC specifying generic data type making canonic
>     definition from Xpath that YANG can reuse. In that case the
>     alphabetic order makes sense moving some constraints into the
>     generic definition of the type one can validate without the
>     context schema but it is not of significant importance.
>
>         The issue of canonical instance-identifier has been discussed
>         many times,
>         and it is not possible to require the usage of specific
>         prefixes in XML.
>         (Note that Lada fixed this for JSON in RFC 7951)
>
>     Yes.
>
>
>         Only the string + expanded names can be properly compared in
>         XML, not the literal string
>         representing the XPath expression.
>
>     Yes.
>
>     I do not see the need of major rework just making the Xpath subset
>     rules stricter with canonical requirement and either allowing
>     concat() (also with canonic rule producing predictable result e.g.
>     to be used only for escaping single quotes and prohibiting double
>     quotes in predicates otherwise). Even with RFC7951 prefix rules
>     added in the instance-identifier can still be a valid Xpath subset
>     requiring trivial prefix replacements so that it can be used with
>     non-YANG aware XML tools keeping that option open.
>
>     Vladimir
>
>
>
>             Vladimir
>
>
>
>         Andy
>
>
>                     3. strict quotation convention with escape option is
>                     added. (only
>                     3. contradicts the sec. 9.13 "..
>         instance-identifier is a
>                     subset of
>                     the XPath ..")
>
>                 I would like to change one more thing - I think it is
>                 unfortunate that
>                 the lexical representation depends on the lexical context;
>                 specifically that prefixes declared in the XML instance
>                 document is
>                 used.  This applies also to identityref.  YANG 2.0
>         should use
>                 the same
>                 encoding as JSON does for these datatypes.
>
>
>
>                 /martin
>
>
>
>                     Vladimir
>
>                     On 10/21/2017 08:16 PM, Andy Bierman wrote:
>
>
>                         On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise
>                         
>         >
>                                            >>>
>                         wrote:
>
>                              Dear all,
>
>                              Shall I validate this one?
>
>
>
>                         To add more context, this relates to the the
>         RESTCONF
>                         JSON vs. XML
>                         discussions in the NETCONF WG.
>
>                            leaf broken {
>                                type union {
>                                  type int32;
>                                  type string;
>                               }
>                            }
>
>                         If all values of key leaf "broken" are sent as
>         strings
>                         in an
>                         instance-identifier,
>                         then the int32 value may not match in all
>                         implementations, instead of
>                         the string.
>                         Allowing numbers as literals in addition to quoted
>                         strings allows the
>                         sender
>                         to be specific, and all implementations to be
>         consistent.
>
>
>                              Regards, Benoit
>
>
>
>                         Andy
>
>                                  The following errata report has been
>                         submitted for RFC7950,
>                                  "The YANG 1.1 Data Modeling Language".
>
>                                  --------------------------------------
>                                  You may review the report below and at:
>         http://www.rfc-editor.org/errata/eid5157
>         
>                                  >
>                                
>                   
>                                  >>
>
>                                  --------------------------------------
>                                  Type: Technical
>                                  Reported by: Andy Bierman
>         
>                                  >
>                                           
>                                  >>>
>
>                                  Section: 14
>
>                                  Original Text
>                                  -------------
>                                     key-predicate-expr  =
>         node-identifier *WSP
>                         "=" *WSP
>                                  quoted-string
>
>                                  Corrected Text
>                                  --------------
>                                     key-predicate-expr  =
>         node-identifier *WSP
>                         "=" *WSP
>                                           (quoted-string / integer-value /
>                         decimal-value)
>
>                                  Notes
>                                  -----
>                                  An instance identifier is forced to
>         specify
>                         every key value to
>                                  be a string
>                                  even though the YANG key leaf type
>         could be a
>                         numeric type.
>                                  XPath does not require a quoted
>         string here,
>                         just YANG.
>
>                                  Old:  /top/list[idx="4"]
>                                  New: /top/list[idx=4]
>
>                                  Instructions:
>                                  -------------
>                                  This erratum is currently posted as
>                         "Reported". If necessary,
>                                  please
>                                  use "Reply All" to discuss whether it
>         should
>                         be verified or
>                                  rejected. When a decision is reached, the
>                         verifying party
>                                  can log in to change the status and
>         edit the
>                         report, if necessary.
>
>                                  --------------------------------------
>                                  RFC7950 (draft-ietf-netmod-rfc6020bis-14)
>                                  --------------------------------------
>                                  Title               : The YANG 1.1 Data
>                         Modeling Language
>                                  Publication Date    : August 2016
>                                  Author(s)           : M. Bjorklund, Ed.
>                                  Category            : PROPOSED STANDARD
>                                  Source              : NETCONF Data
>         Modeling
>                         Language
>                                  Area                : Operations and
>         Management
>                                  Stream              : IETF
>                                  Verifying Party     : IESG
>                                  .
>
>
>
>
>
>                         _______________________________________________
>                         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
>         
>                              >
>
>
>
>
>


--------------221BBF821BE966444964574B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
On 10/24/2017 07:06 PM, Andy Bierman wrote:

    

    

      


        


          
On Tue, Oct 24, 2017 at 5:27 AM,
            Vladimir Vassilev <vladimir@transpacket.com>
            wrote:

            
On
              10/24/2017 03:42 AM, Andy Bierman wrote:

              

              

                

                

                On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev <vladimir@transpacket.com
                <mailto:vladimir@transpacket.com>>
                wrote:

                

                =C2=A0 =C2=A0 On 10/23/2017 01:35 PM, Martin Bjorklund wr=
ote:

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 Vladimir Vassilev <vladimir@transpacket.com

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:vladimir@transpacket.com>>
                wrote:

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hello,

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I would like to=
 use the occasion of this
                Errata report to

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 point out

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 some additional=
 issues with the
                instance-identifier type

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition.

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMO the instanc=
e-identifier built-in type
                has 2 additional

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 problems

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that can be add=
ressed with alternative and
                significantly

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 more radical
                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 errata or fixed=
 in a new version of YANG.:

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Problem 1: The =
obvious limitation inherited
                from Xpath 1.0

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - inability

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to escape singl=
e or double quote characters.
                In Xpath

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 world this

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitation is w=
orked around by use of
                concat() which is

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not available
                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the YANG 1.1=
 instance-identifier
                definition. 2 examples

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of this

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitation:

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. It is imposs=
ible to create value of type

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identi=
fier

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 referencing nod=
es in lists with key string
                values

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 containing both=
 a

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 single and a do=
uble quote characters e.g.

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<interfac=
e><name>"It's

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid
                string!"</name></interface>.

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Another exam=
ple of the same problem would
                be a leaf of type

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identi=
fier referencing another leaf
                of type

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identi=
fier. With 2 references it
                works provided

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 one is

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encoded with si=
ngle quotes and the other
                with double but it is

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 impossible to c=
reate third e.g.

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG:

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0list id-list {

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0key "id";

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0leaf id {

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0type instance-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 =C2=A0 =C2=
=A0}

                

                

                

                

                Although the instance-identifier is problematic, it is
                rarely used at all,

                let alone using it as a list key.

              

              It is used as a key in ietf-alarms
              /alarms/alarm-list/alarm.

              

                

                The XPath mixed-quotes problem is well-known, and the
                suggested

                solution seems to be use the "concat" function

                

                =C2=A0 =C2=A0/foo/bar[name=3Dconcat("It's a", ' "valiid" =
string')]

                

                Not very user friendly, is it?

              

              I think people naming their interfaces "It's a valid
              string!" can take it. Prettier escaping solutions are
              available e.g. C string but it will require more work then
              a line in the next YANG version RFC. IMO solution is
              needed either concat or an alternative one.

              

              Practical reason: YANG 1.1 can not create
              instance-identifier to the alarm
              /alarms/alarm-list/alarm[...
              resource=3D"/interfaces/interface[name=3D'eth0']"]. An=
d
              this is not the "That's a valid string!" named interface.
              The "That's a valid string!" interface alarms can not be
              reported as a valid ietf-alarms instance-identifier based
              resource alarm at all.

            

            


            

            


            

            


            

            
Actually the XPath designers made a reasonable
              trade-off by using concat as the solution to

            
a problem that rarely happens. =C2=A0 It is up to the IE=
TF
              to define YANG in a way that does

            
not ignore the XPath solutions.

          

        

      

    

    Yes. How about some proper rules mandating th use of quotes and
    concat like: 1. Only allow use of double quotes when there is single
    quote present. 2. Only use concat when there is both single and
    double quotes present to split the string into 1 char single quote
    strings and the rest.

    

    Then=C2=A0 /foo/bar[name=3Dconcat('It',"'",'s a valid string!"')] is =
the
    only possible canonic representation for all implementations and the
    solution is solving the rare problem without reinventing the wheel.
    

    Vladimir

    

      

        

          


            


            

            
Andy

            


            

            


            

            

              

              

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Data:

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * /top/id-list[=
id=3D"/top/list[idx=3D'4']"]

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * /top/id-list[=
id=3D"/top/id-list[idx=3D'/top/list[idx=3D4]'"]

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <assuming th=
e

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * proposed erra=
ta is also in effect>

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * <next refe=
rence not possible with YANG
                1.1>

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Problem 2: The =
instance-identifier type
                lacks canonical

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 form (which

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 makes it the on=
ly data type with
                implementation dependent

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 representation =
at the data level ... think
                of the integer

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 types

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 allowing option=
al spaces between the
                digits). This is in

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fact the only
                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 built-in data t=
ype that allows the server
                implementation

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to change the
                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration d=
ata replacing double quotes
                with single or

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the other

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 way around. Ins=
erting white spaces where you
                did not have

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 them when

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the configurati=
on was submitted. You can not
                simply read a

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration a=
nd use fast data comparison
                without schema

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 support just
                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 because of this=
 type. This is useless
                flexibility for

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 simple data

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type.

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 And this can be=
 fixed if:

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. white spaces=
 in instance-identifiers are
                prohibited

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. list key pre=
dicates are required in
                alphabetical order

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 Or perhaps use the order the =
keys are defined in
                the data

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 model (the

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 "keys" statement").

                

                =C2=A0 =C2=A0 This is an option but then the e.g. xpath2i=
nstid()
                function

                =C2=A0 =C2=A0 implementations will need schema support.
                

                

                

                All the YANG tools I have seen generate the predicates
                in YANG key order.

              

              Yes.

              

              If Xpath came with a canonical form definition
              (prohibiting spaces, redundant duplication of namespace
              prefixes in children, order of predicates, canonical
              quotation rule, and some flexibility as of the node prefix
              semantics) we would not need to have this discussion.
              Seems no other modeling language of hierarchical data has
              reusable instance-identifier datatype with the necessary
              properties and I can see this as something that can go in
              separate RFC specifying generic data type making canonic
              definition from Xpath that YANG can reuse. In that case
              the alphabetic order makes sense moving some constraints
              into the generic definition of the type one can validate
              without the context schema but it is not of significant
              importance.

              

              

                The issue of canonical instance-identifier has been
                discussed many times,

                and it is not possible to require the usage of specific
                prefixes in XML.

                (Note that Lada fixed this for JSON in RFC 7951)

              

              Yes.

              

                

                Only the string + expanded names can be properly
                compared in XML, not the literal string

                representing the XPath expression.

              

              Yes.

              

              I do not see the need of major rework just making the
              Xpath subset rules stricter with canonical requirement and
              either allowing concat() (also with canonic rule producing
              predictable result e.g. to be used only for escaping
              single quotes and prohibiting double quotes in predicates
              otherwise). Even with RFC7951 prefix rules added in the
              instance-identifier can still be a valid Xpath subset
              requiring trivial prefix replacements so that it can be
              used with non-YANG aware XML tools keeping that option
              open.

              

              Vladimir

              

                

                

                =C2=A0 =C2=A0 Vladimir

                

                

                

                Andy

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3. strict quota=
tion convention with escape
                option is

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 added. (only
                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3. contradicts =
the sec. 9.13 "..
                instance-identifier is a

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 subset of

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the XPath ..")<=
br>
                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 I would like to change one mo=
re thing - I think
                it is

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 unfortunate that

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 the lexical representation de=
pends on the
                lexical context;

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 specifically that prefixes de=
clared in the XML
                instance

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 document is

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 used.=C2=A0 This applies also=
 to identityref.=C2=A0 YANG
                2.0 should use

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 the same

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 encoding as JSON does for the=
se datatypes.

                

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 /martin

                

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Vladimir

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 10/21/2017 0=
8:16 PM, Andy Bierman wrote:

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 O=
n Sat, Oct 21, 2017 at 12:28 AM, Benoit
                Claise

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;bcl=
aise@cisco.com
                <mailto:bcl=
aise@cisco.com>

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;mailto:bcl=
aise@cisco.com
                <mailto:bcl=
aise@cisco.com>>>

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 w=
rote:

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Dear all,

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Shall I validate this one?

                

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 T=
o add more context, this relates to the
                the RESTCONF

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 J=
SON vs. XML

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 d=
iscussions in the NETCONF WG.

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0leaf broken {

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0type 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=A0type int32;

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

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

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

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I=
f all values of key leaf "broken" are
                sent as strings

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i=
n an

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i=
nstance-identifier,

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t=
hen the int32 value may not match in
                all

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i=
mplementations, instead of

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t=
he string.

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A=
llowing numbers as literals in addition
                to quoted

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s=
trings allows the

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s=
ender

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 t=
o be specific, and all implementations
                to be consistent.

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Regards, Benoit

                

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A=
ndy

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The following errata report has
                been

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s=
ubmitted for RFC7950,

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The YANG 1.1 Data Modeling
                Language".

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------=
-

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0You may review the report below
                and at:

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
a moz-do-not-send=3D"true"
                  href=3D"http://www.rfc-editor.org/errata/eid5157"
                  rel=3D"noreferrer" target=3D"_blank">http://www.rfc-edi=
tor.org/errata/eid5157

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;http://www.rfc-edi=
tor.org/errata/eid5157>

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.rfc-edi=
tor.org/errata/eid5157

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;http://www.rfc-edi=
tor.org/errata/eid5157>>

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------=
-

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Type: Technical

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reported by: Andy Bierman <an=
dy@yumaworks.com

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;mailto:an=
dy@yumaworks.com>

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:an=
dy@yumaworks.com

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;mailto:an=
dy@yumaworks.com>>>

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section: 14

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Original Text

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D
                node-identifier *WSP

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
=3D" *WSP

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0quoted-string

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Corrected Text

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--------------

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key-predicate-expr=C2=A0 =3D
                node-identifier *WSP

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
=3D" *WSP

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (quoted-strin=
g /
                integer-value /

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 d=
ecimal-value)

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Notes

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An instance identifier is
                forced to specify

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e=
very key value to

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be a string

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0even though the YANG key leaf
                type could be a

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n=
umeric type.

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0XPath does not require a quoted
                string here,

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 j=
ust YANG.

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Old:=C2=A0 /top/list[idx=3D"4"]

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0New: /top/list[idx=3D4]

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Instructions:

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This erratum is currently
                posted as

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
Reported". If necessary,

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0please

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use "Reply All" to discuss
                whether it should

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 b=
e verified or

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rejected. When a decision is
                reached, the

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=
erifying party

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can log in to change the status
                and edit the

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r=
eport, if necessary.

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------=
-

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC7950
                (draft-ietf-netmod-rfc6020bis-14)

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------=
-

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0: The YANG
                1.1 Data

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M=
odeling Language

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Publication Date=C2=A0 =C2=A0 : August
                2016

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0: M.
                Bjorklund, Ed.

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 : PROPOSED
                STANDARD

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 : NETCONF
                Data Modeling

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 L=
anguage

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 :
                Operations and Management

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 : IETF

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG<=
br>
                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.

                

                

                

                

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _=
______________________________________________

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n=
etmod mailing list

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
a moz-do-not-send=3D"true"
                  href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmo=
d@ietf.org
                <mailto:netmo=
d@ietf.org>

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
a moz-do-not-send=3D"true"
                  href=3D"https://www.ietf.org/mailman/listinfo/netmod"
                  rel=3D"noreferrer" target=3D"_blank">https://www.ietf.o=
rg/mailman/listinfo/netmod

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;https://www.ietf.o=
rg/mailman/listinfo/netmod>

                

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________=
________________________________

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 netmod mailing =
list

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 netmo=
d@ietf.org
                <mailto:netmo=
d@ietf.org>

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o=
rg/mailman/listinfo/netmod

                =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.o=
rg/mailman/listinfo/netmod>

                

                

                

              

              

            

          

          

        

      

    

    

  


--------------221BBF821BE966444964574B--


From nobody Wed Oct 25 04:10:31 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C8A13B2B2 for ; Wed, 25 Oct 2017 04:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIaos6wW-y7d for ; Wed, 25 Oct 2017 04:10:22 -0700 (PDT)
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 F2E7413AE04 for ; Wed, 25 Oct 2017 04:10:21 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 51F7C373; Wed, 25 Oct 2017 13:10:20 +0200 (CEST)
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 MZFTcl-5uilR; Wed, 25 Oct 2017 13:10:20 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Oct 2017 13:10:20 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3EB0C2010B; Wed, 25 Oct 2017 13:10:20 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Sr-_O7TI6bBa; Wed, 25 Oct 2017 13:10:19 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66BAA2010A; Wed, 25 Oct 2017 13:10:19 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D194F413C133; Wed, 25 Oct 2017 13:08:52 +0200 (CEST)
Date: Wed, 25 Oct 2017 13:08:51 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Robert Wilton , Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20171025110851.wdoj2dbrqmxz5shd@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Robert Wilton , Martin Bjorklund , "netmod@ietf.org" 
References: <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 11:10:30 -0000

It seems we are jumping between topics. I will skip over comments
concerning the YANG library and whether it is OK or not OK that YANG
library allows different schemas in different datastores.

On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote:
> On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
> > >
> > > IMO the more complex NMDA is to implement, the less likely it will
> > > be implemented.  If you want the tools to figure out the correct
> > > datastore(s) from description-stmts instead of something
> > > deterministic and machine-usable, NMDA is less likely to be
> > > implemented.
> >
> > There is nothing machine readable today that tells you which argument
> > of get-config identifies the datastore that is being accessed by
> > get-config. Our reasoning is that for most actions that default is
> > going to do the right thing. If there is a need to have further
> > language support to handle the cases where operations may relate to
> > datastores different than operational, then this should be taken up by
> > a future version of YANG.
> >
> >
> There is only 1 schema tree now in pre-NMDA so it is easy to parse
> instance data against the one and only set of modules.
> 
> 
> 
> > > Given that the same objects can be defined differently in each
> > > datastore in NMDA, it is especially useful to know which set of YANG
> > > modules applies, before parsing instance data against those modules.
> >
> > I am not sure I parse this correctly.
> >
> 
> The new YANG library requires the implementation to know the datastore
> to pick the correct set of modules for the datastore used in the operation.
> Module sets are allowed to overlap, so the same module can be different
> in  vs. .
> 
> Developers unaware of the new NMDA complexities should read the drafts
> again.
> 
> 
> 
> >
> > > (2) Define :
> > > >
> > > > I'm not convinced that this is really required/helpful, given that most
> > > > actions are likely to only apply to operational.  If it turns out that
> > this
> > > > is particularly useful then I would propose that this is deferred
> > until a
> > > > future revision of NETCONF, particularly because we are trying to keep
> > the
> > > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
> > > >
> > > > Is this OK?
> > > >
> > >
> > > The NMDA theme has been to declare things that are possible in pre-NMDA
> > > but not supported in post-NMDA to be not useful, so this can be left to
> > > vendors I guess.
> >
> > Not sure I understand this either.
> >
> > If you have a concrete change proposal, perhaps the discussion becomes
> > more concrete and productive.
> >
> 
> 
> I already said to declare that  is invoked in . Period.
> No description-stmt exceptions.
>
> If another datastore is needed, use rpc-stmt instead of action-stmt.

So you are fine if for RPCs description statements can define which
datastores are affected by an RPC? I probably did not get that you
make a distinction between actions and RPCs here.

/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 Oct 25 05:49:55 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC3E1377B3; Wed, 25 Oct 2017 05:49:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150893578927.4882.2117597388624976982@ietfa.amsl.com>
Date: Wed, 25 Oct 2017 05:49:49 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.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, 25 Oct 2017 12:49:49 -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-02.txt
	Pages           : 11
	Date            : 2017-10-25

Abstract:
   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.


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-02
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-02


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 Oct 25 06:14:08 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16F21375C9 for ; Wed, 25 Oct 2017 06:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYzEU9vVF9wM for ; Wed, 25 Oct 2017 06:14:04 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 40536137832 for ; Wed, 25 Oct 2017 06:14:04 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 4426E1E09AB for ; Wed, 25 Oct 2017 07:14:02 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id RpDy1w00H2SSUrH01pE1HK; Wed, 25 Oct 2017 07:14:02 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=0ZgzDHaQzhVBHrr1te0A: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: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=uLtOL7cfIrIUBJZXI7It7zjEJkXL1wBR/gtXBiVFYxs=; b=Wpe1Vspp/XoSE97H1ItMpl3Bxj 1ByWo2/Myx2WadhQhPPWBHJEq5Zi97CHbO8lUh3SvMyjbPuPjSsqPrWzIogT8diLM9TihTsQDDzJ5 lscx60TTl/EEdmaRXnSJR7c8q;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:50902 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e7LVO-003EKI-8v for netmod@ietf.org; Wed, 25 Oct 2017 07:13:58 -0600
To: netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com>
From: Lou Berger 
Message-ID: <23892572-a0db-d24b-e591-a19799ace9ae@labn.net>
Date: Wed, 25 Oct 2017 09:13:56 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <150893578927.4882.2117597388624976982@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
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: 1e7LVO-003EKI-8v
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]:50902
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.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, 25 Oct 2017 13:14:07 -0000

Hi,

    This version addresses all known / open issues in the draft known to
the authors.

The changes are as follows:
- Added groupings and yang-data descriptions
- Added Comments, Long Diagrams and Security Considerations sections
- Clarified representation of schema mount points and representation of
  modules exposed using schema mount.
- Miscellaneous editorial changes

Lou (for draft authors)

On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
>         Authors         : Martin Bjorklund
>                           Lou Berger
> 	Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
> 	Pages           : 11
> 	Date            : 2017-10-25
>
> Abstract:
>    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.
>
>
> 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-02
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-02
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Oct 25 06:20:17 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD441384B2 for ; Wed, 25 Oct 2017 06:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVSQuZdmHROZ for ; Wed, 25 Oct 2017 06:20:13 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771AB137C2E for ; Wed, 25 Oct 2017 06:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2539; q=dns/txt; s=iport; t=1508937613; x=1510147213; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=4ybFvpxKoE8twlN1WNPZajPC1P3HIQyhdJRWnIfmRn4=; b=WRUNbrgmeeKLqkEYPvnYLQKqHWhOGh8kj7hUBQ1k8PjTKlC49Jv00YI/ jeD2wol6t32aiAE78LMAGyQD90JANV5lNq+YqfHT5cc8pz8emQpB7jbUE PJVzF7ZHG4y1fxwKkfEsbCW/nLg4DAdO6YLE7USn5pUKlKtkXR14RVS0y U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAACIjvBZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ih90j2smljqCEQoYDYRHTwKFKxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?eAQEEAQEhDwEFNhsLDgoCAiYCAicwBgEMBgIBAYocEKkYgieLEAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2BD4Ifg1eCEguCdoMyhGeCYQWhc4dljRKCFV2FHoNdhzm?= =?us-ascii?q?OGodngTkfOIFbNCEIHRUfKoJkCYRXPzaMHAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,431,1503360000"; d="scan'208";a="658302120"
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; 25 Oct 2017 13:20:11 +0000
Received: from [10.63.23.81] (dhcp-ensft1-uk-vla370-10-63-23-81.cisco.com [10.63.23.81]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9PDKAZA007654; Wed, 25 Oct 2017 13:20:10 GMT
To: Lou Berger , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net>
From: Robert Wilton 
Message-ID: 
Date: Wed, 25 Oct 2017 14:20:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <23892572-a0db-d24b-e591-a19799ace9ae@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.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, 25 Oct 2017 13:20:15 -0000

Hi Lou,

Do you know when the plan is to call WG LC on this draft?  It is another 
draft that would be good to get out of the door so that all the drafts 
that define YANG modules can reference it.

Thanks,
Rob


On 25/10/2017 14:13, Lou Berger wrote:
> Hi,
>
>      This version addresses all known / open issues in the draft known to
> the authors.
>
> The changes are as follows:
> - Added groupings and yang-data descriptions
> - Added Comments, Long Diagrams and Security Considerations sections
> - Clarified representation of schema mount points and representation of
>    modules exposed using schema mount.
> - Miscellaneous editorial changes
>
> Lou (for draft authors)
>
> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
>>          Authors         : Martin Bjorklund
>>                            Lou Berger
>> 	Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
>> 	Pages           : 11
>> 	Date            : 2017-10-25
>>
>> Abstract:
>>     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.
>>
>>
>> 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-02
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-02
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 25 06:21:50 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0429813A65C for ; Wed, 25 Oct 2017 06:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLsqWIPXrbLC for ; Wed, 25 Oct 2017 06:21:47 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704F8137C2E for ; Wed, 25 Oct 2017 06:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1886; q=dns/txt; s=iport; t=1508937707; x=1510147307; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mvx+XYS5LeuV//Pcs+dy4XgsERvMqyU6AK9iYKR9kKg=; b=YL/UqCl8wc4eCnNWvJMrSUiTqQ7JLpiL26n8/mzNuNyNm9j6dvynBaFe XCfoEUTZJilAo/P5LQs5GyPyLMmHYm4MYK2Ba2RPPu8LC8F943WTJ+s/3 i7GQJ2GwVDvqkje+x3tLf3NKxkmpddQ+VHW5nDzvWKkWPRsnET0qhhj1N k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAQCIjvBZ/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzEuZG4nB4NzmSqYRIIBChgLhElPHIRSQxQBAgEBAQEBAQFrKIU?= =?us-ascii?q?eAgQBASEROgsSAQgODAImAgQlCxUSBAENBYogEKkYgieLEAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEaBYEPgh+CB4ZjhFIBEgEHGIMUgmEFoXMClHWCFYV7hAGHFZVUAhE?= =?us-ascii?q?ZAYE4ATYhgQNYehVJgmSEX3aJZ4EkgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,431,1503360000"; d="scan'208";a="310274180"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2017 13:21:46 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v9PDLj4b016088 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Oct 2017 13:21:46 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 25 Oct 2017 09:21:45 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 25 Oct 2017 09:21:44 -0400
From: "Acee Lindem (acee)" 
To: Kent Watsen , "netmod@ietf.org" 
CC: "Sonal Agarwal (agarwaso)" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
Thread-Index: AQHTTZQz4R9mVwyDOkCxkCX5K2HeVg==
Date: Wed, 25 Oct 2017 13:21:44 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.195]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9D410793B831EB4AB45312A526F5517D@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 13:21:49 -0000

SGkgS2VudCwgTWFoZXNoLCBldCBhbCwNCg0KSSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBzdXBw
b3J0IHB1YmxpY2F0aW9uLiBJIGhhdmUgdHdvIGNvbW1lbnRzIG9uIHRoZQ0KLTE0IHZlcnNpb24u
IA0KDQogIDEuIFRoZSB0cmVlIGRpYWdyYW1zIGRvIG5vdCBmaXQgd2l0aGluIHRoZSBkcmFmdCBw
YWdlcy4gTm90ZSB0aGF0IHJlY2VudA0KdmVyc2lvbnMgb2YgcHlhbmcgc3VwcG9ydCB0aGUg4oCU
dHJlZS1saW5lLWxlbmd0aCBwYXJhbWV0ZXIgYW5kIHRoaXMgbWF5DQpoZWxwLiANCiAgMi4gV2hp
bGUgaXQgaXMgbm9uLW5vcm1hdGl2ZSwgSeKAmWQgcHJlZmVyIHRvIGhhdmUgYXBwZW5kaXggQS4x
IHJlbW92ZWQuDQpJdCB3YXMgYSBtaXN0YWtlIGZvciB2ZW5kb3JzIHRvIG1peCBwYWNrZXQgZmls
dGVyaW5nIGFuZCByb3V0ZSBmaWx0ZXJpbmcNCmluIHRoZSBmaXJzdCBwbGFjZSBhbmQgdGhlIGRy
YWZ0IHNob3VsZCBub3QgaW5zaW51YXRlIHRoYXQgdGhlIG1vZGVsIHdpbGwNCmJlIGF1Z21lbnRl
ZCB0byBkbyB0aGlzLg0KDQpUaGFua3MsDQpBY2VlIA0KDQpPbiAxMC8yMC8xNywgNTozNyBQTSwg
Im5ldG1vZCBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4iDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5v
cmcgb24gYmVoYWxmIG9mIGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+DQo+QWxsLA0K
Pg0KPlRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj5k
cmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQuDQo+DQo+VGhlIHdvcmtpbmcgZ3JvdXAgbGFz
dCBjYWxsIGVuZHMgb24gTm92ZW1iZXIgMy4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRv
IHRoZSBuZXRtb2QgbWFpbGluZyBsaXN0Lg0KPg0KPlBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAi
SSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50DQo+YW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9y
IHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNvbWUhDQo+VGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFu
dCwgZXZlbiBmcm9tIGF1dGhvcnMuDQo+DQo+Q291bGQgdGhlIGF1dGhvcnMsIGV4cGxpY2l0bHkg
Q0MtZWQgb24gdGhpcyBlbWFpbCwgcGxlYXNlDQo+YWxzbyBjb25maXJtIGF0IHRoaXMgdGltZSB0
aGF0IHRoZXkgYXJlIHVuYXdhcmUgb2YgYW55DQo+SVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4N
Cj4NCj5UaGFuayB5b3UsDQo+TmV0bW9kIENoYWlycw0KPg0KPg0KPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5l
dG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kDQoNCg==


From nobody Wed Oct 25 07:10:02 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD04D1388A9 for ; Wed, 25 Oct 2017 07:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 zsBuswN2wXbE for ; Wed, 25 Oct 2017 07:09:59 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 4A8581384B2 for ; Wed, 25 Oct 2017 07:09:59 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id E601E1E08DB for ; Wed, 25 Oct 2017 08:09:55 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id Rq9s1w0092SSUrH01q9vSf; Wed, 25 Oct 2017 08:09:55 -0600
X-Authority-Analysis: v=2.2 cv=H76r+6Qi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=MtRI_ybKjFLk42iChNQA: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: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=mOjAl9URObI+yies7CDfxJ0H+nPFsuzPCfzLgUEwKYk=; b=SyEOagAH8F3T8jx2UN+Fphn4hT yT4u/l4t/gCN7GUOut/Y2KP4O7tZGtRNjxMyboYyyMACJV5J/JnY4BcOquvBVw1+yrZZhcigef3A0 Qm6BvsFyBYXQj2Twk638Inop3;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:53622 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e7MNT-003Ts8-Ab; Wed, 25 Oct 2017 08:09:52 -0600
To: Robert Wilton , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> 
From: Lou Berger 
Message-ID: <6ab3a8c7-abbd-53bf-463e-3f684a5c4a20@labn.net>
Date: Wed, 25 Oct 2017 10:09:49 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
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: 1e7MNT-003Ts8-Ab
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]:53622
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.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, 25 Oct 2017 14:10:01 -0000

Hi Rob,

On 10/25/2017 9:20 AM, Robert Wilton wrote:
> Hi Lou,
>
> Do you know when the plan is to call WG LC on this draft?  

This is Kent's call as I'm co-author.

> It is another 
> draft that would be good to get out of the door so that all the drafts 
> that define YANG modules can reference it.
I agree, and while I was originally pushing for an immediate LC, I also
think it is reasonable to review the changes in Singapore and then,
assuming no disagreement from the WG, move immediately thereafter to LC.

I also think it is fine/good for other drafts to reference this draft
now given LC is soon either way.

Lou

> Thanks,
> Rob
>
>
> On 25/10/2017 14:13, Lou Berger wrote:
>> Hi,
>>
>>      This version addresses all known / open issues in the draft known to
>> the authors.
>>
>> The changes are as follows:
>> - Added groupings and yang-data descriptions
>> - Added Comments, Long Diagrams and Security Considerations sections
>> - Clarified representation of schema mount points and representation of
>>    modules exposed using schema mount.
>> - Miscellaneous editorial changes
>>
>> Lou (for draft authors)
>>
>> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
>>>          Authors         : Martin Bjorklund
>>>                            Lou Berger
>>> 	Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
>>> 	Pages           : 11
>>> 	Date            : 2017-10-25
>>>
>>> Abstract:
>>>     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.
>>>
>>>
>>> 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-02
>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-02
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-02
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Oct 25 07:43:51 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208D11384B2 for ; Wed, 25 Oct 2017 07:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQIy0i-qu-2Q for ; Wed, 25 Oct 2017 07:43:49 -0700 (PDT)
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 8CACA138713 for ; Wed, 25 Oct 2017 07:43:49 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 54540F87; Wed, 25 Oct 2017 16:43:48 +0200 (CEST)
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 kQ9BDrRegjnM; Wed, 25 Oct 2017 16:43:47 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Oct 2017 16:43:48 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4061C2010B; Wed, 25 Oct 2017 16:43:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Og-9ILkbVvnO; Wed, 25 Oct 2017 16:43:47 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71FD52010A; Wed, 25 Oct 2017 16:43:47 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 186D7413C7D3; Wed, 25 Oct 2017 16:42:22 +0200 (CEST)
Date: Wed, 25 Oct 2017 16:42:22 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Lou Berger , netmod@ietf.org
Message-ID: <20171025144222.fyjpong223vhz637@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Lou Berger , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> 
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: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.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, 25 Oct 2017 14:43:51 -0000

While the tree diagram ID has only informative references, I
think this is actually not true. I think RFC7950, RFC 8040 and
I-D.ietf-netmod-schema-mount are actually normative references
since they define the nodes we are talking about.

If so, this ID depends on schema mount. Not a problem but won't be
published before schema mount is coming out as well.

/js

On Wed, Oct 25, 2017 at 02:20:10PM +0100, Robert Wilton wrote:
> Hi Lou,
> 
> Do you know when the plan is to call WG LC on this draft?  It is another
> draft that would be good to get out of the door so that all the drafts that
> define YANG modules can reference it.
> 
> Thanks,
> Rob
> 
> 
> On 25/10/2017 14:13, Lou Berger wrote:
> > Hi,
> > 
> >      This version addresses all known / open issues in the draft known to
> > the authors.
> > 
> > The changes are as follows:
> > - Added groupings and yang-data descriptions
> > - Added Comments, Long Diagrams and Security Considerations sections
> > - Clarified representation of schema mount points and representation of
> >    modules exposed using schema mount.
> > - Miscellaneous editorial changes
> > 
> > Lou (for draft authors)
> > 
> > On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
> > >          Authors         : Martin Bjorklund
> > >                            Lou Berger
> > > 	Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
> > > 	Pages           : 11
> > > 	Date            : 2017-10-25
> > > 
> > > Abstract:
> > >     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.
> > > 
> > > 
> > > 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-02
> > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-02
> > > 
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-02
> > > 
> > > 
> > > Please note that it may take a couple of minutes from the time of submission
> > > until the htmlized version and diff are available at tools.ietf.org.
> > > 
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Wed Oct 25 08:54:47 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54A213DC3B for ; Wed, 25 Oct 2017 08:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frWfryUc7R2G for ; Wed, 25 Oct 2017 08:54:43 -0700 (PDT)
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 958D713F3EE for ; Wed, 25 Oct 2017 08:54:42 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id n69so524394lfn.2 for ; Wed, 25 Oct 2017 08:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cdSCiTlNWgeAX7u4F9akSPJx/LhQ1j+BT3sZdO8xNLQ=; b=1ty8PHziayD8LRk7XzcP26OQCsND/hp7UnUzRCBRN1UicvIct/u6Bve3OzG8lqrpsZ 5/QfncHkzqbrIcW8ujfV3xbs8/y0gx3STY4GoVpNvakxAYYVh9S83eWUN5AdKkrwVZ+x 5oIiDenvof4cQKj2tEPwWatCW+gt2MvaPnbcSt3aWUA/crs8/bmXg52suhe+Tdx7AvhP 6LnpqADUTTkfy7lbvBBFalFVWsaYX7r/rJ1iJr3+aqpLZlQCoNgcBSiT4HqAiKFo5tTi 6U/TOyNBVkA6KeKCDMrVQhSe2BQl4M7fvlE9Vx9/ODOGNITHw94Ph+FxzDW5BBnehg3m e7ZQ==
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=cdSCiTlNWgeAX7u4F9akSPJx/LhQ1j+BT3sZdO8xNLQ=; b=Pgy4qBGJf6PCMDm5zVw/L4Z6/d9hbhufKqsMTuv3gHQaeo1OhGWrSAQd444+d2AYjE cVdwcguchrBCUsxKQOLonrJoYdZRRrgJCQYPrgBB9vZ6mILSh84cxZHmHZkowK8E392N z+qRfMc4jv9R5ecKniG6TDsh92XEulnklWw+76vl05Yal3gyu4snsgejr1YcYknhK+Vr O+TzAZleMN2L675djTW/1NPUJIhKDyKt7ZylZyPDGY9Z5wiAlr7sbL2MORR9Nd1MLLPW EYVDA5pl1mDTAPuZmmUYfDs79UVU2YU/EcApZ/Vc5aEjKuu5qa0F4te6D0aUyztH6mFC 5Svg==
X-Gm-Message-State: AMCzsaWh0mCMe6Gu+AE1/DCvGwXPBDWj2atzvbn/hrJcWgTcpVkn6HTB /4aDjaix2Zdf96pwC4lIZivK2zwwdskkr4s1av/m1A==
X-Google-Smtp-Source: ABhQp+T8rMec95NqmPYyS1Orkk8scX8qPwD9guu4PbTRtzzE2F4z915aTd0mhmgI598iCAUwQgE3oNDuvksL5XQMvx8=
X-Received: by 10.25.211.73 with SMTP id k70mr7125011lfg.51.1508946880715; Wed, 25 Oct 2017 08:54:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 25 Oct 2017 08:54:39 -0700 (PDT)
In-Reply-To: <20171025110851.wdoj2dbrqmxz5shd@elstar.local>
References: <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local>  <20171025110851.wdoj2dbrqmxz5shd@elstar.local>
From: Andy Bierman 
Date: Wed, 25 Oct 2017 08:54:39 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Robert Wilton , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114188aacf742a055c6112c3"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 15:54:46 -0000

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

On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> It seems we are jumping between topics. I will skip over comments
> concerning the YANG library and whether it is OK or not OK that YANG
> library allows different schemas in different datastores.
>
\
\

Actually, this is the only issue that matters.

I decided that no special text is needed because the YANG library is
violating a MUST requirement
in RFC 7950 and needs to be changed.

There can only be one implementation of a module per server, not per
datastore.
Therefore a module MAY appear in multiple module-sets, but it MUST NOT
be different.  The exact same revision, features, and deviations MUST be
present
in each instance.

Andy



> On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote:
> > On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
> > > >
> > > > IMO the more complex NMDA is to implement, the less likely it will
> > > > be implemented.  If you want the tools to figure out the correct
> > > > datastore(s) from description-stmts instead of something
> > > > deterministic and machine-usable, NMDA is less likely to be
> > > > implemented.
> > >
> > > There is nothing machine readable today that tells you which argument
> > > of get-config identifies the datastore that is being accessed by
> > > get-config. Our reasoning is that for most actions that default is
> > > going to do the right thing. If there is a need to have further
> > > language support to handle the cases where operations may relate to
> > > datastores different than operational, then this should be taken up by
> > > a future version of YANG.
> > >
> > >
> > There is only 1 schema tree now in pre-NMDA so it is easy to parse
> > instance data against the one and only set of modules.
> >
> >
> >
> > > > Given that the same objects can be defined differently in each
> > > > datastore in NMDA, it is especially useful to know which set of YANG
> > > > modules applies, before parsing instance data against those modules.
> > >
> > > I am not sure I parse this correctly.
> > >
> >
> > The new YANG library requires the implementation to know the datastore
> > to pick the correct set of modules for the datastore used in the
> operation.
> > Module sets are allowed to overlap, so the same module can be different
> > in  vs. .
> >
> > Developers unaware of the new NMDA complexities should read the drafts
> > again.
> >
> >
> >
> > >
> > > > (2) Define :
> > > > >
> > > > > I'm not convinced that this is really required/helpful, given that
> most
> > > > > actions are likely to only apply to operational.  If it turns out
> that
> > > this
> > > > > is particularly useful then I would propose that this is deferred
> > > until a
> > > > > future revision of NETCONF, particularly because we are trying to
> keep
> > > the
> > > > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
> > > > >
> > > > > Is this OK?
> > > > >
> > > >
> > > > The NMDA theme has been to declare things that are possible in
> pre-NMDA
> > > > but not supported in post-NMDA to be not useful, so this can be left
> to
> > > > vendors I guess.
> > >
> > > Not sure I understand this either.
> > >
> > > If you have a concrete change proposal, perhaps the discussion becomes
> > > more concrete and productive.
> > >
> >
> >
> > I already said to declare that  is invoked in .
> Period.
> > No description-stmt exceptions.
> >
> > If another datastore is needed, use rpc-stmt instead of action-stmt.
>
> So you are fine if for RPCs description statements can define which
> datastores are affected by an RPC? I probably did not get that you
> make a distinction between actions and RPCs here.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
It seems we are jumping between topics. I will skip =
over comments

concerning the YANG library and whether it is OK or not OK that YANG

library allows different schemas in different datastores.
<=
div>\
\

Actually, this is the only issue=
 that matters.

I decided that no special text is n=
eeded because the YANG library is violating a MUST requirement
in=
 RFC 7950 and needs to be changed.

There can only =
be one implementation of a module per server, not per datastore.
=
Therefore a module MAY appear in multiple module-sets, but it MUST NOT
be different.=C2=A0 The exact same revision, features, and deviations=
 MUST be present
in each instance.

Andy<=
/div>





On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote:

> On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <

> j.schoenwaelde=
r@jacobs-university.de> wrote:

>

> > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:

> > >

> > > IMO the more complex NMDA is to implement, the less likely i=
t will

> > > be implemented.=C2=A0 If you want the tools to figure out th=
e correct

> > > datastore(s) from description-stmts instead of something

> > > deterministic and machine-usable, NMDA is less likely to be<=
br>
> > > implemented.

> >

> > There is nothing machine readable today that tells you which argu=
ment

> > of get-config identifies the datastore that is being accessed by<=
br>
> > get-config. Our reasoning is that for most actions that default i=
s

> > going to do the right thing. If there is a need to have further
> > language support to handle the cases where operations may relate =
to

> > datastores different than operational, then this should be taken =
up by

> > a future version of YANG.

> >

> >

> There is only 1 schema tree now in pre-NMDA so it is easy to parse

> instance data against the one and only set of modules.

>

>

>

> > > Given that the same objects can be defined differently in ea=
ch

> > > datastore in NMDA, it is especially useful to know which set=
 of YANG

> > > modules applies, before parsing instance data against those =
modules.

> >

> > I am not sure I parse this correctly.

> >

>

> The new YANG library requires the implementation to know the datastore=


> to pick the correct set of modules for the datastore used in the opera=
tion.

> Module sets are allowed to overlap, so the same module can be differen=
t

> in <running> vs. <operational>.

>

> Developers unaware of the new NMDA complexities should read the drafts=


> again.

>

>

>

> >

> > > (2) Define <action2>:

> > > >

> > > > I'm not convinced that this is really required/help=
ful, given that most

> > > > actions are likely to only apply to operational.=C2=A0 =
If it turns out that

> > this

> > > > is particularly useful then I would propose that this i=
s deferred

> > until a

> > > > future revision of NETCONF, particularly because we are=
 trying to keep

> > the

> > > > NETCONF NMDA and RESTCONF NMDA drafts as small as possi=
ble.

> > > >

> > > > Is this OK?

> > > >

> > >

> > > The NMDA theme has been to declare things that are possible =
in pre-NMDA

> > > but not supported in post-NMDA to be not useful, so this can=
 be left to

> > > vendors I guess.

> >

> > Not sure I understand this either.

> >

> > If you have a concrete change proposal, perhaps the discussion be=
comes

> > more concrete and productive.

> >

>

>

> I already said to declare that <action> is invoked in <operat=
ional>. Period.

> No description-stmt exceptions.

>

> If another datastore is needed, use rpc-stmt instead of action-stmt.


So you are fine if for RPCs description statements can define which

datastores are affected by an RPC? I probably did not get that you

make a distinction between actions and RPCs here.



/js



--

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

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

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





--001a114188aacf742a055c6112c3--


From nobody Wed Oct 25 10:05:49 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4731394F1 for ; Wed, 25 Oct 2017 10:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 gWBMzz1vnExY for ; Wed, 25 Oct 2017 10:05:40 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B638138726 for ; Wed, 25 Oct 2017 10:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20226; q=dns/txt; s=iport; t=1508951140; x=1510160740; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Aa62ZWoQ/pics7Vzo63MdNK25ekfaspO0u+EvWejffY=; b=OPVnouIGAVJUnao88ZR0gL24+gQAH0bDMeKCZ5R7yQRQs8nrYOyUb3bW WheivP4KGZsbPhQvH4ciHMmwbKK5qhULoWErXqB07bsTAFZO0DGZHiMQC aBqRlXp/bLovOcuZUdot9258/Q8b7s/B3L/vGSTHePMZEBpsZJyisDqtJ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQALxPBZ/xbLJq1YAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvgVRuJ4N6ixOQEZB4hUKCEQofgz6BXgKFLRcBAgEBAQEBAQF?= =?us-ascii?q?rKIUdAQEBAwEjZAIJAhAIJwMCAhsrEQYBDAYCAQGKFAiLc51ngicmilMBAQEBA?= =?us-ascii?q?QEBAwEBAQEBAQEBAQEBHQWDKYNXgWkpgwGEbzcmgk2CYQWYdoh9lHeCFYlYJIc?= =?us-ascii?q?VjhqHZ4E5IQMzgVs0IQgdFUmCZAmCGjkcgWg/NowKAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,432,1503360000";  d="scan'208,217";a="656578772"
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; 25 Oct 2017 17:05:37 +0000
Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9PH5bci004764; Wed, 25 Oct 2017 17:05:37 GMT
To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" 
References: <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local>  <20171025110851.wdoj2dbrqmxz5shd@elstar.local> 
From: Robert Wilton 
Message-ID: 
Date: Wed, 25 Oct 2017 18:05:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------3F01318C4E05690CBDF4CC7F"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 17:05:47 -0000

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

Hi Andy,


On 25/10/2017 16:54, Andy Bierman wrote:
>
>
> On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder 
>  > wrote:
>
>     It seems we are jumping between topics. I will skip over comments
>     concerning the YANG library and whether it is OK or not OK that YANG
>     library allows different schemas in different datastores.
>
> \
> \
>
> Actually, this is the only issue that matters.
>
> I decided that no special text is needed because the YANG library is 
> violating a MUST requirement
> in RFC 7950 and needs to be changed.
Are you referring to this text, or something else:

5.6.5.  Implementing a Module

    A server implements a module if it implements the module's data
    nodes, RPCs, actions, notifications, and deviations.

    A server MUST NOT implement more than one revision of a module.

If, so, then we still agree with this constraint, and this hasn't 
changed for NMDA.  I think that YANG library should make this clear in 
the list of modules.

But I don't think that text specifically prevents different deviations 
or features for different datastores ...

>
> There can only be one implementation of a module per server, not per 
> datastore.
> Therefore a module MAY appear in multiple module-sets, but it MUST NOT
> be different.  The exact same revision, features, and deviations MUST 
> be present
> in each instance.

The NMDA draft already states that the schema for all conventional 
configuration datastores must be the same (meaning that all deviations 
and features must be the same as well):

5.1. Conventional Configuration Datastores

    The conventional configuration datastores are a set of configuration
    datastores that share exactly the same schema, allowing data to be
    copied between them.


So, I think that the main question is about how the schema for 
 can differ from the configuration datatstores.

We want to allow different features to be supported in running vs 
operational, so that feature statements can be useful to turn off 
features that may be supported by a device, but might not be externally 
configurable (e.g router-id).  But we could partially constrain their 
use.  So I propose that we add the following extra sentence to the NMDA 
draft on section 5.3  The Operational State Datastore ().

My proposed NEW text is:

If a YANG feature is supported for a module in any configuration 
datastore then it SHOULD also be supported in .  This is to 
allow the applied configuration and any other operational state 
associated with that feature to be available.  The inverse constraint 
does not hold, a server MAY support a feature in  without 
also supporting it in any configuration datatstore.


I'm not sure that it makes sense to constrain deviations to be the same 
for all datastores, since these are the mechanism for reporting why a 
server doesn't conform to the standard ...

Thanks,
Rob


>
> Andy
>
>
>
>     On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote:
>     > On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <
>     > j.schoenwaelder@jacobs-university.de
>     > wrote:
>     >
>     > > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
>     > > >
>     > > > IMO the more complex NMDA is to implement, the less likely
>     it will
>     > > > be implemented.  If you want the tools to figure out the correct
>     > > > datastore(s) from description-stmts instead of something
>     > > > deterministic and machine-usable, NMDA is less likely to be
>     > > > implemented.
>     > >
>     > > There is nothing machine readable today that tells you which
>     argument
>     > > of get-config identifies the datastore that is being accessed by
>     > > get-config. Our reasoning is that for most actions that default is
>     > > going to do the right thing. If there is a need to have further
>     > > language support to handle the cases where operations may
>     relate to
>     > > datastores different than operational, then this should be
>     taken up by
>     > > a future version of YANG.
>     > >
>     > >
>     > There is only 1 schema tree now in pre-NMDA so it is easy to parse
>     > instance data against the one and only set of modules.
>     >
>     >
>     >
>     > > > Given that the same objects can be defined differently in each
>     > > > datastore in NMDA, it is especially useful to know which set
>     of YANG
>     > > > modules applies, before parsing instance data against those
>     modules.
>     > >
>     > > I am not sure I parse this correctly.
>     > >
>     >
>     > The new YANG library requires the implementation to know the
>     datastore
>     > to pick the correct set of modules for the datastore used in the
>     operation.
>     > Module sets are allowed to overlap, so the same module can be
>     different
>     > in  vs. .
>     >
>     > Developers unaware of the new NMDA complexities should read the
>     drafts
>     > again.
>     >
>     >
>     >
>     > >
>     > > > (2) Define :
>     > > > >
>     > > > > I'm not convinced that this is really required/helpful,
>     given that most
>     > > > > actions are likely to only apply to operational.  If it
>     turns out that
>     > > this
>     > > > > is particularly useful then I would propose that this is
>     deferred
>     > > until a
>     > > > > future revision of NETCONF, particularly because we are
>     trying to keep
>     > > the
>     > > > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
>     > > > >
>     > > > > Is this OK?
>     > > > >
>     > > >
>     > > > The NMDA theme has been to declare things that are possible
>     in pre-NMDA
>     > > > but not supported in post-NMDA to be not useful, so this can
>     be left to
>     > > > vendors I guess.
>     > >
>     > > Not sure I understand this either.
>     > >
>     > > If you have a concrete change proposal, perhaps the discussion
>     becomes
>     > > more concrete and productive.
>     > >
>     >
>     >
>     > I already said to declare that  is invoked in
>     . Period.
>     > No description-stmt exceptions.
>     >
>     > If another datastore is needed, use rpc-stmt instead of action-stmt.
>
>     So you are fine if for RPCs description statements can define which
>     datastores are affected by an RPC? I probably did not get that you
>     make a distinction between actions and RPCs here.
>
>     /js
>
>     --
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103              >
>
>


--------------3F01318C4E05690CBDF4CC7F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Andy,

    

    

    
On 25/10/2017 16:54, Andy Bierman
      wrote:

    

    

      
      


        


          
On Wed, Oct 25, 2017 at 4:08 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
It seems
              we are jumping between topics. I will skip over comments

              concerning the YANG library and whether it is OK or not OK
              that YANG

              library allows different schemas in different datastores.

            

            
\

            
\

            


            

            
Actually, this is the only issue that matters.

            


            

            
I decided that no special text is needed because the
              YANG library is violating a MUST requirement

            
in RFC 7950 and needs to be changed.

          

        

      

    

    Are you referring to this text, or something else:

    

    5.6.5.  Implementing a Module

    

       A server implements a module if it implements the
      module's data

       nodes, RPCs, actions, notifications, and deviations.

    

       A server MUST NOT implement more than one revision of a
      module.

    

    If, so, then we still agree with this constraint, and this hasn't
    changed for NMDA.  I think that YANG library should make this clear
    in the list of modules.

    

    But I don't think that text specifically prevents different
    deviations or features for different datastores ...

    

    

      

        

          

            


            

            
There can only be one implementation of a module per
              server, not per datastore.

            
Therefore a module MAY appear in multiple module-sets,
              but it MUST NOT

            
be different.  The exact same revision, features, and
              deviations MUST be present

            
in each instance.

          

        

      

    

    

    The NMDA draft already states that the schema for all conventional
    configuration datastores must be the same (meaning that all
    deviations and features must be the same as well):

    

    
5.1.  Conventional Configuration Datastores

   The conventional configuration datastores are a set of configuration
   datastores that share exactly the same schema, allowing data to be
   copied between them.

    

    So, I think that the main question is about how the schema for
    <operational> can differ from the configuration datatstores.

    

    We want to allow different features to be supported in running vs
    operational, so that feature statements can be useful to turn off
    features that may be supported by a device, but might not be
    externally configurable (e.g router-id).  But we could partially
    constrain their use.  So I propose that we add the following extra
    sentence to the NMDA draft on section 5.3  The Operational State
    Datastore (<operational>).

    

    My proposed NEW text is:

    

    If a YANG feature is supported for a module in any
      configuration datastore then it SHOULD also be supported in
      <operational>.  This is to allow the applied configuration
      and any other operational state associated with that feature to be
      available.  The inverse constraint does not hold, a server MAY
      support a feature in <operational> without also supporting
      it in any configuration datatstore.

    

    

    I'm not sure that it makes sense to constrain deviations to be the
    same for all datastores, since these are the mechanism for reporting
    why a server doesn't conform to the standard ...

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            
Andy

            


            

            


            

            

              

              On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman
              wrote:

              > On Tue, Oct 24, 2017 at 10:21 AM, Juergen
              Schoenwaelder <

              > j.schoenwaelder@jacobs-university.de>
              wrote:

              >

              > > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy
              Bierman wrote:

              > > >

              > > > IMO the more complex NMDA is to implement,
              the less likely it will

              > > > be implemented.  If you want the tools to
              figure out the correct

              > > > datastore(s) from description-stmts instead
              of something

              > > > deterministic and machine-usable, NMDA is
              less likely to be

              > > > implemented.

              > >

              > > There is nothing machine readable today that
              tells you which argument

              > > of get-config identifies the datastore that is
              being accessed by

              > > get-config. Our reasoning is that for most
              actions that default is

              > > going to do the right thing. If there is a need
              to have further

              > > language support to handle the cases where
              operations may relate to

              > > datastores different than operational, then this
              should be taken up by

              > > a future version of YANG.

              > >

              > >

              > There is only 1 schema tree now in pre-NMDA so it is
              easy to parse

              > instance data against the one and only set of
              modules.

              >

              >

              >

              > > > Given that the same objects can be defined
              differently in each

              > > > datastore in NMDA, it is especially useful
              to know which set of YANG

              > > > modules applies, before parsing instance
              data against those modules.

              > >

              > > I am not sure I parse this correctly.

              > >

              >

              > The new YANG library requires the implementation to
              know the datastore

              > to pick the correct set of modules for the datastore
              used in the operation.

              > Module sets are allowed to overlap, so the same
              module can be different

              > in <running> vs. <operational>.

              >

              > Developers unaware of the new NMDA complexities
              should read the drafts

              > again.

              >

              >

              >

              > >

              > > > (2) Define <action2>:

              > > > >

              > > > > I'm not convinced that this is really
              required/helpful, given that most

              > > > > actions are likely to only apply to
              operational.  If it turns out that

              > > this

              > > > > is particularly useful then I would
              propose that this is deferred

              > > until a

              > > > > future revision of NETCONF,
              particularly because we are trying to keep

              > > the

              > > > > NETCONF NMDA and RESTCONF NMDA drafts
              as small as possible.

              > > > >

              > > > > Is this OK?

              > > > >

              > > >

              > > > The NMDA theme has been to declare things
              that are possible in pre-NMDA

              > > > but not supported in post-NMDA to be not
              useful, so this can be left to

              > > > vendors I guess.

              > >

              > > Not sure I understand this either.

              > >

              > > If you have a concrete change proposal, perhaps
              the discussion becomes

              > > more concrete and productive.

              > >

              >

              >

              > I already said to declare that <action> is
              invoked in <operational>. Period.

              > No description-stmt exceptions.

              >

              > If another datastore is needed, use rpc-stmt instead
              of action-stmt.

              

              So you are fine if for RPCs description statements can
              define which

              datastores are affected by an RPC? I probably did not get
              that you

              make a distinction between actions and RPCs here.

              

                  /js

                  

                  --

                  Juergen Schoenwaelder           Jacobs University
                  Bremen gGmbH

                  Phone: +49 421 200 3587         Campus Ring 1 | 28759
                  Bremen | Germany

                  Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

                

          

          

        

      

    

    

  


--------------3F01318C4E05690CBDF4CC7F--


From nobody Wed Oct 25 10:14:17 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BA913943F for ; Wed, 25 Oct 2017 10:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH7z1RGqPcsb for ; Wed, 25 Oct 2017 10:14:14 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFFF138726 for ; Wed, 25 Oct 2017 10:14:14 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 4682E1AE0332; Wed, 25 Oct 2017 19:14:13 +0200 (CEST)
Date: Wed, 25 Oct 2017 19:14:13 +0200 (CEST)
Message-Id: <20171025.191413.1884714432684351955.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20171025110851.wdoj2dbrqmxz5shd@elstar.local>  
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 17:14:16 -0000

Hi,

Robert Wilton  wrote:
> Hi Andy,
> =

> =

> On 25/10/2017 16:54, Andy Bierman wrote:
> >
> >
> > On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder
> >  > > wrote:
> >
> >     It seems we are jumping between topics. I will skip over commen=
ts
> >     concerning the YANG library and whether it is OK or not OK that=
 YANG
> >     library allows different schemas in different datastores.
> >
> > \
> > \
> >
> > Actually, this is the only issue that matters.
> >
> > I decided that no special text is needed because the YANG library i=
s
> > violating a MUST requirement
> > in RFC 7950 and needs to be changed.
> Are you referring to this text, or something else:
> =

> 5.6.5.=A0 Implementing a Module
> =

> =A0=A0 A server implements a module if it implements the module's dat=
a
> =A0=A0 nodes, RPCs, actions, notifications, and deviations.
> =

> =A0=A0 A server MUST NOT implement more than one revision of a module=
.=

> =

> If, so, then we still agree with this constraint, and this hasn't
> changed for NMDA.=A0 I think that YANG library should make this clear=
 in
> the list of modules.
> =

> But I don't think that text specifically prevents different deviation=
s
> or features for different datastores ...
> =

> >
> > There can only be one implementation of a module per server, not pe=
r
> > datastore.
> > Therefore a module MAY appear in multiple module-sets, but it MUST =
NOT
> > be different.=A0 The exact same revision, features, and deviations =
MUST
> > be present
> > in each instance.
> =

> The NMDA draft already states that the schema for all conventional
> configuration datastores must be the same (meaning that all deviation=
s
> and features must be the same as well):
> =

> 5.1. Conventional Configuration Datastores
> =

>    The conventional configuration datastores are a set of configurati=
on
>    datastores that share exactly the same schema, allowing data to be=

>    copied between them.
> =

> =

> So, I think that the main question is about how the schema for
>  can differ from the configuration datatstores.
> =

> We want to allow different features to be supported in running vs
> operational, so that feature statements can be useful to turn off
> features that may be supported by a device, but might not be
> externally configurable (e.g router-id).=A0 But we could partially
> constrain their use.=A0 So I propose that we add the following extra
> sentence to the NMDA draft on section 5.3=A0 The Operational State
> Datastore ().
> =

> My proposed NEW text is:
> =

> If a YANG feature is supported for a module in any configuration
> datastore then it SHOULD also be supported in .=A0 This =
is

I think this should be a MUST; if something is supported in the
conventional datastores, then the same schema must be used for the
applied config.

> to allow the applied configuration and any other operational state
> associated with that feature to be available.=A0 The inverse constrai=
nt
> does not hold, a server MAY support a feature in  withou=
t
> also supporting it in any configuration datatstore.

I agree.

> I'm not sure that it makes sense to constrain deviations to be the
> same for all datastores, since these are the mechanism for reporting
> why a server doesn't conform to the standard ...

I agree.



/martin


From nobody Wed Oct 25 10:50:36 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B95139504 for ; Wed, 25 Oct 2017 10:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CC4R7j4SIRQv for ; Wed, 25 Oct 2017 10:50:31 -0700 (PDT)
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 CCFEB13F439 for ; Wed, 25 Oct 2017 10:50:30 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id a16so914376lfk.0 for ; Wed, 25 Oct 2017 10:50:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mzIC2fqOtE1Y9DWbesffsmfaWYre6tLqa7P5zh22uU8=; b=HUxHQ8+C30umfcU3hsjm8HEqjpe03UJLIiWWa/PTDQk/1/q7DId2i9TxPO5BwR9Po/ kGUxCUSg3I1K96Sdta0esvCVZBA/2WAnlsvwizpIMngq24xhEWakLePI1h7aKGLGFeYD gM1Vj8v2YfDEA8C/ul/9ZNeNc9xoZZDd6CC2yl/fwI8v+xeHnHV+8P0Zaf0wBMSD/exg KjIDGKq8mDNtk0UCEkcKYzHbXAr6z7tWQGoyjQzFEh7IuS12CawzSAu+3n7jAmYWv45r XU7Bz3GnZD5JDDZqKXm92xEUbbSXlrf9+QnyhrL6UhDJeq5KfaAXADsNyQPIDMknYxeq w5Rg==
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=mzIC2fqOtE1Y9DWbesffsmfaWYre6tLqa7P5zh22uU8=; b=f5GiY0uZVNLn4cWI2Z4/+DWvR0La+eEvMTRa2HupmJhO4AdrPe8xmvnXhQozmVXoDD vqHVMWG8+fBVu11WcxTwD2Luyb0SOAlFUUzRSFLwL1Mc3KyTf9f44GCoOSI0Y3AwMUX1 yGU4nrSCApJ0HhZHXEkLMsTuZ3LC3NS/Mcs7oi5Yj0dRTiUoSq/q7t6DXcsdWnVqpVWZ nCE012Yw535s3rbaVmH1J7M5+ZqIC+aYW6dvLmayHxTzUnA/wMQqmi8OdW3GgFdKsEoy PKpS4W52BuyIyjR2zcvhBW7P5xTvbmHsm00wtpLKlxOlql2c5B/5q7k6wXIPxUK1LXD3 SkDw==
X-Gm-Message-State: AMCzsaXBqs3BZgxqFmULAmSrdP9nORcVJosnGPWGmKWJCTp1x5hOEf3u d19zgOG5GEM3Z+deihqV4a6eSM7P8kjnoP1itu/Uog==
X-Google-Smtp-Source: ABhQp+SzBepvO5/GDUSIflWP2iqqyRMVvufWc0pIOEeF9uN6XwxKf7Pf+RsZoKR7/OzfQeKIIth+XJT+7x3YKnXMX7o=
X-Received: by 10.25.221.196 with SMTP id w65mr5977303lfi.89.1508953829083; Wed, 25 Oct 2017 10:50:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 25 Oct 2017 10:50:28 -0700 (PDT)
In-Reply-To: <20171025.191413.1884714432684351955.mbj@tail-f.com>
References: <20171025110851.wdoj2dbrqmxz5shd@elstar.local>   <20171025.191413.1884714432684351955.mbj@tail-f.com>
From: Andy Bierman 
Date: Wed, 25 Oct 2017 10:50:28 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Robert Wilton ,  Juergen Schoenwaelder , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0c884af723a1055c62b0b7"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 17:50:35 -0000

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

On Wed, Oct 25, 2017 at 10:14 AM, Martin Bjorklund  wrote:

> Hi,
>
> Robert Wilton  wrote:
> > Hi Andy,
> >
> >
> > On 25/10/2017 16:54, Andy Bierman wrote:
> > >
> > >
> > > On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder
> > >  > > > wrote:
> > >
> > >     It seems we are jumping between topics. I will skip over comments
> > >     concerning the YANG library and whether it is OK or not OK that
> YANG
> > >     library allows different schemas in different datastores.
> > >
> > > \
> > > \
> > >
> > > Actually, this is the only issue that matters.
> > >
> > > I decided that no special text is needed because the YANG library is
> > > violating a MUST requirement
> > > in RFC 7950 and needs to be changed.
> > Are you referring to this text, or something else:
> >
> > 5.6.5.  Implementing a Module
> >
> >    A server implements a module if it implements the module's data
> >    nodes, RPCs, actions, notifications, and deviations.
> >
> >    A server MUST NOT implement more than one revision of a module.
> >
> > If, so, then we still agree with this constraint, and this hasn't
> > changed for NMDA.  I think that YANG library should make this clear in
> > the list of modules.
> >
> > But I don't think that text specifically prevents different deviations
> > or features for different datastores ...
> >
> > >
> > > There can only be one implementation of a module per server, not per
> > > datastore.
> > > Therefore a module MAY appear in multiple module-sets, but it MUST NOT
> > > be different.  The exact same revision, features, and deviations MUST
> > > be present
> > > in each instance.
> >
> > The NMDA draft already states that the schema for all conventional
> > configuration datastores must be the same (meaning that all deviations
> > and features must be the same as well):
> >
> > 5.1. Conventional Configuration Datastores
> >
> >    The conventional configuration datastores are a set of configuration
> >    datastores that share exactly the same schema, allowing data to be
> >    copied between them.
> >
> >
> > So, I think that the main question is about how the schema for
> >  can differ from the configuration datatstores.
> >
> > We want to allow different features to be supported in running vs
> > operational, so that feature statements can be useful to turn off
> > features that may be supported by a device, but might not be
> > externally configurable (e.g router-id).  But we could partially
> > constrain their use.  So I propose that we add the following extra
> > sentence to the NMDA draft on section 5.3  The Operational State
> > Datastore ().
> >
> > My proposed NEW text is:
> >
> > If a YANG feature is supported for a module in any configuration
> > datastore then it SHOULD also be supported in .  This is
>
> I think this should be a MUST; if something is supported in the
> conventional datastores, then the same schema must be used for the
> applied config.
>
> > to allow the applied configuration and any other operational state
> > associated with that feature to be available.  The inverse constraint
> > does not hold, a server MAY support a feature in  without
> > also supporting it in any configuration datatstore.
>
> I agree.
>

I disagree


>
> > I'm not sure that it makes sense to constrain deviations to be the
> > same for all datastores, since these are the mechanism for reporting
> > why a server doesn't conform to the standard ...
>
> I agree.
>
>
I disagree


Features and deviations are are part of the one implementation.
Features are not mentioned in the cited text because they are inherently
optional and do not have to be implemented.

There is no text in RFC 7950 that supports the notion that an
if-feature-stmt
or a deviation-stmt can apply to a specific datastore.  It applies to the
object.

Good luck getting client developers to support conflicting schema trees
for the same module. Good luck comparing  to .




>
> /martin
>


Andy

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




On Wed, Oct 25, 2017 at 10:14 AM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Hi,



Robert Wilton <rwilton@cisco.com> wrote:

> Hi Andy,

>

>

> On 25/10/2017 16:54, Andy Bierman wrote:

> >

> >

> > On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder

> > <j.sch=
oenwaelder@jacobs-university.de

> > <mailto:j.schoenwaelder@jacobs-university.de>> wrote:

> >

> >=C2=A0 =C2=A0 =C2=A0It seems we are jumping between topics. I will=
 skip over comments

> >=C2=A0 =C2=A0 =C2=A0concerning the YANG library and whether it is =
OK or not OK that YANG

> >=C2=A0 =C2=A0 =C2=A0library allows different schemas in different =
datastores.

> >

> > \

> > \

> >

> > Actually, this is the only issue that matters.

> >

> > I decided that no special text is needed because the YANG library=
 is

> > violating a MUST requirement

> > in RFC 7950 and needs to be changed.

> Are you referring to this text, or something else:

>

> 5.6.5.=C2=A0 Implementing a Module

>

> =C2=A0=C2=A0 A server implements a module if it implements the module&=
#39;s data

> =C2=A0=C2=A0 nodes, RPCs, actions, notifications, and deviations.

>

> =C2=A0=C2=A0 A server MUST NOT implement more than one revision of a m=
odule.

>

> If, so, then we still agree with this constraint, and this hasn't<=
br>
> changed for NMDA.=C2=A0 I think that YANG library should make this cle=
ar in

> the list of modules.

>

> But I don't think that text specifically prevents different deviat=
ions

> or features for different datastores ...

>

> >

> > There can only be one implementation of a module per server, not =
per

> > datastore.

> > Therefore a module MAY appear in multiple module-sets, but it MUS=
T NOT

> > be different.=C2=A0 The exact same revision, features, and deviat=
ions MUST

> > be present

> > in each instance.

>

> The NMDA draft already states that the schema for all conventional

> configuration datastores must be the same (meaning that all deviations=


> and features must be the same as well):

>

> 5.1. Conventional Configuration Datastores

>

>=C2=A0 =C2=A0 The conventional configuration datastores are a set of co=
nfiguration

>=C2=A0 =C2=A0 datastores that share exactly the same schema, allowing d=
ata to be

>=C2=A0 =C2=A0 copied between them.

>

>

> So, I think that the main question is about how the schema for

> <operational> can differ from the configuration datatstores.

>

> We want to allow different features to be supported in running vs

> operational, so that feature statements can be useful to turn off

> features that may be supported by a device, but might not be

> externally configurable (e.g router-id).=C2=A0 But we could partially<=
br>
> constrain their use.=C2=A0 So I propose that we add the following extr=
a

> sentence to the NMDA draft on section 5.3=C2=A0 The Operational State<=
br>
> Datastore (<operational>).

>

> My proposed NEW text is:

>

> If a YANG feature is supported for a module in any configuration

> datastore then it SHOULD also be supported in <operational>.=C2=
=A0 This is



I think this should be a MUST; if something is supported in the

conventional datastores, then the same schema must be used for the

applied config.



> to allow the applied configuration and any other operational state

> associated with that feature to be available.=C2=A0 The inverse constr=
aint

> does not hold, a server MAY support a feature in <operational> w=
ithout

> also supporting it in any configuration datatstore.



I agree.

I disagree
=C2=A0



> I'm not sure that it makes sense to constrain deviations to be the=


> same for all datastores, since these are the mechanism for reporting
> why a server doesn't conform to the standard ...



I agree.



I disagree


F=
eatures and deviations are are part of the one implementation.
Fe=
atures are not mentioned in the cited text because they are inherently
optional and do not have to be implemented.

=
There is no text in RFC 7950 that supports the notion that an if-feature-st=
mt
or a deviation-stmt can apply to a specific datastore.=C2=A0 I=
t applies to the object.

Good luck getting client =
developers to support conflicting schema trees
for the same modul=
e. Good luck comparing <running> to <operational>.







/martin




<=
/div>
Andy



--94eb2c0c884af723a1055c62b0b7--


From nobody Wed Oct 25 11:10:12 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795AC13946F for ; Wed, 25 Oct 2017 11:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KH1eoajUM_Z for ; Wed, 25 Oct 2017 11:10:02 -0700 (PDT)
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 2875613F450 for ; Wed, 25 Oct 2017 11:09:38 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id 90so932541lfs.13 for ; Wed, 25 Oct 2017 11:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qL/JbFd12cg2dPowhwEOK4aBjIzR9+SiEuu/68p2pLo=; b=2CKASkF2WWJXxUhJBZJ6+PV7PxAs+A9SRL2zSvHdMzAwFdh4J19dp3CFrHpxGJE9dw j89aAPDUfn6QuwpVgJhn3u65rYMiiiSQlZkGyRWRjRcdXgVULCh2Xi7hmFPFIOywdvRA d70LK6WEsgMR0fL8g0Bt3XxpjBoKhGp0kEqWxi24jCOLhtNI03JBFTjg/3psGmF6wYrn FgXy0Me9SgdcYEmC8KRRBPvk8jv0TJkFYotZqQtShl6AqA8FyG6obwi2ik9LHO6RS/bT Fv3Ed27W45Rtu5z8Izym5FBqPwElxcyI6R54cegYuQb/Hfcl78UDSscKbl+Y/1fhvYcC cFGA==
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=qL/JbFd12cg2dPowhwEOK4aBjIzR9+SiEuu/68p2pLo=; b=fr4dRc7I83cbghv9Noo2GQQrxu9QsobY4JhmyUr6t1lu++Yf/2PuMuW2FnmgOtTODt fKODyAvQTjAfU+kndxxo1mOqWNRawqy6df8pJYSKb+gds3pnUVH1rQR81a+xMzJsFYKg 07BGZyI5XPhwIUr+wa9eXdbL8ArU7418GP39eGrgWACoQvkXgeK3BMaQz92GqcyTvBMK oxpy35ZHZiKbE1kO42ubcCjJhMCI/H0d6fWOz3R7mlP2ewGFaGabY0h/jxVTA4URdkY3 8LB6FN8EXBDmk1UzYAXE9ZeA1Sj9+FIPAlNNuSmTj9jYJDL9mTp6KdW9Lv5hixVxeGxa RU6w==
X-Gm-Message-State: AMCzsaVbvKjyOXGLlg8NMY2topLuVfUZxF/6xkG0EGcOl6n74vhogZfZ Wk5gQoZoGfNtyB0dCJ306XDRBzpNKDwP+MmVJiRaNQ==
X-Google-Smtp-Source: ABhQp+Qq6FSCDZemou1x0F4ksndQrE1TSZxAwDWlt6UnfNS+knas/cnEU3yt2hJDZ57/KUjM1OhFoy4W7VwEcmlNFDY=
X-Received: by 10.25.156.66 with SMTP id f63mr7021632lfe.194.1508954976231; Wed, 25 Oct 2017 11:09:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 25 Oct 2017 11:09:34 -0700 (PDT)
In-Reply-To: 
References: <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local>  <20171025110851.wdoj2dbrqmxz5shd@elstar.local>  
From: Andy Bierman 
Date: Wed, 25 Oct 2017 11:09:34 -0700
Message-ID: 
To: Robert Wilton 
Cc: Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11411bc6573eca055c62f539"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 18:10:09 -0000

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

On Wed, Oct 25, 2017 at 10:05 AM, Robert Wilton  wrote:

> Hi Andy,
>
> On 25/10/2017 16:54, Andy Bierman wrote:
>
>
>
> On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> It seems we are jumping between topics. I will skip over comments
>> concerning the YANG library and whether it is OK or not OK that YANG
>> library allows different schemas in different datastores.
>>
> \
> \
>
> Actually, this is the only issue that matters.
>
> I decided that no special text is needed because the YANG library is
> violating a MUST requirement
> in RFC 7950 and needs to be changed.
>
> Are you referring to this text, or something else:
>
> 5.6.5.  Implementing a Module
>
>    A server implements a module if it implements the module's data
>    nodes, RPCs, actions, notifications, and deviations.
>
>    A server MUST NOT implement more than one revision of a module.
>
> If, so, then we still agree with this constraint, and this hasn't changed
> for NMDA.  I think that YANG library should make this clear in the list of
> modules.
>
> But I don't think that text specifically prevents different deviations or
> features for different datastores ...
>



I think NMDA is creating much more complexity and disruption than is
required.
The original issue was the OpenConfig-style config/state trees.
The WG agreed that an RPC-based solution was needed so that the
YANG modules would not need to change (far too disruptive!).

Then the IETF proceeds to redo all the YANG modules anyway.
Now the server is allowed to implement the same module differently in each
datastore.
Now comparing the configured and operational value is even harder than
before.

None of this added complexity was in the OpenConfig proposal.
It was not even possible to have different features and deviations for the
same object in that proposal.


Andy




>
> There can only be one implementation of a module per server, not per
> datastore.
> Therefore a module MAY appear in multiple module-sets, but it MUST NOT
> be different.  The exact same revision, features, and deviations MUST be
> present
> in each instance.
>
>
> The NMDA draft already states that the schema for all conventional
> configuration datastores must be the same (meaning that all deviations and
> features must be the same as well):
>
> 5.1.  Conventional Configuration Datastores
>
>    The conventional configuration datastores are a set of configuration
>    datastores that share exactly the same schema, allowing data to be
>    copied between them.
>
>
> So, I think that the main question is about how the schema for
>  can differ from the configuration datatstores.
>
> We want to allow different features to be supported in running vs
> operational, so that feature statements can be useful to turn off features
> that may be supported by a device, but might not be externally configurable
> (e.g router-id).  But we could partially constrain their use.  So I propose
> that we add the following extra sentence to the NMDA draft on section 5.3
> The Operational State Datastore ().
>
> My proposed NEW text is:
>
> If a YANG feature is supported for a module in any configuration datastore
> then it SHOULD also be supported in .  This is to allow the
> applied configuration and any other operational state associated with that
> feature to be available.  The inverse constraint does not hold, a server
> MAY support a feature in  without also supporting it in any
> configuration datatstore.
>
>
> I'm not sure that it makes sense to constrain deviations to be the same
> for all datastores, since these are the mechanism for reporting why a
> server doesn't conform to the standard ...
>
> Thanks,
> Rob
>
>
>
> Andy
>
>
>
>> On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote:
>> > On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <
>> > j.schoenwaelder@jacobs-university.de> wrote:
>> >
>> > > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
>> > > >
>> > > > IMO the more complex NMDA is to implement, the less likely it will
>> > > > be implemented.  If you want the tools to figure out the correct
>> > > > datastore(s) from description-stmts instead of something
>> > > > deterministic and machine-usable, NMDA is less likely to be
>> > > > implemented.
>> > >
>> > > There is nothing machine readable today that tells you which argument
>> > > of get-config identifies the datastore that is being accessed by
>> > > get-config. Our reasoning is that for most actions that default is
>> > > going to do the right thing. If there is a need to have further
>> > > language support to handle the cases where operations may relate to
>> > > datastores different than operational, then this should be taken up by
>> > > a future version of YANG.
>> > >
>> > >
>> > There is only 1 schema tree now in pre-NMDA so it is easy to parse
>> > instance data against the one and only set of modules.
>> >
>> >
>> >
>> > > > Given that the same objects can be defined differently in each
>> > > > datastore in NMDA, it is especially useful to know which set of YANG
>> > > > modules applies, before parsing instance data against those modules.
>> > >
>> > > I am not sure I parse this correctly.
>> > >
>> >
>> > The new YANG library requires the implementation to know the datastore
>> > to pick the correct set of modules for the datastore used in the
>> operation.
>> > Module sets are allowed to overlap, so the same module can be different
>> > in  vs. .
>> >
>> > Developers unaware of the new NMDA complexities should read the drafts
>> > again.
>> >
>> >
>> >
>> > >
>> > > > (2) Define :
>> > > > >
>> > > > > I'm not convinced that this is really required/helpful, given
>> that most
>> > > > > actions are likely to only apply to operational.  If it turns out
>> that
>> > > this
>> > > > > is particularly useful then I would propose that this is deferred
>> > > until a
>> > > > > future revision of NETCONF, particularly because we are trying to
>> keep
>> > > the
>> > > > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
>> > > > >
>> > > > > Is this OK?
>> > > > >
>> > > >
>> > > > The NMDA theme has been to declare things that are possible in
>> pre-NMDA
>> > > > but not supported in post-NMDA to be not useful, so this can be
>> left to
>> > > > vendors I guess.
>> > >
>> > > Not sure I understand this either.
>> > >
>> > > If you have a concrete change proposal, perhaps the discussion becomes
>> > > more concrete and productive.
>> > >
>> >
>> >
>> > I already said to declare that  is invoked in .
>> Period.
>> > No description-stmt exceptions.
>> >
>> > If another datastore is needed, use rpc-stmt instead of action-stmt.
>>
>> So you are fine if for RPCs description statements can define which
>> datastores are affected by an RPC? I probably did not get that you
>> make a distinction between actions and RPCs here.
>>
>> /js
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
>
>
>

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




On Wed, Oct 25, 2017 at 10:05 AM, Robert Wilton <<=
a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com=
> wrote:

 =20
   =20
 =20
  

    
Hi Andy,

    

    

    
On 25/10/2017 16:54=
, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Wed, Oct 25, 2017 at 4:08 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jaco=
bs-university.de>
            wrote:

            
It seems
              we are jumping between topics. I will skip over comments

              concerning the YANG library and whether it is OK or not OK
              that YANG

              library allows different schemas in different datastores.

            

            
\

            
\

            


            

            
Actually, this is the only issue that matters.

            


            

            
I decided that no special text is needed because the
              YANG library is violating a MUST requirement

            
in RFC 7950 and needs to be changed.

          

        

      

    

    Are you referring to this text, or something else:

    

    5.6.5.=C2=A0 Implementing a Module

    

    =C2=A0=C2=A0 A server implements a module if it implements the
      module's data

    =C2=A0=C2=A0 nodes, RPCs, actions, notifications, and deviatio=
ns.

    

    =C2=A0=C2=A0 A server MUST NOT implement more than one revisio=
n of a
      module.

    

    If, so, then we still agree with this constraint, and this hasn't
    changed for NMDA.=C2=A0 I think that YANG library should make this clea=
r
    in the list of modules.

    

    But I don't think that text specifically prevents different
    deviations or features for different datastores ...



I think NMDA is creati=
ng much more complexity and disruption than is required.
The orig=
inal issue was the OpenConfig-style config/state trees.
The WG ag=
reed that an RPC-based solution was needed so that the
YANG modul=
es would not need to change (far too disruptive!).

Then the IETF proceeds to redo all the YANG modules anyway.
Now =
the server is allowed to implement the same module differently in each data=
store.
Now comparing the configured and operational value is even=
 harder than before.

None of this added complexity=
 was in the OpenConfig proposal.
It was not even possible to have=
 different features and deviations for the
same object in that pr=
oposal.


Andy




    

    

      

        

          

            


            

            
There can only be one implementation of a module per
              server, not per datastore.

            
Therefore a module MAY appear in multiple module-sets,
              but it MUST NOT

            
be different.=C2=A0 The exact same revision, features, and
              deviations MUST be present

            
in each instance.

          

        

      

    

    

    The NMDA draft already states that the schema for all conventional
    configuration datastores must be the same (meaning that all
    deviations and features must be the same as well):

    

    
5.1.  Conventional Configur=
ation Datastores

   The conventional configuration datastores are a set of configuration
   datastores that share exactly the same schema, allowing data to be
   copied between them.

    

    So, I think that the main question is about how the schema for
    <operational> can differ from the configuration datatstores.

    

    We want to allow different features to be supported in running vs
    operational, so that feature statements can be useful to turn off
    features that may be supported by a device, but might not be
    externally configurable (e.g router-id).=C2=A0 But we could partially
    constrain their use.=C2=A0 So I propose that we add the following extra
    sentence to the NMDA draft on section 5.3=C2=A0 The Operational State
    Datastore (<operational>).

    

    My proposed NEW text is:

    

    If a YANG feature is supported for a module in any
      configuration datastore then it SHOULD also be supported in
      <operational>.=C2=A0 This is to allow the applied configuration
      and any other operational state associated with that feature to be
      available.=C2=A0 The inverse constraint does not hold, a server MAY
      support a feature in <operational> without also supporting
      it in any configuration datatstore.

    

    

    I'm not sure that it makes sense to constrain deviations to be the
    same for all datastores, since these are the mechanism for reporting
    why a server doesn't conform to the standard ...

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            
Andy

            


            

            


            

            

              

              On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman
              wrote:

              > On Tue, Oct 24, 2017 at 10:21 AM, Juergen
              Schoenwaelder <

              > j.schoenwaelder@jacobs-university.de>
              wrote:

              >

              > > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy
              Bierman wrote:

              > > >

              > > > IMO the more complex NMDA is to implement,
              the less likely it will

              > > > be implemented.=C2=A0 If you want the tools to
              figure out the correct

              > > > datastore(s) from description-stmts instead
              of something

              > > > deterministic and machine-usable, NMDA is
              less likely to be

              > > > implemented.

              > >

              > > There is nothing machine readable today that
              tells you which argument

              > > of get-config identifies the datastore that is
              being accessed by

              > > get-config. Our reasoning is that for most
              actions that default is

              > > going to do the right thing. If there is a need
              to have further

              > > language support to handle the cases where
              operations may relate to

              > > datastores different than operational, then this
              should be taken up by

              > > a future version of YANG.

              > >

              > >

              > There is only 1 schema tree now in pre-NMDA so it is
              easy to parse

              > instance data against the one and only set of
              modules.

              >

              >

              >

              > > > Given that the same objects can be defined
              differently in each

              > > > datastore in NMDA, it is especially useful
              to know which set of YANG

              > > > modules applies, before parsing instance
              data against those modules.

              > >

              > > I am not sure I parse this correctly.

              > >

              >

              > The new YANG library requires the implementation to
              know the datastore

              > to pick the correct set of modules for the datastore
              used in the operation.

              > Module sets are allowed to overlap, so the same
              module can be different

              > in <running> vs. <operational>.

              >

              > Developers unaware of the new NMDA complexities
              should read the drafts

              > again.

              >

              >

              >

              > >

              > > > (2) Define <action2>:

              > > > >

              > > > > I'm not convinced that this is really
              required/helpful, given that most

              > > > > actions are likely to only apply to
              operational.=C2=A0 If it turns out that

              > > this

              > > > > is particularly useful then I would
              propose that this is deferred

              > > until a

              > > > > future revision of NETCONF,
              particularly because we are trying to keep

              > > the

              > > > > NETCONF NMDA and RESTCONF NMDA drafts
              as small as possible.

              > > > >

              > > > > Is this OK?

              > > > >

              > > >

              > > > The NMDA theme has been to declare things
              that are possible in pre-NMDA

              > > > but not supported in post-NMDA to be not
              useful, so this can be left to

              > > > vendors I guess.

              > >

              > > Not sure I understand this either.

              > >

              > > If you have a concrete change proposal, perhaps
              the discussion becomes

              > > more concrete and productive.

              > >

              >

              >

              > I already said to declare that <action> is
              invoked in <operational>. Period.

              > No description-stmt exceptions.

              >

              > If another datastore is needed, use rpc-stmt instead
              of action-stmt.

              

              So you are fine if for RPCs description statements can
              define which

              datastores are affected by an RPC? I probably did not get
              that you

              make a distinction between actions and RPCs here.

              

                  /js

                  

                  --

                  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=A0=
Campus Ring 1 | 28759
                  Bremen | Germany

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

                

          

          

        

      

    

    

  






--001a11411bc6573eca055c62f539--


From nobody Wed Oct 25 12:49:33 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7C3139095 for ; Wed, 25 Oct 2017 12:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB25j7az7m56 for ; Wed, 25 Oct 2017 12:49:31 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2581E138AEE for ; Wed, 25 Oct 2017 12:49:31 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B09F1AE0332; Wed, 25 Oct 2017 21:49:29 +0200 (CEST)
Date: Wed, 25 Oct 2017 21:49:29 +0200 (CEST)
Message-Id: <20171025.214929.480782767501855061.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: rwilton@cisco.com, j.schoenwaelder@jacobs-university.de, 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] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 19:49:32 -0000

Andy Bierman  wrote:
> I think NMDA is creating much more complexity and disruption than is
> required.
> The original issue was the OpenConfig-style config/state trees.
> The WG agreed that an RPC-based solution was needed so that the
> YANG modules would not need to change (far too disruptive!).
> 
> Then the IETF proceeds to redo all the YANG modules anyway.
> Now the server is allowed to implement the same module differently in each
> datastore.
> Now comparing the configured and operational value is even harder than
> before.
> 
> None of this added complexity was in the OpenConfig proposal.
> It was not even possible to have different features and deviations for the
> same object in that proposal.

Actually, this is not correct.  In both OC and the old IETF split tree
solutions, the configuration and operational state were modelled with
duplicate nodes, and you could certainly deviate these nodes
differently.

This said, I share your concern about complexity.  I also agree that
the only model that makes the client simple is that if all objects in
the config are also available with the same types in operational
state.  Otherwise comparison won't work (or be complicated).

But at the same time, the converse is not true.  I.e., if an object is
present in operational, it doesn't have to be configurable.

So what I think we want is that the schema for the conventional
datastore is a subset of the schema for operational.

This would allow an implementation that cannot support configuration
of let's say the MTU, to deviate the mtu with "not-supported" in the
conventional datastore, but it will still be available for inspection
in operational.

Does this make sense?


/martin


From nobody Wed Oct 25 14:22:04 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C92013F472 for ; Wed, 25 Oct 2017 14:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjPaeKetut4V for ; Wed, 25 Oct 2017 14:22:00 -0700 (PDT)
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 1633713F471 for ; Wed, 25 Oct 2017 14:22:00 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id 90so1472275lfs.13 for ; Wed, 25 Oct 2017 14:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oWjTFT/CW0QuOSusAO024VbCDbqGlpyhAdvYhGG/Nac=; b=Aidieneb8GRe6TnNAlTbZ1Mj+fA+7amkwS1S7y0H+uZl3sajvly8EoDyPAH+i/P/rM Q/AiK8+RmVXy1z6tqiS0Jyh/5DzzTSWfWMQ0WdelN/2SBc1LsH7yQuZuQaLCVbO53UAd TRfSE07Ht0lPc8cl2hYk2Z5Ol8gQCJwqV08tmHFkx6nOB5hn0XWgSKh7Bsh7wP7qdmQs de4MyImsO2mjia9EiNdTrSAE3ieViLbRZ85ha93jjyYzYuvQdJX5Rgfjkfil2kCqxAKK 2+qXOlsSw3AiVnG/NUUs12KkMElskVPqOs9379btJlu4jfabqtcs0ajXDiJDes2gcclm oNng==
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=oWjTFT/CW0QuOSusAO024VbCDbqGlpyhAdvYhGG/Nac=; b=qGwk9SSD/S3H0PGd7AkTJdLGSWyKfDUsty4aygHyjZfB7dKgs+bigPgaOV1arLzj6o 22skim4ghkFT50glDgdg9HiHSJDFLA+hAeiWcOgNTCqKUE1ApcXhFRhdCoMTVGvizbi0 GyuvREBnhnz1Et2qjpQUaIbucYzAZiFv4lmcqP2YV7VMhC90pJ3wDuK0+pGYPb3dd6ed JOocO7NvEYQd6+doavChITrutgdYNu+dkjPc4SbG10AVevWuGeBwLXfhQ5YsrEhjdegF GdYE2wx2arER7kTdBP5cQMDh18aIhJFbljXyLDcmSRaJ57k/xTHxJMbpkJ75RfPDYDGO QPAg==
X-Gm-Message-State: AMCzsaVPskg5v5WTNYRNGJE6DmnDxLHEeR6OxHEkFbOTQck731t7Nq4k ohDiBK/4RX1skd5r6UzYAIPkoUdT94rKDnIU9tIO8A==
X-Google-Smtp-Source: ABhQp+Tgynl47Sh7hDaM0yoHne1HR8bw9LfZJrmabo15cHrq8IrfjPVko+7zmbtfwdlRlLFiRYBhc3MsDBX3NHXErJk=
X-Received: by 10.25.211.73 with SMTP id k70mr7395430lfg.51.1508966518220; Wed, 25 Oct 2017 14:21:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 25 Oct 2017 14:21:57 -0700 (PDT)
In-Reply-To: <20171025.214929.480782767501855061.mbj@tail-f.com>
References:    <20171025.214929.480782767501855061.mbj@tail-f.com>
From: Andy Bierman 
Date: Wed, 25 Oct 2017 14:21:57 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Robert Wilton ,  Juergen Schoenwaelder , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114188aa4c01a7055c65a5e3"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 25 Oct 2017 21:22:02 -0000

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

On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > I think NMDA is creating much more complexity and disruption than is
> > required.
> > The original issue was the OpenConfig-style config/state trees.
> > The WG agreed that an RPC-based solution was needed so that the
> > YANG modules would not need to change (far too disruptive!).
> >
> > Then the IETF proceeds to redo all the YANG modules anyway.
> > Now the server is allowed to implement the same module differently in
> each
> > datastore.
> > Now comparing the configured and operational value is even harder than
> > before.
> >
> > None of this added complexity was in the OpenConfig proposal.
> > It was not even possible to have different features and deviations for
> the
> > same object in that proposal.
>
> Actually, this is not correct.  In both OC and the old IETF split tree
> solutions, the configuration and operational state were modelled with
> duplicate nodes, and you could certainly deviate these nodes
> differently.
>
>
No, you cannot deviate the same schema node in different ways.
You can define or deviate 2 different schema nodes.
That is the unacceptable change to YANG and why I like the OC solution
better.



> This said, I share your concern about complexity.  I also agree that
> the only model that makes the client simple is that if all objects in
> the config are also available with the same types in operational
> state.  Otherwise comparison won't work (or be complicated).
>
>

Agreed.
A vendor can provide unusable APIs with any YANG module,
given the right deviations, so this cannot be a factor.
But the OC solution did not allow features to be different at all.


But at the same time, the converse is not true.  I.e., if an object is
> present in operational, it doesn't have to be configurable.
>
>
Correct but maybe irrelevant.

I am only concerned with the same schema node being different in multiple
datastores.  This was never part of the OC requirement.

Each datastore can implement a specific subset of all the server modules.
That part is well-defined and the framework allows for lots of innovation
here
without modifying YANG at all.




> So what I think we want is that the schema for the conventional
> datastore is a subset of the schema for operational.
>
> This would allow an implementation that cannot support configuration
> of let's say the MTU, to deviate the mtu with "not-supported" in the
> conventional datastore, but it will still be available for inspection
> in operational.
>
> Does this make sense?
>


Non-overlapping subsets are fine.
Overlapping subset but the details are the same for each module are fine.



>
> /martin
>

Andy

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




On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> I think NMDA is creating much more complexity and disruption than is
> required.

> The original issue was the OpenConfig-style config/state trees.

> The WG agreed that an RPC-based solution was needed so that the

> YANG modules would not need to change (far too disruptive!).

>

> Then the IETF proceeds to redo all the YANG modules anyway.

> Now the server is allowed to implement the same module differently in =
each

> datastore.

> Now comparing the configured and operational value is even harder than=


> before.

>

> None of this added complexity was in the OpenConfig proposal.

> It was not even possible to have different features and deviations for=
 the

> same object in that proposal.



Actually, this is not correct.=C2=A0 In both OC and the old IETF split tree=


solutions, the configuration and operational state were modelled with

duplicate nodes, and you could certainly deviate these nodes

differently.



No, you cannot deviate the same schema=
 node in different ways.
You can define or deviate 2 different sc=
hema nodes.
That is the unacceptable change to YANG and why I lik=
e the OC solution better.

=C2=A0

This said, I share your concern about complexity.=C2=A0 I also agree that
the only model that makes the client simple is that if all objects in

the config are also available with the same types in operational

state.=C2=A0 Otherwise comparison won't work (or be complicated).




Agreed.
A ven=
dor can provide unusable APIs with any YANG module,
given the rig=
ht deviations, so this cannot be a factor.
But the OC solution di=
d not allow features to be different at all.


<=
/div>

But at the same time, the converse is not true.=C2=A0 I.e., if an object is=


present in operational, it doesn't have to be configurable.



Correct but maybe irrelevant.

I am only concerned with the same schema node being differ=
ent in multiple
datastores.=C2=A0 This was never part of the OC r=
equirement.

Each datastore can implement a specifi=
c subset of all the server modules.
That part is well-defined and=
 the framework allows for lots of innovation here
without modifyi=
ng YANG at all.


=C2=A0

So what I think we want is that the schema for the conventional

datastore is a subset of the schema for operational.



This would allow an implementation that cannot support configuration

of let's say the MTU, to deviate the mtu with "not-supported"=
 in the

conventional datastore, but it will still be available for inspection

in operational.



Does this make sense?


No=
n-overlapping subsets are fine.
Overlapping subset but the detail=
s are the same for each module are fine.







/martin



Andy<=
/div>



--001a114188aa4c01a7055c65a5e3--


From nobody Wed Oct 25 17:06:20 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1314F13F4F1 for ; Wed, 25 Oct 2017 17:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.011
X-Spam-Level: 
X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=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 heVtTF_YuJuC for ; Wed, 25 Oct 2017 17:06:14 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0128.outbound.protection.outlook.com [104.47.32.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B79813954B for ; Wed, 25 Oct 2017 17:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QLooy9q+s+dy2Dc4R/bfb4h0c6suAgXQPMIDyEp2iLc=; b=gZdMOYhfCLbwdtfyF3vCNTARml8sFudG6Tl9IxeflsuZrf/zc3yYC8zr3lqNKfpLjAXsV/omGbrqCr8uuSio6CSZM+fb0Az8bwrxon4KGeuMBNxTjWLTsg35pwFwjcol+Q3G50x7XWnWl00kJKg9wntZLA/PQfdf54iy2h/blGE=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB276.namprd05.prod.outlook.com (10.141.22.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Thu, 26 Oct 2017 00:06:12 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0178.003; Thu, 26 Oct 2017 00:06:12 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "Robert Wilton" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt
Thread-Index: AQHTTY/GCcSGoy8Ln0yx9ksq5tj726L0ixkAgAABvgCAABb3AIAAWnsA
Date: Thu, 26 Oct 2017 00:06:12 +0000
Message-ID: <0D675509-60FA-4EC7-9773-DB2451BDC2B7@juniper.net>
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net>  <20171025144222.fyjpong223vhz637@elstar.local>
In-Reply-To: <20171025144222.fyjpong223vhz637@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; BLUPR05MB276; 6:PHF4oXGVheipWUbyBUXOQ1gDPxMB7HyLqxSa7+nyYT/xOVFSPwOehceGTTyB9YiQFWoRLvGf+M0qXZDWsvX5YmdY/KmH3rVZrM8279GwZ7w0uxfjTjGrxPEMpd+CJWYgLzKksejhWPE4SPZX2cvlp90PC3amhKXkOyg4I9emWO034uDqrdKewmJBf2rLJLTw3uLtAA68YmiJmvGRk9hQnQXscwzCOQIjRZH4hzadLsy7nHJVEX3/Fugmku94GObqxRb1qNPgbYS0CG2wkncimzDcQVw5Y4KC+gCwiC4gdsLq1rxXslZZQ31XBgqk8AxQgiWK5m3eSGve76G0dYsLs+Ef2hoJQntm+tC4pQhRJKI=; 5:rAE8dv7x2VYzU1q9nD1yIahPPIPZn4NdT1BStrHbUPhNRIatSIdkJKQugljN+NurJ6sVSEAg1Ps/94+q5PfOrU0Wo497bKsQzkdLUadyAnn5K9Y6Ecf2RQXGTgtc01ZRYWi6k62dab3MNIBOi9EkHfUvY0rkDcP2hbfh1xMkwQk=; 24:0y5ciDq6leJJ5RTrD2EqfYKSX1WjmBB8f/u+4LzWWCO15NEkbYKs9AsEdndwsPjO7j0h51WqU9eQVCYhmqqFM2fNg+R34Jpy6f85Gqk7/3o=; 7:XCkduFaLMU+2C79eTXJIQHWvd2pTL+3mTjokw1ZUU1m/s6RIy8xrKs3BN2Mze6ACGWv/XS59AwqcoIP+EERyXnvKcUAwD2RTS8qYFjXRZIcIxQzafYCH+J3AM3sQqc4xqcvN/d+Vydq+uR5z5YJLVBo2HC8GH6RWpm9vRTnEF/9ejyGdw2CF9h0kQ/aFobSW7mcVH1DG0x4+xiuF/7+wbU5F27PQhpBD/RxzJa7LrcEDy+tgG6wy4DpwDTPajUAf
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 31524a05-2954-4fa8-ab0d-08d51c055e55
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:BLUPR05MB276; 
x-ms-traffictypediagnostic: BLUPR05MB276:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB276; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB276; 
x-forefront-prvs: 04724A515E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(199003)(189002)(8676002)(3280700002)(81166006)(2950100002)(478600001)(82746002)(93886005)(66066001)(81156014)(14454004)(305945005)(230783001)(36756003)(7736002)(3660700001)(2906002)(97736004)(5660300001)(25786009)(83506002)(58126008)(83716003)(316002)(8936002)(106356001)(50986999)(6486002)(76176999)(77096006)(68736007)(54356999)(105586002)(110136005)(3846002)(101416001)(4326008)(229853002)(6116002)(102836003)(6246003)(86362001)(6512007)(99286003)(6506006)(189998001)(33656002)(2900100001)(6436002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB276; H:BLUPR05MB275.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)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
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: 31524a05-2954-4fa8-ab0d-08d51c055e55
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 00:06:12.5098 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB276
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.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, 26 Oct 2017 00:06:16 -0000

RnJvbSBhbm90aGVyIHRocmVhZCBpbiBORVRDT05GLCBKdWVyZ2VuIHdyaXRlczoNCg0KICBJIGRv
IG5vdCBrbm93IHdoZXRoZXIgdGhlIG9mZmljaWFsIHRyZWUgZGlhZ3JhbSBmb3JtYXRzIHdpbGwg
DQogIGhhdmUgd2F5cyB0byBzaG93IHNheSBhIGNvbnRhaW5lciB3aXRoIHVzZWQgZ3JvdXBpbmdz
IGNvbGxhcHNlZC4NCiAgVGhpcyBtYXkgYWN0dWFsbHkgYmUgdXNlZnVsIHNvbWV0aW1lcywgYnV0
IHRoaXMgaXMgbm90IHdoYXQgeW91DQogIGFyZSBsb29rIGZvciBoZXJlIGVpdGhlci4gSSBhbSB0
aGlua2luZyBhYm91dA0KDQogICArLS1ydyBjb250YWluZXINCiAgICAgICstdS0tIDxncm91cGlu
Zz4gICAgICAgKEknbSBndWVzcyAndScgZm9yICJ1c2VzIikNCiAgICAgICstLXJ3IHJlZ3VsYXIt
bGVhZg0KDQogIENsZWFybHksIHRoaXMgaXMgZm9yIGEgZGlmZmVyZW50IHRocmVhZC4uLg0KDQog
IEFuZCBJIHdyb3RlIGJhY2sgIkl0IG1pZ2h0IGJlIGhlbHBmdWwgdG8gaGF2ZSB0aGUgYWJpbGl0
eSB0byANCiAgb3V0cHV0IGEgdHJlZSBkaWFncmFtIHRoYXQgaGFzIG5vdCBleHBhbmRlZCBpdHMg
Z3JvdXBpbmdzLiAgDQogIEJ1dCwgYXMgeW91IHNheSwgZm9yIGFub3RoZXIgdGhyZWFkLiINCg0K
DQpUbyBhZGQgdG8gdGhpcywgSSB3cm90ZSBhIG1vZHVsZSByZWNlbnRseSB0aGF0IGRlZmluZWQg
YW4gUlBDDQphbmQgeWFuZy1kYXRhIGFyb3VuZCB0aGUgc2FtZSBncm91cGluZ3MuICBBbiBhYmls
aXR5IHRvIDEpIHByaW50DQp0aGUgZ3JvdXBpbmdzIGFuZCAyKSBvbmx5IHByaW50IHJlZmVyZW5j
ZXMgdG8gdGhlIGdyb3VwaW5ncywNCndvdWxkJ3ZlIGNvbGxhcHNlZCB0aGUgdHJlZS1kaWFncmFt
IHRyZW1lbmRvdXNseS4gIEZvciBleGFtcGxlOg0KDQpycGNzOg0KDQogIGZvb2Jhcg0KICAgIGlu
cHV0DQogICAgICArLXUtLSA8aW5wdXQtZ3JvdXBpbmc+DQogICAgb3V0cHV0DQogICAgICArLXUt
LSA8b3V0cHV0LWdyb3VwaW5nPg0KDQp5YW5nLWRhdGE6DQoNCiAgaW5wdXQtYXJ0aWZhY3QNCiAg
ICArLXUtLSA8aW5wdXQtZ3JvdXBpbmc+DQoNCiAgb3V0cHV0LWFydGlmYWN0DQogICAgKy11LS0g
PG91dHB1dC1ncm91cGluZz4NCg0KZ3JvdXBpbmdzOg0KDQogIGlucHV0LWdyb3VwaW5nDQogICAr
LS0gPGZ1bGwgdHJlZSBoZXJlPg0KDQogIG91dHB1dC1ncm91cGluZw0KICAgKy0tIGZ1bGwgdHJl
ZSBoZXJlPg0KDQoNClRob3VnaHRzPw0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQo=


From nobody Wed Oct 25 17:21:07 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F2A13F4FC for ; Wed, 25 Oct 2017 17:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BmYxtK0SqyQc for ; Wed, 25 Oct 2017 17:20:53 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241D813A441 for ; Wed, 25 Oct 2017 17:20:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYL27278; Thu, 26 Oct 2017 00:20:49 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 26 Oct 2017 01:20:47 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001;  Wed, 25 Oct 2017 17:20:42 -0700
From: Alexander Clemm 
To: Kent Watsen , Juergen Schoenwaelder , Robert Wilton 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt
Thread-Index: AQHTTY/ZXNxDwTOxe0Sv8TZmZdoHr6L1AHIAgAABvgCAABb3AIAAnYkA//+OBbA=
Date: Thu, 26 Oct 2017 00:20:41 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB954F@sjceml521-mbx.china.huawei.com>
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net>  <20171025144222.fyjpong223vhz637@elstar.local> <0D675509-60FA-4EC7-9773-DB2451BDC2B7@juniper.net>
In-Reply-To: <0D675509-60FA-4EC7-9773-DB2451BDC2B7@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.102]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59F12A62.0080, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 27132543671324f0e5968e894f7c0e3b
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.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, 26 Oct 2017 00:20:56 -0000

I would find an  option to show "uses" very useful, instead of always havin=
g to expand groupings.  Depending on the groupings and the amount of groupi=
ngs reuse it can cut down complexity of trees substantially and directs foc=
us to the forest, not the trees - really ultimately the intent of this. =20

--- Alex

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
> Sent: Wednesday, October 25, 2017 5:06 PM
> To: Juergen Schoenwaelder ;
> Robert Wilton 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-
> 02.txt
>=20
> From another thread in NETCONF, Juergen writes:
>=20
>   I do not know whether the official tree diagram formats will
>   have ways to show say a container with used groupings collapsed.
>   This may actually be useful sometimes, but this is not what you
>   are look for here either. I am thinking about
>=20
>    +--rw container
>       +-u--        (I'm guess 'u' for "uses")
>       +--rw regular-leaf
>=20
>   Clearly, this is for a different thread...
>=20
>   And I wrote back "It might be helpful to have the ability to
>   output a tree diagram that has not expanded its groupings.
>   But, as you say, for another thread."
>=20
>=20
> To add to this, I wrote a module recently that defined an RPC
> and yang-data around the same groupings.  An ability to 1) print
> the groupings and 2) only print references to the groupings,
> would've collapsed the tree-diagram tremendously.  For example:
>=20
> rpcs:
>=20
>   foobar
>     input
>       +-u-- 
>     output
>       +-u-- 
>=20
> yang-data:
>=20
>   input-artifact
>     +-u-- 
>=20
>   output-artifact
>     +-u-- 
>=20
> groupings:
>=20
>   input-grouping
>    +-- 
>=20
>   output-grouping
>    +-- full tree here>
>=20
>=20
> Thoughts?
>=20
> Kent // contributor
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Oct 25 18:22:38 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF5613B098 for ; Wed, 25 Oct 2017 18:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZokb2lmvGkT for ; Wed, 25 Oct 2017 18:22:36 -0700 (PDT)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 6DB8313A5CF for ; Wed, 25 Oct 2017 18:22:36 -0700 (PDT)
Received: by mail-pg0-x230.google.com with SMTP id g6so1390359pgn.6 for ; Wed, 25 Oct 2017 18:22:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qv7oXLZAU+AXI2jLFfJKejy/hpNbN+fxbyh0sdT5pG4=; b=fidKnF+4RPbIWzxeVq0h2HDvTxLd2nDfqOBoi7I7ROPvruSfA+1gs6FHiu7uKNYCve Hvezvi1p1w2zqsvo0BZVTDJqq9xZc6PHb/PzwrjmQLhCeT+p/hMZYkpeexfUqXpOuzf7 sNLrmpfaRLWyyFY1brxhS55lJS1PD1IVgpbXnVo6fRoEOKtACXpQrahbkRSXbcWGP3JK m2vBTiG8RPQn3yEBy6V7nFLuXlOUcbSCbjOGFQv3tA2o+Lv0s5PaoJrb5om29i7SCIQx bfNGk0u/BcCTs40IzLMe+M6PliWHC4f+sWtRcN2IaJmHLBusEyPh+sIsa/clcZ10nJNd RCPg==
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=Qv7oXLZAU+AXI2jLFfJKejy/hpNbN+fxbyh0sdT5pG4=; b=C3eTAqZrmmIqjIICFJEsgbSXJsveewA+RtXhSFG4iEMvg3fMFdQPKhAgXj0hYWJ37e KCXcM//3YJuXQxPrAO5E0bXMzNNB8qB6JT6/k3/gaORq2rREjLxEA1/6XtMOb8IcYLB1 oqD5v/TwjmkdTRO6VxdfvMaZxMOXdX/qTg4Q/6PewKdn5gPVyHsFNC3g9oCoDi8ujmt4 m3QNwv3wAdGUEEyZpyO/OYse0V/Th2Ru8VRTrx1Nsy3nH8U6vYxlOAhhaMPxrqm/HdKb KKJWmVOmeHgowetIa6PVkxxUwuLkk3NKryNXhM7AAeQwb4of4/sBz+XhlG51rZG4stWh RTrg==
X-Gm-Message-State: AMCzsaU1eBaYVXwifb0ddwC2jU/KmWcXG0CEQOb+IVUAJ3+Ej9bE3jjC 4yXsS3oZ5z12Lfgdd6ZMzbs=
X-Google-Smtp-Source: ABhQp+S4RgMH4oQLDtzkLcXbLxk3ogcTateZmT3BAIcen1IADCJpWuPoQNevhmGH8zLERSR2qJ0Spg==
X-Received: by 10.84.174.67 with SMTP id q61mr3178573plb.184.1508980955413; Wed, 25 Oct 2017 18:22:35 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1320:5900:c62:62d3:bd5f? ([2001:420:30d:1320:5900:c62:62d3:bd5f]) by smtp.gmail.com with ESMTPSA id d15sm7054757pfj.163.2017.10.25.18.22.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Oct 2017 18:22:34 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Wed, 25 Oct 2017 18:22:56 -0700
Cc: Kent Watsen , "netmod@ietf.org" , Sonal Agarwal 
Content-Transfer-Encoding: quoted-printable
Message-Id: <880E1C02-2D32-4298-B970-D2D61E2F3C28@gmail.com>
References: 
To: "Acee Lindem (acee)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 01:22:38 -0000

Acee,

Thanks for reviewing the draft.

> On Oct 25, 2017, at 6:21 AM, Acee Lindem (acee)  =
wrote:
>=20
> Hi Kent, Mahesh, et al,
>=20
> I have read the draft and support publication. I have two comments on =
the
> -14 version.=20
>=20
>  1. The tree diagrams do not fit within the draft pages. Note that =
recent
> versions of pyang support the =E2=80=94tree-line-length parameter and =
this may
> help.=20

I used the =E2=80=94tree-line-length=3D72 as the parameter to generate =
the tree, and that is why you see the line wrap around.

>  2. While it is non-normative, I=E2=80=99d prefer to have appendix A.1 =
removed.
> It was a mistake for vendors to mix packet filtering and route =
filtering
> in the first place and the draft should not insinuate that the model =
will
> be augmented to do this.

The example is just an example of how the model can be extended. There =
is no implication that the model will be augmented to support mixing of =
packet filtering with route filtering.

>=20
> Thanks,
> Acee=20
>=20
> On 10/20/17, 5:37 PM, "netmod on behalf of Kent Watsen"
>  wrote:
>=20
>>=20
>> All,
>>=20
>> This starts a two-week working group last call on
>> draft-ietf-netmod-acl-model-14.
>>=20
>> The working group last call ends on November 3.
>> Please send your comments to the netmod mailing list.
>>=20
>> 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.
>>=20
>> Could the authors, explicitly CC-ed on this email, please
>> also confirm at this time that they are unaware of any
>> IPR related to this draft.
>>=20
>> Thank you,
>> Netmod 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

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Wed Oct 25 18:46:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFE1395F3 for ; Wed, 25 Oct 2017 18:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 tA9uvm1j2jWB for ; Wed, 25 Oct 2017 18:46:48 -0700 (PDT)
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 0B18113F4FB for ; Wed, 25 Oct 2017 18:46:48 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id 75so1994192lfx.1 for ; Wed, 25 Oct 2017 18:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1pNJ5Pdfv5P8xwjmydXN3FX3p3guKNVyrGo2NSHnHx8=; b=n/5LdsIz++Wk4et2TMw0mtiMgDpBsAk6mjaPJYa2ycJgMVES21olLEYpeG15nh5sTl CNYRBv8Q8W6RiTtvIaU65Rbdlo+AC8bVPLNqBHWuQjm8iFYjz25Ik8ewqN9yTsZprATe SCr4UynKVPEr8kqbncMmTlL0Thh2hb09zfFJPDJBqjc9qroucql44H79YsL6IzHH4OMt yLzzV0/FzTwRIRn23TEtxiWbCCbh6uQDkobMeczqrZrnFnK1jzMoQa4wleLUgQbYTFB5 O7isOWA5IEyc5HsvNyBUY4LB3+tG+pSpZuD25d2KuGQyb+tpgKuDFcRf3BZP6YhiFMmt OHHA==
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=1pNJ5Pdfv5P8xwjmydXN3FX3p3guKNVyrGo2NSHnHx8=; b=d+SpikbUYWRrA0KaSR0EuS+OnIE0NG4dUkFNHaLleh+Dc3vZ65PquMp8qIQ2EN3fgn +iasCDw4LNAsgbpgib/9yNVIB6v5dh/OURskJ0PtPNqIOM8V+EfhffFdxVwSF5+JmO4m smt+VDRiT+SYe2IQaz8/f6jO+0yL8nZnHnLdpDjfnSJJgL0mYRFR0wctcVPosQIGbOli ypfSes0owXSGq42iZbP+uMiHMkBrpJpAQqLNFFJJtDY8tk0U/yV3tKssOKNSuCVzaaZ6 GIih7qPLGGyPXU1C3jzcwXCq37n/LvcpeLH6LZsuBdX0LOTt8NjrluYIhExEWPRY4fmQ F8sg==
X-Gm-Message-State: AMCzsaW8LemugQWWfttf+n+OjlvgArxNCCe8Z8mdnthFllqEI5uql6dn eilhilfo5Ii8W+WzVIjTm8Mu+WFnHkmdkCPPgYidnA==
X-Google-Smtp-Source: ABhQp+Q8/K2ys+V95TFEmH8KW9Qz47f/VVOdw6FbX5gTKB3n0E0FYDcYyxcupsuaGVhcVDuKLrHsn/ZpsoIrVWDvChQ=
X-Received: by 10.46.117.24 with SMTP id q24mr8616253ljc.14.1508982406282; Wed, 25 Oct 2017 18:46:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Wed, 25 Oct 2017 18:46:45 -0700 (PDT)
In-Reply-To: <20171025.214929.480782767501855061.mbj@tail-f.com>
References:    <20171025.214929.480782767501855061.mbj@tail-f.com>
From: Andy Bierman 
Date: Wed, 25 Oct 2017 18:46:45 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Robert Wilton ,  Juergen Schoenwaelder , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="089e082f63e04c92aa055c6958be"
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 01:46:50 -0000

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

On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > I think NMDA is creating much more complexity and disruption than is
> > required.
> > The original issue was the OpenConfig-style config/state trees.
> > The WG agreed that an RPC-based solution was needed so that the
> > YANG modules would not need to change (far too disruptive!).
> >
> > Then the IETF proceeds to redo all the YANG modules anyway.
> > Now the server is allowed to implement the same module differently in
> each
> > datastore.
> > Now comparing the configured and operational value is even harder than
> > before.
> >
> > None of this added complexity was in the OpenConfig proposal.
> > It was not even possible to have different features and deviations for
> the
> > same object in that proposal.
>
> Actually, this is not correct.  In both OC and the old IETF split tree
> solutions, the configuration and operational state were modelled with
> duplicate nodes, and you could certainly deviate these nodes
> differently.
>
> This said, I share your concern about complexity.  I also agree that
> the only model that makes the client simple is that if all objects in
> the config are also available with the same types in operational
> state.  Otherwise comparison won't work (or be complicated).
>
> But at the same time, the converse is not true.  I.e., if an object is
> present in operational, it doesn't have to be configurable.
>
> So what I think we want is that the schema for the conventional
> datastore is a subset of the schema for operational.
>
> This would allow an implementation that cannot support configuration
> of let's say the MTU, to deviate the mtu with "not-supported" in the
> conventional datastore, but it will still be available for inspection
> in operational.
>
> Does this make sense?
>

OK -- deviations for not-supported make sense per datastore
to resolve the missing-object ambiguity problem.
It is not realistic to expect every object in a module to be able
to report its operational state in the same release.
It is better to report not-supported than return nothing or return the
configured value as a guess.

If the admin-state and oper-state objects are different, 2 objects should
be used instead of per-datastore deviations of the syntax of 1 object.



>
> /martin
>


Andy

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




On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> I think NMDA is creating much more complexity and disruption than is
> required.

> The original issue was the OpenConfig-style config/state trees.

> The WG agreed that an RPC-based solution was needed so that the

> YANG modules would not need to change (far too disruptive!).

>

> Then the IETF proceeds to redo all the YANG modules anyway.

> Now the server is allowed to implement the same module differently in =
each

> datastore.

> Now comparing the configured and operational value is even harder than=


> before.

>

> None of this added complexity was in the OpenConfig proposal.

> It was not even possible to have different features and deviations for=
 the

> same object in that proposal.



Actually, this is not correct.=C2=A0 In both OC and the old IETF split tree=


solutions, the configuration and operational state were modelled with

duplicate nodes, and you could certainly deviate these nodes

differently.



This said, I share your concern about complexity.=C2=A0 I also agree that
the only model that makes the client simple is that if all objects in

the config are also available with the same types in operational

state.=C2=A0 Otherwise comparison won't work (or be complicated).



But at the same time, the converse is not true.=C2=A0 I.e., if an object is=


present in operational, it doesn't have to be configurable.



So what I think we want is that the schema for the conventional

datastore is a subset of the schema for operational.



This would allow an implementation that cannot support configuration

of let's say the MTU, to deviate the mtu with "not-supported"=
 in the

conventional datastore, but it will still be available for inspection

in operational.



Does this make sense?

OK -- deviations =
for not-supported make sense per datastore
to resolve the missing=
-object ambiguity problem.
It is not realistic to expect every ob=
ject in a module to be able
to report its operational state in th=
e same release.
It is better to report not-supported than return =
nothing or return the
configured value as a guess.

=

If the admin-state and oper-state objects are different, 2 objec=
ts should
be used instead of per-datastore deviations of the synt=
ax of 1 object.







/martin




<=
/div>
Andy



--089e082f63e04c92aa055c6958be--


From nobody Thu Oct 26 02:28:17 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515ED13F4D3; Thu, 26 Oct 2017 02:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 S5XHJ9imiC2y; Thu, 26 Oct 2017 02:28:14 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E8413A5A3; Thu, 26 Oct 2017 02:28:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYM03237; Thu, 26 Oct 2017 09:28:12 +0000 (GMT)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 26 Oct 2017 10:28:12 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.154]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Thu, 26 Oct 2017 17:27:37 +0800
From: "dingxiaojian (A)" 
To: "i-d-announce@ietf.org" 
CC: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-ding-netmod-arp-yang-model-00.txt
Thread-Index: AdNOPIiM+GAErL7MSeeuMv3UOyh70w==
Date: Thu, 26 Oct 2017 09:27:37 +0000
Message-ID: <3B110B81B721B940871EC78F107D848C01015592@DGGEMM506-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.134.227]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.59F1AAAD.000D, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.3.154, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1a2aa0ba52a018268152eef7e2fcc066
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-ding-netmod-arp-yang-model-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, 26 Oct 2017 09:28:16 -0000

SGkgYWxsLA0KDQpUaGUgQVJQIFlBTkcgbW9kdWxlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBo
YXMgY29tbW9uIHByb3BlcnRpZXMgdGhhdCBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQuIA0KSXQgcHJv
dmlkZXMgZnJlZWRvbSBmb3Igc2VydmljZSBwcm92aWRlcnMgdG8gYWRhcHQgdGhpcyBkYXRhIG1v
ZGVsIHRvIGRpZmZlcmVudCBwcm9kdWN0IGltcGxlbWVudGF0aW9ucy4NCg0KUGxlYXNlIGhhdmUg
YSBsb29rIGFuZCBwcm92aWRlIGNvbW1lbnRzIG9uIHRoZSBsaXN0Lg0KVGhhbmtzLA0KDQpYaWFv
amlhbg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kaW5nLW5ldG1vZC1hcnAteWFu
Zy1tb2RlbC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2pp
YW4gRGluZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm
dC1kaW5nLW5ldG1vZC1hcnAteWFuZy1tb2RlbA0KUmV2aXNpb246CTAwDQpUaXRsZToJCVlBTkcg
RGF0YSBNb2RlbCBmb3IgQVJQDQpEb2N1bWVudCBkYXRlOgkyMDE3LTEwLTI2DQpHcm91cDoJCUlu
ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v
d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kaW5nLW5ldG1vZC1hcnAteWFuZy1t
b2RlbC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1kaW5nLW5ldG1vZC1hcnAteWFuZy1tb2RlbC8NCkh0bWxpemVkOiAgICAgICBo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGluZy1uZXRtb2QtYXJwLXlhbmctbW9k
ZWwtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o
dG1sL2RyYWZ0LWRpbmctbmV0bW9kLWFycC15YW5nLW1vZGVsLTAwDQoNCg0KQWJzdHJhY3Q6DQog
ICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgdG8gZGVzY3JpYmUgQWRk
cmVzcw0KICAgUmVzb2x1dGlvbiBQcm90b2NvbCAoQVJQKSBjb25maWd1cmF0aW9ucy4gIEl0IGlz
IGludGVuZGVkIHRoaXMgbW9kZWwNCiAgIGJlIHVzZWQgYnkgc2VydmljZSBwcm92aWRlcnMgd2hv
IG1hbmlwdWxhdGUgZGV2aWNlcyBmcm9tIGRpZmZlcmVudA0KICAgdmVuZG9ycyBpbiBhIHN0YW5k
YXJkIHdheS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRo
YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p
c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh
dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K


From nobody Thu Oct 26 02:47:01 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F173613F545 for ; Thu, 26 Oct 2017 02:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSXbiaeHldk3 for ; Thu, 26 Oct 2017 02:46:58 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B9213F50D for ; Thu, 26 Oct 2017 02:46:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3384; q=dns/txt; s=iport; t=1509011218; x=1510220818; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aqPda5Ak/menQlF1c8F5ukl5xgOgd7zNlo9R7jZSvwk=; b=ZI/WehZ7yHN62uzRJ1f1Iii1xNpsCnx9UiTNls3dV+fPaXu4rErgnWy0 J6qOo9X36hcpknUiatJmxyn5izzYf8ruYdrxTzbiCwMH9mbVZCP6HWuc3 PZfKxtuHQktZ/g+axjDocpLv5fBiuKBEwkmfhOBc366tMSFT6SowT6HvZ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAADQrfFZ/5pdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHg3OKH48LgXqITo1yEIIBChgLhElPAhqEXT8YAQIBAQE?= =?us-ascii?q?BAQEBayiFHQEBAQECAQEBIRE6CxACAQgOCgICJgICAh8GCxUQAgQOBYoIAw0IE?= =?us-ascii?q?KkrgieHNQ2DLwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CH4IHhmOCXoF0ARI?= =?us-ascii?q?BB4MsgmEFoT08Ao9+hHmCFYV+hAKHFY0TiEgCERkBgTgBHziBA2V6FUmCZIRfd?= =?us-ascii?q?4k4gSSBEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,434,1503360000"; d="scan'208";a="306347807"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2017 09:46:57 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9Q9kv7a025468 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Oct 2017 09:46:57 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; Thu, 26 Oct 2017 05:46:56 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 26 Oct 2017 05:46:55 -0400
From: "Acee Lindem (acee)" 
To: Mahesh Jethanandani 
CC: Kent Watsen , "netmod@ietf.org" , "Sonal Agarwal (agarwaso)" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
Thread-Index: AQHTTZQz4R9mVwyDOkCxkCX5K2HeVqL1mc0AgABJnYA=
Date: Thu, 26 Oct 2017 09:46:55 +0000
Message-ID: 
References:  <880E1C02-2D32-4298-B970-D2D61E2F3C28@gmail.com>
In-Reply-To: <880E1C02-2D32-4298-B970-D2D61E2F3C28@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.116.152.195]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2A07129E279FF34D85424C68EB944DCA@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 09:47:00 -0000

SGkgTWFoZXNoLCANCg0KT24gMTAvMjUvMTcsIDk6MjIgUE0sICJNYWhlc2ggSmV0aGFuYW5kYW5p
IiA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQp3cm90ZToNCg0KPkFjZWUsDQo+DQo+VGhhbmtz
IGZvciByZXZpZXdpbmcgdGhlIGRyYWZ0Lg0KPg0KPj4gT24gT2N0IDI1LCAyMDE3LCBhdCA2OjIx
IEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4g
SGkgS2VudCwgTWFoZXNoLCBldCBhbCwNCj4+IA0KPj4gSSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFu
ZCBzdXBwb3J0IHB1YmxpY2F0aW9uLiBJIGhhdmUgdHdvIGNvbW1lbnRzIG9uDQo+PnRoZQ0KPj4g
LTE0IHZlcnNpb24uIA0KPj4gDQo+PiAgMS4gVGhlIHRyZWUgZGlhZ3JhbXMgZG8gbm90IGZpdCB3
aXRoaW4gdGhlIGRyYWZ0IHBhZ2VzLiBOb3RlIHRoYXQNCj4+cmVjZW50DQo+PiB2ZXJzaW9ucyBv
ZiBweWFuZyBzdXBwb3J0IHRoZSDigJR0cmVlLWxpbmUtbGVuZ3RoIHBhcmFtZXRlciBhbmQgdGhp
cyBtYXkNCj4+IGhlbHAuIA0KPg0KPkkgdXNlZCB0aGUg4oCUdHJlZS1saW5lLWxlbmd0aD03MiBh
cyB0aGUgcGFyYW1ldGVyIHRvIGdlbmVyYXRlIHRoZSB0cmVlLA0KPmFuZCB0aGF0IGlzIHdoeSB5
b3Ugc2VlIHRoZSBsaW5lIHdyYXAgYXJvdW5kLg0KDQpJIGd1ZXNzIHRoZW4geW91IG5lZWQgdG8g
bWFudWFsbHkgZm9ybWF0IGl0IHNvIGl0IGZpdHMuDQoNCj4NCj4+ICAyLiBXaGlsZSBpdCBpcyBu
b24tbm9ybWF0aXZlLCBJ4oCZZCBwcmVmZXIgdG8gaGF2ZSBhcHBlbmRpeCBBLjEgcmVtb3ZlZC4N
Cj4+IEl0IHdhcyBhIG1pc3Rha2UgZm9yIHZlbmRvcnMgdG8gbWl4IHBhY2tldCBmaWx0ZXJpbmcg
YW5kIHJvdXRlIGZpbHRlcmluZw0KPj4gaW4gdGhlIGZpcnN0IHBsYWNlIGFuZCB0aGUgZHJhZnQg
c2hvdWxkIG5vdCBpbnNpbnVhdGUgdGhhdCB0aGUgbW9kZWwNCj4+d2lsbA0KPj4gYmUgYXVnbWVu
dGVkIHRvIGRvIHRoaXMuDQo+DQo+VGhlIGV4YW1wbGUgaXMganVzdCBhbiBleGFtcGxlIG9mIGhv
dyB0aGUgbW9kZWwgY2FuIGJlIGV4dGVuZGVkLiBUaGVyZSBpcw0KPm5vIGltcGxpY2F0aW9uIHRo
YXQgdGhlIG1vZGVsIHdpbGwgYmUgYXVnbWVudGVkIHRvIHN1cHBvcnQgbWl4aW5nIG9mDQo+cGFj
a2V0IGZpbHRlcmluZyB3aXRoIHJvdXRlIGZpbHRlcmluZy4NCg0KSSB1bmRlcnN0YW5kIHRoYXQu
IEhvd2V2ZXIsIGl0IGlzIG1vcmUgYW4gZXhhbXBsZSBvZiBob3cgaXQgc2hvdWxkIG5vdCBiZQ0K
dXNlZC4gRG8geW91IHJlYWxseSB3YW50IHRvIHB1Ymxpc2ggdGhpcz8NCg0KVGhhbmtzLA0KQWNl
ZQ0KDQo+DQo+PiANCj4+IFRoYW5rcywNCj4+IEFjZWUgDQo+PiANCj4+IE9uIDEwLzIwLzE3LCA1
OjM3IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiINCj4+IDxuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+
PiANCj4+PiANCj4+PiBBbGwsDQo+Pj4gDQo+Pj4gVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3Jr
aW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPj4+IGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0x
NC4NCj4+PiANCj4+PiBUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBOb3ZlbWJl
ciAzLg0KPj4+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5n
IGxpc3QuDQo+Pj4gDQo+Pj4gUG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2Vk
IHRoaXMgZG9jdW1lbnQNCj4+PiBhbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRp
b24iLCBhcmUgd2VsY29tZSENCj4+PiBUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVu
IGZyb20gYXV0aG9ycy4NCj4+PiANCj4+PiBDb3VsZCB0aGUgYXV0aG9ycywgZXhwbGljaXRseSBD
Qy1lZCBvbiB0aGlzIGVtYWlsLCBwbGVhc2UNCj4+PiBhbHNvIGNvbmZpcm0gYXQgdGhpcyB0aW1l
IHRoYXQgdGhleSBhcmUgdW5hd2FyZSBvZiBhbnkNCj4+PiBJUFIgcmVsYXRlZCB0byB0aGlzIGRy
YWZ0Lg0KPj4+IA0KPj4+IFRoYW5rIHlvdSwNCj4+PiBOZXRtb2QgQ2hhaXJzDQo+Pj4gDQo+Pj4g
DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+
PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+IA0KPj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxp
c3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCj4NCj5NYWhlc2ggSmV0aGFuYW5kYW5pDQo+bWpldGhhbmFuZGFuaUBn
bWFpbC5jb20NCj4NCj4NCj4NCg0K


From nobody Thu Oct 26 03:09:24 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E19C13F54C for ; Thu, 26 Oct 2017 03:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X58RXweutccU for ; Thu, 26 Oct 2017 03:09:22 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0879013F545 for ; Thu, 26 Oct 2017 03:09:22 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id EDE3A1AE012C; Thu, 26 Oct 2017 12:09:20 +0200 (CEST)
Date: Thu, 26 Oct 2017 12:09:20 +0200 (CEST)
Message-Id: <20171026.120920.1585653562670944391.mbj@tail-f.com>
To: acee@cisco.com
Cc: mjethanandani@gmail.com, agarwaso@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <880E1C02-2D32-4298-B970-D2D61E2F3C28@gmail.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 10:09:23 -0000

IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gSGkgTWFoZXNo
LCANCj4gDQo+IE9uIDEwLzI1LzE3LCA5OjIyIFBNLCAiTWFoZXNoIEpldGhhbmFuZGFuaSIgPG1q
ZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KPiB3cm90ZToNCj4gDQo+ID5BY2VlLA0KPiA+DQo+ID5U
aGFua3MgZm9yIHJldmlld2luZyB0aGUgZHJhZnQuDQo+ID4NCj4gPj4gT24gT2N0IDI1LCAyMDE3
LCBhdCA2OjIxIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90ZToN
Cj4gPj4gDQo+ID4+IEhpIEtlbnQsIE1haGVzaCwgZXQgYWwsDQo+ID4+IA0KPiA+PiBJIGhhdmUg
cmVhZCB0aGUgZHJhZnQgYW5kIHN1cHBvcnQgcHVibGljYXRpb24uIEkgaGF2ZSB0d28gY29tbWVu
dHMgb24NCj4gPj50aGUNCj4gPj4gLTE0IHZlcnNpb24uIA0KPiA+PiANCj4gPj4gIDEuIFRoZSB0
cmVlIGRpYWdyYW1zIGRvIG5vdCBmaXQgd2l0aGluIHRoZSBkcmFmdCBwYWdlcy4gTm90ZSB0aGF0
DQo+ID4+cmVjZW50DQo+ID4+IHZlcnNpb25zIG9mIHB5YW5nIHN1cHBvcnQgdGhlIOKAlHRyZWUt
bGluZS1sZW5ndGggcGFyYW1ldGVyIGFuZCB0aGlzIG1heQ0KPiA+PiBoZWxwLiANCj4gPg0KPiA+
SSB1c2VkIHRoZSDigJR0cmVlLWxpbmUtbGVuZ3RoPTcyIGFzIHRoZSBwYXJhbWV0ZXIgdG8gZ2Vu
ZXJhdGUgdGhlIHRyZWUsDQo+ID5hbmQgdGhhdCBpcyB3aHkgeW91IHNlZSB0aGUgbGluZSB3cmFw
IGFyb3VuZC4NCj4gDQo+IEkgZ3Vlc3MgdGhlbiB5b3UgbmVlZCB0byBtYW51YWxseSBmb3JtYXQg
aXQgc28gaXQgZml0cy4NCg0KVHJ5IC0tdHJlZS1saW5lLWxlbmd0aCA2OS4gICBUaGUgcmVhc29u
IGZvciB0aGlzIGlzIHRoYXQgdGhlIGZpZ3VyZXMNCmFyZSBpbmRlbnRlZCBieSB4bWwycmZjLiAg
SSBhZGRlZCB0aGlzIGFzIGEgcmVjb21tZW50aW9uIHRvIHRoZQ0KdHJlZS1kaWFncmFtIGRyYWZ0
IGFzIHdlbGwgdGhlIG90aGVyIGRheS4NCg0KDQovbWFydGluDQo=


From nobody Thu Oct 26 03:10:36 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54913F54C for ; Thu, 26 Oct 2017 03:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UXO-vVzWXH_U for ; Thu, 26 Oct 2017 03:10:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CC8F113F545 for ; Thu, 26 Oct 2017 03:10:27 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 176621AE012C; Thu, 26 Oct 2017 12:10:27 +0200 (CEST)
Date: Thu, 26 Oct 2017 12:10:26 +0200 (CEST)
Message-Id: <20171026.121026.1881945352164553624.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: rwilton@cisco.com, j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20171025.214929.480782767501855061.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 10:10:34 -0000

Andy Bierman  wrote:
> On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > I think NMDA is creating much more complexity and disruption than is
> > > required.
> > > The original issue was the OpenConfig-style config/state trees.
> > > The WG agreed that an RPC-based solution was needed so that the
> > > YANG modules would not need to change (far too disruptive!).
> > >
> > > Then the IETF proceeds to redo all the YANG modules anyway.
> > > Now the server is allowed to implement the same module differently in
> > each
> > > datastore.
> > > Now comparing the configured and operational value is even harder than
> > > before.
> > >
> > > None of this added complexity was in the OpenConfig proposal.
> > > It was not even possible to have different features and deviations for
> > the
> > > same object in that proposal.
> >
> > Actually, this is not correct.  In both OC and the old IETF split tree
> > solutions, the configuration and operational state were modelled with
> > duplicate nodes, and you could certainly deviate these nodes
> > differently.
> >
> > This said, I share your concern about complexity.  I also agree that
> > the only model that makes the client simple is that if all objects in
> > the config are also available with the same types in operational
> > state.  Otherwise comparison won't work (or be complicated).
> >
> > But at the same time, the converse is not true.  I.e., if an object is
> > present in operational, it doesn't have to be configurable.
> >
> > So what I think we want is that the schema for the conventional
> > datastore is a subset of the schema for operational.
> >
> > This would allow an implementation that cannot support configuration
> > of let's say the MTU, to deviate the mtu with "not-supported" in the
> > conventional datastore, but it will still be available for inspection
> > in operational.
> >
> > Does this make sense?
> >
> 
> OK -- deviations for not-supported make sense per datastore
> to resolve the missing-object ambiguity problem.
> It is not realistic to expect every object in a module to be able
> to report its operational state in the same release.
> It is better to report not-supported than return nothing or return the
> configured value as a guess.
> 
> If the admin-state and oper-state objects are different, 2 objects should
> be used instead of per-datastore deviations of the syntax of 1 object.

Agreed.

So based on this, how about this text:

  The schema for  MUST be a superset of the combined
  schema used in all configuration datastores except that YANG nodes
  supported in a configuration datastore MAY be omitted from
   if a server is not able to accurately report them.



/martin


From nobody Thu Oct 26 09:02:21 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5458813F597 for ; Thu, 26 Oct 2017 09:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp97lDKxLpoF for ; Thu, 26 Oct 2017 09:02:17 -0700 (PDT)
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 9BB7D13B488 for ; Thu, 26 Oct 2017 09:02:17 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id k40so4323958lfi.4 for ; Thu, 26 Oct 2017 09:02:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3uY42IVD2A4TSXjigtaOdLiVFenENXJOZS/oIj2dmJI=; b=hqpFe5PXXjqyVS6TesKMpCNg0SrUNAj/FN9W5KKSZPJ7uhDPVIEQAe7/3ZAxPp1nQW /6z7vdE5vyvKV/WfmVgKIAwIH2SkuAsFz8wV3N3rnEFWLMFaoQJuzXZkfOA0sD3C/YAt GHcUSLlrE+KAMFDoLnxmyG6hXXFEdNwxK1xdb/ejMdQtzDfiDSONBo+/vYz1ywNL5j5Z Sb45zoaxYyT7arhlMO5+kEUdbtDqmJfghzHViNVRMojoNAje6GRMcNPGtXfKF6JVFP5v oSkmMGktbbfusLUbw3kjO/JX/GXY5Sc7bNXcOdcxoRK/lBt/PizNwS+b7ynQPbWXZiSm pjxQ==
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=3uY42IVD2A4TSXjigtaOdLiVFenENXJOZS/oIj2dmJI=; b=Q+h9b7me8d0ff/02o2EjsYLVbXegsuSrEqxqZmJjobRmTzY7HjnMsVx3i7tqLtFTdk gm6NpZBRXHK1PZ5eKgbs9bzLwLgv6Jy30LktgsJXL1pjuMVngIZJC4hht5knlnyk8rAv A2Di/oZmvQThBiQlDm95VYw33Ig02uPfNRc52LdlFcwpr0rwuIHRXjP1AzUiIrnJo9kf O98ezQmznMxUxHRuPN+heqGFlF6vQ6EM3HaK8lyzDAWb4FQm0hy516xsgmknnlNfJNaY 3zx6SENhdIRP3ExEW9pmf0vQ4JuFe/zuf4ho5BGHGt790u4zNM7yBoSfQ4kgFF+jqGKV eugQ==
X-Gm-Message-State: AMCzsaVXACPGxH3TIeQlA+eUT1ZKLuhebLI9T9TbCnBke5O/HTo/CRNg SLFzb3ugRryUsEUgEZu0v6YtSLnUG7XvJ8GyiUBBWw==
X-Google-Smtp-Source: ABhQp+T+4ZDDn5i2q7AHy1BJWcV437lA76edF4JqIOE5IqZSlSx83DjRtg7bV6uQ3aSCb0a+jS/gYlPlsPlGOyQAI/Q=
X-Received: by 10.46.2.197 with SMTP id y66mr9606318lje.151.1509033735817; Thu, 26 Oct 2017 09:02:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Thu, 26 Oct 2017 09:02:14 -0700 (PDT)
In-Reply-To: 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>   
From: Andy Bierman 
Date: Thu, 26 Oct 2017 09:02:14 -0700
Message-ID: 
To: Vladimir Vassilev 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1cddeac72907055c754bd0"
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 16:02:19 -0000

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

On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev  wrote:

> On 10/24/2017 03:42 AM, Andy Bierman wrote:
>
> ....
>>
>> Although the instance-identifier is problematic, it is rarely used at all,
>> let alone using it as a list key.
>>
> It is used as a key in ietf-alarms /alarms/alarm-list/alarm.
>
>> ...
>
>
I guess if you wanted to create the most complex module possible,
using an XPath instance-identifier as a list key is a good start.

It's too bad we can't use the RESTCONF path URI string as an i-i:

  - the only representation is also the canonical representation
  - the list keys are much less verbose (required to be in schema order)
  - percent-encoded chars are allowed, which are simpler than character
entities
    and much simpler than the concat() function
  - no use of prefix mappings at all so i-i strings are complete and
permanent


Andy

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




On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev &l=
t;vladimir@tr=
anspacket.com> wrote:
On 10=
/24/2017 03:42 AM, Andy Bierman wrote:




....



Although the instance-identifier is problematic, it is rarely used at all,<=
br>
let alone using it as a list key.



It is used as a key in ietf-alarms /alarms/alarm-list/alarm.


...

=

I guess if you wanted to create the most complex module possible,
using an XPath instance-identifier as a list key is a good start.

It's too bad we can't use the RESTCONF path U=
RI string as an i-i:

=C2=A0 - the only representat=
ion is also the canonical representation
=C2=A0 - the list keys a=
re much less verbose (required to be in schema order)
=C2=A0 - pe=
rcent-encoded chars are allowed, which are simpler than character entities<=
/div>
=C2=A0 =C2=A0 and much simpler than the concat() function
=C2=A0 - no use of prefix mappings at all so i-i strings are complete an=
d permanent


Andy


=C2=A0



--94eb2c1cddeac72907055c754bd0--


From nobody Thu Oct 26 09:27:15 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C831384B5 for ; Thu, 26 Oct 2017 09:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 WFW4pjflAKBn for ; Thu, 26 Oct 2017 09:27:11 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0093.outbound.protection.outlook.com [104.47.40.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 AB5E013AD2D for ; Thu, 26 Oct 2017 09:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hqwpMGj3XmPVMxYbjrbYiFda+eRoaHW2kEc1IkfZ13U=; b=AlifS0TY2poHHefWDOOroxoX1RXAx+pH7DwNk6BFJVvP/zODEoFQYIHHQTFLE3xD7kB7t6EExwI4dytgNdPuwitKFkM60EG6+WTK2SPHjH9Sb6RObEiBFPDqQC8Oq7UHX2Q3JMG3XQsRnoAN/6xMhc5UECATmU41Vv403Id5AcA=
Received: from SN4PR0501CA0108.namprd05.prod.outlook.com (10.167.128.25) by SN1PR0501MB2080.namprd05.prod.outlook.com (10.163.227.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Thu, 26 Oct 2017 16:27:10 +0000
Received: from BY2NAM05FT035.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::201) by SN4PR0501CA0108.outlook.office365.com (2603:10b6:803:42::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Thu, 26 Oct 2017 16:27:10 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT035.mail.protection.outlook.com (10.152.100.172) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.178.5 via Frontend Transport; Thu, 26 Oct 2017 16:27:10 +0000
Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Oct 2017 09:27:09 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v9QGR8r5017051; Thu, 26 Oct 2017 09:27:09 -0700	(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 v9QGR7fU067102; Thu, 26 Oct 2017 12:27:07 -0400 (EDT)	(envelope-from phil@juniper.net)
Message-ID: <201710261627.v9QGR7fU067102@idle.juniper.net>
From: Phil Shafer 
To: Andy Bierman 
CC: Robert Wilton , "netmod@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <67100.1509035227.1@idle.juniper.net>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 Oct 2017 12:27:07 -0400
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(2980300002)(199003)(189002)(77096006)(229853002)(4326008)(54906003)(81166006)(46406003)(81156014)(76506005)(69596002)(53416004)(97756001)(8936002)(316002)(6916009)(86362001)(2950100002)(189998001)(7126002)(6246003)(7696004)(106466001)(47776003)(5660300001)(2906002)(97736004)(68736007)(8276002)(356003)(50466002)(105596002)(8746002)(23726003)(53936002)(54356999)(305945005)(478600001)(1076002)(8676002)(2810700001)(50986999)(299355004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2080; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT035; 1:mwqlXcSf8P3NaFlptQQjJeelu2gh/C5WW3jayhJPYUdgILV0P4BglPiAj8EYZHS7pccNJB0mOjpc3hu7Lt4GmMJATm4DHJxFQn/dE7ss+lUDp+IH9VlI7eXoyu+pg6Fb
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2c8b85ec-073a-4c76-b20e-08d51c8e6850
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:SN1PR0501MB2080; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2080; 3:dRW8jUvoFfW4clD8aI4WWIH0QVj66kYymGNJpJfwqx2vWreum8/Eqf99v1S8d/ziCgBHTDRXBQhChemMgh5TBZiMo27k2Ll5+bcA7N2NFit2IESz7nmzolPr7FByToxOcSdCz1x1jDhN+1t8hUBBasel7dFcqdoRXM8duAqh39t+kXG3DH5juPzO42cx7Uxx+6fKLUx2kwrWcVPCF/nek/B1GouFo3/x4pLd6f1ZsNiwpNh6PmR+AAnXgAqzsBWXK2mGNa+9FTvFFgulwUZG1Is1LMkv3HILBB+vTYEA2iu8dofTr7gMmyITAhH1KPZdpycQRS28nA7yBZa4avpux5yEc8/4sebBFVcQ2P2zV9s=; 25:ypZWM6xiYSWKP669+gP8dH0NhlmhgZ4JSeyWzxg6XmBxyZI4BEXHoEBpsHu+L5RF3j8cNgKZ+YRJVFV9PKWgVd0/TgvIPk7NXXotGEFI37DSwCsAd+w7I46mNzxnTdeC/5TZ4dfGgxq5R7aLFSdQINFe6MVKOrK3Vkip6ObCZmgP+HvLwPLg3gMITKlY1UYb1JIhpiNALa2T9Wd1C0fRrH90hKVR9YvBBo7VSsxy5uaCgglba3bsXVyWYUARBcatNkbDfNtg44tEZZZj4Ji65jtcXQDVaEymBQosyRFwE5udXMZANjy9Z+91SakUz/FVnA/DF1ApBFxWITjwG2ILHg==
X-MS-TrafficTypeDiagnostic: SN1PR0501MB2080:
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2080; 31:bmw86slkSiyFxp43VfGdK8cxdVa/PHg2coc8uc0s37biUWjPTy4/AwhmECh0Lme1Gy+U9FhdFh/aV0QIvgAzPAc+Hy04RslW9FMBvPc6/yRqPtnFQeLk4XPQ4v2SPxbkoNsE3OFbjYQ114cLBDQJCdGxedXBFuF2ouPxOjMTa8lcnsyu9VOl7+B5AlWbZYmB8rurM3w7U9h7OcIdqod+1Ic1J1ID64j+mGGbUPN8HPE=; 20:t+AZQyOBg69uNDMCLyq6lFgxeu9cFbEBM43nMWl+RL9bKuLyq+POXt+H1mOkTCSBv/bFmi7s/SHE+6kGHFIvw5YRYxFXN0XeiqXHaDbX86bLsST36ipCDDrRMrpdgl7UmD7wsJFhLtkdQaV5m0a5wvglkxG/gofgMR4oYs7OyztZ3TWkkDtmGpkmht2X88u0ZteHXobVXD2Fyt6jnprnrue2iGWc9YMaM7FDyqYKYtjoi1R4TdN3kr2fq6Tg0spWhLKzmauc6jI8N1WzDgMMz97U2k9MZA41YZ5ZuUdScO4uwIcJc5yZIxHHeGF0Kjqk7zuJtJ8roj6VsdCA94dzdeY/GuMDw2Wngadsw3L22benU+QM/V6lVMTk52UWKB3tO2yBLScGSo0mUtG0phoRre+A7B1ugF1n78rt78k8gmiwaOMMzzdlgkl43wjUIjX7sCjVAzqpROP3Y+ovrCObMx9Ddsx0GggUdOqYltSImZa/4nFAtrDfgkXasZID/lou
X-Exchange-Antispam-Report-Test: UriScan:(17755550239193);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93003095)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0501MB2080; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0501MB2080; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2080; 4:MVJxlie+2FFrUt9upJXIT+McE+NreaJYtZfTJcd9rV6iujns4dnS4AWiocbN/2X4QHv1bRuHxbckXu/1krMqVHWp+EibwslQXk+7jtPbZ39s117a+9EVlX0o3CAzxOgErcflBXv3/3oaj1/3p9eaCWDlWHaougSRmxL3f7eURkhao3in4peRDmX4gFXWYZuMu2h/HwZDp3J6O1ge/6eZhUrD1rDnSAc+gExBSHmb3Qnbi8+BOHoMoDVEYsyhFvxBv9Fpk6HArUt7n4oKdWXlCyN3BH7OKeMuz/OarR+6gjUm1z8uWV6/uKmnj5jSX1fI
X-Forefront-PRVS: 04724A515E
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB2080; 23:PzKJqJQKDqanRWNZWekZBWdJQFOzbzOZjloml+g?= =?us-ascii?Q?Tgxygt9f14OIwBy7FlJ/6kmdqEpjw+L4kbsFgywu2QvW4ERBbCtlsZQmKIXC?= =?us-ascii?Q?Byl2thuhNRKOAzsWcPfh93vVEfV2DMSvwiQURO+hYKkGxT+UU0lpZH4lZ8sy?= =?us-ascii?Q?USKvkT1CgLyBchqJ+tj7XmNvwUO0ie4DX9+uFDtgFDZVzI0e28acXM/SFxDs?= =?us-ascii?Q?tbAN+wQ0IC9MxnDxK0WLGiiRsocIJ6M/+45sWMkGd8EqNuDDnuuq7f3nT2Nl?= =?us-ascii?Q?zyEjIzKAAKqkqTYLpAlqZd4ji+N72CEsITR3b29qekUuUsM/TgRanXGCAQqt?= =?us-ascii?Q?DQab/8bwUKdBcR7V53wPtcl6hP2MKyryKWb7jqiefd9b1dMlXpJdIUIwrspS?= =?us-ascii?Q?D9Y6oMzuvABqFRffZqIIKBncu9vO7PzQVwOipMypmIJ1+8BeqyEsZ7Vwg435?= =?us-ascii?Q?p2PGMgOlhdI7rP9M71Th2W7Z04ky2z4dSun47E8R/oNkB/ZSnin75um0gmwl?= =?us-ascii?Q?Nic4rxlOfpNwCBKXmVMwP65+etAzzWPMO+/XaBqJw3kDF6wFOS+Bnvxq6wfz?= =?us-ascii?Q?J3rVNA1dBCdBTusqqzGMOJE04Dv90TT6MdrOrL7bWGZSv7CDKVNVK6HWleIm?= =?us-ascii?Q?ggtN2SRhujwU/TFJ9C387jqVtFr+UotGnxXsi90ZNem1fKvcfKmUF42xVswB?= =?us-ascii?Q?RoaQQ95E5xgvLImBZjGtpYifYALVMATQjAhfgoBY3SibjQuZPd6iyAwUR2hh?= =?us-ascii?Q?7E5hGCsyv/sTEJ1QySAgNU6JWamzjxmsJA2rzcHWtNPtkClmkLJIVAagivqH?= =?us-ascii?Q?UGaMFKe6rsyA7mLnKNquU5gSHdlEr4bMtaOPzKL5GXKKvXSJaeBKIVSsLJGe?= =?us-ascii?Q?O0PC6xaw+InxJU0cu5EdGJj0mNXVq4EykuBgBOLKpYb/AOheoarj9r6cKANM?= =?us-ascii?Q?GTS+F9ZpX05Uky+5MFHPg1BB1dokSwmE+Me3W4bywAwA+eEBWcdF7XQYTbWh?= =?us-ascii?Q?OXHwb0KoIqmDnMtwQylviA+fOEWPl7eA2l5pKK+uh9df6U3FKH/93YgICiyP?= =?us-ascii?Q?mCxxyDMq5fJ+IFgzcFVg1YbUmUiIFbVhBdIhLOhHVwrJv9J+zCyzxqnz8snq?= =?us-ascii?Q?ftw2Pj7CSobHTHJvBsBgqC0DDttQG7UAB?=
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2080; 6:c3+hnKtgopwaNDtl0CN7MkIerBsHSEeIWqBA9nxsGyIfRLuzOmptTkkzK/HaJ7+/Nc1t+uYjQBT1MtAd1wJPYmoDIrvc0UdukobD0Rko0miiawPwH8SY3C6Lqf0BNZ9XIe6tyXl6H4td9S2Jjkxn2C9XrZsDDErZgYM6MCCATFzrB31+O/etdoulSi1Hbep0nhKo17xZOUNm+MLMPScA1ThaSjJ0cyLcnRuX5i1j1N7kYzqR0+O31J5kGriWVDfh3vYbJHxe7LYAFU7O/drl72Enx93v4ikzJGzK9hk2/A3xbO7eaZPD8ANPEZ59zIF4It86J4QWKv1tNpaO4eL9s2zswD1/jK1FxVw/kqWx1uM=; 5:51DBa7lMAwMAV+68Vo0SCf4YJsgZUcG4FI3uV0d6uMkPBKgVVBqV4sn5E9nt5jY/lXWyCKjdZSLI634pUHiguNKa1Rk8bNMcmKS1sgzRI5eaLf6JCe0HiaERrWeq5KvC9YZF4vu2fWyVfz64ghTb29+nvHhWfXqFAjfAwCYKa8Q=; 24:c5l4qN3rH7uDGGGzNNYJlqhNTRC32B+BdQyqQDF73sIUsmyW++25SitoN9xLaJeGRTHjC9M7u9yt1RgbBNubfHhsAeV/v+3CLODntSMf+SM=; 7:byDIQSpjEuSI50+xUERiCSzRCriHL4owYsHi2zfJMn9N4a4n2Mohs7hBwesNILBg2fFQDKuU8xw9L4ljjYn1p8vQosvruKaltto0bJ/DWQSU9X7I+N5+B0Cj4NjMAk0ThiQ9S7x2PrlVtHxnFYcIUIVu1wS3v6KLPa7WV0wyDy2qNX+90Ux+pntNSnTo8BhgCTiV6gPCTryixKJU5ydC4nAkbulOhJxjXYv5EaqpzgPG3UI2YWjywf+AgiEwIooJ
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2017 16:27:10.1658 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c8b85ec-073a-4c76-b20e-08d51c8e6850
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.12];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2080
Archived-At: 
Subject: Re: [netmod] XPath node type tests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 16:27:13 -0000

Andy Bierman writes:
>I think text() and node() are just filter tests.
>
>  /foo/*[text()] would return all the child nodes of /foo that are leaf o=
r
>leaf-list
>
>text() returns a boolean (0 or 1).  Do not use it for value testing:
>
>  /foo/*[text() =3D3D 'fred']  // wrong!
>
>  /foo/*[. =3D3D 'fred']  // correct

I haven't looked at the spec, but this isn't true for libxml2/libxslt/libs=
lax:

(sdb) n
4: var $foo :=3D  {  "one";  "two"; }
(sdb) n
2: main  { }
(sdb) p $foo
[node-set] (1) rtf-doc

  one
  two



(sdb) p $foo/*
[node-set] (1)

  one
  two


Outside predicates, it's a node test, matching text nodes:

(sdb) p $foo/*/text()
[node-set] (0)

(sdb) p $foo/*/*/text()
[node-set] (2)
one
two

But inside predicates is does return the text, probably like string():

(sdb) p $foo/*/*
[node-set] (2)
one
two

(sdb) p $foo/*[text() =3D=3D 'one']
[node-set] (0)

(sdb) p $foo/*/*[text() =3D=3D 'one']
[node-set] (1)
one

It could be just a bug in libxml2;  I'll take a look.

Thanks,
 Phil

P.s.: the command line I used was:

   slaxproc -d -m 'main  { }' -E -m 'var $foo :=3D  {  "one=
";  "two"; }'

The ":=3D" operator turns RTFs into node-sets (via calling node-set()).


From nobody Thu Oct 26 09:57:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B606013B1A9 for ; Thu, 26 Oct 2017 09:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 pc1YDOq6Pjwa for ; Thu, 26 Oct 2017 09:57:15 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0123.outbound.protection.outlook.com [104.47.2.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28FE139059 for ; Thu, 26 Oct 2017 09:57:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vJhU/9ovZSFTE6aLi1U0vAoi0j8MigiOqFZdxBkksOs=; b=KWw7Qw+4ocBeDBfL9xWE3CbeBiHZPihr689D1tvsX5E2T9T4c952Lq3kLHHsMNyxquHAep2uc/IjT7F23wHucr76Kp4epONei+K86g3axc6daErW5s6RCBIp5W+5QLIInnRZHd4HgmzKQN2DSHMvlMk9/FRHAEjJRT6LAY1mapk=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.169.153.236) by AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Thu, 26 Oct 2017 16:57:09 +0000
Message-ID: <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "Lou Berger" 
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net>
Date: Thu, 26 Oct 2017 17:50:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: VI1PR07CA0141.eurprd07.prod.outlook.com (2603:10a6:802:16::28) To AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e0519939-89f4-4f97-f8ca-08d51c929909
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM5PR0701MB2993; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:rRPNmymqsMYfLzPkggJGJyuAXIA9QXRDcILlVFbvhOHzlXRC4aqdGuZB2Rhi/CvQLlYM2aml670fmjr54cSCmK6ZUGMrWCzsmZGHZubhhscJKJurYJIGPTWJE2H9ZPWQwXaKDwLl1ViNpqgSr+cmruLiLvPxBLomu8mHgv138anLOfAvTzFs7pOAcX4n7Eg2mEHJqdKB0BlNvvf3wd+r6qsDihMcczIYsdDu3JwchFHZJwrF4ORnVosjtnclO13j; 25:57APduamL3gyYVWZlb6+iChX6GxPlqL6JHkgd3368vQK8kjkOKF+GsgEerD+TMEtprUfXjnYhvYqUfPzjNxN4ycr/fJVQEEGM3SPm7whBtHvKqgLhDSHckaABRKQDKTqBf37Iq9J1Q3/WX6sYf1Mng73RnJKn8DjUboFqVYnD9c+WeMDGvhtczW7fZpvDa+qsowF+wmRKcQw/kTZa67eW6C/G74Ltj/V/gTAs7Y8PadtljbL3SyDiOz6E093Y+mu2ulM4kpkzGRMwk3CzEc2ZIhFb28f+JKH6Sfwqm73GaPfNlQK5d+rQGczZ+E07zXmIdjcuFtkY7IqLvOechPlRQ==; 31:NFs8BwKkoy2ci5OJPraoBTuHuE/2tMuCRb9KOJuv5hjD6D1X3AL7MuVQgO6H7d6XfUg/h04E55+Ct7wPdNg0AStPKWZ1ZgZQ8OlY/8C1PVL5J2roYNluQfuFB/JqOny2NoYCsZSfPkK6MZKwDrOCBfUsHGrUZ6O4NK2jFQ+HvD/AkwfoOcA+eWjSkZ/aClnE/viHy48B3vzCRSREJYYjFshipgJpSFzuUi9wVtOGZMk=
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2993:
X-Exchange-Antispam-Report-Test: UriScan:(192374486261705);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231020)(10201501046)(61426038)(61427038)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2993; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 4:TN7WrLCGxjyG60H55U+MDuXPaEI6eaa2Dxlj4RuvHLifYta6SDWJm0nSBnsr0kUInIkYPvH6WnQ4Al8VLa1qL3sXD/5br2D0z7EmcOpq8u6Uhgt706zYMkcRbi5Z/7AroMzvp6iNyaxw9g/ZnaVlq0zIOq33CaKoCAt0LXmumkaPFGaTPIaIxCpuE+a6pWhIDyUsoPcJvB19G/Gh8NNDrSFhwQYh7EIUxTeWgeMgPxB5wn3FBiKa2yYKsH9rLecZMvQrIwCjiE7QdbnsK0D+Ag1JE4lo2dyh3Xc2UaxyA2C5Q+i8pLE2MOSgCL6VV+Yz
X-Forefront-PRVS: 04724A515E
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(377424004)(13464003)(24454002)(199003)(189002)(8676002)(230783001)(2906002)(116806002)(229853002)(33646002)(44736005)(7736002)(6486002)(16526018)(305945005)(106356001)(2870700001)(105586002)(6666003)(5660300001)(84392002)(61296003)(8936002)(81166006)(1556002)(6496005)(4720700003)(1456003)(189998001)(101416001)(81816999)(81686999)(316002)(86362001)(50226002)(110136005)(68736007)(62236002)(47776003)(66066001)(81156014)(44716002)(50986999)(478600001)(53546010)(76176999)(6246003)(53936002)(9686003)(97736004)(53946003)(25786009)(6116002)(4001150100001)(16200700003)(14496001)(23676002)(50466002)(3846002)(74416001)(7726001)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; 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?MTtBTTVQUjA3MDFNQjI5OTM7MjM6bEswS3psV0lIaGZrS2xmSTJnY2RYRm5Q?= =?utf-8?B?VDNJVUNOa2R5TTUzbUJTTGF2TWdLOC8ybUFwZWRxVkllbnpxcWxYVTVEejgy?= =?utf-8?B?MFFCRmUyNjJ6TTVMRWc5QkUrd0hBdlJaVkwrZkJWV0RUVGxVL3lkM244SW1u?= =?utf-8?B?eGs5dUJMS0VaZStyYURZTTZwTW5HVzNHNzhDenFmR3VHVkdraHJyUStHWUFP?= =?utf-8?B?ODluNHZNSzdRZzg3N3NiZmtDVEVNdjl6SW02b3VlcHBPTUUzZ2QyR3d4TnY0?= =?utf-8?B?VTlscUh3b3ZLL1lHL1h2YUsxKzJsOVo3c0RlSktSME5SMmlPNjBhaldVV0hw?= =?utf-8?B?b1lkRnNZQmgrUEprNWI0UjhlTFF5WWwwU1EyM0JoMkIyUDMwVEhzL210OWh4?= =?utf-8?B?dU8xcHZsY3ZjM2JUVFBZdnZORXVMYUxPZkNraVVWNkx5RjlTOWNWZE5sUFRJ?= =?utf-8?B?aW93Q3BDTTBTTFBIeUdFTVQ0OCt3S0ltaFpKbG1ramROUUNrRU1hMzZCNCtD?= =?utf-8?B?OXdMTHpja3ZXMjNQc2FwVGhWRy85N0U2U2l4cXpnT0VrVVR5a0xQQ2pEd0xS?= =?utf-8?B?QXMyM3ZuS2tTOFdqeU13ZlBIMldUWHJteEpWd2RwMjlGVlc5clVmeUpIYWdS?= =?utf-8?B?OGd1L0R6aXVrRkFSenROU1R5ajhBTDNYV2JucDlkWktHVmRrTGQ3azEzZWI2?= =?utf-8?B?MVBQTUw4Z1JQSDdXNjllNmNuTm1IYmpEOWo1ZFBvZ2lGWHZNTUsvTHdpNW91?= =?utf-8?B?c2ZXdVdYSzJKM0Izc0oxTk5iSDNzUDFNRkNJelFWTUdPSWE2VHc1bUpKNFhD?= =?utf-8?B?SkxET1o5RFh5T2J6YkR1TUZFclVucUE2Zmo3a2tGVGdxL1RhS1hqRUpwcHJ4?= =?utf-8?B?SjMxdVZCWEpjNGlRTlBzb0xWWGtNcVJLQWZ4VmdGc1lHMHg2VTUyZ1B5ck1H?= =?utf-8?B?bXlaSEduZkpJekFkODZ3OEd3K2NWZ2lWVlBqVzZRbHVES1NCQzBLb2wwcmV2?= =?utf-8?B?M3Z4Z0Urc1p3RGxrOUFWNjJxQ1orMGNZWWd6ZHQySHY5UEFYODJobkNGamJN?= =?utf-8?B?aTN1L0tYeHBSNVZrQ0FHeWdHbjdMTC9HbUlNTjZ6S2JDL1NyNG82eDJWNDBy?= =?utf-8?B?QUFZVnNURHBncEloYUh4ZEZVZUxqQmwwbnJuZTV5Y3NHYk1mWGYxcGdjOVh4?= =?utf-8?B?YTgyMGpvNnhwT1FvR3Z3aTdDQlhhYTdTY2swMTljeUZPUXV1NjFoOWpCSVRB?= =?utf-8?B?TXhWNk1CalZlVkxQaDdaQ3dXcXhtVFlnNGN5dGJXMUNzNWMrOXI5L2gvZll2?= =?utf-8?B?a0psRHgrdFEyRjlKbHBSVVV0SG9aUDU2SWdxUDJMNWEvQSsxQzZoeXBrTmtp?= =?utf-8?B?RTYzdzBYV09vbGRCVG9Lcnp1RlhlbjEvQmxDVi9Ea0R0NUM5ME4xV0FTRGxR?= =?utf-8?B?WlVUR1FVQjM2clRPR1E3Tm9SOWQ2MGwyaDU4OW9CeU5EUEo5amlZT2k0RVJ5?= =?utf-8?B?SXdxWWNYVWp5cGhJcUJYb2tETkhLM1ZNMmRPaWM4T3NPUUFBZ1dKR1dVZ09Y?= =?utf-8?B?cVp1R29wODl5L1VOK2RlL0lidHRmcnNYQ2RMN2hsUEEwZDBkWjVONlE5a01x?= =?utf-8?B?d2o4WlRORU5YUzVKT0djUjhDdk56R3VKQnA1TGJIQnQ5TXVJamZTRW5jNTJu?= =?utf-8?B?WXc4amU3WTdhU0h5MExrYmlEWHk2WWd2Tkx4TFJxbWV5d0t6SkhjTEpYa1J1?= =?utf-8?B?cE9CVTg3TUZLNzNDUnhRVWxqZHhhTVpEN2UvSjFsWDEyNDVRV1Q0aFRkcEVs?= =?utf-8?B?Zk1YeHh5MDFvbTFiVnJKeGVjQytSbDFvSXkrQzlFU3M2eHg1M0h3akM5ZmVG?= =?utf-8?B?dTlGd29YQ0hNcE84bnlMUlZscjlRaFAyR2VsRWJnTGlzbEZSWTFwN1IwSVlP?= =?utf-8?B?WFJtVnZ3dnFldUNhV1FrbkR2Y0pyT3FOUktwb0NQakl2elJ2UHMvVDRiNit3?= =?utf-8?B?QkxGT01XWldYZ1QxWU9xRGJFN3VVNFBXOVByQlk0b3I1ODdYWTBqeUVEVldD?= =?utf-8?B?M3J5WThtd2E5SFNtaEtvM05lZjVmNTFEa3VJRzdFR2FpQVJibW9hZytCY1Nx?= =?utf-8?B?VCtWUT09?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:qRAMl7bmVll+1ebPmiz/R1TnyG8FCJdki16vW3Wq67VTlrofUX2x04CSGtIyjH02Ft5JAMe7/Gg9+YQYNsLm9xfncT25NVReYXCXBKYwXx4foODIIFIm4TdCJinsdRVEAU7Jk65OCDdetnwj3eInBbDG/yiF0sMWJ+p9D5jj4/dCKczCD7Y/jVcKI5s1jXesvEVYqZkNYP7las1i1DNNTLONE+3l3/PwLp7aKA66E63JoW+TmLiRAGXsU6HEwzPE4LQupw1Scx1ZFtvAG3EHgcy7fVqbtYAIv/JoB0kESVP0VsKRl/GER1aHNKlED2alYopoajN85z/+sM/ZVzhW8++tav90UZl9AweDWsilYkY=; 5:uBFbAYRrbkXwmAU8LUuHDZiOZXGlXXnJqeZtb4jn55cirweygQJhcmLec4zb11l2/kGAbftIAoaj80HrzebAB3B6VS4ZNeeS1/gxA7tLBIwj1G5Jw3roT13duG9c5Em2SS34k6sKUgcVOd/AF9/h2h6U1k2NhlGmkUoqSqa8axE=; 24:soF3pGCak2bbUye+DaxXeegd5yjm5MxifpZJco2RWBdGt94HQuGSneEJrHwJVt2mT+IS/tFb3dTAW49N7l1CqJKG8Qv20XOowPbN7rE7670=; 7:oW0lZ40U0vz2b9469tUCJ+S+5xGi/49eA2ffy0Mx2E+y0429UjQANaDKbzu/kj5leXGptmsP5G6Gm9T4zw0g1dBrFoQ8iJfTiQpa30ZT+9H5r9wpzwJEy4MLSTqSVpXdD1xE9ND5wNkQZp60chAdgDhP7jdcAQ/PGKM1YBGUkd9tRznXw3oDpklv5xbm/6otU0BtI7Mb6OvTk/guyOIpocnn536lyjmyH31s95qMJr9gc9hgFbgAkJFYya3F5QCi
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2017 16:57:09.7101 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e0519939-89f4-4f97-f8ca-08d51c929909
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 16:57:31 -0000

Lou

I like the advice that diagrams should be one page long but wonder how
to apply that to those I see in routing WGs.  I have just been looking
at

 draft-ietf-teas-yang-te-topo-12

where the diagram is 36 pages long - which may be one of the larger ones
but by no means exceptional - and I think the diagram is  more or less
useless as a result.  But what practical advice can we give them?

I append the diagram below

Tom Petch


start of diagram
==================================================


Liu, et al             Expires January 17, 2018               [Page 31]


6. Tree Structure

   module: ietf-te-topology
   augment /nw:networks/nw:network/nw:network-types:
      +--rw te-topology!
   augment /nw:networks:
      +--rw te!
         +--rw templates
            +--rw node-template* [name] {template}?
            |  +--rw name                       te-types:te-template-
   name
            |  +--rw priority?                  uint16
            |  +--rw reference-change-policy?   enumeration
            |  +--rw te-node-attributes
            |     +--rw admin-status?        te-types:te-admin-status
            |     +--rw domain-id?           uint32
            |     +--rw is-abstract?         empty
            |     +--rw name?                inet:domain-name
            |     +--rw signaling-address*   inet:ip-address
            |     +--rw underlay-topology {te-topology-hierarchy}?
            |        +--rw network-ref?   leafref
            +--rw link-template* [name] {template}?
               +--rw name                       te-types:te-template-
   name
               +--rw priority?                  uint16
               +--rw reference-change-policy?   enumeration
               +--rw te-link-attributes
                  +--rw access-type?                      te-types:te-
   link-access-type
                  +--rw external-domain
                  |  +--rw network-ref?            leafref
                  |  +--rw remote-te-node-id?      te-types:te-node-id
                  |  +--rw remote-te-link-tp-id?   te-types:te-tp-id
                  |  +--rw plug-id?                uint32
                  +--rw is-abstract?                      empty
                  +--rw name?                             string
                  +--rw underlay {te-topology-hierarchy}?
                  |  +--rw enabled?                     boolean
                  |  +--rw primary-path
                  |  |  +--rw network-ref?    leafref
                  |  |  +--rw path-element* [path-element-id]
                  |  |     +--rw path-element-id    uint32
                  |  |     +--rw index?             uint32



                  |  |     +--rw (type)?
                  |  |        +--:(numbered)
                  |  |        |  +--rw numbered-hop
                  |  |        |     +--rw address?    te-types:te-tp-id
                  |  |        |     +--rw hop-type?   te-hop-type
                  |  |        +--:(as-number)
                  |  |        |  +--rw as-number-hop
                  |  |        |     +--rw as-number?   binary
                  |  |        |     +--rw hop-type?    te-hop-type
                  |  |        +--:(unnumbered)
                  |  |        |  +--rw unnumbered-hop
                  |  |        |     +--rw node-id?      te-types:te-
   node-id
                  |  |        |     +--rw link-tp-id?   te-types:te-tp-
   id
                  |  |        |     +--rw hop-type?     te-hop-type
                  |  |        +--:(label)
                  |  |        |  +--rw label-hop
                  |  |        |     +--rw value?   rt-types:generalized-
   label
                  |  |        +--:(sid)
                  |  |           +--rw sid-hop
                  |  |              +--rw sid?   rt-types:generalized-
   label
                  |  +--rw backup-path* [index]
                  |  |  +--rw index           uint32
                  |  |  +--rw network-ref?    leafref
                  |  |  +--rw path-element* [path-element-id]
                  |  |     +--rw path-element-id    uint32
                  |  |     +--rw index?             uint32
                  |  |     +--rw (type)?
                  |  |        +--:(numbered)
                  |  |        |  +--rw numbered-hop
                  |  |        |     +--rw address?    te-types:te-tp-id
                  |  |        |     +--rw hop-type?   te-hop-type
                  |  |        +--:(as-number)
                  |  |        |  +--rw as-number-hop
                  |  |        |     +--rw as-number?   binary
                  |  |        |     +--rw hop-type?    te-hop-type
                  |  |        +--:(unnumbered)
                  |  |        |  +--rw unnumbered-hop
                  |  |        |     +--rw node-id?      te-types:te-
   node-id
                  |  |        |     +--rw link-tp-id?   te-types:te-tp-
   id
                  |  |        |     +--rw hop-type?     te-hop-type
                  |  |        +--:(label)


                  |  |        |  +--rw label-hop
                  |  |        |     +--rw value?   rt-types:generalized-
   label
                  |  |        +--:(sid)
                  |  |           +--rw sid-hop
                  |  |              +--rw sid?   rt-types:generalized-
   label
                  |  +--rw protection-type?             identityref
                  |  +--rw tunnel-termination-points
                  |  |  +--rw source?        binary
                  |  |  +--rw destination?   binary
                  |  +--rw tunnels
                  |     +--rw sharing?   boolean
                  |     +--rw tunnel* [tunnel-name]
                  |        +--rw tunnel-name    string
                  |        +--rw sharing?       boolean
                  +--rw admin-status?                     te-types:te-
   admin-status
                  +--rw link-index?                       uint64
                  +--rw administrative-group?             te-
   types:admin-groups
                  +--rw interface-switching-capability* [switching-
   capability encoding]
                  |  +--rw switching-capability    identityref
                  |  +--rw encoding                identityref
                  |  +--rw max-lsp-bandwidth* [priority]
                  |     +--rw priority     uint8
                  |     +--rw bandwidth
                  |        +--rw te-bandwidth
                  |           +--rw (technology)?
                  |              +--:(psc)
                  |              |  +--rw psc?       rt-types:bandwidth-
   ieee-float32
                  |              +--:(otn)
                  |              |  +--rw otn* [rate-type]
                  |              |     +--rw rate-type    identityref
                  |              |     +--rw counter?     uint16
                  |              +--:(lsc)
                  |              |  +--rw wdm* [spectrum slot]
                  |              |     +--rw spectrum    identityref
                  |              |     +--rw slot        int16
                  |              |     +--rw width?      uint16
                  |              +--:(generic)
                  |                 +--rw generic?   te-bandwidth
                  +--rw label-restriction* [inclusive-exclusive label-
   start]
                  |  +--rw inclusive-exclusive    enumeration



                  |  +--rw label-start            rt-types:generalized-
   label
                  |  +--rw label-end?             rt-types:generalized-
   label
                  |  +--rw range-bitmap?          binary
                  +--rw link-protection-type?             enumeration
                  +--rw max-link-bandwidth
                  |  +--rw te-bandwidth
                  |     +--rw (technology)?
                  |        +--:(psc)
                  |        |  +--rw psc?       rt-types:bandwidth-ieee-
   float32
                  |        +--:(otn)
                  |        |  +--rw otn* [rate-type]
                  |        |     +--rw rate-type    identityref
                  |        |     +--rw counter?     uint16
                  |        +--:(lsc)
                  |        |  +--rw wdm* [spectrum slot]
                  |        |     +--rw spectrum    identityref
                  |        |     +--rw slot        int16
                  |        |     +--rw width?      uint16
                  |        +--:(generic)
                  |           +--rw generic?   te-bandwidth
                  +--rw max-resv-link-bandwidth
                  |  +--rw te-bandwidth
                  |     +--rw (technology)?
                  |        +--:(psc)
                  |        |  +--rw psc?       rt-types:bandwidth-ieee-
   float32
                  |        +--:(otn)
                  |        |  +--rw otn* [rate-type]
                  |        |     +--rw rate-type    identityref
                  |        |     +--rw counter?     uint16
                  |        +--:(lsc)
                  |        |  +--rw wdm* [spectrum slot]
                  |        |     +--rw spectrum    identityref
                  |        |     +--rw slot        int16
                  |        |     +--rw width?      uint16
                  |        +--:(generic)
                  |           +--rw generic?   te-bandwidth
                  +--rw unreserved-bandwidth* [priority]
                  |  +--rw priority     uint8
                  |  +--rw bandwidth
                  |     +--rw te-bandwidth
                  |        +--rw (technology)?
                  |           +--:(psc)



                  |           |  +--rw psc?       rt-types:bandwidth-
   ieee-float32
                  |           +--:(otn)
                  |           |  +--rw otn* [rate-type]
                  |           |     +--rw rate-type    identityref
                  |           |     +--rw counter?     uint16
                  |           +--:(lsc)
                  |           |  +--rw wdm* [spectrum slot]
                  |           |     +--rw spectrum    identityref
                  |           |     +--rw slot        int16
                  |           |     +--rw width?      uint16
                  |           +--:(generic)
                  |              +--rw generic?   te-bandwidth
                  +--rw te-default-metric?                uint32
                  +--rw te-delay-metric?                  uint32
                  +--rw te-igp-metric?                    uint32
                  +--rw te-srlgs
                  |  +--rw value*   te-types:srlg
                  +--rw te-nsrlgs {nsrlg}?
                     +--rw id*   uint32
   augment /nw:networks/nw:network:
      +--rw provider-id?      te-types:te-global-id
      +--rw client-id?        te-types:te-global-id
      +--rw te-topology-id?   te-types:te-topology-id
      +--rw te!
         +--rw preference?               uint8
         +--rw optimization-criterion?   identityref
         +--rw nsrlg* [id] {nsrlg}?
         |  +--rw id              uint32
         |  +--rw disjointness?   te-types:te-path-disjointness
         +--ro geolocation
            +--ro altitude?    int64
            +--ro latitude?    geographic-coordinate-degree
            +--ro longitude?   geographic-coordinate-degree
   augment /nw:networks/nw:network/nw:node:
      +--rw te-node-id?   te-types:te-node-id
      +--rw te!
         +--rw te-node-template*           leafref {template}?
         +--rw te-node-attributes
         |  +--rw admin-status?            te-types:te-admin-status
         |  +--rw connectivity-matrices
         |  |  +--rw number-of-entries?          uint16
         |  |  +--rw label-restriction* [inclusive-exclusive label-
   start]
         |  |  |  +--rw inclusive-exclusive    enumeration
         |  |  |  +--rw label-start            rt-types:generalized-
   label



         |  |  |  +--rw label-end?             rt-types:generalized-
   label
         |  |  |  +--rw range-bitmap?          binary
         |  |  +--rw is-allowed?                 boolean
         |  |  +--rw underlay {te-topology-hierarchy}?
         |  |  |  +--rw enabled?                     boolean
         |  |  |  +--rw primary-path
         |  |  |  |  +--rw network-ref?    leafref
         |  |  |  |  +--rw path-element* [path-element-id]
         |  |  |  |     +--rw path-element-id    uint32
         |  |  |  |     +--rw index?             uint32
         |  |  |  |     +--rw (type)?
         |  |  |  |        +--:(numbered)
         |  |  |  |        |  +--rw numbered-hop
         |  |  |  |        |     +--rw address?    te-types:te-tp-id
         |  |  |  |        |     +--rw hop-type?   te-hop-type
         |  |  |  |        +--:(as-number)
         |  |  |  |        |  +--rw as-number-hop
         |  |  |  |        |     +--rw as-number?   binary
         |  |  |  |        |     +--rw hop-type?    te-hop-type
         |  |  |  |        +--:(unnumbered)
         |  |  |  |        |  +--rw unnumbered-hop
         |  |  |  |        |     +--rw node-id?      te-types:te-node-id
         |  |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
         |  |  |  |        |     +--rw hop-type?     te-hop-type
         |  |  |  |        +--:(label)
         |  |  |  |        |  +--rw label-hop
         |  |  |  |        |     +--rw value?   rt-types:generalized-
   label
         |  |  |  |        +--:(sid)
         |  |  |  |           +--rw sid-hop
         |  |  |  |              +--rw sid?   rt-types:generalized-label
         |  |  |  +--rw backup-path* [index]
         |  |  |  |  +--rw index           uint32
         |  |  |  |  +--rw network-ref?    leafref
         |  |  |  |  +--rw path-element* [path-element-id]
         |  |  |  |     +--rw path-element-id    uint32
         |  |  |  |     +--rw index?             uint32
         |  |  |  |     +--rw (type)?
         |  |  |  |        +--:(numbered)
         |  |  |  |        |  +--rw numbered-hop
         |  |  |  |        |     +--rw address?    te-types:te-tp-id
         |  |  |  |        |     +--rw hop-type?   te-hop-type
         |  |  |  |        +--:(as-number)
         |  |  |  |        |  +--rw as-number-hop
         |  |  |  |        |     +--rw as-number?   binary
         |  |  |  |        |     +--rw hop-type?    te-hop-type


         |  |  |  |        +--:(unnumbered)
         |  |  |  |        |  +--rw unnumbered-hop
         |  |  |  |        |     +--rw node-id?      te-types:te-node-id
         |  |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
         |  |  |  |        |     +--rw hop-type?     te-hop-type
         |  |  |  |        +--:(label)
         |  |  |  |        |  +--rw label-hop
         |  |  |  |        |     +--rw value?   rt-types:generalized-
   label
         |  |  |  |        +--:(sid)
         |  |  |  |           +--rw sid-hop
         |  |  |  |              +--rw sid?   rt-types:generalized-label
         |  |  |  +--rw protection-type?             identityref
         |  |  |  +--rw tunnel-termination-points
         |  |  |  |  +--rw source?        binary
         |  |  |  |  +--rw destination?   binary
         |  |  |  +--rw tunnels
         |  |  |     +--rw sharing?   boolean
         |  |  |     +--rw tunnel* [tunnel-name]
         |  |  |        +--rw tunnel-name    string
         |  |  |        +--rw sharing?       boolean
         |  |  +--rw path-constraints
         |  |  |  +--rw path-metric-bound* [metric-type]
         |  |  |  |  +--rw metric-type    identityref
         |  |  |  |  +--rw upper-bound?   uint64
         |  |  |  +--rw topology-id?         te-types:te-topology-id
         |  |  |  +--rw ignore-overload?     boolean
         |  |  |  +--rw bandwidth-generic
         |  |  |  |  +--rw te-bandwidth
         |  |  |  |     +--rw (technology)?
         |  |  |  |        +--:(psc)
         |  |  |  |        |  +--rw psc?       rt-types:bandwidth-ieee-
   float32
         |  |  |  |        +--:(otn)
         |  |  |  |        |  +--rw otn* [rate-type]
         |  |  |  |        |     +--rw rate-type    identityref
         |  |  |  |        |     +--rw counter?     uint16
         |  |  |  |        +--:(lsc)
         |  |  |  |        |  +--rw wdm* [spectrum slot]
         |  |  |  |        |     +--rw spectrum    identityref
         |  |  |  |        |     +--rw slot        int16
         |  |  |  |        |     +--rw width?      uint16
         |  |  |  |        +--:(generic)
         |  |  |  |           +--rw generic?   te-bandwidth
         |  |  |  +--rw disjointness?        te-types:te-path-
   disjointness
         |  |  |  +--rw setup-priority?      uint8


         |  |  |  +--rw hold-priority?       uint8
         |  |  |  +--rw signaling-type?      identityref
         |  |  |  +--rw path-affinities
         |  |  |  |  +--rw constraint* [usage]
         |  |  |  |     +--rw usage    identityref
         |  |  |  |     +--rw value?   admin-groups
         |  |  |  +--rw path-srlgs
         |  |  |     +--rw usage?    identityref
         |  |  |     +--rw values*   srlg
         |  |  +--rw optimizations
         |  |  |  +--rw (algorithm)?
         |  |  |     +--:(metric) {path-optimization-metric}?
         |  |  |     |  +--rw optimization-metric* [metric-type]
         |  |  |     |  |  +--rw metric-type    identityref
         |  |  |     |  |  +--rw weight?        uint8
         |  |  |     |  +--rw tiebreakers
         |  |  |     |     +--rw tiebreaker* [tiebreaker-type]
         |  |  |     |        +--rw tiebreaker-type    identityref
         |  |  |     +--:(objective-function) {path-optimization-
   objective-function}?
         |  |  |        +--rw objective-function
         |  |  |           +--rw objective-function-type?   identityref
         |  |  +--ro computed-path-properties
         |  |  |  +--ro path-metric* [metric-type]
         |  |  |  |  +--ro metric-type           identityref
         |  |  |  |  +--ro accumulative-value?   uint64
         |  |  |  +--ro path-affinities
         |  |  |  |  +--ro constraint* [usage]
         |  |  |  |     +--ro usage    identityref
         |  |  |  |     +--ro value?   admin-groups
         |  |  |  +--ro path-srlgs
         |  |  |  |  +--ro usage?    identityref
         |  |  |  |  +--ro values*   srlg
         |  |  |  +--ro path-computed-route-objects
         |  |  |     +--ro path-computed-route-object* [index]
         |  |  |        +--ro index             uint32
         |  |  |        +--ro (type)?
         |  |  |           +--:(numbered)
         |  |  |           |  +--ro numbered-hop
         |  |  |           |     +--ro address?    te-types:te-tp-id
         |  |  |           |     +--ro hop-type?   te-hop-type
         |  |  |           +--:(as-number)
         |  |  |           |  +--ro as-number-hop
         |  |  |           |     +--ro as-number?   binary
         |  |  |           |     +--ro hop-type?    te-hop-type
         |  |  |           +--:(unnumbered)
         |  |  |           |  +--ro unnumbered-hop




         |  |  |           |     +--ro node-id?      te-types:te-node-id
         |  |  |           |     +--ro link-tp-id?   te-types:te-tp-id
         |  |  |           |     +--ro hop-type?     te-hop-type
         |  |  |           +--:(label)
         |  |  |           |  +--ro label-hop
         |  |  |           |     +--ro value?   rt-types:generalized-
   label
         |  |  |           +--:(sid)
         |  |  |              +--ro sid-hop
         |  |  |                 +--ro sid?   rt-types:generalized-label
         |  |  +--rw connectivity-matrix* [id]
         |  |     +--rw id                          uint32
         |  |     +--rw from
         |  |     |  +--rw tp-ref?              leafref
         |  |     |  +--rw label-restriction* [inclusive-exclusive
   label-start]
         |  |     |     +--rw inclusive-exclusive    enumeration
         |  |     |     +--rw label-start            rt-
   types:generalized-label
         |  |     |     +--rw label-end?             rt-
   types:generalized-label
         |  |     |     +--rw range-bitmap?          binary
         |  |     +--rw to
         |  |     |  +--rw tp-ref?              leafref
         |  |     |  +--rw label-restriction* [inclusive-exclusive
   label-start]
         |  |     |     +--rw inclusive-exclusive    enumeration
         |  |     |     +--rw label-start            rt-
   types:generalized-label
         |  |     |     +--rw label-end?             rt-
   types:generalized-label
         |  |     |     +--rw range-bitmap?          binary
         |  |     +--rw is-allowed?                 boolean
         |  |     +--rw underlay {te-topology-hierarchy}?
         |  |     |  +--rw enabled?                     boolean
         |  |     |  +--rw primary-path
         |  |     |  |  +--rw network-ref?    leafref
         |  |     |  |  +--rw path-element* [path-element-id]
         |  |     |  |     +--rw path-element-id    uint32
         |  |     |  |     +--rw index?             uint32
         |  |     |  |     +--rw (type)?
         |  |     |  |        +--:(numbered)
         |  |     |  |        |  +--rw numbered-hop
         |  |     |  |        |     +--rw address?    te-types:te-tp-id
         |  |     |  |        |     +--rw hop-type?   te-hop-type
         |  |     |  |        +--:(as-number)
         |  |     |  |        |  +--rw as-number-hop




         |  |     |  |        |     +--rw as-number?   binary
         |  |     |  |        |     +--rw hop-type?    te-hop-type
         |  |     |  |        +--:(unnumbered)
         |  |     |  |        |  +--rw unnumbered-hop
         |  |     |  |        |     +--rw node-id?      te-types:te-
   node-id
         |  |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
   id
         |  |     |  |        |     +--rw hop-type?     te-hop-type
         |  |     |  |        +--:(label)
         |  |     |  |        |  +--rw label-hop
         |  |     |  |        |     +--rw value?   rt-types:generalized-
   label
         |  |     |  |        +--:(sid)
         |  |     |  |           +--rw sid-hop
         |  |     |  |              +--rw sid?   rt-types:generalized-
   label
         |  |     |  +--rw backup-path* [index]
         |  |     |  |  +--rw index           uint32
         |  |     |  |  +--rw network-ref?    leafref
         |  |     |  |  +--rw path-element* [path-element-id]
         |  |     |  |     +--rw path-element-id    uint32
         |  |     |  |     +--rw index?             uint32
         |  |     |  |     +--rw (type)?
         |  |     |  |        +--:(numbered)
         |  |     |  |        |  +--rw numbered-hop
         |  |     |  |        |     +--rw address?    te-types:te-tp-id
         |  |     |  |        |     +--rw hop-type?   te-hop-type
         |  |     |  |        +--:(as-number)
         |  |     |  |        |  +--rw as-number-hop
         |  |     |  |        |     +--rw as-number?   binary
         |  |     |  |        |     +--rw hop-type?    te-hop-type
         |  |     |  |        +--:(unnumbered)
         |  |     |  |        |  +--rw unnumbered-hop
         |  |     |  |        |     +--rw node-id?      te-types:te-
   node-id
         |  |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
   id
         |  |     |  |        |     +--rw hop-type?     te-hop-type
         |  |     |  |        +--:(label)
         |  |     |  |        |  +--rw label-hop
         |  |     |  |        |     +--rw value?   rt-types:generalized-
   label
         |  |     |  |        +--:(sid)
         |  |     |  |           +--rw sid-hop
         |  |     |  |              +--rw sid?   rt-types:generalized-
   label


         |  |     |  +--rw protection-type?             identityref
         |  |     |  +--rw tunnel-termination-points
         |  |     |  |  +--rw source?        binary
         |  |     |  |  +--rw destination?   binary
         |  |     |  +--rw tunnels
         |  |     |     +--rw sharing?   boolean
         |  |     |     +--rw tunnel* [tunnel-name]
         |  |     |        +--rw tunnel-name    string
         |  |     |        +--rw sharing?       boolean
         |  |     +--rw path-constraints
         |  |     |  +--rw path-metric-bound* [metric-type]
         |  |     |  |  +--rw metric-type    identityref
         |  |     |  |  +--rw upper-bound?   uint64
         |  |     |  +--rw topology-id?         te-types:te-topology-id
         |  |     |  +--rw ignore-overload?     boolean
         |  |     |  +--rw bandwidth-generic
         |  |     |  |  +--rw te-bandwidth
         |  |     |  |     +--rw (technology)?
         |  |     |  |        +--:(psc)
         |  |     |  |        |  +--rw psc?       rt-types:bandwidth-
   ieee-float32
         |  |     |  |        +--:(otn)
         |  |     |  |        |  +--rw otn* [rate-type]
         |  |     |  |        |     +--rw rate-type    identityref
         |  |     |  |        |     +--rw counter?     uint16
         |  |     |  |        +--:(lsc)
         |  |     |  |        |  +--rw wdm* [spectrum slot]
         |  |     |  |        |     +--rw spectrum    identityref
         |  |     |  |        |     +--rw slot        int16
         |  |     |  |        |     +--rw width?      uint16
         |  |     |  |        +--:(generic)
         |  |     |  |           +--rw generic?   te-bandwidth
         |  |     |  +--rw disjointness?        te-types:te-path-
   disjointness
         |  |     |  +--rw setup-priority?      uint8
         |  |     |  +--rw hold-priority?       uint8
         |  |     |  +--rw signaling-type?      identityref
         |  |     |  +--rw path-affinities
         |  |     |  |  +--rw constraint* [usage]
         |  |     |  |     +--rw usage    identityref
         |  |     |  |     +--rw value?   admin-groups
         |  |     |  +--rw path-srlgs
         |  |     |     +--rw usage?    identityref
         |  |     |     +--rw values*   srlg
         |  |     +--rw optimizations
         |  |     |  +--rw (algorithm)?
         |  |     |     +--:(metric) {path-optimization-metric}?


         |  |     |     |  +--rw optimization-metric* [metric-type]
         |  |     |     |  |  +--rw metric-type    identityref
         |  |     |     |  |  +--rw weight?        uint8
         |  |     |     |  +--rw tiebreakers
         |  |     |     |     +--rw tiebreaker* [tiebreaker-type]
         |  |     |     |        +--rw tiebreaker-type    identityref
         |  |     |     +--:(objective-function) {path-optimization-
   objective-function}?
         |  |     |        +--rw objective-function
         |  |     |           +--rw objective-function-type?
   identityref
         |  |     +--ro computed-path-properties
         |  |        +--ro path-metric* [metric-type]
         |  |        |  +--ro metric-type           identityref
         |  |        |  +--ro accumulative-value?   uint64
         |  |        +--ro path-affinities
         |  |        |  +--ro constraint* [usage]
         |  |        |     +--ro usage    identityref
         |  |        |     +--ro value?   admin-groups
         |  |        +--ro path-srlgs
         |  |        |  +--ro usage?    identityref
         |  |        |  +--ro values*   srlg
         |  |        +--ro path-computed-route-objects
         |  |           +--ro path-computed-route-object* [index]
         |  |              +--ro index             uint32
         |  |              +--ro (type)?
         |  |                 +--:(numbered)
         |  |                 |  +--ro numbered-hop
         |  |                 |     +--ro address?    te-types:te-tp-id
         |  |                 |     +--ro hop-type?   te-hop-type
         |  |                 +--:(as-number)
         |  |                 |  +--ro as-number-hop
         |  |                 |     +--ro as-number?   binary
         |  |                 |     +--ro hop-type?    te-hop-type
         |  |                 +--:(unnumbered)
         |  |                 |  +--ro unnumbered-hop
         |  |                 |     +--ro node-id?      te-types:te-
   node-id
         |  |                 |     +--ro link-tp-id?   te-types:te-tp-
   id
         |  |                 |     +--ro hop-type?     te-hop-type
         |  |                 +--:(label)
         |  |                 |  +--ro label-hop
         |  |                 |     +--ro value?   rt-types:generalized-
   label
         |  |                 +--:(sid)
         |  |                    +--ro sid-hop

         |  |                       +--ro sid?   rt-types:generalized-
   label
         |  +--rw domain-id?               uint32
         |  +--rw is-abstract?             empty
         |  +--rw name?                    inet:domain-name
         |  +--rw signaling-address*       inet:ip-address
         |  +--rw underlay-topology {te-topology-hierarchy}?
         |     +--rw network-ref?   leafref
         +--ro oper-status?                te-types:te-oper-status
         +--ro geolocation
         |  +--ro altitude?    int64
         |  +--ro latitude?    geographic-coordinate-degree
         |  +--ro longitude?   geographic-coordinate-degree
         +--ro is-multi-access-dr?         empty
         +--ro information-source?         te-info-source
         +--ro information-source-state
         |  +--ro credibility-preference?    uint16
         |  +--ro logical-network-element?   string
         |  +--ro network-instance?          string
         |  +--ro topology
         |     +--ro node-ref?      leafref
         |     +--ro network-ref?   leafref
         +--ro information-source-entry* [information-source]
         |  +--ro information-source          te-info-source
         |  +--ro information-source-state
         |  |  +--ro credibility-preference?    uint16
         |  |  +--ro logical-network-element?   string
         |  |  +--ro network-instance?          string
         |  |  +--ro topology
         |  |     +--ro node-ref?      leafref
         |  |     +--ro network-ref?   leafref
         |  +--ro connectivity-matrices
         |  |  +--ro number-of-entries?          uint16
         |  |  +--ro label-restriction* [inclusive-exclusive label-
   start]
         |  |  |  +--ro inclusive-exclusive    enumeration
         |  |  |  +--ro label-start            rt-types:generalized-
   label
         |  |  |  +--ro label-end?             rt-types:generalized-
   label
         |  |  |  +--ro range-bitmap?          binary
         |  |  +--ro is-allowed?                 boolean
         |  |  +--ro underlay {te-topology-hierarchy}?
         |  |  |  +--ro enabled?                     boolean
         |  |  |  +--ro primary-path
         |  |  |  |  +--ro network-ref?    leafref
         |  |  |  |  +--ro path-element* [path-element-id]


         |  |  |  |     +--ro path-element-id    uint32
         |  |  |  |     +--ro index?             uint32
         |  |  |  |     +--ro (type)?
         |  |  |  |        +--:(numbered)
         |  |  |  |        |  +--ro numbered-hop
         |  |  |  |        |     +--ro address?    te-types:te-tp-id
         |  |  |  |        |     +--ro hop-type?   te-hop-type
         |  |  |  |        +--:(as-number)
         |  |  |  |        |  +--ro as-number-hop
         |  |  |  |        |     +--ro as-number?   binary
         |  |  |  |        |     +--ro hop-type?    te-hop-type
         |  |  |  |        +--:(unnumbered)
         |  |  |  |        |  +--ro unnumbered-hop
         |  |  |  |        |     +--ro node-id?      te-types:te-node-id
         |  |  |  |        |     +--ro link-tp-id?   te-types:te-tp-id
         |  |  |  |        |     +--ro hop-type?     te-hop-type
         |  |  |  |        +--:(label)
         |  |  |  |        |  +--ro label-hop
         |  |  |  |        |     +--ro value?   rt-types:generalized-
   label
         |  |  |  |        +--:(sid)
         |  |  |  |           +--ro sid-hop
         |  |  |  |              +--ro sid?   rt-types:generalized-label
         |  |  |  +--ro backup-path* [index]
         |  |  |  |  +--ro index           uint32
         |  |  |  |  +--ro network-ref?    leafref
         |  |  |  |  +--ro path-element* [path-element-id]
         |  |  |  |     +--ro path-element-id    uint32
         |  |  |  |     +--ro index?             uint32
         |  |  |  |     +--ro (type)?
         |  |  |  |        +--:(numbered)
         |  |  |  |        |  +--ro numbered-hop
         |  |  |  |        |     +--ro address?    te-types:te-tp-id
         |  |  |  |        |     +--ro hop-type?   te-hop-type
         |  |  |  |        +--:(as-number)
         |  |  |  |        |  +--ro as-number-hop
         |  |  |  |        |     +--ro as-number?   binary
         |  |  |  |        |     +--ro hop-type?    te-hop-type
         |  |  |  |        +--:(unnumbered)
         |  |  |  |        |  +--ro unnumbered-hop
         |  |  |  |        |     +--ro node-id?      te-types:te-node-id
         |  |  |  |        |     +--ro link-tp-id?   te-types:te-tp-id
         |  |  |  |        |     +--ro hop-type?     te-hop-type
         |  |  |  |        +--:(label)
         |  |  |  |        |  +--ro label-hop
         |  |  |  |        |     +--ro value?   rt-types:generalized-
   label


         |  |  |  |        +--:(sid)
         |  |  |  |           +--ro sid-hop
         |  |  |  |              +--ro sid?   rt-types:generalized-label
         |  |  |  +--ro protection-type?             identityref
         |  |  |  +--ro tunnel-termination-points
         |  |  |  |  +--ro source?        binary
         |  |  |  |  +--ro destination?   binary
         |  |  |  +--ro tunnels
         |  |  |     +--ro sharing?   boolean
         |  |  |     +--ro tunnel* [tunnel-name]
         |  |  |        +--ro tunnel-name    string
         |  |  |        +--ro sharing?       boolean
         |  |  +--ro path-constraints
         |  |  |  +--ro path-metric-bound* [metric-type]
         |  |  |  |  +--ro metric-type    identityref
         |  |  |  |  +--ro upper-bound?   uint64
         |  |  |  +--ro topology-id?         te-types:te-topology-id
         |  |  |  +--ro ignore-overload?     boolean
         |  |  |  +--ro bandwidth-generic
         |  |  |  |  +--ro te-bandwidth
         |  |  |  |     +--ro (technology)?
         |  |  |  |        +--:(psc)
         |  |  |  |        |  +--ro psc?       rt-types:bandwidth-ieee-
   float32
         |  |  |  |        +--:(otn)
         |  |  |  |        |  +--ro otn* [rate-type]
         |  |  |  |        |     +--ro rate-type    identityref
         |  |  |  |        |     +--ro counter?     uint16
         |  |  |  |        +--:(lsc)
         |  |  |  |        |  +--ro wdm* [spectrum slot]
         |  |  |  |        |     +--ro spectrum    identityref
         |  |  |  |        |     +--ro slot        int16
         |  |  |  |        |     +--ro width?      uint16
         |  |  |  |        +--:(generic)
         |  |  |  |           +--ro generic?   te-bandwidth
         |  |  |  +--ro disjointness?        te-types:te-path-
   disjointness
         |  |  |  +--ro setup-priority?      uint8
         |  |  |  +--ro hold-priority?       uint8
         |  |  |  +--ro signaling-type?      identityref
         |  |  |  +--ro path-affinities
         |  |  |  |  +--ro constraint* [usage]
         |  |  |  |     +--ro usage    identityref
         |  |  |  |     +--ro value?   admin-groups
         |  |  |  +--ro path-srlgs
         |  |  |     +--ro usage?    identityref
         |  |  |     +--ro values*   srlg


         |  |  +--ro optimizations
         |  |  |  +--ro (algorithm)?
         |  |  |     +--:(metric) {path-optimization-metric}?
         |  |  |     |  +--ro optimization-metric* [metric-type]
         |  |  |     |  |  +--ro metric-type    identityref
         |  |  |     |  |  +--ro weight?        uint8
         |  |  |     |  +--ro tiebreakers
         |  |  |     |     +--ro tiebreaker* [tiebreaker-type]
         |  |  |     |        +--ro tiebreaker-type    identityref
         |  |  |     +--:(objective-function) {path-optimization-
   objective-function}?
         |  |  |        +--ro objective-function
         |  |  |           +--ro objective-function-type?   identityref
         |  |  +--ro computed-path-properties
         |  |  |  +--ro path-metric* [metric-type]
         |  |  |  |  +--ro metric-type           identityref
         |  |  |  |  +--ro accumulative-value?   uint64
         |  |  |  +--ro path-affinities
         |  |  |  |  +--ro constraint* [usage]
         |  |  |  |     +--ro usage    identityref
         |  |  |  |     +--ro value?   admin-groups
         |  |  |  +--ro path-srlgs
         |  |  |  |  +--ro usage?    identityref
         |  |  |  |  +--ro values*   srlg
         |  |  |  +--ro path-computed-route-objects
         |  |  |     +--ro path-computed-route-object* [index]
         |  |  |        +--ro index             uint32
         |  |  |        +--ro (type)?
         |  |  |           +--:(numbered)
         |  |  |           |  +--ro numbered-hop
         |  |  |           |     +--ro address?    te-types:te-tp-id
         |  |  |           |     +--ro hop-type?   te-hop-type
         |  |  |           +--:(as-number)
         |  |  |           |  +--ro as-number-hop
         |  |  |           |     +--ro as-number?   binary
         |  |  |           |     +--ro hop-type?    te-hop-type
         |  |  |           +--:(unnumbered)
         |  |  |           |  +--ro unnumbered-hop
         |  |  |           |     +--ro node-id?      te-types:te-node-id
         |  |  |           |     +--ro link-tp-id?   te-types:te-tp-id
         |  |  |           |     +--ro hop-type?     te-hop-type
         |  |  |           +--:(label)
         |  |  |           |  +--ro label-hop
         |  |  |           |     +--ro value?   rt-types:generalized-
   label
         |  |  |           +--:(sid)
         |  |  |              +--ro sid-hop


         |  |  |                 +--ro sid?   rt-types:generalized-label
         |  |  +--ro connectivity-matrix* [id]
         |  |     +--ro id                          uint32
         |  |     +--ro from
         |  |     |  +--ro tp-ref?              leafref
         |  |     |  +--ro label-restriction* [inclusive-exclusive
   label-start]
         |  |     |     +--ro inclusive-exclusive    enumeration
         |  |     |     +--ro label-start            rt-
   types:generalized-label
         |  |     |     +--ro label-end?             rt-
   types:generalized-label
         |  |     |     +--ro range-bitmap?          binary
         |  |     +--ro to
         |  |     |  +--ro tp-ref?              leafref
         |  |     |  +--ro label-restriction* [inclusive-exclusive
   label-start]
         |  |     |     +--ro inclusive-exclusive    enumeration
         |  |     |     +--ro label-start            rt-
   types:generalized-label
         |  |     |     +--ro label-end?             rt-
   types:generalized-label
         |  |     |     +--ro range-bitmap?          binary
         |  |     +--ro is-allowed?                 boolean
         |  |     +--ro underlay {te-topology-hierarchy}?
         |  |     |  +--ro enabled?                     boolean
         |  |     |  +--ro primary-path
         |  |     |  |  +--ro network-ref?    leafref
         |  |     |  |  +--ro path-element* [path-element-id]
         |  |     |  |     +--ro path-element-id    uint32
         |  |     |  |     +--ro index?             uint32
         |  |     |  |     +--ro (type)?
         |  |     |  |        +--:(numbered)
         |  |     |  |        |  +--ro numbered-hop
         |  |     |  |        |     +--ro address?    te-types:te-tp-id
         |  |     |  |        |     +--ro hop-type?   te-hop-type
         |  |     |  |        +--:(as-number)
         |  |     |  |        |  +--ro as-number-hop
         |  |     |  |        |     +--ro as-number?   binary
         |  |     |  |        |     +--ro hop-type?    te-hop-type
         |  |     |  |        +--:(unnumbered)
         |  |     |  |        |  +--ro unnumbered-hop
         |  |     |  |        |     +--ro node-id?      te-types:te-
   node-id
         |  |     |  |        |     +--ro link-tp-id?   te-types:te-tp-
   id
         |  |     |  |        |     +--ro hop-type?     te-hop-type


         |  |     |  |        +--:(label)
         |  |     |  |        |  +--ro label-hop
         |  |     |  |        |     +--ro value?   rt-types:generalized-
   label
         |  |     |  |        +--:(sid)
         |  |     |  |           +--ro sid-hop
         |  |     |  |              +--ro sid?   rt-types:generalized-
   label
         |  |     |  +--ro backup-path* [index]
         |  |     |  |  +--ro index           uint32
         |  |     |  |  +--ro network-ref?    leafref
         |  |     |  |  +--ro path-element* [path-element-id]
         |  |     |  |     +--ro path-element-id    uint32
         |  |     |  |     +--ro index?             uint32
         |  |     |  |     +--ro (type)?
         |  |     |  |        +--:(numbered)
         |  |     |  |        |  +--ro numbered-hop
         |  |     |  |        |     +--ro address?    te-types:te-tp-id
         |  |     |  |        |     +--ro hop-type?   te-hop-type
         |  |     |  |        +--:(as-number)
         |  |     |  |        |  +--ro as-number-hop
         |  |     |  |        |     +--ro as-number?   binary
         |  |     |  |        |     +--ro hop-type?    te-hop-type
         |  |     |  |        +--:(unnumbered)
         |  |     |  |        |  +--ro unnumbered-hop
         |  |     |  |        |     +--ro node-id?      te-types:te-
   node-id
         |  |     |  |        |     +--ro link-tp-id?   te-types:te-tp-
   id
         |  |     |  |        |     +--ro hop-type?     te-hop-type
         |  |     |  |        +--:(label)
         |  |     |  |        |  +--ro label-hop
         |  |     |  |        |     +--ro value?   rt-types:generalized-
   label
         |  |     |  |        +--:(sid)
         |  |     |  |           +--ro sid-hop
         |  |     |  |              +--ro sid?   rt-types:generalized-
   label
         |  |     |  +--ro protection-type?             identityref
         |  |     |  +--ro tunnel-termination-points
         |  |     |  |  +--ro source?        binary
         |  |     |  |  +--ro destination?   binary
         |  |     |  +--ro tunnels
         |  |     |     +--ro sharing?   boolean
         |  |     |     +--ro tunnel* [tunnel-name]
         |  |     |        +--ro tunnel-name    string
         |  |     |        +--ro sharing?       boolean



         |  |     +--ro path-constraints
         |  |     |  +--ro path-metric-bound* [metric-type]
         |  |     |  |  +--ro metric-type    identityref
         |  |     |  |  +--ro upper-bound?   uint64
         |  |     |  +--ro topology-id?         te-types:te-topology-id
         |  |     |  +--ro ignore-overload?     boolean
         |  |     |  +--ro bandwidth-generic
         |  |     |  |  +--ro te-bandwidth
         |  |     |  |     +--ro (technology)?
         |  |     |  |        +--:(psc)
         |  |     |  |        |  +--ro psc?       rt-types:bandwidth-
   ieee-float32
         |  |     |  |        +--:(otn)
         |  |     |  |        |  +--ro otn* [rate-type]
         |  |     |  |        |     +--ro rate-type    identityref
         |  |     |  |        |     +--ro counter?     uint16
         |  |     |  |        +--:(lsc)
         |  |     |  |        |  +--ro wdm* [spectrum slot]
         |  |     |  |        |     +--ro spectrum    identityref
         |  |     |  |        |     +--ro slot        int16
         |  |     |  |        |     +--ro width?      uint16
         |  |     |  |        +--:(generic)
         |  |     |  |           +--ro generic?   te-bandwidth
         |  |     |  +--ro disjointness?        te-types:te-path-
   disjointness
         |  |     |  +--ro setup-priority?      uint8
         |  |     |  +--ro hold-priority?       uint8
         |  |     |  +--ro signaling-type?      identityref
         |  |     |  +--ro path-affinities
         |  |     |  |  +--ro constraint* [usage]
         |  |     |  |     +--ro usage    identityref
         |  |     |  |     +--ro value?   admin-groups
         |  |     |  +--ro path-srlgs
         |  |     |     +--ro usage?    identityref
         |  |     |     +--ro values*   srlg
         |  |     +--ro optimizations
         |  |     |  +--ro (algorithm)?
         |  |     |     +--:(metric) {path-optimization-metric}?
         |  |     |     |  +--ro optimization-metric* [metric-type]
         |  |     |     |  |  +--ro metric-type    identityref
         |  |     |     |  |  +--ro weight?        uint8
         |  |     |     |  +--ro tiebreakers
         |  |     |     |     +--ro tiebreaker* [tiebreaker-type]
         |  |     |     |        +--ro tiebreaker-type    identityref
         |  |     |     +--:(objective-function) {path-optimization-
   objective-function}?
         |  |     |        +--ro objective-function


         |  |     |           +--ro objective-function-type?
   identityref
         |  |     +--ro computed-path-properties
         |  |        +--ro path-metric* [metric-type]
         |  |        |  +--ro metric-type           identityref
         |  |        |  +--ro accumulative-value?   uint64
         |  |        +--ro path-affinities
         |  |        |  +--ro constraint* [usage]
         |  |        |     +--ro usage    identityref
         |  |        |     +--ro value?   admin-groups
         |  |        +--ro path-srlgs
         |  |        |  +--ro usage?    identityref
         |  |        |  +--ro values*   srlg
         |  |        +--ro path-computed-route-objects
         |  |           +--ro path-computed-route-object* [index]
         |  |              +--ro index             uint32
         |  |              +--ro (type)?
         |  |                 +--:(numbered)
         |  |                 |  +--ro numbered-hop
         |  |                 |     +--ro address?    te-types:te-tp-id
         |  |                 |     +--ro hop-type?   te-hop-type
         |  |                 +--:(as-number)
         |  |                 |  +--ro as-number-hop
         |  |                 |     +--ro as-number?   binary
         |  |                 |     +--ro hop-type?    te-hop-type
         |  |                 +--:(unnumbered)
         |  |                 |  +--ro unnumbered-hop
         |  |                 |     +--ro node-id?      te-types:te-
   node-id
         |  |                 |     +--ro link-tp-id?   te-types:te-tp-
   id
         |  |                 |     +--ro hop-type?     te-hop-type
         |  |                 +--:(label)
         |  |                 |  +--ro label-hop
         |  |                 |     +--ro value?   rt-types:generalized-
   label
         |  |                 +--:(sid)
         |  |                    +--ro sid-hop
         |  |                       +--ro sid?   rt-types:generalized-
   label
         |  +--ro domain-id?                  uint32
         |  +--ro is-abstract?                empty
         |  +--ro name?                       inet:domain-name
         |  +--ro signaling-address*          inet:ip-address
         |  +--ro underlay-topology {te-topology-hierarchy}?
         |     +--ro network-ref?   leafref
         +--ro statistics



         |  +--ro discontinuity-time           yang:date-and-time
         |  +--ro node
         |  |  +--ro disables?             yang:counter32
         |  |  +--ro enables?              yang:counter32
         |  |  +--ro maintenance-sets?     yang:counter32
         |  |  +--ro maintenance-clears?   yang:counter32
         |  |  +--ro modifies?             yang:counter32
         |  +--ro connectivity-matrix-entry
         |     +--ro creates?    yang:counter32
         |     +--ro deletes?    yang:counter32
         |     +--ro disables?   yang:counter32
         |     +--ro enables?    yang:counter32
         |     +--ro modifies?   yang:counter32
         +--rw tunnel-termination-point* [tunnel-tp-id]
            +--rw tunnel-tp-id                           binary
            +--rw admin-status?                          te-types:te-
   admin-status
            +--rw name?                                  string
            +--rw switching-capability?                  identityref
            +--rw encoding?                              identityref
            +--rw inter-layer-lock-id*                   uint32
            +--rw protection-type?                       identityref
            +--rw client-layer-adaptation
            |  +--rw switching-capability* [switching-capability
   encoding]
            |     +--rw switching-capability    identityref
            |     +--rw encoding                identityref
            |     +--rw bandwidth
            |        +--rw te-bandwidth
            |           +--rw (technology)?
            |              +--:(psc)
            |              |  +--rw psc?       rt-types:bandwidth-ieee-
   float32
            |              +--:(otn)
            |              |  +--rw otn* [rate-type]
            |              |     +--rw rate-type    identityref
            |              |     +--rw counter?     uint16
            |              +--:(lsc)
            |              |  +--rw wdm* [spectrum slot]
            |              |     +--rw spectrum    identityref
            |              |     +--rw slot        int16
            |              |     +--rw width?      uint16
            |              +--:(generic)
            |                 +--rw generic?   te-bandwidth
            +--rw local-link-connectivities
            |  +--rw number-of-entries?          uint16



            |  +--rw label-restriction* [inclusive-exclusive label-
   start]
            |  |  +--rw inclusive-exclusive    enumeration
            |  |  +--rw label-start            rt-types:generalized-
   label
            |  |  +--rw label-end?             rt-types:generalized-
   label
            |  |  +--rw range-bitmap?          binary
            |  +--rw is-allowed?                 boolean
            |  +--rw underlay {te-topology-hierarchy}?
            |  |  +--rw enabled?                     boolean
            |  |  +--rw primary-path
            |  |  |  +--rw network-ref?    leafref
            |  |  |  +--rw path-element* [path-element-id]
            |  |  |     +--rw path-element-id    uint32
            |  |  |     +--rw index?             uint32
            |  |  |     +--rw (type)?
            |  |  |        +--:(numbered)
            |  |  |        |  +--rw numbered-hop
            |  |  |        |     +--rw address?    te-types:te-tp-id
            |  |  |        |     +--rw hop-type?   te-hop-type
            |  |  |        +--:(as-number)
            |  |  |        |  +--rw as-number-hop
            |  |  |        |     +--rw as-number?   binary
            |  |  |        |     +--rw hop-type?    te-hop-type
            |  |  |        +--:(unnumbered)
            |  |  |        |  +--rw unnumbered-hop
            |  |  |        |     +--rw node-id?      te-types:te-node-id
            |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
            |  |  |        |     +--rw hop-type?     te-hop-type
            |  |  |        +--:(label)
            |  |  |        |  +--rw label-hop
            |  |  |        |     +--rw value?   rt-types:generalized-
   label
            |  |  |        +--:(sid)
            |  |  |           +--rw sid-hop
            |  |  |              +--rw sid?   rt-types:generalized-label
            |  |  +--rw backup-path* [index]
            |  |  |  +--rw index           uint32
            |  |  |  +--rw network-ref?    leafref
            |  |  |  +--rw path-element* [path-element-id]
            |  |  |     +--rw path-element-id    uint32
            |  |  |     +--rw index?             uint32
            |  |  |     +--rw (type)?
            |  |  |        +--:(numbered)
            |  |  |        |  +--rw numbered-hop
            |  |  |        |     +--rw address?    te-types:te-tp-id




            |  |  |        |     +--rw hop-type?   te-hop-type
            |  |  |        +--:(as-number)
            |  |  |        |  +--rw as-number-hop
            |  |  |        |     +--rw as-number?   binary
            |  |  |        |     +--rw hop-type?    te-hop-type
            |  |  |        +--:(unnumbered)
            |  |  |        |  +--rw unnumbered-hop
            |  |  |        |     +--rw node-id?      te-types:te-node-id
            |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
            |  |  |        |     +--rw hop-type?     te-hop-type
            |  |  |        +--:(label)
            |  |  |        |  +--rw label-hop
            |  |  |        |     +--rw value?   rt-types:generalized-
   label
            |  |  |        +--:(sid)
            |  |  |           +--rw sid-hop
            |  |  |              +--rw sid?   rt-types:generalized-label
            |  |  +--rw protection-type?             identityref
            |  |  +--rw tunnel-termination-points
            |  |  |  +--rw source?        binary
            |  |  |  +--rw destination?   binary
            |  |  +--rw tunnels
            |  |     +--rw sharing?   boolean
            |  |     +--rw tunnel* [tunnel-name]
            |  |        +--rw tunnel-name    string
            |  |        +--rw sharing?       boolean
            |  +--rw path-constraints
            |  |  +--rw path-metric-bound* [metric-type]
            |  |  |  +--rw metric-type    identityref
            |  |  |  +--rw upper-bound?   uint64
            |  |  +--rw topology-id?         te-types:te-topology-id
            |  |  +--rw ignore-overload?     boolean
            |  |  +--rw bandwidth-generic
            |  |  |  +--rw te-bandwidth
            |  |  |     +--rw (technology)?
            |  |  |        +--:(psc)
            |  |  |        |  +--rw psc?       rt-types:bandwidth-ieee-
   float32
            |  |  |        +--:(otn)
            |  |  |        |  +--rw otn* [rate-type]
            |  |  |        |     +--rw rate-type    identityref
            |  |  |        |     +--rw counter?     uint16
            |  |  |        +--:(lsc)
            |  |  |        |  +--rw wdm* [spectrum slot]
            |  |  |        |     +--rw spectrum    identityref
            |  |  |        |     +--rw slot        int16
            |  |  |        |     +--rw width?      uint16




            |  |  |        +--:(generic)
            |  |  |           +--rw generic?   te-bandwidth
            |  |  +--rw disjointness?        te-types:te-path-
   disjointness
            |  |  +--rw setup-priority?      uint8
            |  |  +--rw hold-priority?       uint8
            |  |  +--rw signaling-type?      identityref
            |  |  +--rw path-affinities
            |  |  |  +--rw constraint* [usage]
            |  |  |     +--rw usage    identityref
            |  |  |     +--rw value?   admin-groups
            |  |  +--rw path-srlgs
            |  |     +--rw usage?    identityref
            |  |     +--rw values*   srlg
            |  +--rw optimizations
            |  |  +--rw (algorithm)?
            |  |     +--:(metric) {path-optimization-metric}?
            |  |     |  +--rw optimization-metric* [metric-type]
            |  |     |  |  +--rw metric-type    identityref
            |  |     |  |  +--rw weight?        uint8
            |  |     |  +--rw tiebreakers
            |  |     |     +--rw tiebreaker* [tiebreaker-type]
            |  |     |        +--rw tiebreaker-type    identityref
            |  |     +--:(objective-function) {path-optimization-
   objective-function}?
            |  |        +--rw objective-function
            |  |           +--rw objective-function-type?   identityref
            |  +--ro computed-path-properties
            |  |  +--ro path-metric* [metric-type]
            |  |  |  +--ro metric-type           identityref
            |  |  |  +--ro accumulative-value?   uint64
            |  |  +--ro path-affinities
            |  |  |  +--ro constraint* [usage]
            |  |  |     +--ro usage    identityref
            |  |  |     +--ro value?   admin-groups
            |  |  +--ro path-srlgs
            |  |  |  +--ro usage?    identityref
            |  |  |  +--ro values*   srlg
            |  |  +--ro path-computed-route-objects
            |  |     +--ro path-computed-route-object* [index]
            |  |        +--ro index             uint32
            |  |        +--ro (type)?
            |  |           +--:(numbered)
            |  |           |  +--ro numbered-hop
            |  |           |     +--ro address?    te-types:te-tp-id
            |  |           |     +--ro hop-type?   te-hop-type
            |  |           +--:(as-number)



            |  |           |  +--ro as-number-hop
            |  |           |     +--ro as-number?   binary
            |  |           |     +--ro hop-type?    te-hop-type
            |  |           +--:(unnumbered)
            |  |           |  +--ro unnumbered-hop
            |  |           |     +--ro node-id?      te-types:te-node-id
            |  |           |     +--ro link-tp-id?   te-types:te-tp-id
            |  |           |     +--ro hop-type?     te-hop-type
            |  |           +--:(label)
            |  |           |  +--ro label-hop
            |  |           |     +--ro value?   rt-types:generalized-
   label
            |  |           +--:(sid)
            |  |              +--ro sid-hop
            |  |                 +--ro sid?   rt-types:generalized-label
            |  +--rw local-link-connectivity* [link-tp-ref]
            |     +--rw link-tp-ref                 leafref
            |     +--rw label-restriction* [inclusive-exclusive label-
   start]
            |     |  +--rw inclusive-exclusive    enumeration
            |     |  +--rw label-start            rt-types:generalized-
   label
            |     |  +--rw label-end?             rt-types:generalized-
   label
            |     |  +--rw range-bitmap?          binary
            |     +--rw is-allowed?                 boolean
            |     +--rw underlay {te-topology-hierarchy}?
            |     |  +--rw enabled?                     boolean
            |     |  +--rw primary-path
            |     |  |  +--rw network-ref?    leafref
            |     |  |  +--rw path-element* [path-element-id]
            |     |  |     +--rw path-element-id    uint32
            |     |  |     +--rw index?             uint32
            |     |  |     +--rw (type)?
            |     |  |        +--:(numbered)
            |     |  |        |  +--rw numbered-hop
            |     |  |        |     +--rw address?    te-types:te-tp-id
            |     |  |        |     +--rw hop-type?   te-hop-type
            |     |  |        +--:(as-number)
            |     |  |        |  +--rw as-number-hop
            |     |  |        |     +--rw as-number?   binary
            |     |  |        |     +--rw hop-type?    te-hop-type
            |     |  |        +--:(unnumbered)
            |     |  |        |  +--rw unnumbered-hop
            |     |  |        |     +--rw node-id?      te-types:te-
   node-id




            |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
   id
            |     |  |        |     +--rw hop-type?     te-hop-type
            |     |  |        +--:(label)
            |     |  |        |  +--rw label-hop
            |     |  |        |     +--rw value?   rt-types:generalized-
   label
            |     |  |        +--:(sid)
            |     |  |           +--rw sid-hop
            |     |  |              +--rw sid?   rt-types:generalized-
   label
            |     |  +--rw backup-path* [index]
            |     |  |  +--rw index           uint32
            |     |  |  +--rw network-ref?    leafref
            |     |  |  +--rw path-element* [path-element-id]
            |     |  |     +--rw path-element-id    uint32
            |     |  |     +--rw index?             uint32
            |     |  |     +--rw (type)?
            |     |  |        +--:(numbered)
            |     |  |        |  +--rw numbered-hop
            |     |  |        |     +--rw address?    te-types:te-tp-id
            |     |  |        |     +--rw hop-type?   te-hop-type
            |     |  |        +--:(as-number)
            |     |  |        |  +--rw as-number-hop
            |     |  |        |     +--rw as-number?   binary
            |     |  |        |     +--rw hop-type?    te-hop-type
            |     |  |        +--:(unnumbered)
            |     |  |        |  +--rw unnumbered-hop
            |     |  |        |     +--rw node-id?      te-types:te-
   node-id
            |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
   id
            |     |  |        |     +--rw hop-type?     te-hop-type
            |     |  |        +--:(label)
            |     |  |        |  +--rw label-hop
            |     |  |        |     +--rw value?   rt-types:generalized-
   label
            |     |  |        +--:(sid)
            |     |  |           +--rw sid-hop
            |     |  |              +--rw sid?   rt-types:generalized-
   label
            |     |  +--rw protection-type?             identityref
            |     |  +--rw tunnel-termination-points
            |     |  |  +--rw source?        binary
            |     |  |  +--rw destination?   binary
            |     |  +--rw tunnels
            |     |     +--rw sharing?   boolean



            |     |     +--rw tunnel* [tunnel-name]
            |     |        +--rw tunnel-name    string
            |     |        +--rw sharing?       boolean
            |     +--rw path-constraints
            |     |  +--rw path-metric-bound* [metric-type]
            |     |  |  +--rw metric-type    identityref
            |     |  |  +--rw upper-bound?   uint64
            |     |  +--rw topology-id?         te-types:te-topology-id
            |     |  +--rw ignore-overload?     boolean
            |     |  +--rw bandwidth-generic
            |     |  |  +--rw te-bandwidth
            |     |  |     +--rw (technology)?
            |     |  |        +--:(psc)
            |     |  |        |  +--rw psc?       rt-types:bandwidth-
   ieee-float32
            |     |  |        +--:(otn)
            |     |  |        |  +--rw otn* [rate-type]
            |     |  |        |     +--rw rate-type    identityref
            |     |  |        |     +--rw counter?     uint16
            |     |  |        +--:(lsc)
            |     |  |        |  +--rw wdm* [spectrum slot]
            |     |  |        |     +--rw spectrum    identityref
            |     |  |        |     +--rw slot        int16
            |     |  |        |     +--rw width?      uint16
            |     |  |        +--:(generic)
            |     |  |           +--rw generic?   te-bandwidth
            |     |  +--rw disjointness?        te-types:te-path-
   disjointness
            |     |  +--rw setup-priority?      uint8
            |     |  +--rw hold-priority?       uint8
            |     |  +--rw signaling-type?      identityref
            |     |  +--rw path-affinities
            |     |  |  +--rw constraint* [usage]
            |     |  |     +--rw usage    identityref
            |     |  |     +--rw value?   admin-groups
            |     |  +--rw path-srlgs
            |     |     +--rw usage?    identityref
            |     |     +--rw values*   srlg
            |     +--rw optimizations
            |     |  +--rw (algorithm)?
            |     |     +--:(metric) {path-optimization-metric}?
            |     |     |  +--rw optimization-metric* [metric-type]
            |     |     |  |  +--rw metric-type    identityref
            |     |     |  |  +--rw weight?        uint8
            |     |     |  +--rw tiebreakers
            |     |     |     +--rw tiebreaker* [tiebreaker-type]
            |     |     |        +--rw tiebreaker-type    identityref




            |     |     +--:(objective-function) {path-optimization-
   objective-function}?
            |     |        +--rw objective-function
            |     |           +--rw objective-function-type?
   identityref
            |     +--ro computed-path-properties
            |        +--ro path-metric* [metric-type]
            |        |  +--ro metric-type           identityref
            |        |  +--ro accumulative-value?   uint64
            |        +--ro path-affinities
            |        |  +--ro constraint* [usage]
            |        |     +--ro usage    identityref
            |        |     +--ro value?   admin-groups
            |        +--ro path-srlgs
            |        |  +--ro usage?    identityref
            |        |  +--ro values*   srlg
            |        +--ro path-computed-route-objects
            |           +--ro path-computed-route-object* [index]
            |              +--ro index             uint32
            |              +--ro (type)?
            |                 +--:(numbered)
            |                 |  +--ro numbered-hop
            |                 |     +--ro address?    te-types:te-tp-id
            |                 |     +--ro hop-type?   te-hop-type
            |                 +--:(as-number)
            |                 |  +--ro as-number-hop
            |                 |     +--ro as-number?   binary
            |                 |     +--ro hop-type?    te-hop-type
            |                 +--:(unnumbered)
            |                 |  +--ro unnumbered-hop
            |                 |     +--ro node-id?      te-types:te-
   node-id
            |                 |     +--ro link-tp-id?   te-types:te-tp-
   id
            |                 |     +--ro hop-type?     te-hop-type
            |                 +--:(label)
            |                 |  +--ro label-hop
            |                 |     +--ro value?   rt-types:generalized-
   label
            |                 +--:(sid)
            |                    +--ro sid-hop
            |                       +--ro sid?   rt-types:generalized-
   label
            +--ro oper-status?                           te-types:te-
   oper-status
            +--ro geolocation
            |  +--ro altitude?    int64


            |  +--ro latitude?    geographic-coordinate-degree
            |  +--ro longitude?   geographic-coordinate-degree
            +--ro statistics
            |  +--ro discontinuity-time          yang:date-and-time
            |  +--ro tunnel-termination-point
            |  |  +--ro disables?             yang:counter32
            |  |  +--ro enables?              yang:counter32
            |  |  +--ro maintenance-clears?   yang:counter32
            |  |  +--ro maintenance-sets?     yang:counter32
            |  |  +--ro modifies?             yang:counter32
            |  |  +--ro downs?                yang:counter32
            |  |  +--ro ups?                  yang:counter32
            |  |  +--ro in-service-clears?    yang:counter32
            |  |  +--ro in-service-sets?      yang:counter32
            |  +--ro local-link-connectivity
            |     +--ro creates?    yang:counter32
            |     +--ro deletes?    yang:counter32
            |     +--ro disables?   yang:counter32
            |     +--ro enables?    yang:counter32
            |     +--ro modifies?   yang:counter32
            +--rw supporting-tunnel-termination-point* [node-ref tunnel-
   tp-ref]
               +--rw node-ref         inet:uri
               +--rw tunnel-tp-ref    binary
   augment /nw:networks/nw:network/nt:link:
      +--rw te!
         +--rw (bundle-stack-level)?
         |  +--:(bundle)
         |  |  +--rw bundled-links
         |  |     +--rw bundled-link* [sequence]
         |  |        +--rw sequence      uint32
         |  |        +--rw src-tp-ref?   leafref
         |  |        +--rw des-tp-ref?   leafref
         |  +--:(component)
         |     +--rw component-links
         |        +--rw component-link* [sequence]
         |           +--rw sequence             uint32
         |           +--rw src-interface-ref?   string
         |           +--rw des-interface-ref?   string
         +--rw te-link-template*           leafref {template}?
         +--rw te-link-attributes
         |  +--rw access-type?                      te-types:te-link-
   access-type
         |  +--rw external-domain
         |  |  +--rw network-ref?            leafref
         |  |  +--rw remote-te-node-id?      te-types:te-node-id
         |  |  +--rw remote-te-link-tp-id?   te-types:te-tp-id




         |  |  +--rw plug-id?                uint32
         |  +--rw is-abstract?                      empty
         |  +--rw name?                             string
         |  +--rw underlay {te-topology-hierarchy}?
         |  |  +--rw enabled?                     boolean
         |  |  +--rw primary-path
         |  |  |  +--rw network-ref?    leafref
         |  |  |  +--rw path-element* [path-element-id]
         |  |  |     +--rw path-element-id    uint32
         |  |  |     +--rw index?             uint32
         |  |  |     +--rw (type)?
         |  |  |        +--:(numbered)
         |  |  |        |  +--rw numbered-hop
         |  |  |        |     +--rw address?    te-types:te-tp-id
         |  |  |        |     +--rw hop-type?   te-hop-type
         |  |  |        +--:(as-number)
         |  |  |        |  +--rw as-number-hop
         |  |  |        |     +--rw as-number?   binary
         |  |  |        |     +--rw hop-type?    te-hop-type
         |  |  |        +--:(unnumbered)
         |  |  |        |  +--rw unnumbered-hop
         |  |  |        |     +--rw node-id?      te-types:te-node-id
         |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
         |  |  |        |     +--rw hop-type?     te-hop-type
         |  |  |        +--:(label)
         |  |  |        |  +--rw label-hop
         |  |  |        |     +--rw value?   rt-types:generalized-label
         |  |  |        +--:(sid)
         |  |  |           +--rw sid-hop
         |  |  |              +--rw sid?   rt-types:generalized-label
         |  |  +--rw backup-path* [index]
         |  |  |  +--rw index           uint32
         |  |  |  +--rw network-ref?    leafref
         |  |  |  +--rw path-element* [path-element-id]
         |  |  |     +--rw path-element-id    uint32
         |  |  |     +--rw index?             uint32
         |  |  |     +--rw (type)?
         |  |  |        +--:(numbered)
         |  |  |        |  +--rw numbered-hop
         |  |  |        |     +--rw address?    te-types:te-tp-id
         |  |  |        |     +--rw hop-type?   te-hop-type
         |  |  |        +--:(as-number)
         |  |  |        |  +--rw as-number-hop
         |  |  |        |     +--rw as-number?   binary
         |  |  |        |     +--rw hop-type?    te-hop-type
         |  |  |        +--:(unnumbered)
         |  |  |        |  +--rw unnumbered-hop


         |  |  |        |     +--rw node-id?      te-types:te-node-id
         |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
         |  |  |        |     +--rw hop-type?     te-hop-type
         |  |  |        +--:(label)
         |  |  |        |  +--rw label-hop
         |  |  |        |     +--rw value?   rt-types:generalized-label
         |  |  |        +--:(sid)
         |  |  |           +--rw sid-hop
         |  |  |              +--rw sid?   rt-types:generalized-label
         |  |  +--rw protection-type?             identityref
         |  |  +--rw tunnel-termination-points
         |  |  |  +--rw source?        binary
         |  |  |  +--rw destination?   binary
         |  |  +--rw tunnels
         |  |     +--rw sharing?   boolean
         |  |     +--rw tunnel* [tunnel-name]
         |  |        +--rw tunnel-name    string
         |  |        +--rw sharing?       boolean
         |  +--rw admin-status?                     te-types:te-admin-
   status
         |  +--rw link-index?                       uint64
         |  +--rw administrative-group?             te-types:admin-
   groups
         |  +--rw interface-switching-capability* [switching-capability
   encoding]
         |  |  +--rw switching-capability    identityref
         |  |  +--rw encoding                identityref
         |  |  +--rw max-lsp-bandwidth* [priority]
         |  |     +--rw priority     uint8
         |  |     +--rw bandwidth
         |  |        +--rw te-bandwidth
         |  |           +--rw (technology)?
         |  |              +--:(psc)
         |  |              |  +--rw psc?       rt-types:bandwidth-ieee-
   float32
         |  |              +--:(otn)
         |  |              |  +--rw otn* [rate-type]
         |  |              |     +--rw rate-type    identityref
         |  |              |     +--rw counter?     uint16
         |  |              +--:(lsc)
         |  |              |  +--rw wdm* [spectrum slot]
         |  |              |     +--rw spectrum    identityref
         |  |              |     +--rw slot        int16
         |  |              |     +--rw width?      uint16
         |  |              +--:(generic)
         |  |                 +--rw generic?   te-bandwidth
         |  +--rw label-restriction* [inclusive-exclusive label-start]



         |  |  +--rw inclusive-exclusive    enumeration
         |  |  +--rw label-start            rt-types:generalized-label
         |  |  +--rw label-end?             rt-types:generalized-label
         |  |  +--rw range-bitmap?          binary
         |  +--rw link-protection-type?             enumeration
         |  +--rw max-link-bandwidth
         |  |  +--rw te-bandwidth
         |  |     +--rw (technology)?
         |  |        +--:(psc)
         |  |        |  +--rw psc?       rt-types:bandwidth-ieee-float32
         |  |        +--:(otn)
         |  |        |  +--rw otn* [rate-type]
         |  |        |     +--rw rate-type    identityref
         |  |        |     +--rw counter?     uint16
         |  |        +--:(lsc)
         |  |        |  +--rw wdm* [spectrum slot]
         |  |        |     +--rw spectrum    identityref
         |  |        |     +--rw slot        int16
         |  |        |     +--rw width?      uint16
         |  |        +--:(generic)
         |  |           +--rw generic?   te-bandwidth
         |  +--rw max-resv-link-bandwidth
         |  |  +--rw te-bandwidth
         |  |     +--rw (technology)?
         |  |        +--:(psc)
         |  |        |  +--rw psc?       rt-types:bandwidth-ieee-float32
         |  |        +--:(otn)
         |  |        |  +--rw otn* [rate-type]
         |  |        |     +--rw rate-type    identityref
         |  |        |     +--rw counter?     uint16
         |  |        +--:(lsc)
         |  |        |  +--rw wdm* [spectrum slot]
         |  |        |     +--rw spectrum    identityref
         |  |        |     +--rw slot        int16
         |  |        |     +--rw width?      uint16
         |  |        +--:(generic)
         |  |           +--rw generic?   te-bandwidth
         |  +--rw unreserved-bandwidth* [priority]
         |  |  +--rw priority     uint8
         |  |  +--rw bandwidth
         |  |     +--rw te-bandwidth
         |  |        +--rw (technology)?
         |  |           +--:(psc)
         |  |           |  +--rw psc?       rt-types:bandwidth-ieee-
   float32
         |  |           +--:(otn)
         |  |           |  +--rw otn* [rate-type]


         |  |           |     +--rw rate-type    identityref
         |  |           |     +--rw counter?     uint16
         |  |           +--:(lsc)
         |  |           |  +--rw wdm* [spectrum slot]
         |  |           |     +--rw spectrum    identityref
         |  |           |     +--rw slot        int16
         |  |           |     +--rw width?      uint16
         |  |           +--:(generic)
         |  |              +--rw generic?   te-bandwidth
         |  +--rw te-default-metric?                uint32
         |  +--rw te-delay-metric?                  uint32
         |  +--rw te-igp-metric?                    uint32
         |  +--rw te-srlgs
         |  |  +--rw value*   te-types:srlg
         |  +--rw te-nsrlgs {nsrlg}?
         |     +--rw id*   uint32
         +--ro oper-status?                te-types:te-oper-status
         +--ro is-transitional?            empty
         +--ro information-source?         te-info-source
         +--ro information-source-state
         |  +--ro credibility-preference?    uint16
         |  +--ro logical-network-element?   string
         |  +--ro network-instance?          string
         |  +--ro topology
         |     +--ro link-ref?      leafref
         |     +--ro network-ref?   leafref
         +--ro information-source-entry* [information-source]
         |  +--ro information-source                te-info-source
         |  +--ro information-source-state
         |  |  +--ro credibility-preference?    uint16
         |  |  +--ro logical-network-element?   string
         |  |  +--ro network-instance?          string
         |  |  +--ro topology
         |  |     +--ro link-ref?      leafref
         |  |     +--ro network-ref?   leafref
         |  +--ro link-index?                       uint64
         |  +--ro administrative-group?             te-types:admin-
   groups
         |  +--ro interface-switching-capability* [switching-capability
   encoding]
         |  |  +--ro switching-capability    identityref
         |  |  +--ro encoding                identityref
         |  |  +--ro max-lsp-bandwidth* [priority]
         |  |     +--ro priority     uint8
         |  |     +--ro bandwidth
         |  |        +--ro te-bandwidth
         |  |           +--ro (technology)?


         |  |              +--:(psc)
         |  |              |  +--ro psc?       rt-types:bandwidth-ieee-
   float32
         |  |              +--:(otn)
         |  |              |  +--ro otn* [rate-type]
         |  |              |     +--ro rate-type    identityref
         |  |              |     +--ro counter?     uint16
         |  |              +--:(lsc)
         |  |              |  +--ro wdm* [spectrum slot]
         |  |              |     +--ro spectrum    identityref
         |  |              |     +--ro slot        int16
         |  |              |     +--ro width?      uint16
         |  |              +--:(generic)
         |  |                 +--ro generic?   te-bandwidth
         |  +--ro label-restriction* [inclusive-exclusive label-start]
         |  |  +--ro inclusive-exclusive    enumeration
         |  |  +--ro label-start            rt-types:generalized-label
         |  |  +--ro label-end?             rt-types:generalized-label
         |  |  +--ro range-bitmap?          binary
         |  +--ro link-protection-type?             enumeration
         |  +--ro max-link-bandwidth
         |  |  +--ro te-bandwidth
         |  |     +--ro (technology)?
         |  |        +--:(psc)
         |  |        |  +--ro psc?       rt-types:bandwidth-ieee-float32
         |  |        +--:(otn)
         |  |        |  +--ro otn* [rate-type]
         |  |        |     +--ro rate-type    identityref
         |  |        |     +--ro counter?     uint16
         |  |        +--:(lsc)
         |  |        |  +--ro wdm* [spectrum slot]
         |  |        |     +--ro spectrum    identityref
         |  |        |     +--ro slot        int16
         |  |        |     +--ro width?      uint16
         |  |        +--:(generic)
         |  |           +--ro generic?   te-bandwidth
         |  +--ro max-resv-link-bandwidth
         |  |  +--ro te-bandwidth
         |  |     +--ro (technology)?
         |  |        +--:(psc)
         |  |        |  +--ro psc?       rt-types:bandwidth-ieee-float32
         |  |        +--:(otn)
         |  |        |  +--ro otn* [rate-type]
         |  |        |     +--ro rate-type    identityref
         |  |        |     +--ro counter?     uint16
         |  |        +--:(lsc)
         |  |        |  +--ro wdm* [spectrum slot]



         |  |        |     +--ro spectrum    identityref
         |  |        |     +--ro slot        int16
         |  |        |     +--ro width?      uint16
         |  |        +--:(generic)
         |  |           +--ro generic?   te-bandwidth
         |  +--ro unreserved-bandwidth* [priority]
         |  |  +--ro priority     uint8
         |  |  +--ro bandwidth
         |  |     +--ro te-bandwidth
         |  |        +--ro (technology)?
         |  |           +--:(psc)
         |  |           |  +--ro psc?       rt-types:bandwidth-ieee-
   float32
         |  |           +--:(otn)
         |  |           |  +--ro otn* [rate-type]
         |  |           |     +--ro rate-type    identityref
         |  |           |     +--ro counter?     uint16
         |  |           +--:(lsc)
         |  |           |  +--ro wdm* [spectrum slot]
         |  |           |     +--ro spectrum    identityref
         |  |           |     +--ro slot        int16
         |  |           |     +--ro width?      uint16
         |  |           +--:(generic)
         |  |              +--ro generic?   te-bandwidth
         |  +--ro te-default-metric?                uint32
         |  +--ro te-delay-metric?                  uint32
         |  +--ro te-igp-metric?                    uint32
         |  +--ro te-srlgs
         |  |  +--ro value*   te-types:srlg
         |  +--ro te-nsrlgs {nsrlg}?
         |     +--ro id*   uint32
         +--ro recovery
         |  +--ro restoration-status?   te-types:te-recovery-status
         |  +--ro protection-status?    te-types:te-recovery-status
         +--ro underlay {te-topology-hierarchy}?
         |  +--ro dynamic?     boolean
         |  +--ro committed?   boolean
         +--ro statistics
            +--ro discontinuity-time                 yang:date-and-time
            +--ro disables?                          yang:counter32
            +--ro enables?                           yang:counter32
            +--ro maintenance-clears?                yang:counter32
            +--ro maintenance-sets?                  yang:counter32
            +--ro modifies?                          yang:counter32
            +--ro downs?                             yang:counter32
            +--ro ups?                               yang:counter32
            +--ro fault-clears?                      yang:counter32



            +--ro fault-detects?                     yang:counter32
            +--ro protection-switches?               yang:counter32
            +--ro protection-reverts?                yang:counter32
            +--ro restoration-failures?              yang:counter32
            +--ro restoration-starts?                yang:counter32
            +--ro restoration-successes?             yang:counter32
            +--ro restoration-reversion-failures?    yang:counter32
            +--ro restoration-reversion-starts?      yang:counter32
            +--ro restoration-reversion-successes?   yang:counter32
   augment /nw:networks/nw:network/nw:node/nt:termination-point:
      +--rw te-tp-id?   te-types:te-tp-id
      +--rw te!
         +--rw admin-status?                     te-types:te-admin-
   status
         +--rw name?                             string
         +--rw interface-switching-capability* [switching-capability
   encoding]
         |  +--rw switching-capability    identityref
         |  +--rw encoding                identityref
         |  +--rw max-lsp-bandwidth* [priority]
         |     +--rw priority     uint8
         |     +--rw bandwidth
         |        +--rw te-bandwidth
         |           +--rw (technology)?
         |              +--:(psc)
         |              |  +--rw psc?       rt-types:bandwidth-ieee-
   float32
         |              +--:(otn)
         |              |  +--rw otn* [rate-type]
         |              |     +--rw rate-type    identityref
         |              |     +--rw counter?     uint16
         |              +--:(lsc)
         |              |  +--rw wdm* [spectrum slot]
         |              |     +--rw spectrum    identityref
         |              |     +--rw slot        int16
         |              |     +--rw width?      uint16
         |              +--:(generic)
         |                 +--rw generic?   te-bandwidth
         +--rw inter-layer-lock-id*              uint32
         +--ro oper-status?                      te-types:te-oper-status
         +--ro geolocation
            +--ro altitude?    int64
            +--ro latitude?    geographic-coordinate-degree
            +--ro longitude?   geographic-coordinate-degree



=====================================
end of diagram

----- Original Message -----
From: "Lou Berger" 
To: 
Sent: Wednesday, October 25, 2017 2:13 PM
Subject: Re: [netmod] I-D Action:
draft-ietf-netmod-yang-tree-diagrams-02.txt


> Hi,
>
> This version addresses all known / open issues in the draft known to
> the authors.
>
> The changes are as follows:
> - Added groupings and yang-data descriptions
> - Added Comments, Long Diagrams and Security Considerations sections
> - Clarified representation of schema mount points and representation
of
> modules exposed using schema mount.
> - Miscellaneous editorial changes
>
> Lou (for draft authors)
>
> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
> >         Authors         : Martin Bjorklund
> >                           Lou Berger
> > Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
> > Pages           : 11
> > Date            : 2017-10-25
> >


From nobody Thu Oct 26 10:04:37 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DD213F3AC for ; Thu, 26 Oct 2017 10:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 G22xCR8WWFvY for ; Thu, 26 Oct 2017 10:04:33 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30133.outbound.protection.outlook.com [40.107.3.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB8913F088 for ; Thu, 26 Oct 2017 10:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+Ceu6bKLzVMyvfgMYMEM2cuEK8IxwH3Wg0Hfx9Iznv0=; b=ACCOFcUS+hSgEfg+HO7hvF8nvY/OK4hnJEk5Wuhj+fmdVOcrtb8eYpiCgwZXtXbVIljt4wozJtDfpRNgoSwWDcucU1Ea4glnPjjUlg3QqQmzxNWXfL4Zl9wajxjz3QE4dUBoKP/+Tk173Gm8xiggNR2YFVYj0Yieak5sh5rTKp0=
Received: from VI1PR07MB1135.eurprd07.prod.outlook.com (10.163.168.144) by VI1PR07MB1135.eurprd07.prod.outlook.com (10.163.168.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Thu, 26 Oct 2017 17:04:30 +0000
Received: from VI1PR07MB1135.eurprd07.prod.outlook.com ([fe80::b526:9a86:1da8:4072]) by VI1PR07MB1135.eurprd07.prod.outlook.com ([fe80::b526:9a86:1da8:4072%14]) with mapi id 15.20.0178.003; Thu, 26 Oct 2017 17:04:30 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: "netmod@ietf.org" 
Thread-Topic: rfc7223bis (interfaces) enabled leaf vs SNMP admin-state
Thread-Index: AdNOevP2Ug0r6+CiQ+ipzdRijgA3aQ==
Date: Thu, 26 Oct 2017 17:04:30 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.245.20.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB1135; 6:VWhhkN43V+MEKpvS+2RLZE5mHf/yUWRgM3+1imL+KE2EhbseKqdL3MxTPbPZOmZLSb4vOxGOBSxh0vT/kcX1+j1mIWLZZvtoOJ55h+AEpdc7rj9fYH6Dv1bUxXQckjy7Fkn4FCYtIN4zikzpPgOiM48EUQMQYn3zUWhPciCjC/VlnT8bdkgvTe7JShuWFlbc5d4/InubHnJa6y6rzHZd0CiF81/z9pnYV3uRFHqKPrOOoGFIsKd0eEX3fQa8vBoVKAdxeVgfy8DSrw3hYEdVRWWYf2ta3lPzNNps+DbCi3ndTSm6dpNbsdWVXN9gHZbLi3QeQyiEqLNyncdRWRjLKrdfav5c1WEaCknoCMncGa4=; 5:hboCSAbeOY34SAp3pxcjbwDQmDwguB07SBE3VQLqLIBamX+dDF9Wvif/UB1J0UABZCrUXMMAhPomWo+tDNUxlz10cWdH3t/7im2iXWqVxQS+fGuqdkQ5VwauFqm1tHPaPyDyr6G04R+RB8gn8gnyHBPDSLQXedIJxoHcOX/ZX+Y=; 24:c8R4CvcBUmeIA3YzNz26cB/6BahAAzvrbSXuti/ickCTpE3lsF0FY/j4h4C5t7NIOW7/cjfLDd2necFviY+4BxKcM0nqUW9TdeCiIccJPzc=; 7:qq8qmv+hCFGh4GNwxSCvR54T9/u9HBtdjoptAQMuFzSb/3vFuce9GcaWYPb6FX3Wwj4UbEu74PKSqWhu8BZBrGrRg4DnGLA379kXRF16nydJ9WPhnY0RkMtNs8vAUno4afr0RgxSmzgmKRJ/8lZBKdDezwsPYOa4+Y/z1rCUXG0mBL6HHZSZkLSyWsVJmtAxYQdCReGJqPgVacLXm14vVh+ne9x/RuR+y07kx34SheqkQrKmCYor61B7mSdtIuBU
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: d4607cd7-c16c-429d-2044-08d51c939fb6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603238); SRVR:VI1PR07MB1135; 
x-ms-traffictypediagnostic: VI1PR07MB1135:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231020)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1135; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1135; 
x-forefront-prvs: 04724A515E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(377424004)(13464003)(53754006)(189002)(199003)(2900100001)(105586002)(86362001)(14454004)(106356001)(3280700002)(6916009)(2906002)(54356999)(102836003)(1730700003)(9686003)(53936002)(99286003)(8936002)(6506006)(5660300001)(6306002)(316002)(55016002)(33656002)(3660700001)(101416001)(81156014)(81166006)(7696004)(50986999)(8676002)(305945005)(189998001)(97736004)(74316002)(68736007)(5640700003)(3846002)(6116002)(66066001)(6436002)(7736002)(25786009)(4001150100001)(5250100002)(53546010)(478600001)(966005)(2351001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1135; H:VI1PR07MB1135.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)
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: d4607cd7-c16c-429d-2044-08d51c939fb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 17:04:30.6982 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1135
Archived-At: 
Subject: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP admin-state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 17:04:36 -0000

Hi all,

The issue I'm raising isn't new to the 'bis' version of RFC7223, but I'm qu=
estioning whether we should consider changing something about it while we'r=
e in there.

The 'enabled' leaf has this in the description:

             Changes in this leaf in the intended configuration are
             reflected in ifAdminStatus, but if ifAdminStatus is
             changed over SNMP, this leaf is not affected.

As an example of "working code", Nokia's SR OS has supported full router co=
nfiguration via SNMP for many years.  When someone enables an interface via=
 CLI, that is reflected in ifAdminStatus and vice-versa.   i.e. configurati=
on via two different interfaces (SNMP & CLI) that use different data models=
, map rw leafs from the two interfaces/models to the same underlying intern=
al object.

In general, many SNMP rw objects will map to the same underlying internal r=
w object as the equivalent rw leaf in a YANG model (for products that actua=
lly support config management via SNMP as well as NETCONF).  Changing the l=
eaf/object via SNMP affects the equivalent leaf/object in NETCONF.  Why mak=
e this one a special case ?

I'd propose that we remove that sentence.

Rgds,
Jason

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Monday, October 16, 2017 9:25
> To: i-d-announce@ietf.org
> Cc: netmod@ietf.org
> Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-00.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Network Modeling WG of the IETF.
>=20
>         Title           : A YANG Data Model for Interface Management
>         Author          : Martin Bjorklund
> 	Filename        : draft-ietf-netmod-rfc7223bis-00.txt
> 	Pages           : 47
> 	Date            : 2017-10-15
>=20
> Abstract:
>    This document defines a YANG data model for the management of network
>    interfaces.  It is expected that interface-type-specific data models
>    augment the generic interfaces data model defined in this document.
>    The data model includes definitions for configuration and system
>    state (status information and counters for the collection of
>    statistics).  This document obsoletes RFC 7223.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-00
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> 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


From nobody Thu Oct 26 10:07:50 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8447713F3EE for ; Thu, 26 Oct 2017 10:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 ihNoeGLoSuUy for ; Thu, 26 Oct 2017 10:07:36 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9E513F3D7 for ; Thu, 26 Oct 2017 10:07:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=93775; q=dns/txt; s=iport; t=1509037655; x=1510247255; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=fLNbhO5DgXlnj0sqvQenBnFvZmyS92hFZItfTZvnsn0=; b=kegwk9w94YWV677PVibWxffCY9pr/N9281OknFNAPrdA97aB2iY5HJnF jcK8OZIniG2BR3xOrsF+0woWaWfNKx2PHXk0iwjdZ8Fl2Sb/ieK5aRnxY A50WgHPV78P1/Y/lEkq22M/gYF4Qbc6UccXLOGLZZBxE90UigX+vCUi8Y o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQD8FfJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ixOQF5hOAwoYC4E5AYMPTwKFBBQBAgEBAQEBAQFrKIU?= =?us-ascii?q?dAQEBAQIBAQEYAQgPAQU2FwQLEQQBAQECAiYCAicoCAYBDAYCAQGKFAgQqTmCJ?= =?us-ascii?q?4pyAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4Ifg1eCEoMBhEFEgxSCYQWKFId?= =?us-ascii?q?DkCSUeYtyhzmKUINSh2iBOTYhgWg0IQgdFR8qgmSCXByBaEA2jEYBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,301,1505779200"; d="scan'208";a="658326823"
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; 26 Oct 2017 17:07:15 +0000
Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9QH7Ei2005131; Thu, 26 Oct 2017 17:07:15 GMT
To: "t.petch" , netmod@ietf.org, Lou Berger 
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: <7f3b7f56-2de2-62c2-f9ec-6a010348eeb9@cisco.com>
Date: Thu, 26 Oct 2017 18:07:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 17:07:48 -0000

On 26/10/2017 17:50, t.petch wrote:
> Lou
>
> I like the advice that diagrams should be one page long but wonder how
> to apply that to those I see in routing WGs.  I have just been looking
> at
>
>   draft-ietf-teas-yang-te-topo-12
>
> where the diagram is 36 pages long - which may be one of the larger ones
> but by no means exceptional - and I think the diagram is  more or less
> useless as a result.  But what practical advice can we give them?
36 pages!  Wow.  It should be split up into smaller chunks, at that size 
I suspect that there is a certain amount of repetition.

Thanks,
Rob


>
> I append the diagram below
>
> Tom Petch
>
>
> start of diagram
> ==================================================
>
>
> Liu, et al             Expires January 17, 2018               [Page 31]
> 
>
> 6. Tree Structure
>
>     module: ietf-te-topology
>     augment /nw:networks/nw:network/nw:network-types:
>        +--rw te-topology!
>     augment /nw:networks:
>        +--rw te!
>           +--rw templates
>              +--rw node-template* [name] {template}?
>              |  +--rw name                       te-types:te-template-
>     name
>              |  +--rw priority?                  uint16
>              |  +--rw reference-change-policy?   enumeration
>              |  +--rw te-node-attributes
>              |     +--rw admin-status?        te-types:te-admin-status
>              |     +--rw domain-id?           uint32
>              |     +--rw is-abstract?         empty
>              |     +--rw name?                inet:domain-name
>              |     +--rw signaling-address*   inet:ip-address
>              |     +--rw underlay-topology {te-topology-hierarchy}?
>              |        +--rw network-ref?   leafref
>              +--rw link-template* [name] {template}?
>                 +--rw name                       te-types:te-template-
>     name
>                 +--rw priority?                  uint16
>                 +--rw reference-change-policy?   enumeration
>                 +--rw te-link-attributes
>                    +--rw access-type?                      te-types:te-
>     link-access-type
>                    +--rw external-domain
>                    |  +--rw network-ref?            leafref
>                    |  +--rw remote-te-node-id?      te-types:te-node-id
>                    |  +--rw remote-te-link-tp-id?   te-types:te-tp-id
>                    |  +--rw plug-id?                uint32
>                    +--rw is-abstract?                      empty
>                    +--rw name?                             string
>                    +--rw underlay {te-topology-hierarchy}?
>                    |  +--rw enabled?                     boolean
>                    |  +--rw primary-path
>                    |  |  +--rw network-ref?    leafref
>                    |  |  +--rw path-element* [path-element-id]
>                    |  |     +--rw path-element-id    uint32
>                    |  |     +--rw index?             uint32
>
>
>
>                    |  |     +--rw (type)?
>                    |  |        +--:(numbered)
>                    |  |        |  +--rw numbered-hop
>                    |  |        |     +--rw address?    te-types:te-tp-id
>                    |  |        |     +--rw hop-type?   te-hop-type
>                    |  |        +--:(as-number)
>                    |  |        |  +--rw as-number-hop
>                    |  |        |     +--rw as-number?   binary
>                    |  |        |     +--rw hop-type?    te-hop-type
>                    |  |        +--:(unnumbered)
>                    |  |        |  +--rw unnumbered-hop
>                    |  |        |     +--rw node-id?      te-types:te-
>     node-id
>                    |  |        |     +--rw link-tp-id?   te-types:te-tp-
>     id
>                    |  |        |     +--rw hop-type?     te-hop-type
>                    |  |        +--:(label)
>                    |  |        |  +--rw label-hop
>                    |  |        |     +--rw value?   rt-types:generalized-
>     label
>                    |  |        +--:(sid)
>                    |  |           +--rw sid-hop
>                    |  |              +--rw sid?   rt-types:generalized-
>     label
>                    |  +--rw backup-path* [index]
>                    |  |  +--rw index           uint32
>                    |  |  +--rw network-ref?    leafref
>                    |  |  +--rw path-element* [path-element-id]
>                    |  |     +--rw path-element-id    uint32
>                    |  |     +--rw index?             uint32
>                    |  |     +--rw (type)?
>                    |  |        +--:(numbered)
>                    |  |        |  +--rw numbered-hop
>                    |  |        |     +--rw address?    te-types:te-tp-id
>                    |  |        |     +--rw hop-type?   te-hop-type
>                    |  |        +--:(as-number)
>                    |  |        |  +--rw as-number-hop
>                    |  |        |     +--rw as-number?   binary
>                    |  |        |     +--rw hop-type?    te-hop-type
>                    |  |        +--:(unnumbered)
>                    |  |        |  +--rw unnumbered-hop
>                    |  |        |     +--rw node-id?      te-types:te-
>     node-id
>                    |  |        |     +--rw link-tp-id?   te-types:te-tp-
>     id
>                    |  |        |     +--rw hop-type?     te-hop-type
>                    |  |        +--:(label)
>
>
>                    |  |        |  +--rw label-hop
>                    |  |        |     +--rw value?   rt-types:generalized-
>     label
>                    |  |        +--:(sid)
>                    |  |           +--rw sid-hop
>                    |  |              +--rw sid?   rt-types:generalized-
>     label
>                    |  +--rw protection-type?             identityref
>                    |  +--rw tunnel-termination-points
>                    |  |  +--rw source?        binary
>                    |  |  +--rw destination?   binary
>                    |  +--rw tunnels
>                    |     +--rw sharing?   boolean
>                    |     +--rw tunnel* [tunnel-name]
>                    |        +--rw tunnel-name    string
>                    |        +--rw sharing?       boolean
>                    +--rw admin-status?                     te-types:te-
>     admin-status
>                    +--rw link-index?                       uint64
>                    +--rw administrative-group?             te-
>     types:admin-groups
>                    +--rw interface-switching-capability* [switching-
>     capability encoding]
>                    |  +--rw switching-capability    identityref
>                    |  +--rw encoding                identityref
>                    |  +--rw max-lsp-bandwidth* [priority]
>                    |     +--rw priority     uint8
>                    |     +--rw bandwidth
>                    |        +--rw te-bandwidth
>                    |           +--rw (technology)?
>                    |              +--:(psc)
>                    |              |  +--rw psc?       rt-types:bandwidth-
>     ieee-float32
>                    |              +--:(otn)
>                    |              |  +--rw otn* [rate-type]
>                    |              |     +--rw rate-type    identityref
>                    |              |     +--rw counter?     uint16
>                    |              +--:(lsc)
>                    |              |  +--rw wdm* [spectrum slot]
>                    |              |     +--rw spectrum    identityref
>                    |              |     +--rw slot        int16
>                    |              |     +--rw width?      uint16
>                    |              +--:(generic)
>                    |                 +--rw generic?   te-bandwidth
>                    +--rw label-restriction* [inclusive-exclusive label-
>     start]
>                    |  +--rw inclusive-exclusive    enumeration
>
>
>
>                    |  +--rw label-start            rt-types:generalized-
>     label
>                    |  +--rw label-end?             rt-types:generalized-
>     label
>                    |  +--rw range-bitmap?          binary
>                    +--rw link-protection-type?             enumeration
>                    +--rw max-link-bandwidth
>                    |  +--rw te-bandwidth
>                    |     +--rw (technology)?
>                    |        +--:(psc)
>                    |        |  +--rw psc?       rt-types:bandwidth-ieee-
>     float32
>                    |        +--:(otn)
>                    |        |  +--rw otn* [rate-type]
>                    |        |     +--rw rate-type    identityref
>                    |        |     +--rw counter?     uint16
>                    |        +--:(lsc)
>                    |        |  +--rw wdm* [spectrum slot]
>                    |        |     +--rw spectrum    identityref
>                    |        |     +--rw slot        int16
>                    |        |     +--rw width?      uint16
>                    |        +--:(generic)
>                    |           +--rw generic?   te-bandwidth
>                    +--rw max-resv-link-bandwidth
>                    |  +--rw te-bandwidth
>                    |     +--rw (technology)?
>                    |        +--:(psc)
>                    |        |  +--rw psc?       rt-types:bandwidth-ieee-
>     float32
>                    |        +--:(otn)
>                    |        |  +--rw otn* [rate-type]
>                    |        |     +--rw rate-type    identityref
>                    |        |     +--rw counter?     uint16
>                    |        +--:(lsc)
>                    |        |  +--rw wdm* [spectrum slot]
>                    |        |     +--rw spectrum    identityref
>                    |        |     +--rw slot        int16
>                    |        |     +--rw width?      uint16
>                    |        +--:(generic)
>                    |           +--rw generic?   te-bandwidth
>                    +--rw unreserved-bandwidth* [priority]
>                    |  +--rw priority     uint8
>                    |  +--rw bandwidth
>                    |     +--rw te-bandwidth
>                    |        +--rw (technology)?
>                    |           +--:(psc)
>
>
>
>                    |           |  +--rw psc?       rt-types:bandwidth-
>     ieee-float32
>                    |           +--:(otn)
>                    |           |  +--rw otn* [rate-type]
>                    |           |     +--rw rate-type    identityref
>                    |           |     +--rw counter?     uint16
>                    |           +--:(lsc)
>                    |           |  +--rw wdm* [spectrum slot]
>                    |           |     +--rw spectrum    identityref
>                    |           |     +--rw slot        int16
>                    |           |     +--rw width?      uint16
>                    |           +--:(generic)
>                    |              +--rw generic?   te-bandwidth
>                    +--rw te-default-metric?                uint32
>                    +--rw te-delay-metric?                  uint32
>                    +--rw te-igp-metric?                    uint32
>                    +--rw te-srlgs
>                    |  +--rw value*   te-types:srlg
>                    +--rw te-nsrlgs {nsrlg}?
>                       +--rw id*   uint32
>     augment /nw:networks/nw:network:
>        +--rw provider-id?      te-types:te-global-id
>        +--rw client-id?        te-types:te-global-id
>        +--rw te-topology-id?   te-types:te-topology-id
>        +--rw te!
>           +--rw preference?               uint8
>           +--rw optimization-criterion?   identityref
>           +--rw nsrlg* [id] {nsrlg}?
>           |  +--rw id              uint32
>           |  +--rw disjointness?   te-types:te-path-disjointness
>           +--ro geolocation
>              +--ro altitude?    int64
>              +--ro latitude?    geographic-coordinate-degree
>              +--ro longitude?   geographic-coordinate-degree
>     augment /nw:networks/nw:network/nw:node:
>        +--rw te-node-id?   te-types:te-node-id
>        +--rw te!
>           +--rw te-node-template*           leafref {template}?
>           +--rw te-node-attributes
>           |  +--rw admin-status?            te-types:te-admin-status
>           |  +--rw connectivity-matrices
>           |  |  +--rw number-of-entries?          uint16
>           |  |  +--rw label-restriction* [inclusive-exclusive label-
>     start]
>           |  |  |  +--rw inclusive-exclusive    enumeration
>           |  |  |  +--rw label-start            rt-types:generalized-
>     label
>
>
>
>           |  |  |  +--rw label-end?             rt-types:generalized-
>     label
>           |  |  |  +--rw range-bitmap?          binary
>           |  |  +--rw is-allowed?                 boolean
>           |  |  +--rw underlay {te-topology-hierarchy}?
>           |  |  |  +--rw enabled?                     boolean
>           |  |  |  +--rw primary-path
>           |  |  |  |  +--rw network-ref?    leafref
>           |  |  |  |  +--rw path-element* [path-element-id]
>           |  |  |  |     +--rw path-element-id    uint32
>           |  |  |  |     +--rw index?             uint32
>           |  |  |  |     +--rw (type)?
>           |  |  |  |        +--:(numbered)
>           |  |  |  |        |  +--rw numbered-hop
>           |  |  |  |        |     +--rw address?    te-types:te-tp-id
>           |  |  |  |        |     +--rw hop-type?   te-hop-type
>           |  |  |  |        +--:(as-number)
>           |  |  |  |        |  +--rw as-number-hop
>           |  |  |  |        |     +--rw as-number?   binary
>           |  |  |  |        |     +--rw hop-type?    te-hop-type
>           |  |  |  |        +--:(unnumbered)
>           |  |  |  |        |  +--rw unnumbered-hop
>           |  |  |  |        |     +--rw node-id?      te-types:te-node-id
>           |  |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>           |  |  |  |        |     +--rw hop-type?     te-hop-type
>           |  |  |  |        +--:(label)
>           |  |  |  |        |  +--rw label-hop
>           |  |  |  |        |     +--rw value?   rt-types:generalized-
>     label
>           |  |  |  |        +--:(sid)
>           |  |  |  |           +--rw sid-hop
>           |  |  |  |              +--rw sid?   rt-types:generalized-label
>           |  |  |  +--rw backup-path* [index]
>           |  |  |  |  +--rw index           uint32
>           |  |  |  |  +--rw network-ref?    leafref
>           |  |  |  |  +--rw path-element* [path-element-id]
>           |  |  |  |     +--rw path-element-id    uint32
>           |  |  |  |     +--rw index?             uint32
>           |  |  |  |     +--rw (type)?
>           |  |  |  |        +--:(numbered)
>           |  |  |  |        |  +--rw numbered-hop
>           |  |  |  |        |     +--rw address?    te-types:te-tp-id
>           |  |  |  |        |     +--rw hop-type?   te-hop-type
>           |  |  |  |        +--:(as-number)
>           |  |  |  |        |  +--rw as-number-hop
>           |  |  |  |        |     +--rw as-number?   binary
>           |  |  |  |        |     +--rw hop-type?    te-hop-type
>
>
>           |  |  |  |        +--:(unnumbered)
>           |  |  |  |        |  +--rw unnumbered-hop
>           |  |  |  |        |     +--rw node-id?      te-types:te-node-id
>           |  |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>           |  |  |  |        |     +--rw hop-type?     te-hop-type
>           |  |  |  |        +--:(label)
>           |  |  |  |        |  +--rw label-hop
>           |  |  |  |        |     +--rw value?   rt-types:generalized-
>     label
>           |  |  |  |        +--:(sid)
>           |  |  |  |           +--rw sid-hop
>           |  |  |  |              +--rw sid?   rt-types:generalized-label
>           |  |  |  +--rw protection-type?             identityref
>           |  |  |  +--rw tunnel-termination-points
>           |  |  |  |  +--rw source?        binary
>           |  |  |  |  +--rw destination?   binary
>           |  |  |  +--rw tunnels
>           |  |  |     +--rw sharing?   boolean
>           |  |  |     +--rw tunnel* [tunnel-name]
>           |  |  |        +--rw tunnel-name    string
>           |  |  |        +--rw sharing?       boolean
>           |  |  +--rw path-constraints
>           |  |  |  +--rw path-metric-bound* [metric-type]
>           |  |  |  |  +--rw metric-type    identityref
>           |  |  |  |  +--rw upper-bound?   uint64
>           |  |  |  +--rw topology-id?         te-types:te-topology-id
>           |  |  |  +--rw ignore-overload?     boolean
>           |  |  |  +--rw bandwidth-generic
>           |  |  |  |  +--rw te-bandwidth
>           |  |  |  |     +--rw (technology)?
>           |  |  |  |        +--:(psc)
>           |  |  |  |        |  +--rw psc?       rt-types:bandwidth-ieee-
>     float32
>           |  |  |  |        +--:(otn)
>           |  |  |  |        |  +--rw otn* [rate-type]
>           |  |  |  |        |     +--rw rate-type    identityref
>           |  |  |  |        |     +--rw counter?     uint16
>           |  |  |  |        +--:(lsc)
>           |  |  |  |        |  +--rw wdm* [spectrum slot]
>           |  |  |  |        |     +--rw spectrum    identityref
>           |  |  |  |        |     +--rw slot        int16
>           |  |  |  |        |     +--rw width?      uint16
>           |  |  |  |        +--:(generic)
>           |  |  |  |           +--rw generic?   te-bandwidth
>           |  |  |  +--rw disjointness?        te-types:te-path-
>     disjointness
>           |  |  |  +--rw setup-priority?      uint8
>
>
>           |  |  |  +--rw hold-priority?       uint8
>           |  |  |  +--rw signaling-type?      identityref
>           |  |  |  +--rw path-affinities
>           |  |  |  |  +--rw constraint* [usage]
>           |  |  |  |     +--rw usage    identityref
>           |  |  |  |     +--rw value?   admin-groups
>           |  |  |  +--rw path-srlgs
>           |  |  |     +--rw usage?    identityref
>           |  |  |     +--rw values*   srlg
>           |  |  +--rw optimizations
>           |  |  |  +--rw (algorithm)?
>           |  |  |     +--:(metric) {path-optimization-metric}?
>           |  |  |     |  +--rw optimization-metric* [metric-type]
>           |  |  |     |  |  +--rw metric-type    identityref
>           |  |  |     |  |  +--rw weight?        uint8
>           |  |  |     |  +--rw tiebreakers
>           |  |  |     |     +--rw tiebreaker* [tiebreaker-type]
>           |  |  |     |        +--rw tiebreaker-type    identityref
>           |  |  |     +--:(objective-function) {path-optimization-
>     objective-function}?
>           |  |  |        +--rw objective-function
>           |  |  |           +--rw objective-function-type?   identityref
>           |  |  +--ro computed-path-properties
>           |  |  |  +--ro path-metric* [metric-type]
>           |  |  |  |  +--ro metric-type           identityref
>           |  |  |  |  +--ro accumulative-value?   uint64
>           |  |  |  +--ro path-affinities
>           |  |  |  |  +--ro constraint* [usage]
>           |  |  |  |     +--ro usage    identityref
>           |  |  |  |     +--ro value?   admin-groups
>           |  |  |  +--ro path-srlgs
>           |  |  |  |  +--ro usage?    identityref
>           |  |  |  |  +--ro values*   srlg
>           |  |  |  +--ro path-computed-route-objects
>           |  |  |     +--ro path-computed-route-object* [index]
>           |  |  |        +--ro index             uint32
>           |  |  |        +--ro (type)?
>           |  |  |           +--:(numbered)
>           |  |  |           |  +--ro numbered-hop
>           |  |  |           |     +--ro address?    te-types:te-tp-id
>           |  |  |           |     +--ro hop-type?   te-hop-type
>           |  |  |           +--:(as-number)
>           |  |  |           |  +--ro as-number-hop
>           |  |  |           |     +--ro as-number?   binary
>           |  |  |           |     +--ro hop-type?    te-hop-type
>           |  |  |           +--:(unnumbered)
>           |  |  |           |  +--ro unnumbered-hop
>
>
>
>
>           |  |  |           |     +--ro node-id?      te-types:te-node-id
>           |  |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>           |  |  |           |     +--ro hop-type?     te-hop-type
>           |  |  |           +--:(label)
>           |  |  |           |  +--ro label-hop
>           |  |  |           |     +--ro value?   rt-types:generalized-
>     label
>           |  |  |           +--:(sid)
>           |  |  |              +--ro sid-hop
>           |  |  |                 +--ro sid?   rt-types:generalized-label
>           |  |  +--rw connectivity-matrix* [id]
>           |  |     +--rw id                          uint32
>           |  |     +--rw from
>           |  |     |  +--rw tp-ref?              leafref
>           |  |     |  +--rw label-restriction* [inclusive-exclusive
>     label-start]
>           |  |     |     +--rw inclusive-exclusive    enumeration
>           |  |     |     +--rw label-start            rt-
>     types:generalized-label
>           |  |     |     +--rw label-end?             rt-
>     types:generalized-label
>           |  |     |     +--rw range-bitmap?          binary
>           |  |     +--rw to
>           |  |     |  +--rw tp-ref?              leafref
>           |  |     |  +--rw label-restriction* [inclusive-exclusive
>     label-start]
>           |  |     |     +--rw inclusive-exclusive    enumeration
>           |  |     |     +--rw label-start            rt-
>     types:generalized-label
>           |  |     |     +--rw label-end?             rt-
>     types:generalized-label
>           |  |     |     +--rw range-bitmap?          binary
>           |  |     +--rw is-allowed?                 boolean
>           |  |     +--rw underlay {te-topology-hierarchy}?
>           |  |     |  +--rw enabled?                     boolean
>           |  |     |  +--rw primary-path
>           |  |     |  |  +--rw network-ref?    leafref
>           |  |     |  |  +--rw path-element* [path-element-id]
>           |  |     |  |     +--rw path-element-id    uint32
>           |  |     |  |     +--rw index?             uint32
>           |  |     |  |     +--rw (type)?
>           |  |     |  |        +--:(numbered)
>           |  |     |  |        |  +--rw numbered-hop
>           |  |     |  |        |     +--rw address?    te-types:te-tp-id
>           |  |     |  |        |     +--rw hop-type?   te-hop-type
>           |  |     |  |        +--:(as-number)
>           |  |     |  |        |  +--rw as-number-hop
>
>
>
>
>           |  |     |  |        |     +--rw as-number?   binary
>           |  |     |  |        |     +--rw hop-type?    te-hop-type
>           |  |     |  |        +--:(unnumbered)
>           |  |     |  |        |  +--rw unnumbered-hop
>           |  |     |  |        |     +--rw node-id?      te-types:te-
>     node-id
>           |  |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>     id
>           |  |     |  |        |     +--rw hop-type?     te-hop-type
>           |  |     |  |        +--:(label)
>           |  |     |  |        |  +--rw label-hop
>           |  |     |  |        |     +--rw value?   rt-types:generalized-
>     label
>           |  |     |  |        +--:(sid)
>           |  |     |  |           +--rw sid-hop
>           |  |     |  |              +--rw sid?   rt-types:generalized-
>     label
>           |  |     |  +--rw backup-path* [index]
>           |  |     |  |  +--rw index           uint32
>           |  |     |  |  +--rw network-ref?    leafref
>           |  |     |  |  +--rw path-element* [path-element-id]
>           |  |     |  |     +--rw path-element-id    uint32
>           |  |     |  |     +--rw index?             uint32
>           |  |     |  |     +--rw (type)?
>           |  |     |  |        +--:(numbered)
>           |  |     |  |        |  +--rw numbered-hop
>           |  |     |  |        |     +--rw address?    te-types:te-tp-id
>           |  |     |  |        |     +--rw hop-type?   te-hop-type
>           |  |     |  |        +--:(as-number)
>           |  |     |  |        |  +--rw as-number-hop
>           |  |     |  |        |     +--rw as-number?   binary
>           |  |     |  |        |     +--rw hop-type?    te-hop-type
>           |  |     |  |        +--:(unnumbered)
>           |  |     |  |        |  +--rw unnumbered-hop
>           |  |     |  |        |     +--rw node-id?      te-types:te-
>     node-id
>           |  |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>     id
>           |  |     |  |        |     +--rw hop-type?     te-hop-type
>           |  |     |  |        +--:(label)
>           |  |     |  |        |  +--rw label-hop
>           |  |     |  |        |     +--rw value?   rt-types:generalized-
>     label
>           |  |     |  |        +--:(sid)
>           |  |     |  |           +--rw sid-hop
>           |  |     |  |              +--rw sid?   rt-types:generalized-
>     label
>
>
>           |  |     |  +--rw protection-type?             identityref
>           |  |     |  +--rw tunnel-termination-points
>           |  |     |  |  +--rw source?        binary
>           |  |     |  |  +--rw destination?   binary
>           |  |     |  +--rw tunnels
>           |  |     |     +--rw sharing?   boolean
>           |  |     |     +--rw tunnel* [tunnel-name]
>           |  |     |        +--rw tunnel-name    string
>           |  |     |        +--rw sharing?       boolean
>           |  |     +--rw path-constraints
>           |  |     |  +--rw path-metric-bound* [metric-type]
>           |  |     |  |  +--rw metric-type    identityref
>           |  |     |  |  +--rw upper-bound?   uint64
>           |  |     |  +--rw topology-id?         te-types:te-topology-id
>           |  |     |  +--rw ignore-overload?     boolean
>           |  |     |  +--rw bandwidth-generic
>           |  |     |  |  +--rw te-bandwidth
>           |  |     |  |     +--rw (technology)?
>           |  |     |  |        +--:(psc)
>           |  |     |  |        |  +--rw psc?       rt-types:bandwidth-
>     ieee-float32
>           |  |     |  |        +--:(otn)
>           |  |     |  |        |  +--rw otn* [rate-type]
>           |  |     |  |        |     +--rw rate-type    identityref
>           |  |     |  |        |     +--rw counter?     uint16
>           |  |     |  |        +--:(lsc)
>           |  |     |  |        |  +--rw wdm* [spectrum slot]
>           |  |     |  |        |     +--rw spectrum    identityref
>           |  |     |  |        |     +--rw slot        int16
>           |  |     |  |        |     +--rw width?      uint16
>           |  |     |  |        +--:(generic)
>           |  |     |  |           +--rw generic?   te-bandwidth
>           |  |     |  +--rw disjointness?        te-types:te-path-
>     disjointness
>           |  |     |  +--rw setup-priority?      uint8
>           |  |     |  +--rw hold-priority?       uint8
>           |  |     |  +--rw signaling-type?      identityref
>           |  |     |  +--rw path-affinities
>           |  |     |  |  +--rw constraint* [usage]
>           |  |     |  |     +--rw usage    identityref
>           |  |     |  |     +--rw value?   admin-groups
>           |  |     |  +--rw path-srlgs
>           |  |     |     +--rw usage?    identityref
>           |  |     |     +--rw values*   srlg
>           |  |     +--rw optimizations
>           |  |     |  +--rw (algorithm)?
>           |  |     |     +--:(metric) {path-optimization-metric}?
>
>
>           |  |     |     |  +--rw optimization-metric* [metric-type]
>           |  |     |     |  |  +--rw metric-type    identityref
>           |  |     |     |  |  +--rw weight?        uint8
>           |  |     |     |  +--rw tiebreakers
>           |  |     |     |     +--rw tiebreaker* [tiebreaker-type]
>           |  |     |     |        +--rw tiebreaker-type    identityref
>           |  |     |     +--:(objective-function) {path-optimization-
>     objective-function}?
>           |  |     |        +--rw objective-function
>           |  |     |           +--rw objective-function-type?
>     identityref
>           |  |     +--ro computed-path-properties
>           |  |        +--ro path-metric* [metric-type]
>           |  |        |  +--ro metric-type           identityref
>           |  |        |  +--ro accumulative-value?   uint64
>           |  |        +--ro path-affinities
>           |  |        |  +--ro constraint* [usage]
>           |  |        |     +--ro usage    identityref
>           |  |        |     +--ro value?   admin-groups
>           |  |        +--ro path-srlgs
>           |  |        |  +--ro usage?    identityref
>           |  |        |  +--ro values*   srlg
>           |  |        +--ro path-computed-route-objects
>           |  |           +--ro path-computed-route-object* [index]
>           |  |              +--ro index             uint32
>           |  |              +--ro (type)?
>           |  |                 +--:(numbered)
>           |  |                 |  +--ro numbered-hop
>           |  |                 |     +--ro address?    te-types:te-tp-id
>           |  |                 |     +--ro hop-type?   te-hop-type
>           |  |                 +--:(as-number)
>           |  |                 |  +--ro as-number-hop
>           |  |                 |     +--ro as-number?   binary
>           |  |                 |     +--ro hop-type?    te-hop-type
>           |  |                 +--:(unnumbered)
>           |  |                 |  +--ro unnumbered-hop
>           |  |                 |     +--ro node-id?      te-types:te-
>     node-id
>           |  |                 |     +--ro link-tp-id?   te-types:te-tp-
>     id
>           |  |                 |     +--ro hop-type?     te-hop-type
>           |  |                 +--:(label)
>           |  |                 |  +--ro label-hop
>           |  |                 |     +--ro value?   rt-types:generalized-
>     label
>           |  |                 +--:(sid)
>           |  |                    +--ro sid-hop
>
>           |  |                       +--ro sid?   rt-types:generalized-
>     label
>           |  +--rw domain-id?               uint32
>           |  +--rw is-abstract?             empty
>           |  +--rw name?                    inet:domain-name
>           |  +--rw signaling-address*       inet:ip-address
>           |  +--rw underlay-topology {te-topology-hierarchy}?
>           |     +--rw network-ref?   leafref
>           +--ro oper-status?                te-types:te-oper-status
>           +--ro geolocation
>           |  +--ro altitude?    int64
>           |  +--ro latitude?    geographic-coordinate-degree
>           |  +--ro longitude?   geographic-coordinate-degree
>           +--ro is-multi-access-dr?         empty
>           +--ro information-source?         te-info-source
>           +--ro information-source-state
>           |  +--ro credibility-preference?    uint16
>           |  +--ro logical-network-element?   string
>           |  +--ro network-instance?          string
>           |  +--ro topology
>           |     +--ro node-ref?      leafref
>           |     +--ro network-ref?   leafref
>           +--ro information-source-entry* [information-source]
>           |  +--ro information-source          te-info-source
>           |  +--ro information-source-state
>           |  |  +--ro credibility-preference?    uint16
>           |  |  +--ro logical-network-element?   string
>           |  |  +--ro network-instance?          string
>           |  |  +--ro topology
>           |  |     +--ro node-ref?      leafref
>           |  |     +--ro network-ref?   leafref
>           |  +--ro connectivity-matrices
>           |  |  +--ro number-of-entries?          uint16
>           |  |  +--ro label-restriction* [inclusive-exclusive label-
>     start]
>           |  |  |  +--ro inclusive-exclusive    enumeration
>           |  |  |  +--ro label-start            rt-types:generalized-
>     label
>           |  |  |  +--ro label-end?             rt-types:generalized-
>     label
>           |  |  |  +--ro range-bitmap?          binary
>           |  |  +--ro is-allowed?                 boolean
>           |  |  +--ro underlay {te-topology-hierarchy}?
>           |  |  |  +--ro enabled?                     boolean
>           |  |  |  +--ro primary-path
>           |  |  |  |  +--ro network-ref?    leafref
>           |  |  |  |  +--ro path-element* [path-element-id]
>
>
>           |  |  |  |     +--ro path-element-id    uint32
>           |  |  |  |     +--ro index?             uint32
>           |  |  |  |     +--ro (type)?
>           |  |  |  |        +--:(numbered)
>           |  |  |  |        |  +--ro numbered-hop
>           |  |  |  |        |     +--ro address?    te-types:te-tp-id
>           |  |  |  |        |     +--ro hop-type?   te-hop-type
>           |  |  |  |        +--:(as-number)
>           |  |  |  |        |  +--ro as-number-hop
>           |  |  |  |        |     +--ro as-number?   binary
>           |  |  |  |        |     +--ro hop-type?    te-hop-type
>           |  |  |  |        +--:(unnumbered)
>           |  |  |  |        |  +--ro unnumbered-hop
>           |  |  |  |        |     +--ro node-id?      te-types:te-node-id
>           |  |  |  |        |     +--ro link-tp-id?   te-types:te-tp-id
>           |  |  |  |        |     +--ro hop-type?     te-hop-type
>           |  |  |  |        +--:(label)
>           |  |  |  |        |  +--ro label-hop
>           |  |  |  |        |     +--ro value?   rt-types:generalized-
>     label
>           |  |  |  |        +--:(sid)
>           |  |  |  |           +--ro sid-hop
>           |  |  |  |              +--ro sid?   rt-types:generalized-label
>           |  |  |  +--ro backup-path* [index]
>           |  |  |  |  +--ro index           uint32
>           |  |  |  |  +--ro network-ref?    leafref
>           |  |  |  |  +--ro path-element* [path-element-id]
>           |  |  |  |     +--ro path-element-id    uint32
>           |  |  |  |     +--ro index?             uint32
>           |  |  |  |     +--ro (type)?
>           |  |  |  |        +--:(numbered)
>           |  |  |  |        |  +--ro numbered-hop
>           |  |  |  |        |     +--ro address?    te-types:te-tp-id
>           |  |  |  |        |     +--ro hop-type?   te-hop-type
>           |  |  |  |        +--:(as-number)
>           |  |  |  |        |  +--ro as-number-hop
>           |  |  |  |        |     +--ro as-number?   binary
>           |  |  |  |        |     +--ro hop-type?    te-hop-type
>           |  |  |  |        +--:(unnumbered)
>           |  |  |  |        |  +--ro unnumbered-hop
>           |  |  |  |        |     +--ro node-id?      te-types:te-node-id
>           |  |  |  |        |     +--ro link-tp-id?   te-types:te-tp-id
>           |  |  |  |        |     +--ro hop-type?     te-hop-type
>           |  |  |  |        +--:(label)
>           |  |  |  |        |  +--ro label-hop
>           |  |  |  |        |     +--ro value?   rt-types:generalized-
>     label
>
>
>           |  |  |  |        +--:(sid)
>           |  |  |  |           +--ro sid-hop
>           |  |  |  |              +--ro sid?   rt-types:generalized-label
>           |  |  |  +--ro protection-type?             identityref
>           |  |  |  +--ro tunnel-termination-points
>           |  |  |  |  +--ro source?        binary
>           |  |  |  |  +--ro destination?   binary
>           |  |  |  +--ro tunnels
>           |  |  |     +--ro sharing?   boolean
>           |  |  |     +--ro tunnel* [tunnel-name]
>           |  |  |        +--ro tunnel-name    string
>           |  |  |        +--ro sharing?       boolean
>           |  |  +--ro path-constraints
>           |  |  |  +--ro path-metric-bound* [metric-type]
>           |  |  |  |  +--ro metric-type    identityref
>           |  |  |  |  +--ro upper-bound?   uint64
>           |  |  |  +--ro topology-id?         te-types:te-topology-id
>           |  |  |  +--ro ignore-overload?     boolean
>           |  |  |  +--ro bandwidth-generic
>           |  |  |  |  +--ro te-bandwidth
>           |  |  |  |     +--ro (technology)?
>           |  |  |  |        +--:(psc)
>           |  |  |  |        |  +--ro psc?       rt-types:bandwidth-ieee-
>     float32
>           |  |  |  |        +--:(otn)
>           |  |  |  |        |  +--ro otn* [rate-type]
>           |  |  |  |        |     +--ro rate-type    identityref
>           |  |  |  |        |     +--ro counter?     uint16
>           |  |  |  |        +--:(lsc)
>           |  |  |  |        |  +--ro wdm* [spectrum slot]
>           |  |  |  |        |     +--ro spectrum    identityref
>           |  |  |  |        |     +--ro slot        int16
>           |  |  |  |        |     +--ro width?      uint16
>           |  |  |  |        +--:(generic)
>           |  |  |  |           +--ro generic?   te-bandwidth
>           |  |  |  +--ro disjointness?        te-types:te-path-
>     disjointness
>           |  |  |  +--ro setup-priority?      uint8
>           |  |  |  +--ro hold-priority?       uint8
>           |  |  |  +--ro signaling-type?      identityref
>           |  |  |  +--ro path-affinities
>           |  |  |  |  +--ro constraint* [usage]
>           |  |  |  |     +--ro usage    identityref
>           |  |  |  |     +--ro value?   admin-groups
>           |  |  |  +--ro path-srlgs
>           |  |  |     +--ro usage?    identityref
>           |  |  |     +--ro values*   srlg
>
>
>           |  |  +--ro optimizations
>           |  |  |  +--ro (algorithm)?
>           |  |  |     +--:(metric) {path-optimization-metric}?
>           |  |  |     |  +--ro optimization-metric* [metric-type]
>           |  |  |     |  |  +--ro metric-type    identityref
>           |  |  |     |  |  +--ro weight?        uint8
>           |  |  |     |  +--ro tiebreakers
>           |  |  |     |     +--ro tiebreaker* [tiebreaker-type]
>           |  |  |     |        +--ro tiebreaker-type    identityref
>           |  |  |     +--:(objective-function) {path-optimization-
>     objective-function}?
>           |  |  |        +--ro objective-function
>           |  |  |           +--ro objective-function-type?   identityref
>           |  |  +--ro computed-path-properties
>           |  |  |  +--ro path-metric* [metric-type]
>           |  |  |  |  +--ro metric-type           identityref
>           |  |  |  |  +--ro accumulative-value?   uint64
>           |  |  |  +--ro path-affinities
>           |  |  |  |  +--ro constraint* [usage]
>           |  |  |  |     +--ro usage    identityref
>           |  |  |  |     +--ro value?   admin-groups
>           |  |  |  +--ro path-srlgs
>           |  |  |  |  +--ro usage?    identityref
>           |  |  |  |  +--ro values*   srlg
>           |  |  |  +--ro path-computed-route-objects
>           |  |  |     +--ro path-computed-route-object* [index]
>           |  |  |        +--ro index             uint32
>           |  |  |        +--ro (type)?
>           |  |  |           +--:(numbered)
>           |  |  |           |  +--ro numbered-hop
>           |  |  |           |     +--ro address?    te-types:te-tp-id
>           |  |  |           |     +--ro hop-type?   te-hop-type
>           |  |  |           +--:(as-number)
>           |  |  |           |  +--ro as-number-hop
>           |  |  |           |     +--ro as-number?   binary
>           |  |  |           |     +--ro hop-type?    te-hop-type
>           |  |  |           +--:(unnumbered)
>           |  |  |           |  +--ro unnumbered-hop
>           |  |  |           |     +--ro node-id?      te-types:te-node-id
>           |  |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>           |  |  |           |     +--ro hop-type?     te-hop-type
>           |  |  |           +--:(label)
>           |  |  |           |  +--ro label-hop
>           |  |  |           |     +--ro value?   rt-types:generalized-
>     label
>           |  |  |           +--:(sid)
>           |  |  |              +--ro sid-hop
>
>
>           |  |  |                 +--ro sid?   rt-types:generalized-label
>           |  |  +--ro connectivity-matrix* [id]
>           |  |     +--ro id                          uint32
>           |  |     +--ro from
>           |  |     |  +--ro tp-ref?              leafref
>           |  |     |  +--ro label-restriction* [inclusive-exclusive
>     label-start]
>           |  |     |     +--ro inclusive-exclusive    enumeration
>           |  |     |     +--ro label-start            rt-
>     types:generalized-label
>           |  |     |     +--ro label-end?             rt-
>     types:generalized-label
>           |  |     |     +--ro range-bitmap?          binary
>           |  |     +--ro to
>           |  |     |  +--ro tp-ref?              leafref
>           |  |     |  +--ro label-restriction* [inclusive-exclusive
>     label-start]
>           |  |     |     +--ro inclusive-exclusive    enumeration
>           |  |     |     +--ro label-start            rt-
>     types:generalized-label
>           |  |     |     +--ro label-end?             rt-
>     types:generalized-label
>           |  |     |     +--ro range-bitmap?          binary
>           |  |     +--ro is-allowed?                 boolean
>           |  |     +--ro underlay {te-topology-hierarchy}?
>           |  |     |  +--ro enabled?                     boolean
>           |  |     |  +--ro primary-path
>           |  |     |  |  +--ro network-ref?    leafref
>           |  |     |  |  +--ro path-element* [path-element-id]
>           |  |     |  |     +--ro path-element-id    uint32
>           |  |     |  |     +--ro index?             uint32
>           |  |     |  |     +--ro (type)?
>           |  |     |  |        +--:(numbered)
>           |  |     |  |        |  +--ro numbered-hop
>           |  |     |  |        |     +--ro address?    te-types:te-tp-id
>           |  |     |  |        |     +--ro hop-type?   te-hop-type
>           |  |     |  |        +--:(as-number)
>           |  |     |  |        |  +--ro as-number-hop
>           |  |     |  |        |     +--ro as-number?   binary
>           |  |     |  |        |     +--ro hop-type?    te-hop-type
>           |  |     |  |        +--:(unnumbered)
>           |  |     |  |        |  +--ro unnumbered-hop
>           |  |     |  |        |     +--ro node-id?      te-types:te-
>     node-id
>           |  |     |  |        |     +--ro link-tp-id?   te-types:te-tp-
>     id
>           |  |     |  |        |     +--ro hop-type?     te-hop-type
>
>
>           |  |     |  |        +--:(label)
>           |  |     |  |        |  +--ro label-hop
>           |  |     |  |        |     +--ro value?   rt-types:generalized-
>     label
>           |  |     |  |        +--:(sid)
>           |  |     |  |           +--ro sid-hop
>           |  |     |  |              +--ro sid?   rt-types:generalized-
>     label
>           |  |     |  +--ro backup-path* [index]
>           |  |     |  |  +--ro index           uint32
>           |  |     |  |  +--ro network-ref?    leafref
>           |  |     |  |  +--ro path-element* [path-element-id]
>           |  |     |  |     +--ro path-element-id    uint32
>           |  |     |  |     +--ro index?             uint32
>           |  |     |  |     +--ro (type)?
>           |  |     |  |        +--:(numbered)
>           |  |     |  |        |  +--ro numbered-hop
>           |  |     |  |        |     +--ro address?    te-types:te-tp-id
>           |  |     |  |        |     +--ro hop-type?   te-hop-type
>           |  |     |  |        +--:(as-number)
>           |  |     |  |        |  +--ro as-number-hop
>           |  |     |  |        |     +--ro as-number?   binary
>           |  |     |  |        |     +--ro hop-type?    te-hop-type
>           |  |     |  |        +--:(unnumbered)
>           |  |     |  |        |  +--ro unnumbered-hop
>           |  |     |  |        |     +--ro node-id?      te-types:te-
>     node-id
>           |  |     |  |        |     +--ro link-tp-id?   te-types:te-tp-
>     id
>           |  |     |  |        |     +--ro hop-type?     te-hop-type
>           |  |     |  |        +--:(label)
>           |  |     |  |        |  +--ro label-hop
>           |  |     |  |        |     +--ro value?   rt-types:generalized-
>     label
>           |  |     |  |        +--:(sid)
>           |  |     |  |           +--ro sid-hop
>           |  |     |  |              +--ro sid?   rt-types:generalized-
>     label
>           |  |     |  +--ro protection-type?             identityref
>           |  |     |  +--ro tunnel-termination-points
>           |  |     |  |  +--ro source?        binary
>           |  |     |  |  +--ro destination?   binary
>           |  |     |  +--ro tunnels
>           |  |     |     +--ro sharing?   boolean
>           |  |     |     +--ro tunnel* [tunnel-name]
>           |  |     |        +--ro tunnel-name    string
>           |  |     |        +--ro sharing?       boolean
>
>
>
>           |  |     +--ro path-constraints
>           |  |     |  +--ro path-metric-bound* [metric-type]
>           |  |     |  |  +--ro metric-type    identityref
>           |  |     |  |  +--ro upper-bound?   uint64
>           |  |     |  +--ro topology-id?         te-types:te-topology-id
>           |  |     |  +--ro ignore-overload?     boolean
>           |  |     |  +--ro bandwidth-generic
>           |  |     |  |  +--ro te-bandwidth
>           |  |     |  |     +--ro (technology)?
>           |  |     |  |        +--:(psc)
>           |  |     |  |        |  +--ro psc?       rt-types:bandwidth-
>     ieee-float32
>           |  |     |  |        +--:(otn)
>           |  |     |  |        |  +--ro otn* [rate-type]
>           |  |     |  |        |     +--ro rate-type    identityref
>           |  |     |  |        |     +--ro counter?     uint16
>           |  |     |  |        +--:(lsc)
>           |  |     |  |        |  +--ro wdm* [spectrum slot]
>           |  |     |  |        |     +--ro spectrum    identityref
>           |  |     |  |        |     +--ro slot        int16
>           |  |     |  |        |     +--ro width?      uint16
>           |  |     |  |        +--:(generic)
>           |  |     |  |           +--ro generic?   te-bandwidth
>           |  |     |  +--ro disjointness?        te-types:te-path-
>     disjointness
>           |  |     |  +--ro setup-priority?      uint8
>           |  |     |  +--ro hold-priority?       uint8
>           |  |     |  +--ro signaling-type?      identityref
>           |  |     |  +--ro path-affinities
>           |  |     |  |  +--ro constraint* [usage]
>           |  |     |  |     +--ro usage    identityref
>           |  |     |  |     +--ro value?   admin-groups
>           |  |     |  +--ro path-srlgs
>           |  |     |     +--ro usage?    identityref
>           |  |     |     +--ro values*   srlg
>           |  |     +--ro optimizations
>           |  |     |  +--ro (algorithm)?
>           |  |     |     +--:(metric) {path-optimization-metric}?
>           |  |     |     |  +--ro optimization-metric* [metric-type]
>           |  |     |     |  |  +--ro metric-type    identityref
>           |  |     |     |  |  +--ro weight?        uint8
>           |  |     |     |  +--ro tiebreakers
>           |  |     |     |     +--ro tiebreaker* [tiebreaker-type]
>           |  |     |     |        +--ro tiebreaker-type    identityref
>           |  |     |     +--:(objective-function) {path-optimization-
>     objective-function}?
>           |  |     |        +--ro objective-function
>
>
>           |  |     |           +--ro objective-function-type?
>     identityref
>           |  |     +--ro computed-path-properties
>           |  |        +--ro path-metric* [metric-type]
>           |  |        |  +--ro metric-type           identityref
>           |  |        |  +--ro accumulative-value?   uint64
>           |  |        +--ro path-affinities
>           |  |        |  +--ro constraint* [usage]
>           |  |        |     +--ro usage    identityref
>           |  |        |     +--ro value?   admin-groups
>           |  |        +--ro path-srlgs
>           |  |        |  +--ro usage?    identityref
>           |  |        |  +--ro values*   srlg
>           |  |        +--ro path-computed-route-objects
>           |  |           +--ro path-computed-route-object* [index]
>           |  |              +--ro index             uint32
>           |  |              +--ro (type)?
>           |  |                 +--:(numbered)
>           |  |                 |  +--ro numbered-hop
>           |  |                 |     +--ro address?    te-types:te-tp-id
>           |  |                 |     +--ro hop-type?   te-hop-type
>           |  |                 +--:(as-number)
>           |  |                 |  +--ro as-number-hop
>           |  |                 |     +--ro as-number?   binary
>           |  |                 |     +--ro hop-type?    te-hop-type
>           |  |                 +--:(unnumbered)
>           |  |                 |  +--ro unnumbered-hop
>           |  |                 |     +--ro node-id?      te-types:te-
>     node-id
>           |  |                 |     +--ro link-tp-id?   te-types:te-tp-
>     id
>           |  |                 |     +--ro hop-type?     te-hop-type
>           |  |                 +--:(label)
>           |  |                 |  +--ro label-hop
>           |  |                 |     +--ro value?   rt-types:generalized-
>     label
>           |  |                 +--:(sid)
>           |  |                    +--ro sid-hop
>           |  |                       +--ro sid?   rt-types:generalized-
>     label
>           |  +--ro domain-id?                  uint32
>           |  +--ro is-abstract?                empty
>           |  +--ro name?                       inet:domain-name
>           |  +--ro signaling-address*          inet:ip-address
>           |  +--ro underlay-topology {te-topology-hierarchy}?
>           |     +--ro network-ref?   leafref
>           +--ro statistics
>
>
>
>           |  +--ro discontinuity-time           yang:date-and-time
>           |  +--ro node
>           |  |  +--ro disables?             yang:counter32
>           |  |  +--ro enables?              yang:counter32
>           |  |  +--ro maintenance-sets?     yang:counter32
>           |  |  +--ro maintenance-clears?   yang:counter32
>           |  |  +--ro modifies?             yang:counter32
>           |  +--ro connectivity-matrix-entry
>           |     +--ro creates?    yang:counter32
>           |     +--ro deletes?    yang:counter32
>           |     +--ro disables?   yang:counter32
>           |     +--ro enables?    yang:counter32
>           |     +--ro modifies?   yang:counter32
>           +--rw tunnel-termination-point* [tunnel-tp-id]
>              +--rw tunnel-tp-id                           binary
>              +--rw admin-status?                          te-types:te-
>     admin-status
>              +--rw name?                                  string
>              +--rw switching-capability?                  identityref
>              +--rw encoding?                              identityref
>              +--rw inter-layer-lock-id*                   uint32
>              +--rw protection-type?                       identityref
>              +--rw client-layer-adaptation
>              |  +--rw switching-capability* [switching-capability
>     encoding]
>              |     +--rw switching-capability    identityref
>              |     +--rw encoding                identityref
>              |     +--rw bandwidth
>              |        +--rw te-bandwidth
>              |           +--rw (technology)?
>              |              +--:(psc)
>              |              |  +--rw psc?       rt-types:bandwidth-ieee-
>     float32
>              |              +--:(otn)
>              |              |  +--rw otn* [rate-type]
>              |              |     +--rw rate-type    identityref
>              |              |     +--rw counter?     uint16
>              |              +--:(lsc)
>              |              |  +--rw wdm* [spectrum slot]
>              |              |     +--rw spectrum    identityref
>              |              |     +--rw slot        int16
>              |              |     +--rw width?      uint16
>              |              +--:(generic)
>              |                 +--rw generic?   te-bandwidth
>              +--rw local-link-connectivities
>              |  +--rw number-of-entries?          uint16
>
>
>
>              |  +--rw label-restriction* [inclusive-exclusive label-
>     start]
>              |  |  +--rw inclusive-exclusive    enumeration
>              |  |  +--rw label-start            rt-types:generalized-
>     label
>              |  |  +--rw label-end?             rt-types:generalized-
>     label
>              |  |  +--rw range-bitmap?          binary
>              |  +--rw is-allowed?                 boolean
>              |  +--rw underlay {te-topology-hierarchy}?
>              |  |  +--rw enabled?                     boolean
>              |  |  +--rw primary-path
>              |  |  |  +--rw network-ref?    leafref
>              |  |  |  +--rw path-element* [path-element-id]
>              |  |  |     +--rw path-element-id    uint32
>              |  |  |     +--rw index?             uint32
>              |  |  |     +--rw (type)?
>              |  |  |        +--:(numbered)
>              |  |  |        |  +--rw numbered-hop
>              |  |  |        |     +--rw address?    te-types:te-tp-id
>              |  |  |        |     +--rw hop-type?   te-hop-type
>              |  |  |        +--:(as-number)
>              |  |  |        |  +--rw as-number-hop
>              |  |  |        |     +--rw as-number?   binary
>              |  |  |        |     +--rw hop-type?    te-hop-type
>              |  |  |        +--:(unnumbered)
>              |  |  |        |  +--rw unnumbered-hop
>              |  |  |        |     +--rw node-id?      te-types:te-node-id
>              |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>              |  |  |        |     +--rw hop-type?     te-hop-type
>              |  |  |        +--:(label)
>              |  |  |        |  +--rw label-hop
>              |  |  |        |     +--rw value?   rt-types:generalized-
>     label
>              |  |  |        +--:(sid)
>              |  |  |           +--rw sid-hop
>              |  |  |              +--rw sid?   rt-types:generalized-label
>              |  |  +--rw backup-path* [index]
>              |  |  |  +--rw index           uint32
>              |  |  |  +--rw network-ref?    leafref
>              |  |  |  +--rw path-element* [path-element-id]
>              |  |  |     +--rw path-element-id    uint32
>              |  |  |     +--rw index?             uint32
>              |  |  |     +--rw (type)?
>              |  |  |        +--:(numbered)
>              |  |  |        |  +--rw numbered-hop
>              |  |  |        |     +--rw address?    te-types:te-tp-id
>
>
>
>
>              |  |  |        |     +--rw hop-type?   te-hop-type
>              |  |  |        +--:(as-number)
>              |  |  |        |  +--rw as-number-hop
>              |  |  |        |     +--rw as-number?   binary
>              |  |  |        |     +--rw hop-type?    te-hop-type
>              |  |  |        +--:(unnumbered)
>              |  |  |        |  +--rw unnumbered-hop
>              |  |  |        |     +--rw node-id?      te-types:te-node-id
>              |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>              |  |  |        |     +--rw hop-type?     te-hop-type
>              |  |  |        +--:(label)
>              |  |  |        |  +--rw label-hop
>              |  |  |        |     +--rw value?   rt-types:generalized-
>     label
>              |  |  |        +--:(sid)
>              |  |  |           +--rw sid-hop
>              |  |  |              +--rw sid?   rt-types:generalized-label
>              |  |  +--rw protection-type?             identityref
>              |  |  +--rw tunnel-termination-points
>              |  |  |  +--rw source?        binary
>              |  |  |  +--rw destination?   binary
>              |  |  +--rw tunnels
>              |  |     +--rw sharing?   boolean
>              |  |     +--rw tunnel* [tunnel-name]
>              |  |        +--rw tunnel-name    string
>              |  |        +--rw sharing?       boolean
>              |  +--rw path-constraints
>              |  |  +--rw path-metric-bound* [metric-type]
>              |  |  |  +--rw metric-type    identityref
>              |  |  |  +--rw upper-bound?   uint64
>              |  |  +--rw topology-id?         te-types:te-topology-id
>              |  |  +--rw ignore-overload?     boolean
>              |  |  +--rw bandwidth-generic
>              |  |  |  +--rw te-bandwidth
>              |  |  |     +--rw (technology)?
>              |  |  |        +--:(psc)
>              |  |  |        |  +--rw psc?       rt-types:bandwidth-ieee-
>     float32
>              |  |  |        +--:(otn)
>              |  |  |        |  +--rw otn* [rate-type]
>              |  |  |        |     +--rw rate-type    identityref
>              |  |  |        |     +--rw counter?     uint16
>              |  |  |        +--:(lsc)
>              |  |  |        |  +--rw wdm* [spectrum slot]
>              |  |  |        |     +--rw spectrum    identityref
>              |  |  |        |     +--rw slot        int16
>              |  |  |        |     +--rw width?      uint16
>
>
>
>
>              |  |  |        +--:(generic)
>              |  |  |           +--rw generic?   te-bandwidth
>              |  |  +--rw disjointness?        te-types:te-path-
>     disjointness
>              |  |  +--rw setup-priority?      uint8
>              |  |  +--rw hold-priority?       uint8
>              |  |  +--rw signaling-type?      identityref
>              |  |  +--rw path-affinities
>              |  |  |  +--rw constraint* [usage]
>              |  |  |     +--rw usage    identityref
>              |  |  |     +--rw value?   admin-groups
>              |  |  +--rw path-srlgs
>              |  |     +--rw usage?    identityref
>              |  |     +--rw values*   srlg
>              |  +--rw optimizations
>              |  |  +--rw (algorithm)?
>              |  |     +--:(metric) {path-optimization-metric}?
>              |  |     |  +--rw optimization-metric* [metric-type]
>              |  |     |  |  +--rw metric-type    identityref
>              |  |     |  |  +--rw weight?        uint8
>              |  |     |  +--rw tiebreakers
>              |  |     |     +--rw tiebreaker* [tiebreaker-type]
>              |  |     |        +--rw tiebreaker-type    identityref
>              |  |     +--:(objective-function) {path-optimization-
>     objective-function}?
>              |  |        +--rw objective-function
>              |  |           +--rw objective-function-type?   identityref
>              |  +--ro computed-path-properties
>              |  |  +--ro path-metric* [metric-type]
>              |  |  |  +--ro metric-type           identityref
>              |  |  |  +--ro accumulative-value?   uint64
>              |  |  +--ro path-affinities
>              |  |  |  +--ro constraint* [usage]
>              |  |  |     +--ro usage    identityref
>              |  |  |     +--ro value?   admin-groups
>              |  |  +--ro path-srlgs
>              |  |  |  +--ro usage?    identityref
>              |  |  |  +--ro values*   srlg
>              |  |  +--ro path-computed-route-objects
>              |  |     +--ro path-computed-route-object* [index]
>              |  |        +--ro index             uint32
>              |  |        +--ro (type)?
>              |  |           +--:(numbered)
>              |  |           |  +--ro numbered-hop
>              |  |           |     +--ro address?    te-types:te-tp-id
>              |  |           |     +--ro hop-type?   te-hop-type
>              |  |           +--:(as-number)
>
>
>
>              |  |           |  +--ro as-number-hop
>              |  |           |     +--ro as-number?   binary
>              |  |           |     +--ro hop-type?    te-hop-type
>              |  |           +--:(unnumbered)
>              |  |           |  +--ro unnumbered-hop
>              |  |           |     +--ro node-id?      te-types:te-node-id
>              |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>              |  |           |     +--ro hop-type?     te-hop-type
>              |  |           +--:(label)
>              |  |           |  +--ro label-hop
>              |  |           |     +--ro value?   rt-types:generalized-
>     label
>              |  |           +--:(sid)
>              |  |              +--ro sid-hop
>              |  |                 +--ro sid?   rt-types:generalized-label
>              |  +--rw local-link-connectivity* [link-tp-ref]
>              |     +--rw link-tp-ref                 leafref
>              |     +--rw label-restriction* [inclusive-exclusive label-
>     start]
>              |     |  +--rw inclusive-exclusive    enumeration
>              |     |  +--rw label-start            rt-types:generalized-
>     label
>              |     |  +--rw label-end?             rt-types:generalized-
>     label
>              |     |  +--rw range-bitmap?          binary
>              |     +--rw is-allowed?                 boolean
>              |     +--rw underlay {te-topology-hierarchy}?
>              |     |  +--rw enabled?                     boolean
>              |     |  +--rw primary-path
>              |     |  |  +--rw network-ref?    leafref
>              |     |  |  +--rw path-element* [path-element-id]
>              |     |  |     +--rw path-element-id    uint32
>              |     |  |     +--rw index?             uint32
>              |     |  |     +--rw (type)?
>              |     |  |        +--:(numbered)
>              |     |  |        |  +--rw numbered-hop
>              |     |  |        |     +--rw address?    te-types:te-tp-id
>              |     |  |        |     +--rw hop-type?   te-hop-type
>              |     |  |        +--:(as-number)
>              |     |  |        |  +--rw as-number-hop
>              |     |  |        |     +--rw as-number?   binary
>              |     |  |        |     +--rw hop-type?    te-hop-type
>              |     |  |        +--:(unnumbered)
>              |     |  |        |  +--rw unnumbered-hop
>              |     |  |        |     +--rw node-id?      te-types:te-
>     node-id
>
>
>
>
>              |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>     id
>              |     |  |        |     +--rw hop-type?     te-hop-type
>              |     |  |        +--:(label)
>              |     |  |        |  +--rw label-hop
>              |     |  |        |     +--rw value?   rt-types:generalized-
>     label
>              |     |  |        +--:(sid)
>              |     |  |           +--rw sid-hop
>              |     |  |              +--rw sid?   rt-types:generalized-
>     label
>              |     |  +--rw backup-path* [index]
>              |     |  |  +--rw index           uint32
>              |     |  |  +--rw network-ref?    leafref
>              |     |  |  +--rw path-element* [path-element-id]
>              |     |  |     +--rw path-element-id    uint32
>              |     |  |     +--rw index?             uint32
>              |     |  |     +--rw (type)?
>              |     |  |        +--:(numbered)
>              |     |  |        |  +--rw numbered-hop
>              |     |  |        |     +--rw address?    te-types:te-tp-id
>              |     |  |        |     +--rw hop-type?   te-hop-type
>              |     |  |        +--:(as-number)
>              |     |  |        |  +--rw as-number-hop
>              |     |  |        |     +--rw as-number?   binary
>              |     |  |        |     +--rw hop-type?    te-hop-type
>              |     |  |        +--:(unnumbered)
>              |     |  |        |  +--rw unnumbered-hop
>              |     |  |        |     +--rw node-id?      te-types:te-
>     node-id
>              |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>     id
>              |     |  |        |     +--rw hop-type?     te-hop-type
>              |     |  |        +--:(label)
>              |     |  |        |  +--rw label-hop
>              |     |  |        |     +--rw value?   rt-types:generalized-
>     label
>              |     |  |        +--:(sid)
>              |     |  |           +--rw sid-hop
>              |     |  |              +--rw sid?   rt-types:generalized-
>     label
>              |     |  +--rw protection-type?             identityref
>              |     |  +--rw tunnel-termination-points
>              |     |  |  +--rw source?        binary
>              |     |  |  +--rw destination?   binary
>              |     |  +--rw tunnels
>              |     |     +--rw sharing?   boolean
>
>
>
>              |     |     +--rw tunnel* [tunnel-name]
>              |     |        +--rw tunnel-name    string
>              |     |        +--rw sharing?       boolean
>              |     +--rw path-constraints
>              |     |  +--rw path-metric-bound* [metric-type]
>              |     |  |  +--rw metric-type    identityref
>              |     |  |  +--rw upper-bound?   uint64
>              |     |  +--rw topology-id?         te-types:te-topology-id
>              |     |  +--rw ignore-overload?     boolean
>              |     |  +--rw bandwidth-generic
>              |     |  |  +--rw te-bandwidth
>              |     |  |     +--rw (technology)?
>              |     |  |        +--:(psc)
>              |     |  |        |  +--rw psc?       rt-types:bandwidth-
>     ieee-float32
>              |     |  |        +--:(otn)
>              |     |  |        |  +--rw otn* [rate-type]
>              |     |  |        |     +--rw rate-type    identityref
>              |     |  |        |     +--rw counter?     uint16
>              |     |  |        +--:(lsc)
>              |     |  |        |  +--rw wdm* [spectrum slot]
>              |     |  |        |     +--rw spectrum    identityref
>              |     |  |        |     +--rw slot        int16
>              |     |  |        |     +--rw width?      uint16
>              |     |  |        +--:(generic)
>              |     |  |           +--rw generic?   te-bandwidth
>              |     |  +--rw disjointness?        te-types:te-path-
>     disjointness
>              |     |  +--rw setup-priority?      uint8
>              |     |  +--rw hold-priority?       uint8
>              |     |  +--rw signaling-type?      identityref
>              |     |  +--rw path-affinities
>              |     |  |  +--rw constraint* [usage]
>              |     |  |     +--rw usage    identityref
>              |     |  |     +--rw value?   admin-groups
>              |     |  +--rw path-srlgs
>              |     |     +--rw usage?    identityref
>              |     |     +--rw values*   srlg
>              |     +--rw optimizations
>              |     |  +--rw (algorithm)?
>              |     |     +--:(metric) {path-optimization-metric}?
>              |     |     |  +--rw optimization-metric* [metric-type]
>              |     |     |  |  +--rw metric-type    identityref
>              |     |     |  |  +--rw weight?        uint8
>              |     |     |  +--rw tiebreakers
>              |     |     |     +--rw tiebreaker* [tiebreaker-type]
>              |     |     |        +--rw tiebreaker-type    identityref
>
>
>
>
>              |     |     +--:(objective-function) {path-optimization-
>     objective-function}?
>              |     |        +--rw objective-function
>              |     |           +--rw objective-function-type?
>     identityref
>              |     +--ro computed-path-properties
>              |        +--ro path-metric* [metric-type]
>              |        |  +--ro metric-type           identityref
>              |        |  +--ro accumulative-value?   uint64
>              |        +--ro path-affinities
>              |        |  +--ro constraint* [usage]
>              |        |     +--ro usage    identityref
>              |        |     +--ro value?   admin-groups
>              |        +--ro path-srlgs
>              |        |  +--ro usage?    identityref
>              |        |  +--ro values*   srlg
>              |        +--ro path-computed-route-objects
>              |           +--ro path-computed-route-object* [index]
>              |              +--ro index             uint32
>              |              +--ro (type)?
>              |                 +--:(numbered)
>              |                 |  +--ro numbered-hop
>              |                 |     +--ro address?    te-types:te-tp-id
>              |                 |     +--ro hop-type?   te-hop-type
>              |                 +--:(as-number)
>              |                 |  +--ro as-number-hop
>              |                 |     +--ro as-number?   binary
>              |                 |     +--ro hop-type?    te-hop-type
>              |                 +--:(unnumbered)
>              |                 |  +--ro unnumbered-hop
>              |                 |     +--ro node-id?      te-types:te-
>     node-id
>              |                 |     +--ro link-tp-id?   te-types:te-tp-
>     id
>              |                 |     +--ro hop-type?     te-hop-type
>              |                 +--:(label)
>              |                 |  +--ro label-hop
>              |                 |     +--ro value?   rt-types:generalized-
>     label
>              |                 +--:(sid)
>              |                    +--ro sid-hop
>              |                       +--ro sid?   rt-types:generalized-
>     label
>              +--ro oper-status?                           te-types:te-
>     oper-status
>              +--ro geolocation
>              |  +--ro altitude?    int64
>
>
>              |  +--ro latitude?    geographic-coordinate-degree
>              |  +--ro longitude?   geographic-coordinate-degree
>              +--ro statistics
>              |  +--ro discontinuity-time          yang:date-and-time
>              |  +--ro tunnel-termination-point
>              |  |  +--ro disables?             yang:counter32
>              |  |  +--ro enables?              yang:counter32
>              |  |  +--ro maintenance-clears?   yang:counter32
>              |  |  +--ro maintenance-sets?     yang:counter32
>              |  |  +--ro modifies?             yang:counter32
>              |  |  +--ro downs?                yang:counter32
>              |  |  +--ro ups?                  yang:counter32
>              |  |  +--ro in-service-clears?    yang:counter32
>              |  |  +--ro in-service-sets?      yang:counter32
>              |  +--ro local-link-connectivity
>              |     +--ro creates?    yang:counter32
>              |     +--ro deletes?    yang:counter32
>              |     +--ro disables?   yang:counter32
>              |     +--ro enables?    yang:counter32
>              |     +--ro modifies?   yang:counter32
>              +--rw supporting-tunnel-termination-point* [node-ref tunnel-
>     tp-ref]
>                 +--rw node-ref         inet:uri
>                 +--rw tunnel-tp-ref    binary
>     augment /nw:networks/nw:network/nt:link:
>        +--rw te!
>           +--rw (bundle-stack-level)?
>           |  +--:(bundle)
>           |  |  +--rw bundled-links
>           |  |     +--rw bundled-link* [sequence]
>           |  |        +--rw sequence      uint32
>           |  |        +--rw src-tp-ref?   leafref
>           |  |        +--rw des-tp-ref?   leafref
>           |  +--:(component)
>           |     +--rw component-links
>           |        +--rw component-link* [sequence]
>           |           +--rw sequence             uint32
>           |           +--rw src-interface-ref?   string
>           |           +--rw des-interface-ref?   string
>           +--rw te-link-template*           leafref {template}?
>           +--rw te-link-attributes
>           |  +--rw access-type?                      te-types:te-link-
>     access-type
>           |  +--rw external-domain
>           |  |  +--rw network-ref?            leafref
>           |  |  +--rw remote-te-node-id?      te-types:te-node-id
>           |  |  +--rw remote-te-link-tp-id?   te-types:te-tp-id
>
>
>
>
>           |  |  +--rw plug-id?                uint32
>           |  +--rw is-abstract?                      empty
>           |  +--rw name?                             string
>           |  +--rw underlay {te-topology-hierarchy}?
>           |  |  +--rw enabled?                     boolean
>           |  |  +--rw primary-path
>           |  |  |  +--rw network-ref?    leafref
>           |  |  |  +--rw path-element* [path-element-id]
>           |  |  |     +--rw path-element-id    uint32
>           |  |  |     +--rw index?             uint32
>           |  |  |     +--rw (type)?
>           |  |  |        +--:(numbered)
>           |  |  |        |  +--rw numbered-hop
>           |  |  |        |     +--rw address?    te-types:te-tp-id
>           |  |  |        |     +--rw hop-type?   te-hop-type
>           |  |  |        +--:(as-number)
>           |  |  |        |  +--rw as-number-hop
>           |  |  |        |     +--rw as-number?   binary
>           |  |  |        |     +--rw hop-type?    te-hop-type
>           |  |  |        +--:(unnumbered)
>           |  |  |        |  +--rw unnumbered-hop
>           |  |  |        |     +--rw node-id?      te-types:te-node-id
>           |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>           |  |  |        |     +--rw hop-type?     te-hop-type
>           |  |  |        +--:(label)
>           |  |  |        |  +--rw label-hop
>           |  |  |        |     +--rw value?   rt-types:generalized-label
>           |  |  |        +--:(sid)
>           |  |  |           +--rw sid-hop
>           |  |  |              +--rw sid?   rt-types:generalized-label
>           |  |  +--rw backup-path* [index]
>           |  |  |  +--rw index           uint32
>           |  |  |  +--rw network-ref?    leafref
>           |  |  |  +--rw path-element* [path-element-id]
>           |  |  |     +--rw path-element-id    uint32
>           |  |  |     +--rw index?             uint32
>           |  |  |     +--rw (type)?
>           |  |  |        +--:(numbered)
>           |  |  |        |  +--rw numbered-hop
>           |  |  |        |     +--rw address?    te-types:te-tp-id
>           |  |  |        |     +--rw hop-type?   te-hop-type
>           |  |  |        +--:(as-number)
>           |  |  |        |  +--rw as-number-hop
>           |  |  |        |     +--rw as-number?   binary
>           |  |  |        |     +--rw hop-type?    te-hop-type
>           |  |  |        +--:(unnumbered)
>           |  |  |        |  +--rw unnumbered-hop
>
>
>           |  |  |        |     +--rw node-id?      te-types:te-node-id
>           |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>           |  |  |        |     +--rw hop-type?     te-hop-type
>           |  |  |        +--:(label)
>           |  |  |        |  +--rw label-hop
>           |  |  |        |     +--rw value?   rt-types:generalized-label
>           |  |  |        +--:(sid)
>           |  |  |           +--rw sid-hop
>           |  |  |              +--rw sid?   rt-types:generalized-label
>           |  |  +--rw protection-type?             identityref
>           |  |  +--rw tunnel-termination-points
>           |  |  |  +--rw source?        binary
>           |  |  |  +--rw destination?   binary
>           |  |  +--rw tunnels
>           |  |     +--rw sharing?   boolean
>           |  |     +--rw tunnel* [tunnel-name]
>           |  |        +--rw tunnel-name    string
>           |  |        +--rw sharing?       boolean
>           |  +--rw admin-status?                     te-types:te-admin-
>     status
>           |  +--rw link-index?                       uint64
>           |  +--rw administrative-group?             te-types:admin-
>     groups
>           |  +--rw interface-switching-capability* [switching-capability
>     encoding]
>           |  |  +--rw switching-capability    identityref
>           |  |  +--rw encoding                identityref
>           |  |  +--rw max-lsp-bandwidth* [priority]
>           |  |     +--rw priority     uint8
>           |  |     +--rw bandwidth
>           |  |        +--rw te-bandwidth
>           |  |           +--rw (technology)?
>           |  |              +--:(psc)
>           |  |              |  +--rw psc?       rt-types:bandwidth-ieee-
>     float32
>           |  |              +--:(otn)
>           |  |              |  +--rw otn* [rate-type]
>           |  |              |     +--rw rate-type    identityref
>           |  |              |     +--rw counter?     uint16
>           |  |              +--:(lsc)
>           |  |              |  +--rw wdm* [spectrum slot]
>           |  |              |     +--rw spectrum    identityref
>           |  |              |     +--rw slot        int16
>           |  |              |     +--rw width?      uint16
>           |  |              +--:(generic)
>           |  |                 +--rw generic?   te-bandwidth
>           |  +--rw label-restriction* [inclusive-exclusive label-start]
>
>
>
>           |  |  +--rw inclusive-exclusive    enumeration
>           |  |  +--rw label-start            rt-types:generalized-label
>           |  |  +--rw label-end?             rt-types:generalized-label
>           |  |  +--rw range-bitmap?          binary
>           |  +--rw link-protection-type?             enumeration
>           |  +--rw max-link-bandwidth
>           |  |  +--rw te-bandwidth
>           |  |     +--rw (technology)?
>           |  |        +--:(psc)
>           |  |        |  +--rw psc?       rt-types:bandwidth-ieee-float32
>           |  |        +--:(otn)
>           |  |        |  +--rw otn* [rate-type]
>           |  |        |     +--rw rate-type    identityref
>           |  |        |     +--rw counter?     uint16
>           |  |        +--:(lsc)
>           |  |        |  +--rw wdm* [spectrum slot]
>           |  |        |     +--rw spectrum    identityref
>           |  |        |     +--rw slot        int16
>           |  |        |     +--rw width?      uint16
>           |  |        +--:(generic)
>           |  |           +--rw generic?   te-bandwidth
>           |  +--rw max-resv-link-bandwidth
>           |  |  +--rw te-bandwidth
>           |  |     +--rw (technology)?
>           |  |        +--:(psc)
>           |  |        |  +--rw psc?       rt-types:bandwidth-ieee-float32
>           |  |        +--:(otn)
>           |  |        |  +--rw otn* [rate-type]
>           |  |        |     +--rw rate-type    identityref
>           |  |        |     +--rw counter?     uint16
>           |  |        +--:(lsc)
>           |  |        |  +--rw wdm* [spectrum slot]
>           |  |        |     +--rw spectrum    identityref
>           |  |        |     +--rw slot        int16
>           |  |        |     +--rw width?      uint16
>           |  |        +--:(generic)
>           |  |           +--rw generic?   te-bandwidth
>           |  +--rw unreserved-bandwidth* [priority]
>           |  |  +--rw priority     uint8
>           |  |  +--rw bandwidth
>           |  |     +--rw te-bandwidth
>           |  |        +--rw (technology)?
>           |  |           +--:(psc)
>           |  |           |  +--rw psc?       rt-types:bandwidth-ieee-
>     float32
>           |  |           +--:(otn)
>           |  |           |  +--rw otn* [rate-type]
>
>
>           |  |           |     +--rw rate-type    identityref
>           |  |           |     +--rw counter?     uint16
>           |  |           +--:(lsc)
>           |  |           |  +--rw wdm* [spectrum slot]
>           |  |           |     +--rw spectrum    identityref
>           |  |           |     +--rw slot        int16
>           |  |           |     +--rw width?      uint16
>           |  |           +--:(generic)
>           |  |              +--rw generic?   te-bandwidth
>           |  +--rw te-default-metric?                uint32
>           |  +--rw te-delay-metric?                  uint32
>           |  +--rw te-igp-metric?                    uint32
>           |  +--rw te-srlgs
>           |  |  +--rw value*   te-types:srlg
>           |  +--rw te-nsrlgs {nsrlg}?
>           |     +--rw id*   uint32
>           +--ro oper-status?                te-types:te-oper-status
>           +--ro is-transitional?            empty
>           +--ro information-source?         te-info-source
>           +--ro information-source-state
>           |  +--ro credibility-preference?    uint16
>           |  +--ro logical-network-element?   string
>           |  +--ro network-instance?          string
>           |  +--ro topology
>           |     +--ro link-ref?      leafref
>           |     +--ro network-ref?   leafref
>           +--ro information-source-entry* [information-source]
>           |  +--ro information-source                te-info-source
>           |  +--ro information-source-state
>           |  |  +--ro credibility-preference?    uint16
>           |  |  +--ro logical-network-element?   string
>           |  |  +--ro network-instance?          string
>           |  |  +--ro topology
>           |  |     +--ro link-ref?      leafref
>           |  |     +--ro network-ref?   leafref
>           |  +--ro link-index?                       uint64
>           |  +--ro administrative-group?             te-types:admin-
>     groups
>           |  +--ro interface-switching-capability* [switching-capability
>     encoding]
>           |  |  +--ro switching-capability    identityref
>           |  |  +--ro encoding                identityref
>           |  |  +--ro max-lsp-bandwidth* [priority]
>           |  |     +--ro priority     uint8
>           |  |     +--ro bandwidth
>           |  |        +--ro te-bandwidth
>           |  |           +--ro (technology)?
>
>
>           |  |              +--:(psc)
>           |  |              |  +--ro psc?       rt-types:bandwidth-ieee-
>     float32
>           |  |              +--:(otn)
>           |  |              |  +--ro otn* [rate-type]
>           |  |              |     +--ro rate-type    identityref
>           |  |              |     +--ro counter?     uint16
>           |  |              +--:(lsc)
>           |  |              |  +--ro wdm* [spectrum slot]
>           |  |              |     +--ro spectrum    identityref
>           |  |              |     +--ro slot        int16
>           |  |              |     +--ro width?      uint16
>           |  |              +--:(generic)
>           |  |                 +--ro generic?   te-bandwidth
>           |  +--ro label-restriction* [inclusive-exclusive label-start]
>           |  |  +--ro inclusive-exclusive    enumeration
>           |  |  +--ro label-start            rt-types:generalized-label
>           |  |  +--ro label-end?             rt-types:generalized-label
>           |  |  +--ro range-bitmap?          binary
>           |  +--ro link-protection-type?             enumeration
>           |  +--ro max-link-bandwidth
>           |  |  +--ro te-bandwidth
>           |  |     +--ro (technology)?
>           |  |        +--:(psc)
>           |  |        |  +--ro psc?       rt-types:bandwidth-ieee-float32
>           |  |        +--:(otn)
>           |  |        |  +--ro otn* [rate-type]
>           |  |        |     +--ro rate-type    identityref
>           |  |        |     +--ro counter?     uint16
>           |  |        +--:(lsc)
>           |  |        |  +--ro wdm* [spectrum slot]
>           |  |        |     +--ro spectrum    identityref
>           |  |        |     +--ro slot        int16
>           |  |        |     +--ro width?      uint16
>           |  |        +--:(generic)
>           |  |           +--ro generic?   te-bandwidth
>           |  +--ro max-resv-link-bandwidth
>           |  |  +--ro te-bandwidth
>           |  |     +--ro (technology)?
>           |  |        +--:(psc)
>           |  |        |  +--ro psc?       rt-types:bandwidth-ieee-float32
>           |  |        +--:(otn)
>           |  |        |  +--ro otn* [rate-type]
>           |  |        |     +--ro rate-type    identityref
>           |  |        |     +--ro counter?     uint16
>           |  |        +--:(lsc)
>           |  |        |  +--ro wdm* [spectrum slot]
>
>
>
>           |  |        |     +--ro spectrum    identityref
>           |  |        |     +--ro slot        int16
>           |  |        |     +--ro width?      uint16
>           |  |        +--:(generic)
>           |  |           +--ro generic?   te-bandwidth
>           |  +--ro unreserved-bandwidth* [priority]
>           |  |  +--ro priority     uint8
>           |  |  +--ro bandwidth
>           |  |     +--ro te-bandwidth
>           |  |        +--ro (technology)?
>           |  |           +--:(psc)
>           |  |           |  +--ro psc?       rt-types:bandwidth-ieee-
>     float32
>           |  |           +--:(otn)
>           |  |           |  +--ro otn* [rate-type]
>           |  |           |     +--ro rate-type    identityref
>           |  |           |     +--ro counter?     uint16
>           |  |           +--:(lsc)
>           |  |           |  +--ro wdm* [spectrum slot]
>           |  |           |     +--ro spectrum    identityref
>           |  |           |     +--ro slot        int16
>           |  |           |     +--ro width?      uint16
>           |  |           +--:(generic)
>           |  |              +--ro generic?   te-bandwidth
>           |  +--ro te-default-metric?                uint32
>           |  +--ro te-delay-metric?                  uint32
>           |  +--ro te-igp-metric?                    uint32
>           |  +--ro te-srlgs
>           |  |  +--ro value*   te-types:srlg
>           |  +--ro te-nsrlgs {nsrlg}?
>           |     +--ro id*   uint32
>           +--ro recovery
>           |  +--ro restoration-status?   te-types:te-recovery-status
>           |  +--ro protection-status?    te-types:te-recovery-status
>           +--ro underlay {te-topology-hierarchy}?
>           |  +--ro dynamic?     boolean
>           |  +--ro committed?   boolean
>           +--ro statistics
>              +--ro discontinuity-time                 yang:date-and-time
>              +--ro disables?                          yang:counter32
>              +--ro enables?                           yang:counter32
>              +--ro maintenance-clears?                yang:counter32
>              +--ro maintenance-sets?                  yang:counter32
>              +--ro modifies?                          yang:counter32
>              +--ro downs?                             yang:counter32
>              +--ro ups?                               yang:counter32
>              +--ro fault-clears?                      yang:counter32
>
>
>
>              +--ro fault-detects?                     yang:counter32
>              +--ro protection-switches?               yang:counter32
>              +--ro protection-reverts?                yang:counter32
>              +--ro restoration-failures?              yang:counter32
>              +--ro restoration-starts?                yang:counter32
>              +--ro restoration-successes?             yang:counter32
>              +--ro restoration-reversion-failures?    yang:counter32
>              +--ro restoration-reversion-starts?      yang:counter32
>              +--ro restoration-reversion-successes?   yang:counter32
>     augment /nw:networks/nw:network/nw:node/nt:termination-point:
>        +--rw te-tp-id?   te-types:te-tp-id
>        +--rw te!
>           +--rw admin-status?                     te-types:te-admin-
>     status
>           +--rw name?                             string
>           +--rw interface-switching-capability* [switching-capability
>     encoding]
>           |  +--rw switching-capability    identityref
>           |  +--rw encoding                identityref
>           |  +--rw max-lsp-bandwidth* [priority]
>           |     +--rw priority     uint8
>           |     +--rw bandwidth
>           |        +--rw te-bandwidth
>           |           +--rw (technology)?
>           |              +--:(psc)
>           |              |  +--rw psc?       rt-types:bandwidth-ieee-
>     float32
>           |              +--:(otn)
>           |              |  +--rw otn* [rate-type]
>           |              |     +--rw rate-type    identityref
>           |              |     +--rw counter?     uint16
>           |              +--:(lsc)
>           |              |  +--rw wdm* [spectrum slot]
>           |              |     +--rw spectrum    identityref
>           |              |     +--rw slot        int16
>           |              |     +--rw width?      uint16
>           |              +--:(generic)
>           |                 +--rw generic?   te-bandwidth
>           +--rw inter-layer-lock-id*              uint32
>           +--ro oper-status?                      te-types:te-oper-status
>           +--ro geolocation
>              +--ro altitude?    int64
>              +--ro latitude?    geographic-coordinate-degree
>              +--ro longitude?   geographic-coordinate-degree
>
>
>
> =====================================
> end of diagram
>
> ----- Original Message -----
> From: "Lou Berger" 
> To: 
> Sent: Wednesday, October 25, 2017 2:13 PM
> Subject: Re: [netmod] I-D Action:
> draft-ietf-netmod-yang-tree-diagrams-02.txt
>
>
>> Hi,
>>
>> This version addresses all known / open issues in the draft known to
>> the authors.
>>
>> The changes are as follows:
>> - Added groupings and yang-data descriptions
>> - Added Comments, Long Diagrams and Security Considerations sections
>> - Clarified representation of schema mount points and representation
> of
>> modules exposed using schema mount.
>> - Miscellaneous editorial changes
>>
>> Lou (for draft authors)
>>
>> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
>>>          Authors         : Martin Bjorklund
>>>                            Lou Berger
>>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
>>> Pages           : 11
>>> Date            : 2017-10-25
>>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>



From nobody Thu Oct 26 10:35:16 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE33D13F421 for ; Thu, 26 Oct 2017 10:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFuCLhv97W1F for ; Thu, 26 Oct 2017 10:35:09 -0700 (PDT)
Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::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 6040813F3C7 for ; Thu, 26 Oct 2017 10:35:09 -0700 (PDT)
Received: by mail-pg0-x241.google.com with SMTP id j3so3255588pga.1 for ; Thu, 26 Oct 2017 10:35:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c5D7Z7pLV/T67JPb3Ffmu1e7eRt2HHVjo7ORZjiXbvc=; b=Dtf0cmOyw5dkuIKoYQdTPRpVRxLlQMhntEA8pWaB9cBpJzBaQNDsMHGg760GrwnfRZ SfKewnUkpLG7WeFLF7hajuWZU9aTTX3+bOltYkdKWzC3PQXE96VrjlilV9LDr9lXH1Ul n2wV/S0oaBd31oSyD2JZK+gOTx1BC+XibKF1CYYvVhdve2pAk+2tXcSZLqJR0f3m0/s2 UqTTAweaYRB9lzxXGgJi/2gQlPY1Ch9cquFc4eMvPoorC/KB+wn4klvH9d2ZhETPz4Nh sV/wobvO5VmubFAzQTYTSD8MbBCOA+izvJG93YacFzAQ8ZKd+FPIaVgsGUN0I1s92Nly lYiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c5D7Z7pLV/T67JPb3Ffmu1e7eRt2HHVjo7ORZjiXbvc=; b=ZyuEG0Pb2XyCfoU2i7TIL1dzAYkiCtAzW/nbdmuEogz7xKxMl3xT3PHgj3LdrCktMU wwZtJaVYFOuLhuelCnL2+uc1vyDEdoS5lS5udou0FHeL7n/glCJw153ol59sOK1gn6m/ Qs4NgCErF6hMXBT7wJuZVh5tNnlmxurSdIZZNWjTFZjchYP59evky+steB9xOVpz9uK3 papLoJZC6TObGF5cVAO+3q4qnnVXQrviTpAjcMyQz8jFau7TEgF7x9MaDGyfIHZRJXix 9/pIE2HBuhGaQYRV75K7XmTJ2tu9pehXSjomQ/3kQ4NgbeEzwFvHq85vvOzgEPSzDEkn 5Lvg==
X-Gm-Message-State: AMCzsaWGIq7MfWvP+Q2qBGSDkYNWG5VkcwtLiDjPqHkRu4UIZxODuLjA yJvjDtG2DvGplRSLLt2GT5s=
X-Google-Smtp-Source: ABhQp+QS9jHQVGgcUemsVrwfv2QC0g/DoVf6YfhVfr2L9SMOeSwPDi2I5DOeiFR3OCPSKG/40IrltQ==
X-Received: by 10.99.111.65 with SMTP id k62mr5491092pgc.56.1509039306149; Thu, 26 Oct 2017 10:35:06 -0700 (PDT)
Received: from sjc-mahesh-nitro4.cisco.com ([128.107.241.177]) by smtp.gmail.com with ESMTPSA id g7sm10918268pfj.13.2017.10.26.10.35.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Oct 2017 10:35:05 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Mahesh Jethanandani 
X-Priority: 3
In-Reply-To: <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>
Date: Thu, 26 Oct 2017 10:35:27 -0700
Cc: netmod@ietf.org, Lou Berger 
Content-Transfer-Encoding: quoted-printable
Message-Id: <122E6B31-38CA-47DD-8891-A79D3BC8BCC7@gmail.com>
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>
To: "t.petch" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 17:35:15 -0000

> On Oct 26, 2017, at 9:50 AM, t.petch  wrote:
>=20
> Lou
>=20
> I like the advice that diagrams should be one page long but wonder how
> to apply that to those I see in routing WGs.  I have just been looking
> at
>=20
> draft-ietf-teas-yang-te-topo-12
>=20
> where the diagram is 36 pages long - which may be one of the larger =
ones
> but by no means exceptional - and I think the diagram is  more or less
> useless as a result.  But what practical advice can we give them?

How about using the depth of the =E2=80=94tree-depth option to generate =
smaller trees that may not give the whole tree, but at least give you a =
nice overview? Follow that with smaller chunks using the =E2=80=94tree-pat=
h for each section of the tree.

>=20
> I append the diagram below
>=20
> Tom Petch
>=20
>=20
> start of diagram
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
>=20
>=20
> Liu, et al             Expires January 17, 2018               [Page =
31]
>=20
>=20
> 6. Tree Structure
>=20
>   module: ietf-te-topology
>   augment /nw:networks/nw:network/nw:network-types:
>      +--rw te-topology!
>   augment /nw:networks:
>      +--rw te!
>         +--rw templates
>            +--rw node-template* [name] {template}?
>            |  +--rw name                       te-types:te-template-
>   name
>            |  +--rw priority?                  uint16
>            |  +--rw reference-change-policy?   enumeration
>            |  +--rw te-node-attributes
>            |     +--rw admin-status?        te-types:te-admin-status
>            |     +--rw domain-id?           uint32
>            |     +--rw is-abstract?         empty
>            |     +--rw name?                inet:domain-name
>            |     +--rw signaling-address*   inet:ip-address
>            |     +--rw underlay-topology {te-topology-hierarchy}?
>            |        +--rw network-ref?   leafref
>            +--rw link-template* [name] {template}?
>               +--rw name                       te-types:te-template-
>   name
>               +--rw priority?                  uint16
>               +--rw reference-change-policy?   enumeration
>               +--rw te-link-attributes
>                  +--rw access-type?                      te-types:te-
>   link-access-type
>                  +--rw external-domain
>                  |  +--rw network-ref?            leafref
>                  |  +--rw remote-te-node-id?      te-types:te-node-id
>                  |  +--rw remote-te-link-tp-id?   te-types:te-tp-id
>                  |  +--rw plug-id?                uint32
>                  +--rw is-abstract?                      empty
>                  +--rw name?                             string
>                  +--rw underlay {te-topology-hierarchy}?
>                  |  +--rw enabled?                     boolean
>                  |  +--rw primary-path
>                  |  |  +--rw network-ref?    leafref
>                  |  |  +--rw path-element* [path-element-id]
>                  |  |     +--rw path-element-id    uint32
>                  |  |     +--rw index?             uint32
>=20
>=20
>=20
>                  |  |     +--rw (type)?
>                  |  |        +--:(numbered)
>                  |  |        |  +--rw numbered-hop
>                  |  |        |     +--rw address?    te-types:te-tp-id
>                  |  |        |     +--rw hop-type?   te-hop-type
>                  |  |        +--:(as-number)
>                  |  |        |  +--rw as-number-hop
>                  |  |        |     +--rw as-number?   binary
>                  |  |        |     +--rw hop-type?    te-hop-type
>                  |  |        +--:(unnumbered)
>                  |  |        |  +--rw unnumbered-hop
>                  |  |        |     +--rw node-id?      te-types:te-
>   node-id
>                  |  |        |     +--rw link-tp-id?   te-types:te-tp-
>   id
>                  |  |        |     +--rw hop-type?     te-hop-type
>                  |  |        +--:(label)
>                  |  |        |  +--rw label-hop
>                  |  |        |     +--rw value?   =
rt-types:generalized-
>   label
>                  |  |        +--:(sid)
>                  |  |           +--rw sid-hop
>                  |  |              +--rw sid?   rt-types:generalized-
>   label
>                  |  +--rw backup-path* [index]
>                  |  |  +--rw index           uint32
>                  |  |  +--rw network-ref?    leafref
>                  |  |  +--rw path-element* [path-element-id]
>                  |  |     +--rw path-element-id    uint32
>                  |  |     +--rw index?             uint32
>                  |  |     +--rw (type)?
>                  |  |        +--:(numbered)
>                  |  |        |  +--rw numbered-hop
>                  |  |        |     +--rw address?    te-types:te-tp-id
>                  |  |        |     +--rw hop-type?   te-hop-type
>                  |  |        +--:(as-number)
>                  |  |        |  +--rw as-number-hop
>                  |  |        |     +--rw as-number?   binary
>                  |  |        |     +--rw hop-type?    te-hop-type
>                  |  |        +--:(unnumbered)
>                  |  |        |  +--rw unnumbered-hop
>                  |  |        |     +--rw node-id?      te-types:te-
>   node-id
>                  |  |        |     +--rw link-tp-id?   te-types:te-tp-
>   id
>                  |  |        |     +--rw hop-type?     te-hop-type
>                  |  |        +--:(label)
>=20
>=20
>                  |  |        |  +--rw label-hop
>                  |  |        |     +--rw value?   =
rt-types:generalized-
>   label
>                  |  |        +--:(sid)
>                  |  |           +--rw sid-hop
>                  |  |              +--rw sid?   rt-types:generalized-
>   label
>                  |  +--rw protection-type?             identityref
>                  |  +--rw tunnel-termination-points
>                  |  |  +--rw source?        binary
>                  |  |  +--rw destination?   binary
>                  |  +--rw tunnels
>                  |     +--rw sharing?   boolean
>                  |     +--rw tunnel* [tunnel-name]
>                  |        +--rw tunnel-name    string
>                  |        +--rw sharing?       boolean
>                  +--rw admin-status?                     te-types:te-
>   admin-status
>                  +--rw link-index?                       uint64
>                  +--rw administrative-group?             te-
>   types:admin-groups
>                  +--rw interface-switching-capability* [switching-
>   capability encoding]
>                  |  +--rw switching-capability    identityref
>                  |  +--rw encoding                identityref
>                  |  +--rw max-lsp-bandwidth* [priority]
>                  |     +--rw priority     uint8
>                  |     +--rw bandwidth
>                  |        +--rw te-bandwidth
>                  |           +--rw (technology)?
>                  |              +--:(psc)
>                  |              |  +--rw psc?       =
rt-types:bandwidth-
>   ieee-float32
>                  |              +--:(otn)
>                  |              |  +--rw otn* [rate-type]
>                  |              |     +--rw rate-type    identityref
>                  |              |     +--rw counter?     uint16
>                  |              +--:(lsc)
>                  |              |  +--rw wdm* [spectrum slot]
>                  |              |     +--rw spectrum    identityref
>                  |              |     +--rw slot        int16
>                  |              |     +--rw width?      uint16
>                  |              +--:(generic)
>                  |                 +--rw generic?   te-bandwidth
>                  +--rw label-restriction* [inclusive-exclusive label-
>   start]
>                  |  +--rw inclusive-exclusive    enumeration
>=20
>=20
>=20
>                  |  +--rw label-start            rt-types:generalized-
>   label
>                  |  +--rw label-end?             rt-types:generalized-
>   label
>                  |  +--rw range-bitmap?          binary
>                  +--rw link-protection-type?             enumeration
>                  +--rw max-link-bandwidth
>                  |  +--rw te-bandwidth
>                  |     +--rw (technology)?
>                  |        +--:(psc)
>                  |        |  +--rw psc?       rt-types:bandwidth-ieee-
>   float32
>                  |        +--:(otn)
>                  |        |  +--rw otn* [rate-type]
>                  |        |     +--rw rate-type    identityref
>                  |        |     +--rw counter?     uint16
>                  |        +--:(lsc)
>                  |        |  +--rw wdm* [spectrum slot]
>                  |        |     +--rw spectrum    identityref
>                  |        |     +--rw slot        int16
>                  |        |     +--rw width?      uint16
>                  |        +--:(generic)
>                  |           +--rw generic?   te-bandwidth
>                  +--rw max-resv-link-bandwidth
>                  |  +--rw te-bandwidth
>                  |     +--rw (technology)?
>                  |        +--:(psc)
>                  |        |  +--rw psc?       rt-types:bandwidth-ieee-
>   float32
>                  |        +--:(otn)
>                  |        |  +--rw otn* [rate-type]
>                  |        |     +--rw rate-type    identityref
>                  |        |     +--rw counter?     uint16
>                  |        +--:(lsc)
>                  |        |  +--rw wdm* [spectrum slot]
>                  |        |     +--rw spectrum    identityref
>                  |        |     +--rw slot        int16
>                  |        |     +--rw width?      uint16
>                  |        +--:(generic)
>                  |           +--rw generic?   te-bandwidth
>                  +--rw unreserved-bandwidth* [priority]
>                  |  +--rw priority     uint8
>                  |  +--rw bandwidth
>                  |     +--rw te-bandwidth
>                  |        +--rw (technology)?
>                  |           +--:(psc)
>=20
>=20
>=20
>                  |           |  +--rw psc?       rt-types:bandwidth-
>   ieee-float32
>                  |           +--:(otn)
>                  |           |  +--rw otn* [rate-type]
>                  |           |     +--rw rate-type    identityref
>                  |           |     +--rw counter?     uint16
>                  |           +--:(lsc)
>                  |           |  +--rw wdm* [spectrum slot]
>                  |           |     +--rw spectrum    identityref
>                  |           |     +--rw slot        int16
>                  |           |     +--rw width?      uint16
>                  |           +--:(generic)
>                  |              +--rw generic?   te-bandwidth
>                  +--rw te-default-metric?                uint32
>                  +--rw te-delay-metric?                  uint32
>                  +--rw te-igp-metric?                    uint32
>                  +--rw te-srlgs
>                  |  +--rw value*   te-types:srlg
>                  +--rw te-nsrlgs {nsrlg}?
>                     +--rw id*   uint32
>   augment /nw:networks/nw:network:
>      +--rw provider-id?      te-types:te-global-id
>      +--rw client-id?        te-types:te-global-id
>      +--rw te-topology-id?   te-types:te-topology-id
>      +--rw te!
>         +--rw preference?               uint8
>         +--rw optimization-criterion?   identityref
>         +--rw nsrlg* [id] {nsrlg}?
>         |  +--rw id              uint32
>         |  +--rw disjointness?   te-types:te-path-disjointness
>         +--ro geolocation
>            +--ro altitude?    int64
>            +--ro latitude?    geographic-coordinate-degree
>            +--ro longitude?   geographic-coordinate-degree
>   augment /nw:networks/nw:network/nw:node:
>      +--rw te-node-id?   te-types:te-node-id
>      +--rw te!
>         +--rw te-node-template*           leafref {template}?
>         +--rw te-node-attributes
>         |  +--rw admin-status?            te-types:te-admin-status
>         |  +--rw connectivity-matrices
>         |  |  +--rw number-of-entries?          uint16
>         |  |  +--rw label-restriction* [inclusive-exclusive label-
>   start]
>         |  |  |  +--rw inclusive-exclusive    enumeration
>         |  |  |  +--rw label-start            rt-types:generalized-
>   label
>=20
>=20
>=20
>         |  |  |  +--rw label-end?             rt-types:generalized-
>   label
>         |  |  |  +--rw range-bitmap?          binary
>         |  |  +--rw is-allowed?                 boolean
>         |  |  +--rw underlay {te-topology-hierarchy}?
>         |  |  |  +--rw enabled?                     boolean
>         |  |  |  +--rw primary-path
>         |  |  |  |  +--rw network-ref?    leafref
>         |  |  |  |  +--rw path-element* [path-element-id]
>         |  |  |  |     +--rw path-element-id    uint32
>         |  |  |  |     +--rw index?             uint32
>         |  |  |  |     +--rw (type)?
>         |  |  |  |        +--:(numbered)
>         |  |  |  |        |  +--rw numbered-hop
>         |  |  |  |        |     +--rw address?    te-types:te-tp-id
>         |  |  |  |        |     +--rw hop-type?   te-hop-type
>         |  |  |  |        +--:(as-number)
>         |  |  |  |        |  +--rw as-number-hop
>         |  |  |  |        |     +--rw as-number?   binary
>         |  |  |  |        |     +--rw hop-type?    te-hop-type
>         |  |  |  |        +--:(unnumbered)
>         |  |  |  |        |  +--rw unnumbered-hop
>         |  |  |  |        |     +--rw node-id?      =
te-types:te-node-id
>         |  |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>         |  |  |  |        |     +--rw hop-type?     te-hop-type
>         |  |  |  |        +--:(label)
>         |  |  |  |        |  +--rw label-hop
>         |  |  |  |        |     +--rw value?   rt-types:generalized-
>   label
>         |  |  |  |        +--:(sid)
>         |  |  |  |           +--rw sid-hop
>         |  |  |  |              +--rw sid?   =
rt-types:generalized-label
>         |  |  |  +--rw backup-path* [index]
>         |  |  |  |  +--rw index           uint32
>         |  |  |  |  +--rw network-ref?    leafref
>         |  |  |  |  +--rw path-element* [path-element-id]
>         |  |  |  |     +--rw path-element-id    uint32
>         |  |  |  |     +--rw index?             uint32
>         |  |  |  |     +--rw (type)?
>         |  |  |  |        +--:(numbered)
>         |  |  |  |        |  +--rw numbered-hop
>         |  |  |  |        |     +--rw address?    te-types:te-tp-id
>         |  |  |  |        |     +--rw hop-type?   te-hop-type
>         |  |  |  |        +--:(as-number)
>         |  |  |  |        |  +--rw as-number-hop
>         |  |  |  |        |     +--rw as-number?   binary
>         |  |  |  |        |     +--rw hop-type?    te-hop-type
>=20
>=20
>         |  |  |  |        +--:(unnumbered)
>         |  |  |  |        |  +--rw unnumbered-hop
>         |  |  |  |        |     +--rw node-id?      =
te-types:te-node-id
>         |  |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>         |  |  |  |        |     +--rw hop-type?     te-hop-type
>         |  |  |  |        +--:(label)
>         |  |  |  |        |  +--rw label-hop
>         |  |  |  |        |     +--rw value?   rt-types:generalized-
>   label
>         |  |  |  |        +--:(sid)
>         |  |  |  |           +--rw sid-hop
>         |  |  |  |              +--rw sid?   =
rt-types:generalized-label
>         |  |  |  +--rw protection-type?             identityref
>         |  |  |  +--rw tunnel-termination-points
>         |  |  |  |  +--rw source?        binary
>         |  |  |  |  +--rw destination?   binary
>         |  |  |  +--rw tunnels
>         |  |  |     +--rw sharing?   boolean
>         |  |  |     +--rw tunnel* [tunnel-name]
>         |  |  |        +--rw tunnel-name    string
>         |  |  |        +--rw sharing?       boolean
>         |  |  +--rw path-constraints
>         |  |  |  +--rw path-metric-bound* [metric-type]
>         |  |  |  |  +--rw metric-type    identityref
>         |  |  |  |  +--rw upper-bound?   uint64
>         |  |  |  +--rw topology-id?         te-types:te-topology-id
>         |  |  |  +--rw ignore-overload?     boolean
>         |  |  |  +--rw bandwidth-generic
>         |  |  |  |  +--rw te-bandwidth
>         |  |  |  |     +--rw (technology)?
>         |  |  |  |        +--:(psc)
>         |  |  |  |        |  +--rw psc?       rt-types:bandwidth-ieee-
>   float32
>         |  |  |  |        +--:(otn)
>         |  |  |  |        |  +--rw otn* [rate-type]
>         |  |  |  |        |     +--rw rate-type    identityref
>         |  |  |  |        |     +--rw counter?     uint16
>         |  |  |  |        +--:(lsc)
>         |  |  |  |        |  +--rw wdm* [spectrum slot]
>         |  |  |  |        |     +--rw spectrum    identityref
>         |  |  |  |        |     +--rw slot        int16
>         |  |  |  |        |     +--rw width?      uint16
>         |  |  |  |        +--:(generic)
>         |  |  |  |           +--rw generic?   te-bandwidth
>         |  |  |  +--rw disjointness?        te-types:te-path-
>   disjointness
>         |  |  |  +--rw setup-priority?      uint8
>=20
>=20
>         |  |  |  +--rw hold-priority?       uint8
>         |  |  |  +--rw signaling-type?      identityref
>         |  |  |  +--rw path-affinities
>         |  |  |  |  +--rw constraint* [usage]
>         |  |  |  |     +--rw usage    identityref
>         |  |  |  |     +--rw value?   admin-groups
>         |  |  |  +--rw path-srlgs
>         |  |  |     +--rw usage?    identityref
>         |  |  |     +--rw values*   srlg
>         |  |  +--rw optimizations
>         |  |  |  +--rw (algorithm)?
>         |  |  |     +--:(metric) {path-optimization-metric}?
>         |  |  |     |  +--rw optimization-metric* [metric-type]
>         |  |  |     |  |  +--rw metric-type    identityref
>         |  |  |     |  |  +--rw weight?        uint8
>         |  |  |     |  +--rw tiebreakers
>         |  |  |     |     +--rw tiebreaker* [tiebreaker-type]
>         |  |  |     |        +--rw tiebreaker-type    identityref
>         |  |  |     +--:(objective-function) {path-optimization-
>   objective-function}?
>         |  |  |        +--rw objective-function
>         |  |  |           +--rw objective-function-type?   identityref
>         |  |  +--ro computed-path-properties
>         |  |  |  +--ro path-metric* [metric-type]
>         |  |  |  |  +--ro metric-type           identityref
>         |  |  |  |  +--ro accumulative-value?   uint64
>         |  |  |  +--ro path-affinities
>         |  |  |  |  +--ro constraint* [usage]
>         |  |  |  |     +--ro usage    identityref
>         |  |  |  |     +--ro value?   admin-groups
>         |  |  |  +--ro path-srlgs
>         |  |  |  |  +--ro usage?    identityref
>         |  |  |  |  +--ro values*   srlg
>         |  |  |  +--ro path-computed-route-objects
>         |  |  |     +--ro path-computed-route-object* [index]
>         |  |  |        +--ro index             uint32
>         |  |  |        +--ro (type)?
>         |  |  |           +--:(numbered)
>         |  |  |           |  +--ro numbered-hop
>         |  |  |           |     +--ro address?    te-types:te-tp-id
>         |  |  |           |     +--ro hop-type?   te-hop-type
>         |  |  |           +--:(as-number)
>         |  |  |           |  +--ro as-number-hop
>         |  |  |           |     +--ro as-number?   binary
>         |  |  |           |     +--ro hop-type?    te-hop-type
>         |  |  |           +--:(unnumbered)
>         |  |  |           |  +--ro unnumbered-hop
>=20
>=20
>=20
>=20
>         |  |  |           |     +--ro node-id?      =
te-types:te-node-id
>         |  |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>         |  |  |           |     +--ro hop-type?     te-hop-type
>         |  |  |           +--:(label)
>         |  |  |           |  +--ro label-hop
>         |  |  |           |     +--ro value?   rt-types:generalized-
>   label
>         |  |  |           +--:(sid)
>         |  |  |              +--ro sid-hop
>         |  |  |                 +--ro sid?   =
rt-types:generalized-label
>         |  |  +--rw connectivity-matrix* [id]
>         |  |     +--rw id                          uint32
>         |  |     +--rw from
>         |  |     |  +--rw tp-ref?              leafref
>         |  |     |  +--rw label-restriction* [inclusive-exclusive
>   label-start]
>         |  |     |     +--rw inclusive-exclusive    enumeration
>         |  |     |     +--rw label-start            rt-
>   types:generalized-label
>         |  |     |     +--rw label-end?             rt-
>   types:generalized-label
>         |  |     |     +--rw range-bitmap?          binary
>         |  |     +--rw to
>         |  |     |  +--rw tp-ref?              leafref
>         |  |     |  +--rw label-restriction* [inclusive-exclusive
>   label-start]
>         |  |     |     +--rw inclusive-exclusive    enumeration
>         |  |     |     +--rw label-start            rt-
>   types:generalized-label
>         |  |     |     +--rw label-end?             rt-
>   types:generalized-label
>         |  |     |     +--rw range-bitmap?          binary
>         |  |     +--rw is-allowed?                 boolean
>         |  |     +--rw underlay {te-topology-hierarchy}?
>         |  |     |  +--rw enabled?                     boolean
>         |  |     |  +--rw primary-path
>         |  |     |  |  +--rw network-ref?    leafref
>         |  |     |  |  +--rw path-element* [path-element-id]
>         |  |     |  |     +--rw path-element-id    uint32
>         |  |     |  |     +--rw index?             uint32
>         |  |     |  |     +--rw (type)?
>         |  |     |  |        +--:(numbered)
>         |  |     |  |        |  +--rw numbered-hop
>         |  |     |  |        |     +--rw address?    te-types:te-tp-id
>         |  |     |  |        |     +--rw hop-type?   te-hop-type
>         |  |     |  |        +--:(as-number)
>         |  |     |  |        |  +--rw as-number-hop
>=20
>=20
>=20
>=20
>         |  |     |  |        |     +--rw as-number?   binary
>         |  |     |  |        |     +--rw hop-type?    te-hop-type
>         |  |     |  |        +--:(unnumbered)
>         |  |     |  |        |  +--rw unnumbered-hop
>         |  |     |  |        |     +--rw node-id?      te-types:te-
>   node-id
>         |  |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>   id
>         |  |     |  |        |     +--rw hop-type?     te-hop-type
>         |  |     |  |        +--:(label)
>         |  |     |  |        |  +--rw label-hop
>         |  |     |  |        |     +--rw value?   =
rt-types:generalized-
>   label
>         |  |     |  |        +--:(sid)
>         |  |     |  |           +--rw sid-hop
>         |  |     |  |              +--rw sid?   rt-types:generalized-
>   label
>         |  |     |  +--rw backup-path* [index]
>         |  |     |  |  +--rw index           uint32
>         |  |     |  |  +--rw network-ref?    leafref
>         |  |     |  |  +--rw path-element* [path-element-id]
>         |  |     |  |     +--rw path-element-id    uint32
>         |  |     |  |     +--rw index?             uint32
>         |  |     |  |     +--rw (type)?
>         |  |     |  |        +--:(numbered)
>         |  |     |  |        |  +--rw numbered-hop
>         |  |     |  |        |     +--rw address?    te-types:te-tp-id
>         |  |     |  |        |     +--rw hop-type?   te-hop-type
>         |  |     |  |        +--:(as-number)
>         |  |     |  |        |  +--rw as-number-hop
>         |  |     |  |        |     +--rw as-number?   binary
>         |  |     |  |        |     +--rw hop-type?    te-hop-type
>         |  |     |  |        +--:(unnumbered)
>         |  |     |  |        |  +--rw unnumbered-hop
>         |  |     |  |        |     +--rw node-id?      te-types:te-
>   node-id
>         |  |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>   id
>         |  |     |  |        |     +--rw hop-type?     te-hop-type
>         |  |     |  |        +--:(label)
>         |  |     |  |        |  +--rw label-hop
>         |  |     |  |        |     +--rw value?   =
rt-types:generalized-
>   label
>         |  |     |  |        +--:(sid)
>         |  |     |  |           +--rw sid-hop
>         |  |     |  |              +--rw sid?   rt-types:generalized-
>   label
>=20
>=20
>         |  |     |  +--rw protection-type?             identityref
>         |  |     |  +--rw tunnel-termination-points
>         |  |     |  |  +--rw source?        binary
>         |  |     |  |  +--rw destination?   binary
>         |  |     |  +--rw tunnels
>         |  |     |     +--rw sharing?   boolean
>         |  |     |     +--rw tunnel* [tunnel-name]
>         |  |     |        +--rw tunnel-name    string
>         |  |     |        +--rw sharing?       boolean
>         |  |     +--rw path-constraints
>         |  |     |  +--rw path-metric-bound* [metric-type]
>         |  |     |  |  +--rw metric-type    identityref
>         |  |     |  |  +--rw upper-bound?   uint64
>         |  |     |  +--rw topology-id?         te-types:te-topology-id
>         |  |     |  +--rw ignore-overload?     boolean
>         |  |     |  +--rw bandwidth-generic
>         |  |     |  |  +--rw te-bandwidth
>         |  |     |  |     +--rw (technology)?
>         |  |     |  |        +--:(psc)
>         |  |     |  |        |  +--rw psc?       rt-types:bandwidth-
>   ieee-float32
>         |  |     |  |        +--:(otn)
>         |  |     |  |        |  +--rw otn* [rate-type]
>         |  |     |  |        |     +--rw rate-type    identityref
>         |  |     |  |        |     +--rw counter?     uint16
>         |  |     |  |        +--:(lsc)
>         |  |     |  |        |  +--rw wdm* [spectrum slot]
>         |  |     |  |        |     +--rw spectrum    identityref
>         |  |     |  |        |     +--rw slot        int16
>         |  |     |  |        |     +--rw width?      uint16
>         |  |     |  |        +--:(generic)
>         |  |     |  |           +--rw generic?   te-bandwidth
>         |  |     |  +--rw disjointness?        te-types:te-path-
>   disjointness
>         |  |     |  +--rw setup-priority?      uint8
>         |  |     |  +--rw hold-priority?       uint8
>         |  |     |  +--rw signaling-type?      identityref
>         |  |     |  +--rw path-affinities
>         |  |     |  |  +--rw constraint* [usage]
>         |  |     |  |     +--rw usage    identityref
>         |  |     |  |     +--rw value?   admin-groups
>         |  |     |  +--rw path-srlgs
>         |  |     |     +--rw usage?    identityref
>         |  |     |     +--rw values*   srlg
>         |  |     +--rw optimizations
>         |  |     |  +--rw (algorithm)?
>         |  |     |     +--:(metric) {path-optimization-metric}?
>=20
>=20
>         |  |     |     |  +--rw optimization-metric* [metric-type]
>         |  |     |     |  |  +--rw metric-type    identityref
>         |  |     |     |  |  +--rw weight?        uint8
>         |  |     |     |  +--rw tiebreakers
>         |  |     |     |     +--rw tiebreaker* [tiebreaker-type]
>         |  |     |     |        +--rw tiebreaker-type    identityref
>         |  |     |     +--:(objective-function) {path-optimization-
>   objective-function}?
>         |  |     |        +--rw objective-function
>         |  |     |           +--rw objective-function-type?
>   identityref
>         |  |     +--ro computed-path-properties
>         |  |        +--ro path-metric* [metric-type]
>         |  |        |  +--ro metric-type           identityref
>         |  |        |  +--ro accumulative-value?   uint64
>         |  |        +--ro path-affinities
>         |  |        |  +--ro constraint* [usage]
>         |  |        |     +--ro usage    identityref
>         |  |        |     +--ro value?   admin-groups
>         |  |        +--ro path-srlgs
>         |  |        |  +--ro usage?    identityref
>         |  |        |  +--ro values*   srlg
>         |  |        +--ro path-computed-route-objects
>         |  |           +--ro path-computed-route-object* [index]
>         |  |              +--ro index             uint32
>         |  |              +--ro (type)?
>         |  |                 +--:(numbered)
>         |  |                 |  +--ro numbered-hop
>         |  |                 |     +--ro address?    te-types:te-tp-id
>         |  |                 |     +--ro hop-type?   te-hop-type
>         |  |                 +--:(as-number)
>         |  |                 |  +--ro as-number-hop
>         |  |                 |     +--ro as-number?   binary
>         |  |                 |     +--ro hop-type?    te-hop-type
>         |  |                 +--:(unnumbered)
>         |  |                 |  +--ro unnumbered-hop
>         |  |                 |     +--ro node-id?      te-types:te-
>   node-id
>         |  |                 |     +--ro link-tp-id?   te-types:te-tp-
>   id
>         |  |                 |     +--ro hop-type?     te-hop-type
>         |  |                 +--:(label)
>         |  |                 |  +--ro label-hop
>         |  |                 |     +--ro value?   =
rt-types:generalized-
>   label
>         |  |                 +--:(sid)
>         |  |                    +--ro sid-hop
>=20
>         |  |                       +--ro sid?   rt-types:generalized-
>   label
>         |  +--rw domain-id?               uint32
>         |  +--rw is-abstract?             empty
>         |  +--rw name?                    inet:domain-name
>         |  +--rw signaling-address*       inet:ip-address
>         |  +--rw underlay-topology {te-topology-hierarchy}?
>         |     +--rw network-ref?   leafref
>         +--ro oper-status?                te-types:te-oper-status
>         +--ro geolocation
>         |  +--ro altitude?    int64
>         |  +--ro latitude?    geographic-coordinate-degree
>         |  +--ro longitude?   geographic-coordinate-degree
>         +--ro is-multi-access-dr?         empty
>         +--ro information-source?         te-info-source
>         +--ro information-source-state
>         |  +--ro credibility-preference?    uint16
>         |  +--ro logical-network-element?   string
>         |  +--ro network-instance?          string
>         |  +--ro topology
>         |     +--ro node-ref?      leafref
>         |     +--ro network-ref?   leafref
>         +--ro information-source-entry* [information-source]
>         |  +--ro information-source          te-info-source
>         |  +--ro information-source-state
>         |  |  +--ro credibility-preference?    uint16
>         |  |  +--ro logical-network-element?   string
>         |  |  +--ro network-instance?          string
>         |  |  +--ro topology
>         |  |     +--ro node-ref?      leafref
>         |  |     +--ro network-ref?   leafref
>         |  +--ro connectivity-matrices
>         |  |  +--ro number-of-entries?          uint16
>         |  |  +--ro label-restriction* [inclusive-exclusive label-
>   start]
>         |  |  |  +--ro inclusive-exclusive    enumeration
>         |  |  |  +--ro label-start            rt-types:generalized-
>   label
>         |  |  |  +--ro label-end?             rt-types:generalized-
>   label
>         |  |  |  +--ro range-bitmap?          binary
>         |  |  +--ro is-allowed?                 boolean
>         |  |  +--ro underlay {te-topology-hierarchy}?
>         |  |  |  +--ro enabled?                     boolean
>         |  |  |  +--ro primary-path
>         |  |  |  |  +--ro network-ref?    leafref
>         |  |  |  |  +--ro path-element* [path-element-id]
>=20
>=20
>         |  |  |  |     +--ro path-element-id    uint32
>         |  |  |  |     +--ro index?             uint32
>         |  |  |  |     +--ro (type)?
>         |  |  |  |        +--:(numbered)
>         |  |  |  |        |  +--ro numbered-hop
>         |  |  |  |        |     +--ro address?    te-types:te-tp-id
>         |  |  |  |        |     +--ro hop-type?   te-hop-type
>         |  |  |  |        +--:(as-number)
>         |  |  |  |        |  +--ro as-number-hop
>         |  |  |  |        |     +--ro as-number?   binary
>         |  |  |  |        |     +--ro hop-type?    te-hop-type
>         |  |  |  |        +--:(unnumbered)
>         |  |  |  |        |  +--ro unnumbered-hop
>         |  |  |  |        |     +--ro node-id?      =
te-types:te-node-id
>         |  |  |  |        |     +--ro link-tp-id?   te-types:te-tp-id
>         |  |  |  |        |     +--ro hop-type?     te-hop-type
>         |  |  |  |        +--:(label)
>         |  |  |  |        |  +--ro label-hop
>         |  |  |  |        |     +--ro value?   rt-types:generalized-
>   label
>         |  |  |  |        +--:(sid)
>         |  |  |  |           +--ro sid-hop
>         |  |  |  |              +--ro sid?   =
rt-types:generalized-label
>         |  |  |  +--ro backup-path* [index]
>         |  |  |  |  +--ro index           uint32
>         |  |  |  |  +--ro network-ref?    leafref
>         |  |  |  |  +--ro path-element* [path-element-id]
>         |  |  |  |     +--ro path-element-id    uint32
>         |  |  |  |     +--ro index?             uint32
>         |  |  |  |     +--ro (type)?
>         |  |  |  |        +--:(numbered)
>         |  |  |  |        |  +--ro numbered-hop
>         |  |  |  |        |     +--ro address?    te-types:te-tp-id
>         |  |  |  |        |     +--ro hop-type?   te-hop-type
>         |  |  |  |        +--:(as-number)
>         |  |  |  |        |  +--ro as-number-hop
>         |  |  |  |        |     +--ro as-number?   binary
>         |  |  |  |        |     +--ro hop-type?    te-hop-type
>         |  |  |  |        +--:(unnumbered)
>         |  |  |  |        |  +--ro unnumbered-hop
>         |  |  |  |        |     +--ro node-id?      =
te-types:te-node-id
>         |  |  |  |        |     +--ro link-tp-id?   te-types:te-tp-id
>         |  |  |  |        |     +--ro hop-type?     te-hop-type
>         |  |  |  |        +--:(label)
>         |  |  |  |        |  +--ro label-hop
>         |  |  |  |        |     +--ro value?   rt-types:generalized-
>   label
>=20
>=20
>         |  |  |  |        +--:(sid)
>         |  |  |  |           +--ro sid-hop
>         |  |  |  |              +--ro sid?   =
rt-types:generalized-label
>         |  |  |  +--ro protection-type?             identityref
>         |  |  |  +--ro tunnel-termination-points
>         |  |  |  |  +--ro source?        binary
>         |  |  |  |  +--ro destination?   binary
>         |  |  |  +--ro tunnels
>         |  |  |     +--ro sharing?   boolean
>         |  |  |     +--ro tunnel* [tunnel-name]
>         |  |  |        +--ro tunnel-name    string
>         |  |  |        +--ro sharing?       boolean
>         |  |  +--ro path-constraints
>         |  |  |  +--ro path-metric-bound* [metric-type]
>         |  |  |  |  +--ro metric-type    identityref
>         |  |  |  |  +--ro upper-bound?   uint64
>         |  |  |  +--ro topology-id?         te-types:te-topology-id
>         |  |  |  +--ro ignore-overload?     boolean
>         |  |  |  +--ro bandwidth-generic
>         |  |  |  |  +--ro te-bandwidth
>         |  |  |  |     +--ro (technology)?
>         |  |  |  |        +--:(psc)
>         |  |  |  |        |  +--ro psc?       rt-types:bandwidth-ieee-
>   float32
>         |  |  |  |        +--:(otn)
>         |  |  |  |        |  +--ro otn* [rate-type]
>         |  |  |  |        |     +--ro rate-type    identityref
>         |  |  |  |        |     +--ro counter?     uint16
>         |  |  |  |        +--:(lsc)
>         |  |  |  |        |  +--ro wdm* [spectrum slot]
>         |  |  |  |        |     +--ro spectrum    identityref
>         |  |  |  |        |     +--ro slot        int16
>         |  |  |  |        |     +--ro width?      uint16
>         |  |  |  |        +--:(generic)
>         |  |  |  |           +--ro generic?   te-bandwidth
>         |  |  |  +--ro disjointness?        te-types:te-path-
>   disjointness
>         |  |  |  +--ro setup-priority?      uint8
>         |  |  |  +--ro hold-priority?       uint8
>         |  |  |  +--ro signaling-type?      identityref
>         |  |  |  +--ro path-affinities
>         |  |  |  |  +--ro constraint* [usage]
>         |  |  |  |     +--ro usage    identityref
>         |  |  |  |     +--ro value?   admin-groups
>         |  |  |  +--ro path-srlgs
>         |  |  |     +--ro usage?    identityref
>         |  |  |     +--ro values*   srlg
>=20
>=20
>         |  |  +--ro optimizations
>         |  |  |  +--ro (algorithm)?
>         |  |  |     +--:(metric) {path-optimization-metric}?
>         |  |  |     |  +--ro optimization-metric* [metric-type]
>         |  |  |     |  |  +--ro metric-type    identityref
>         |  |  |     |  |  +--ro weight?        uint8
>         |  |  |     |  +--ro tiebreakers
>         |  |  |     |     +--ro tiebreaker* [tiebreaker-type]
>         |  |  |     |        +--ro tiebreaker-type    identityref
>         |  |  |     +--:(objective-function) {path-optimization-
>   objective-function}?
>         |  |  |        +--ro objective-function
>         |  |  |           +--ro objective-function-type?   identityref
>         |  |  +--ro computed-path-properties
>         |  |  |  +--ro path-metric* [metric-type]
>         |  |  |  |  +--ro metric-type           identityref
>         |  |  |  |  +--ro accumulative-value?   uint64
>         |  |  |  +--ro path-affinities
>         |  |  |  |  +--ro constraint* [usage]
>         |  |  |  |     +--ro usage    identityref
>         |  |  |  |     +--ro value?   admin-groups
>         |  |  |  +--ro path-srlgs
>         |  |  |  |  +--ro usage?    identityref
>         |  |  |  |  +--ro values*   srlg
>         |  |  |  +--ro path-computed-route-objects
>         |  |  |     +--ro path-computed-route-object* [index]
>         |  |  |        +--ro index             uint32
>         |  |  |        +--ro (type)?
>         |  |  |           +--:(numbered)
>         |  |  |           |  +--ro numbered-hop
>         |  |  |           |     +--ro address?    te-types:te-tp-id
>         |  |  |           |     +--ro hop-type?   te-hop-type
>         |  |  |           +--:(as-number)
>         |  |  |           |  +--ro as-number-hop
>         |  |  |           |     +--ro as-number?   binary
>         |  |  |           |     +--ro hop-type?    te-hop-type
>         |  |  |           +--:(unnumbered)
>         |  |  |           |  +--ro unnumbered-hop
>         |  |  |           |     +--ro node-id?      =
te-types:te-node-id
>         |  |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>         |  |  |           |     +--ro hop-type?     te-hop-type
>         |  |  |           +--:(label)
>         |  |  |           |  +--ro label-hop
>         |  |  |           |     +--ro value?   rt-types:generalized-
>   label
>         |  |  |           +--:(sid)
>         |  |  |              +--ro sid-hop
>=20
>=20
>         |  |  |                 +--ro sid?   =
rt-types:generalized-label
>         |  |  +--ro connectivity-matrix* [id]
>         |  |     +--ro id                          uint32
>         |  |     +--ro from
>         |  |     |  +--ro tp-ref?              leafref
>         |  |     |  +--ro label-restriction* [inclusive-exclusive
>   label-start]
>         |  |     |     +--ro inclusive-exclusive    enumeration
>         |  |     |     +--ro label-start            rt-
>   types:generalized-label
>         |  |     |     +--ro label-end?             rt-
>   types:generalized-label
>         |  |     |     +--ro range-bitmap?          binary
>         |  |     +--ro to
>         |  |     |  +--ro tp-ref?              leafref
>         |  |     |  +--ro label-restriction* [inclusive-exclusive
>   label-start]
>         |  |     |     +--ro inclusive-exclusive    enumeration
>         |  |     |     +--ro label-start            rt-
>   types:generalized-label
>         |  |     |     +--ro label-end?             rt-
>   types:generalized-label
>         |  |     |     +--ro range-bitmap?          binary
>         |  |     +--ro is-allowed?                 boolean
>         |  |     +--ro underlay {te-topology-hierarchy}?
>         |  |     |  +--ro enabled?                     boolean
>         |  |     |  +--ro primary-path
>         |  |     |  |  +--ro network-ref?    leafref
>         |  |     |  |  +--ro path-element* [path-element-id]
>         |  |     |  |     +--ro path-element-id    uint32
>         |  |     |  |     +--ro index?             uint32
>         |  |     |  |     +--ro (type)?
>         |  |     |  |        +--:(numbered)
>         |  |     |  |        |  +--ro numbered-hop
>         |  |     |  |        |     +--ro address?    te-types:te-tp-id
>         |  |     |  |        |     +--ro hop-type?   te-hop-type
>         |  |     |  |        +--:(as-number)
>         |  |     |  |        |  +--ro as-number-hop
>         |  |     |  |        |     +--ro as-number?   binary
>         |  |     |  |        |     +--ro hop-type?    te-hop-type
>         |  |     |  |        +--:(unnumbered)
>         |  |     |  |        |  +--ro unnumbered-hop
>         |  |     |  |        |     +--ro node-id?      te-types:te-
>   node-id
>         |  |     |  |        |     +--ro link-tp-id?   te-types:te-tp-
>   id
>         |  |     |  |        |     +--ro hop-type?     te-hop-type
>=20
>=20
>         |  |     |  |        +--:(label)
>         |  |     |  |        |  +--ro label-hop
>         |  |     |  |        |     +--ro value?   =
rt-types:generalized-
>   label
>         |  |     |  |        +--:(sid)
>         |  |     |  |           +--ro sid-hop
>         |  |     |  |              +--ro sid?   rt-types:generalized-
>   label
>         |  |     |  +--ro backup-path* [index]
>         |  |     |  |  +--ro index           uint32
>         |  |     |  |  +--ro network-ref?    leafref
>         |  |     |  |  +--ro path-element* [path-element-id]
>         |  |     |  |     +--ro path-element-id    uint32
>         |  |     |  |     +--ro index?             uint32
>         |  |     |  |     +--ro (type)?
>         |  |     |  |        +--:(numbered)
>         |  |     |  |        |  +--ro numbered-hop
>         |  |     |  |        |     +--ro address?    te-types:te-tp-id
>         |  |     |  |        |     +--ro hop-type?   te-hop-type
>         |  |     |  |        +--:(as-number)
>         |  |     |  |        |  +--ro as-number-hop
>         |  |     |  |        |     +--ro as-number?   binary
>         |  |     |  |        |     +--ro hop-type?    te-hop-type
>         |  |     |  |        +--:(unnumbered)
>         |  |     |  |        |  +--ro unnumbered-hop
>         |  |     |  |        |     +--ro node-id?      te-types:te-
>   node-id
>         |  |     |  |        |     +--ro link-tp-id?   te-types:te-tp-
>   id
>         |  |     |  |        |     +--ro hop-type?     te-hop-type
>         |  |     |  |        +--:(label)
>         |  |     |  |        |  +--ro label-hop
>         |  |     |  |        |     +--ro value?   =
rt-types:generalized-
>   label
>         |  |     |  |        +--:(sid)
>         |  |     |  |           +--ro sid-hop
>         |  |     |  |              +--ro sid?   rt-types:generalized-
>   label
>         |  |     |  +--ro protection-type?             identityref
>         |  |     |  +--ro tunnel-termination-points
>         |  |     |  |  +--ro source?        binary
>         |  |     |  |  +--ro destination?   binary
>         |  |     |  +--ro tunnels
>         |  |     |     +--ro sharing?   boolean
>         |  |     |     +--ro tunnel* [tunnel-name]
>         |  |     |        +--ro tunnel-name    string
>         |  |     |        +--ro sharing?       boolean
>=20
>=20
>=20
>         |  |     +--ro path-constraints
>         |  |     |  +--ro path-metric-bound* [metric-type]
>         |  |     |  |  +--ro metric-type    identityref
>         |  |     |  |  +--ro upper-bound?   uint64
>         |  |     |  +--ro topology-id?         te-types:te-topology-id
>         |  |     |  +--ro ignore-overload?     boolean
>         |  |     |  +--ro bandwidth-generic
>         |  |     |  |  +--ro te-bandwidth
>         |  |     |  |     +--ro (technology)?
>         |  |     |  |        +--:(psc)
>         |  |     |  |        |  +--ro psc?       rt-types:bandwidth-
>   ieee-float32
>         |  |     |  |        +--:(otn)
>         |  |     |  |        |  +--ro otn* [rate-type]
>         |  |     |  |        |     +--ro rate-type    identityref
>         |  |     |  |        |     +--ro counter?     uint16
>         |  |     |  |        +--:(lsc)
>         |  |     |  |        |  +--ro wdm* [spectrum slot]
>         |  |     |  |        |     +--ro spectrum    identityref
>         |  |     |  |        |     +--ro slot        int16
>         |  |     |  |        |     +--ro width?      uint16
>         |  |     |  |        +--:(generic)
>         |  |     |  |           +--ro generic?   te-bandwidth
>         |  |     |  +--ro disjointness?        te-types:te-path-
>   disjointness
>         |  |     |  +--ro setup-priority?      uint8
>         |  |     |  +--ro hold-priority?       uint8
>         |  |     |  +--ro signaling-type?      identityref
>         |  |     |  +--ro path-affinities
>         |  |     |  |  +--ro constraint* [usage]
>         |  |     |  |     +--ro usage    identityref
>         |  |     |  |     +--ro value?   admin-groups
>         |  |     |  +--ro path-srlgs
>         |  |     |     +--ro usage?    identityref
>         |  |     |     +--ro values*   srlg
>         |  |     +--ro optimizations
>         |  |     |  +--ro (algorithm)?
>         |  |     |     +--:(metric) {path-optimization-metric}?
>         |  |     |     |  +--ro optimization-metric* [metric-type]
>         |  |     |     |  |  +--ro metric-type    identityref
>         |  |     |     |  |  +--ro weight?        uint8
>         |  |     |     |  +--ro tiebreakers
>         |  |     |     |     +--ro tiebreaker* [tiebreaker-type]
>         |  |     |     |        +--ro tiebreaker-type    identityref
>         |  |     |     +--:(objective-function) {path-optimization-
>   objective-function}?
>         |  |     |        +--ro objective-function
>=20
>=20
>         |  |     |           +--ro objective-function-type?
>   identityref
>         |  |     +--ro computed-path-properties
>         |  |        +--ro path-metric* [metric-type]
>         |  |        |  +--ro metric-type           identityref
>         |  |        |  +--ro accumulative-value?   uint64
>         |  |        +--ro path-affinities
>         |  |        |  +--ro constraint* [usage]
>         |  |        |     +--ro usage    identityref
>         |  |        |     +--ro value?   admin-groups
>         |  |        +--ro path-srlgs
>         |  |        |  +--ro usage?    identityref
>         |  |        |  +--ro values*   srlg
>         |  |        +--ro path-computed-route-objects
>         |  |           +--ro path-computed-route-object* [index]
>         |  |              +--ro index             uint32
>         |  |              +--ro (type)?
>         |  |                 +--:(numbered)
>         |  |                 |  +--ro numbered-hop
>         |  |                 |     +--ro address?    te-types:te-tp-id
>         |  |                 |     +--ro hop-type?   te-hop-type
>         |  |                 +--:(as-number)
>         |  |                 |  +--ro as-number-hop
>         |  |                 |     +--ro as-number?   binary
>         |  |                 |     +--ro hop-type?    te-hop-type
>         |  |                 +--:(unnumbered)
>         |  |                 |  +--ro unnumbered-hop
>         |  |                 |     +--ro node-id?      te-types:te-
>   node-id
>         |  |                 |     +--ro link-tp-id?   te-types:te-tp-
>   id
>         |  |                 |     +--ro hop-type?     te-hop-type
>         |  |                 +--:(label)
>         |  |                 |  +--ro label-hop
>         |  |                 |     +--ro value?   =
rt-types:generalized-
>   label
>         |  |                 +--:(sid)
>         |  |                    +--ro sid-hop
>         |  |                       +--ro sid?   rt-types:generalized-
>   label
>         |  +--ro domain-id?                  uint32
>         |  +--ro is-abstract?                empty
>         |  +--ro name?                       inet:domain-name
>         |  +--ro signaling-address*          inet:ip-address
>         |  +--ro underlay-topology {te-topology-hierarchy}?
>         |     +--ro network-ref?   leafref
>         +--ro statistics
>=20
>=20
>=20
>         |  +--ro discontinuity-time           yang:date-and-time
>         |  +--ro node
>         |  |  +--ro disables?             yang:counter32
>         |  |  +--ro enables?              yang:counter32
>         |  |  +--ro maintenance-sets?     yang:counter32
>         |  |  +--ro maintenance-clears?   yang:counter32
>         |  |  +--ro modifies?             yang:counter32
>         |  +--ro connectivity-matrix-entry
>         |     +--ro creates?    yang:counter32
>         |     +--ro deletes?    yang:counter32
>         |     +--ro disables?   yang:counter32
>         |     +--ro enables?    yang:counter32
>         |     +--ro modifies?   yang:counter32
>         +--rw tunnel-termination-point* [tunnel-tp-id]
>            +--rw tunnel-tp-id                           binary
>            +--rw admin-status?                          te-types:te-
>   admin-status
>            +--rw name?                                  string
>            +--rw switching-capability?                  identityref
>            +--rw encoding?                              identityref
>            +--rw inter-layer-lock-id*                   uint32
>            +--rw protection-type?                       identityref
>            +--rw client-layer-adaptation
>            |  +--rw switching-capability* [switching-capability
>   encoding]
>            |     +--rw switching-capability    identityref
>            |     +--rw encoding                identityref
>            |     +--rw bandwidth
>            |        +--rw te-bandwidth
>            |           +--rw (technology)?
>            |              +--:(psc)
>            |              |  +--rw psc?       rt-types:bandwidth-ieee-
>   float32
>            |              +--:(otn)
>            |              |  +--rw otn* [rate-type]
>            |              |     +--rw rate-type    identityref
>            |              |     +--rw counter?     uint16
>            |              +--:(lsc)
>            |              |  +--rw wdm* [spectrum slot]
>            |              |     +--rw spectrum    identityref
>            |              |     +--rw slot        int16
>            |              |     +--rw width?      uint16
>            |              +--:(generic)
>            |                 +--rw generic?   te-bandwidth
>            +--rw local-link-connectivities
>            |  +--rw number-of-entries?          uint16
>=20
>=20
>=20
>            |  +--rw label-restriction* [inclusive-exclusive label-
>   start]
>            |  |  +--rw inclusive-exclusive    enumeration
>            |  |  +--rw label-start            rt-types:generalized-
>   label
>            |  |  +--rw label-end?             rt-types:generalized-
>   label
>            |  |  +--rw range-bitmap?          binary
>            |  +--rw is-allowed?                 boolean
>            |  +--rw underlay {te-topology-hierarchy}?
>            |  |  +--rw enabled?                     boolean
>            |  |  +--rw primary-path
>            |  |  |  +--rw network-ref?    leafref
>            |  |  |  +--rw path-element* [path-element-id]
>            |  |  |     +--rw path-element-id    uint32
>            |  |  |     +--rw index?             uint32
>            |  |  |     +--rw (type)?
>            |  |  |        +--:(numbered)
>            |  |  |        |  +--rw numbered-hop
>            |  |  |        |     +--rw address?    te-types:te-tp-id
>            |  |  |        |     +--rw hop-type?   te-hop-type
>            |  |  |        +--:(as-number)
>            |  |  |        |  +--rw as-number-hop
>            |  |  |        |     +--rw as-number?   binary
>            |  |  |        |     +--rw hop-type?    te-hop-type
>            |  |  |        +--:(unnumbered)
>            |  |  |        |  +--rw unnumbered-hop
>            |  |  |        |     +--rw node-id?      =
te-types:te-node-id
>            |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>            |  |  |        |     +--rw hop-type?     te-hop-type
>            |  |  |        +--:(label)
>            |  |  |        |  +--rw label-hop
>            |  |  |        |     +--rw value?   rt-types:generalized-
>   label
>            |  |  |        +--:(sid)
>            |  |  |           +--rw sid-hop
>            |  |  |              +--rw sid?   =
rt-types:generalized-label
>            |  |  +--rw backup-path* [index]
>            |  |  |  +--rw index           uint32
>            |  |  |  +--rw network-ref?    leafref
>            |  |  |  +--rw path-element* [path-element-id]
>            |  |  |     +--rw path-element-id    uint32
>            |  |  |     +--rw index?             uint32
>            |  |  |     +--rw (type)?
>            |  |  |        +--:(numbered)
>            |  |  |        |  +--rw numbered-hop
>            |  |  |        |     +--rw address?    te-types:te-tp-id
>=20
>=20
>=20
>=20
>            |  |  |        |     +--rw hop-type?   te-hop-type
>            |  |  |        +--:(as-number)
>            |  |  |        |  +--rw as-number-hop
>            |  |  |        |     +--rw as-number?   binary
>            |  |  |        |     +--rw hop-type?    te-hop-type
>            |  |  |        +--:(unnumbered)
>            |  |  |        |  +--rw unnumbered-hop
>            |  |  |        |     +--rw node-id?      =
te-types:te-node-id
>            |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>            |  |  |        |     +--rw hop-type?     te-hop-type
>            |  |  |        +--:(label)
>            |  |  |        |  +--rw label-hop
>            |  |  |        |     +--rw value?   rt-types:generalized-
>   label
>            |  |  |        +--:(sid)
>            |  |  |           +--rw sid-hop
>            |  |  |              +--rw sid?   =
rt-types:generalized-label
>            |  |  +--rw protection-type?             identityref
>            |  |  +--rw tunnel-termination-points
>            |  |  |  +--rw source?        binary
>            |  |  |  +--rw destination?   binary
>            |  |  +--rw tunnels
>            |  |     +--rw sharing?   boolean
>            |  |     +--rw tunnel* [tunnel-name]
>            |  |        +--rw tunnel-name    string
>            |  |        +--rw sharing?       boolean
>            |  +--rw path-constraints
>            |  |  +--rw path-metric-bound* [metric-type]
>            |  |  |  +--rw metric-type    identityref
>            |  |  |  +--rw upper-bound?   uint64
>            |  |  +--rw topology-id?         te-types:te-topology-id
>            |  |  +--rw ignore-overload?     boolean
>            |  |  +--rw bandwidth-generic
>            |  |  |  +--rw te-bandwidth
>            |  |  |     +--rw (technology)?
>            |  |  |        +--:(psc)
>            |  |  |        |  +--rw psc?       rt-types:bandwidth-ieee-
>   float32
>            |  |  |        +--:(otn)
>            |  |  |        |  +--rw otn* [rate-type]
>            |  |  |        |     +--rw rate-type    identityref
>            |  |  |        |     +--rw counter?     uint16
>            |  |  |        +--:(lsc)
>            |  |  |        |  +--rw wdm* [spectrum slot]
>            |  |  |        |     +--rw spectrum    identityref
>            |  |  |        |     +--rw slot        int16
>            |  |  |        |     +--rw width?      uint16
>=20
>=20
>=20
>=20
>            |  |  |        +--:(generic)
>            |  |  |           +--rw generic?   te-bandwidth
>            |  |  +--rw disjointness?        te-types:te-path-
>   disjointness
>            |  |  +--rw setup-priority?      uint8
>            |  |  +--rw hold-priority?       uint8
>            |  |  +--rw signaling-type?      identityref
>            |  |  +--rw path-affinities
>            |  |  |  +--rw constraint* [usage]
>            |  |  |     +--rw usage    identityref
>            |  |  |     +--rw value?   admin-groups
>            |  |  +--rw path-srlgs
>            |  |     +--rw usage?    identityref
>            |  |     +--rw values*   srlg
>            |  +--rw optimizations
>            |  |  +--rw (algorithm)?
>            |  |     +--:(metric) {path-optimization-metric}?
>            |  |     |  +--rw optimization-metric* [metric-type]
>            |  |     |  |  +--rw metric-type    identityref
>            |  |     |  |  +--rw weight?        uint8
>            |  |     |  +--rw tiebreakers
>            |  |     |     +--rw tiebreaker* [tiebreaker-type]
>            |  |     |        +--rw tiebreaker-type    identityref
>            |  |     +--:(objective-function) {path-optimization-
>   objective-function}?
>            |  |        +--rw objective-function
>            |  |           +--rw objective-function-type?   identityref
>            |  +--ro computed-path-properties
>            |  |  +--ro path-metric* [metric-type]
>            |  |  |  +--ro metric-type           identityref
>            |  |  |  +--ro accumulative-value?   uint64
>            |  |  +--ro path-affinities
>            |  |  |  +--ro constraint* [usage]
>            |  |  |     +--ro usage    identityref
>            |  |  |     +--ro value?   admin-groups
>            |  |  +--ro path-srlgs
>            |  |  |  +--ro usage?    identityref
>            |  |  |  +--ro values*   srlg
>            |  |  +--ro path-computed-route-objects
>            |  |     +--ro path-computed-route-object* [index]
>            |  |        +--ro index             uint32
>            |  |        +--ro (type)?
>            |  |           +--:(numbered)
>            |  |           |  +--ro numbered-hop
>            |  |           |     +--ro address?    te-types:te-tp-id
>            |  |           |     +--ro hop-type?   te-hop-type
>            |  |           +--:(as-number)
>=20
>=20
>=20
>            |  |           |  +--ro as-number-hop
>            |  |           |     +--ro as-number?   binary
>            |  |           |     +--ro hop-type?    te-hop-type
>            |  |           +--:(unnumbered)
>            |  |           |  +--ro unnumbered-hop
>            |  |           |     +--ro node-id?      =
te-types:te-node-id
>            |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>            |  |           |     +--ro hop-type?     te-hop-type
>            |  |           +--:(label)
>            |  |           |  +--ro label-hop
>            |  |           |     +--ro value?   rt-types:generalized-
>   label
>            |  |           +--:(sid)
>            |  |              +--ro sid-hop
>            |  |                 +--ro sid?   =
rt-types:generalized-label
>            |  +--rw local-link-connectivity* [link-tp-ref]
>            |     +--rw link-tp-ref                 leafref
>            |     +--rw label-restriction* [inclusive-exclusive label-
>   start]
>            |     |  +--rw inclusive-exclusive    enumeration
>            |     |  +--rw label-start            rt-types:generalized-
>   label
>            |     |  +--rw label-end?             rt-types:generalized-
>   label
>            |     |  +--rw range-bitmap?          binary
>            |     +--rw is-allowed?                 boolean
>            |     +--rw underlay {te-topology-hierarchy}?
>            |     |  +--rw enabled?                     boolean
>            |     |  +--rw primary-path
>            |     |  |  +--rw network-ref?    leafref
>            |     |  |  +--rw path-element* [path-element-id]
>            |     |  |     +--rw path-element-id    uint32
>            |     |  |     +--rw index?             uint32
>            |     |  |     +--rw (type)?
>            |     |  |        +--:(numbered)
>            |     |  |        |  +--rw numbered-hop
>            |     |  |        |     +--rw address?    te-types:te-tp-id
>            |     |  |        |     +--rw hop-type?   te-hop-type
>            |     |  |        +--:(as-number)
>            |     |  |        |  +--rw as-number-hop
>            |     |  |        |     +--rw as-number?   binary
>            |     |  |        |     +--rw hop-type?    te-hop-type
>            |     |  |        +--:(unnumbered)
>            |     |  |        |  +--rw unnumbered-hop
>            |     |  |        |     +--rw node-id?      te-types:te-
>   node-id
>=20
>=20
>=20
>=20
>            |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>   id
>            |     |  |        |     +--rw hop-type?     te-hop-type
>            |     |  |        +--:(label)
>            |     |  |        |  +--rw label-hop
>            |     |  |        |     +--rw value?   =
rt-types:generalized-
>   label
>            |     |  |        +--:(sid)
>            |     |  |           +--rw sid-hop
>            |     |  |              +--rw sid?   rt-types:generalized-
>   label
>            |     |  +--rw backup-path* [index]
>            |     |  |  +--rw index           uint32
>            |     |  |  +--rw network-ref?    leafref
>            |     |  |  +--rw path-element* [path-element-id]
>            |     |  |     +--rw path-element-id    uint32
>            |     |  |     +--rw index?             uint32
>            |     |  |     +--rw (type)?
>            |     |  |        +--:(numbered)
>            |     |  |        |  +--rw numbered-hop
>            |     |  |        |     +--rw address?    te-types:te-tp-id
>            |     |  |        |     +--rw hop-type?   te-hop-type
>            |     |  |        +--:(as-number)
>            |     |  |        |  +--rw as-number-hop
>            |     |  |        |     +--rw as-number?   binary
>            |     |  |        |     +--rw hop-type?    te-hop-type
>            |     |  |        +--:(unnumbered)
>            |     |  |        |  +--rw unnumbered-hop
>            |     |  |        |     +--rw node-id?      te-types:te-
>   node-id
>            |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>   id
>            |     |  |        |     +--rw hop-type?     te-hop-type
>            |     |  |        +--:(label)
>            |     |  |        |  +--rw label-hop
>            |     |  |        |     +--rw value?   =
rt-types:generalized-
>   label
>            |     |  |        +--:(sid)
>            |     |  |           +--rw sid-hop
>            |     |  |              +--rw sid?   rt-types:generalized-
>   label
>            |     |  +--rw protection-type?             identityref
>            |     |  +--rw tunnel-termination-points
>            |     |  |  +--rw source?        binary
>            |     |  |  +--rw destination?   binary
>            |     |  +--rw tunnels
>            |     |     +--rw sharing?   boolean
>=20
>=20
>=20
>            |     |     +--rw tunnel* [tunnel-name]
>            |     |        +--rw tunnel-name    string
>            |     |        +--rw sharing?       boolean
>            |     +--rw path-constraints
>            |     |  +--rw path-metric-bound* [metric-type]
>            |     |  |  +--rw metric-type    identityref
>            |     |  |  +--rw upper-bound?   uint64
>            |     |  +--rw topology-id?         te-types:te-topology-id
>            |     |  +--rw ignore-overload?     boolean
>            |     |  +--rw bandwidth-generic
>            |     |  |  +--rw te-bandwidth
>            |     |  |     +--rw (technology)?
>            |     |  |        +--:(psc)
>            |     |  |        |  +--rw psc?       rt-types:bandwidth-
>   ieee-float32
>            |     |  |        +--:(otn)
>            |     |  |        |  +--rw otn* [rate-type]
>            |     |  |        |     +--rw rate-type    identityref
>            |     |  |        |     +--rw counter?     uint16
>            |     |  |        +--:(lsc)
>            |     |  |        |  +--rw wdm* [spectrum slot]
>            |     |  |        |     +--rw spectrum    identityref
>            |     |  |        |     +--rw slot        int16
>            |     |  |        |     +--rw width?      uint16
>            |     |  |        +--:(generic)
>            |     |  |           +--rw generic?   te-bandwidth
>            |     |  +--rw disjointness?        te-types:te-path-
>   disjointness
>            |     |  +--rw setup-priority?      uint8
>            |     |  +--rw hold-priority?       uint8
>            |     |  +--rw signaling-type?      identityref
>            |     |  +--rw path-affinities
>            |     |  |  +--rw constraint* [usage]
>            |     |  |     +--rw usage    identityref
>            |     |  |     +--rw value?   admin-groups
>            |     |  +--rw path-srlgs
>            |     |     +--rw usage?    identityref
>            |     |     +--rw values*   srlg
>            |     +--rw optimizations
>            |     |  +--rw (algorithm)?
>            |     |     +--:(metric) {path-optimization-metric}?
>            |     |     |  +--rw optimization-metric* [metric-type]
>            |     |     |  |  +--rw metric-type    identityref
>            |     |     |  |  +--rw weight?        uint8
>            |     |     |  +--rw tiebreakers
>            |     |     |     +--rw tiebreaker* [tiebreaker-type]
>            |     |     |        +--rw tiebreaker-type    identityref
>=20
>=20
>=20
>=20
>            |     |     +--:(objective-function) {path-optimization-
>   objective-function}?
>            |     |        +--rw objective-function
>            |     |           +--rw objective-function-type?
>   identityref
>            |     +--ro computed-path-properties
>            |        +--ro path-metric* [metric-type]
>            |        |  +--ro metric-type           identityref
>            |        |  +--ro accumulative-value?   uint64
>            |        +--ro path-affinities
>            |        |  +--ro constraint* [usage]
>            |        |     +--ro usage    identityref
>            |        |     +--ro value?   admin-groups
>            |        +--ro path-srlgs
>            |        |  +--ro usage?    identityref
>            |        |  +--ro values*   srlg
>            |        +--ro path-computed-route-objects
>            |           +--ro path-computed-route-object* [index]
>            |              +--ro index             uint32
>            |              +--ro (type)?
>            |                 +--:(numbered)
>            |                 |  +--ro numbered-hop
>            |                 |     +--ro address?    te-types:te-tp-id
>            |                 |     +--ro hop-type?   te-hop-type
>            |                 +--:(as-number)
>            |                 |  +--ro as-number-hop
>            |                 |     +--ro as-number?   binary
>            |                 |     +--ro hop-type?    te-hop-type
>            |                 +--:(unnumbered)
>            |                 |  +--ro unnumbered-hop
>            |                 |     +--ro node-id?      te-types:te-
>   node-id
>            |                 |     +--ro link-tp-id?   te-types:te-tp-
>   id
>            |                 |     +--ro hop-type?     te-hop-type
>            |                 +--:(label)
>            |                 |  +--ro label-hop
>            |                 |     +--ro value?   =
rt-types:generalized-
>   label
>            |                 +--:(sid)
>            |                    +--ro sid-hop
>            |                       +--ro sid?   rt-types:generalized-
>   label
>            +--ro oper-status?                           te-types:te-
>   oper-status
>            +--ro geolocation
>            |  +--ro altitude?    int64
>=20
>=20
>            |  +--ro latitude?    geographic-coordinate-degree
>            |  +--ro longitude?   geographic-coordinate-degree
>            +--ro statistics
>            |  +--ro discontinuity-time          yang:date-and-time
>            |  +--ro tunnel-termination-point
>            |  |  +--ro disables?             yang:counter32
>            |  |  +--ro enables?              yang:counter32
>            |  |  +--ro maintenance-clears?   yang:counter32
>            |  |  +--ro maintenance-sets?     yang:counter32
>            |  |  +--ro modifies?             yang:counter32
>            |  |  +--ro downs?                yang:counter32
>            |  |  +--ro ups?                  yang:counter32
>            |  |  +--ro in-service-clears?    yang:counter32
>            |  |  +--ro in-service-sets?      yang:counter32
>            |  +--ro local-link-connectivity
>            |     +--ro creates?    yang:counter32
>            |     +--ro deletes?    yang:counter32
>            |     +--ro disables?   yang:counter32
>            |     +--ro enables?    yang:counter32
>            |     +--ro modifies?   yang:counter32
>            +--rw supporting-tunnel-termination-point* [node-ref =
tunnel-
>   tp-ref]
>               +--rw node-ref         inet:uri
>               +--rw tunnel-tp-ref    binary
>   augment /nw:networks/nw:network/nt:link:
>      +--rw te!
>         +--rw (bundle-stack-level)?
>         |  +--:(bundle)
>         |  |  +--rw bundled-links
>         |  |     +--rw bundled-link* [sequence]
>         |  |        +--rw sequence      uint32
>         |  |        +--rw src-tp-ref?   leafref
>         |  |        +--rw des-tp-ref?   leafref
>         |  +--:(component)
>         |     +--rw component-links
>         |        +--rw component-link* [sequence]
>         |           +--rw sequence             uint32
>         |           +--rw src-interface-ref?   string
>         |           +--rw des-interface-ref?   string
>         +--rw te-link-template*           leafref {template}?
>         +--rw te-link-attributes
>         |  +--rw access-type?                      te-types:te-link-
>   access-type
>         |  +--rw external-domain
>         |  |  +--rw network-ref?            leafref
>         |  |  +--rw remote-te-node-id?      te-types:te-node-id
>         |  |  +--rw remote-te-link-tp-id?   te-types:te-tp-id
>=20
>=20
>=20
>=20
>         |  |  +--rw plug-id?                uint32
>         |  +--rw is-abstract?                      empty
>         |  +--rw name?                             string
>         |  +--rw underlay {te-topology-hierarchy}?
>         |  |  +--rw enabled?                     boolean
>         |  |  +--rw primary-path
>         |  |  |  +--rw network-ref?    leafref
>         |  |  |  +--rw path-element* [path-element-id]
>         |  |  |     +--rw path-element-id    uint32
>         |  |  |     +--rw index?             uint32
>         |  |  |     +--rw (type)?
>         |  |  |        +--:(numbered)
>         |  |  |        |  +--rw numbered-hop
>         |  |  |        |     +--rw address?    te-types:te-tp-id
>         |  |  |        |     +--rw hop-type?   te-hop-type
>         |  |  |        +--:(as-number)
>         |  |  |        |  +--rw as-number-hop
>         |  |  |        |     +--rw as-number?   binary
>         |  |  |        |     +--rw hop-type?    te-hop-type
>         |  |  |        +--:(unnumbered)
>         |  |  |        |  +--rw unnumbered-hop
>         |  |  |        |     +--rw node-id?      te-types:te-node-id
>         |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>         |  |  |        |     +--rw hop-type?     te-hop-type
>         |  |  |        +--:(label)
>         |  |  |        |  +--rw label-hop
>         |  |  |        |     +--rw value?   rt-types:generalized-label
>         |  |  |        +--:(sid)
>         |  |  |           +--rw sid-hop
>         |  |  |              +--rw sid?   rt-types:generalized-label
>         |  |  +--rw backup-path* [index]
>         |  |  |  +--rw index           uint32
>         |  |  |  +--rw network-ref?    leafref
>         |  |  |  +--rw path-element* [path-element-id]
>         |  |  |     +--rw path-element-id    uint32
>         |  |  |     +--rw index?             uint32
>         |  |  |     +--rw (type)?
>         |  |  |        +--:(numbered)
>         |  |  |        |  +--rw numbered-hop
>         |  |  |        |     +--rw address?    te-types:te-tp-id
>         |  |  |        |     +--rw hop-type?   te-hop-type
>         |  |  |        +--:(as-number)
>         |  |  |        |  +--rw as-number-hop
>         |  |  |        |     +--rw as-number?   binary
>         |  |  |        |     +--rw hop-type?    te-hop-type
>         |  |  |        +--:(unnumbered)
>         |  |  |        |  +--rw unnumbered-hop
>=20
>=20
>         |  |  |        |     +--rw node-id?      te-types:te-node-id
>         |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>         |  |  |        |     +--rw hop-type?     te-hop-type
>         |  |  |        +--:(label)
>         |  |  |        |  +--rw label-hop
>         |  |  |        |     +--rw value?   rt-types:generalized-label
>         |  |  |        +--:(sid)
>         |  |  |           +--rw sid-hop
>         |  |  |              +--rw sid?   rt-types:generalized-label
>         |  |  +--rw protection-type?             identityref
>         |  |  +--rw tunnel-termination-points
>         |  |  |  +--rw source?        binary
>         |  |  |  +--rw destination?   binary
>         |  |  +--rw tunnels
>         |  |     +--rw sharing?   boolean
>         |  |     +--rw tunnel* [tunnel-name]
>         |  |        +--rw tunnel-name    string
>         |  |        +--rw sharing?       boolean
>         |  +--rw admin-status?                     te-types:te-admin-
>   status
>         |  +--rw link-index?                       uint64
>         |  +--rw administrative-group?             te-types:admin-
>   groups
>         |  +--rw interface-switching-capability* [switching-capability
>   encoding]
>         |  |  +--rw switching-capability    identityref
>         |  |  +--rw encoding                identityref
>         |  |  +--rw max-lsp-bandwidth* [priority]
>         |  |     +--rw priority     uint8
>         |  |     +--rw bandwidth
>         |  |        +--rw te-bandwidth
>         |  |           +--rw (technology)?
>         |  |              +--:(psc)
>         |  |              |  +--rw psc?       rt-types:bandwidth-ieee-
>   float32
>         |  |              +--:(otn)
>         |  |              |  +--rw otn* [rate-type]
>         |  |              |     +--rw rate-type    identityref
>         |  |              |     +--rw counter?     uint16
>         |  |              +--:(lsc)
>         |  |              |  +--rw wdm* [spectrum slot]
>         |  |              |     +--rw spectrum    identityref
>         |  |              |     +--rw slot        int16
>         |  |              |     +--rw width?      uint16
>         |  |              +--:(generic)
>         |  |                 +--rw generic?   te-bandwidth
>         |  +--rw label-restriction* [inclusive-exclusive label-start]
>=20
>=20
>=20
>         |  |  +--rw inclusive-exclusive    enumeration
>         |  |  +--rw label-start            rt-types:generalized-label
>         |  |  +--rw label-end?             rt-types:generalized-label
>         |  |  +--rw range-bitmap?          binary
>         |  +--rw link-protection-type?             enumeration
>         |  +--rw max-link-bandwidth
>         |  |  +--rw te-bandwidth
>         |  |     +--rw (technology)?
>         |  |        +--:(psc)
>         |  |        |  +--rw psc?       =
rt-types:bandwidth-ieee-float32
>         |  |        +--:(otn)
>         |  |        |  +--rw otn* [rate-type]
>         |  |        |     +--rw rate-type    identityref
>         |  |        |     +--rw counter?     uint16
>         |  |        +--:(lsc)
>         |  |        |  +--rw wdm* [spectrum slot]
>         |  |        |     +--rw spectrum    identityref
>         |  |        |     +--rw slot        int16
>         |  |        |     +--rw width?      uint16
>         |  |        +--:(generic)
>         |  |           +--rw generic?   te-bandwidth
>         |  +--rw max-resv-link-bandwidth
>         |  |  +--rw te-bandwidth
>         |  |     +--rw (technology)?
>         |  |        +--:(psc)
>         |  |        |  +--rw psc?       =
rt-types:bandwidth-ieee-float32
>         |  |        +--:(otn)
>         |  |        |  +--rw otn* [rate-type]
>         |  |        |     +--rw rate-type    identityref
>         |  |        |     +--rw counter?     uint16
>         |  |        +--:(lsc)
>         |  |        |  +--rw wdm* [spectrum slot]
>         |  |        |     +--rw spectrum    identityref
>         |  |        |     +--rw slot        int16
>         |  |        |     +--rw width?      uint16
>         |  |        +--:(generic)
>         |  |           +--rw generic?   te-bandwidth
>         |  +--rw unreserved-bandwidth* [priority]
>         |  |  +--rw priority     uint8
>         |  |  +--rw bandwidth
>         |  |     +--rw te-bandwidth
>         |  |        +--rw (technology)?
>         |  |           +--:(psc)
>         |  |           |  +--rw psc?       rt-types:bandwidth-ieee-
>   float32
>         |  |           +--:(otn)
>         |  |           |  +--rw otn* [rate-type]
>=20
>=20
>         |  |           |     +--rw rate-type    identityref
>         |  |           |     +--rw counter?     uint16
>         |  |           +--:(lsc)
>         |  |           |  +--rw wdm* [spectrum slot]
>         |  |           |     +--rw spectrum    identityref
>         |  |           |     +--rw slot        int16
>         |  |           |     +--rw width?      uint16
>         |  |           +--:(generic)
>         |  |              +--rw generic?   te-bandwidth
>         |  +--rw te-default-metric?                uint32
>         |  +--rw te-delay-metric?                  uint32
>         |  +--rw te-igp-metric?                    uint32
>         |  +--rw te-srlgs
>         |  |  +--rw value*   te-types:srlg
>         |  +--rw te-nsrlgs {nsrlg}?
>         |     +--rw id*   uint32
>         +--ro oper-status?                te-types:te-oper-status
>         +--ro is-transitional?            empty
>         +--ro information-source?         te-info-source
>         +--ro information-source-state
>         |  +--ro credibility-preference?    uint16
>         |  +--ro logical-network-element?   string
>         |  +--ro network-instance?          string
>         |  +--ro topology
>         |     +--ro link-ref?      leafref
>         |     +--ro network-ref?   leafref
>         +--ro information-source-entry* [information-source]
>         |  +--ro information-source                te-info-source
>         |  +--ro information-source-state
>         |  |  +--ro credibility-preference?    uint16
>         |  |  +--ro logical-network-element?   string
>         |  |  +--ro network-instance?          string
>         |  |  +--ro topology
>         |  |     +--ro link-ref?      leafref
>         |  |     +--ro network-ref?   leafref
>         |  +--ro link-index?                       uint64
>         |  +--ro administrative-group?             te-types:admin-
>   groups
>         |  +--ro interface-switching-capability* [switching-capability
>   encoding]
>         |  |  +--ro switching-capability    identityref
>         |  |  +--ro encoding                identityref
>         |  |  +--ro max-lsp-bandwidth* [priority]
>         |  |     +--ro priority     uint8
>         |  |     +--ro bandwidth
>         |  |        +--ro te-bandwidth
>         |  |           +--ro (technology)?
>=20
>=20
>         |  |              +--:(psc)
>         |  |              |  +--ro psc?       rt-types:bandwidth-ieee-
>   float32
>         |  |              +--:(otn)
>         |  |              |  +--ro otn* [rate-type]
>         |  |              |     +--ro rate-type    identityref
>         |  |              |     +--ro counter?     uint16
>         |  |              +--:(lsc)
>         |  |              |  +--ro wdm* [spectrum slot]
>         |  |              |     +--ro spectrum    identityref
>         |  |              |     +--ro slot        int16
>         |  |              |     +--ro width?      uint16
>         |  |              +--:(generic)
>         |  |                 +--ro generic?   te-bandwidth
>         |  +--ro label-restriction* [inclusive-exclusive label-start]
>         |  |  +--ro inclusive-exclusive    enumeration
>         |  |  +--ro label-start            rt-types:generalized-label
>         |  |  +--ro label-end?             rt-types:generalized-label
>         |  |  +--ro range-bitmap?          binary
>         |  +--ro link-protection-type?             enumeration
>         |  +--ro max-link-bandwidth
>         |  |  +--ro te-bandwidth
>         |  |     +--ro (technology)?
>         |  |        +--:(psc)
>         |  |        |  +--ro psc?       =
rt-types:bandwidth-ieee-float32
>         |  |        +--:(otn)
>         |  |        |  +--ro otn* [rate-type]
>         |  |        |     +--ro rate-type    identityref
>         |  |        |     +--ro counter?     uint16
>         |  |        +--:(lsc)
>         |  |        |  +--ro wdm* [spectrum slot]
>         |  |        |     +--ro spectrum    identityref
>         |  |        |     +--ro slot        int16
>         |  |        |     +--ro width?      uint16
>         |  |        +--:(generic)
>         |  |           +--ro generic?   te-bandwidth
>         |  +--ro max-resv-link-bandwidth
>         |  |  +--ro te-bandwidth
>         |  |     +--ro (technology)?
>         |  |        +--:(psc)
>         |  |        |  +--ro psc?       =
rt-types:bandwidth-ieee-float32
>         |  |        +--:(otn)
>         |  |        |  +--ro otn* [rate-type]
>         |  |        |     +--ro rate-type    identityref
>         |  |        |     +--ro counter?     uint16
>         |  |        +--:(lsc)
>         |  |        |  +--ro wdm* [spectrum slot]
>=20
>=20
>=20
>         |  |        |     +--ro spectrum    identityref
>         |  |        |     +--ro slot        int16
>         |  |        |     +--ro width?      uint16
>         |  |        +--:(generic)
>         |  |           +--ro generic?   te-bandwidth
>         |  +--ro unreserved-bandwidth* [priority]
>         |  |  +--ro priority     uint8
>         |  |  +--ro bandwidth
>         |  |     +--ro te-bandwidth
>         |  |        +--ro (technology)?
>         |  |           +--:(psc)
>         |  |           |  +--ro psc?       rt-types:bandwidth-ieee-
>   float32
>         |  |           +--:(otn)
>         |  |           |  +--ro otn* [rate-type]
>         |  |           |     +--ro rate-type    identityref
>         |  |           |     +--ro counter?     uint16
>         |  |           +--:(lsc)
>         |  |           |  +--ro wdm* [spectrum slot]
>         |  |           |     +--ro spectrum    identityref
>         |  |           |     +--ro slot        int16
>         |  |           |     +--ro width?      uint16
>         |  |           +--:(generic)
>         |  |              +--ro generic?   te-bandwidth
>         |  +--ro te-default-metric?                uint32
>         |  +--ro te-delay-metric?                  uint32
>         |  +--ro te-igp-metric?                    uint32
>         |  +--ro te-srlgs
>         |  |  +--ro value*   te-types:srlg
>         |  +--ro te-nsrlgs {nsrlg}?
>         |     +--ro id*   uint32
>         +--ro recovery
>         |  +--ro restoration-status?   te-types:te-recovery-status
>         |  +--ro protection-status?    te-types:te-recovery-status
>         +--ro underlay {te-topology-hierarchy}?
>         |  +--ro dynamic?     boolean
>         |  +--ro committed?   boolean
>         +--ro statistics
>            +--ro discontinuity-time                 yang:date-and-time
>            +--ro disables?                          yang:counter32
>            +--ro enables?                           yang:counter32
>            +--ro maintenance-clears?                yang:counter32
>            +--ro maintenance-sets?                  yang:counter32
>            +--ro modifies?                          yang:counter32
>            +--ro downs?                             yang:counter32
>            +--ro ups?                               yang:counter32
>            +--ro fault-clears?                      yang:counter32
>=20
>=20
>=20
>            +--ro fault-detects?                     yang:counter32
>            +--ro protection-switches?               yang:counter32
>            +--ro protection-reverts?                yang:counter32
>            +--ro restoration-failures?              yang:counter32
>            +--ro restoration-starts?                yang:counter32
>            +--ro restoration-successes?             yang:counter32
>            +--ro restoration-reversion-failures?    yang:counter32
>            +--ro restoration-reversion-starts?      yang:counter32
>            +--ro restoration-reversion-successes?   yang:counter32
>   augment /nw:networks/nw:network/nw:node/nt:termination-point:
>      +--rw te-tp-id?   te-types:te-tp-id
>      +--rw te!
>         +--rw admin-status?                     te-types:te-admin-
>   status
>         +--rw name?                             string
>         +--rw interface-switching-capability* [switching-capability
>   encoding]
>         |  +--rw switching-capability    identityref
>         |  +--rw encoding                identityref
>         |  +--rw max-lsp-bandwidth* [priority]
>         |     +--rw priority     uint8
>         |     +--rw bandwidth
>         |        +--rw te-bandwidth
>         |           +--rw (technology)?
>         |              +--:(psc)
>         |              |  +--rw psc?       rt-types:bandwidth-ieee-
>   float32
>         |              +--:(otn)
>         |              |  +--rw otn* [rate-type]
>         |              |     +--rw rate-type    identityref
>         |              |     +--rw counter?     uint16
>         |              +--:(lsc)
>         |              |  +--rw wdm* [spectrum slot]
>         |              |     +--rw spectrum    identityref
>         |              |     +--rw slot        int16
>         |              |     +--rw width?      uint16
>         |              +--:(generic)
>         |                 +--rw generic?   te-bandwidth
>         +--rw inter-layer-lock-id*              uint32
>         +--ro oper-status?                      =
te-types:te-oper-status
>         +--ro geolocation
>            +--ro altitude?    int64
>            +--ro latitude?    geographic-coordinate-degree
>            +--ro longitude?   geographic-coordinate-degree
>=20
>=20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> end of diagram
>=20
> ----- Original Message -----
> From: "Lou Berger" 
> To: 
> Sent: Wednesday, October 25, 2017 2:13 PM
> Subject: Re: [netmod] I-D Action:
> draft-ietf-netmod-yang-tree-diagrams-02.txt
>=20
>=20
>> Hi,
>>=20
>> This version addresses all known / open issues in the draft known to
>> the authors.
>>=20
>> The changes are as follows:
>> - Added groupings and yang-data descriptions
>> - Added Comments, Long Diagrams and Security Considerations sections
>> - Clarified representation of schema mount points and representation
> of
>> modules exposed using schema mount.
>> - Miscellaneous editorial changes
>>=20
>> Lou (for draft authors)
>>=20
>> On 10/25/2017 8:49 AM, 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.
>>>=20
>>>        Title           : YANG Tree Diagrams
>>>        Authors         : Martin Bjorklund
>>>                          Lou Berger
>>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
>>> Pages           : 11
>>> Date            : 2017-10-25
>>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com





From nobody Thu Oct 26 10:45:08 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AB4138BE7 for ; Thu, 26 Oct 2017 10:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, 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 7RCL-CIbaldP for ; Thu, 26 Oct 2017 10:45:04 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677B413F3C7 for ; Thu, 26 Oct 2017 10:45:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7732; q=dns/txt; s=iport; t=1509039903; x=1510249503; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=LpG0AggKqGWVXu4HCNjNa82XcUG1zRjbvdj3atUqaIA=; b=JZKWh3wO3emMwuVtKpUrGDXuFbwpBd7zBvs8UH5lPaqw7hS+bqx7SEGF 4b4e4fZx4UI1O/ncpbG8AftVweMgSWaVvOMKZSh7LoSqTSQTrRmz+SFYO H6xPOVICBZM6Aq2V+zK4TbILKZxKLSlQCvkzQtX42JAUicwgGO/GSts5n 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQC6HvJZ/xbLJq1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRDboQhixOQF5B8h1UKH4M+gV4ChQMVAQIBAQEBAQEBayiFHgE?= =?us-ascii?q?FI1YOAgkSCCoCAhs8BgEMCAEBihyLap1ngicmik8BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdBYMpg1eBaSmHcDcmgk2CYQWhe4FukwuLcoc5jiKHaIE5NSKBaDQhCB0?= =?us-ascii?q?Vgy4Igho5HIFoQIx8AQEB?=
X-IronPort-AV: E=Sophos;i="5.44,301,1505779200";  d="scan'208,217";a="656600367"
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 Oct 2017 17:44:53 +0000
Received: from [10.61.199.20] ([10.61.199.20]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9QHirVA021489; Thu, 26 Oct 2017 17:44:53 GMT
To: Andy Bierman , "netmod@ietf.org" 
References: <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local>  <20171025110851.wdoj2dbrqmxz5shd@elstar.local> 
From: Robert Wilton 
Message-ID: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>
Date: Thu, 26 Oct 2017 18:44:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------36B587DBD20BEC11677F3BFA"
Content-Language: en-US
Archived-At: 
Subject: [netmod] Action and RPC statements [was Re: augment YANG 1.0 with YANG 1.1 OK?]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 17:45:06 -0000

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

Hi ,

Separating out the issue regarding which datastore action and RPC apply 
to, we propose the following NEW text to the datastores draft:

6.2 Invocation of Actions and RPC Operations

   This section updates section 7.15. of RFC 7950.

   In YANG data models, the "action" statement may appear under "config
   true" and "config false" schema nodes.  While instances of both
   schema nodes may appear in , instances of "config true"
   schema nodes may also appear in other datastores.

   An NMDA compliant server MUST execute all actions in the context of
   .  Likewise, an NMDA compliant server MUST invoke all RPC
   operations in the context of , unless the RPC is explicitly
   defined as affecting other datastores (e.g., ).

OK?

Thanks,
Rob


On 25/10/2017 16:54, Andy Bierman wrote:
>
>     > >
>     > > > (2) Define :
>     > > > >
>     > > > > I'm not convinced that this is really required/helpful,
>     given that most
>     > > > > actions are likely to only apply to operational.  If it
>     turns out that
>     > > this
>     > > > > is particularly useful then I would propose that this is
>     deferred
>     > > until a
>     > > > > future revision of NETCONF, particularly because we are
>     trying to keep
>     > > the
>     > > > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
>     > > > >
>     > > > > Is this OK?
>     > > > >
>     > > >
>     > > > The NMDA theme has been to declare things that are possible
>     in pre-NMDA
>     > > > but not supported in post-NMDA to be not useful, so this can
>     be left to
>     > > > vendors I guess.
>     > >
>     > > Not sure I understand this either.
>     > >
>     > > If you have a concrete change proposal, perhaps the discussion
>     becomes
>     > > more concrete and productive.
>     > >
>     >
>     >
>     > I already said to declare that  is invoked in
>     . Period.
>     > No description-stmt exceptions.
>     >
>     > If another datastore is needed, use rpc-stmt instead of action-stmt.
>
>     So you are fine if for RPCs description statements can define which
>     datastores are affected by an RPC? I probably did not get that you
>     make a distinction between actions and RPCs here.
>
>     /js
>
>     --
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103              >
>
>


--------------36B587DBD20BEC11677F3BFA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi ,

    

    
Separating out the issue regarding which datastore action and RPC
      apply to, we propose the following NEW text to the datastores
      draft:

    
6.2 Invocation of Actions and RPC Operations

  This section updates section 7.15. of RFC 7950.

  In YANG data models, the "action" statement may appear under "config
  true" and "config false" schema nodes.  While instances of both
  schema nodes may appear in <operational>, instances of "config true"
  schema nodes may also appear in other datastores.

  An NMDA compliant server MUST execute all actions in the context of
  <operational>.  Likewise, an NMDA compliant server MUST invoke all RPC
  operations in the context of <operational>, unless the RPC is explicitly
  defined as affecting other datastores (e.g., <edit-config>).

    OK?

    

    Thanks,

    Rob

    

    

    
On 25/10/2017 16:54, Andy Bierman
      wrote:

    

    

      
      


        

          

            

              > >

              > > > (2) Define <action2>:

              > > > >

              > > > > I'm not convinced that this is really
              required/helpful, given that most

              > > > > actions are likely to only apply to
              operational.  If it turns out that

              > > this

              > > > > is particularly useful then I would
              propose that this is deferred

              > > until a

              > > > > future revision of NETCONF,
              particularly because we are trying to keep

              > > the

              > > > > NETCONF NMDA and RESTCONF NMDA drafts
              as small as possible.

              > > > >

              > > > > Is this OK?

              > > > >

              > > >

              > > > The NMDA theme has been to declare things
              that are possible in pre-NMDA

              > > > but not supported in post-NMDA to be not
              useful, so this can be left to

              > > > vendors I guess.

              > >

              > > Not sure I understand this either.

              > >

              > > If you have a concrete change proposal, perhaps
              the discussion becomes

              > > more concrete and productive.

              > >

              >

              >

              > I already said to declare that <action> is
              invoked in <operational>. Period.

              > No description-stmt exceptions.

              >

              > If another datastore is needed, use rpc-stmt instead
              of action-stmt.

              

              So you are fine if for RPCs description statements can
              define which

              datastores are affected by an RPC? I probably did not get
              that you

              make a distinction between actions and RPCs here.

              

                  /js

                  

                  --

                  Juergen Schoenwaelder           Jacobs University
                  Bremen gGmbH

                  Phone: +49 421 200 3587         Campus Ring 1 | 28759
                  Bremen | Germany

                  Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

                

          

          

        

      

    

    

  


--------------36B587DBD20BEC11677F3BFA--


From nobody Thu Oct 26 10:53:13 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DF213F5D1 for ; Thu, 26 Oct 2017 10:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 OAn9DeCTItJt for ; Thu, 26 Oct 2017 10:53:10 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025EA13F5D0 for ; Thu, 26 Oct 2017 10:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4190; q=dns/txt; s=iport; t=1509040390; x=1510249990; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=K0IlOi6InvuFlnnYZ5Y7Wbbd9xEksxPqfsUJvDqnd8Y=; b=VBTntQSdT49zGNRCvS9xBO87ooxwqYWbEVwYarsE0ueCkVkDS3VqH9oS 8IO0DsK98pTIYF7VIEKpbQU5iXp++Z+HAMQdQAZHCOeRc8epFmNCQQTM9 Q5V9jiL699LW5hMR1dvjl+LwUE35kQb51335lwxRFqUqV8GeiIkG7fJdr s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADpH/JZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTEng3qKH3SQF5ZAghEKhTsChQAYAQIBAQEBAQEBayiFHgEFIw8?= =?us-ascii?q?BBVELDgoCAiYCAlcGAQwGAgEBF4oFqVGCJ4p1AQEBAQEBAQMBAQEBAQEigQ+CH?= =?us-ascii?q?4NXgWkpgwGEb4MqgmEFoXuUeYtyhzmOIodogTkfOEKBJjQhCB0Vgy2CXByBaEA?= =?us-ascii?q?2jEYBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,301,1505779200"; d="scan'208";a="655696335"
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; 26 Oct 2017 17:53:07 +0000
Received: from [10.61.199.20] ([10.61.199.20]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9QHr7CZ013799; Thu, 26 Oct 2017 17:53:07 GMT
To: Martin Bjorklund , andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, netmod@ietf.org
References:  <20171025.214929.480782767501855061.mbj@tail-f.com>  <20171026.121026.1881945352164553624.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Thu, 26 Oct 2017 18:53:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171026.121026.1881945352164553624.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] augment YANG 1.0 with YANG 1.1 OK?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 17:53:12 -0000

Hi,

A refined version of the proposed text is below (because "schema" isn't 
defined):


On 26/10/2017 11:10, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund  wrote:
>>
>>> Andy Bierman  wrote:
>>>> I think NMDA is creating much more complexity and disruption than is
>>>> required.
>>>> The original issue was the OpenConfig-style config/state trees.
>>>> The WG agreed that an RPC-based solution was needed so that the
>>>> YANG modules would not need to change (far too disruptive!).
>>>>
>>>> Then the IETF proceeds to redo all the YANG modules anyway.
>>>> Now the server is allowed to implement the same module differently in
>>> each
>>>> datastore.
>>>> Now comparing the configured and operational value is even harder than
>>>> before.
>>>>
>>>> None of this added complexity was in the OpenConfig proposal.
>>>> It was not even possible to have different features and deviations for
>>> the
>>>> same object in that proposal.
>>> Actually, this is not correct.  In both OC and the old IETF split tree
>>> solutions, the configuration and operational state were modelled with
>>> duplicate nodes, and you could certainly deviate these nodes
>>> differently.
>>>
>>> This said, I share your concern about complexity.  I also agree that
>>> the only model that makes the client simple is that if all objects in
>>> the config are also available with the same types in operational
>>> state.  Otherwise comparison won't work (or be complicated).
>>>
>>> But at the same time, the converse is not true.  I.e., if an object is
>>> present in operational, it doesn't have to be configurable.
>>>
>>> So what I think we want is that the schema for the conventional
>>> datastore is a subset of the schema for operational.
>>>
>>> This would allow an implementation that cannot support configuration
>>> of let's say the MTU, to deviate the mtu with "not-supported" in the
>>> conventional datastore, but it will still be available for inspection
>>> in operational.
>>>
>>> Does this make sense?
>>>
>> OK -- deviations for not-supported make sense per datastore
>> to resolve the missing-object ambiguity problem.
>> It is not realistic to expect every object in a module to be able
>> to report its operational state in the same release.
>> It is better to report not-supported than return nothing or return the
>> configured value as a guess.
>>
>> If the admin-state and oper-state objects are different, 2 objects should
>> be used instead of per-datastore deviations of the syntax of 1 object.
> Agreed.
>
> So based on this, how about this text:
>
>    The schema for  MUST be a superset of the combined
>    schema used in all configuration datastores except that YANG nodes
>    supported in a configuration datastore MAY be omitted from
>     if a server is not able to accurately report them.
Given that "schema" isn't defined, we propose using "datastore schema" 
instead:

NEW:

schema node - A node in the schema tree.  The formal definition is in 
RFC 7950.

datastore schema - is the combined set of schema nodes for all modules
supported by a particular datastore, taking into consideration any
deviations and enabled features for that datastore.


The below text is changed from "schema" to "datastore schema":

5.1.  Conventional Configuration Datastores

    The conventional configuration datastores are a set of configuration
    datastores that share exactly the same datastore schema, allowing
    data to be copied between them.  The term is meant as a generic
   umbrella description of these datastores.  The set of datastores 
include:


The proposed new text for operational would change to:

The datastore schema for  MUST be a superset of the combined
datastore schema used in all configuration datastores except that YANG
nodes supported in a configuration datastore MAY be omitted
from  if a server is not able to accurately report them.

Thanks,
Rob


>
>
> /martin
> .
>


From nobody Thu Oct 26 10:55:05 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61E913F5D2 for ; Thu, 26 Oct 2017 10:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, 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 lyoaRDovHYor for ; Thu, 26 Oct 2017 10:55:01 -0700 (PDT)
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 42A9F13F5D0 for ; Thu, 26 Oct 2017 10:55:01 -0700 (PDT)
Received: from birdie5 (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 4E419626EB for ; Thu, 26 Oct 2017 19:54:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1509040499; bh=Lxa+TzmrwMXcWkk92tfEVRDaQBZzFqPcG5xAKx6He2Q=; h=From:To:Date; b=IKBHh5pyvYL2c4WDrxjgeX7/u1GmaFpJ8Af78Ddi/PMt1dsKZ0aVrbe1su5/813H9 pDsdOr26+O0IkbgZhPWxE2q2UfswQZpH8VGP/W5EEf0BilS8tm//xp/IQik38OsYch wQJ0kK7j9XAQprb9TsnrQzLUjolNVfbb578pV1j0=
Message-ID: <1509040558.4084.3.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Thu, 26 Oct 2017 19:55:58 +0200
In-Reply-To: 
References: <67172aec-686f-90ba-0fc8-1ce2bc3dcdb4@cisco.com>  <6d43c6fb-ae11-df39-0dd4-766f7b25ac82@transpacket.com> <20171023.133559.470792369996870413.mbj@tail-f.com>    
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.1 
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] [Technical Errata Reported] RFC7950 (5157)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 17:55:03 -0000

On Thu, 2017-10-26 at 09:02 -0700, Andy Bierman wrote:
> 
> 
> On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev  wrote:
> > On 10/24/2017 03:42 AM, Andy Bierman wrote:
> > 
> > > ....
> > > 
> > > Although the instance-identifier is problematic, it is rarely used at all,
> > > let alone using it as a list key.
> > > 
> >  It is used as a key in ietf-alarms /alarms/alarm-list/alarm.
> > > ...
> 
> I guess if you wanted to create the most complex module possible,
> using an XPath instance-identifier as a list key is a good start.
> 
> It's too bad we can't use the RESTCONF path URI string as an i-i:

Why not? Just use JSON. XML is bound to be abadoned, sooner or later.

Lada

> 
>   - the only representation is also the canonical representation
>   - the list keys are much less verbose (required to be in schema order)
>   - percent-encoded chars are allowed, which are simpler than character entities
>     and much simpler than the concat() function
>   - no use of prefix mappings at all so i-i strings are complete and permanent
> 
> 
> Andy
> 
> 
>  
> 
> _______________________________________________
> 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 Thu Oct 26 11:04:01 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E87E13F5D4 for ; Thu, 26 Oct 2017 11:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7mLAkYXuJTo for ; Thu, 26 Oct 2017 11:03:55 -0700 (PDT)
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 8053113F441 for ; Thu, 26 Oct 2017 11:03:55 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id D0FDC216126 for ; Thu, 26 Oct 2017 11:32:50 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id SHYm1w01b2SSUrH01HYp34; Thu, 26 Oct 2017 11:32:50 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=DsNEj0OqSk4F1GMhC-0A:9 a=2zuwW42HAEvmORGn:21 a=cZwc4jFpki8unXc9:21 a=WnLS2z3rvpuhsL0o:21 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: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=mhAHdrIhL+JFYo/0VfKqwaxJKTqLVvHoZrT6dN4u3dE=; b=wAxwQ7A4rmlfknkMmSxcFA9FS+ BRekMFfjGPih2bmH2GevUBrapWSuE4VEytL6cTH61mPgUouFQ+zbXAc00n+Y2bdOJqGCA6RcKjg3h XlOKcfjxaYYlu5EyDQVdPvcB4;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:54550 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e7m1O-000vFR-Du; Thu, 26 Oct 2017 11:32:46 -0600
To: "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>
From: Lou Berger 
Message-ID: 
Date: Thu, 26 Oct 2017 13:32:45 -0400
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: <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1e7m1O-000vFR-Du
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:54550
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 18:03:59 -0000

Hi Tom,


On 10/26/2017 12:50 PM, t.petch wrote:
> Lou
> 
> I like the advice that diagrams should be one page long but wonder how
> to apply that to those I see in routing WGs.  I have just been looking
> at
> 
>  draft-ietf-teas-yang-te-topo-12
> 
> where the diagram is 36 pages long - which may be one of the larger ones
> but by no means exceptional - and I think the diagram is  more or less
> useless as a result. 

I agree.

> But what practical advice can we give them?

we added section 3.2 covering Long Diagrams in general, and due to this
draft we added:

   When long diagrams are included in a document, authors
   should consider whether to include the long diagram in the main body
   of the document or in an appendix.

This is also the recommendation I made to the authors as that draft's
Shepherd...

If you have any suggestion on improving the language that would be most
appreciated.

Lou

> 
> I append the diagram below
> 
> Tom Petch
> 
> 
> start of diagram
> ==================================================
> 
> 
> Liu, et al             Expires January 17, 2018               [Page 31]
> 
> 
> 6. Tree Structure
> 
>    module: ietf-te-topology
>    augment /nw:networks/nw:network/nw:network-types:
>       +--rw te-topology!
>    augment /nw:networks:
>       +--rw te!
>          +--rw templates
>             +--rw node-template* [name] {template}?
>             |  +--rw name                       te-types:te-template-
>    name
>             |  +--rw priority?                  uint16
>             |  +--rw reference-change-policy?   enumeration
>             |  +--rw te-node-attributes
>             |     +--rw admin-status?        te-types:te-admin-status
>             |     +--rw domain-id?           uint32
>             |     +--rw is-abstract?         empty
>             |     +--rw name?                inet:domain-name
>             |     +--rw signaling-address*   inet:ip-address
>             |     +--rw underlay-topology {te-topology-hierarchy}?
>             |        +--rw network-ref?   leafref
>             +--rw link-template* [name] {template}?
>                +--rw name                       te-types:te-template-
>    name
>                +--rw priority?                  uint16
>                +--rw reference-change-policy?   enumeration
>                +--rw te-link-attributes
>                   +--rw access-type?                      te-types:te-
>    link-access-type
>                   +--rw external-domain
>                   |  +--rw network-ref?            leafref
>                   |  +--rw remote-te-node-id?      te-types:te-node-id
>                   |  +--rw remote-te-link-tp-id?   te-types:te-tp-id
>                   |  +--rw plug-id?                uint32
>                   +--rw is-abstract?                      empty
>                   +--rw name?                             string
>                   +--rw underlay {te-topology-hierarchy}?
>                   |  +--rw enabled?                     boolean
>                   |  +--rw primary-path
>                   |  |  +--rw network-ref?    leafref
>                   |  |  +--rw path-element* [path-element-id]
>                   |  |     +--rw path-element-id    uint32
>                   |  |     +--rw index?             uint32
> 
> 
> 
>                   |  |     +--rw (type)?
>                   |  |        +--:(numbered)
>                   |  |        |  +--rw numbered-hop
>                   |  |        |     +--rw address?    te-types:te-tp-id
>                   |  |        |     +--rw hop-type?   te-hop-type
>                   |  |        +--:(as-number)
>                   |  |        |  +--rw as-number-hop
>                   |  |        |     +--rw as-number?   binary
>                   |  |        |     +--rw hop-type?    te-hop-type
>                   |  |        +--:(unnumbered)
>                   |  |        |  +--rw unnumbered-hop
>                   |  |        |     +--rw node-id?      te-types:te-
>    node-id
>                   |  |        |     +--rw link-tp-id?   te-types:te-tp-
>    id
>                   |  |        |     +--rw hop-type?     te-hop-type
>                   |  |        +--:(label)
>                   |  |        |  +--rw label-hop
>                   |  |        |     +--rw value?   rt-types:generalized-
>    label
>                   |  |        +--:(sid)
>                   |  |           +--rw sid-hop
>                   |  |              +--rw sid?   rt-types:generalized-
>    label
>                   |  +--rw backup-path* [index]
>                   |  |  +--rw index           uint32
>                   |  |  +--rw network-ref?    leafref
>                   |  |  +--rw path-element* [path-element-id]
>                   |  |     +--rw path-element-id    uint32
>                   |  |     +--rw index?             uint32
>                   |  |     +--rw (type)?
>                   |  |        +--:(numbered)
>                   |  |        |  +--rw numbered-hop
>                   |  |        |     +--rw address?    te-types:te-tp-id
>                   |  |        |     +--rw hop-type?   te-hop-type
>                   |  |        +--:(as-number)
>                   |  |        |  +--rw as-number-hop
>                   |  |        |     +--rw as-number?   binary
>                   |  |        |     +--rw hop-type?    te-hop-type
>                   |  |        +--:(unnumbered)
>                   |  |        |  +--rw unnumbered-hop
>                   |  |        |     +--rw node-id?      te-types:te-
>    node-id
>                   |  |        |     +--rw link-tp-id?   te-types:te-tp-
>    id
>                   |  |        |     +--rw hop-type?     te-hop-type
>                   |  |        +--:(label)
> 
> 
>                   |  |        |  +--rw label-hop
>                   |  |        |     +--rw value?   rt-types:generalized-
>    label
>                   |  |        +--:(sid)
>                   |  |           +--rw sid-hop
>                   |  |              +--rw sid?   rt-types:generalized-
>    label
>                   |  +--rw protection-type?             identityref
>                   |  +--rw tunnel-termination-points
>                   |  |  +--rw source?        binary
>                   |  |  +--rw destination?   binary
>                   |  +--rw tunnels
>                   |     +--rw sharing?   boolean
>                   |     +--rw tunnel* [tunnel-name]
>                   |        +--rw tunnel-name    string
>                   |        +--rw sharing?       boolean
>                   +--rw admin-status?                     te-types:te-
>    admin-status
>                   +--rw link-index?                       uint64
>                   +--rw administrative-group?             te-
>    types:admin-groups
>                   +--rw interface-switching-capability* [switching-
>    capability encoding]
>                   |  +--rw switching-capability    identityref
>                   |  +--rw encoding                identityref
>                   |  +--rw max-lsp-bandwidth* [priority]
>                   |     +--rw priority     uint8
>                   |     +--rw bandwidth
>                   |        +--rw te-bandwidth
>                   |           +--rw (technology)?
>                   |              +--:(psc)
>                   |              |  +--rw psc?       rt-types:bandwidth-
>    ieee-float32
>                   |              +--:(otn)
>                   |              |  +--rw otn* [rate-type]
>                   |              |     +--rw rate-type    identityref
>                   |              |     +--rw counter?     uint16
>                   |              +--:(lsc)
>                   |              |  +--rw wdm* [spectrum slot]
>                   |              |     +--rw spectrum    identityref
>                   |              |     +--rw slot        int16
>                   |              |     +--rw width?      uint16
>                   |              +--:(generic)
>                   |                 +--rw generic?   te-bandwidth
>                   +--rw label-restriction* [inclusive-exclusive label-
>    start]
>                   |  +--rw inclusive-exclusive    enumeration
> 
> 
> 
>                   |  +--rw label-start            rt-types:generalized-
>    label
>                   |  +--rw label-end?             rt-types:generalized-
>    label
>                   |  +--rw range-bitmap?          binary
>                   +--rw link-protection-type?             enumeration
>                   +--rw max-link-bandwidth
>                   |  +--rw te-bandwidth
>                   |     +--rw (technology)?
>                   |        +--:(psc)
>                   |        |  +--rw psc?       rt-types:bandwidth-ieee-
>    float32
>                   |        +--:(otn)
>                   |        |  +--rw otn* [rate-type]
>                   |        |     +--rw rate-type    identityref
>                   |        |     +--rw counter?     uint16
>                   |        +--:(lsc)
>                   |        |  +--rw wdm* [spectrum slot]
>                   |        |     +--rw spectrum    identityref
>                   |        |     +--rw slot        int16
>                   |        |     +--rw width?      uint16
>                   |        +--:(generic)
>                   |           +--rw generic?   te-bandwidth
>                   +--rw max-resv-link-bandwidth
>                   |  +--rw te-bandwidth
>                   |     +--rw (technology)?
>                   |        +--:(psc)
>                   |        |  +--rw psc?       rt-types:bandwidth-ieee-
>    float32
>                   |        +--:(otn)
>                   |        |  +--rw otn* [rate-type]
>                   |        |     +--rw rate-type    identityref
>                   |        |     +--rw counter?     uint16
>                   |        +--:(lsc)
>                   |        |  +--rw wdm* [spectrum slot]
>                   |        |     +--rw spectrum    identityref
>                   |        |     +--rw slot        int16
>                   |        |     +--rw width?      uint16
>                   |        +--:(generic)
>                   |           +--rw generic?   te-bandwidth
>                   +--rw unreserved-bandwidth* [priority]
>                   |  +--rw priority     uint8
>                   |  +--rw bandwidth
>                   |     +--rw te-bandwidth
>                   |        +--rw (technology)?
>                   |           +--:(psc)
> 
> 
> 
>                   |           |  +--rw psc?       rt-types:bandwidth-
>    ieee-float32
>                   |           +--:(otn)
>                   |           |  +--rw otn* [rate-type]
>                   |           |     +--rw rate-type    identityref
>                   |           |     +--rw counter?     uint16
>                   |           +--:(lsc)
>                   |           |  +--rw wdm* [spectrum slot]
>                   |           |     +--rw spectrum    identityref
>                   |           |     +--rw slot        int16
>                   |           |     +--rw width?      uint16
>                   |           +--:(generic)
>                   |              +--rw generic?   te-bandwidth
>                   +--rw te-default-metric?                uint32
>                   +--rw te-delay-metric?                  uint32
>                   +--rw te-igp-metric?                    uint32
>                   +--rw te-srlgs
>                   |  +--rw value*   te-types:srlg
>                   +--rw te-nsrlgs {nsrlg}?
>                      +--rw id*   uint32
>    augment /nw:networks/nw:network:
>       +--rw provider-id?      te-types:te-global-id
>       +--rw client-id?        te-types:te-global-id
>       +--rw te-topology-id?   te-types:te-topology-id
>       +--rw te!
>          +--rw preference?               uint8
>          +--rw optimization-criterion?   identityref
>          +--rw nsrlg* [id] {nsrlg}?
>          |  +--rw id              uint32
>          |  +--rw disjointness?   te-types:te-path-disjointness
>          +--ro geolocation
>             +--ro altitude?    int64
>             +--ro latitude?    geographic-coordinate-degree
>             +--ro longitude?   geographic-coordinate-degree
>    augment /nw:networks/nw:network/nw:node:
>       +--rw te-node-id?   te-types:te-node-id
>       +--rw te!
>          +--rw te-node-template*           leafref {template}?
>          +--rw te-node-attributes
>          |  +--rw admin-status?            te-types:te-admin-status
>          |  +--rw connectivity-matrices
>          |  |  +--rw number-of-entries?          uint16
>          |  |  +--rw label-restriction* [inclusive-exclusive label-
>    start]
>          |  |  |  +--rw inclusive-exclusive    enumeration
>          |  |  |  +--rw label-start            rt-types:generalized-
>    label
> 
> 
> 
>          |  |  |  +--rw label-end?             rt-types:generalized-
>    label
>          |  |  |  +--rw range-bitmap?          binary
>          |  |  +--rw is-allowed?                 boolean
>          |  |  +--rw underlay {te-topology-hierarchy}?
>          |  |  |  +--rw enabled?                     boolean
>          |  |  |  +--rw primary-path
>          |  |  |  |  +--rw network-ref?    leafref
>          |  |  |  |  +--rw path-element* [path-element-id]
>          |  |  |  |     +--rw path-element-id    uint32
>          |  |  |  |     +--rw index?             uint32
>          |  |  |  |     +--rw (type)?
>          |  |  |  |        +--:(numbered)
>          |  |  |  |        |  +--rw numbered-hop
>          |  |  |  |        |     +--rw address?    te-types:te-tp-id
>          |  |  |  |        |     +--rw hop-type?   te-hop-type
>          |  |  |  |        +--:(as-number)
>          |  |  |  |        |  +--rw as-number-hop
>          |  |  |  |        |     +--rw as-number?   binary
>          |  |  |  |        |     +--rw hop-type?    te-hop-type
>          |  |  |  |        +--:(unnumbered)
>          |  |  |  |        |  +--rw unnumbered-hop
>          |  |  |  |        |     +--rw node-id?      te-types:te-node-id
>          |  |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>          |  |  |  |        |     +--rw hop-type?     te-hop-type
>          |  |  |  |        +--:(label)
>          |  |  |  |        |  +--rw label-hop
>          |  |  |  |        |     +--rw value?   rt-types:generalized-
>    label
>          |  |  |  |        +--:(sid)
>          |  |  |  |           +--rw sid-hop
>          |  |  |  |              +--rw sid?   rt-types:generalized-label
>          |  |  |  +--rw backup-path* [index]
>          |  |  |  |  +--rw index           uint32
>          |  |  |  |  +--rw network-ref?    leafref
>          |  |  |  |  +--rw path-element* [path-element-id]
>          |  |  |  |     +--rw path-element-id    uint32
>          |  |  |  |     +--rw index?             uint32
>          |  |  |  |     +--rw (type)?
>          |  |  |  |        +--:(numbered)
>          |  |  |  |        |  +--rw numbered-hop
>          |  |  |  |        |     +--rw address?    te-types:te-tp-id
>          |  |  |  |        |     +--rw hop-type?   te-hop-type
>          |  |  |  |        +--:(as-number)
>          |  |  |  |        |  +--rw as-number-hop
>          |  |  |  |        |     +--rw as-number?   binary
>          |  |  |  |        |     +--rw hop-type?    te-hop-type
> 
> 
>          |  |  |  |        +--:(unnumbered)
>          |  |  |  |        |  +--rw unnumbered-hop
>          |  |  |  |        |     +--rw node-id?      te-types:te-node-id
>          |  |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>          |  |  |  |        |     +--rw hop-type?     te-hop-type
>          |  |  |  |        +--:(label)
>          |  |  |  |        |  +--rw label-hop
>          |  |  |  |        |     +--rw value?   rt-types:generalized-
>    label
>          |  |  |  |        +--:(sid)
>          |  |  |  |           +--rw sid-hop
>          |  |  |  |              +--rw sid?   rt-types:generalized-label
>          |  |  |  +--rw protection-type?             identityref
>          |  |  |  +--rw tunnel-termination-points
>          |  |  |  |  +--rw source?        binary
>          |  |  |  |  +--rw destination?   binary
>          |  |  |  +--rw tunnels
>          |  |  |     +--rw sharing?   boolean
>          |  |  |     +--rw tunnel* [tunnel-name]
>          |  |  |        +--rw tunnel-name    string
>          |  |  |        +--rw sharing?       boolean
>          |  |  +--rw path-constraints
>          |  |  |  +--rw path-metric-bound* [metric-type]
>          |  |  |  |  +--rw metric-type    identityref
>          |  |  |  |  +--rw upper-bound?   uint64
>          |  |  |  +--rw topology-id?         te-types:te-topology-id
>          |  |  |  +--rw ignore-overload?     boolean
>          |  |  |  +--rw bandwidth-generic
>          |  |  |  |  +--rw te-bandwidth
>          |  |  |  |     +--rw (technology)?
>          |  |  |  |        +--:(psc)
>          |  |  |  |        |  +--rw psc?       rt-types:bandwidth-ieee-
>    float32
>          |  |  |  |        +--:(otn)
>          |  |  |  |        |  +--rw otn* [rate-type]
>          |  |  |  |        |     +--rw rate-type    identityref
>          |  |  |  |        |     +--rw counter?     uint16
>          |  |  |  |        +--:(lsc)
>          |  |  |  |        |  +--rw wdm* [spectrum slot]
>          |  |  |  |        |     +--rw spectrum    identityref
>          |  |  |  |        |     +--rw slot        int16
>          |  |  |  |        |     +--rw width?      uint16
>          |  |  |  |        +--:(generic)
>          |  |  |  |           +--rw generic?   te-bandwidth
>          |  |  |  +--rw disjointness?        te-types:te-path-
>    disjointness
>          |  |  |  +--rw setup-priority?      uint8
> 
> 
>          |  |  |  +--rw hold-priority?       uint8
>          |  |  |  +--rw signaling-type?      identityref
>          |  |  |  +--rw path-affinities
>          |  |  |  |  +--rw constraint* [usage]
>          |  |  |  |     +--rw usage    identityref
>          |  |  |  |     +--rw value?   admin-groups
>          |  |  |  +--rw path-srlgs
>          |  |  |     +--rw usage?    identityref
>          |  |  |     +--rw values*   srlg
>          |  |  +--rw optimizations
>          |  |  |  +--rw (algorithm)?
>          |  |  |     +--:(metric) {path-optimization-metric}?
>          |  |  |     |  +--rw optimization-metric* [metric-type]
>          |  |  |     |  |  +--rw metric-type    identityref
>          |  |  |     |  |  +--rw weight?        uint8
>          |  |  |     |  +--rw tiebreakers
>          |  |  |     |     +--rw tiebreaker* [tiebreaker-type]
>          |  |  |     |        +--rw tiebreaker-type    identityref
>          |  |  |     +--:(objective-function) {path-optimization-
>    objective-function}?
>          |  |  |        +--rw objective-function
>          |  |  |           +--rw objective-function-type?   identityref
>          |  |  +--ro computed-path-properties
>          |  |  |  +--ro path-metric* [metric-type]
>          |  |  |  |  +--ro metric-type           identityref
>          |  |  |  |  +--ro accumulative-value?   uint64
>          |  |  |  +--ro path-affinities
>          |  |  |  |  +--ro constraint* [usage]
>          |  |  |  |     +--ro usage    identityref
>          |  |  |  |     +--ro value?   admin-groups
>          |  |  |  +--ro path-srlgs
>          |  |  |  |  +--ro usage?    identityref
>          |  |  |  |  +--ro values*   srlg
>          |  |  |  +--ro path-computed-route-objects
>          |  |  |     +--ro path-computed-route-object* [index]
>          |  |  |        +--ro index             uint32
>          |  |  |        +--ro (type)?
>          |  |  |           +--:(numbered)
>          |  |  |           |  +--ro numbered-hop
>          |  |  |           |     +--ro address?    te-types:te-tp-id
>          |  |  |           |     +--ro hop-type?   te-hop-type
>          |  |  |           +--:(as-number)
>          |  |  |           |  +--ro as-number-hop
>          |  |  |           |     +--ro as-number?   binary
>          |  |  |           |     +--ro hop-type?    te-hop-type
>          |  |  |           +--:(unnumbered)
>          |  |  |           |  +--ro unnumbered-hop
> 
> 
> 
> 
>          |  |  |           |     +--ro node-id?      te-types:te-node-id
>          |  |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>          |  |  |           |     +--ro hop-type?     te-hop-type
>          |  |  |           +--:(label)
>          |  |  |           |  +--ro label-hop
>          |  |  |           |     +--ro value?   rt-types:generalized-
>    label
>          |  |  |           +--:(sid)
>          |  |  |              +--ro sid-hop
>          |  |  |                 +--ro sid?   rt-types:generalized-label
>          |  |  +--rw connectivity-matrix* [id]
>          |  |     +--rw id                          uint32
>          |  |     +--rw from
>          |  |     |  +--rw tp-ref?              leafref
>          |  |     |  +--rw label-restriction* [inclusive-exclusive
>    label-start]
>          |  |     |     +--rw inclusive-exclusive    enumeration
>          |  |     |     +--rw label-start            rt-
>    types:generalized-label
>          |  |     |     +--rw label-end?             rt-
>    types:generalized-label
>          |  |     |     +--rw range-bitmap?          binary
>          |  |     +--rw to
>          |  |     |  +--rw tp-ref?              leafref
>          |  |     |  +--rw label-restriction* [inclusive-exclusive
>    label-start]
>          |  |     |     +--rw inclusive-exclusive    enumeration
>          |  |     |     +--rw label-start            rt-
>    types:generalized-label
>          |  |     |     +--rw label-end?             rt-
>    types:generalized-label
>          |  |     |     +--rw range-bitmap?          binary
>          |  |     +--rw is-allowed?                 boolean
>          |  |     +--rw underlay {te-topology-hierarchy}?
>          |  |     |  +--rw enabled?                     boolean
>          |  |     |  +--rw primary-path
>          |  |     |  |  +--rw network-ref?    leafref
>          |  |     |  |  +--rw path-element* [path-element-id]
>          |  |     |  |     +--rw path-element-id    uint32
>          |  |     |  |     +--rw index?             uint32
>          |  |     |  |     +--rw (type)?
>          |  |     |  |        +--:(numbered)
>          |  |     |  |        |  +--rw numbered-hop
>          |  |     |  |        |     +--rw address?    te-types:te-tp-id
>          |  |     |  |        |     +--rw hop-type?   te-hop-type
>          |  |     |  |        +--:(as-number)
>          |  |     |  |        |  +--rw as-number-hop
> 
> 
> 
> 
>          |  |     |  |        |     +--rw as-number?   binary
>          |  |     |  |        |     +--rw hop-type?    te-hop-type
>          |  |     |  |        +--:(unnumbered)
>          |  |     |  |        |  +--rw unnumbered-hop
>          |  |     |  |        |     +--rw node-id?      te-types:te-
>    node-id
>          |  |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>    id
>          |  |     |  |        |     +--rw hop-type?     te-hop-type
>          |  |     |  |        +--:(label)
>          |  |     |  |        |  +--rw label-hop
>          |  |     |  |        |     +--rw value?   rt-types:generalized-
>    label
>          |  |     |  |        +--:(sid)
>          |  |     |  |           +--rw sid-hop
>          |  |     |  |              +--rw sid?   rt-types:generalized-
>    label
>          |  |     |  +--rw backup-path* [index]
>          |  |     |  |  +--rw index           uint32
>          |  |     |  |  +--rw network-ref?    leafref
>          |  |     |  |  +--rw path-element* [path-element-id]
>          |  |     |  |     +--rw path-element-id    uint32
>          |  |     |  |     +--rw index?             uint32
>          |  |     |  |     +--rw (type)?
>          |  |     |  |        +--:(numbered)
>          |  |     |  |        |  +--rw numbered-hop
>          |  |     |  |        |     +--rw address?    te-types:te-tp-id
>          |  |     |  |        |     +--rw hop-type?   te-hop-type
>          |  |     |  |        +--:(as-number)
>          |  |     |  |        |  +--rw as-number-hop
>          |  |     |  |        |     +--rw as-number?   binary
>          |  |     |  |        |     +--rw hop-type?    te-hop-type
>          |  |     |  |        +--:(unnumbered)
>          |  |     |  |        |  +--rw unnumbered-hop
>          |  |     |  |        |     +--rw node-id?      te-types:te-
>    node-id
>          |  |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>    id
>          |  |     |  |        |     +--rw hop-type?     te-hop-type
>          |  |     |  |        +--:(label)
>          |  |     |  |        |  +--rw label-hop
>          |  |     |  |        |     +--rw value?   rt-types:generalized-
>    label
>          |  |     |  |        +--:(sid)
>          |  |     |  |           +--rw sid-hop
>          |  |     |  |              +--rw sid?   rt-types:generalized-
>    label
> 
> 
>          |  |     |  +--rw protection-type?             identityref
>          |  |     |  +--rw tunnel-termination-points
>          |  |     |  |  +--rw source?        binary
>          |  |     |  |  +--rw destination?   binary
>          |  |     |  +--rw tunnels
>          |  |     |     +--rw sharing?   boolean
>          |  |     |     +--rw tunnel* [tunnel-name]
>          |  |     |        +--rw tunnel-name    string
>          |  |     |        +--rw sharing?       boolean
>          |  |     +--rw path-constraints
>          |  |     |  +--rw path-metric-bound* [metric-type]
>          |  |     |  |  +--rw metric-type    identityref
>          |  |     |  |  +--rw upper-bound?   uint64
>          |  |     |  +--rw topology-id?         te-types:te-topology-id
>          |  |     |  +--rw ignore-overload?     boolean
>          |  |     |  +--rw bandwidth-generic
>          |  |     |  |  +--rw te-bandwidth
>          |  |     |  |     +--rw (technology)?
>          |  |     |  |        +--:(psc)
>          |  |     |  |        |  +--rw psc?       rt-types:bandwidth-
>    ieee-float32
>          |  |     |  |        +--:(otn)
>          |  |     |  |        |  +--rw otn* [rate-type]
>          |  |     |  |        |     +--rw rate-type    identityref
>          |  |     |  |        |     +--rw counter?     uint16
>          |  |     |  |        +--:(lsc)
>          |  |     |  |        |  +--rw wdm* [spectrum slot]
>          |  |     |  |        |     +--rw spectrum    identityref
>          |  |     |  |        |     +--rw slot        int16
>          |  |     |  |        |     +--rw width?      uint16
>          |  |     |  |        +--:(generic)
>          |  |     |  |           +--rw generic?   te-bandwidth
>          |  |     |  +--rw disjointness?        te-types:te-path-
>    disjointness
>          |  |     |  +--rw setup-priority?      uint8
>          |  |     |  +--rw hold-priority?       uint8
>          |  |     |  +--rw signaling-type?      identityref
>          |  |     |  +--rw path-affinities
>          |  |     |  |  +--rw constraint* [usage]
>          |  |     |  |     +--rw usage    identityref
>          |  |     |  |     +--rw value?   admin-groups
>          |  |     |  +--rw path-srlgs
>          |  |     |     +--rw usage?    identityref
>          |  |     |     +--rw values*   srlg
>          |  |     +--rw optimizations
>          |  |     |  +--rw (algorithm)?
>          |  |     |     +--:(metric) {path-optimization-metric}?
> 
> 
>          |  |     |     |  +--rw optimization-metric* [metric-type]
>          |  |     |     |  |  +--rw metric-type    identityref
>          |  |     |     |  |  +--rw weight?        uint8
>          |  |     |     |  +--rw tiebreakers
>          |  |     |     |     +--rw tiebreaker* [tiebreaker-type]
>          |  |     |     |        +--rw tiebreaker-type    identityref
>          |  |     |     +--:(objective-function) {path-optimization-
>    objective-function}?
>          |  |     |        +--rw objective-function
>          |  |     |           +--rw objective-function-type?
>    identityref
>          |  |     +--ro computed-path-properties
>          |  |        +--ro path-metric* [metric-type]
>          |  |        |  +--ro metric-type           identityref
>          |  |        |  +--ro accumulative-value?   uint64
>          |  |        +--ro path-affinities
>          |  |        |  +--ro constraint* [usage]
>          |  |        |     +--ro usage    identityref
>          |  |        |     +--ro value?   admin-groups
>          |  |        +--ro path-srlgs
>          |  |        |  +--ro usage?    identityref
>          |  |        |  +--ro values*   srlg
>          |  |        +--ro path-computed-route-objects
>          |  |           +--ro path-computed-route-object* [index]
>          |  |              +--ro index             uint32
>          |  |              +--ro (type)?
>          |  |                 +--:(numbered)
>          |  |                 |  +--ro numbered-hop
>          |  |                 |     +--ro address?    te-types:te-tp-id
>          |  |                 |     +--ro hop-type?   te-hop-type
>          |  |                 +--:(as-number)
>          |  |                 |  +--ro as-number-hop
>          |  |                 |     +--ro as-number?   binary
>          |  |                 |     +--ro hop-type?    te-hop-type
>          |  |                 +--:(unnumbered)
>          |  |                 |  +--ro unnumbered-hop
>          |  |                 |     +--ro node-id?      te-types:te-
>    node-id
>          |  |                 |     +--ro link-tp-id?   te-types:te-tp-
>    id
>          |  |                 |     +--ro hop-type?     te-hop-type
>          |  |                 +--:(label)
>          |  |                 |  +--ro label-hop
>          |  |                 |     +--ro value?   rt-types:generalized-
>    label
>          |  |                 +--:(sid)
>          |  |                    +--ro sid-hop
> 
>          |  |                       +--ro sid?   rt-types:generalized-
>    label
>          |  +--rw domain-id?               uint32
>          |  +--rw is-abstract?             empty
>          |  +--rw name?                    inet:domain-name
>          |  +--rw signaling-address*       inet:ip-address
>          |  +--rw underlay-topology {te-topology-hierarchy}?
>          |     +--rw network-ref?   leafref
>          +--ro oper-status?                te-types:te-oper-status
>          +--ro geolocation
>          |  +--ro altitude?    int64
>          |  +--ro latitude?    geographic-coordinate-degree
>          |  +--ro longitude?   geographic-coordinate-degree
>          +--ro is-multi-access-dr?         empty
>          +--ro information-source?         te-info-source
>          +--ro information-source-state
>          |  +--ro credibility-preference?    uint16
>          |  +--ro logical-network-element?   string
>          |  +--ro network-instance?          string
>          |  +--ro topology
>          |     +--ro node-ref?      leafref
>          |     +--ro network-ref?   leafref
>          +--ro information-source-entry* [information-source]
>          |  +--ro information-source          te-info-source
>          |  +--ro information-source-state
>          |  |  +--ro credibility-preference?    uint16
>          |  |  +--ro logical-network-element?   string
>          |  |  +--ro network-instance?          string
>          |  |  +--ro topology
>          |  |     +--ro node-ref?      leafref
>          |  |     +--ro network-ref?   leafref
>          |  +--ro connectivity-matrices
>          |  |  +--ro number-of-entries?          uint16
>          |  |  +--ro label-restriction* [inclusive-exclusive label-
>    start]
>          |  |  |  +--ro inclusive-exclusive    enumeration
>          |  |  |  +--ro label-start            rt-types:generalized-
>    label
>          |  |  |  +--ro label-end?             rt-types:generalized-
>    label
>          |  |  |  +--ro range-bitmap?          binary
>          |  |  +--ro is-allowed?                 boolean
>          |  |  +--ro underlay {te-topology-hierarchy}?
>          |  |  |  +--ro enabled?                     boolean
>          |  |  |  +--ro primary-path
>          |  |  |  |  +--ro network-ref?    leafref
>          |  |  |  |  +--ro path-element* [path-element-id]
> 
> 
>          |  |  |  |     +--ro path-element-id    uint32
>          |  |  |  |     +--ro index?             uint32
>          |  |  |  |     +--ro (type)?
>          |  |  |  |        +--:(numbered)
>          |  |  |  |        |  +--ro numbered-hop
>          |  |  |  |        |     +--ro address?    te-types:te-tp-id
>          |  |  |  |        |     +--ro hop-type?   te-hop-type
>          |  |  |  |        +--:(as-number)
>          |  |  |  |        |  +--ro as-number-hop
>          |  |  |  |        |     +--ro as-number?   binary
>          |  |  |  |        |     +--ro hop-type?    te-hop-type
>          |  |  |  |        +--:(unnumbered)
>          |  |  |  |        |  +--ro unnumbered-hop
>          |  |  |  |        |     +--ro node-id?      te-types:te-node-id
>          |  |  |  |        |     +--ro link-tp-id?   te-types:te-tp-id
>          |  |  |  |        |     +--ro hop-type?     te-hop-type
>          |  |  |  |        +--:(label)
>          |  |  |  |        |  +--ro label-hop
>          |  |  |  |        |     +--ro value?   rt-types:generalized-
>    label
>          |  |  |  |        +--:(sid)
>          |  |  |  |           +--ro sid-hop
>          |  |  |  |              +--ro sid?   rt-types:generalized-label
>          |  |  |  +--ro backup-path* [index]
>          |  |  |  |  +--ro index           uint32
>          |  |  |  |  +--ro network-ref?    leafref
>          |  |  |  |  +--ro path-element* [path-element-id]
>          |  |  |  |     +--ro path-element-id    uint32
>          |  |  |  |     +--ro index?             uint32
>          |  |  |  |     +--ro (type)?
>          |  |  |  |        +--:(numbered)
>          |  |  |  |        |  +--ro numbered-hop
>          |  |  |  |        |     +--ro address?    te-types:te-tp-id
>          |  |  |  |        |     +--ro hop-type?   te-hop-type
>          |  |  |  |        +--:(as-number)
>          |  |  |  |        |  +--ro as-number-hop
>          |  |  |  |        |     +--ro as-number?   binary
>          |  |  |  |        |     +--ro hop-type?    te-hop-type
>          |  |  |  |        +--:(unnumbered)
>          |  |  |  |        |  +--ro unnumbered-hop
>          |  |  |  |        |     +--ro node-id?      te-types:te-node-id
>          |  |  |  |        |     +--ro link-tp-id?   te-types:te-tp-id
>          |  |  |  |        |     +--ro hop-type?     te-hop-type
>          |  |  |  |        +--:(label)
>          |  |  |  |        |  +--ro label-hop
>          |  |  |  |        |     +--ro value?   rt-types:generalized-
>    label
> 
> 
>          |  |  |  |        +--:(sid)
>          |  |  |  |           +--ro sid-hop
>          |  |  |  |              +--ro sid?   rt-types:generalized-label
>          |  |  |  +--ro protection-type?             identityref
>          |  |  |  +--ro tunnel-termination-points
>          |  |  |  |  +--ro source?        binary
>          |  |  |  |  +--ro destination?   binary
>          |  |  |  +--ro tunnels
>          |  |  |     +--ro sharing?   boolean
>          |  |  |     +--ro tunnel* [tunnel-name]
>          |  |  |        +--ro tunnel-name    string
>          |  |  |        +--ro sharing?       boolean
>          |  |  +--ro path-constraints
>          |  |  |  +--ro path-metric-bound* [metric-type]
>          |  |  |  |  +--ro metric-type    identityref
>          |  |  |  |  +--ro upper-bound?   uint64
>          |  |  |  +--ro topology-id?         te-types:te-topology-id
>          |  |  |  +--ro ignore-overload?     boolean
>          |  |  |  +--ro bandwidth-generic
>          |  |  |  |  +--ro te-bandwidth
>          |  |  |  |     +--ro (technology)?
>          |  |  |  |        +--:(psc)
>          |  |  |  |        |  +--ro psc?       rt-types:bandwidth-ieee-
>    float32
>          |  |  |  |        +--:(otn)
>          |  |  |  |        |  +--ro otn* [rate-type]
>          |  |  |  |        |     +--ro rate-type    identityref
>          |  |  |  |        |     +--ro counter?     uint16
>          |  |  |  |        +--:(lsc)
>          |  |  |  |        |  +--ro wdm* [spectrum slot]
>          |  |  |  |        |     +--ro spectrum    identityref
>          |  |  |  |        |     +--ro slot        int16
>          |  |  |  |        |     +--ro width?      uint16
>          |  |  |  |        +--:(generic)
>          |  |  |  |           +--ro generic?   te-bandwidth
>          |  |  |  +--ro disjointness?        te-types:te-path-
>    disjointness
>          |  |  |  +--ro setup-priority?      uint8
>          |  |  |  +--ro hold-priority?       uint8
>          |  |  |  +--ro signaling-type?      identityref
>          |  |  |  +--ro path-affinities
>          |  |  |  |  +--ro constraint* [usage]
>          |  |  |  |     +--ro usage    identityref
>          |  |  |  |     +--ro value?   admin-groups
>          |  |  |  +--ro path-srlgs
>          |  |  |     +--ro usage?    identityref
>          |  |  |     +--ro values*   srlg
> 
> 
>          |  |  +--ro optimizations
>          |  |  |  +--ro (algorithm)?
>          |  |  |     +--:(metric) {path-optimization-metric}?
>          |  |  |     |  +--ro optimization-metric* [metric-type]
>          |  |  |     |  |  +--ro metric-type    identityref
>          |  |  |     |  |  +--ro weight?        uint8
>          |  |  |     |  +--ro tiebreakers
>          |  |  |     |     +--ro tiebreaker* [tiebreaker-type]
>          |  |  |     |        +--ro tiebreaker-type    identityref
>          |  |  |     +--:(objective-function) {path-optimization-
>    objective-function}?
>          |  |  |        +--ro objective-function
>          |  |  |           +--ro objective-function-type?   identityref
>          |  |  +--ro computed-path-properties
>          |  |  |  +--ro path-metric* [metric-type]
>          |  |  |  |  +--ro metric-type           identityref
>          |  |  |  |  +--ro accumulative-value?   uint64
>          |  |  |  +--ro path-affinities
>          |  |  |  |  +--ro constraint* [usage]
>          |  |  |  |     +--ro usage    identityref
>          |  |  |  |     +--ro value?   admin-groups
>          |  |  |  +--ro path-srlgs
>          |  |  |  |  +--ro usage?    identityref
>          |  |  |  |  +--ro values*   srlg
>          |  |  |  +--ro path-computed-route-objects
>          |  |  |     +--ro path-computed-route-object* [index]
>          |  |  |        +--ro index             uint32
>          |  |  |        +--ro (type)?
>          |  |  |           +--:(numbered)
>          |  |  |           |  +--ro numbered-hop
>          |  |  |           |     +--ro address?    te-types:te-tp-id
>          |  |  |           |     +--ro hop-type?   te-hop-type
>          |  |  |           +--:(as-number)
>          |  |  |           |  +--ro as-number-hop
>          |  |  |           |     +--ro as-number?   binary
>          |  |  |           |     +--ro hop-type?    te-hop-type
>          |  |  |           +--:(unnumbered)
>          |  |  |           |  +--ro unnumbered-hop
>          |  |  |           |     +--ro node-id?      te-types:te-node-id
>          |  |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>          |  |  |           |     +--ro hop-type?     te-hop-type
>          |  |  |           +--:(label)
>          |  |  |           |  +--ro label-hop
>          |  |  |           |     +--ro value?   rt-types:generalized-
>    label
>          |  |  |           +--:(sid)
>          |  |  |              +--ro sid-hop
> 
> 
>          |  |  |                 +--ro sid?   rt-types:generalized-label
>          |  |  +--ro connectivity-matrix* [id]
>          |  |     +--ro id                          uint32
>          |  |     +--ro from
>          |  |     |  +--ro tp-ref?              leafref
>          |  |     |  +--ro label-restriction* [inclusive-exclusive
>    label-start]
>          |  |     |     +--ro inclusive-exclusive    enumeration
>          |  |     |     +--ro label-start            rt-
>    types:generalized-label
>          |  |     |     +--ro label-end?             rt-
>    types:generalized-label
>          |  |     |     +--ro range-bitmap?          binary
>          |  |     +--ro to
>          |  |     |  +--ro tp-ref?              leafref
>          |  |     |  +--ro label-restriction* [inclusive-exclusive
>    label-start]
>          |  |     |     +--ro inclusive-exclusive    enumeration
>          |  |     |     +--ro label-start            rt-
>    types:generalized-label
>          |  |     |     +--ro label-end?             rt-
>    types:generalized-label
>          |  |     |     +--ro range-bitmap?          binary
>          |  |     +--ro is-allowed?                 boolean
>          |  |     +--ro underlay {te-topology-hierarchy}?
>          |  |     |  +--ro enabled?                     boolean
>          |  |     |  +--ro primary-path
>          |  |     |  |  +--ro network-ref?    leafref
>          |  |     |  |  +--ro path-element* [path-element-id]
>          |  |     |  |     +--ro path-element-id    uint32
>          |  |     |  |     +--ro index?             uint32
>          |  |     |  |     +--ro (type)?
>          |  |     |  |        +--:(numbered)
>          |  |     |  |        |  +--ro numbered-hop
>          |  |     |  |        |     +--ro address?    te-types:te-tp-id
>          |  |     |  |        |     +--ro hop-type?   te-hop-type
>          |  |     |  |        +--:(as-number)
>          |  |     |  |        |  +--ro as-number-hop
>          |  |     |  |        |     +--ro as-number?   binary
>          |  |     |  |        |     +--ro hop-type?    te-hop-type
>          |  |     |  |        +--:(unnumbered)
>          |  |     |  |        |  +--ro unnumbered-hop
>          |  |     |  |        |     +--ro node-id?      te-types:te-
>    node-id
>          |  |     |  |        |     +--ro link-tp-id?   te-types:te-tp-
>    id
>          |  |     |  |        |     +--ro hop-type?     te-hop-type
> 
> 
>          |  |     |  |        +--:(label)
>          |  |     |  |        |  +--ro label-hop
>          |  |     |  |        |     +--ro value?   rt-types:generalized-
>    label
>          |  |     |  |        +--:(sid)
>          |  |     |  |           +--ro sid-hop
>          |  |     |  |              +--ro sid?   rt-types:generalized-
>    label
>          |  |     |  +--ro backup-path* [index]
>          |  |     |  |  +--ro index           uint32
>          |  |     |  |  +--ro network-ref?    leafref
>          |  |     |  |  +--ro path-element* [path-element-id]
>          |  |     |  |     +--ro path-element-id    uint32
>          |  |     |  |     +--ro index?             uint32
>          |  |     |  |     +--ro (type)?
>          |  |     |  |        +--:(numbered)
>          |  |     |  |        |  +--ro numbered-hop
>          |  |     |  |        |     +--ro address?    te-types:te-tp-id
>          |  |     |  |        |     +--ro hop-type?   te-hop-type
>          |  |     |  |        +--:(as-number)
>          |  |     |  |        |  +--ro as-number-hop
>          |  |     |  |        |     +--ro as-number?   binary
>          |  |     |  |        |     +--ro hop-type?    te-hop-type
>          |  |     |  |        +--:(unnumbered)
>          |  |     |  |        |  +--ro unnumbered-hop
>          |  |     |  |        |     +--ro node-id?      te-types:te-
>    node-id
>          |  |     |  |        |     +--ro link-tp-id?   te-types:te-tp-
>    id
>          |  |     |  |        |     +--ro hop-type?     te-hop-type
>          |  |     |  |        +--:(label)
>          |  |     |  |        |  +--ro label-hop
>          |  |     |  |        |     +--ro value?   rt-types:generalized-
>    label
>          |  |     |  |        +--:(sid)
>          |  |     |  |           +--ro sid-hop
>          |  |     |  |              +--ro sid?   rt-types:generalized-
>    label
>          |  |     |  +--ro protection-type?             identityref
>          |  |     |  +--ro tunnel-termination-points
>          |  |     |  |  +--ro source?        binary
>          |  |     |  |  +--ro destination?   binary
>          |  |     |  +--ro tunnels
>          |  |     |     +--ro sharing?   boolean
>          |  |     |     +--ro tunnel* [tunnel-name]
>          |  |     |        +--ro tunnel-name    string
>          |  |     |        +--ro sharing?       boolean
> 
> 
> 
>          |  |     +--ro path-constraints
>          |  |     |  +--ro path-metric-bound* [metric-type]
>          |  |     |  |  +--ro metric-type    identityref
>          |  |     |  |  +--ro upper-bound?   uint64
>          |  |     |  +--ro topology-id?         te-types:te-topology-id
>          |  |     |  +--ro ignore-overload?     boolean
>          |  |     |  +--ro bandwidth-generic
>          |  |     |  |  +--ro te-bandwidth
>          |  |     |  |     +--ro (technology)?
>          |  |     |  |        +--:(psc)
>          |  |     |  |        |  +--ro psc?       rt-types:bandwidth-
>    ieee-float32
>          |  |     |  |        +--:(otn)
>          |  |     |  |        |  +--ro otn* [rate-type]
>          |  |     |  |        |     +--ro rate-type    identityref
>          |  |     |  |        |     +--ro counter?     uint16
>          |  |     |  |        +--:(lsc)
>          |  |     |  |        |  +--ro wdm* [spectrum slot]
>          |  |     |  |        |     +--ro spectrum    identityref
>          |  |     |  |        |     +--ro slot        int16
>          |  |     |  |        |     +--ro width?      uint16
>          |  |     |  |        +--:(generic)
>          |  |     |  |           +--ro generic?   te-bandwidth
>          |  |     |  +--ro disjointness?        te-types:te-path-
>    disjointness
>          |  |     |  +--ro setup-priority?      uint8
>          |  |     |  +--ro hold-priority?       uint8
>          |  |     |  +--ro signaling-type?      identityref
>          |  |     |  +--ro path-affinities
>          |  |     |  |  +--ro constraint* [usage]
>          |  |     |  |     +--ro usage    identityref
>          |  |     |  |     +--ro value?   admin-groups
>          |  |     |  +--ro path-srlgs
>          |  |     |     +--ro usage?    identityref
>          |  |     |     +--ro values*   srlg
>          |  |     +--ro optimizations
>          |  |     |  +--ro (algorithm)?
>          |  |     |     +--:(metric) {path-optimization-metric}?
>          |  |     |     |  +--ro optimization-metric* [metric-type]
>          |  |     |     |  |  +--ro metric-type    identityref
>          |  |     |     |  |  +--ro weight?        uint8
>          |  |     |     |  +--ro tiebreakers
>          |  |     |     |     +--ro tiebreaker* [tiebreaker-type]
>          |  |     |     |        +--ro tiebreaker-type    identityref
>          |  |     |     +--:(objective-function) {path-optimization-
>    objective-function}?
>          |  |     |        +--ro objective-function
> 
> 
>          |  |     |           +--ro objective-function-type?
>    identityref
>          |  |     +--ro computed-path-properties
>          |  |        +--ro path-metric* [metric-type]
>          |  |        |  +--ro metric-type           identityref
>          |  |        |  +--ro accumulative-value?   uint64
>          |  |        +--ro path-affinities
>          |  |        |  +--ro constraint* [usage]
>          |  |        |     +--ro usage    identityref
>          |  |        |     +--ro value?   admin-groups
>          |  |        +--ro path-srlgs
>          |  |        |  +--ro usage?    identityref
>          |  |        |  +--ro values*   srlg
>          |  |        +--ro path-computed-route-objects
>          |  |           +--ro path-computed-route-object* [index]
>          |  |              +--ro index             uint32
>          |  |              +--ro (type)?
>          |  |                 +--:(numbered)
>          |  |                 |  +--ro numbered-hop
>          |  |                 |     +--ro address?    te-types:te-tp-id
>          |  |                 |     +--ro hop-type?   te-hop-type
>          |  |                 +--:(as-number)
>          |  |                 |  +--ro as-number-hop
>          |  |                 |     +--ro as-number?   binary
>          |  |                 |     +--ro hop-type?    te-hop-type
>          |  |                 +--:(unnumbered)
>          |  |                 |  +--ro unnumbered-hop
>          |  |                 |     +--ro node-id?      te-types:te-
>    node-id
>          |  |                 |     +--ro link-tp-id?   te-types:te-tp-
>    id
>          |  |                 |     +--ro hop-type?     te-hop-type
>          |  |                 +--:(label)
>          |  |                 |  +--ro label-hop
>          |  |                 |     +--ro value?   rt-types:generalized-
>    label
>          |  |                 +--:(sid)
>          |  |                    +--ro sid-hop
>          |  |                       +--ro sid?   rt-types:generalized-
>    label
>          |  +--ro domain-id?                  uint32
>          |  +--ro is-abstract?                empty
>          |  +--ro name?                       inet:domain-name
>          |  +--ro signaling-address*          inet:ip-address
>          |  +--ro underlay-topology {te-topology-hierarchy}?
>          |     +--ro network-ref?   leafref
>          +--ro statistics
> 
> 
> 
>          |  +--ro discontinuity-time           yang:date-and-time
>          |  +--ro node
>          |  |  +--ro disables?             yang:counter32
>          |  |  +--ro enables?              yang:counter32
>          |  |  +--ro maintenance-sets?     yang:counter32
>          |  |  +--ro maintenance-clears?   yang:counter32
>          |  |  +--ro modifies?             yang:counter32
>          |  +--ro connectivity-matrix-entry
>          |     +--ro creates?    yang:counter32
>          |     +--ro deletes?    yang:counter32
>          |     +--ro disables?   yang:counter32
>          |     +--ro enables?    yang:counter32
>          |     +--ro modifies?   yang:counter32
>          +--rw tunnel-termination-point* [tunnel-tp-id]
>             +--rw tunnel-tp-id                           binary
>             +--rw admin-status?                          te-types:te-
>    admin-status
>             +--rw name?                                  string
>             +--rw switching-capability?                  identityref
>             +--rw encoding?                              identityref
>             +--rw inter-layer-lock-id*                   uint32
>             +--rw protection-type?                       identityref
>             +--rw client-layer-adaptation
>             |  +--rw switching-capability* [switching-capability
>    encoding]
>             |     +--rw switching-capability    identityref
>             |     +--rw encoding                identityref
>             |     +--rw bandwidth
>             |        +--rw te-bandwidth
>             |           +--rw (technology)?
>             |              +--:(psc)
>             |              |  +--rw psc?       rt-types:bandwidth-ieee-
>    float32
>             |              +--:(otn)
>             |              |  +--rw otn* [rate-type]
>             |              |     +--rw rate-type    identityref
>             |              |     +--rw counter?     uint16
>             |              +--:(lsc)
>             |              |  +--rw wdm* [spectrum slot]
>             |              |     +--rw spectrum    identityref
>             |              |     +--rw slot        int16
>             |              |     +--rw width?      uint16
>             |              +--:(generic)
>             |                 +--rw generic?   te-bandwidth
>             +--rw local-link-connectivities
>             |  +--rw number-of-entries?          uint16
> 
> 
> 
>             |  +--rw label-restriction* [inclusive-exclusive label-
>    start]
>             |  |  +--rw inclusive-exclusive    enumeration
>             |  |  +--rw label-start            rt-types:generalized-
>    label
>             |  |  +--rw label-end?             rt-types:generalized-
>    label
>             |  |  +--rw range-bitmap?          binary
>             |  +--rw is-allowed?                 boolean
>             |  +--rw underlay {te-topology-hierarchy}?
>             |  |  +--rw enabled?                     boolean
>             |  |  +--rw primary-path
>             |  |  |  +--rw network-ref?    leafref
>             |  |  |  +--rw path-element* [path-element-id]
>             |  |  |     +--rw path-element-id    uint32
>             |  |  |     +--rw index?             uint32
>             |  |  |     +--rw (type)?
>             |  |  |        +--:(numbered)
>             |  |  |        |  +--rw numbered-hop
>             |  |  |        |     +--rw address?    te-types:te-tp-id
>             |  |  |        |     +--rw hop-type?   te-hop-type
>             |  |  |        +--:(as-number)
>             |  |  |        |  +--rw as-number-hop
>             |  |  |        |     +--rw as-number?   binary
>             |  |  |        |     +--rw hop-type?    te-hop-type
>             |  |  |        +--:(unnumbered)
>             |  |  |        |  +--rw unnumbered-hop
>             |  |  |        |     +--rw node-id?      te-types:te-node-id
>             |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>             |  |  |        |     +--rw hop-type?     te-hop-type
>             |  |  |        +--:(label)
>             |  |  |        |  +--rw label-hop
>             |  |  |        |     +--rw value?   rt-types:generalized-
>    label
>             |  |  |        +--:(sid)
>             |  |  |           +--rw sid-hop
>             |  |  |              +--rw sid?   rt-types:generalized-label
>             |  |  +--rw backup-path* [index]
>             |  |  |  +--rw index           uint32
>             |  |  |  +--rw network-ref?    leafref
>             |  |  |  +--rw path-element* [path-element-id]
>             |  |  |     +--rw path-element-id    uint32
>             |  |  |     +--rw index?             uint32
>             |  |  |     +--rw (type)?
>             |  |  |        +--:(numbered)
>             |  |  |        |  +--rw numbered-hop
>             |  |  |        |     +--rw address?    te-types:te-tp-id
> 
> 
> 
> 
>             |  |  |        |     +--rw hop-type?   te-hop-type
>             |  |  |        +--:(as-number)
>             |  |  |        |  +--rw as-number-hop
>             |  |  |        |     +--rw as-number?   binary
>             |  |  |        |     +--rw hop-type?    te-hop-type
>             |  |  |        +--:(unnumbered)
>             |  |  |        |  +--rw unnumbered-hop
>             |  |  |        |     +--rw node-id?      te-types:te-node-id
>             |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>             |  |  |        |     +--rw hop-type?     te-hop-type
>             |  |  |        +--:(label)
>             |  |  |        |  +--rw label-hop
>             |  |  |        |     +--rw value?   rt-types:generalized-
>    label
>             |  |  |        +--:(sid)
>             |  |  |           +--rw sid-hop
>             |  |  |              +--rw sid?   rt-types:generalized-label
>             |  |  +--rw protection-type?             identityref
>             |  |  +--rw tunnel-termination-points
>             |  |  |  +--rw source?        binary
>             |  |  |  +--rw destination?   binary
>             |  |  +--rw tunnels
>             |  |     +--rw sharing?   boolean
>             |  |     +--rw tunnel* [tunnel-name]
>             |  |        +--rw tunnel-name    string
>             |  |        +--rw sharing?       boolean
>             |  +--rw path-constraints
>             |  |  +--rw path-metric-bound* [metric-type]
>             |  |  |  +--rw metric-type    identityref
>             |  |  |  +--rw upper-bound?   uint64
>             |  |  +--rw topology-id?         te-types:te-topology-id
>             |  |  +--rw ignore-overload?     boolean
>             |  |  +--rw bandwidth-generic
>             |  |  |  +--rw te-bandwidth
>             |  |  |     +--rw (technology)?
>             |  |  |        +--:(psc)
>             |  |  |        |  +--rw psc?       rt-types:bandwidth-ieee-
>    float32
>             |  |  |        +--:(otn)
>             |  |  |        |  +--rw otn* [rate-type]
>             |  |  |        |     +--rw rate-type    identityref
>             |  |  |        |     +--rw counter?     uint16
>             |  |  |        +--:(lsc)
>             |  |  |        |  +--rw wdm* [spectrum slot]
>             |  |  |        |     +--rw spectrum    identityref
>             |  |  |        |     +--rw slot        int16
>             |  |  |        |     +--rw width?      uint16
> 
> 
> 
> 
>             |  |  |        +--:(generic)
>             |  |  |           +--rw generic?   te-bandwidth
>             |  |  +--rw disjointness?        te-types:te-path-
>    disjointness
>             |  |  +--rw setup-priority?      uint8
>             |  |  +--rw hold-priority?       uint8
>             |  |  +--rw signaling-type?      identityref
>             |  |  +--rw path-affinities
>             |  |  |  +--rw constraint* [usage]
>             |  |  |     +--rw usage    identityref
>             |  |  |     +--rw value?   admin-groups
>             |  |  +--rw path-srlgs
>             |  |     +--rw usage?    identityref
>             |  |     +--rw values*   srlg
>             |  +--rw optimizations
>             |  |  +--rw (algorithm)?
>             |  |     +--:(metric) {path-optimization-metric}?
>             |  |     |  +--rw optimization-metric* [metric-type]
>             |  |     |  |  +--rw metric-type    identityref
>             |  |     |  |  +--rw weight?        uint8
>             |  |     |  +--rw tiebreakers
>             |  |     |     +--rw tiebreaker* [tiebreaker-type]
>             |  |     |        +--rw tiebreaker-type    identityref
>             |  |     +--:(objective-function) {path-optimization-
>    objective-function}?
>             |  |        +--rw objective-function
>             |  |           +--rw objective-function-type?   identityref
>             |  +--ro computed-path-properties
>             |  |  +--ro path-metric* [metric-type]
>             |  |  |  +--ro metric-type           identityref
>             |  |  |  +--ro accumulative-value?   uint64
>             |  |  +--ro path-affinities
>             |  |  |  +--ro constraint* [usage]
>             |  |  |     +--ro usage    identityref
>             |  |  |     +--ro value?   admin-groups
>             |  |  +--ro path-srlgs
>             |  |  |  +--ro usage?    identityref
>             |  |  |  +--ro values*   srlg
>             |  |  +--ro path-computed-route-objects
>             |  |     +--ro path-computed-route-object* [index]
>             |  |        +--ro index             uint32
>             |  |        +--ro (type)?
>             |  |           +--:(numbered)
>             |  |           |  +--ro numbered-hop
>             |  |           |     +--ro address?    te-types:te-tp-id
>             |  |           |     +--ro hop-type?   te-hop-type
>             |  |           +--:(as-number)
> 
> 
> 
>             |  |           |  +--ro as-number-hop
>             |  |           |     +--ro as-number?   binary
>             |  |           |     +--ro hop-type?    te-hop-type
>             |  |           +--:(unnumbered)
>             |  |           |  +--ro unnumbered-hop
>             |  |           |     +--ro node-id?      te-types:te-node-id
>             |  |           |     +--ro link-tp-id?   te-types:te-tp-id
>             |  |           |     +--ro hop-type?     te-hop-type
>             |  |           +--:(label)
>             |  |           |  +--ro label-hop
>             |  |           |     +--ro value?   rt-types:generalized-
>    label
>             |  |           +--:(sid)
>             |  |              +--ro sid-hop
>             |  |                 +--ro sid?   rt-types:generalized-label
>             |  +--rw local-link-connectivity* [link-tp-ref]
>             |     +--rw link-tp-ref                 leafref
>             |     +--rw label-restriction* [inclusive-exclusive label-
>    start]
>             |     |  +--rw inclusive-exclusive    enumeration
>             |     |  +--rw label-start            rt-types:generalized-
>    label
>             |     |  +--rw label-end?             rt-types:generalized-
>    label
>             |     |  +--rw range-bitmap?          binary
>             |     +--rw is-allowed?                 boolean
>             |     +--rw underlay {te-topology-hierarchy}?
>             |     |  +--rw enabled?                     boolean
>             |     |  +--rw primary-path
>             |     |  |  +--rw network-ref?    leafref
>             |     |  |  +--rw path-element* [path-element-id]
>             |     |  |     +--rw path-element-id    uint32
>             |     |  |     +--rw index?             uint32
>             |     |  |     +--rw (type)?
>             |     |  |        +--:(numbered)
>             |     |  |        |  +--rw numbered-hop
>             |     |  |        |     +--rw address?    te-types:te-tp-id
>             |     |  |        |     +--rw hop-type?   te-hop-type
>             |     |  |        +--:(as-number)
>             |     |  |        |  +--rw as-number-hop
>             |     |  |        |     +--rw as-number?   binary
>             |     |  |        |     +--rw hop-type?    te-hop-type
>             |     |  |        +--:(unnumbered)
>             |     |  |        |  +--rw unnumbered-hop
>             |     |  |        |     +--rw node-id?      te-types:te-
>    node-id
> 
> 
> 
> 
>             |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>    id
>             |     |  |        |     +--rw hop-type?     te-hop-type
>             |     |  |        +--:(label)
>             |     |  |        |  +--rw label-hop
>             |     |  |        |     +--rw value?   rt-types:generalized-
>    label
>             |     |  |        +--:(sid)
>             |     |  |           +--rw sid-hop
>             |     |  |              +--rw sid?   rt-types:generalized-
>    label
>             |     |  +--rw backup-path* [index]
>             |     |  |  +--rw index           uint32
>             |     |  |  +--rw network-ref?    leafref
>             |     |  |  +--rw path-element* [path-element-id]
>             |     |  |     +--rw path-element-id    uint32
>             |     |  |     +--rw index?             uint32
>             |     |  |     +--rw (type)?
>             |     |  |        +--:(numbered)
>             |     |  |        |  +--rw numbered-hop
>             |     |  |        |     +--rw address?    te-types:te-tp-id
>             |     |  |        |     +--rw hop-type?   te-hop-type
>             |     |  |        +--:(as-number)
>             |     |  |        |  +--rw as-number-hop
>             |     |  |        |     +--rw as-number?   binary
>             |     |  |        |     +--rw hop-type?    te-hop-type
>             |     |  |        +--:(unnumbered)
>             |     |  |        |  +--rw unnumbered-hop
>             |     |  |        |     +--rw node-id?      te-types:te-
>    node-id
>             |     |  |        |     +--rw link-tp-id?   te-types:te-tp-
>    id
>             |     |  |        |     +--rw hop-type?     te-hop-type
>             |     |  |        +--:(label)
>             |     |  |        |  +--rw label-hop
>             |     |  |        |     +--rw value?   rt-types:generalized-
>    label
>             |     |  |        +--:(sid)
>             |     |  |           +--rw sid-hop
>             |     |  |              +--rw sid?   rt-types:generalized-
>    label
>             |     |  +--rw protection-type?             identityref
>             |     |  +--rw tunnel-termination-points
>             |     |  |  +--rw source?        binary
>             |     |  |  +--rw destination?   binary
>             |     |  +--rw tunnels
>             |     |     +--rw sharing?   boolean
> 
> 
> 
>             |     |     +--rw tunnel* [tunnel-name]
>             |     |        +--rw tunnel-name    string
>             |     |        +--rw sharing?       boolean
>             |     +--rw path-constraints
>             |     |  +--rw path-metric-bound* [metric-type]
>             |     |  |  +--rw metric-type    identityref
>             |     |  |  +--rw upper-bound?   uint64
>             |     |  +--rw topology-id?         te-types:te-topology-id
>             |     |  +--rw ignore-overload?     boolean
>             |     |  +--rw bandwidth-generic
>             |     |  |  +--rw te-bandwidth
>             |     |  |     +--rw (technology)?
>             |     |  |        +--:(psc)
>             |     |  |        |  +--rw psc?       rt-types:bandwidth-
>    ieee-float32
>             |     |  |        +--:(otn)
>             |     |  |        |  +--rw otn* [rate-type]
>             |     |  |        |     +--rw rate-type    identityref
>             |     |  |        |     +--rw counter?     uint16
>             |     |  |        +--:(lsc)
>             |     |  |        |  +--rw wdm* [spectrum slot]
>             |     |  |        |     +--rw spectrum    identityref
>             |     |  |        |     +--rw slot        int16
>             |     |  |        |     +--rw width?      uint16
>             |     |  |        +--:(generic)
>             |     |  |           +--rw generic?   te-bandwidth
>             |     |  +--rw disjointness?        te-types:te-path-
>    disjointness
>             |     |  +--rw setup-priority?      uint8
>             |     |  +--rw hold-priority?       uint8
>             |     |  +--rw signaling-type?      identityref
>             |     |  +--rw path-affinities
>             |     |  |  +--rw constraint* [usage]
>             |     |  |     +--rw usage    identityref
>             |     |  |     +--rw value?   admin-groups
>             |     |  +--rw path-srlgs
>             |     |     +--rw usage?    identityref
>             |     |     +--rw values*   srlg
>             |     +--rw optimizations
>             |     |  +--rw (algorithm)?
>             |     |     +--:(metric) {path-optimization-metric}?
>             |     |     |  +--rw optimization-metric* [metric-type]
>             |     |     |  |  +--rw metric-type    identityref
>             |     |     |  |  +--rw weight?        uint8
>             |     |     |  +--rw tiebreakers
>             |     |     |     +--rw tiebreaker* [tiebreaker-type]
>             |     |     |        +--rw tiebreaker-type    identityref
> 
> 
> 
> 
>             |     |     +--:(objective-function) {path-optimization-
>    objective-function}?
>             |     |        +--rw objective-function
>             |     |           +--rw objective-function-type?
>    identityref
>             |     +--ro computed-path-properties
>             |        +--ro path-metric* [metric-type]
>             |        |  +--ro metric-type           identityref
>             |        |  +--ro accumulative-value?   uint64
>             |        +--ro path-affinities
>             |        |  +--ro constraint* [usage]
>             |        |     +--ro usage    identityref
>             |        |     +--ro value?   admin-groups
>             |        +--ro path-srlgs
>             |        |  +--ro usage?    identityref
>             |        |  +--ro values*   srlg
>             |        +--ro path-computed-route-objects
>             |           +--ro path-computed-route-object* [index]
>             |              +--ro index             uint32
>             |              +--ro (type)?
>             |                 +--:(numbered)
>             |                 |  +--ro numbered-hop
>             |                 |     +--ro address?    te-types:te-tp-id
>             |                 |     +--ro hop-type?   te-hop-type
>             |                 +--:(as-number)
>             |                 |  +--ro as-number-hop
>             |                 |     +--ro as-number?   binary
>             |                 |     +--ro hop-type?    te-hop-type
>             |                 +--:(unnumbered)
>             |                 |  +--ro unnumbered-hop
>             |                 |     +--ro node-id?      te-types:te-
>    node-id
>             |                 |     +--ro link-tp-id?   te-types:te-tp-
>    id
>             |                 |     +--ro hop-type?     te-hop-type
>             |                 +--:(label)
>             |                 |  +--ro label-hop
>             |                 |     +--ro value?   rt-types:generalized-
>    label
>             |                 +--:(sid)
>             |                    +--ro sid-hop
>             |                       +--ro sid?   rt-types:generalized-
>    label
>             +--ro oper-status?                           te-types:te-
>    oper-status
>             +--ro geolocation
>             |  +--ro altitude?    int64
> 
> 
>             |  +--ro latitude?    geographic-coordinate-degree
>             |  +--ro longitude?   geographic-coordinate-degree
>             +--ro statistics
>             |  +--ro discontinuity-time          yang:date-and-time
>             |  +--ro tunnel-termination-point
>             |  |  +--ro disables?             yang:counter32
>             |  |  +--ro enables?              yang:counter32
>             |  |  +--ro maintenance-clears?   yang:counter32
>             |  |  +--ro maintenance-sets?     yang:counter32
>             |  |  +--ro modifies?             yang:counter32
>             |  |  +--ro downs?                yang:counter32
>             |  |  +--ro ups?                  yang:counter32
>             |  |  +--ro in-service-clears?    yang:counter32
>             |  |  +--ro in-service-sets?      yang:counter32
>             |  +--ro local-link-connectivity
>             |     +--ro creates?    yang:counter32
>             |     +--ro deletes?    yang:counter32
>             |     +--ro disables?   yang:counter32
>             |     +--ro enables?    yang:counter32
>             |     +--ro modifies?   yang:counter32
>             +--rw supporting-tunnel-termination-point* [node-ref tunnel-
>    tp-ref]
>                +--rw node-ref         inet:uri
>                +--rw tunnel-tp-ref    binary
>    augment /nw:networks/nw:network/nt:link:
>       +--rw te!
>          +--rw (bundle-stack-level)?
>          |  +--:(bundle)
>          |  |  +--rw bundled-links
>          |  |     +--rw bundled-link* [sequence]
>          |  |        +--rw sequence      uint32
>          |  |        +--rw src-tp-ref?   leafref
>          |  |        +--rw des-tp-ref?   leafref
>          |  +--:(component)
>          |     +--rw component-links
>          |        +--rw component-link* [sequence]
>          |           +--rw sequence             uint32
>          |           +--rw src-interface-ref?   string
>          |           +--rw des-interface-ref?   string
>          +--rw te-link-template*           leafref {template}?
>          +--rw te-link-attributes
>          |  +--rw access-type?                      te-types:te-link-
>    access-type
>          |  +--rw external-domain
>          |  |  +--rw network-ref?            leafref
>          |  |  +--rw remote-te-node-id?      te-types:te-node-id
>          |  |  +--rw remote-te-link-tp-id?   te-types:te-tp-id
> 
> 
> 
> 
>          |  |  +--rw plug-id?                uint32
>          |  +--rw is-abstract?                      empty
>          |  +--rw name?                             string
>          |  +--rw underlay {te-topology-hierarchy}?
>          |  |  +--rw enabled?                     boolean
>          |  |  +--rw primary-path
>          |  |  |  +--rw network-ref?    leafref
>          |  |  |  +--rw path-element* [path-element-id]
>          |  |  |     +--rw path-element-id    uint32
>          |  |  |     +--rw index?             uint32
>          |  |  |     +--rw (type)?
>          |  |  |        +--:(numbered)
>          |  |  |        |  +--rw numbered-hop
>          |  |  |        |     +--rw address?    te-types:te-tp-id
>          |  |  |        |     +--rw hop-type?   te-hop-type
>          |  |  |        +--:(as-number)
>          |  |  |        |  +--rw as-number-hop
>          |  |  |        |     +--rw as-number?   binary
>          |  |  |        |     +--rw hop-type?    te-hop-type
>          |  |  |        +--:(unnumbered)
>          |  |  |        |  +--rw unnumbered-hop
>          |  |  |        |     +--rw node-id?      te-types:te-node-id
>          |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>          |  |  |        |     +--rw hop-type?     te-hop-type
>          |  |  |        +--:(label)
>          |  |  |        |  +--rw label-hop
>          |  |  |        |     +--rw value?   rt-types:generalized-label
>          |  |  |        +--:(sid)
>          |  |  |           +--rw sid-hop
>          |  |  |              +--rw sid?   rt-types:generalized-label
>          |  |  +--rw backup-path* [index]
>          |  |  |  +--rw index           uint32
>          |  |  |  +--rw network-ref?    leafref
>          |  |  |  +--rw path-element* [path-element-id]
>          |  |  |     +--rw path-element-id    uint32
>          |  |  |     +--rw index?             uint32
>          |  |  |     +--rw (type)?
>          |  |  |        +--:(numbered)
>          |  |  |        |  +--rw numbered-hop
>          |  |  |        |     +--rw address?    te-types:te-tp-id
>          |  |  |        |     +--rw hop-type?   te-hop-type
>          |  |  |        +--:(as-number)
>          |  |  |        |  +--rw as-number-hop
>          |  |  |        |     +--rw as-number?   binary
>          |  |  |        |     +--rw hop-type?    te-hop-type
>          |  |  |        +--:(unnumbered)
>          |  |  |        |  +--rw unnumbered-hop
> 
> 
>          |  |  |        |     +--rw node-id?      te-types:te-node-id
>          |  |  |        |     +--rw link-tp-id?   te-types:te-tp-id
>          |  |  |        |     +--rw hop-type?     te-hop-type
>          |  |  |        +--:(label)
>          |  |  |        |  +--rw label-hop
>          |  |  |        |     +--rw value?   rt-types:generalized-label
>          |  |  |        +--:(sid)
>          |  |  |           +--rw sid-hop
>          |  |  |              +--rw sid?   rt-types:generalized-label
>          |  |  +--rw protection-type?             identityref
>          |  |  +--rw tunnel-termination-points
>          |  |  |  +--rw source?        binary
>          |  |  |  +--rw destination?   binary
>          |  |  +--rw tunnels
>          |  |     +--rw sharing?   boolean
>          |  |     +--rw tunnel* [tunnel-name]
>          |  |        +--rw tunnel-name    string
>          |  |        +--rw sharing?       boolean
>          |  +--rw admin-status?                     te-types:te-admin-
>    status
>          |  +--rw link-index?                       uint64
>          |  +--rw administrative-group?             te-types:admin-
>    groups
>          |  +--rw interface-switching-capability* [switching-capability
>    encoding]
>          |  |  +--rw switching-capability    identityref
>          |  |  +--rw encoding                identityref
>          |  |  +--rw max-lsp-bandwidth* [priority]
>          |  |     +--rw priority     uint8
>          |  |     +--rw bandwidth
>          |  |        +--rw te-bandwidth
>          |  |           +--rw (technology)?
>          |  |              +--:(psc)
>          |  |              |  +--rw psc?       rt-types:bandwidth-ieee-
>    float32
>          |  |              +--:(otn)
>          |  |              |  +--rw otn* [rate-type]
>          |  |              |     +--rw rate-type    identityref
>          |  |              |     +--rw counter?     uint16
>          |  |              +--:(lsc)
>          |  |              |  +--rw wdm* [spectrum slot]
>          |  |              |     +--rw spectrum    identityref
>          |  |              |     +--rw slot        int16
>          |  |              |     +--rw width?      uint16
>          |  |              +--:(generic)
>          |  |                 +--rw generic?   te-bandwidth
>          |  +--rw label-restriction* [inclusive-exclusive label-start]
> 
> 
> 
>          |  |  +--rw inclusive-exclusive    enumeration
>          |  |  +--rw label-start            rt-types:generalized-label
>          |  |  +--rw label-end?             rt-types:generalized-label
>          |  |  +--rw range-bitmap?          binary
>          |  +--rw link-protection-type?             enumeration
>          |  +--rw max-link-bandwidth
>          |  |  +--rw te-bandwidth
>          |  |     +--rw (technology)?
>          |  |        +--:(psc)
>          |  |        |  +--rw psc?       rt-types:bandwidth-ieee-float32
>          |  |        +--:(otn)
>          |  |        |  +--rw otn* [rate-type]
>          |  |        |     +--rw rate-type    identityref
>          |  |        |     +--rw counter?     uint16
>          |  |        +--:(lsc)
>          |  |        |  +--rw wdm* [spectrum slot]
>          |  |        |     +--rw spectrum    identityref
>          |  |        |     +--rw slot        int16
>          |  |        |     +--rw width?      uint16
>          |  |        +--:(generic)
>          |  |           +--rw generic?   te-bandwidth
>          |  +--rw max-resv-link-bandwidth
>          |  |  +--rw te-bandwidth
>          |  |     +--rw (technology)?
>          |  |        +--:(psc)
>          |  |        |  +--rw psc?       rt-types:bandwidth-ieee-float32
>          |  |        +--:(otn)
>          |  |        |  +--rw otn* [rate-type]
>          |  |        |     +--rw rate-type    identityref
>          |  |        |     +--rw counter?     uint16
>          |  |        +--:(lsc)
>          |  |        |  +--rw wdm* [spectrum slot]
>          |  |        |     +--rw spectrum    identityref
>          |  |        |     +--rw slot        int16
>          |  |        |     +--rw width?      uint16
>          |  |        +--:(generic)
>          |  |           +--rw generic?   te-bandwidth
>          |  +--rw unreserved-bandwidth* [priority]
>          |  |  +--rw priority     uint8
>          |  |  +--rw bandwidth
>          |  |     +--rw te-bandwidth
>          |  |        +--rw (technology)?
>          |  |           +--:(psc)
>          |  |           |  +--rw psc?       rt-types:bandwidth-ieee-
>    float32
>          |  |           +--:(otn)
>          |  |           |  +--rw otn* [rate-type]
> 
> 
>          |  |           |     +--rw rate-type    identityref
>          |  |           |     +--rw counter?     uint16
>          |  |           +--:(lsc)
>          |  |           |  +--rw wdm* [spectrum slot]
>          |  |           |     +--rw spectrum    identityref
>          |  |           |     +--rw slot        int16
>          |  |           |     +--rw width?      uint16
>          |  |           +--:(generic)
>          |  |              +--rw generic?   te-bandwidth
>          |  +--rw te-default-metric?                uint32
>          |  +--rw te-delay-metric?                  uint32
>          |  +--rw te-igp-metric?                    uint32
>          |  +--rw te-srlgs
>          |  |  +--rw value*   te-types:srlg
>          |  +--rw te-nsrlgs {nsrlg}?
>          |     +--rw id*   uint32
>          +--ro oper-status?                te-types:te-oper-status
>          +--ro is-transitional?            empty
>          +--ro information-source?         te-info-source
>          +--ro information-source-state
>          |  +--ro credibility-preference?    uint16
>          |  +--ro logical-network-element?   string
>          |  +--ro network-instance?          string
>          |  +--ro topology
>          |     +--ro link-ref?      leafref
>          |     +--ro network-ref?   leafref
>          +--ro information-source-entry* [information-source]
>          |  +--ro information-source                te-info-source
>          |  +--ro information-source-state
>          |  |  +--ro credibility-preference?    uint16
>          |  |  +--ro logical-network-element?   string
>          |  |  +--ro network-instance?          string
>          |  |  +--ro topology
>          |  |     +--ro link-ref?      leafref
>          |  |     +--ro network-ref?   leafref
>          |  +--ro link-index?                       uint64
>          |  +--ro administrative-group?             te-types:admin-
>    groups
>          |  +--ro interface-switching-capability* [switching-capability
>    encoding]
>          |  |  +--ro switching-capability    identityref
>          |  |  +--ro encoding                identityref
>          |  |  +--ro max-lsp-bandwidth* [priority]
>          |  |     +--ro priority     uint8
>          |  |     +--ro bandwidth
>          |  |        +--ro te-bandwidth
>          |  |           +--ro (technology)?
> 
> 
>          |  |              +--:(psc)
>          |  |              |  +--ro psc?       rt-types:bandwidth-ieee-
>    float32
>          |  |              +--:(otn)
>          |  |              |  +--ro otn* [rate-type]
>          |  |              |     +--ro rate-type    identityref
>          |  |              |     +--ro counter?     uint16
>          |  |              +--:(lsc)
>          |  |              |  +--ro wdm* [spectrum slot]
>          |  |              |     +--ro spectrum    identityref
>          |  |              |     +--ro slot        int16
>          |  |              |     +--ro width?      uint16
>          |  |              +--:(generic)
>          |  |                 +--ro generic?   te-bandwidth
>          |  +--ro label-restriction* [inclusive-exclusive label-start]
>          |  |  +--ro inclusive-exclusive    enumeration
>          |  |  +--ro label-start            rt-types:generalized-label
>          |  |  +--ro label-end?             rt-types:generalized-label
>          |  |  +--ro range-bitmap?          binary
>          |  +--ro link-protection-type?             enumeration
>          |  +--ro max-link-bandwidth
>          |  |  +--ro te-bandwidth
>          |  |     +--ro (technology)?
>          |  |        +--:(psc)
>          |  |        |  +--ro psc?       rt-types:bandwidth-ieee-float32
>          |  |        +--:(otn)
>          |  |        |  +--ro otn* [rate-type]
>          |  |        |     +--ro rate-type    identityref
>          |  |        |     +--ro counter?     uint16
>          |  |        +--:(lsc)
>          |  |        |  +--ro wdm* [spectrum slot]
>          |  |        |     +--ro spectrum    identityref
>          |  |        |     +--ro slot        int16
>          |  |        |     +--ro width?      uint16
>          |  |        +--:(generic)
>          |  |           +--ro generic?   te-bandwidth
>          |  +--ro max-resv-link-bandwidth
>          |  |  +--ro te-bandwidth
>          |  |     +--ro (technology)?
>          |  |        +--:(psc)
>          |  |        |  +--ro psc?       rt-types:bandwidth-ieee-float32
>          |  |        +--:(otn)
>          |  |        |  +--ro otn* [rate-type]
>          |  |        |     +--ro rate-type    identityref
>          |  |        |     +--ro counter?     uint16
>          |  |        +--:(lsc)
>          |  |        |  +--ro wdm* [spectrum slot]
> 
> 
> 
>          |  |        |     +--ro spectrum    identityref
>          |  |        |     +--ro slot        int16
>          |  |        |     +--ro width?      uint16
>          |  |        +--:(generic)
>          |  |           +--ro generic?   te-bandwidth
>          |  +--ro unreserved-bandwidth* [priority]
>          |  |  +--ro priority     uint8
>          |  |  +--ro bandwidth
>          |  |     +--ro te-bandwidth
>          |  |        +--ro (technology)?
>          |  |           +--:(psc)
>          |  |           |  +--ro psc?       rt-types:bandwidth-ieee-
>    float32
>          |  |           +--:(otn)
>          |  |           |  +--ro otn* [rate-type]
>          |  |           |     +--ro rate-type    identityref
>          |  |           |     +--ro counter?     uint16
>          |  |           +--:(lsc)
>          |  |           |  +--ro wdm* [spectrum slot]
>          |  |           |     +--ro spectrum    identityref
>          |  |           |     +--ro slot        int16
>          |  |           |     +--ro width?      uint16
>          |  |           +--:(generic)
>          |  |              +--ro generic?   te-bandwidth
>          |  +--ro te-default-metric?                uint32
>          |  +--ro te-delay-metric?                  uint32
>          |  +--ro te-igp-metric?                    uint32
>          |  +--ro te-srlgs
>          |  |  +--ro value*   te-types:srlg
>          |  +--ro te-nsrlgs {nsrlg}?
>          |     +--ro id*   uint32
>          +--ro recovery
>          |  +--ro restoration-status?   te-types:te-recovery-status
>          |  +--ro protection-status?    te-types:te-recovery-status
>          +--ro underlay {te-topology-hierarchy}?
>          |  +--ro dynamic?     boolean
>          |  +--ro committed?   boolean
>          +--ro statistics
>             +--ro discontinuity-time                 yang:date-and-time
>             +--ro disables?                          yang:counter32
>             +--ro enables?                           yang:counter32
>             +--ro maintenance-clears?                yang:counter32
>             +--ro maintenance-sets?                  yang:counter32
>             +--ro modifies?                          yang:counter32
>             +--ro downs?                             yang:counter32
>             +--ro ups?                               yang:counter32
>             +--ro fault-clears?                      yang:counter32
> 
> 
> 
>             +--ro fault-detects?                     yang:counter32
>             +--ro protection-switches?               yang:counter32
>             +--ro protection-reverts?                yang:counter32
>             +--ro restoration-failures?              yang:counter32
>             +--ro restoration-starts?                yang:counter32
>             +--ro restoration-successes?             yang:counter32
>             +--ro restoration-reversion-failures?    yang:counter32
>             +--ro restoration-reversion-starts?      yang:counter32
>             +--ro restoration-reversion-successes?   yang:counter32
>    augment /nw:networks/nw:network/nw:node/nt:termination-point:
>       +--rw te-tp-id?   te-types:te-tp-id
>       +--rw te!
>          +--rw admin-status?                     te-types:te-admin-
>    status
>          +--rw name?                             string
>          +--rw interface-switching-capability* [switching-capability
>    encoding]
>          |  +--rw switching-capability    identityref
>          |  +--rw encoding                identityref
>          |  +--rw max-lsp-bandwidth* [priority]
>          |     +--rw priority     uint8
>          |     +--rw bandwidth
>          |        +--rw te-bandwidth
>          |           +--rw (technology)?
>          |              +--:(psc)
>          |              |  +--rw psc?       rt-types:bandwidth-ieee-
>    float32
>          |              +--:(otn)
>          |              |  +--rw otn* [rate-type]
>          |              |     +--rw rate-type    identityref
>          |              |     +--rw counter?     uint16
>          |              +--:(lsc)
>          |              |  +--rw wdm* [spectrum slot]
>          |              |     +--rw spectrum    identityref
>          |              |     +--rw slot        int16
>          |              |     +--rw width?      uint16
>          |              +--:(generic)
>          |                 +--rw generic?   te-bandwidth
>          +--rw inter-layer-lock-id*              uint32
>          +--ro oper-status?                      te-types:te-oper-status
>          +--ro geolocation
>             +--ro altitude?    int64
>             +--ro latitude?    geographic-coordinate-degree
>             +--ro longitude?   geographic-coordinate-degree
> 
> 
> 
> =====================================
> end of diagram
> 
> ----- Original Message -----
> From: "Lou Berger" 
> To: 
> Sent: Wednesday, October 25, 2017 2:13 PM
> Subject: Re: [netmod] I-D Action:
> draft-ietf-netmod-yang-tree-diagrams-02.txt
> 
> 
>> Hi,
>>
>> This version addresses all known / open issues in the draft known to
>> the authors.
>>
>> The changes are as follows:
>> - Added groupings and yang-data descriptions
>> - Added Comments, Long Diagrams and Security Considerations sections
>> - Clarified representation of schema mount points and representation
> of
>> modules exposed using schema mount.
>> - Miscellaneous editorial changes
>>
>> Lou (for draft authors)
>>
>> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
>>>         Authors         : Martin Bjorklund
>>>                           Lou Berger
>>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
>>> Pages           : 11
>>> Date            : 2017-10-25
>>>
> 
> 



From nobody Thu Oct 26 11:23:01 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6720513F5D8 for ; Thu, 26 Oct 2017 11:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4V21lvdmbGV for ; Thu, 26 Oct 2017 11:22:58 -0700 (PDT)
Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) (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 5636813F442 for ; Thu, 26 Oct 2017 11:22:57 -0700 (PDT)
Received: by mail-pg0-f51.google.com with SMTP id y5so3336082pgq.7 for ; Thu, 26 Oct 2017 11:22:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7ihuhcGrINgRW033TT3K1nJfFfP1DqgzUZpAyB+B3WA=; b=FrSsF5m+7NmRbyDhK9qvU0R1NwahlFnqnCSEfjARfsUpUcZxOQC7ymgqnrhuzLrn8N Prapw8B8CYQDmkYKFGhue+96PmhSRGzOyfINMbOPmrVvANNvKAB+zzV1xvLUlNIpLp9p w+KSpQltnYCxTnVrbU62gYqzUq3HGw0Ed1Ehj9i/E7g/wjM2k8tZXBb2B8S0Wr8x+RZt 54X6WNrk/HEop2QBskaxkfYlKs2ekOJXm3lis8NL3WhgokRfnAR6qdO0VJQyLQF4Zdy+ kPc+yh3qC6DJ1GbIpOX6m1QsiTto5ff3OM2UMEk3xgCR78FSzTBmOUvZ0+jeUTh5wMQc GnVQ==
X-Gm-Message-State: AMCzsaXow6SiVAIt6bqNBws5qTIU+ixe07FjdQ+AJhqjH4lPiQ+JsOq9 +96o8psWtkMJRuMlu8cCDl+Ua0eAiQY=
X-Google-Smtp-Source: ABhQp+SNOGm0Yu/VeDDXSd82zVjPmBhbY+UVW6wXh/oQuqx16bsygtnezRq/VEZwmBA3fWfOSLvlag==
X-Received: by 10.84.244.6 with SMTP id g6mr5148276pll.148.1509042176525; Thu, 26 Oct 2017 11:22:56 -0700 (PDT)
Received: from [192.168.1.102] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id f85sm12586093pfj.5.2017.10.26.11.22.55 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 11:22:55 -0700 (PDT)
To: netmod@ietf.org
References: <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local>  <20171025110851.wdoj2dbrqmxz5shd@elstar.local>  <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>
From: Randy Presuhn 
Message-ID: 
Date: Thu, 26 Oct 2017 11:22:54 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Action and RPC statements [was Re: augment YANG 1.0 with YANG 1.1 OK?]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 18:23:00 -0000

Hi -

On 10/26/2017 10:44 AM, Robert Wilton wrote:
> Hi ,
> 
> Separating out the issue regarding which datastore action and RPC apply 
> to, we propose the following NEW text to the datastores draft:
> 
> 6.2 Invocation of Actions and RPC Operations
> 
>    This section updates section 7.15. of RFC 7950.
> 
>    In YANG data models, the "action" statement may appear under "config
>    true" and "config false" schema nodes.  While instances of both
>    schema nodes may appear in , instances of "config true"
>    schema nodes may also appear in other datastores.
> 
>    An NMDA compliant server MUST execute all actions in the context of
>    .  Likewise, an NMDA compliant server MUST invoke all RPC
>    operations in the context of , unless the RPC is explicitly
>    defined as affecting other datastores (e.g., ).
> 
> OK?

A question - I understand the motivation for the "unless" for RPC
operations, but wonder why there is no similar "unless" for actions.

Randy


From nobody Thu Oct 26 11:28:41 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645BD13F44A for ; Thu, 26 Oct 2017 11:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 UPjOzTMEUkoj for ; Thu, 26 Oct 2017 11:28:36 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0123.outbound.protection.outlook.com [104.47.40.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BC213F448 for ; Thu, 26 Oct 2017 11:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XCpyU0n3evKjq8k1I/K/vF9JOTonuusbkSNmtbc8pyM=; b=FyX+sVy+LcPGy1cBuV/WewcPAU/QRj83xNSGGYHnlHYTmDdKdGqWcLzqG68UnQdy46Bk9uR+6h8nve9IUUABUFWVm28Rh+n8wvCjb/PQhndyW13Y+5wIT8MtjfO1NKXM1q5hYcIftAGbHxN1B1mXjQMmAPUJxE8hARsovcoh+pk=
Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Thu, 26 Oct 2017 18:28:33 +0000
Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497%14]) with mapi id 15.20.0178.003; Thu, 26 Oct 2017 18:28:33 +0000
From: Kent Watsen 
To: Alexander Clemm , Juergen Schoenwaelder , Robert Wilton 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt
Thread-Index: AQHTTY/GCcSGoy8Ln0yx9ksq5tj726L0ixkAgAABvgCAABb3AIAAWnsAgABHGoCAAOzlAA==
Date: Thu, 26 Oct 2017 18:28:33 +0000
Message-ID: <11012066-FD51-44F2-BFEF-BB9CF5A100CA@juniper.net>
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net>  <20171025144222.fyjpong223vhz637@elstar.local> <0D675509-60FA-4EC7-9773-DB2451BDC2B7@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB954F@sjceml521-mbx.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAB954F@sjceml521-mbx.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
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN1PR05MB280; 6:XHEqENwqUpXnqbS3FM6e9CIic6O9fYHVtDFDN1LUfUd8RpPg3vzLXgSM0WMQ0XmnYcRVVXYvQxzreYaYoITEsGg54zVgt5FW4+yTo1UcZ1ZPbf7/zgo+oyxFYcM5Tp7/5Cyl1BaK5TdJeRUyJr8tmEKk/BFL6MRFas3RZpJLkbKDtiAKaanyJtv3pTmlYHtm7fpJYxrmm7YY5MiOokARDxjD1nOADloFblJ2WKyKVGXK4U6F7Cf/v2oLlQm5Q9wXlQHtOyHmuUifPEGKQR6YvhqN+F43gUxeyWkIJxtmEl6j/+8whjZ/lfH5evB0Qy2URg+VqWbhtUNWv/FYcoFFlpSpy8xz7mOqYevwqtAyu58=; 5:kwDJuUqxAwnPCsLLPXWT05eFMzlYeJ/XS8GCMAAZmrnPnSxvTZAXrj0Y7M/D4QsgTTdBQij0RFZ8nkwPRSrBXTlsm/PrO1uBBC/zCidAJ3ylUn12hGlY/5EvbsuecXCdBzI6no10K/bz3Tp70K1rZK4LyrfQRz0Vt80WQiQmgaU=; 24:HiY7a310bftENpO8G3uekaEW7fqiFiPcS8V26QpQ/u3saI/Vzv01ka4dBcYYb1+ov+wUqJOKlMFfrVt0ZCTx7S8KbfuAycBqWyFdcqTQm6I=; 7:phDf198miu42SyI1kuYYo4jm5O7Fjwi+uRrSuP+3TQO5bJHPHlLZ1jYBrFp7YFU0tdkTuHINBFSFgA5CYFRi8G1lds3xWY5W3aXM65bQpdIQNVLBDyil8PtwQsNTew6Yd82KhoRgycFuRAjgF+X32p3GiXQTt7sufUE6eAmENZt/TGkzhjfJkFC51wKZfEjDzp+tRO46IHa1heVuf1RqoZqu9+lwPJCp4tnNpxE555iRGxDuaWg5IlGoXhTMN+46
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 17e9ee73-896a-4326-891c-08d51c9f5d99
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:BN1PR05MB280; 
x-ms-traffictypediagnostic: BN1PR05MB280:
x-exchange-antispam-report-test: UriScan:(10436049006162)(95692535739014);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB280; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB280; 
x-forefront-prvs: 04724A515E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(199003)(189002)(13464003)(54356999)(25786009)(68736007)(6116002)(102836003)(101416001)(3846002)(110136005)(58126008)(76176999)(50986999)(36756003)(5660300001)(966005)(93886005)(5250100002)(3660700001)(81166006)(33656002)(81156014)(8676002)(3280700002)(8936002)(2900100001)(82746002)(86362001)(53546010)(105586002)(106356001)(4326008)(305945005)(575784001)(14454004)(230783001)(7736002)(2950100002)(66066001)(83716003)(6246003)(83506002)(6486002)(6506006)(478600001)(97736004)(99286003)(316002)(229853002)(6436002)(2906002)(189998001)(53936002)(6306002)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB280; H:BN1PR05MB280.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <8A302A2B909E814DABF45AAE85ECF47F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 17e9ee73-896a-4326-891c-08d51c9f5d99
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 18:28:33.6951 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB280
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.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, 26 Oct 2017 18:28:38 -0000

SW5kZWVkLiBUaGVyZSBpcyBhIGxvdCBvZiBncm91cGluZyBleHBhbnNpb24gb2NjdXJyaW5nIGlu
IHNvbWUgb2YgeW91ciBkcmFmdHMuDQoNCksuICAvLyBjb250cmlidXRvcg0KDQoNCg0KSSB3b3Vs
ZCBmaW5kIGFuICBvcHRpb24gdG8gc2hvdyAidXNlcyIgdmVyeSB1c2VmdWwsIGluc3RlYWQgb2Yg
YWx3YXlzIGhhdmluZyB0byBleHBhbmQgZ3JvdXBpbmdzLiAgRGVwZW5kaW5nIG9uIHRoZSBncm91
cGluZ3MgYW5kIHRoZSBhbW91bnQgb2YgZ3JvdXBpbmdzIHJldXNlIGl0IGNhbiBjdXQgZG93biBj
b21wbGV4aXR5IG9mIHRyZWVzIHN1YnN0YW50aWFsbHkgYW5kIGRpcmVjdHMgZm9jdXMgdG8gdGhl
IGZvcmVzdCwgbm90IHRoZSB0cmVlcyAtIHJlYWxseSB1bHRpbWF0ZWx5IHRoZSBpbnRlbnQgb2Yg
dGhpcy4gIA0KDQotLS0gQWxleA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
S2VudCBXYXRzZW4NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDI1LCAyMDE3IDU6MDYgUE0N
Cj4gVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2
ZXJzaXR5LmRlPjsNCj4gUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+DQo+IENjOiBu
ZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIEktRCBBY3Rpb246IGRyYWZ0
LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcy0NCj4gMDIudHh0DQo+IA0KPiBGcm9tIGFu
b3RoZXIgdGhyZWFkIGluIE5FVENPTkYsIEp1ZXJnZW4gd3JpdGVzOg0KPiANCj4gICBJIGRvIG5v
dCBrbm93IHdoZXRoZXIgdGhlIG9mZmljaWFsIHRyZWUgZGlhZ3JhbSBmb3JtYXRzIHdpbGwNCj4g
ICBoYXZlIHdheXMgdG8gc2hvdyBzYXkgYSBjb250YWluZXIgd2l0aCB1c2VkIGdyb3VwaW5ncyBj
b2xsYXBzZWQuDQo+ICAgVGhpcyBtYXkgYWN0dWFsbHkgYmUgdXNlZnVsIHNvbWV0aW1lcywgYnV0
IHRoaXMgaXMgbm90IHdoYXQgeW91DQo+ICAgYXJlIGxvb2sgZm9yIGhlcmUgZWl0aGVyLiBJIGFt
IHRoaW5raW5nIGFib3V0DQo+IA0KPiAgICArLS1ydyBjb250YWluZXINCj4gICAgICAgKy11LS0g
PGdyb3VwaW5nPiAgICAgICAoSSdtIGd1ZXNzICd1JyBmb3IgInVzZXMiKQ0KPiAgICAgICArLS1y
dyByZWd1bGFyLWxlYWYNCj4gDQo+ICAgQ2xlYXJseSwgdGhpcyBpcyBmb3IgYSBkaWZmZXJlbnQg
dGhyZWFkLi4uDQo+IA0KPiAgIEFuZCBJIHdyb3RlIGJhY2sgIkl0IG1pZ2h0IGJlIGhlbHBmdWwg
dG8gaGF2ZSB0aGUgYWJpbGl0eSB0bw0KPiAgIG91dHB1dCBhIHRyZWUgZGlhZ3JhbSB0aGF0IGhh
cyBub3QgZXhwYW5kZWQgaXRzIGdyb3VwaW5ncy4NCj4gICBCdXQsIGFzIHlvdSBzYXksIGZvciBh
bm90aGVyIHRocmVhZC4iDQo+IA0KPiANCj4gVG8gYWRkIHRvIHRoaXMsIEkgd3JvdGUgYSBtb2R1
bGUgcmVjZW50bHkgdGhhdCBkZWZpbmVkIGFuIFJQQw0KPiBhbmQgeWFuZy1kYXRhIGFyb3VuZCB0
aGUgc2FtZSBncm91cGluZ3MuICBBbiBhYmlsaXR5IHRvIDEpIHByaW50DQo+IHRoZSBncm91cGlu
Z3MgYW5kIDIpIG9ubHkgcHJpbnQgcmVmZXJlbmNlcyB0byB0aGUgZ3JvdXBpbmdzLA0KPiB3b3Vs
ZCd2ZSBjb2xsYXBzZWQgdGhlIHRyZWUtZGlhZ3JhbSB0cmVtZW5kb3VzbHkuICBGb3IgZXhhbXBs
ZToNCj4gDQo+IHJwY3M6DQo+IA0KPiAgIGZvb2Jhcg0KPiAgICAgaW5wdXQNCj4gICAgICAgKy11
LS0gPGlucHV0LWdyb3VwaW5nPg0KPiAgICAgb3V0cHV0DQo+ICAgICAgICstdS0tIDxvdXRwdXQt
Z3JvdXBpbmc+DQo+IA0KPiB5YW5nLWRhdGE6DQo+IA0KPiAgIGlucHV0LWFydGlmYWN0DQo+ICAg
ICArLXUtLSA8aW5wdXQtZ3JvdXBpbmc+DQo+IA0KPiAgIG91dHB1dC1hcnRpZmFjdA0KPiAgICAg
Ky11LS0gPG91dHB1dC1ncm91cGluZz4NCj4gDQo+IGdyb3VwaW5nczoNCj4gDQo+ICAgaW5wdXQt
Z3JvdXBpbmcNCj4gICAgKy0tIDxmdWxsIHRyZWUgaGVyZT4NCj4gDQo+ICAgb3V0cHV0LWdyb3Vw
aW5nDQo+ICAgICstLSBmdWxsIHRyZWUgaGVyZT4NCj4gDQo+IA0KPiBUaG91Z2h0cz8NCj4gDQo+
IEtlbnQgLy8gY29udHJpYnV0b3INCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRt
b2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91
PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lGQWcm
Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpV
dlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTFxZ3R1ekdOYjIwYTdwdjZLY01j
UjBCNm5CSVVpUm0tZ0hxNlcxNHplSUEmcz11OXFSLUYwc2pkZWtDWkNsWlpMY1JneFlvVnl1eWl4
dTlNbEs5QU84UUpJJmU9DQoNCg0K


From nobody Thu Oct 26 11:42:32 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D228913F44A for ; Thu, 26 Oct 2017 11:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl6JQlyes0WC for ; Thu, 26 Oct 2017 11:42:29 -0700 (PDT)
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 920D413F448 for ; Thu, 26 Oct 2017 11:42:28 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id 90so4807152lfs.13 for ; Thu, 26 Oct 2017 11:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GgU+Y+TiYNf96p72/RhJYDjurF/ttxnOIc6MwPQPoh0=; b=0jhOjebGPzdUK6AgLVRt42R4RTU3q3SP1BnMV0UTcuLAWVnhddoOMeNpARCKR36vrp PGo/M6atUvVhphDqqVio2Xc1zHZ4gafbjwBXGlILG+zZXWv4nnrezIH2sHVxXn2Gv2JE SPfEmVZ0EBlidZJjuk/jKGe+b+TV2OYSaQqeRW1lSuBiTg6e4zh+rG6F/z74BjTWRtyX ymlgVv4eMEWDhPwSkKBGbO6/GpJ2MAzIzJITuMD/oSaz9cpIZ5yKSF5UwFaSxg7b1khU H6SEgjgpDdQLil09xfLJmMMetSVymuWnKlv0RqjOtrIWeTf8seezcmNlLl/fCnW0xvtW 3aqw==
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=GgU+Y+TiYNf96p72/RhJYDjurF/ttxnOIc6MwPQPoh0=; b=Kw83zZW5Mc0YO6TpEkwQdzmWwV2UjLKoeeBLVz8DOAOgeUfG5NS0aaRO8JuypuSAmG 4jyNn5XZl5GqirjbXrqun3C+v5aazkUjVf7bhkmPwdcPdwi100Jn7NtMhop/LYCtj8jf 3WDWCK5s5ekiJ3C4a3FuSDsmfNhdOareLkvgZGTaXlzgwIIcHzQiQOCDRM+pZl3EjVsZ /71hnlNw7usPfTLs/3SWMepRhtKQuQ9aogR8FhHBzs0OEp6rLduxWLvfCiWtpvBjWolY Oy1FFKuCHDH9jwQCipUVik8hmS4PfJjy/FM3kRPIzC1GCWV73V38xsodEfr03X1uUVYt kkLg==
X-Gm-Message-State: AMCzsaXUTtKK7U+lev9XEnAHx4RsQNucjWnVXH2ntKjwB0MObIfdX1dD KSfkChljUaDm8luZewmKb19ldlx/MZ9m8g8bpNQK5Q==
X-Google-Smtp-Source: ABhQp+SZRRu1Z3tBytHYW1VdoRK2fmqb/oy41UP5cs/mB5YLnOY8ZDvWOqM2VxRTjLGODU3VgmsJYAViLWZPutbCGbQ=
X-Received: by 10.25.23.165 with SMTP id 37mr8256024lfx.202.1509043346848; Thu, 26 Oct 2017 11:42:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Thu, 26 Oct 2017 11:42:26 -0700 (PDT)
In-Reply-To: 
References: <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local>  <20171025110851.wdoj2dbrqmxz5shd@elstar.local>  <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com> 
From: Andy Bierman 
Date: Thu, 26 Oct 2017 11:42:26 -0700
Message-ID: 
To: Randy Presuhn 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11401a04a3d6a9055c7788d1"
Archived-At: 
Subject: Re: [netmod] Action and RPC statements [was Re: augment YANG 1.0 with YANG 1.1 OK?]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 18:42:31 -0000

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

On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <
randy_presuhn@alumni.stanford.edu> wrote:

> Hi -
>
> On 10/26/2017 10:44 AM, Robert Wilton wrote:
>
>> Hi ,
>>
>> Separating out the issue regarding which datastore action and RPC apply
>> to, we propose the following NEW text to the datastores draft:
>>
>> 6.2 Invocation of Actions and RPC Operations
>>
>>    This section updates section 7.15. of RFC 7950.
>>
>>    In YANG data models, the "action" statement may appear under "config
>>    true" and "config false" schema nodes.  While instances of both
>>    schema nodes may appear in , instances of "config true"
>>    schema nodes may also appear in other datastores.
>>
>>    An NMDA compliant server MUST execute all actions in the context of
>>    .  Likewise, an NMDA compliant server MUST invoke all RPC
>>    operations in the context of , unless the RPC is
>> explicitly
>>    defined as affecting other datastores (e.g., ).
>>
>> OK?
>>
>
> A question - I understand the motivation for the "unless" for RPC
> operations, but wonder why there is no similar "unless" for actions.
>
>

The  is not really in a datastore at all.
It may have input and output parameters with leafref and must/when
statements.
These are evaluated in the  context.
The  may in fact be something like 
which has parameters (like  to apply to
a specific datastore.

The action node is embedded within some data that has to be parsed
in a specific datastore before the action is processed.
This data is required to be in .
It also has XPath and leafref that needs to be resolved (same as ).

The side effects of the  or  can impact other datastores.
This would be defined in the description-stmt and this is not a problem.



Randy
>
>
Andy


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

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




On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <<=
a href=3D"mailto:randy_presuhn@alumni.stanford.edu" target=3D"_blank">randy=
_presuhn@alumni.stanford.edu> wrote:
Hi -



On 10/26/2017 10:44 AM, Robert Wilton wrote:



Hi ,



Separating out the issue regarding which datastore action and RPC apply to,=
 we propose the following NEW text to the datastores draft:



6.2 Invocation of Actions and RPC Operations



=C2=A0 =C2=A0This section updates section 7.15. of RFC 7950.



=C2=A0 =C2=A0In YANG data models, the "action" statement may appe=
ar under "config

=C2=A0 =C2=A0true" and "config false" schema nodes.=C2=A0 Wh=
ile instances of both

=C2=A0 =C2=A0schema nodes may appear in <operational>, instances of &=
quot;config true"

=C2=A0 =C2=A0schema nodes may also appear in other datastores.



=C2=A0 =C2=A0An NMDA compliant server MUST execute all actions in the conte=
xt of

=C2=A0 =C2=A0<operational>.=C2=A0 Likewise, an NMDA compliant server =
MUST invoke all RPC

=C2=A0 =C2=A0operations in the context of <operational>, unless the R=
PC is explicitly

=C2=A0 =C2=A0defined as affecting other datastores (e.g., <edit-config&g=
t;).



OK?





A question - I understand the motivation for the "unless" for RPC=


operations, but wonder why there is no similar "unless" for actio=
ns.




The <rpc> is not =
really in a datastore at all.
It may have input and output parame=
ters with leafref and must/when statements.
These are evaluated i=
n the <operational> context.
The <rpc> may in fact be=
 something like <edit-config>
which has parameters (like &l=
t;config> to apply to
a specific datastore.

The action node is embedded within some data that has to be parsed
in a specific datastore before the action is processed.
=
This data is required to be in <operational>.
It also has X=
Path and leafref that needs to be resolved (same as <rpc>).

The side effects of the <rpc> or <action> can i=
mpact other datastores.
This would be defined in the description-=
stmt and this is not a problem.



Randy



Andy
=C2=A0

_______________________________________________

netmod mailing list

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




--001a11401a04a3d6a9055c7788d1--


From nobody Thu Oct 26 11:50:58 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3913F439 for ; Thu, 26 Oct 2017 11:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PBZqLHUJXPku for ; Thu, 26 Oct 2017 11:50:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84B1513942C for ; Thu, 26 Oct 2017 11:50:54 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 9D35E1AE012C; Thu, 26 Oct 2017 20:50:53 +0200 (CEST)
Date: Thu, 26 Oct 2017 20:50:53 +0200 (CEST)
Message-Id: <20171026.205053.2059947918997412077.mbj@tail-f.com>
To: jason.sterne@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] rfc7223bis (interfaces) enabled leaf vs SNMP admin-state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 18:50:57 -0000

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Hi all,
> 
> The issue I'm raising isn't new to the 'bis' version of RFC7223, but
> I'm questioning whether we should consider changing something about it
> while we're in there.
> 
> The 'enabled' leaf has this in the description:
> 
>              Changes in this leaf in the intended configuration are
>              reflected in ifAdminStatus, but if ifAdminStatus is
>              changed over SNMP, this leaf is not affected.
> 
> As an example of "working code", Nokia's SR OS has supported full
> router configuration via SNMP for many years.  When someone enables an
> interface via CLI, that is reflected in ifAdminStatus and vice-versa.
> i.e. configuration via two different interfaces (SNMP & CLI) that use
> different data models, map rw leafs from the two interfaces/models to
> the same underlying internal object.
> 
> In general, many SNMP rw objects will map to the same underlying
> internal rw object as the equivalent rw leaf in a YANG model (for
> products that actually support config management via SNMP as well as
> NETCONF).  Changing the leaf/object via SNMP affects the equivalent
> leaf/object in NETCONF.  Why make this one a special case ?

Note how ifAdminStatus is defined:

            "The desired state of the interface.  The testing(3) state
            indicates that no operational packets can be passed.  When a
            managed system initializes, all interfaces start with
            ifAdminStatus in the down(2) state.  As a result of either
            explicit management action or per configuration information
            retained by the managed system, ifAdminStatus is then
            changed to either the up(1) or testing(3) states (or remains
            in the down(2) state)."

Note the *per configuration information*.  It is clear that
ifAdminStatus is not the same as the "per configuration information".
The config object can affect ifAdminStatus.  "enabled" in the YANG
model is supposed to be that config object that can affect
ifAdminStatus.



/martin


> 
> I'd propose that we remove that sentence.
> 
> Rgds,
> Jason
> 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of internet-
> > drafts@ietf.org
> > Sent: Monday, October 16, 2017 9:25
> > To: i-d-announce@ietf.org
> > Cc: netmod@ietf.org
> > Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-00.txt
> > 
> > 
> > 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 Interface Management
> >         Author          : Martin Bjorklund
> > 	Filename        : draft-ietf-netmod-rfc7223bis-00.txt
> > 	Pages           : 47
> > 	Date            : 2017-10-15
> > 
> > Abstract:
> >    This document defines a YANG data model for the management of network
> >    interfaces.  It is expected that interface-type-specific data models
> >    augment the generic interfaces data model defined in this document.
> >    The data model includes definitions for configuration and system
> >    state (status information and counters for the collection of
> >    statistics).  This document obsoletes RFC 7223.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-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/
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Oct 26 12:11:25 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1726613F5E9 for ; Thu, 26 Oct 2017 12:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 F8Luc_9wLVMc for ; Thu, 26 Oct 2017 12:11:21 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20122.outbound.protection.outlook.com [40.107.2.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC5713F445 for ; Thu, 26 Oct 2017 12:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ljUU9PZdpYWUD60o+xOCMGeTjvOUom0clMskycFkJoA=; b=K5vti6FTroDIq1ZqxKV/imBlK37ScpfMySz3zlbbBQ7sPPBuCQjb5sfv1DrEcqpYV60sJnt5tqFQdooWVXiO6OzTbGz4/MrnUtakuV4tPDmtt3Sifjc08cOTR+TD/Oor5ugUnbcg+F6p3YSIiYnYlcrsQ0ht5yxQYoJWpLanw8U=
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com (10.163.187.158) by AM3PR07MB1124.eurprd07.prod.outlook.com (10.163.187.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Thu, 26 Oct 2017 19:11:18 +0000
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527]) by AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527%14]) with mapi id 15.20.0178.003; Thu, 26 Oct 2017 19:11:18 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP admin-state
Thread-Index: AdNOevP2Ug0r6+CiQ+ipzdRijgA3aQAEGVeAAACr5bA=
Date: Thu, 26 Oct 2017 19:11:18 +0000
Message-ID: 
References:  <20171026.205053.2059947918997412077.mbj@tail-f.com>
In-Reply-To: <20171026.205053.2059947918997412077.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.20.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1124; 6:2qLlBqESjaOBpHUs/Qw45MViix31lO0KgZZblntYwR4ADW2iLUSeHh70p1bK75ox3U1bn40T4UIocW9QMYXm7gsKdziQDY/TnrikbVoOesmNAxFhFqYg+cxIxyX0ALyhX8HvIT9NOacuG00eLNFQmHWNmcKjake4U9H0GT9ETF9t5iryTCWaIWsDFuHCZkYvWjaKUSCtoiZynE/tRFfUcx6v2I9w7t4NlILi0c31VEmdl7lxN6PiFDWM9kK6oiS29HVSzAp6SIXH8Nx/dtcdpnIsE1l4DqEvvQBBG3zeaazhfyUsiVDCRQ/yWx7nq/roS/i0jg5/JVb+fcdgqo1AWjyKQ10HjMeSbCrtjXxAPfg=; 5:W+SByNeLAWB9O6ilSWRop0UxP2c09O5R6Rari4zJBIe7b1ptOgyXzndVRvAtbfHNFN1DRlUikxoxH1M37Ipm5Hq4Tknm4r1E/rq4ZHDp9Sh7LRKa8nVbxE0RqjZ4v/6bAzumEiCaRqPc3hE+iFk4edpwut5flB3NkLTlj7dg7VQ=; 24:ltO56i6o92C440ZTa2bZJQWB/MPgXZa5VtXMIkz0UyP9pYUwf7oB2uWHBmyARFBgymOLxB1wK19eH3LGPytB0jS7fk9T9GyUd19gVkIGa3U=; 7:Z/ht1lyL6fj8A6YrRKrSH0EFWvNQtIEkipSuI+uNXRAVOVmBgqcwjbOacWUTXSuo2EeiwJcb0KBu4v+tPrtElIOYL0cA6swrRBLjWWYZAfoFP4hajhNeqfrd0p+7SJOvkdLmHKoWwVCH8R8SrYWrh59C/ogcJhpGO4ARJ2ZBBKuLk1WSy4H73Q/7tuXCOgZmM2Uma0I4VdOn9pQ/IDWDuMPUfK14tBycxV6stkSSal7qdIRZjETmLROqV4H8fmgJ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 73d2e9dc-e3eb-4c7b-9697-08d51ca55661
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(48565401081)(2017052603238); SRVR:AM3PR07MB1124; 
x-ms-traffictypediagnostic: AM3PR07MB1124:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(3231020)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1124; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1124; 
x-forefront-prvs: 04724A515E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(199003)(377424004)(13464003)(189002)(24454002)(53754006)(54356999)(76176999)(66066001)(50986999)(33656002)(5660300001)(2900100001)(25786009)(2950100002)(68736007)(81156014)(81166006)(8676002)(478600001)(966005)(8936002)(101416001)(7696004)(86362001)(305945005)(7736002)(74316002)(316002)(6116002)(102836003)(6246003)(6506006)(14454004)(6436002)(189998001)(5250100002)(229853002)(6916009)(3846002)(105586002)(106356001)(53546010)(53936002)(3280700002)(6306002)(55016002)(2906002)(99286003)(4001150100001)(97736004)(4326008)(9686003)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1124; H:AM3PR07MB1124.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)
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: 73d2e9dc-e3eb-4c7b-9697-08d51ca55661
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2017 19:11:18.6273 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1124
Archived-At: 
Subject: Re: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP admin-state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 19:11:24 -0000

Hi Martin,

I'm OK with that direction ('enabled' affects ifAdminStatus).  I'm question=
ing the other direction.  I think a change in ifAdminStatus should be refle=
cted in 'enabled'.

Rgds,
Jason

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Thursday, October 26, 2017 14:51
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP admin-
> state
>=20
> "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > Hi all,
> >
> > The issue I'm raising isn't new to the 'bis' version of RFC7223, but
> > I'm questioning whether we should consider changing something about it
> > while we're in there.
> >
> > The 'enabled' leaf has this in the description:
> >
> >              Changes in this leaf in the intended configuration are
> >              reflected in ifAdminStatus, but if ifAdminStatus is
> >              changed over SNMP, this leaf is not affected.
> >
> > As an example of "working code", Nokia's SR OS has supported full
> > router configuration via SNMP for many years.  When someone enables an
> > interface via CLI, that is reflected in ifAdminStatus and vice-versa.
> > i.e. configuration via two different interfaces (SNMP & CLI) that use
> > different data models, map rw leafs from the two interfaces/models to
> > the same underlying internal object.
> >
> > In general, many SNMP rw objects will map to the same underlying
> > internal rw object as the equivalent rw leaf in a YANG model (for
> > products that actually support config management via SNMP as well as
> > NETCONF).  Changing the leaf/object via SNMP affects the equivalent
> > leaf/object in NETCONF.  Why make this one a special case ?
>=20
> Note how ifAdminStatus is defined:
>=20
>             "The desired state of the interface.  The testing(3) state
>             indicates that no operational packets can be passed.  When a
>             managed system initializes, all interfaces start with
>             ifAdminStatus in the down(2) state.  As a result of either
>             explicit management action or per configuration information
>             retained by the managed system, ifAdminStatus is then
>             changed to either the up(1) or testing(3) states (or remains
>             in the down(2) state)."
>=20
> Note the *per configuration information*.  It is clear that ifAdminStatus=
 is not
> the same as the "per configuration information".
> The config object can affect ifAdminStatus.  "enabled" in the YANG model =
is
> supposed to be that config object that can affect ifAdminStatus.
>=20
>=20
>=20
> /martin
>=20
>=20
> >
> > I'd propose that we remove that sentence.
> >
> > Rgds,
> > Jason
> >
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of internet-
> > > drafts@ietf.org
> > > Sent: Monday, October 16, 2017 9:25
> > > To: i-d-announce@ietf.org
> > > Cc: netmod@ietf.org
> > > Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-00.txt
> > >
> > >
> > > 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 Interface Management
> > >         Author          : Martin Bjorklund
> > > 	Filename        : draft-ietf-netmod-rfc7223bis-00.txt
> > > 	Pages           : 47
> > > 	Date            : 2017-10-15
> > >
> > > Abstract:
> > >    This document defines a YANG data model for the management of
> network
> > >    interfaces.  It is expected that interface-type-specific data mode=
ls
> > >    augment the generic interfaces data model defined in this document=
.
> > >    The data model includes definitions for configuration and system
> > >    state (status information and counters for the collection of
> > >    statistics).  This document obsoletes RFC 7223.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
> > >
> > > There are also htmlized versions available at:
> > > https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00
> > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-0
> > > 0
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> > > tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >


From nobody Thu Oct 26 13:42:22 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102C8139567 for ; Thu, 26 Oct 2017 13:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p173XgIGxV21 for ; Thu, 26 Oct 2017 13:42:18 -0700 (PDT)
Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) (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 D101313899A for ; Thu, 26 Oct 2017 13:42:18 -0700 (PDT)
Received: by mail-pg0-f51.google.com with SMTP id m18so3589912pgd.13 for ; Thu, 26 Oct 2017 13:42:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M05odCVu1Hti1tjgLIC2TSBsvR4VNQk7KiWSwyoMsAg=; b=bn6ebwSLC0CZwcI5jJ8K5heL7mP+sGKWa7EjX4pKO18d2UyZGDdlAeCWJZ7EIHVnV5 kQEZmLWhVrqhXwr2IVn3BDpKOv3R+bOCXAkEhnQ1SZvcRoR6kNsSMy7f2/aVOn8edJfs VKgzgsYBF2ygdeMgYYuf5dVMirfNYiy7kAJXP65PTpy0EMGMZBiFb/b4fAPAVP+Gcz1E aRoHbIB4LLdyphtkH9UbgxIkv8LD8kHpdJM1wxwBYUNrKrmEVfUMzgyhn//1BR2ZCJl3 0vkSfqJhBhRN3uxymILTR+0nPFuyiMoF8L7u9rv43FxgkiZ3YhNWCucdQ5YcxAxKyHPR Ye0g==
X-Gm-Message-State: AMCzsaWwnspgPFXnSpqX/8wEN9l0/9o/jWyNgSK4QFMNLjnnW/d8dyRu Ga3JPfBvGupiDPFNGPspeVBfCX+9I9U=
X-Google-Smtp-Source: ABhQp+S4LhNBXK5u9pSQZlKCWuKiLYbEDA9xhVijOak3iFxvzBb/U3G0YlnpySfW/tC/VGHh1xJL0A==
X-Received: by 10.98.65.11 with SMTP id o11mr6706846pfa.86.1509050537753; Thu, 26 Oct 2017 13:42:17 -0700 (PDT)
Received: from [192.168.1.102] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id f7sm9013247pgq.5.2017.10.26.13.42.16 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 13:42:17 -0700 (PDT)
To: "netmod@ietf.org" 
References: <20171015.095206.5556973134711466.mbj@tail-f.com>  <20171018143651.kdsf77r65ptlu4mq@elstar.local>  <20171018213601.hdkt2qtqsno6vr4u@elstar.local>    <20171024172125.l6l3yhocakfkcoh2@elstar.local>  <20171025110851.wdoj2dbrqmxz5shd@elstar.local>  <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>  
From: Randy Presuhn 
Message-ID: 
Date: Thu, 26 Oct 2017 13:42:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; 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: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Action and RPC statements [was Re: augment YANG 1.0 with YANG 1.1 OK?]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 20:42:20 -0000

Hi -

On 10/26/2017 11:42 AM, Andy Bierman wrote:
> 
> 
> On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn 
>  > wrote:
> 
>     Hi -
> 
>     On 10/26/2017 10:44 AM, Robert Wilton wrote:
> 
>         Hi ,
> 
>         Separating out the issue regarding which datastore action and
>         RPC apply to, we propose the following NEW text to the
>         datastores draft:
> 
>         6.2 Invocation of Actions and RPC Operations
> 
>             This section updates section 7.15. of RFC 7950.
> 
>             In YANG data models, the "action" statement may appear under
>         "config
>             true" and "config false" schema nodes.  While instances of both
>             schema nodes may appear in , instances of
>         "config true"
>             schema nodes may also appear in other datastores.
> 
>             An NMDA compliant server MUST execute all actions in the
>         context of
>             .  Likewise, an NMDA compliant server MUST
>         invoke all RPC
>             operations in the context of , unless the RPC
>         is explicitly
>             defined as affecting other datastores (e.g., ).
> 
>         OK?
> 
> 
>     A question - I understand the motivation for the "unless" for RPC
>     operations, but wonder why there is no similar "unless" for actions.
> 
> 
> 
> The  is not really in a datastore at all.
> It may have input and output parameters with leafref and must/when 
> statements.
> These are evaluated in the  context.
> The  may in fact be something like 
> which has parameters (like  to apply to
> a specific datastore.
> 
> The action node is embedded within some data that has to be parsed
> in a specific datastore before the action is processed.
> This data is required to be in .
> It also has XPath and leafref that needs to be resolved (same as ).
> 
> The side effects of the  or  can impact other datastores.
> This would be defined in the description-stmt and this is not a problem.

Thus my question.  I don't see a substantial difference between
"impact" and "affect" when side effects are permitted.  It seems
that the scope of what is affected (think about the consequences
for someone formulating an access control policy) in both cases
MUST be documented in in the description-stmt.  The fact that the
action is bound to a particular chunk of data is only the tip of
the iceberg, and doesn't seem to make a difference in terms of what
the description-stmt needs to spell out.

Randy


From nobody Thu Oct 26 15:19:08 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2513F605 for ; Thu, 26 Oct 2017 15:19:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 UCFyNasBUywk for ; Thu, 26 Oct 2017 15:19:04 -0700 (PDT)
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 7B27A13F46E for ; Thu, 26 Oct 2017 15:19:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2310EEFF; Fri, 27 Oct 2017 00:19:03 +0200 (CEST)
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 stJuLGVFJH19; Fri, 27 Oct 2017 00:19:02 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Oct 2017 00:19:02 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5C272010B; Fri, 27 Oct 2017 00:19:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6xf48g7ST-Cr; Fri, 27 Oct 2017 00:19:02 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BE042010A; Fri, 27 Oct 2017 00:19:02 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B2AC7413EC4C; Fri, 27 Oct 2017 00:17:36 +0200 (CEST)
Date: Fri, 27 Oct 2017 00:17:36 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: "t.petch" , netmod@ietf.org
Message-ID: <20171026221736.cl3kpzo2i7zaa4qh@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 22:19:07 -0000

On Thu, Oct 26, 2017 at 01:32:45PM -0400, Lou Berger wrote:
 
> > But what practical advice can we give them?
> 
> we added section 3.2 covering Long Diagrams in general, and due to this
> draft we added:
> 
>    When long diagrams are included in a document, authors
>    should consider whether to include the long diagram in the main body
>    of the document or in an appendix.
> 
> This is also the recommendation I made to the authors as that draft's
> Shepherd...
> 
> If you have any suggestion on improving the language that would be most
> appreciated.

I think the suggestion is wrong. A long tree diagram should be split
into smaller meaningful pieces to help readers. Moving the diagram to
a different place in the document does not really achieve anything.

I love the way RFC 7317 is written. Sure, the model in RFC 7317 is not
as complex as some of the newer models but still breaking things into
pieces that are explained with surrounding text is where you get a lot
of added value. Yes, there is real work to be done to produce such a
document but as a reader or reviewer or implementor it helps
tremendously with understanding the model if things are presented in
digestable pieces.

/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 Oct 26 15:30:07 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCBE13F623; Thu, 26 Oct 2017 15:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 9TdBPmxXs0uD; Thu, 26 Oct 2017 15:30:01 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B0113F61D; Thu, 26 Oct 2017 15:30:01 -0700 (PDT)
From: Alex Campbell 
To: "dingxiaojian (A)" , "i-d-announce@ietf.org" 
CC: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-ding-netmod-arp-yang-model-00.txt
Thread-Index: AdNOPIiM+GAErL7MSeeuMv3UOyh70wAauoJU
Date: Thu, 26 Oct 2017 22:29:59 +0000
Message-ID: <1509056999180.68991@Aviatnet.com>
References: <3B110B81B721B940871EC78F107D848C01015592@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <3B110B81B721B940871EC78F107D848C01015592@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-ding-netmod-arp-yang-model-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, 26 Oct 2017 22:30:05 -0000

Hi Xiaojian,=0A=
=0A=
* The published module ietf-ip (RFC 7277) overlaps the data being provided =
in this module.=0A=
  Especially your /arp/arp-tables and /arp/arp-static-tables seem to corres=
pond to /interfaces-state/interface/ipv4/neighbor and /interfaces/interface=
/ipv4/neighbor from ietf-ip.=0A=
  I think we should avoid duplication of data where possible; can you refac=
tor this module to augment what is already there?=0A=
=0A=
* Data relating to a specific interface should be inside /interfaces/interf=
ace (and -state) (ietf-interfaces, RFC 7223) where it is possible and relev=
ant.=0A=
  I don't see any reason to have a completely separate list with a leafref =
as a key, when you could use 'augment' to have the data as part of the inte=
rface itself.=0A=
=0A=
* ARP as a feature is not dependent on VRFs, but implementing this module r=
equires the server to also implement ietf-network-instances.=0A=
  If the ARP-related data was under /interfaces(-state) then this draft wou=
ldn't need to rely on ietf-network-instances.=0A=
  The network-instances draft already takes care of making sure each VRF ha=
s a separate list of interfaces.=0A=
=0A=
Alex=0A=
________________________________________=0A=
From: netmod  on behalf of dingxiaojian (A) =0A=
Sent: Thursday, 26 October 2017 10:27 p.m.=0A=
To: i-d-announce@ietf.org=0A=
Cc: netmod@ietf.org=0A=
Subject: Re: [netmod] New Version Notification for draft-ding-netmod-arp-ya=
ng-model-00.txt=0A=
=0A=
Hi all,=0A=
=0A=
The ARP YANG module defined in this document has common properties that nee=
d to be configured.=0A=
It provides freedom for service providers to adapt this data model to diffe=
rent product implementations.=0A=
=0A=
Please have a look and provide comments on the list.=0A=
Thanks,=0A=
=0A=
Xiaojian=0A=
=0A=
=0A=
A new version of I-D, draft-ding-netmod-arp-yang-model-00.txt=0A=
has been successfully submitted by Xiaojian Ding and posted to the IETF rep=
ository.=0A=
=0A=
Name:           draft-ding-netmod-arp-yang-model=0A=
Revision:       00=0A=
Title:          YANG Data Model for ARP=0A=
Document date:  2017-10-26=0A=
Group:          Individual Submission=0A=
Pages:          16=0A=
URL:            https://www.ietf.org/internet-drafts/draft-ding-netmod-arp-=
yang-model-00.txt=0A=
Status:         https://datatracker.ietf.org/doc/draft-ding-netmod-arp-yang=
-model/=0A=
Htmlized:       https://tools.ietf.org/html/draft-ding-netmod-arp-yang-mode=
l-00=0A=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ding-netmod-arp=
-yang-model-00=0A=
=0A=
=0A=
Abstract:=0A=
   This document defines a YANG data model to describe Address=0A=
   Resolution Protocol (ARP) configurations.  It is intended this model=0A=
   be used by service providers who manipulate devices from different=0A=
   vendors in a standard way.=0A=
=0A=
=0A=
=0A=
=0A=
Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.=0A=
=0A=
The IETF Secretariat=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Thu Oct 26 16:02:21 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A2513F48D for ; Thu, 26 Oct 2017 16:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 AIxr5bjuYbaF for ; Thu, 26 Oct 2017 16:02:18 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E99113A296 for ; Thu, 26 Oct 2017 16:02:18 -0700 (PDT)
From: Alex Campbell 
To: "dingxiaojian (A)" , "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-ding-netmod-arp-yang-model-00.txt
Thread-Index: AdNOPIiM+GAErL7MSeeuMv3UOyh70wAccbJ+
Date: Thu, 26 Oct 2017 23:02:16 +0000
Message-ID: <1509058936542.20975@Aviatnet.com>
References: <3B110B81B721B940871EC78F107D848C01015592@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <3B110B81B721B940871EC78F107D848C01015592@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-ding-netmod-arp-yang-model-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, 26 Oct 2017 23:02:20 -0000

Resending as I previously sent this to i-d-announces by mistake and it appe=
ars the whole message was rejected (i.e. it didn't get sent to netmod eithe=
r)=0A=
------------------------=0A=
=0A=
Hi Xiaojian,=0A=
=0A=
* The published module ietf-ip (RFC 7277) overlaps the data being provided =
in this module.=0A=
  Especially your /arp/arp-tables and /arp/arp-static-tables seem to corres=
pond to /interfaces-state/interface/ipv4/neighbor and /interfaces/interface=
/ipv4/neighbor from ietf-ip.=0A=
  I think we should avoid duplication of data where possible; can you refac=
tor this module to augment what is already there?=0A=
=0A=
* Data relating to a specific interface should be inside /interfaces/interf=
ace (and -state) (ietf-interfaces, RFC 7223) where it is possible and relev=
ant.=0A=
  I don't see any reason to have a completely separate list with a leafref =
as a key, when you could use 'augment' to have the data as part of the inte=
rface itself.=0A=
=0A=
* ARP as a feature is not dependent on VRFs, but implementing this module r=
equires the server to also implement ietf-network-instances.=0A=
  If the ARP-related data was under /interfaces(-state) then this draft wou=
ldn't need to rely on ietf-network-instances.=0A=
  The network-instances draft already takes care of making sure each VRF ha=
s a separate list of interfaces.=0A=
=0A=
Alex=0A=
=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of dingxiaojian (A) =0A=
Sent: Thursday, 26 October 2017 10:27 p.m.=0A=
To: i-d-announce@ietf.org=0A=
Cc: netmod@ietf.org=0A=
Subject: Re: [netmod] New Version Notification for draft-ding-netmod-arp-ya=
ng-model-00.txt=0A=
=0A=
Hi all,=0A=
=0A=
The ARP YANG module defined in this document has common properties that nee=
d to be configured.=0A=
It provides freedom for service providers to adapt this data model to diffe=
rent product implementations.=0A=
=0A=
Please have a look and provide comments on the list.=0A=
Thanks,=0A=
=0A=
Xiaojian=0A=
=0A=
=0A=
A new version of I-D, draft-ding-netmod-arp-yang-model-00.txt=0A=
has been successfully submitted by Xiaojian Ding and posted to the IETF rep=
ository.=0A=
=0A=
Name:           draft-ding-netmod-arp-yang-model=0A=
Revision:       00=0A=
Title:          YANG Data Model for ARP=0A=
Document date:  2017-10-26=0A=
Group:          Individual Submission=0A=
Pages:          16=0A=
URL:            https://www.ietf.org/internet-drafts/draft-ding-netmod-arp-=
yang-model-00.txt=0A=
Status:         https://datatracker.ietf.org/doc/draft-ding-netmod-arp-yang=
-model/=0A=
Htmlized:       https://tools.ietf.org/html/draft-ding-netmod-arp-yang-mode=
l-00=0A=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ding-netmod-arp=
-yang-model-00=0A=
=0A=
=0A=
Abstract:=0A=
   This document defines a YANG data model to describe Address=0A=
   Resolution Protocol (ARP) configurations.  It is intended this model=0A=
   be used by service providers who manipulate devices from different=0A=
   vendors in a standard way.=0A=
=0A=
=0A=
=0A=
=0A=
Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.=0A=
=0A=
The IETF Secretariat=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Thu Oct 26 16:03:25 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB0713A296 for ; Thu, 26 Oct 2017 16:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 pAulJkFwNeq6 for ; Thu, 26 Oct 2017 16:03:22 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 675E9139F44 for ; Thu, 26 Oct 2017 16:03:22 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 3DC9A1E063A for ; Thu, 26 Oct 2017 17:03:20 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id SP3G1w00Y2SSUrH01P3Kpe; Thu, 26 Oct 2017 17:03:20 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=qLRM_7iknmYyy--agnkA: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: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=DQKfjcfO/JZkhwBIT4xSiRvJjZSKW1I6wTooRmNaqbw=; b=vAv4uCdoPQLpWcdgp/wA6PPjyx EDPZpWBNiZJ6pxSYbkHp43+VRUnr7mCLZwpNkeatxGDGqObNTE4je4OBiinr5yivEkqUKcxcMtcPr oBAPEgMifsy12mHGgflqO1Skv;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:42874 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e7rBE-002DOV-Ee; Thu, 26 Oct 2017 17:03:16 -0600
To: "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>  <20171026221736.cl3kpzo2i7zaa4qh@elstar.local>
From: Lou Berger 
Message-ID: <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net>
Date: Thu, 26 Oct 2017 19:03:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171026221736.cl3kpzo2i7zaa4qh@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: 1e7rBE-002DOV-Ee
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]:42874
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 23:03:24 -0000

On 10/26/2017 6:17 PM, Juergen Schoenwaelder wrote:
> On Thu, Oct 26, 2017 at 01:32:45PM -0400, Lou Berger wrote:
>  
>>> But what practical advice can we give them?
>> we added section 3.2 covering Long Diagrams in general, and due to this
>> draft we added:
>>
>>    When long diagrams are included in a document, authors
>>    should consider whether to include the long diagram in the main body
>>    of the document or in an appendix.
>>
>> This is also the recommendation I made to the authors as that draft's
>> Shepherd...
>>
>> If you have any suggestion on improving the language that would be most
>> appreciated.
> I think the suggestion is wrong. A long tree diagram should be split
> into smaller meaningful pieces to help readers. Moving the diagram to
> a different place in the document does not really achieve anything.
context is everything:
https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-02#section-3.2


   As tree diagrams are intended to provide a simplified view of a
   module, diagrams longer than a page should generally be avoided.  If
   the complete tree diagram for a module becomes too long, the diagram
   can be split into several smaller diagrams.  For example, it might be
   possible to have one diagram with the data node and another with all
   notifications.  If the data nodes tree is too long, it is also
   possible to split the diagram into smaller diagrams for different
   subtrees.  When long diagrams are included in a document, authors
   should consider whether to include the long diagram in the main body
   of the document or in an appendix.


again, please suggest improvements.

Lou

> I love the way RFC 7317 is written. Sure, the model in RFC 7317 is not
> as complex as some of the newer models but still breaking things into
> pieces that are explained with surrounding text is where you get a lot
> of added value. Yes, there is real work to be done to produce such a
> document but as a reader or reviewer or implementor it helps
> tremendously with understanding the model if things are presented in
> digestable pieces.
>
> /js
>


From nobody Thu Oct 26 16:42:54 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6A213B472 for ; Thu, 26 Oct 2017 16:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 etAQPqPmPKY3 for ; Thu, 26 Oct 2017 16:42:51 -0700 (PDT)
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 77D111389AC for ; Thu, 26 Oct 2017 16:42:50 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 29CAA65B; Fri, 27 Oct 2017 01:42:49 +0200 (CEST)
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 7KUFEw4B0iq6; Fri, 27 Oct 2017 01:42:48 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Oct 2017 01:42:49 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1735E2010A; Fri, 27 Oct 2017 01:42:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YyRa8x_Brgr3; Fri, 27 Oct 2017 01:42:48 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B715D2010B; Fri, 27 Oct 2017 01:42:48 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3FBD4413ED11; Fri, 27 Oct 2017 01:41:23 +0200 (CEST)
Date: Fri, 27 Oct 2017 01:41:23 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: "t.petch" , netmod@ietf.org
Message-ID: <20171026234123.pt65l6ctgmx2hd55@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>  <20171026221736.cl3kpzo2i7zaa4qh@elstar.local> <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Oct 2017 23:42:53 -0000

On Thu, Oct 26, 2017 at 07:03:11PM -0400, Lou Berger wrote:
> 
>    As tree diagrams are intended to provide a simplified view of a
>    module, diagrams longer than a page should generally be avoided.  If
>    the complete tree diagram for a module becomes too long, the diagram
>    can be split into several smaller diagrams.  For example, it might be
>    possible to have one diagram with the data node and another with all
>    notifications.  If the data nodes tree is too long, it is also
>    possible to split the diagram into smaller diagrams for different
>    subtrees.  When long diagrams are included in a document, authors
>    should consider whether to include the long diagram in the main body
>    of the document or in an appendix.
> 
> 
> again, please suggest improvements.
>

Remove the last sentence. Moving lengthy diagrams to an appendix does
not help the reader.

/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 Oct 26 19:21:21 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2258213F4FE; Thu, 26 Oct 2017 19:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMLC1-Z1Px3i; Thu, 26 Oct 2017 19:21:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152ED13968C; Thu, 26 Oct 2017 19:21:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRJ84296; Fri, 27 Oct 2017 02:21:15 +0000 (GMT)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 27 Oct 2017 03:21:14 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.245]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Fri, 27 Oct 2017 10:21:04 +0800
From: Jiangyuanlong 
To: "tictoc@ietf.org" 
CC: "netmod@ietf.org" , Xian Liu ,  Rodney Cummings , Xujinchun 
Thread-Topic: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTTso91J0wdpBQm0ySMhnhc/8WWQ==
Date: Fri, 27 Oct 2017 02:21:04 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97@dggeml507-mbx.china.huawei.com>
References: <150906887826.22201.5033565145094897903.idtracker@ietfa.amsl.com>
In-Reply-To: <150906887826.22201.5033565145094897903.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59F2981B.0066, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.245, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 68bed10d5040c7f7edb6f7d7b4977f73
Archived-At: 
Subject: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 02:21:20 -0000

RGVhciBhbGwsDQoNCkJhc2VkIG9uIGFsbCB0aGUgY29tbWVudHMgd2UgcmVjZWl2ZWQgZHVyaW5n
IHRoZSBXRyBMYXN0IENhbGwgcHJvY2Vzcywgd2UndmUgdXBkYXRlZCB0aGUgZG9jdW1lbnQgdG8g
dmVyc2lvbiA2Lg0KV2UgYmVsaWV2ZSBhbGwgdGhlIExDIGNvbW1lbnRzIGFyZSByZXNvbHZlZCBh
bmQgdGhlIGNvbnNlbnN1cyBpcyByZWZsZWN0ZWQgaW4gdGhpcyBuZXcgcmV2aXNpb24uIA0KTWFu
eSB0aGFua3MgdG8gTWFydGluLCBUYWwsIE9waGVyLCBBbGV4LCBKb2huIGFuZCBtYW55IG90aGVy
cyB3aG8gaGFkIHJldmlld2VkIGFuZCBjb21tZW50ZWQgb24gdGhpcyBkcmFmdC4NCg0KQ2hlZXJz
LA0KWXVhbmxvbmcgb24gYmVoYWxmIG9mIGFsbCBjb2F1dGhvcnMNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy
bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjcsIDIwMTcgOTo0
OCBBTQ0KVG86IFhpYW4gTGl1OyBSb2RuZXkgQ3VtbWluZ3M7IHJvZG5leS5jdW1taW5nc0BuaS5j
b207IEppYW5neXVhbmxvbmc7IFh1amluY2h1bg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp
Y2F0aW9uIGZvciBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNi50eHQNCg0KDQpBIG5l
dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDYudHh0DQpo
YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFl1YW5sb25nIEppYW5nIGFuZCBwb3N0
ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtdGljdG9jLTE1
ODh2Mi15YW5nDQpSZXZpc2lvbjoJMDYNClRpdGxlOgkJWUFORyBEYXRhIE1vZGVsIGZvciBJRUVF
IDE1ODgtMjAwOA0KRG9jdW1lbnQgZGF0ZToJMjAxNy0xMC0yNg0KR3JvdXA6CQl0aWN0b2MNClBh
Z2VzOgkJMzANClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k
cmFmdHMvZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDYudHh0DQpTdGF0dXM6ICAgICAg
ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10aWN0b2MtMTU4
OHYyLXlhbmcvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA2DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFu
Zy0wNg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k
cmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j
dW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gb2YN
CiAgIElFRUUgMTU4OC0yMDA4IGRldmljZXMgYW5kIGNsb2NrcywgYW5kIGFsc28gcmV0cmlldmFs
IG9mIHRoZQ0KICAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiwgZGF0YSBzZXQgYW5kIHJ1bm5p
bmcgc3RhdGVzIG9mIElFRUUNCiAgIDE1ODgtMjAwOCBjbG9ja3MuDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m
IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2
ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJ
RVRGIFNlY3JldGFyaWF0DQoNCg==


From nobody Fri Oct 27 00:44:10 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CAC139982 for ; Fri, 27 Oct 2017 00:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HID4Qs7DOGYk for ; Fri, 27 Oct 2017 00:44:08 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1417138FA0 for ; Fri, 27 Oct 2017 00:44:07 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 21A831AE030A; Fri, 27 Oct 2017 09:44:06 +0200 (CEST)
Date: Fri, 27 Oct 2017 09:44:05 +0200 (CEST)
Message-Id: <20171027.094405.1477743471980617736.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: ietfc@btconnect.com, netmod@ietf.org, lberger@labn.net
From: Martin Bjorklund 
In-Reply-To: <7f3b7f56-2de2-62c2-f9ec-6a010348eeb9@cisco.com>
References: <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net> <7f3b7f56-2de2-62c2-f9ec-6a010348eeb9@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] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 07:44:09 -0000

Robert Wilton  wrote:
> =

> =

> On 26/10/2017 17:50, t.petch wrote:
> > Lou
> >
> > I like the advice that diagrams should be one page long but wonder =
how
> > to apply that to those I see in routing WGs.  I have just been look=
ing
> > at
> >
> >   draft-ietf-teas-yang-te-topo-12
> >
> > where the diagram is 36 pages long - which may be one of the larger=

> > ones
> > but by no means exceptional - and I think the diagram is  more or l=
ess
> > useless as a result.  But what practical advice can we give them?
> 36 pages!=A0 Wow.=A0 It should be split up into smaller chunks, at th=
at
> size I suspect that there is a certain amount of repetition.

Right.  I think we need to think about *why* we include these tree
diagrams in the first place, so that it doesn't just become a checkbox
item for draft authors.  The original idea behind including the tree
diagrams was to give the reader an *overview* of the structure of the
model.   If the tree becomes too large, it obviously doesn't help
anymore.  So what do you do in this case?  I think there are a couple
of things you can do:

  o split the diagram into smaller pieces, and explain each piece on
    its own (see e.g. RFC 7317).

  o make use of "..." to show the overall structure w/o all the
    details.  (pyang --tree-depth might help here)

  o introduce the option of not expanding groupings, as was proposed
    earlier.

I'd rather see a small diagram that explains the structure, but
leaves out the details (they are of course found the module), than a
36-page long figure that can't really be read.


/martin


From nobody Fri Oct 27 00:50:21 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1813713F486 for ; Fri, 27 Oct 2017 00:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtO3yv10BmHk for ; Fri, 27 Oct 2017 00:50:16 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 25370139507 for ; Fri, 27 Oct 2017 00:50:16 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 656961AE030A; Fri, 27 Oct 2017 09:50:15 +0200 (CEST)
Date: Fri, 27 Oct 2017 09:50:15 +0200 (CEST)
Message-Id: <20171027.095015.776466334584979124.mbj@tail-f.com>
To: jason.sterne@nokia.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20171026.205053.2059947918997412077.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] rfc7223bis (interfaces) enabled leaf vs SNMP admin-state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 07:50:18 -0000

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Hi Martin,
> 
> I'm OK with that direction ('enabled' affects ifAdminStatus).  I'm questioning the other direction.  I think a change in ifAdminStatus should be reflected in 'enabled'.

How about simply:

              Changes in this leaf in the intended configuration are
              reflected in ifAdminStatus.

This would allow implementations that separate the two to not update
"enabled" when ifAdminStatus is updated, and allow your implemenation
to do the update (how do you handle 'testing' btw?).


/martin


> 
> Rgds,
> Jason
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > Sent: Thursday, October 26, 2017 14:51
> > To: Sterne, Jason (Nokia - CA/Ottawa) 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP admin-
> > state
> > 
> > "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > > Hi all,
> > >
> > > The issue I'm raising isn't new to the 'bis' version of RFC7223, but
> > > I'm questioning whether we should consider changing something about it
> > > while we're in there.
> > >
> > > The 'enabled' leaf has this in the description:
> > >
> > >              Changes in this leaf in the intended configuration are
> > >              reflected in ifAdminStatus, but if ifAdminStatus is
> > >              changed over SNMP, this leaf is not affected.
> > >
> > > As an example of "working code", Nokia's SR OS has supported full
> > > router configuration via SNMP for many years.  When someone enables an
> > > interface via CLI, that is reflected in ifAdminStatus and vice-versa.
> > > i.e. configuration via two different interfaces (SNMP & CLI) that use
> > > different data models, map rw leafs from the two interfaces/models to
> > > the same underlying internal object.
> > >
> > > In general, many SNMP rw objects will map to the same underlying
> > > internal rw object as the equivalent rw leaf in a YANG model (for
> > > products that actually support config management via SNMP as well as
> > > NETCONF).  Changing the leaf/object via SNMP affects the equivalent
> > > leaf/object in NETCONF.  Why make this one a special case ?
> > 
> > Note how ifAdminStatus is defined:
> > 
> >             "The desired state of the interface.  The testing(3) state
> >             indicates that no operational packets can be passed.  When a
> >             managed system initializes, all interfaces start with
> >             ifAdminStatus in the down(2) state.  As a result of either
> >             explicit management action or per configuration information
> >             retained by the managed system, ifAdminStatus is then
> >             changed to either the up(1) or testing(3) states (or remains
> >             in the down(2) state)."
> > 
> > Note the *per configuration information*.  It is clear that ifAdminStatus is not
> > the same as the "per configuration information".
> > The config object can affect ifAdminStatus.  "enabled" in the YANG model is
> > supposed to be that config object that can affect ifAdminStatus.
> > 
> > 
> > 
> > /martin
> > 
> > 
> > >
> > > I'd propose that we remove that sentence.
> > >
> > > Rgds,
> > > Jason
> > >
> > > > -----Original Message-----
> > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of internet-
> > > > drafts@ietf.org
> > > > Sent: Monday, October 16, 2017 9:25
> > > > To: i-d-announce@ietf.org
> > > > Cc: netmod@ietf.org
> > > > Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-00.txt
> > > >
> > > >
> > > > 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 Interface Management
> > > >         Author          : Martin Bjorklund
> > > > 	Filename        : draft-ietf-netmod-rfc7223bis-00.txt
> > > > 	Pages           : 47
> > > > 	Date            : 2017-10-15
> > > >
> > > > Abstract:
> > > >    This document defines a YANG data model for the management of
> > network
> > > >    interfaces.  It is expected that interface-type-specific data models
> > > >    augment the generic interfaces data model defined in this document.
> > > >    The data model includes definitions for configuration and system
> > > >    state (status information and counters for the collection of
> > > >    statistics).  This document obsoletes RFC 7223.
> > > >
> > > >
> > > > The IETF datatracker status page for this draft is:
> > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
> > > >
> > > > There are also htmlized versions available at:
> > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00
> > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-0
> > > > 0
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from the time of
> > > > submission until the htmlized version and diff are available at
> > > > tools.ietf.org.
> > > >
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> 


From nobody Fri Oct 27 01:17:08 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E010E13942F for ; Fri, 27 Oct 2017 01:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfhAhU4z3Eyb for ; Fri, 27 Oct 2017 01:17:05 -0700 (PDT)
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 36B0213F486 for ; Fri, 27 Oct 2017 01:17:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26842; q=dns/txt; s=iport; t=1509092225; x=1510301825; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jDmJ1O7mtavmlvtacqjBBCIyfOvg/QqT5Ra4K/bRrn4=; b=giH7WU3oRFPtKFxaR42NpfXE1FE6Q/o0OjdyC+K5F3+99QKjpZo18Vhl U0+TPRD64CWszAgUDKmpRN2mdH4yG1kYxwQBzk5HHR9dnXDILvb3Lfv4d EZdet8wNPSm9zJ9VPEFSGA18qopfcxhG3hxREKSuYjyCJjyHdizOonTDU 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AAC16vJZ/4MNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9CLmRuJweDc4ofjxKKSY1zEIIBChgBCoRJTwIahCo/GAECAQE?= =?us-ascii?q?BAQEBAWsohR4CAQMBASFLCxACAQg4BwMCAgIfBgsUEQIEAQ0FiT9MAxUQqQuCJ?= =?us-ascii?q?4c+DYMjAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDLoIHg2KDAYJegXQBEgEHF4M?= =?us-ascii?q?WL4IyBZkBiEU8ApAAhHmCFYYAhAOHFY0XhTuDDwIRGQGBOAEfOIEDZXoVSS0Bg?= =?us-ascii?q?jZJhBZ3iTeBJIERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,304,1505779200";  d="scan'208,217";a="311129783"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Oct 2017 08:17:04 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9R8H3Hi014421 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Oct 2017 08:17:04 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Oct 2017 04:17:03 -0400
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; Fri, 27 Oct 2017 04:17:03 -0400
From: "Einar Nilsen-Nygaard (einarnn)" 
To: "Acee Lindem (acee)" , Mahesh Jethanandani , Kent Watsen 
CC: "Sonal Agarwal (agarwaso)" , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
Thread-Index: AQHTTZQz4R9mVwyDOkCxkCX5K2HeVqL1mc0AgABJnYCAAbx1gA==
Date: Fri, 27 Oct 2017 08:17:02 +0000
Message-ID: 
References:  <880E1C02-2D32-4298-B970-D2D61E2F3C28@gmail.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.1.7)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.242.241]
Content-Type: multipart/alternative; boundary="_000_B944DCDAC8B647BF936D7E0EE0EDFEA0ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 08:17:07 -0000

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

SSBhZ3JlZSB3aXRoIEFjZWUsIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBleGFtcGxlIGhlIG1lbnRp
b25zIHJlbW92ZWQgaW4gY2FzZSBwZW9wbGUgdHJ5IHRvIGNvcHkgaXQuIEJ1dCBvdGhlcndpc2Ug
SSBhbSBoYXBweSB0byBzZWUgdGhpcyBkb2N1bWVudCBwdWJsaXNoZWQuDQoNCkNoZWVycywNCg0K
RWluYXINCg0KT24gMjYgT2N0IDIwMTcsIGF0IDEwOjQ2LCBBY2VlIExpbmRlbSAoYWNlZSkgPGFj
ZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBNYWhlc2gs
DQoNCk9uIDEwLzI1LzE3LCA5OjIyIFBNLCAiTWFoZXNoIEpldGhhbmFuZGFuaSIgPG1qZXRoYW5h
bmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+DQp3cm90ZToN
Cg0KQWNlZSwNCg0KVGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIGRyYWZ0Lg0KDQpPbiBPY3QgMjUs
IDIwMTcsIGF0IDY6MjEgQU0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb208bWFp
bHRvOmFjZWVAY2lzY28uY29tPj4gd3JvdGU6DQoNCkhpIEtlbnQsIE1haGVzaCwgZXQgYWwsDQoN
CkkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhbmQgc3VwcG9ydCBwdWJsaWNhdGlvbi4gSSBoYXZlIHR3
byBjb21tZW50cyBvbg0KdGhlDQotMTQgdmVyc2lvbi4NCg0KMS4gVGhlIHRyZWUgZGlhZ3JhbXMg
ZG8gbm90IGZpdCB3aXRoaW4gdGhlIGRyYWZ0IHBhZ2VzLiBOb3RlIHRoYXQNCnJlY2VudA0KdmVy
c2lvbnMgb2YgcHlhbmcgc3VwcG9ydCB0aGUg4oCUdHJlZS1saW5lLWxlbmd0aCBwYXJhbWV0ZXIg
YW5kIHRoaXMgbWF5DQpoZWxwLg0KDQpJIHVzZWQgdGhlIOKAlHRyZWUtbGluZS1sZW5ndGg9NzIg
YXMgdGhlIHBhcmFtZXRlciB0byBnZW5lcmF0ZSB0aGUgdHJlZSwNCmFuZCB0aGF0IGlzIHdoeSB5
b3Ugc2VlIHRoZSBsaW5lIHdyYXAgYXJvdW5kLg0KDQpJIGd1ZXNzIHRoZW4geW91IG5lZWQgdG8g
bWFudWFsbHkgZm9ybWF0IGl0IHNvIGl0IGZpdHMuDQoNCg0KMi4gV2hpbGUgaXQgaXMgbm9uLW5v
cm1hdGl2ZSwgSeKAmWQgcHJlZmVyIHRvIGhhdmUgYXBwZW5kaXggQS4xIHJlbW92ZWQuDQpJdCB3
YXMgYSBtaXN0YWtlIGZvciB2ZW5kb3JzIHRvIG1peCBwYWNrZXQgZmlsdGVyaW5nIGFuZCByb3V0
ZSBmaWx0ZXJpbmcNCmluIHRoZSBmaXJzdCBwbGFjZSBhbmQgdGhlIGRyYWZ0IHNob3VsZCBub3Qg
aW5zaW51YXRlIHRoYXQgdGhlIG1vZGVsDQp3aWxsDQpiZSBhdWdtZW50ZWQgdG8gZG8gdGhpcy4N
Cg0KVGhlIGV4YW1wbGUgaXMganVzdCBhbiBleGFtcGxlIG9mIGhvdyB0aGUgbW9kZWwgY2FuIGJl
IGV4dGVuZGVkLiBUaGVyZSBpcw0Kbm8gaW1wbGljYXRpb24gdGhhdCB0aGUgbW9kZWwgd2lsbCBi
ZSBhdWdtZW50ZWQgdG8gc3VwcG9ydCBtaXhpbmcgb2YNCnBhY2tldCBmaWx0ZXJpbmcgd2l0aCBy
b3V0ZSBmaWx0ZXJpbmcuDQoNCkkgdW5kZXJzdGFuZCB0aGF0LiBIb3dldmVyLCBpdCBpcyBtb3Jl
IGFuIGV4YW1wbGUgb2YgaG93IGl0IHNob3VsZCBub3QgYmUNCnVzZWQuIERvIHlvdSByZWFsbHkg
d2FudCB0byBwdWJsaXNoIHRoaXM/DQoNClRoYW5rcywNCkFjZWUNCg0KDQoNClRoYW5rcywNCkFj
ZWUNCg0KT24gMTAvMjAvMTcsIDU6MzcgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEtlbnQgV2F0
c2VuIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRm
Lm9yZz4gb24gYmVoYWxmIG9mIGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVu
aXBlci5uZXQ+PiB3cm90ZToNCg0KDQpBbGwsDQoNClRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29y
a2luZyBncm91cCBsYXN0IGNhbGwgb24NCmRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNC4N
Cg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gTm92ZW1iZXIgMy4NClBsZWFz
ZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3QuDQoNClBvc2l0
aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50DQphbmQgYmVs
aWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENClRoaXMgaXMg
dXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KDQpDb3VsZCB0aGUgYXV0
aG9ycywgZXhwbGljaXRseSBDQy1lZCBvbiB0aGlzIGVtYWlsLCBwbGVhc2UNCmFsc28gY29uZmly
bSBhdCB0aGlzIHRpbWUgdGhhdCB0aGV5IGFyZSB1bmF3YXJlIG9mIGFueQ0KSVBSIHJlbGF0ZWQg
dG8gdGhpcyBkcmFmdC4NCg0KVGhhbmsgeW91LA0KTmV0bW9kIENoYWlycw0KDQoNCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBs
aXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA
aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRh
bmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWls
aW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYWdyZWUgd2l0aCBBY2VlLCB3b3VsZCBsaWtl
IHRvIHNlZSB0aGUgZXhhbXBsZSBoZSBtZW50aW9ucyByZW1vdmVkIGluIGNhc2UgcGVvcGxlIHRy
eSB0byBjb3B5IGl0LiBCdXQgb3RoZXJ3aXNlIEkgYW0gaGFwcHkgdG8gc2VlIHRoaXMgZG9jdW1l
bnQgcHVibGlzaGVkLjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp
dj5FaW5hcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAyNiBPY3QgMjAx
NywgYXQgMTA6NDYsIEFjZWUgTGluZGVtIChhY2VlKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVA
Y2lzY28uY29tIiBjbGFzcz0iIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K
PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z
dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25l
OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkhpDQogTWFoZXNoLDxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyIHN0
eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6
IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg
bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp
bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIg
c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6
IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh
Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt
c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v
cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k
ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk
LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9u
ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Pbg0KIDEwLzI1LzE3LCA5
OjIyIFBNLCAmcXVvdDtNYWhlc2ggSmV0aGFuYW5kYW5pJnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJl
Zj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0
LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNv
bTwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv
YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jmd0Ozwvc3Bh
bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p
bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv
cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i
Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7
IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln
aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl
eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h
dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj53cm90ZTo8L3Nw
YW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv
bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6
IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt
aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9
IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo
dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz
cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh
cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg
b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt
dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt
c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KQWNlZSw8YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpUaGFua3MgZm9yIHJldmlld2luZyB0aGUgZHJhZnQuPGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gT2N0IDI1
LCAyMDE3LCBhdCA2OjIxIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgJmx0OzxhIGhyZWY9Im1haWx0
bzphY2VlQGNpc2NvLmNvbSIgY2xhc3M9IiI+YWNlZUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSBLZW50LCBNYWhlc2gsIGV0IGFsLDxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhbmQgc3VwcG9y
dCBwdWJsaWNhdGlvbi4gSSBoYXZlIHR3byBjb21tZW50cyBvbjxiciBjbGFzcz0iIj4NCnRoZTxi
ciBjbGFzcz0iIj4NCi0xNCB2ZXJzaW9uLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoxLiBUaGUgdHJl
ZSBkaWFncmFtcyBkbyBub3QgZml0IHdpdGhpbiB0aGUgZHJhZnQgcGFnZXMuIE5vdGUgdGhhdDxi
ciBjbGFzcz0iIj4NCnJlY2VudDxiciBjbGFzcz0iIj4NCnZlcnNpb25zIG9mIHB5YW5nIHN1cHBv
cnQgdGhlIOKAlHRyZWUtbGluZS1sZW5ndGggcGFyYW1ldGVyIGFuZCB0aGlzIG1heTxiciBjbGFz
cz0iIj4NCmhlbHAuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkkgdXNlZCB0
aGUg4oCUdHJlZS1saW5lLWxlbmd0aD03MiBhcyB0aGUgcGFyYW1ldGVyIHRvIGdlbmVyYXRlIHRo
ZSB0cmVlLDxiciBjbGFzcz0iIj4NCmFuZCB0aGF0IGlzIHdoeSB5b3Ugc2VlIHRoZSBsaW5lIHdy
YXAgYXJvdW5kLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iZm9udC1m
YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj
aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy
YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4
OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp
bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkkNCiBndWVzcyB0aGVuIHlvdSBuZWVkIHRvIG1h
bnVhbGx5IGZvcm1hdCBpdCBzbyBpdCBmaXRzLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5
OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh
cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog
bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0
LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1p
bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n
OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z
Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u
dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4y
LiBXaGlsZSBpdCBpcyBub24tbm9ybWF0aXZlLCBJ4oCZZCBwcmVmZXIgdG8gaGF2ZSBhcHBlbmRp
eCBBLjEgcmVtb3ZlZC48YnIgY2xhc3M9IiI+DQpJdCB3YXMgYSBtaXN0YWtlIGZvciB2ZW5kb3Jz
IHRvIG1peCBwYWNrZXQgZmlsdGVyaW5nIGFuZCByb3V0ZSBmaWx0ZXJpbmc8YnIgY2xhc3M9IiI+
DQppbiB0aGUgZmlyc3QgcGxhY2UgYW5kIHRoZSBkcmFmdCBzaG91bGQgbm90IGluc2ludWF0ZSB0
aGF0IHRoZSBtb2RlbDxiciBjbGFzcz0iIj4NCndpbGw8YnIgY2xhc3M9IiI+DQpiZSBhdWdtZW50
ZWQgdG8gZG8gdGhpcy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+
DQpUaGUgZXhhbXBsZSBpcyBqdXN0IGFuIGV4YW1wbGUgb2YgaG93IHRoZSBtb2RlbCBjYW4gYmUg
ZXh0ZW5kZWQuIFRoZXJlIGlzPGJyIGNsYXNzPSIiPg0Kbm8gaW1wbGljYXRpb24gdGhhdCB0aGUg
bW9kZWwgd2lsbCBiZSBhdWdtZW50ZWQgdG8gc3VwcG9ydCBtaXhpbmcgb2Y8YnIgY2xhc3M9IiI+
DQpwYWNrZXQgZmlsdGVyaW5nIHdpdGggcm91dGUgZmlsdGVyaW5nLjxiciBjbGFzcz0iIj4NCjwv
YmxvY2txdW90ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0
YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt
c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs
OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi
PkkNCiB1bmRlcnN0YW5kIHRoYXQuIEhvd2V2ZXIsIGl0IGlzIG1vcmUgYW4gZXhhbXBsZSBvZiBo
b3cgaXQgc2hvdWxkIG5vdCBiZTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs
dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh
bnQ7IiBjbGFzcz0iIj51c2VkLg0KIERvIHlvdSByZWFsbHkgd2FudCB0byBwdWJsaXNoIHRoaXM/
PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs
YXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy
cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13
ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7
IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y
bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg
Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv
bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0
YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+VGhh
bmtzLDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog
MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250
LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy
dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu
b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp
emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog
c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj
ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog
MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5B
Y2VlPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx
MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt
d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi
IGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6
IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u
dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh
cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog
bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6
IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4
OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv
OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NClRoYW5rcyw8YnIg
Y2xhc3M9IiI+DQpBY2VlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDEwLzIwLzE3LCA1OjM3IFBN
LCAmcXVvdDtuZXRtb2Qgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuJnF1b3Q7PGJyIGNsYXNzPSIi
Pg0KJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+
bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRv
Omt3YXRzZW5AanVuaXBlci5uZXQiIGNsYXNzPSIiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0
OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj
aXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpBbGwsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz
PSIiPg0KVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbjxi
ciBjbGFzcz0iIj4NCmRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNC48YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQpUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBOb3Zl
bWJlciAzLjxiciBjbGFzcz0iIj4NClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG5l
dG1vZCBtYWlsaW5nIGxpc3QuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUG9zaXRpdmUg
Y29tbWVudHMsIGUuZy4sICZxdW90O0kndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudDxiciBjbGFz
cz0iIj4NCmFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiZxdW90OywgYXJl
IHdlbGNvbWUhPGJyIGNsYXNzPSIiPg0KVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZl
biBmcm9tIGF1dGhvcnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ291bGQgdGhlIGF1
dGhvcnMsIGV4cGxpY2l0bHkgQ0MtZWQgb24gdGhpcyBlbWFpbCwgcGxlYXNlPGJyIGNsYXNzPSIi
Pg0KYWxzbyBjb25maXJtIGF0IHRoaXMgdGltZSB0aGF0IHRoZXkgYXJlIHVuYXdhcmUgb2YgYW55
PGJyIGNsYXNzPSIiPg0KSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC48YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQpUaGFuayB5b3UsPGJyIGNsYXNzPSIiPg0KTmV0bW9kIENoYWlyczxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbmV0bW9kIG1haWxp
bmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNs
YXNzPSIiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgY2xhc3M9IiI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyIGNsYXNzPSIiPg0KPC9i
bG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyIGNs
YXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9IiI+bmV0bW9k
QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8
YnIgY2xhc3M9IiI+DQpNYWhlc2ggSmV0aGFuYW5kYW5pPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i
bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiBjbGFzcz0iIj5tamV0aGFuYW5kYW5pQGdt
YWlsLmNvbTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2
ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt
Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs
OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v
bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v
cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt
OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv
cnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6
ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm
b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz
dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl
OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw
cHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250
LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i
Ij5uZXRtb2QNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs
dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50
LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0
LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y
bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w
b3J0YW50OyIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9
IiI+bmV0bW9kQGlldGYub3JnPC9hPjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2
ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt
Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs
OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v
bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v
cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt
OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10
ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv
cnRhbnQ7IiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRtb2Q8L2E+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg
Y2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B944DCDAC8B647BF936D7E0EE0EDFEA0ciscocom_--


From nobody Fri Oct 27 01:33:45 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0054138103 for ; Fri, 27 Oct 2017 01:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dc2J8Nc369Q for ; Fri, 27 Oct 2017 01:33:42 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD99138726 for ; Fri, 27 Oct 2017 01:33:42 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 581CF1AE030A; Fri, 27 Oct 2017 10:33:41 +0200 (CEST)
Date: Fri, 27 Oct 2017 10:33:41 +0200 (CEST)
Message-Id: <20171027.103341.1048835221774842137.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: randy_presuhn@alumni.stanford.edu, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>  
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 08:33:44 -0000

Andy Bierman  wrote:
> On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <
> randy_presuhn@alumni.stanford.edu> wrote:
> 
> > Hi -
> >
> > On 10/26/2017 10:44 AM, Robert Wilton wrote:
> >
> >> Hi ,
> >>
> >> Separating out the issue regarding which datastore action and RPC apply
> >> to, we propose the following NEW text to the datastores draft:
> >>
> >> 6.2 Invocation of Actions and RPC Operations
> >>
> >>    This section updates section 7.15. of RFC 7950.
> >>
> >>    In YANG data models, the "action" statement may appear under "config
> >>    true" and "config false" schema nodes.  While instances of both
> >>    schema nodes may appear in , instances of "config true"
> >>    schema nodes may also appear in other datastores.
> >>
> >>    An NMDA compliant server MUST execute all actions in the context of
> >>    .  Likewise, an NMDA compliant server MUST invoke all RPC
> >>    operations in the context of , unless the RPC is
> >> explicitly
> >>    defined as affecting other datastores (e.g., ).
> >>
> >> OK?
> >>
> >
> > A question - I understand the motivation for the "unless" for RPC
> > operations, but wonder why there is no similar "unless" for actions.
> >
> >
> 
> The  is not really in a datastore at all.
> It may have input and output parameters with leafref and must/when
> statements.
> These are evaluated in the  context.
> The  may in fact be something like 
> which has parameters (like  to apply to
> a specific datastore.
> 
> The action node is embedded within some data that has to be parsed
> in a specific datastore before the action is processed.
> This data is required to be in .
> It also has XPath and leafref that needs to be resolved (same as ).
> 
> The side effects of the  or  can impact other datastores.
> This would be defined in the description-stmt and this is not a problem.

This is exactly right.  We need to capture this in the text.


/martin


From nobody Fri Oct 27 03:00:59 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623D913B138 for ; Fri, 27 Oct 2017 03:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFO8fpQlygzV for ; Fri, 27 Oct 2017 03:00:56 -0700 (PDT)
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 33B5B13AB12 for ; Fri, 27 Oct 2017 03:00:56 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 9A0171E0EC7 for ; Fri, 27 Oct 2017 04:00:55 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id Sa0s1w00Z2SSUrH01a0vbn; Fri, 27 Oct 2017 04:00:55 -0600
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=02M-m0pO-4AA:10 a=j3Z76cjpAAAA:8 a=c4zLxNkgn3jE6x304_QA:9 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=9ZYBcOd_X9kS2t7VFny2:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6AmzWsnf99+EGRNtxBdRfEuNNM7ALhSCR17xW2kX2y0=; b=Diu5iFN7xCrjeP/k+AHHQ4bf2L Q4Isn5gbxFv04duCo7aTBay1URwRL4aIE04+eFffEJnGAT56L2vJ08w6UDQ2kZh4WMC8N9907YvGh pT47O5iJi4rtfAdM3+9Y5SefK;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:54148 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e81Rb-000H8d-U9; Fri, 27 Oct 2017 04:00:52 -0600
From: Lou Berger 
To: Juergen Schoenwaelder 
CC: "t.petch" , 
Date: Fri, 27 Oct 2017 06:00:50 -0400
Message-ID: <15f5d46ec50.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171026234123.pt65l6ctgmx2hd55@elstar.local>
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>  <20171026221736.cl3kpzo2i7zaa4qh@elstar.local> <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net> <20171026234123.pt65l6ctgmx2hd55@elstar.local>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
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: 1e81Rb-000H8d-U9
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:54148
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 10:00:58 -0000

Juergen,



On October 26, 2017 7:43:18 PM Juergen Schoenwaelder 
 wrote:

> On Thu, Oct 26, 2017 at 07:03:11PM -0400, Lou Berger wrote:
>>
>>    As tree diagrams are intended to provide a simplified view of a
>>    module, diagrams longer than a page should generally be avoided.  If
>>    the complete tree diagram for a module becomes too long, the diagram
>>    can be split into several smaller diagrams.  For example, it might be
>>    possible to have one diagram with the data node and another with all
>>    notifications.  If the data nodes tree is too long, it is also
>>    possible to split the diagram into smaller diagrams for different
>>    subtrees.  When long diagrams are included in a document, authors
>>    should consider whether to include the long diagram in the main body
>>    of the document or in an appendix.
>>
>>
>> again, please suggest improvements.
>>
>
> Remove the last sentence. Moving lengthy diagrams to an appendix does
> not help the reader.
>

Keep in mind this is guidance, so autos may include a long tree even if the 
text says don't.  So what do you want them to do if they decide they really 
want a many page tree? leave the long tree in the body???

Lou


> /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 Oct 27 03:06:13 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C620E13A9F5 for ; Fri, 27 Oct 2017 03:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya_X4P1IMiHi for ; Fri, 27 Oct 2017 03:06:11 -0700 (PDT)
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 7BB5013B13B for ; Fri, 27 Oct 2017 03:06:11 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 2A37B1E09F1 for ; Fri, 27 Oct 2017 04:06:08 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id Sa641w01E2SSUrH01a679V; Fri, 27 Oct 2017 04:06:08 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=u07AKapRAAAA:8 a=AUd_NHdVAAAA:8 a=y6juYkxV1VpOikQJWNEA:9 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2F8x7QqmJlob5bKPAsbkVqT7xTPU3VT8P/GqeDchA/I=; b=bLoKJlQHPnxW6wLVYRCvklMG2v NtODfGfdwFxVyPKeV/6IbGML4yUbbC3Xelp3zRCQ5bru2lhAi+withvUgdDkQgjyVSeOJBOny0hDG 4GCmeQ7Kn2+Cl2N+EyrUAq9zr;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:54156 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e81We-000IZz-6x; Fri, 27 Oct 2017 04:06:04 -0600
From: Lou Berger 
To: Martin Bjorklund , 
CC: , 
Date: Fri, 27 Oct 2017 06:06:02 -0400
Message-ID: <15f5d4baf10.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171027.094405.1477743471980617736.mbj@tail-f.com>
References: <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net> <7f3b7f56-2de2-62c2-f9ec-6a010348eeb9@cisco.com> <20171027.094405.1477743471980617736.mbj@tail-f.com>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1e81We-000IZz-6x
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([11.4.0.163]) [100.15.86.101]:54156
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 10:06:13 -0000

On October 27, 2017 3:44:39 AM Martin Bjorklund  wrote:

> Robert Wilton  wrote:
>>
>>
>> On 26/10/2017 17:50, t.petch wrote:
>> > Lou
>> >
>> > I like the advice that diagrams should be one page long but wonder how
>> > to apply that to those I see in routing WGs.  I have just been looking
>> > at
>> >
>> >   draft-ietf-teas-yang-te-topo-12
>> >
>> > where the diagram is 36 pages long - which may be one of the larger
>> > ones
>> > but by no means exceptional - and I think the diagram is  more or less
>> > useless as a result.  But what practical advice can we give them?
>> 36 pages!  Wow.  It should be split up into smaller chunks, at that
>> size I suspect that there is a certain amount of repetition.
>
> Right.  I think we need to think about *why* we include these tree
> diagrams in the first place, so that it doesn't just become a checkbox
> item for draft authors.  The original idea behind including the tree
> diagrams was to give the reader an *overview* of the structure of the
> model.   If the tree becomes too large, it obviously doesn't help
> anymore.  So what do you do in this case?  I think there are a couple
> of things you can do:
>
>   o split the diagram into smaller pieces, and explain each piece on
>     its own (see e.g. RFC 7317).
>
>   o make use of "..." to show the overall structure w/o all the
>     details.  (pyang --tree-depth might help here)
>
>   o introduce the option of not expanding groupings, as was proposed
>     earlier.
>
> I'd rather see a small diagram that explains the structure, but
> leaves out the details (they are of course found the module), than a
> 36-page long figure that can't really be read.
>

I completely agree,  but also think we need to cover (okay, protect 
ourselves from) the case of full trees included in drafts.

Lou

>
> /martin
>



From nobody Fri Oct 27 03:53:32 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CD213F4D3 for ; Fri, 27 Oct 2017 03:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KveYPtisC22l for ; Fri, 27 Oct 2017 03:53:28 -0700 (PDT)
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 CFDD413F46A for ; Fri, 27 Oct 2017 03:53:27 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 78DE0374; Fri, 27 Oct 2017 12:53:26 +0200 (CEST)
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 rOSAmYnc7sf5; Fri, 27 Oct 2017 12:53:25 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Oct 2017 12:53:26 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46D9A2010B; Fri, 27 Oct 2017 12:53:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gFye3FyacMQA; Fri, 27 Oct 2017 12:53:25 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8F272010A; Fri, 27 Oct 2017 12:53:25 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3942E413F7D4; Fri, 27 Oct 2017 12:51:59 +0200 (CEST)
Date: Fri, 27 Oct 2017 12:51:59 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: "t.petch" , netmod@ietf.org
Message-ID: <20171027105159.up6ec5xwbcy75hcr@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>  <20171026221736.cl3kpzo2i7zaa4qh@elstar.local> <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net> <20171026234123.pt65l6ctgmx2hd55@elstar.local> <15f5d46ec50.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15f5d46ec50.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 10:53:31 -0000

On Fri, Oct 27, 2017 at 06:00:50AM -0400, Lou Berger wrote:
> Juergen,
> 
> Keep in mind this is guidance, so autos may include a long tree even if the
> text says don't.  So what do you want them to do if they decide they really
> want a many page tree? leave the long tree in the body???
>

What I am saying is that the value of the diagram does not change if I
move it around. If a plain fully expanded tree dump is not useful
anymore for the reader to get an overview, then other content must be
produced to provide an overview.  And perhaps the plain tree dump is
then not even needed anymore to be present in the document if there is
other good overview material.

We should encourage authors to split large diagrams into manageable
pieces. Sometimes suppressing lots of statistics counters helps,
sometimes showing which groupings are used instead of their expansion
helps. Sometimes it helps to separate major branches of a tree and to
discuss them separately. We should encourage authors to do these
things. Perhaps we need to state clearly that it is not necessary to
include a plain fully expanded tree diagram.

In the case of draft-ietf-teas-yang-te-topo-12.txt, the fully expanded
tree diagram (36 pages) is simply in no good relation with the size of
the definitions (47 pages). And the authors of this document do the
right thing, they provide overview diagrams that leave out lots of
details and that are comprehensible. So is it valuable to keep the
full dump in the document?

/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 Oct 27 04:04:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A0A13F46A for ; Fri, 27 Oct 2017 04:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWlDIHg9IRH5 for ; Fri, 27 Oct 2017 04:04:32 -0700 (PDT)
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 522C013B408 for ; Fri, 27 Oct 2017 04:04:32 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 1467F1E08F6 for ; Fri, 27 Oct 2017 05:04:32 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id Sb4U1w00H2SSUrH01b4XS8; Fri, 27 Oct 2017 05:04:32 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=pRk_hpag8t209Mc66IYA: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=14c5UpmLWbabzXazPFHFrMYJOe7vD4L0+Tcffa9QHmw=; b=das9Y2cG4SA7IXsCrzsP9PepG4 YOUQ7ExPkH45edy2F4IDSL8iUmXeYRLqpnsNhGx3uk1G9frVtSG7IKHtskStVvyU0nco+CB5Gl0WA mDWs5uMM0DD3WDXa+4JQyjhl8;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:46004 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e82RA-000X8m-2d; Fri, 27 Oct 2017 05:04:28 -0600
To: "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>  <20171026221736.cl3kpzo2i7zaa4qh@elstar.local> <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net> <20171026234123.pt65l6ctgmx2hd55@elstar.local> <15f5d46ec50.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171027105159.up6ec5xwbcy75hcr@elstar.local>
From: Lou Berger 
Message-ID: <34dbaaaa-8a06-f980-7bf8-4a54aa117423@labn.net>
Date: Fri, 27 Oct 2017 07:04:24 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171027105159.up6ec5xwbcy75hcr@elstar.local>
Content-Type: text/plain; charset=utf-8
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: 1e82RA-000X8m-2d
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]:46004
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 11:04:34 -0000

On 10/27/2017 6:51 AM, Juergen Schoenwaelder wrote:
> On Fri, Oct 27, 2017 at 06:00:50AM -0400, Lou Berger wrote:
>> Juergen,
>>
>> Keep in mind this is guidance, so autos may include a long tree even if the
>> text says don't.  So what do you want them to do if they decide they really
>> want a many page tree? leave the long tree in the body???
>>
> What I am saying is that the value of the diagram does not change if I
> move it around. If a plain fully expanded tree dump is not useful
> anymore for the reader to get an overview, then other content must be
> produced to provide an overview.  And perhaps the plain tree dump is
> then not even needed anymore to be present in the document if there is
> other good overview material.
I completely agree.

> We should encourage authors to split large diagrams into manageable
> pieces. Sometimes suppressing lots of statistics counters helps,
> sometimes showing which groupings are used instead of their expansion
> helps. Sometimes it helps to separate major branches of a tree and to
> discuss them separately. We should encourage authors to do these
> things. 

I agree with this too, and this was the goal of the current text.
> Perhaps we need to state clearly that it is not necessary to
> include a plain fully expanded tree diagram.
Please propose text for the draft!

> In the case of draft-ietf-teas-yang-te-topo-12.txt, the fully expanded
> tree diagram (36 pages) is simply in no good relation with the size of
> the definitions (47 pages). And the authors of this document do the
> right thing, they provide overview diagrams that leave out lots of
> details and that are comprehensible. So is it valuable to keep the
> full dump in the document?
I personally don't think so, and questioned its usefulness.  I also
suggested moving to an appendix if they really wanted to keep it.  For
whatever reason they decided they wanted to keep it which is, of course,
within their purview.

So, I think the question for us is: what, beyond the change you suggest
above, add to the tree draft to cover cases where authors really want to
include such long trees?

Lou
> /js
>


From nobody Fri Oct 27 04:12:50 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E5B13F4FF for ; Fri, 27 Oct 2017 04:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 AxmFSznX6wpz for ; Fri, 27 Oct 2017 04:12:46 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0136.outbound.protection.outlook.com [104.47.1.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D1C13F4F0 for ; Fri, 27 Oct 2017 04:12:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=z5TV1+EOrjzH6Ry54c0diwyh8O420U2MZYRk92mxfv0=; b=Lf4FAX8qfJnaxYlT6b45lZpQKDTTdof7nBSaCPQ3wz//VCObGaHqbomE7f8YMW8FA0xwFlZIM1BGYsqvQWbwgbwz0dII1xXDb8H4YKbfhmxaIYZZBgQDEOhM69pls0dQR1d9RfQeNw5awITgkCDZSe2Ig9hiViMY1Z+8CCLEtLg=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.169.153.236) by AM5PR0701MB2995.eurprd07.prod.outlook.com (2603:10a6:203:48::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Fri, 27 Oct 2017 11:12:43 +0000
Message-ID: <03bb01d34f14$2907e5c0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "Lou Berger" 
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net>
Date: Fri, 27 Oct 2017 12:08:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: DB6P189CA0008.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::21) To AM5PR0701MB2995.eurprd07.prod.outlook.com (2603:10a6:203:48::17)
X-MS-Office365-Filtering-Correlation-Id: e81b9020-6c4a-48ba-dbd1-08d51d2ba550
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM5PR0701MB2995; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:VMFvUg07Q4gz5AqoZjg6iLNCUa7OzNmB+4GYHWZfAFRRHT9aJXhD2U/9bV8pfTS7lRriqFm0fqIZxuQ859g7gSttiN5KbAznOJSbflpHL7iiCLkk+5sbvBQORyT6k+eZVV+vGJkRVu32EJnTAFkNvzFVMuFRiIVXvGOKyRaFP8Odr44qU6GhVF8qXIo0vPrGwppMPGt+eMYI8t0qjLq7rttD0C+wxNKSeZw/LfAJHvlhQjmhXLdaI9gSmgbod3Y2; 25:zhFwbnrleb50xZKq+LFSN3y4mXz8kTOQSTUtxXZaiez0hsOmV/Sv9eS7SHEhBo0ev5i/HzqSRRv35QU0zkvOuRQ7KU91Nt3Jh5uLjLMLknT5LKfSxQhPA075yyL9EOzmOIcdMnOLEJGBbTsISiAAA3pqkI7si64LUvSPHNKh1G97AH7paYHCFdYnCtvtFTVyEGBJBF4ynz7TN/kwU3mxLoAFraY4pcN4HK6GFro+afV8VoMABB0Qayw064vQItKgz+A3PvVrUmBvA9/ilUje/OStrV3oYurlEAO+W9l1xR4LF5lblYc5Ej0N+FBMqHhfwvPNkb1wG+PEfeMo1Y5o2w==; 31:pRvpPQ+3XLVxoL9WNxWi8uyKwoYotBi2Q32+u3EyPINfmblF+sESHhyU7jtq6KvWI0kosjOqNy9PWcglJY/uDdi3wn89W0D5MJBdMs82xE3gJhzMktciFWnoWOcDdPvA40K1vpUkFQDnjFPaW0i7JdQPNTM+cTr/6VeOJOVmFd+dD8yBBUZVWD2nkShSqO+O/VqH1Is6lKyrAH7/slnycW7Kvv7rmTyZgcFBaeqtqaE=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2995:
X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231020)(100000703101)(100105400095)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2995; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 4:B8BC9PeDEdBPAFm3IqFgSXJoJWx2f6CigLzpnFj0qYXKfWCuLecKQwFOLEzdOI/Q+p3ckOjTCCDI6EgAWgNUxSBtPcZWcXux8TpRXQ2G7JTJ33AD3gS9CoV/9VcvFQwL5jR38Q1mjl5/IKbiTPe8zKntnv1uY8XwtscO3iZQjG1qZ8+BXyQn8f8041pQp0oXWdEqPO+kkenL+6wW8JGO8JP8YkLsF6m4K2569ELB1XFbkKr/MSvU+zTgeVbhAna0SPEDTAEafFySOiagi0eDS6zWMHrLeWs0ZLnv5+niA/Gi3K8jQhp4Hs7bvWwURNMX+mky9/zIjzxGnT31wQOe0YgnW2RKUh1Xbyl2HWrJxkY=
X-Forefront-PRVS: 0473A03F3F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(24454002)(199003)(377424004)(13464003)(2906002)(68736007)(6246003)(230700001)(4001150100001)(966005)(8676002)(1456003)(1556002)(44736005)(50226002)(4720700003)(61296003)(81816999)(81686999)(110136005)(76176999)(50986999)(229853002)(6496005)(53936002)(6486002)(97736004)(316002)(101416001)(50466002)(25786009)(478600001)(84392002)(6666003)(53546010)(5660300001)(116806002)(105586002)(7736002)(62236002)(8936002)(44716002)(106356001)(47776003)(305945005)(66066001)(16526018)(23676002)(6306002)(189998001)(81156014)(81166006)(9686003)(230783001)(3846002)(6116002)(33646002)(14496001)(86362001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; 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?MTtBTTVQUjA3MDFNQjI5OTU7MjM6VS96WkVmTzYxV0FydkZEUzRVMlVodkdK?= =?utf-8?B?NktDNTVPOTdkZ3d0SCt1cTg0NlpTWkkxeWY0WVAzdWluSnpGZytDZVZZRTAw?= =?utf-8?B?T0sveWtxcWRYZTdiOWVQNW05eXZSa0dsSGRvSU8zVElvQUZITHZSbDdQaC90?= =?utf-8?B?bGd3QmxlSTVBZkxIZklBelpCU25uWHJ1c0tzVlc2NWxyWStxZytHQm9JNVUr?= =?utf-8?B?V1BKSGxhNzFKZG4rY1M3dnZEUGtKK2pHWTl3MytQZnNBRjNlblZnWis3RGxD?= =?utf-8?B?eitJS0VYQkhHVG1xWEtwUm1heUtVbHladlUyZUpmU2NFTHcrSEV4MEh6YVly?= =?utf-8?B?UXZuYm1pWlZVeHFONW40QytmNldKNTRjMjVYME5lSHZCL1VyTmNpcXA1WElr?= =?utf-8?B?RFduVDlocnVXczVWUlRxb0ZKYm9TbjRWQ0ZpZzdaN2x3VDMzYUZIS3g1R2w0?= =?utf-8?B?S0NSL3RqV0RjdlcreTBVT0lnWXF0OUpZSkl6ZmR0YjJEWXlHSWZmNExqNTIw?= =?utf-8?B?UlZ0bVJ2NjM5QmNqdDFzZW1MY2cwanB6Y01nY0krN290OUh4WnFzeUpFdnEz?= =?utf-8?B?RjA0Wm50ZFV0aTRzRDdBeS9LSDFWaVk4QjZBV2dFOGVnQzA0Q3c0ZENJL1dW?= =?utf-8?B?Rlh1YW4yVnZ6T3hJeHVrOU0rMjB6ZGtzUUhLRWRmTG40TElRVTBwNUE2SGJo?= =?utf-8?B?TjlCdDFzMW91UzVZMzBKbUZJUjVZM0JCUUFyNW1oVXNrOVcxRnJQRWpnNVdZ?= =?utf-8?B?L3UwcFRoZzBRQ0hEM0ZlRHEyUVdhTk1SQnByYW8yaEVZKzAzTUptQW1iN0Zx?= =?utf-8?B?d2grem41Y2hPN3QrYm9mM3h3cURORlluR2FLN1YxKzlwMWxOcEdJcG1oZEgz?= =?utf-8?B?Z3QzVmliMEdScitsNVFaVlhIdlByVVJsNmR1R2tteXgxeFRxUitBNFUzSmpS?= =?utf-8?B?NTRucTcrM2FHTlBFbU9ldkVTaVF6RDJpaEVESTQ3R01YVVNNMFVsTUZFaXRL?= =?utf-8?B?WE4rSE1lY05mZFczNVBZeS9Hbng4ZklPWWlRTGZpTVFxaGRXTVRmTmdsb09k?= =?utf-8?B?TUp0VUY2bU5KSjA4b0lkNHkvR0pEbGxDbXNrMit2ZHBiTUFqV1N6SHRVcllh?= =?utf-8?B?ekJvQ1o4NUpIMTBjYUFmUTdXZkdIYjVuK2JkNVczNE9Qd0tONnJYckFtZUs1?= =?utf-8?B?enlaQkt4SlpSR3BTTzlJZ2FpejVDNkNSRkhqWWQvTGRlTjRsWEdPcDdJUGp1?= =?utf-8?B?ajhabDRSdmRDaEYxazR3UHl0eDVPYm5MOXhFcTlkRGpyYWU3YzUvUk0zYXZY?= =?utf-8?B?eXpML0hIZW1zNFF0ckJLd0gyd2JrRzBJOEl2eGU2b0liMlNhOU83VkJLNjA2?= =?utf-8?B?OTV2aDRxVGNvRndaeHRiSmpRTFZLZUpFcTcyREQyNUFNMGNZYlAwT0Rua1RE?= =?utf-8?B?UGZOU0RjYVJlSFF1blZUckZYcTI5MTkyR2NpQXFBcDd6cVhhV3ozRDB0YUda?= =?utf-8?B?am5OWGlucml1d1B0eVB4SDVtUXFuS2I2Ry8zZ3NaVFZGM0xqZmlZSzlMTVRv?= =?utf-8?B?QjZpNjZpVmJUb0VmUnJGd0RYbUdIaDhKV0cyVVpISlF4Tk0vRlNBY3ZVeVQ3?= =?utf-8?B?RVJBdzM2MXhLMEEycVFOTC9mOHkwUDRJRjh6Rk5OYWw3WnNvSTdnTkpiK0ZB?= =?utf-8?B?bUw4TE9MT1czN2JHbEhMWWNBMGdCdDdScjd5ZHFOaEFXN2ZDMXp1cTFYV3pH?= =?utf-8?B?eEp3OHpTSnlmODYwR2lxRUpTRXdtRm5oNWZnZ3dOZ0tWak1EemF5MVVHTUFF?= =?utf-8?B?cDB4YWt0RXVrZUdoUTNTSTZpQ0dOdmtmSVlwQ2pVOTRseS9iVVVJQjhRTEhJ?= =?utf-8?B?ekU1RmxPdDQyTXJmWWpJa29NNEZrOG5hR0xjSDNCR3VYdnppYXdiMG5Fd2NR?= =?utf-8?B?Uy9YMG5Ub3UxL081TXEycXArd09kTDNSTVV1TnZUK3VTWUJpVkZPQkIvNDR0?= =?utf-8?B?blFTZ0ZxTkZEL3ZYc3JNSTBib1ZSR2dhSlpON1duWWJHYjRSdWNaOVRzR1BT?= =?utf-8?Q?eA/Cno=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 6:EPPScyfiCLvu9RAbm2QD0goo4X4nmxgPsOwkXHVJwNMIHHCGP6CBUq1tbuoY16mmisYr8QrcdEyG+1OT/itBrQf4MFSQ9ZdnZIUZVrDNAjkWV0hYmOt0wFdaYY3FZTtwnyCCyG9hUbKuNr2ERrzN7NjoMH+TbR7aiHDENdNryl5bYhVywNBVr4iR36KeNvztqyRMaepZn+/ZkF4Rle7hBllS5iNAMSQvY/zmVYe0QDLNCK2AAjOPrt3q9pE5ukelqNpObVgwDckEVtssOBdB9NTmrsewx6XTRBwSwAoYihqqUyOBmBu9ro6wc+drpwXmVlTl2Re6KQiU0bD9DKYmcExFyBtnKiv2rliw3eQY6qo=; 5:QcbxxO7hm5GMS8BXavs350KJ2Qh8XL0wFpX9IBqPfxR8PC0sTmL/4Gx0wDXhwDPNbQqQqU1LkpOJwaINn7N4N1HlFF8fLNd0xIJOv3DpFskfpEFr5Las288+mpWtbbbUKLEztMDc66tynM9wXG3OWtHNQF5d/2nS3FhLD8Kd0/w=; 24:s/BVNJwSjASuAZehOC/Ym0MWbnXw3RJLGD59ff6rPo6vzEx0eMs0SGN5QCKRezm1hiDaRcjRl9RO5ptOdI8X0BNBIab5ndKx9T0uN4j9Pdc=; 7:lIKBGOj8J0t6vbe63Ax8j4b0+tYNDP4wwMM6v78BDostFa1cjWJ8tKbu1/3k4hlqdM0P4amaYgoVs+8EiNfxl7X0ry0XJfLSHARqGMU8o/fITr9WbOtEfgno+seaHWYQ2CM8s9m1Gk0P/EX7PVsqrExhjzPcaLVibeAoE/NJoAWWPKDVkiDQHvwbmJQnvrVN9IxeAoMO94y17/fRfr+nLxV/MK95MHztD7vW+ORUPrR0/XadJKXsDZrNv0Ctp/km
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2017 11:12:43.4007 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e81b9020-6c4a-48ba-dbd1-08d51d2ba550
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 11:12:49 -0000

Lou

On a slightly different tack, so a slightly modified Subject: line,
when an I-D contains multiple modules, some place all the models
together and then all the modules, e.g.
draft-hares-i2nsf-capability-data-model-04 while others intersperse the
models and the modules, e.g. draft-ietf-lisp-yang-05 .

I think the former is superior and should be recommended, especially
when, as Sue has done, there is a brief paragraph of text before each
model, so it is very clear where a model ends and another begins.  With
the latter, models can be hard to find.

I see this as dovetailing into Juergen's comments on RFC7317 which, to
me, is really several separate modules packaged as one, so the
separation makes excellent sense to a reader.

Where the I-D is already several modules, then do as RFC7317 has done.

Tom Petch

----- Original Message -----
From: "Lou Berger" 
To: 
Sent: Wednesday, October 25, 2017 2:13 PM

> Hi,
>
> This version addresses all known / open issues in the draft known to
> the authors.
>
> The changes are as follows:
> - Added groupings and yang-data descriptions
> - Added Comments, Long Diagrams and Security Considerations sections
> - Clarified representation of schema mount points and representation
of
> modules exposed using schema mount.
> - Miscellaneous editorial changes
>
> Lou (for draft authors)
>
> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
> >         Authors         : Martin Bjorklund
> >                           Lou Berger
> > Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
> > Pages           : 11
> > Date            : 2017-10-25
> >
> > Abstract:
> >    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.
> >
> >
> > 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-02
> >
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagra
ms-02
> >
> > A diff from the previous version is available at:
> >
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-0
2
> >
> >
> > Please note that it may take a couple of minutes from the time of
submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Fri Oct 27 04:12:57 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7468513F4F0 for ; Fri, 27 Oct 2017 04:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 zx9f7lgO8BsV for ; Fri, 27 Oct 2017 04:12:47 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0136.outbound.protection.outlook.com [104.47.1.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A346013F4F4 for ; Fri, 27 Oct 2017 04:12:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yK5ikzbdl/yHtZQd5Ol+fPXMXybsG1MKcoqDNIlxnMA=; b=imAnM8KrDx5NW+mfOe5P99e+tjfUcwsESh8nB+H/2ObTBzHFl9l1QZSJpp5VV/pk28d1vvzVON0j/aU/eiY9DkqxgNzlyreCnDelvSSq50a5wb8+tdoSLcDuLKRdEoONUVFH6YAL7E433CShiiB4kdSGYAlDMGY9H7q0ePyKG5A=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.169.153.236) by AM5PR0701MB2995.eurprd07.prod.outlook.com (2603:10a6:203:48::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Fri, 27 Oct 2017 11:12:44 +0000
Message-ID: <03bc01d34f14$29850500$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Mahesh Jethanandani" 
Cc: , "Lou Berger" 
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net> <122E6B31-38CA-47DD-8891-A79D3BC8BCC7@gmail.com>
Date: Fri, 27 Oct 2017 12:10:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: DB6P189CA0008.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::21) To AM5PR0701MB2995.eurprd07.prod.outlook.com (2603:10a6:203:48::17)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d64e3a5b-3359-47dc-7400-08d51d2ba5ca
X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:AM5PR0701MB2995; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:6Kbu+0bxPCfvIIw8mwNFm9XdF2aDXy45jiIEoPxxgr/0T9d0HVAq5nK67g35a3QflgkjwzfnBBomRbdHzAH7bbo6wlNDW/Jw+By0j495l3uSf3qnpnQx41cU4ymVXLwq2gkIB4cUHmBZWQeHnLrgShmqQrhTPcoKdltUrQYb8mr/VyTaAXpAI8UYTwxmAniZHlvDgabSPiTKRBST9YIomZHgGbCV/mZaZrDX6c4ZU6Q0RXN/dVPjILl+3upcWCdM3eN0Vj0tqRWdMbgu1kpW1+WzmLc2sSueHV0uWT9EUuE=; 25:26EUjR2QBWNgipgsxkmtzr245jWJvRVZIyv+59ycb4/1KzP+MghBZXo1w5jrzUs4Jcfw/LGRe6hsaiDVSnRCQzeuCJ/DEp5as7+tD5JyElvvk5/wwdWYIMrbl2xxDqImWvBCvTAM+gkaNpX9Rby+pMiYFNxwvfnNztAVMzhq2dEBKEFFapgUuwk63TiB6eLTVOxaFj4yNpeDBCcVO/HbS95ykWNtlfvhzobCwAUM61YItnMpItWKI3O6fm+Y0f6PBBQVLVKKP2I2s2JOzH03SDxjl2ZvuW0/sEmPH9OPqL0oaTpsozgqiAJ8K41av0br8H75WYcOP5wKhpc1sxDxgg==; 31:O1qqUypvmHJA/yMy5tVy+D2EKET8dsBqR3Z6akhk34qz6hTaRIFWz4ymVvw/ESh8smnABNdmM0GlJVt7T76fKfTm/HO0C7q82xaqTq6hIifP2Ldwf2FJTlM3qdQvNC5CalWzIjhYQeZM367Ewin0Vcotw8nhk/jkz3Yd9yyxzxFu06Iw7coyOfBZjC9YxPvBw+RvtV6bqzzvz3pdDwGeTmEbVMjbK64/I5IQS1he3e0=
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2995:
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(192374486261705);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231020)(100000703101)(100105400095)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2995; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 4:5xLxyn4IxIZAVXDnR9yJrn24lNIzP6/2/t2NfCxFWdssT2LnNSbACv/KYZifgy4M/vgCD0JYPbC+mYEsV17Ep6Zbrpyh5BErJ/Ui/npamuoM/kFY7Qmaf8Orx1GJJNRoZCA9T08YBuTp1RafhGh/TmEsvUoRe6a/6zS7qp3nAsfKdGQZa/MP3z9czPQ+MGYQQUbh2R/HvkCcqsEQV/JZsfFJQH3BWpx/qPAlEdVzhp9PY6eG/lMgeB+MGkr3o0/zOBF0WZdnikSC47UHd1dxUOT2pprDXvdwcN20N4xB9dVYAVT8ZrcHIs2/q3kKwcBoExD80u66cgT9BX37SeVMuxEVe7rGIUnayBJcObUKYjk=
X-Forefront-PRVS: 0473A03F3F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(51444003)(189002)(24454002)(199003)(377424004)(13464003)(4326008)(2906002)(68736007)(6246003)(4001150100001)(966005)(8676002)(1456003)(1556002)(44736005)(50226002)(4720700003)(2870700001)(61296003)(81816999)(81686999)(54906003)(76176999)(50986999)(229853002)(6496005)(53936002)(6486002)(97736004)(316002)(1411001)(101416001)(39060400002)(50466002)(25786009)(478600001)(84392002)(6666003)(53546010)(5660300001)(116806002)(105586002)(7736002)(62236002)(8936002)(44716002)(106356001)(47776003)(305945005)(66066001)(6916009)(16526018)(23676002)(6306002)(93886005)(189998001)(81156014)(81166006)(9686003)(230783001)(3846002)(6116002)(33646002)(14496001)(86362001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; 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?MTtBTTVQUjA3MDFNQjI5OTU7MjM6TW5SUGhuN1FxWTlxRGRPNU5EMlV4Tm5E?= =?utf-8?B?YloxRTJzL0JoMWprODJiMHNvblFLa0RYZDdqYzRhcUJwcE45K2JHYVA2UmJ2?= =?utf-8?B?VkVQdEJZSXQ4U1lKV3JMOU9WRFE2T1IvK0EyUnJrL3JJSDlRN3NBelpVZ3Vm?= =?utf-8?B?Umwrb2JJWW1rcW45REtjZEwxdzdRZ2w5VU11YXJIc01iOXh4ZnNXdW5MZVcw?= =?utf-8?B?Tm1HYjR1L3dOWlAvR29paFF5K2w0Mm10SnBQdnR4eXpzTXZRNkptUGtIWGRm?= =?utf-8?B?REJCN0R2K1ptMXlPd3MweGVNS01QdHBYYmZLT0dObjk1dUVRZVRGMnZPUWRK?= =?utf-8?B?cXF6bUJVVEpTU09QZDJLdFdtUFNYUytjVnI1OWxNM0JSNHQ2dXQ4MHlBT202?= =?utf-8?B?MVVXazdYVGFCSnNhb01tcjZKTEZucEozTTZvbUk2alNaaHd2L25nVEY3cm1l?= =?utf-8?B?cS9JZmpmbFpMUmdsN2VPdlVrM0t1ZVJDRmFZdzRyZE5aa3VmWisyQnVRaFlr?= =?utf-8?B?WEd4MHNHMWY2QXNQV0UwWlJlaC8ybVdRSnhBUFJ1VVlWMVozQVI0WCswQ0Zq?= =?utf-8?B?MlcvS2JJVGhtenNJcG9xdjI4QkJIOXNzdmYzaHhnMXdnUThtdE12Ym96NFRo?= =?utf-8?B?cGVDRk1UUFBNK29JYTNjMnNiOGFPV1BpOTM1Z1RibEtONXJYM210WXFjdXhI?= =?utf-8?B?TnJJdjBPc3ZxYlRXWXlMdG1qYitueXVLOHpoS3d3UnNpTDU1eUxMN2tqa3h6?= =?utf-8?B?YTNCQ2Vnd3N2OE1qWkJ1MmNOWDd0TmFoaUo0enpPL2ROUFQxdTFrZmFUeXMx?= =?utf-8?B?Qjh2S2xpNjFXWUJyVkd5QWNKbXN5ZmdCVHBHYUxuRitwQU1tMzdCMngwazFL?= =?utf-8?B?MlRnU3BEN0pScWo3ZWMyelYra3NvTmp4SmI4YlUzK045eS9GVUxXVFdqNUFS?= =?utf-8?B?eWRxaEh0dGh0OGc0elNQbGg1WFNGbDU0OEIyYzJKNjVkM0ZIM0FNUlhwbHVl?= =?utf-8?B?YVkwRktld3MvajhKT2NRWGZvb09Ccno2UWlPd2NEUEpwbFR4cWxPOEszbXBF?= =?utf-8?B?QXVnQW1CZEVJbGpSYWEwWE1XODk0NzRPL2F2QVBJdktML1FVNkNBZnBBbzR6?= =?utf-8?B?UkNuV2NtU0I3OFRKbHU3OWg4Q3lvS0Y2UkpZbnBZY0NvUUxGbXFyQnZwRU5i?= =?utf-8?B?dGg4K3NZYkhab2hRMFRUa1BIMUlHVTJrdU44WkJLZkRVc3FPQkpud0J1ckdN?= =?utf-8?B?UFVYT1M0cUgwZUJRKzczQkphN0pWTlhNelErS1VvUGNSWmJQaHJrOVBBSHlZ?= =?utf-8?B?THBhQnE1cUlLYkc3SWEvUkJJRWRsdzFYS25XSE81dEt1VTdlc3d4NjRqdk10?= =?utf-8?B?b2JtSlpEMEd0a2l4a2I3bzlpdXRPbTZiNm1jN0FqZmVHdWQ3SFhaSE1zMW1i?= =?utf-8?B?M25zN2xVT2NCUm5vdjY2SUExcms0ZzlXb2xiQXRTem1mWkhqR2RIYTk0TWZ1?= =?utf-8?B?ODl3K1FPQ0hoVWdzcUoxbDQrOVpTM0t4c2FxaElHNHplOTBLTlBPd0VxTUM2?= =?utf-8?B?LzJxVVp2Nm5oVitzQS9TdVd3TkltRHNjS3JBTGpCMSs4c3FhdlhwRVFqR1Ra?= =?utf-8?B?S1RDUXdEL01hSjJINkRyVnRNZzBSQ05DSC85OTZ6R1pnYkY3aFdHa2EwN3BL?= =?utf-8?B?V05CWklKeG9ucWduQnZ0MDJpNzViVExUb1gvYmwreFNlQVd6czBxWUZaLzB0?= =?utf-8?B?aXRyV2Q4TkEvWDJwT2Y4ejBXYWpzUUNJbmtTWHE4L0svOGIxYjd2T205TjNG?= =?utf-8?B?dUJJVHJBSTl3NFM5bGJMOTYveTk4YWdTNW40ekFoeElKTDkyK29lYlp2ZTdq?= =?utf-8?B?RUxyZmFKTmdWamJKams2OUdmcUdaZG5BVTB5UE1ROW55RUZNVWlYT0lhR01o?= =?utf-8?B?bmFMbGZwZ0RpTWpOY2MxMzM2aTd0OGlsY0p2WHN1Q1IwaWFOY0YyakI0VERT?= =?utf-8?B?cWdIZ3RwdlFVZUlvaXNucWZUSUN2aTBseHZyS05kMS9tZnZCUDhCTUtsTmpR?= =?utf-8?B?cUExWGJXdnU3OGsxZEcyMnlhNm1VK2t3NHJjL0RiQ2dQbXB4aHROUnBodmIv?= =?utf-8?B?dXpJK1ZVa1NnSEZ3T3RwL2VjS3JFOHY3NFVEdTJwc0VGSmdRN21uMHJTWm5Y?= =?utf-8?Q?gyWmPgYEzP4QRv1+wlGiByYfTF7cFuf5+2P0zp3fg2EY=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 6:a6zaHoX/+NechTVWlmvD0lAoCcxhnd4cMDU3rOs+wsx31nb9ZkZBhq7NEMaXuImpqpWrwtQYc24Hd5m/6omFnkC4zZnLkfNP7JSGZHu8YE0580Ilm6/d1zNK2wPqTOvR0spuKfxlcMKVPxf+u247Eizgq/nZnkV5s1aSu1HmDhlFVUQDhVgDyLhYfULocPDCjhEy3/xlPquphxrbXnNxhsEmnXQ5O+9lSeH1SnX99de+b6kggCCm6azPCX+BRj5gBR3zdpLM8ZS8/Vh6v4OkHdXjaRk1MPwpvOsoHsQvp5W6fKF7U7VgbIkjQaNQ1wc4gE6rbKCi0WahwzTBkQGJRHViVxuESDxsom1LELp0beY=; 5:IUMUX7Qa48Z2pGJxS3IuoByuOMFhA03k9JJA+i7Hl39nQWDLvpaZulnHm3RWmnM/3cjOQhMdk5BMqIQMxOnGsJfvxefUCNBlH9FCyQIhRgqeAjyltLc3cSW/TgrR/Ltz+3Jq2ywKk8th0mPAbia2gqGaQTs5DY/+CH+hZ9M3980=; 24:uJ7fg9QnWb5SOT+tlnK9ftuacYh3EJRvSOy+WrLWChqaLBQFSlOccBiH1nxmRWCK3G3us/hvuTsbPnnbDNd3s9/k52kzPqX3rzkV8li74aU=; 7:ASt+KTnPNF7E7XO+AkUM9Bw1AOpK8UdkglP2ArnXEwFZ9/kB1WnTjEmLmLoChXFSQOyZSlc0W8l76TmgzqLFulZDnQObP/YdD/KnmPHdZAn2x4dpXBi7yiClwrctcq3rzhLpFUvVsfudVW6Z4bcsb2C5ga/jjYD6xDjFsd4zdvLBku5fOBxL8PHsCR7910XgsURO8vJHgCauqFVQdSdMbQqAbRjrso2mjXy5x6sx0ovfP18nh4YawBeK2OIH3NSE
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2017 11:12:44.1194 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d64e3a5b-3359-47dc-7400-08d51d2ba5ca
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 11:12:49 -0000

----- Original Message -----
From: "Mahesh Jethanandani" 
To: "t.petch" 
Sent: Thursday, October 26, 2017 6:35 PM

> On Oct 26, 2017, at 9:50 AM, t.petch  wrote:
>
> Lou
>
> I like the advice that diagrams should be one page long but wonder how
> to apply that to those I see in routing WGs.  I have just been looking
> at
>
> draft-ietf-teas-yang-te-topo-12
>
> where the diagram is 36 pages long - which may be one of the larger
ones
> but by no means exceptional - and I think the diagram is  more or less
> useless as a result.  But what practical advice can we give them?

How about using the depth of the —tree-depth option to generate smaller
trees that may not give the whole tree, but at least give you a nice
overview? Follow that with smaller chunks using the —tree-path for each
section of the tree.



Yes!  That is what I do manually when I really really want to understand
and refer to a module - but it is time consuming and tedious.

I look to have a top level of less than a page and lower levels which
may be bigger.

I think that this also interacts with groupings.  If a tree diagram with
groupings expanded is 6 pages and one without the expansion is 2 pages
plus one for the grouping, then I would prefer the latter.  YMMV but I
think that there is a guideline in there somewhere.

Tom Petch

>
> I append the diagram below
>
> Tom Petch
>
>
> start of diagram
> ==================================================
.

>            +--ro altitude?    int64
>            +--ro latitude?    geographic-coordinate-degree
>            +--ro longitude?   geographic-coordinate-degree
>
>
>
> =====================================
> end of diagram
>
> ----- Original Message -----
> From: "Lou Berger" 
> To: 
> Sent: Wednesday, October 25, 2017 2:13 PM
> Subject: Re: [netmod] I-D Action:
> draft-ietf-netmod-yang-tree-diagrams-02.txt
>
>
>> Hi,
>>
>> This version addresses all known / open issues in the draft known to
>> the authors.
>>
>> The changes are as follows:
>> - Added groupings and yang-data descriptions
>> - Added Comments, Long Diagrams and Security Considerations sections
>> - Clarified representation of schema mount points and representation
> of
>> modules exposed using schema mount.
>> - Miscellaneous editorial changes
>>
>> Lou (for draft authors)
>>
>> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
>>>        Authors         : Martin Bjorklund
>>>                          Lou Berger
>>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
>>> Pages           : 11
>>> Date            : 2017-10-25
>>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Fri Oct 27 04:58:31 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BF413F501 for ; Fri, 27 Oct 2017 04:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKbXHPsiSm1L for ; Fri, 27 Oct 2017 04:58:28 -0700 (PDT)
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 EBBE513B13E for ; Fri, 27 Oct 2017 04:58:27 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BB46A373; Fri, 27 Oct 2017 13:58:26 +0200 (CEST)
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 gHiqivxxD0vC; Fri, 27 Oct 2017 13:58:25 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Oct 2017 13:58:26 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7F902010B; Fri, 27 Oct 2017 13:58:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KpmyWV_nkNO0; Fri, 27 Oct 2017 13:58:25 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 192942010A; Fri, 27 Oct 2017 13:58:26 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 69961413FA46; Fri, 27 Oct 2017 13:57:00 +0200 (CEST)
Date: Fri, 27 Oct 2017 13:57:00 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: "t.petch" , netmod@ietf.org
Message-ID: <20171027115700.u5xwq5xw347jbclp@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>  <20171026221736.cl3kpzo2i7zaa4qh@elstar.local> <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net> <20171026234123.pt65l6ctgmx2hd55@elstar.local> <15f5d46ec50.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171027105159.up6ec5xwbcy75hcr@elstar.local> <34dbaaaa-8a06-f980-7bf8-4a54aa117423@labn.net>
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: <34dbaaaa-8a06-f980-7bf8-4a54aa117423@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 11:58:30 -0000

On Fri, Oct 27, 2017 at 07:04:24AM -0400, Lou Berger wrote:
> 
> > We should encourage authors to split large diagrams into manageable
> > pieces. Sometimes suppressing lots of statistics counters helps,
> > sometimes showing which groupings are used instead of their expansion
> > helps. Sometimes it helps to separate major branches of a tree and to
> > discuss them separately. We should encourage authors to do these
> > things. 
> 
> I agree with this too, and this was the goal of the current text.
> > Perhaps we need to state clearly that it is not necessary to
> > include a plain fully expanded tree diagram.
> Please propose text for the draft!

Personally, I think usage guidelines do not belong into the yang tree
document in the first place. Having the document just define what tree
diagrams are would be my preference, leaving usage guidelines to our
guidelines document. Section 3.4 of 6087bis talks about tree diagrams
and I would prefer to have guidelines text in one place. But perhaps a
clear separation of 'here is stuff' from 'this is how we suggest to
use stuff' is difficult in practice. But what we have here is that we
now have two places where advice is given how to use stuff...

That said, RFC 6087bis says:

   YANG tree diagrams provide a concise representation of a YANG module,
   and SHOULD be included to help readers understand YANG module
   structure. Tree diagrams MAY be split into sections to correspond to
   document structure.

With all the capital letters in place, the text might cause people to
draw the wrong conclusion that they have to include plain tree
diagrams. The text does not give a good explanation when a split
should be considered or that a full plain dump may not be needed or
where to find good examples of diagrams broken into pieces. The text
in the yang tree diagram document is actually better in this regard.

The example in section 3.4 of RFC 6087bis is actually repeating the
non-NDMA /foo /foo-state style, well, we are getting off topic.
 
> > In the case of draft-ietf-teas-yang-te-topo-12.txt, the fully expanded
> > tree diagram (36 pages) is simply in no good relation with the size of
> > the definitions (47 pages). And the authors of this document do the
> > right thing, they provide overview diagrams that leave out lots of
> > details and that are comprehensible. So is it valuable to keep the
> > full dump in the document?
> I personally don't think so, and questioned its usefulness.  I also
> suggested moving to an appendix if they really wanted to keep it.  For
> whatever reason they decided they wanted to keep it which is, of course,
> within their purview.
> 
> So, I think the question for us is: what, beyond the change you suggest
> above, add to the tree draft to cover cases where authors really want to
> include such long trees?

At the end, WGs decide with the input from the authors, reviewers
etc. and not everything needs to have rules that we cast into RFCs.
Perhaps we are better off having a few questions and answers on the
FAQ concerning tree diagrams.

/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 Oct 27 05:17:26 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A313F54B for ; Fri, 27 Oct 2017 05:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 2od4xKDjI8CC for ; Fri, 27 Oct 2017 05:17:22 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40131.outbound.protection.outlook.com [40.107.4.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29AF13B13E for ; Fri, 27 Oct 2017 05:17:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qaanxA+wgTCoyEShyvpXLZPabc/9BwUUVKgY/FEV4lg=; b=U9ke30FfDT9uChALmGmA7s5f6DcD5ko+fR69/6KUL4tbduSRamBLdSsbcG5atNFMF1PcOqpisTyCs8m+2DR/lJoD4VbAJyx1XGJTOymXOqAPZrNnRIkrJs5s49AicjINDA3/3yyfRfiVc6famJepReqHKezYPSRS/kJOMSBifWQ=
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com (10.163.187.158) by AM3PR07MB1122.eurprd07.prod.outlook.com (10.163.187.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Fri, 27 Oct 2017 12:17:17 +0000
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527]) by AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527%14]) with mapi id 15.20.0178.003; Fri, 27 Oct 2017 12:17:17 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP admin-state
Thread-Index: AdNOevP2Ug0r6+CiQ+ipzdRijgA3aQAEGVeAAACr5bAAGowwgAAJPbBw
Date: Fri, 27 Oct 2017 12:17:17 +0000
Message-ID: 
References:  <20171026.205053.2059947918997412077.mbj@tail-f.com>  <20171027.095015.776466334584979124.mbj@tail-f.com>
In-Reply-To: <20171027.095015.776466334584979124.mbj@tail-f.com>
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=jason.sterne@nokia.com; 
x-originating-ip: [135.245.20.24]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1122; 6:3IHLbvOtdyJVmp+FVE89222WSGYvmbtJ2oowFvjBOkp9l/oJ7CZ8A7mPhmqBYiNeL/7SxqGYKRAJRochsHR3/D1i0KVykMU9Z/7OaUf82QvyZ3qB4j6B32nEbduhpaqW5YB0PLQPh0InP9biQj0tI1MkE1R0N+NVkJFSDkbl4rMVJ1AHUB4nOT1C+lT4j3Zfv5ODZ0EpTFpNo9z4dhqkJQM+V0TtHDzFDas9zr1HKyRrg+G97TCPgQ/rg9xNB00NegNzZsd3K/uo+9Rg4fZLM60zbx05DsWreJsfJ1QHaL7f0H6MoZVAixyfmcz9LbcdZy1U8umuKxq+JoElFfOdCsivD9Uni2t790bSYVbd0NI=; 5:S4R1iGwks/nL1U5R+nGkWJDqV5CqgJykH5N4KJID248iTNqO6QQLrcl6vfZRzv0fCk20fwRm7wa+v86t5IgZceom4xdwhg3qNqXMP3p0E7D4XHAgL2SGcsnt1XHDRXjRJT40NG4eLQLU+PFzGmMCa/5MFY2tFM9INE7ymathS1g=; 24:hdreT/YwvN8656uPm4nKOX5U1YOQU2TGFivxurWJpqQgwAKGKFnaMwPguVfOYU/NUFT9SfkQkfEQjsh2T0XM+f3TAxzrVQjEIz1BBUs+BaQ=; 7:r8tuaWyIN5D7EQGOSLbt6natZiO0QoDjzHsKs1kaKXAjro096SbJa5WCxexLXLrgARZUx9vwAZmcTr78XYB96qh5vkbmRjcM036UOouB9VeePv+YNU30HD8GTvcDopZwDEj0w5mlS2YnZ28S7xPsxIYjLwmzr3c4lAF5qzz7aQ0+aG1qjOmRN9KsFOBT63e+USDsvtyEtPrCp3BRCcN64gNbB91tSRCSGi29L6zB5Nb7UAMr+desmxu3orVhH6ci
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 6a8508bf-d8b3-4d3c-b3db-08d51d34aa90
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM3PR07MB1122; 
x-ms-traffictypediagnostic: AM3PR07MB1122:
x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231020)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1122; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1122; 
x-forefront-prvs: 0473A03F3F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(377424004)(53754006)(13464003)(189002)(24454002)(199003)(81156014)(8676002)(6506006)(53546010)(25786009)(966005)(6436002)(4001150100001)(68736007)(6246003)(93886005)(2906002)(74316002)(305945005)(86362001)(97736004)(66066001)(14454004)(81166006)(478600001)(4326008)(5250100002)(8936002)(50986999)(76176999)(55016002)(99286003)(54356999)(229853002)(53936002)(33656002)(7736002)(6306002)(101416001)(5660300001)(316002)(6916009)(3846002)(3660700001)(6116002)(2900100001)(2950100002)(7696004)(9686003)(105586002)(102836003)(189998001)(106356001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1122; H:AM3PR07MB1124.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)
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: 6a8508bf-d8b3-4d3c-b3db-08d51d34aa90
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 12:17:17.8032 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1122
Archived-At: 
Subject: Re: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP admin-state
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 12:17:25 -0000

Yes - that seems OK to me.  Although how about we remove the word 'intended=
' to avoid confusion with the NMDA stuff ?

               Changes in this leaf in the configuration are reflected in i=
fAdminStatus.

I'm not sure about 'testing' but I suspect we don't support it (i.e. return=
 an error if an SNMP client tries to set that value).  Or perhaps we map it=
.

Jason

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Friday, October 27, 2017 3:50
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP admin-
> state
>=20
> "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > Hi Martin,
> >
> > I'm OK with that direction ('enabled' affects ifAdminStatus).  I'm
> questioning the other direction.  I think a change in ifAdminStatus shoul=
d be
> reflected in 'enabled'.
>=20
> How about simply:
>=20
>               Changes in this leaf in the intended configuration are
>               reflected in ifAdminStatus.
>=20
> This would allow implementations that separate the two to not update
> "enabled" when ifAdminStatus is updated, and allow your implemenation to
> do the update (how do you handle 'testing' btw?).
>=20
>=20
> /martin
>=20
>=20
> >
> > Rgds,
> > Jason
> >
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > Sent: Thursday, October 26, 2017 14:51
> > > To: Sterne, Jason (Nokia - CA/Ottawa) 
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] rfc7223bis (interfaces) enabled leaf vs SNMP
> > > admin- state
> > >
> > > "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > > > Hi all,
> > > >
> > > > The issue I'm raising isn't new to the 'bis' version of RFC7223,
> > > > but I'm questioning whether we should consider changing something
> > > > about it while we're in there.
> > > >
> > > > The 'enabled' leaf has this in the description:
> > > >
> > > >              Changes in this leaf in the intended configuration are
> > > >              reflected in ifAdminStatus, but if ifAdminStatus is
> > > >              changed over SNMP, this leaf is not affected.
> > > >
> > > > As an example of "working code", Nokia's SR OS has supported full
> > > > router configuration via SNMP for many years.  When someone
> > > > enables an interface via CLI, that is reflected in ifAdminStatus an=
d vice-
> versa.
> > > > i.e. configuration via two different interfaces (SNMP & CLI) that
> > > > use different data models, map rw leafs from the two
> > > > interfaces/models to the same underlying internal object.
> > > >
> > > > In general, many SNMP rw objects will map to the same underlying
> > > > internal rw object as the equivalent rw leaf in a YANG model (for
> > > > products that actually support config management via SNMP as well
> > > > as NETCONF).  Changing the leaf/object via SNMP affects the
> > > > equivalent leaf/object in NETCONF.  Why make this one a special cas=
e ?
> > >
> > > Note how ifAdminStatus is defined:
> > >
> > >             "The desired state of the interface.  The testing(3) stat=
e
> > >             indicates that no operational packets can be passed.  Whe=
n a
> > >             managed system initializes, all interfaces start with
> > >             ifAdminStatus in the down(2) state.  As a result of eithe=
r
> > >             explicit management action or per configuration informati=
on
> > >             retained by the managed system, ifAdminStatus is then
> > >             changed to either the up(1) or testing(3) states (or rema=
ins
> > >             in the down(2) state)."
> > >
> > > Note the *per configuration information*.  It is clear that
> > > ifAdminStatus is not the same as the "per configuration information".
> > > The config object can affect ifAdminStatus.  "enabled" in the YANG
> > > model is supposed to be that config object that can affect ifAdminSta=
tus.
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > I'd propose that we remove that sentence.
> > > >
> > > > Rgds,
> > > > Jason
> > > >
> > > > > -----Original Message-----
> > > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of
> > > > > internet- drafts@ietf.org
> > > > > Sent: Monday, October 16, 2017 9:25
> > > > > To: i-d-announce@ietf.org
> > > > > Cc: netmod@ietf.org
> > > > > Subject: [netmod] I-D Action:
> > > > > draft-ietf-netmod-rfc7223bis-00.txt
> > > > >
> > > > >
> > > > > 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 Interface Managem=
ent
> > > > >         Author          : Martin Bjorklund
> > > > > 	Filename        : draft-ietf-netmod-rfc7223bis-00.txt
> > > > > 	Pages           : 47
> > > > > 	Date            : 2017-10-15
> > > > >
> > > > > Abstract:
> > > > >    This document defines a YANG data model for the management of
> > > network
> > > > >    interfaces.  It is expected that interface-type-specific data =
models
> > > > >    augment the generic interfaces data model defined in this
> document.
> > > > >    The data model includes definitions for configuration and syst=
em
> > > > >    state (status information and counters for the collection of
> > > > >    statistics).  This document obsoletes RFC 7223.
> > > > >
> > > > >
> > > > > The IETF datatracker status page for this draft is:
> > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
> > > > >
> > > > > There are also htmlized versions available at:
> > > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-00
> > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223b
> > > > > is-0
> > > > > 0
> > > > >
> > > > >
> > > > > Please note that it may take a couple of minutes from the time
> > > > > of submission until the htmlized version and diff are available
> > > > > at tools.ietf.org.
> > > > >
> > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> >


From nobody Fri Oct 27 05:37:00 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE81C13F546 for ; Fri, 27 Oct 2017 05:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 UY4dAsGiNYc7 for ; Fri, 27 Oct 2017 05:36:57 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 429A913B262 for ; Fri, 27 Oct 2017 05:36:57 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id BFD851E07A6 for ; Fri, 27 Oct 2017 06:36:55 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id Sccr1w00w2SSUrH01ccud5; Fri, 27 Oct 2017 06:36:55 -0600
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=32qfTp0iF-ENOMR136MA: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=PRcftW9CBW/U42131yMjBJvbv7Z7ikpCnWFOQfOa9iY=; b=rIG/UmCmcis9/LnwXU5Icl82ce h2Wp2tfLYOUrcoSoeK5bAbDSfrvAS3H7ioto4VuIsWYrc35PLINqq1V77OLEz8wIoXztUQ6d91FMs KC8TBqkdAtSG4jIX3odIhww9j;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:50366 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e83sZ-000tU8-Qi; Fri, 27 Oct 2017 06:36:51 -0600
To: "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>  <20171026221736.cl3kpzo2i7zaa4qh@elstar.local> <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net> <20171026234123.pt65l6ctgmx2hd55@elstar.local> <15f5d46ec50.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171027105159.up6ec5xwbcy75hcr@elstar.local> <34dbaaaa-8a06-f980-7bf8-4a54aa117423@labn.net> <20171027115700.u5xwq5xw347jbclp@elstar.local>
From: Lou Berger 
Message-ID: <58770c00-2d4a-f5b2-c0bf-cf52d680577a@labn.net>
Date: Fri, 27 Oct 2017 08:36:43 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171027115700.u5xwq5xw347jbclp@elstar.local>
Content-Type: text/plain; charset=utf-8
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: 1e83sZ-000tU8-Qi
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]:50366
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 12:36:59 -0000

Juergen,


On 10/27/2017 7:57 AM, Juergen Schoenwaelder wrote:
> On Fri, Oct 27, 2017 at 07:04:24AM -0400, Lou Berger wrote:
>>> We should encourage authors to split large diagrams into manageable
>>> pieces. Sometimes suppressing lots of statistics counters helps,
>>> sometimes showing which groupings are used instead of their expansion
>>> helps. Sometimes it helps to separate major branches of a tree and to
>>> discuss them separately. We should encourage authors to do these
>>> things. 
>> I agree with this too, and this was the goal of the current text.
>>> Perhaps we need to state clearly that it is not necessary to
>>> include a plain fully expanded tree diagram.
>> Please propose text for the draft!
> Personally, I think usage guidelines do not belong into the yang tree
> document in the first place. Having the document just define what tree
> diagrams are would be my preference, leaving usage guidelines to our
> guidelines document.

Having a guidelines document that evolves naturally over time is just
fine, much like coding conventions.  But trying to bundle or wait for
the convention update both increases the cost of doing guidelines and
leaves a time window when the guidelines are not documented.  While in
some cases this may just fine, I think in this case it would leave much
"folklore" undocumented.  In other words, I think we should capture the
guidelines as best as we can in this document. As I think I've stated
publicly before, I also think the we as WG have to figure out how to
work more "nimbly" by resisting the temptation to have big documents
that cover all aspects of the particular topic at once.

I do think your observation on having two sets of guidelines is correct
and not a good thing.  We can address this quite simply by (a) marking
this document as updating 6087bis and (b) ensuring we have a full
replacement to the tree guidelines provided in that document.

>  Section 3.4 of 6087bis talks about tree diagrams
> and I would prefer to have guidelines text in one place. But perhaps a
> clear separation of 'here is stuff' from 'this is how we suggest to
> use stuff' is difficult in practice. But what we have here is that we
> now have two places where advice is given how to use stuff...
>
> That said, RFC 6087bis says:
>
>    YANG tree diagrams provide a concise representation of a YANG module,
>    and SHOULD be included to help readers understand YANG module
>    structure. Tree diagrams MAY be split into sections to correspond to
>    document structure.
>
> With all the capital letters in place, the text might cause people to
> draw the wrong conclusion that they have to include plain tree
> diagrams. The text does not give a good explanation when a split
> should be considered or that a full plain dump may not be needed or
> where to find good examples of diagrams broken into pieces. The text
> in the yang tree diagram document is actually better in this regard.
>
> The example in section 3.4 of RFC 6087bis is actually repeating the
> non-NDMA /foo /foo-state style, well, we are getting off topic.
>  
>>> In the case of draft-ietf-teas-yang-te-topo-12.txt, the fully expanded
>>> tree diagram (36 pages) is simply in no good relation with the size of
>>> the definitions (47 pages). And the authors of this document do the
>>> right thing, they provide overview diagrams that leave out lots of
>>> details and that are comprehensible. So is it valuable to keep the
>>> full dump in the document?
>> I personally don't think so, and questioned its usefulness.  I also
>> suggested moving to an appendix if they really wanted to keep it.  For
>> whatever reason they decided they wanted to keep it which is, of course,
>> within their purview.
>>
>> So, I think the question for us is: what, beyond the change you suggest
>> above, add to the tree draft to cover cases where authors really want to
>> include such long trees?
> At the end, WGs decide with the input from the authors, reviewers
> etc. and not everything needs to have rules that we cast into RFCs.
absolutely agree!

Cheers,
Lou
> Perhaps we are better off having a few questions and answers on the
> FAQ concerning tree diagrams.
>
> /js
>


From nobody Fri Oct 27 05:38:18 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B28813B262 for ; Fri, 27 Oct 2017 05:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 hl0LH5tj_wij for ; Fri, 27 Oct 2017 05:38:15 -0700 (PDT)
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 BE20913A8A1 for ; Fri, 27 Oct 2017 05:38:15 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 1AA6B140467 for ; Fri, 27 Oct 2017 06:38:11 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id Sce81w0042SSUrH01ceBWB; Fri, 27 Oct 2017 06:38:11 -0600
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=D2vAwGANpPmac-ssmSAA:9 a=-JxZ8xcSciFRdnWX:21 a=vSDJ_gyedrXwH5x5:21 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: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=SkPlBtZK2GwQ+GwaOioTRz7Az5SEq31HFReb2AyjOnA=; b=JgJcYa5e6wlF+mnNAQY6GVjoYW AauGplAL+4toOxA5B2O2hfyyeCHCCIDkvvhVzU3Xvgcs0RFHEbZnTKO2eNCPSrVZXq3yUUad5doXV DGLeTKZeTmZO5yYq4wdCMPVd4;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:50424 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e83tn-000tkX-T0; Fri, 27 Oct 2017 06:38:07 -0600
To: "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <03bb01d34f14$2907e5c0$4001a8c0@gateway.2wire.net>
From: Lou Berger 
Message-ID: <63fca2cd-e41e-5d79-2290-41e0d0541ccb@labn.net>
Date: Fri, 27 Oct 2017 08:38:04 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <03bb01d34f14$2907e5c0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: 1e83tn-000tkX-T0
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]:50424
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 12:38:17 -0000

Tom,


On 10/27/2017 7:08 AM, t.petch wrote:
> Lou
>
> On a slightly different tack, so a slightly modified Subject: line,
> when an I-D contains multiple modules, some place all the models
> together and then all the modules, e.g.
> draft-hares-i2nsf-capability-data-model-04 while others intersperse the
> models and the modules, e.g. draft-ietf-lisp-yang-05 .
>
> I think the former is superior and should be recommended, especially
> when, as Sue has done, there is a brief paragraph of text before each
> model, so it is very clear where a model ends and another begins.  With
> the latter, models can be hard to find.

> I see this as dovetailing into Juergen's comments on RFC7317 which, to
> me, is really several separate modules packaged as one, so the
> separation makes excellent sense to a reader.
>
> Where the I-D is already several modules, then do as RFC7317 has done.
Sure, Do you have text you'd like to propose?


> Tom Petch
>
> ----- Original Message -----
> From: "Lou Berger" 
> To: 
> Sent: Wednesday, October 25, 2017 2:13 PM
>
>> Hi,
>>
>> This version addresses all known / open issues in the draft known to
>> the authors.
>>
>> The changes are as follows:
>> - Added groupings and yang-data descriptions
>> - Added Comments, Long Diagrams and Security Considerations sections
>> - Clarified representation of schema mount points and representation
> of
>> modules exposed using schema mount.
>> - Miscellaneous editorial changes
>>
>> Lou (for draft authors)
>>
>> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
>>>         Authors         : Martin Bjorklund
>>>                           Lou Berger
>>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
>>> Pages           : 11
>>> Date            : 2017-10-25
>>>
>>> Abstract:
>>>    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.
>>>
>>>
>>> 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-02
>>>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagra
> ms-02
>>> A diff from the previous version is available at:
>>>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-0
> 2
>>>
>>> Please note that it may take a couple of minutes from the time of
> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>


From nobody Fri Oct 27 10:11:28 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B6B13B488 for ; Fri, 27 Oct 2017 10:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 hwF3CWUWqZlp for ; Fri, 27 Oct 2017 10:11:25 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20100.outbound.protection.outlook.com [40.107.2.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 AAE47138A38 for ; Fri, 27 Oct 2017 10:11:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JgVSuGo21cd+gevoJ8gt+6kbvHnRvVDRWilkz3QNAYc=; b=dEISrGgisjCf/cm+Yo57nCjGLLCAqYmU2mFmkGpHHc08VafJUJmqSbWvscqSPox02liQbngunADvCPuVjs4+2uvE1Rwpj+BTkPtgjxPEv5ShnSa7zGruvuPX+LkI7ZAVU8JD4I52RcmbrkeSGTGK71lFUdwYbsyzE2xoXWM3oaE=
Received: from pc6 (86.169.153.236) by AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Fri, 27 Oct 2017 17:11:21 +0000
Message-ID: <013401d34f46$42976740$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "Lou Berger" 
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <03bb01d34f14$2907e5c0$4001a8c0@gateway.2wire.net> <63fca2cd-e41e-5d79-2290-41e0d0541ccb@labn.net>
Date: Fri, 27 Oct 2017 18:08:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: DB6P189CA0032.EURP189.PROD.OUTLOOK.COM (2603:10a6:6:2e::45) To AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18)
X-MS-Office365-Filtering-Correlation-Id: 39968f00-5c0b-4613-329a-08d51d5dbf3c
X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:AM5PR0701MB2996; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 3:2m/86sthchwXR8C1dI7Infr+ppk9nuiZxGG9y67SZoGK84YbDAnnUJXq6Obo56nm7ja7O4icwnmu8kHs6mTn2jzrX55EghWiZVdwbOKMOvFVR2OlbUTmXp/ZmqheuVKG6XLdMuU0iDyNo+9unwlXiidzQGIp522ixp73X9tBRiDddk6p9qFCC4i7vmLnVYmmokZAG0/vC9Ds+oSK98vbmauMB2R35sRCM0MNmuekbuTOzWLjCcTxJZ/rojoHLR9WYAitDk5UR5gP5G/RE2i+K3jnKirqJ7/fUbpScaJfMU8=; 25:EqyIfPSYUQk0vDk8j76dYOz6i0jJsO0ev371ridJuMMV2TyqKMSCphGFuykq48G1hhQioOwkaN/oAppR0XLSS79v2w/+cohYJu0eGBLnS0S0l+bvGaPAJoaz4RLageuAxxhkjh+/MnGYcMuI4zfEc6F2g01Ol8sPy5TGhHnYwFtt4SN+7KZgx5PVnomRbzgtpuuP5zCjltWszY22QZDUAGFU2Gwf8jEmYVnjp36aSNTbezwfm48ijvECHZ7/qQTU/SNKycxrhyy10poP78QCydRV4uk+50ynAbjBnE1VigT94pVuEjK8AlLiYHkRZSVIhGG2t6Q5YfADSpcyd7+Pxw==; 31:uqyoL6tuHr2oXKSrTBxp35I0iTTFpDAl2zbJ5yc6iBsz4yWyexE2O3kqtGB4QbF+8QKg39E1ZDf3OGzJjL83xWOmQOle7txZzhCwKN0cfIAyO9WqrjpVes1DVrgvqav5FZOsKoqoOsVcI6WLuKqqz9WtyMgATld1RW5W4cOcHS1tkOiCN9ImexCJhW78NtsX+eirJ3+xn6lFclvfck7XZn4t5VIMlBo1G4oMcJAqCwk=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2996:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(192374486261705);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3231020)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2996; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2996; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 4:aPI5A40eJxwWKfM4S+4LlxH7mBl+NGo/OwmF85RSfLvSbpuyuQ4fZLzFy0S4QFPOoggILUsXlSHiRZZitDDjj6XoomG23gxKP8o/Xl9keTkQlOJio4RIo/xJJQdmTZFX66uHZGE3IwujGtOiPaewhjVZizYObWllK03zEyut64jO0TFaEt+g+5OvGxt6EymoDgnZj6OqN7RH0HDrQoqrUec5XOhtahMkKzBO7GPHAuYb/DkcL4PUdEXkQgZkO8ctrylHFXScOxmnuWtmyfQJrwiANAR7kHDuqnBv2vc/s68sX6h9EPR+vj1KIf8y1R1rmQ9dtp928t3bt9wpR8ryz9DpL9tpnjmOKCnz0xHqqAQ=
X-Forefront-PRVS: 0473A03F3F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(376002)(346002)(24454002)(13464003)(199003)(189002)(33646002)(1456003)(76176999)(4720700003)(6496005)(7736002)(9686003)(230700001)(106356001)(116806002)(229853002)(68736007)(101416001)(189998001)(6246003)(105586002)(81686999)(230783001)(305945005)(44736005)(84392002)(6486002)(110136005)(61296003)(50986999)(47776003)(53936002)(50226002)(81816999)(6666003)(8676002)(62236002)(66066001)(53546010)(50466002)(14496001)(93886005)(81166006)(6116002)(25786009)(316002)(44716002)(2906002)(81156014)(3846002)(97736004)(8936002)(86362001)(23676002)(1556002)(16526018)(478600001)(5660300001)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2996; 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?MTtBTTVQUjA3MDFNQjI5OTY7MjM6MGRoeDhvNC9NNnlaK3F0cjdVcXVNd1g3?= =?utf-8?B?Q2xNaFFKN0dTTW9WTnQ4NFowS0dMN1dnWmQrUkdNK3Q2S0NVVzdBSkRDeTlm?= =?utf-8?B?cTlqVWh0T1g2TW9qekNyTDA4REwvTlk4eVJxUFVXN3psQWNFbjJWQTFPZ3Ir?= =?utf-8?B?T1krOENjVm5lRHVKNSsrdWlMbHcxNStrYlM4SVFtd0RxSi81cmRodWVJaUxC?= =?utf-8?B?UXdPZCtrZU5qZlFDSWtPOHdGNWpqR3ZEZkZtOWgyUUZJZElWRk94aUIzR0dy?= =?utf-8?B?LzhIWUMrZTB5bnpKaW1MclVpZ1BpK0I5emhYZ2xXMDYzeXBCOW9lRGdOemJi?= =?utf-8?B?OHRuRUtQNHhJQmx1S1RrQmxISTBBNFY0Y1RYUCtabTAxRzYrQlFMRUZSdXRH?= =?utf-8?B?anJiQUQreUZDMncwYnkwTjdpV2Y5YTVDUHprajNZbHpLQzJIalQzdkdHQmZq?= =?utf-8?B?d0VvelE1UUxoNTNqTTNRanYyZ0s4YVBKNndPbU5jN0prcEhaYjVZWW04aUgz?= =?utf-8?B?d0N5SkhYY3lvM0RqY0FZT1VWcng0dTM2elIwV0tmc1IrdSsyV2J6LzYrbVEx?= =?utf-8?B?TWZHaGdjdzdpbjdKOENvajQ3YWF2Nm80NHgrN0hXam9MMkxoNUJ4djZJYlBS?= =?utf-8?B?TE51VVVwNkpZSUV4K3JZRDlCQ1JyMlZ2MFNYNVNpdW1CaUs0L24yU2JtNGgv?= =?utf-8?B?Qk5KYk5XQUhHTnJPcCtMMzF5MHczZkxQVXdPdTA3OHU2Rkh0RU9yTXFWcEJ2?= =?utf-8?B?Q0ZDUUNiTFB3SGlOMndEN1JTRDdSaXlnV0lMNWwxNnFtV29uNmgrRm96Ti9z?= =?utf-8?B?a2JvK21WTUZnVmJlZlRPcUVUWkg5VDlCNlc3QUtrciszSVB6VUlaUDFnODI1?= =?utf-8?B?bUx3OForWmN2bE5OQWpCcSt3UWNSTTNJWlhKcVBpL0V5UVhKTjcrTGcvT2xF?= =?utf-8?B?SDNJcE9mMjY0SFpsb3E2Y3YyeWpUalRUekJuc1Y1bHZVNkE5WE0vanltWmZr?= =?utf-8?B?QnAzdGVQaWozRGxOZ1V0Z3J0V2xGRDZRQWpiNFlsY2N2Rm9aTXJHa3U3Sm5L?= =?utf-8?B?UWNVY1dselNZT1RyVTR3Sm4yK3c3MDgzOFg3bVM1aFhaZXlpZGQrZjZxRUdn?= =?utf-8?B?NERmbEUvdUszNnY1eVhrRW5pOXpPWUpoUTBDZ2R4bTJxUEJ1RmNjZHluZURS?= =?utf-8?B?LzFVYURsRjlIaDRmMGVWSGdxYWkzYWRMUEkwV3BZNkx1NHR2YW03UFFGZnFh?= =?utf-8?B?S205TUJzNTlaRWlaazdFVlZxWG5Bdi92bWwvSzk1U3ZVVHBwN29MS3c3ckV6?= =?utf-8?B?akFTSE9GaE5kYmk4Ui9OZ2owZWk5T1Y3c0JWOWhDT2UwTlgvbURubGxYTHNK?= =?utf-8?B?SDBHc1NmVDFkRkhnaUM4NTg1UzcwSWtZbmtnYnJxRVcwMmtGRHFSL0tqb08v?= =?utf-8?B?Y2dWejgxQ2NVV283UUl1RHc4QkNnWGJoL3cxUUpzMWxiWDZtWUFMOEZQZTdQ?= =?utf-8?B?MEpiL1hmRStlbHA3cDRrWmZXYmwrUVVEQjArcXFNVDZnNndOYmdsNG5kbmd3?= =?utf-8?B?blZ6aW5NamozQ3h0cGVJVUxyeDJkelF1eE1RZjRJWmJuVWthKzdBS0R0OTdh?= =?utf-8?B?aE9XSjQ5dmRLaU1wR1FvamphUmQrUHhDejBHcTI5R3hoZmZOK2ZxbmdKcUds?= =?utf-8?B?ZkdOTjI2a2xtdWdaSWMwZ2JPR0pacFpZcWlhWHVheHpQUUNHb3BueElwdW9w?= =?utf-8?B?RWFXS3FYcEpNdU5HbHdTTjgwWmtvYmxTTXV4SkgyT2pLWkV2aEd2YS90bFM2?= =?utf-8?B?UVN6RXhvUjVGYzQyUk91Y0U4YTJsR3hBcnRhNUZRbWI4L3pteWNLWWhHZzBs?= =?utf-8?B?QXZSTnk4YkFGT3IzL0xQRzZqOWFMQ3kvVTZxVktRdkZWK0tLaFBuWEhkbTEz?= =?utf-8?B?V2p2YkwzK3VrSU1JOXJ2SytSRm9FQjNaR1REc1ZtamtNRHFZYzJXU0xUL3h6?= =?utf-8?B?NWFQRTF2a1JJbFVhc1VwL3lhZE95ak5NQjZyVk9MNWZ5ZFBrUitOTVdkVmlL?= =?utf-8?Q?aJ3dNlFdl1J0EFZiVzjfY5jBYKM?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 6:S9e8zo/jEwRavH0iLr0JRMiYnes5gNH5haJRwu6SqNn74XRBi10vrlgME9NVdYOvhnojMNNVC9acxXpcxOim9j7vVzmITkDR1X4ZhfD1i8tYMuQd965hv5iatNIEElguPhlMlvSxVdTKeVHZtfEMziM6mNCpXjk3j4EUgpD4vzMw4dmRetTf7hPGah2aOdCKNohh1av8G2885QWamhCogmzddlA61TqAvNfUttvq/pShiUWvLKT9F6PEdGXXIXb/6BT5sKHmjRQGrdhZLJciLyy3hWwYXbDT16y81uxEE1jxrzklC3HfDR6FincAY5S02szdqj0AoGj/7UAUEMjALrWQO9eXUEVNuJSKOgkkFyI=; 5:achif78O1pJMGh9NFGv6aK8baqp6cFbYwpXa/Wz8FWUTXbLcfOL39QjHwD4H9bOl+7aIif4ZxzfYuk+cQDfEu9od0wTdZi37gYbxnW2Iz0xMRmXeWawFHZJqBlZpIyszQsHHYjya8ECUTCYIrdnGFVx+0Z/u8Qmjk4eXZrNqpxY=; 24:86bLPfRVoJABOYfYNpHjQTYOR+RpXjBKW4VK3qGjf3Bnr94wWJrl7ytf0yaMbRGSbltloZKY4YbKBr2JYGlQgGYqwLkQyAl8zGiDcVMJCBA=; 7:puwWHEVEXQp55dqTk+jbH/izBZ8DcoznNY583mrzu4jsjWtU2rzcHywMSLomm7xV1pScTbqWPxbjqLP7v4FBA92aVUR1NqB17i0AqF5qAOS9fooV6rGIYRaQfp695R3oG6Apq5OX0AUHzt7ifP/iMDaFM+yGR+Ap52DIyw02IT4UU81GbW4dWNxD2p602AjRrqtlzXgZ8H/5PtAjdMaDA28c+6JW5Z9PViJ8inAQTBSsPU1ObP5VSD3rRYP+60SE
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2017 17:11:21.7381 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 39968f00-5c0b-4613-329a-08d51d5dbf3c
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2996
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 17:11:27 -0000

Lou

Suggested text

NEW

3.3 One Document Several Modules

When a document contains several YANG modules, all the tree diagrams
should be placed together, before all the modules.  Each tree diagram
should be preceded by a brief introduction to highlight where one tree
diagram ends and another starts.

If a document contains a single module which is logically a number of
distinct components, the same strategy should be followed; RFC7317
provides a good example of this approach.

/NEW

Like Juergen, I am conflicted as to at what point details like this
should be part of rfc6087bis; I think a paragraph like this does belong
in 'tree-diagrams'.

Tom Petch

----- Original Message -----
From: "Lou Berger" 
To: "t.petch" ; 
Sent: Friday, October 27, 2017 1:38 PM

> Tom,
>
>
> On 10/27/2017 7:08 AM, t.petch wrote:
> > Lou
> >
> > On a slightly different tack, so a slightly modified Subject: line,
> > when an I-D contains multiple modules, some place all the models
> > together and then all the modules, e.g.
> > draft-hares-i2nsf-capability-data-model-04 while others intersperse
the
> > models and the modules, e.g. draft-ietf-lisp-yang-05 .
> >
> > I think the former is superior and should be recommended, especially
> > when, as Sue has done, there is a brief paragraph of text before
each
> > model, so it is very clear where a model ends and another begins.
With
> > the latter, models can be hard to find.
>
> > I see this as dovetailing into Juergen's comments on RFC7317 which,
to
> > me, is really several separate modules packaged as one, so the
> > separation makes excellent sense to a reader.
> >
> > Where the I-D is already several modules, then do as RFC7317 has
done.
> Sure, Do you have text you'd like to propose?
>
>
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Lou Berger" 
> > To: 
> > Sent: Wednesday, October 25, 2017 2:13 PM
> >
> >> Hi,
> >>
> >> This version addresses all known / open issues in the draft known
to
> >> the authors.
> >>
> >> The changes are as follows:
> >> - Added groupings and yang-data descriptions
> >> - Added Comments, Long Diagrams and Security Considerations
sections
> >> - Clarified representation of schema mount points and
representation
> > of
> >> modules exposed using schema mount.
> >> - Miscellaneous editorial changes
> >>
> >> Lou (for draft authors)
> >>
> >> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
> >>>         Authors         : Martin Bjorklund
> >>>                           Lou Berger
> >>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
> >>> Pages           : 11


From nobody Fri Oct 27 10:16:37 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD5513B2BB for ; Fri, 27 Oct 2017 10:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uxll_0LZKkC for ; Fri, 27 Oct 2017 10:16:33 -0700 (PDT)
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 AB3CE138A38 for ; Fri, 27 Oct 2017 10:16:32 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id g70so8159084lfl.3 for ; Fri, 27 Oct 2017 10:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C69pmwLiS0vqZCUnelIyJYzTK5+yp/wpZ4+XRVB+A+8=; b=wshm7V8xGvj7Ri72h/eesGx5LY89ylh1OQwHVaIuadL0nUl/hHQ4EtsaiUX8zxR3r3 zpfLnMKeZCHrwhpZTuTcc4Neomt5/neMtJPiKmaOuWpIqFcrbDYwiyLhJKjwZFK5mw3F CAW0VieleVtu+CFqD4IqXWHSoX5MOdU8wk5FBPUrqtIlBBVIL1oliCOKqhSl3Hh7x/Vq Qo0MT5oTKvic7MOzAqWkkAqOX///Kj2+NkJ6PuchvG0MtfiDi5Ca113zfT9Q7YOk1t+M 6DNBL5/ylF3Ylv4LISfTZJoUecAQiasDZQzZeDvQ610K+NVBdr0x3sj5DYZWw84QpGcq NByg==
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=C69pmwLiS0vqZCUnelIyJYzTK5+yp/wpZ4+XRVB+A+8=; b=Pd0qYDsoTAqgNmgtbUEutb7AR/wGZ1SEUJAeUC+2aBhpc06+kgFvKsxT66bpZ3P/wj tZtzHr774GJhbzmx/211IpG8bICV9yaCd2cbqq/OPEbR7pM45WvDhIHvGYcKPHi+jXyr Az3YpyeQuGAa+yUK1gu+KSgbmWjzBpAtdAoGKcfs4mo24BM2nTJqy4YYVu1cM42Zw0s9 QhscR4qJUazo26UD8tcxsvxqYrLZAr3/GmpBvYW15tFzTWqE+mgV1TZnmr2/seloKO37 U4HODj+A7yzh5+m5PRGr5uX59TyBJ6bsOrE1TfDe5xe3SLs3HZRQGKUvUV3VN5VjX9Ax Nssw==
X-Gm-Message-State: AMCzsaXX3ygUvgVqrbTxjioE5Pr5Cy/Ss5SA1f/49CbI5NkZjj6SpQGE ahWFFK6RuqSVolwdZQkEgBJEE1VPv10uV1Gg4FkBUw==
X-Google-Smtp-Source: ABhQp+Se1MaCWFOHXmQ2nZ2SXw5nPF+FogauN/wCzcdlm7p2AgJJzrretyYwUn8TxeiDqm/dl3Cs3xIfkvaRDNONOak=
X-Received: by 10.46.83.25 with SMTP id h25mr480844ljb.158.1509124590929; Fri, 27 Oct 2017 10:16:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Fri, 27 Oct 2017 10:16:29 -0700 (PDT)
In-Reply-To: <58770c00-2d4a-f5b2-c0bf-cf52d680577a@labn.net>
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <010301d34e7b$1d5303c0$4001a8c0@gateway.2wire.net>  <20171026221736.cl3kpzo2i7zaa4qh@elstar.local> <3cb344fe-2d49-3fd1-90ad-e6ffe0734dc7@labn.net> <20171026234123.pt65l6ctgmx2hd55@elstar.local> <15f5d46ec50.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171027105159.up6ec5xwbcy75hcr@elstar.local> <34dbaaaa-8a06-f980-7bf8-4a54aa117423@labn.net> <20171027115700.u5xwq5xw347jbclp@elstar.local> <58770c00-2d4a-f5b2-c0bf-cf52d680577a@labn.net>
From: Andy Bierman 
Date: Fri, 27 Oct 2017 10:16:29 -0700
Message-ID: 
To: Lou Berger 
Cc: "t.petch" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403043601422a1d83055c8a7371"
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 17:16:35 -0000

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

Hi,

I do not agree that 6087bis should contain every micro-managed detail
that could possibly pertain to YANG, such as what section the
YANG diagram belongs in, or what exact pyang settings should be
used in every possible usage scenario.

It seems obvious that a 36 page tree diagram for a 47 page module is absurd.
Use a lower tree depth or manually replace subtrees with ...


Andy


On Fri, Oct 27, 2017 at 5:36 AM, Lou Berger  wrote:

> Juergen,
>
>
> On 10/27/2017 7:57 AM, Juergen Schoenwaelder wrote:
> > On Fri, Oct 27, 2017 at 07:04:24AM -0400, Lou Berger wrote:
> >>> We should encourage authors to split large diagrams into manageable
> >>> pieces. Sometimes suppressing lots of statistics counters helps,
> >>> sometimes showing which groupings are used instead of their expansion
> >>> helps. Sometimes it helps to separate major branches of a tree and to
> >>> discuss them separately. We should encourage authors to do these
> >>> things.
> >> I agree with this too, and this was the goal of the current text.
> >>> Perhaps we need to state clearly that it is not necessary to
> >>> include a plain fully expanded tree diagram.
> >> Please propose text for the draft!
> > Personally, I think usage guidelines do not belong into the yang tree
> > document in the first place. Having the document just define what tree
> > diagrams are would be my preference, leaving usage guidelines to our
> > guidelines document.
>
> Having a guidelines document that evolves naturally over time is just
> fine, much like coding conventions.  But trying to bundle or wait for
> the convention update both increases the cost of doing guidelines and
> leaves a time window when the guidelines are not documented.  While in
> some cases this may just fine, I think in this case it would leave much
> "folklore" undocumented.  In other words, I think we should capture the
> guidelines as best as we can in this document. As I think I've stated
> publicly before, I also think the we as WG have to figure out how to
> work more "nimbly" by resisting the temptation to have big documents
> that cover all aspects of the particular topic at once.
>
> I do think your observation on having two sets of guidelines is correct
> and not a good thing.  We can address this quite simply by (a) marking
> this document as updating 6087bis and (b) ensuring we have a full
> replacement to the tree guidelines provided in that document.
>
> >  Section 3.4 of 6087bis talks about tree diagrams
> > and I would prefer to have guidelines text in one place. But perhaps a
> > clear separation of 'here is stuff' from 'this is how we suggest to
> > use stuff' is difficult in practice. But what we have here is that we
> > now have two places where advice is given how to use stuff...
> >
> > That said, RFC 6087bis says:
> >
> >    YANG tree diagrams provide a concise representation of a YANG module,
> >    and SHOULD be included to help readers understand YANG module
> >    structure. Tree diagrams MAY be split into sections to correspond to
> >    document structure.
> >
> > With all the capital letters in place, the text might cause people to
> > draw the wrong conclusion that they have to include plain tree
> > diagrams. The text does not give a good explanation when a split
> > should be considered or that a full plain dump may not be needed or
> > where to find good examples of diagrams broken into pieces. The text
> > in the yang tree diagram document is actually better in this regard.
> >
> > The example in section 3.4 of RFC 6087bis is actually repeating the
> > non-NDMA /foo /foo-state style, well, we are getting off topic.
> >
> >>> In the case of draft-ietf-teas-yang-te-topo-12.txt, the fully expanded
> >>> tree diagram (36 pages) is simply in no good relation with the size of
> >>> the definitions (47 pages). And the authors of this document do the
> >>> right thing, they provide overview diagrams that leave out lots of
> >>> details and that are comprehensible. So is it valuable to keep the
> >>> full dump in the document?
> >> I personally don't think so, and questioned its usefulness.  I also
> >> suggested moving to an appendix if they really wanted to keep it.  For
> >> whatever reason they decided they wanted to keep it which is, of course,
> >> within their purview.
> >>
> >> So, I think the question for us is: what, beyond the change you suggest
> >> above, add to the tree draft to cover cases where authors really want to
> >> include such long trees?
> > At the end, WGs decide with the input from the authors, reviewers
> > etc. and not everything needs to have rules that we cast into RFCs.
> absolutely agree!
>
> Cheers,
> Lou
> > Perhaps we are better off having a few questions and answers on the
> > FAQ concerning tree diagrams.
> >
> > /js
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I do not agree that 6087bis should =
contain every micro-managed detail
that could possibly pertain to=
 YANG, such as what section the
YANG diagram belongs in, or what =
exact pyang settings should be
used in every possible usage scena=
rio.

It seems obvious that a 36 page tree diagram =
for a 47 page module is absurd.
Use a lower tree depth or manuall=
y replace subtrees with ...


Andy


On Fri, Oct 27, 2017 at 5:36 AM, Lou Berger <lberger@labn.net>=
; wrote:
Juergen,





On 10/27/2017 7:57 AM, Juergen Schoenwaelder wrote:

> On Fri, Oct 27, 2017 at 07:04:24AM -0400, Lou Berger wrote:

>>> We should encourage authors to split large diagrams into manag=
eable

>>> pieces. Sometimes suppressing lots of statistics counters help=
s,

>>> sometimes showing which groupings are used instead of their ex=
pansion

>>> helps. Sometimes it helps to separate major branches of a tree=
 and to

>>> discuss them separately. We should encourage authors to do the=
se

>>> things.

>> I agree with this too, and this was the goal of the current text.<=
br>
>>> Perhaps we need to state clearly that it is not necessary to
>>> include a plain fully expanded tree diagram.

>> Please propose text for the draft!

> Personally, I think usage guidelines do not belong into the yang tree<=
br>
> document in the first place. Having the document just define what tree=


> diagrams are would be my preference, leaving usage guidelines to our
> guidelines document.



Having a guidelines document that evolves naturally over time is just

fine, much like coding conventions.=C2=A0 But trying to bundle or wait for<=
br>
the convention update both increases the cost of doing guidelines and

leaves a time window when the guidelines are not documented.=C2=A0 While in=


some cases this may just fine, I think in this case it would leave much

"folklore" undocumented.=C2=A0 In other words, I think we should =
capture the

guidelines as best as we can in this document. As I think I've stated
publicly before, I also think the we as WG have to figure out how to

work more "nimbly" by resisting the temptation to have big docume=
nts

that cover all aspects of the particular topic at once.



I do think your observation on having two sets of guidelines is correct

and not a good thing.=C2=A0 We can address this quite simply by (a) marking=


this document as updating 6087bis and (b) ensuring we have a full

replacement to the tree guidelines provided in that document.



>=C2=A0 Section 3.4 of 6087bis talks about tree diagrams

> and I would prefer to have guidelines text in one place. But perhaps a=


> clear separation of 'here is stuff' from 'this is how we s=
uggest to

> use stuff' is difficult in practice. But what we have here is that=
 we

> now have two places where advice is given how to use stuff...

>

> That said, RFC 6087bis says:

>

>=C2=A0 =C2=A0 YANG tree diagrams provide a concise representation of a =
YANG module,

>=C2=A0 =C2=A0 and SHOULD be included to help readers understand YANG mo=
dule

>=C2=A0 =C2=A0 structure. Tree diagrams MAY be split into sections to co=
rrespond to

>=C2=A0 =C2=A0 document structure.

>

> With all the capital letters in place, the text might cause people to<=
br>
> draw the wrong conclusion that they have to include plain tree

> diagrams. The text does not give a good explanation when a split

> should be considered or that a full plain dump may not be needed or
> where to find good examples of diagrams broken into pieces. The text
> in the yang tree diagram document is actually better in this regard.
>

> The example in section 3.4 of RFC 6087bis is actually repeating the
> non-NDMA /foo /foo-state style, well, we are getting off topic.

>

>>> In the case of draft-ietf-teas-yang-te-topo-12.txt, the f=
ully expanded

>>> tree diagram (36 pages) is simply in no good relation with the=
 size of

>>> the definitions (47 pages). And the authors of this document d=
o the

>>> right thing, they provide overview diagrams that leave out lot=
s of

>>> details and that are comprehensible. So is it valuable to keep=
 the

>>> full dump in the document?

>> I personally don't think so, and questioned its usefulness.=C2=
=A0 I also

>> suggested moving to an appendix if they really wanted to keep it.=
=C2=A0 For

>> whatever reason they decided they wanted to keep it which is, of c=
ourse,

>> within their purview.

>>

>> So, I think the question for us is: what, beyond the change you su=
ggest

>> above, add to the tree draft to cover cases where authors really w=
ant to

>> include such long trees?

> At the end, WGs decide with the input from the authors, reviewers

> etc. and not everything needs to have rules that we cast into RFCs.
absolutely agree!



Cheers,

Lou

> Perhaps we are better off having a few questions and answers on the
> FAQ concerning tree diagrams.

>

> /js

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--f403043601422a1d83055c8a7371--


From nobody Fri Oct 27 10:22:00 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C28138A38 for ; Fri, 27 Oct 2017 10:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AiITiC2F7ub for ; Fri, 27 Oct 2017 10:21:56 -0700 (PDT)
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 43F9213F418 for ; Fri, 27 Oct 2017 10:21:55 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 155FE691; Fri, 27 Oct 2017 19:21:54 +0200 (CEST)
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 M98TdMlUDAgr; Fri, 27 Oct 2017 19:21:52 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Oct 2017 19:21:54 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F34D42010B; Fri, 27 Oct 2017 19:21:53 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BlDF5RX4ZsyK; Fri, 27 Oct 2017 19:21:53 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33E1E2010A; Fri, 27 Oct 2017 19:21:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 956404140172; Fri, 27 Oct 2017 19:20:27 +0200 (CEST)
Date: Fri, 27 Oct 2017 19:20:27 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Cc: netmod@ietf.org, Lou Berger 
Message-ID: <20171027172027.f6ki7wljdwmwzwib@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "t.petch" , netmod@ietf.org, Lou Berger 
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <03bb01d34f14$2907e5c0$4001a8c0@gateway.2wire.net> <63fca2cd-e41e-5d79-2290-41e0d0541ccb@labn.net> <013401d34f46$42976740$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <013401d34f46$42976740$4001a8c0@gateway.2wire.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 17:21:58 -0000

Why do we come up with such rules in the first place? It really
depends on the modules and their relationship and it is the
responsibility of the WG, the authors, the reviewers to produce a
reasonable document.

/js

On Fri, Oct 27, 2017 at 06:08:31PM +0100, t.petch wrote:
> Lou
> 
> Suggested text
> 
> NEW
> 
> 3.3 One Document Several Modules
> 
> When a document contains several YANG modules, all the tree diagrams
> should be placed together, before all the modules.  Each tree diagram
> should be preceded by a brief introduction to highlight where one tree
> diagram ends and another starts.
> 
> If a document contains a single module which is logically a number of
> distinct components, the same strategy should be followed; RFC7317
> provides a good example of this approach.
> 
> /NEW
> 
> Like Juergen, I am conflicted as to at what point details like this
> should be part of rfc6087bis; I think a paragraph like this does belong
> in 'tree-diagrams'.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Lou Berger" 
> To: "t.petch" ; 
> Sent: Friday, October 27, 2017 1:38 PM
> 
> > Tom,
> >
> >
> > On 10/27/2017 7:08 AM, t.petch wrote:
> > > Lou
> > >
> > > On a slightly different tack, so a slightly modified Subject: line,
> > > when an I-D contains multiple modules, some place all the models
> > > together and then all the modules, e.g.
> > > draft-hares-i2nsf-capability-data-model-04 while others intersperse
> the
> > > models and the modules, e.g. draft-ietf-lisp-yang-05 .
> > >
> > > I think the former is superior and should be recommended, especially
> > > when, as Sue has done, there is a brief paragraph of text before
> each
> > > model, so it is very clear where a model ends and another begins.
> With
> > > the latter, models can be hard to find.
> >
> > > I see this as dovetailing into Juergen's comments on RFC7317 which,
> to
> > > me, is really several separate modules packaged as one, so the
> > > separation makes excellent sense to a reader.
> > >
> > > Where the I-D is already several modules, then do as RFC7317 has
> done.
> > Sure, Do you have text you'd like to propose?
> >
> >
> > > Tom Petch
> > >
> > > ----- Original Message -----
> > > From: "Lou Berger" 
> > > To: 
> > > Sent: Wednesday, October 25, 2017 2:13 PM
> > >
> > >> Hi,
> > >>
> > >> This version addresses all known / open issues in the draft known
> to
> > >> the authors.
> > >>
> > >> The changes are as follows:
> > >> - Added groupings and yang-data descriptions
> > >> - Added Comments, Long Diagrams and Security Considerations
> sections
> > >> - Clarified representation of schema mount points and
> representation
> > > of
> > >> modules exposed using schema mount.
> > >> - Miscellaneous editorial changes
> > >>
> > >> Lou (for draft authors)
> > >>
> > >> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
> > >>>         Authors         : Martin Bjorklund
> > >>>                           Lou Berger
> > >>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
> > >>> Pages           : 11
> 
> _______________________________________________
> 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 Oct 27 10:46:27 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A9B13F5AF for ; Fri, 27 Oct 2017 10:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.69
X-Spam-Level: 
X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 (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 duKzYlvIjQ_E for ; Fri, 27 Oct 2017 10:46:21 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0105.outbound.protection.outlook.com [104.47.0.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE3C13F5AB for ; Fri, 27 Oct 2017 10:46:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+8FrXkoMf7KzDHa59f3Tt8Af1SYIqo2KgF2wOGtjrQo=; b=NZvlgmuYYmG9t05Ti5rave9+hDOFAt03z12xs1/RFTyv4VINAIc14tjjlL5rIxKjU/KPSiM5G+17xP3KnkrMyUunzDKY356GdYvZLXB8z2WPZyTgcGyjXI0lZhLN5lMAQn0dQwtZ++XOc0e9A/SNXoFxNfyvIMAQMfklRPy9V/E=
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com (10.163.187.158) by AM3PR07MB1122.eurprd07.prod.outlook.com (10.163.187.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Fri, 27 Oct 2017 17:46:17 +0000
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527]) by AM3PR07MB1124.eurprd07.prod.outlook.com ([fe80::746c:4eb1:1f6a:9527%14]) with mapi id 15.20.0178.003; Fri, 27 Oct 2017 17:46:17 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] leafref to lists that contain system-controlled entries
Thread-Index: AdNETq1mxw6yfiPkS3eq6pji6usdqwCHGGKAAXuDgKAAGoxYAAChbbWQ
Date: Fri, 27 Oct 2017 17:46:17 +0000
Message-ID: 
References:  <63575583-0baa-b0eb-c729-9772988b4f22@cisco.com>  <2e520b70-9f5b-3101-d0fa-ae83dfe34fb6@cisco.com>
In-Reply-To: <2e520b70-9f5b-3101-d0fa-ae83dfe34fb6@cisco.com>
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=jason.sterne@nokia.com; 
x-originating-ip: [135.245.20.24]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1122; 6:tKB3QPU4dg9KBad/I876ZjBiws0U4LTU+QopUJPQId7enSph78B9gm+22ywxiQV8SDrp6p/UjP2ZDB+oaNNU8FV1N7c3T2QMQgwFjd9jGqbgc4WZazZGGyX3GkNcN3E7U4Dn1Zd7sZ8GdlVjnYyjU6bEdonpWcrG40q0Cr5g5AjAbfl2FTJmd4BVxDkFoY7oUadMT0dwXvVMNAWSWsn1rocU4HS2fQn7MZt0hQFzadKkS3G6mGswSPUSCoBqb34pX5FCqL/yvEiWmhy42XIBYijsfedRG2oG2BbhdrlSzqD1HjXXQcG87ehiMchB+Nnc/fvmaEiWVP285rWvzkUkqqWyboD/fici35RttLeW7zg=; 5:Nod4+6eWgRiUgQyo1z/GZ6oJB6A79OgoRaPq7qwkNFcA6MxUnmaCJMnroapurdPXUpZmk4g3SBUawjM6FQot5H5sHk/twtp0GyfL/4iqczHkDMza3Isjv5JbhelNbcN/ebtPxQUCA5dNzpjHUni3qhmAU1BoquDypua1iY59yok=; 24:oyg0gGQIChvtJBEFGlM4j1lShpO1pNXsbo0IP4GqEgOFDlGmXGek4I7m4lvTtJ3WMzh++zIyfuUqZCDFeaWUfWAzyBc9zkBAC83ZJGm4RWU=; 7:1qoLcdruFWJzKvJMwn++s3eh1+7iixlzLLCebGrbeubkbssxlHNTLzYGDCRxmAtpJDq23gDgfh03pLq4HHKlq4T/83j6lvs4wTepJ/1I8Uid/nCiU2PGVh1XG0h00foAPqtBzfi38iYEpscrDLE6QsNwrmXyGVy3XIKHxsOKRF7+DoMeeW7GJBQe3zFpetTR8XrlX/cibLfpxcik40aAEfISPH1Ml9dA+DVXytgzY1EwDfSec/zS9k6/q0mCJ6LS
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 73e3cfba-1f86-4cf4-6653-08d51d62a03a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603199); SRVR:AM3PR07MB1122; 
x-ms-traffictypediagnostic: AM3PR07MB1122:
x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(788757137089)(95692535739014)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1122; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1122; 
x-forefront-prvs: 0473A03F3F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(53754006)(51444003)(189002)(24454002)(199003)(8676002)(81156014)(6506006)(53546010)(25786009)(966005)(68736007)(6436002)(6246003)(93886005)(606006)(2906002)(9326002)(74316002)(14454004)(66066001)(97736004)(2501003)(86362001)(81166006)(478600001)(5250100002)(76176999)(8936002)(50986999)(55016002)(99286003)(54356999)(33656002)(229853002)(53936002)(7736002)(110136005)(6306002)(7696004)(54896002)(5660300001)(101416001)(236005)(316002)(3660700001)(3846002)(2950100002)(790700001)(2900100001)(6116002)(102836003)(9686003)(105586002)(189998001)(3280700002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1122; H:AM3PR07MB1124.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)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM3PR07MB112435038E7693D15A6BC9089B5A0AM3PR07MB1124eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 73e3cfba-1f86-4cf4-6653-08d51d62a03a
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 17:46:17.4038 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1122
Archived-At: 
Subject: Re: [netmod] leafref to lists that contain system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 17:46:25 -0000

--_000_AM3PR07MB112435038E7693D15A6BC9089B5A0AM3PR07MB1124eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Rob,
Please see inline.
Rgds,
Jason

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: Tuesday, October 24, 2017 8:26
To: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf=
.org
Subject: Re: [netmod] leafref to lists that contain system-controlled entri=
es


Hi Jason,

Please see further comments inline ...

On 24/10/2017 00:58, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Thanks Rob.  Please see below.
Jason

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: Monday, October 16, 2017 6:40
To: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf.org
Subject: Re: [netmod] leafref to lists that contain system-controlled entri=
es


Hi Jason,

On 13/10/2017 19:43, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Hi all,

There are a few threads on the mailing list that touch on the concept of sy=
stem-controlled resources (mostly list entries):

https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0
https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w
https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0

A few drafts & RFCs also refer to the concept:
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
https://tools.ietf.org/html/rfc7223

Several vendor implementations have list entries (instance data) that are p=
opulated by the server and can be referenced (leafref) from other places in=
 the configuration.  These system entries are useful pre-created policies, =
interfaces, etc that can then be used (and referred-to) by operators in the=
ir explicit configuration.

If those entries are only expected to exist in the  datastore,=
 then in theory any references to them in user created configuration will c=
ause a validation problem in the candidate/running (missing leafref target)=
.

One solution discussed in the mailing lists is to change every reference to=
 lists that could contain a system created entry to a "require-instance fal=
se" leafref.  But then some useful validation is lost.  In many cases the m=
odel is more correctly "require-instance true" but the set of targets inclu=
des the system create entries.

I agree that this is not a good general solution for system created configu=
ration that is always expected to exist on the device because some of the u=
seful validation is lost.

But I think that this solution does work well were the system created entri=
es are truly dynamic in nature, e.g. it seems to work well for the topology=
 YANG module where the topology may be explicitly configured, but would mor=
e normally be learned dynamically from protocol interactions, or perhaps be=
 configured via a dynamic configuration protocol.

[>>JTS] OK - I think I follow you here.  You're saying that if there are re=
ferences to truly dynamic entries, then since those entries will come and g=
o (vs static bootup-time system entries that are always there), references =
to them will more likely be "require-instance false".   But that does mean =
the system has to allow references to non-existent entries, and you lose va=
lidation. You also risk errors like referencing a name that is just 1 char =
different from what you really wanted but the system can't tell you that yo=
u got it wrong.

Yes.  I don't think that you can solve this during existing YANG datastore =
validation, as it is defined today.

But I also think that NETCONF/YANG is potentially missing an RPC that is a =
step beyond validation, but before actually applying configuration.

YANG and the NMDA datastores draft makes it clear that both  and <=
intended> are always valid datastores. This means that the validation rules=
 for these datastores really should not depend on the current hardware in a=
 device if that hardware could be removed or change.  Otherwise, if you all=
ow validation to depend on the current hardware capabilities, then if someo=
ne pulls out a linecard, that would cause a previously valid configuration =
to immediately become invalid, violating the rule that /=
 are always valid.
[>>JTS] In implementations that support templating today, the  is =
not always valid.  It is only upon expansion of the templates that you end =
up with a valid datastore (i.e. in the ).  The template may provi=
de missing mandatory parms, provide the actual targets of leafrefs, etc.
  I can't see a way to actually make  or  valid with th=
e concept of templates  (unless we define validity as after a temporary exp=
ansion in some post-processed version of the  - but that would jus=
t be the ).
  This problem of validity isn't specific to dynamic behavior (e.g. hardwar=
e coming & going), or to system provisioned objects.  It is a problem just =
with static config as well.


I think that a potential solution to this problem, is that a new NETCONF RP=
C could be defined that is a "" operation.   Pro=
cessing during this new RPC would be able to check against current system r=
esources, current hardware capabilities, etc, and would be designed to indi=
cate whether the system expects (but does not guarantee) that the configura=
tion would completely apply successfully without any errors or unapplied co=
nfiguration.
[>>JTS] "completely apply successfully" does not necessarily mean the candi=
date or running are "valid" against the YANG model.
Configuration datastores would not have to always conform to this constrain=
t, so that if an operator changed or removed a linecard, the configuration =
would still be "valid" (as per NMDA and RFC7950 rules) but would fail a sub=
sequent "should-successfully-apply" check.
[>>JTS] I see it the other way around.  With template support, a  =
datastore will usually pass the "should-succesfully-apply" criteria but won=
't be 'valid'.






Another solution discussed is to have the system created entries appear in =
the  datastore (as part of template/expansion).  That would make =
validation pass on the intended datastore, but then the candidate/running/s=
tartup datastores would not be valid (would be missing leafref targets if a=
ny part of the config refers to system created entries).  THis sounds simil=
ar to the problem that has been discussed in the past about the fact that t=
emplates (in the running) basically mean the running/candidate aren't neces=
sarily valid (until after template expansion, which means only the intended=
 would be valid).

I think that this solution is OK, but not necessarily ideal.

As you say, it means that // may not be valid,=
 which I see as quite a big down side.  Longer term, I think that it would =
be a good aim to allow the configuration to be validated off the device, if=
 a client desired to do so.





Another approach could be to actually have those system created entries sho=
w up in running/candidate.  That would ensure that references to those entr=
ies are valid.  But if the whole concept of templates just cause the runnin=
g/candidate to not be valid anyways maybe we wouldn't worry about the inval=
id aspect of references to system created list entries ?

I know that quite a few implementations do this today, but I'm generally no=
t a fan of the system modifying .  It seems that an overall archit=
ecture is much cleaner if  has a single source of truth and hence =
can be exclusively controlled by the client.

But I also like the approach where the client (rather than the device) expl=
icitly writes these default entries into the configuration, if they are ref=
erenced elsewhere by the configuration, to make the configuration "complete=
".  E.g. if part of the configuration references the loopback0 interface th=
en also explicitly add the necessary loopback0 configuration to instantiate=
 the "loopback0" interface.  When this configuration is pushed to the devic=
e (i.e. using merge or replace operation semantics) then the system should =
silently accept/ignore the explicit configuration to create the loopback0 i=
nterface if it already exists on the system.

[>>JTS] Yes - that is another option and I like it.  If I follow you correc=
tly, the server would never return these system entries in a  u=
nless the client/operator had already explicitly 'created' them.
So the operator has the option to make the system entries visible or not.
Yes, exactly.




I think the server should still accept references to the system entries eve=
n if the client/operator hasn't explicitly created them.  The whole point i=
s that those system entries are there and waiting for operators to use them=
 from the start (without *having* to explicitly create or define them).   I=
n that case the references would be 'dangling' (unresolved) as far as an of=
fline validation is concerned (but a client could select to fix that by exp=
licitly defining any entries they want to reference).
I think that this is OK.

Effectively, I see that being like a static system provided template for co=
nfiguration that is merged with  to form , which is then=
 validated.
[>>JTS] Yes.  But that means the  or  is not valid (but=
 would pass your  check) , but the  is =
valid.







At the moment, IETF, and other SDOs are busy defining standard YANG models,=
 but for those models to end up being truly generic they also need to have =
consistency about which bits of configuration are always expected to implic=
itly exist on the device.  E.g. considering the example above of configurat=
ion referencing loopback0: if some systems automatically create a loopback0=
 interface and others do not, then a generic configuration needs to handle =
both scenarios.

If IETF standardizes YANG configuration templates, then perhaps it would be=
 good to investigate whether some of these "useful default system propertie=
s" could instead be embodied into one or more standard device templates?  T=
hese templates could then be explicitly referenced in the  configu=
ration.  This may allow  to be small, but still allow it to be "co=
mplete" and able to be validated off the box.
[>>JTS] I'm not clear on this approach.
OK, so this is just an idea:

1) Assume a YANG extension is defined to allow templates to be defined.
2) Further, assume that there is a way to store, and uniquely name some of =
those templates in a standard place.

So, perhaps IETF could define a template like this, which is stored as a we=
ll defined place:



Now, when it comes to the configuration file for your device, it could look=
 like this:
  
    http://yang-templates.ietf.org/ietf-basic-router-v=
1

    ... rest of config as normal.
  

So, the expanded configuration would include the explicit configuration for=
 Loopback0 and Null0 interfaces, but that would be pulled via use of a remo=
te template (the contents of which is probably already cached on the device=
).
[>>JTS] Sorry for harping on this point -> but this still means the candida=
te/running are not valid.  It is only post-expansion that a datastore becom=
es valid against the YANG model.   I'm not saying this "use-remote-template=
" idea doesn't have merit, but it still leaves us with the problem of inval=
id running/candidate.

It is also causing me to think that perhaps the transition from running->in=
tended could also include the addition of the system provisioned objects (i=
f they haven't been explicitly configured by the client as discussed above)=
 as part of that 'expansion'.



How would the templates be referenced in the  ?  Can you give me a=
n example ? (is this different than a direct reference to a system created =
entry that I am talking about ?)
The above is just an idea.  Normally I would expect configuration templates=
 to be defined in the running configuration.  But here I was considering th=
e idea that a template is predefined in some way, and then referenced, so t=
hat it doesn't have to be provided inline in the running configuration.



How would this allow  to be small ? Do the templates contain the f=
ull definition of the system created entries ?
Yes, I was assuming that the template could contain what might normally be =
represented as system created entries today.  Standard templates could eith=
er be defined by SDOs, vendors, or operators, as long as there is a way to =
reference them.

Thanks,
Rob





Thanks,
Rob





Rgds,
Jason






_______________________________________________

netmod mailing list

netmod@ietf.org

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



--_000_AM3PR07MB112435038E7693D15A6BC9089B5A0AM3PR07MB1124eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Rob,<=
/span>


Please see inline.<=
o:p>


Rgds,


Jason


 








From:=
 Robert Wilton [mailto:rwilton@cisco.com]


Sent: Tuesday, October 24, 2017 8:26

To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>=
; netmod@ietf.org

Subject: Re: [netmod] leafref to lists that contain system-controlle=
d entries






 


Hi Jason,


Please see further comments inline ...


 




On 24/10/2017 00:58, Sterne, Jason (Nokia - CA/Ottaw=
a) wrote:






Thanks Rob.  P=
lease see below.


Jason


 <=
/o:p>








From:=
 Robert Wilton [mailto:rwilton@cisco.com]


Sent: Monday, October 16, 2017 6:40

To: Sterne, Jason (Nokia - CA/Ottawa) 
<jason.sterne@nokia.com>; netm=
od@ietf.org

Subject: Re: [netmod] leafref to lists that contain system-controlle=
d entries






 


Hi Jason,


 




On 13/10/2017 19:43, Sterne, Jason (Nokia - CA/Ottaw=
a) wrote:






Hi all,


 


There are a few threads on the mailing list that tou=
ch on the concept of system-controlled resources (mostly list entries):


 


https://mailarchive.ietf.org/arch/msg/netm=
od/3fTSHIh_MfHzmuDCoicAGiXA2E0


https://mailarchive.ietf.org/arch/msg/netm=
od/KIsSgKByQWpqYzA4i6Bwc8fuH3w


https://mailarchive.ietf.org/arch/msg/netm=
od/mjLJdiYErtNG41dJ5bJ5ji07cz0


 


A few drafts & RFCs also refer to the concept:


https://tools.ietf.org/html/draft-ietf-netmod-r=
evised-datastores-04


http=
s://tools.ietf.org/html/rfc7223


 


Several vendor implementations have list entries (in=
stance data) that are populated by the server and can be referenced (leafre=
f) from other places in the configuration.  These system entries are u=
seful pre-created policies, interfaces,
 etc that can then be used (and referred-to) by operators in their explicit=
 configuration.


 


If those entries are only expected to exist in the &=
lt;operational> datastore, then in theory any references to them in user=
 created configuration will cause a validation problem in the candidate/run=
ning (missing leafref target).


 


One solution discussed in the mailing lists is to ch=
ange every reference to lists that could contain a system created entry to =
a “require-instance false” leafref.  But then some useful =
validation is lost.  In many cases the model is more
 correctly “require-instance true” but the set of targets inclu=
des the system create entries.






I agree that this is not a good general solution for system created configu=
ration that is always expected to exist on the device because some of the u=
seful validation is lost.



But I think that this solution does work well were the system created entri=
es are truly dynamic in nature, e.g. it seems to work well for the topology=
 YANG module where the topology may be explicitly configured, but would mor=
e normally be learned dynamically
 from protocol interactions, or perhaps be configured via a dynamic configu=
ration protocol.


 =



[>>JTS]=
 OK – I think I follow you here.  You’re saying that if th=
ere are references to truly dynamic entries, then since those entries will =
come and go (vs static bootup-time system entries that are
 always there), references to them will more likely be “require-insta=
nce false”.   But that does mean the system has to allow re=
ferences to non-existent entries, and you lose validation. You also risk er=
rors like referencing a name that is just 1 char different
 from what you really wanted but the system can’t tell you that you g=
ot it wrong.








Yes.  I don't think that you can solve this during existing YANG datas=
tore validation, as it is defined today.



But I also think that NETCONF/YANG is potentially missing an RPC that is a =
step beyond validation, but before actually applying configuration.



YANG and the NMDA datastores draft makes it clear that both <running>=
 and <intended> are always valid datastores. This means that the vali=
dation rules for these datastores really should not depend on the current h=
ardware in a device if that hardware could be
 removed or change.  Otherwise, if you allow validation to depend on t=
he current hardware capabilities, then if someone pulls out a linecard, tha=
t would cause a previously valid configuration to immediately become invali=
d, violating the rule that <running>/<intended>
 are always valid.


[>>JTS]=
 In implementations that support templating today, the <running> is n=
ot always valid.  It is only upon expansion of the templates that you =
end up with a valid datastore (i.e. in the <intended>). 
 The template may provide missing mandatory parms, provide the actual targe=
ts of leafrefs, etc.


  I can&=
#8217;t see a way to actually make <running> or <candidate> val=
id with the concept of templates  (unless we define validity as after =
a temporary expansion in some post-processed version of the <running>
 - but that would just be the <intended>).<=
/p>

  This p=
roblem of validity isn’t specific to dynamic behavior (e.g. hardware =
coming & going), or to system provisioned objects.  It is a proble=
m just with static config as well.






I think that a potential solution to this problem, is that a new NETCONF RP=
C could be defined that is a "<should-successfully-apply>" =
operation.   Processing during this new RPC would be able to chec=
k against current system resources, current hardware capabilities,
 etc, and would be designed to indicate whether the system expects (but doe=
s not guarantee) that the configuration would completely apply successfully=
 without any errors or unapplied configuration. 



[>>JTS]=
 “completely apply successfully” does not necessarily mean the =
candidate or running are “valid” against the YANG model.


Configuration datastores would not have to always co=
nform to this constraint, so that if an operator changed or removed a linec=
ard, the configuration would still be "valid" (as per NMDA and RF=
C7950 rules) but would fail a subsequent "should-successfully-apply&qu=
ot;
 check.


[>>JTS]=
 I see it the other way around.  With template support, a <running&=
gt; datastore will usually pass the “should-succesfully-apply” =
criteria but won’t be ‘valid’.<=
/p>




















 


Another solution discussed is to have the system cre=
ated entries appear in the <intended> datastore (as part of template/=
expansion).  That would make validation pass on the intended datastore=
, but then the candidate/running/startup datastores
 would not be valid (would be missing leafref targets if any part of the co=
nfig refers to system created entries).  THis sounds similar to the pr=
oblem that has been discussed in the past about the fact that templates (in=
 the running) basically mean the running/candidate
 aren’t necessarily valid (until after template expansion, which mean=
s only the intended would be valid).






I think that this solution is OK, but not necessarily ideal.



As you say, it means that <running>/<candidate>/<startup>=
 may not be valid, which I see as quite a big down side.  Longer term,=
 I think that it would be a good aim to allow the configuration to be valid=
ated off the device, if a client desired to do so.














 


Another approach could be to actually have those sys=
tem created entries show up in running/candidate.  That would ensure t=
hat references to those entries are valid.  But if the whole concept o=
f templates just cause the running/candidate
 to not be valid anyways maybe we wouldn’t worry about the invalid as=
pect of references to system created list entries ?






I know that quite a few implementations do this today, but I'm generally no=
t a fan of the system modifying <running>.  It seems that an ove=
rall architecture is much cleaner if <running> has a single source of=
 truth and hence can be exclusively controlled by
 the client.



But I also like the approach where the client (rather than the device) expl=
icitly writes these default entries into the configuration, if they are ref=
erenced elsewhere by the configuration, to make the configuration "com=
plete".  E.g. if part of the configuration
 references the loopback0 interface then also explicitly add the necessary =
loopback0 configuration to instantiate the "loopback0" interface.=
  When this configuration is pushed to the device (i.e. using merge or=
 replace operation semantics) then the system should
 silently accept/ignore the explicit configuration to create the loopback0 =
interface if it already exists on the system.


 =



[>>JTS]=
 Yes – that is another option and I like it.  If I follow you co=
rrectly, the server would never return these system entries in a <get-co=
nfig> unless the client/operator had already explicitly
 ‘created’ them.   


So the operat=
or has the option to make the system entries visible or not.=







Yes, exactly.














 =



I think the s=
erver should still accept references to the system entries even if the clie=
nt/operator hasn’t explicitly created them.  The whole point is =
that those system entries are there and waiting
 for operators to use them from the start (without *having* to explicitly c=
reate or define them).   In that case the references would be =
216;dangling’ (unresolved) as far as an offline validation is concern=
ed (but a client could select to fix that by explicitly
 defining any entries they want to reference).





I think that this is OK.



Effectively, I see that being like a static system provided template for co=
nfiguration that is merged with <running> to form <intended>, w=
hich is then validated.<=
/p>

[>>JTS]=
 Yes.  But that means the <running> or <candidate> is not =
valid (but would pass your <should-succesfully-apply> check) , but th=
e <intended> is valid.























At the moment, IETF, and other SDOs are busy defining standard YANG models,=
 but for those models to end up being truly generic they also need to have =
consistency about which bits of configuration are always expected to implic=
itly exist on the device.  E.g.
 considering the example above of configuration referencing loopback0: if s=
ome systems automatically create a loopback0 interface and others do not, t=
hen a generic configuration needs to handle both scenarios.



If IETF standardizes YANG configuration templates, then perhaps it would be=
 good to investigate whether some of these "useful default system prop=
erties" could instead be embodied into one or more standard device tem=
plates?  These templates could then be explicitly
 referenced in the <running> configuration.  This may allow <=
running> to be small, but still allow it to be "complete" and =
able to be validated off the box.


[>>JTS]=
 I’m not clear on this approach. 







OK, so this is just an idea:



1) Assume a YANG extension is defined to allow templates to be defined.

2) Further, assume that there is a way to store, and uniquely name some of =
those templates in a standard place.



So, perhaps IETF could define a template like this, which is stored as a we=
ll defined place:



<template>

  <name>ietf-basic-router-v1</name>

  <config>

    <interfaces>

      <interface>

        <name>Loopback0</name>=
;

        <type>ianaift:loopback=
</type>

      </interface>

      <interface>

        <name>Null0</name&g=
t;

        <type>ianaift:null<=
/type>

      </interface>

    </interfaces> 

  </config>

</template>



Now, when it comes to the configuration file for your device, it could look=
 like this:

  <config>

    <use-remote-template>http://yang-templates.ietf.org/ietf-=
basic-router-v1</use-remote-template>



    ... rest of config as normal.

  </config>



So, the expanded configuration would include the explicit configuration for=
 Loopback0 and Null0 interfaces, but that would be pulled via use of a remo=
te template (the contents of which is probably already cached on the device=
).


[>>JTS]=
 Sorry for harping on this point -> but this still means the candidate/r=
unning are not valid.  It is only post-expansion that a datastore beco=
mes valid against the YANG model.   I’m not saying
 this “use-remote-template” idea doesn’t have merit, but =
it still leaves us with the problem of invalid running/candidate.


 


It is also ca=
using me to think that perhaps the transition from running->intended cou=
ld also include the addition of the system provisioned objects (if they hav=
en’t been explicitly configured by the
 client as discussed above) as part of that ‘expansion’. 














How would the=
 templates be referenced in the <running> ?  Can you give me an =
example ? (is this different than a direct reference to a system created en=
try that I am talking about ?)






The above is just an idea.  Normally I would ex=
pect configuration templates to be defined in the running configuration.&nb=
sp; But here I was considering the idea that a template is predefined in so=
me way, and then referenced, so that it doesn't
 have to be provided inline in the running configuration.














How would thi=
s allow <running> to be small ? Do the templates contain the full def=
inition of the system created entries ?






Yes, I was assuming that the template could contain =
what might normally be represented as system created entries today.  S=
tandard templates could either be defined by SDOs, vendors, or operators, a=
s long as there is a way to reference them.



Thanks,

Rob


















Thanks,

Rob














 


Rgds,


Jason


 













_______________________________________________


netmod mailing list


netmod@ietf.org

https://www.i=
etf.org/mailman/listinfo/netmod




 






 








--_000_AM3PR07MB112435038E7693D15A6BC9089B5A0AM3PR07MB1124eurp_--


From nobody Fri Oct 27 12:40:47 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B870139612 for ; Fri, 27 Oct 2017 12:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSIvB08UfNTy for ; Fri, 27 Oct 2017 12:40:43 -0700 (PDT)
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 80D2F137E0B for ; Fri, 27 Oct 2017 12:40:43 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id C09331E0DA4 for ; Fri, 27 Oct 2017 13:40:40 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id Sjgd1w00W2SSUrH01jgggM; Fri, 27 Oct 2017 13:40:40 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=wU2YTnxGAAAA:8 a=voZKSeMjAAAA:8 a=48vgC7mUAAAA:8 a=nZT61kyedtMgwWHzslEA:9 a=CeDx01oTrxxHmUpt:21 a=GV8UPRuREXzylEK6:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=9_PflfxPP4jfUBPIDKbT: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: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=Pb7oWU2VzA0WKn9JyGGyBeFZI1EXJN/F0STRD3Oe/O8=; b=JxxqhenJVnb1msLcgEnw29pJYx Yj7K6dWJLi+QACM08D7feOVG33d6TiE96QKkw27rzaPdJ5OusBaxUKDlb+HUXxHhau1fL1CL9wk7X mlHUG8M90COyEWCg+Ctg1W2FQ;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:42314 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e8AUf-002aU0-4d; Fri, 27 Oct 2017 13:40:37 -0600
To: "t.petch" , netmod@ietf.org
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <03bb01d34f14$2907e5c0$4001a8c0@gateway.2wire.net> <63fca2cd-e41e-5d79-2290-41e0d0541ccb@labn.net> <013401d34f46$42976740$4001a8c0@gateway.2wire.net> <20171027172027.f6ki7wljdwmwzwib@elstar.local>
From: Lou Berger 
Message-ID: 
Date: Fri, 27 Oct 2017 15:40:36 -0400
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: <20171027172027.f6ki7wljdwmwzwib@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1e8AUf-002aU0-4d
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:42314
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 19:40:46 -0000

On 10/27/2017 01:20 PM, Juergen Schoenwaelder wrote:
> Why do we come up with such rules in the first place? It really
> depends on the modules and their relationship and it is the
> responsibility of the WG, the authors, the reviewers to produce a
> reasonable document.
> 

My personal view - Because having a few knowledgeable people doesn't
scale and not all model writers are at the IETF.

Lou

> /js
> 
> On Fri, Oct 27, 2017 at 06:08:31PM +0100, t.petch wrote:
>> Lou
>>
>> Suggested text
>>
>> NEW
>>
>> 3.3 One Document Several Modules
>>
>> When a document contains several YANG modules, all the tree diagrams
>> should be placed together, before all the modules.  Each tree diagram
>> should be preceded by a brief introduction to highlight where one tree
>> diagram ends and another starts.
>>
>> If a document contains a single module which is logically a number of
>> distinct components, the same strategy should be followed; RFC7317
>> provides a good example of this approach.
>>
>> /NEW
>>
>> Like Juergen, I am conflicted as to at what point details like this
>> should be part of rfc6087bis; I think a paragraph like this does belong
>> in 'tree-diagrams'.
>>
>> Tom Petch
>>
>> ----- Original Message -----
>> From: "Lou Berger" 
>> To: "t.petch" ; 
>> Sent: Friday, October 27, 2017 1:38 PM
>>
>>> Tom,
>>>
>>>
>>> On 10/27/2017 7:08 AM, t.petch wrote:
>>>> Lou
>>>>
>>>> On a slightly different tack, so a slightly modified Subject: line,
>>>> when an I-D contains multiple modules, some place all the models
>>>> together and then all the modules, e.g.
>>>> draft-hares-i2nsf-capability-data-model-04 while others intersperse
>> the
>>>> models and the modules, e.g. draft-ietf-lisp-yang-05 .
>>>>
>>>> I think the former is superior and should be recommended, especially
>>>> when, as Sue has done, there is a brief paragraph of text before
>> each
>>>> model, so it is very clear where a model ends and another begins.
>> With
>>>> the latter, models can be hard to find.
>>>
>>>> I see this as dovetailing into Juergen's comments on RFC7317 which,
>> to
>>>> me, is really several separate modules packaged as one, so the
>>>> separation makes excellent sense to a reader.
>>>>
>>>> Where the I-D is already several modules, then do as RFC7317 has
>> done.
>>> Sure, Do you have text you'd like to propose?
>>>
>>>
>>>> Tom Petch
>>>>
>>>> ----- Original Message -----
>>>> From: "Lou Berger" 
>>>> To: 
>>>> Sent: Wednesday, October 25, 2017 2:13 PM
>>>>
>>>>> Hi,
>>>>>
>>>>> This version addresses all known / open issues in the draft known
>> to
>>>>> the authors.
>>>>>
>>>>> The changes are as follows:
>>>>> - Added groupings and yang-data descriptions
>>>>> - Added Comments, Long Diagrams and Security Considerations
>> sections
>>>>> - Clarified representation of schema mount points and
>> representation
>>>> of
>>>>> modules exposed using schema mount.
>>>>> - Miscellaneous editorial changes
>>>>>
>>>>> Lou (for draft authors)
>>>>>
>>>>> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
>>>>>>         Authors         : Martin Bjorklund
>>>>>>                           Lou Berger
>>>>>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
>>>>>> Pages           : 11
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Fri Oct 27 12:56:47 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65C913F3E6 for ; Fri, 27 Oct 2017 12:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlgT1dDG3CA0 for ; Fri, 27 Oct 2017 12:56:43 -0700 (PDT)
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 B4FF9139612 for ; Fri, 27 Oct 2017 12:56:42 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id g70so8568186lfl.3 for ; Fri, 27 Oct 2017 12:56:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uBIOzCErYD9TTt1f7YuI/6WXyIJidzir+7wBRN7jS/o=; b=KYVIIh4hZ0uwB2aFoiZddq2xMfdRLN1/XsF3EyZZgNJBkV1LLneMv1DzqUzUOCI/AT B4Og6LoNn73TLk6lL/oPavKiaakb1Fw6KI/Up4vk8uL4nlIjJ9FjQUFgHTz/VpzecnqE CSblWUQ6fQ608VYWTxn4YfsWleB7Cpbfv73fUSQmH97jyJMhUAdRM97+GFQv0/RAvG1p oz3+ZfKbqUYyshcJW1TAEgm6zOEVYlcxQy+DRcd9teZ/EVnL1q1aZcQyWTH0LEmct27X S0EYQS0J4ZqL7EnYkHtrzFl/qtgmGC6vvubKeH70xhV7qabVrrF1IofZAwmjyvssixz8 1y6w==
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=uBIOzCErYD9TTt1f7YuI/6WXyIJidzir+7wBRN7jS/o=; b=hcdDOUHERzcPmcTE1NBrUB8dFYMRXWYVJzMEI/vTMcRyUvQck3J5KX3xQxTavy0T7t 7zY2yUzMTinUIuyWUytJF+y9AsKcNAWg88iFpwJ1FshGhIXOxLm3WblhVLulSUg8PvJW 1c7H7jg8SEK6BW1FPI3gktARXFVjrOXBm+Mx53AMHZBJi/8oZpdMT/Y7F0JQo3LY/FJk DHQ3Z/H+WptYz3CrngaD3sEsKlu6kZUe8e3/ggqcmAnX0ZB0UD5Afl+ZJ2n87HxXK5Uu XorZIps9Q6enbCCNDwVBOaPa54NeUvDTrAdP5StMQPmwSdXLo92j7eT5WtcciPx8Bj55 hP3Q==
X-Gm-Message-State: AMCzsaUCTwWsDklZWtfDoYVCBnOhVHYyF3YeToVcOnOm8UUouH6NFj2H CA4qDmpTMIrTXRPDT12DvdazTS+9zfXFp7lHtBJRGg==
X-Google-Smtp-Source: ABhQp+TMU42NyacAOiEtApRkErSA+3NQaAG6ZlflX0j/jtFna1FSCIb0uyakUO4g3pFcOcY8DxfAzySX9hqWl+ZHAcw=
X-Received: by 10.25.104.21 with SMTP id d21mr503730lfc.45.1509134201000; Fri, 27 Oct 2017 12:56:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Fri, 27 Oct 2017 12:56:40 -0700 (PDT)
In-Reply-To: 
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <03bb01d34f14$2907e5c0$4001a8c0@gateway.2wire.net> <63fca2cd-e41e-5d79-2290-41e0d0541ccb@labn.net> <013401d34f46$42976740$4001a8c0@gateway.2wire.net> <20171027172027.f6ki7wljdwmwzwib@elstar.local> 
From: Andy Bierman 
Date: Fri, 27 Oct 2017 12:56:40 -0700
Message-ID: 
To: Lou Berger 
Cc: "t.petch" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045e5616f82a3c055c8cafca"
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Oct 2017 19:56:46 -0000

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

On Fri, Oct 27, 2017 at 12:40 PM, Lou Berger  wrote:

> On 10/27/2017 01:20 PM, Juergen Schoenwaelder wrote:
> > Why do we come up with such rules in the first place? It really
> > depends on the modules and their relationship and it is the
> > responsibility of the WG, the authors, the reviewers to produce a
> > reasonable document.
> >
>
> My personal view - Because having a few knowledgeable people doesn't
> scale and not all model writers are at the IETF.
>
>
It is easy to add a guideline that says "a YANG tree diagram MAY be pruned
if it is too verbose, in order to improve readability.".

Not so easy to define "too verbose" or define what should be pruned.
This is where I agree with Juergen. The authors and reviewers have the
responsibility to make these decisions.



> Lou
>


Andy


>
> > /js
> >
> > On Fri, Oct 27, 2017 at 06:08:31PM +0100, t.petch wrote:
> >> Lou
> >>
> >> Suggested text
> >>
> >> NEW
> >>
> >> 3.3 One Document Several Modules
> >>
> >> When a document contains several YANG modules, all the tree diagrams
> >> should be placed together, before all the modules.  Each tree diagram
> >> should be preceded by a brief introduction to highlight where one tree
> >> diagram ends and another starts.
> >>
> >> If a document contains a single module which is logically a number of
> >> distinct components, the same strategy should be followed; RFC7317
> >> provides a good example of this approach.
> >>
> >> /NEW
> >>
> >> Like Juergen, I am conflicted as to at what point details like this
> >> should be part of rfc6087bis; I think a paragraph like this does belong
> >> in 'tree-diagrams'.
> >>
> >> Tom Petch
> >>
> >> ----- Original Message -----
> >> From: "Lou Berger" 
> >> To: "t.petch" ; 
> >> Sent: Friday, October 27, 2017 1:38 PM
> >>
> >>> Tom,
> >>>
> >>>
> >>> On 10/27/2017 7:08 AM, t.petch wrote:
> >>>> Lou
> >>>>
> >>>> On a slightly different tack, so a slightly modified Subject: line,
> >>>> when an I-D contains multiple modules, some place all the models
> >>>> together and then all the modules, e.g.
> >>>> draft-hares-i2nsf-capability-data-model-04 while others intersperse
> >> the
> >>>> models and the modules, e.g. draft-ietf-lisp-yang-05 .
> >>>>
> >>>> I think the former is superior and should be recommended, especially
> >>>> when, as Sue has done, there is a brief paragraph of text before
> >> each
> >>>> model, so it is very clear where a model ends and another begins.
> >> With
> >>>> the latter, models can be hard to find.
> >>>
> >>>> I see this as dovetailing into Juergen's comments on RFC7317 which,
> >> to
> >>>> me, is really several separate modules packaged as one, so the
> >>>> separation makes excellent sense to a reader.
> >>>>
> >>>> Where the I-D is already several modules, then do as RFC7317 has
> >> done.
> >>> Sure, Do you have text you'd like to propose?
> >>>
> >>>
> >>>> Tom Petch
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Lou Berger" 
> >>>> To: 
> >>>> Sent: Wednesday, October 25, 2017 2:13 PM
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> This version addresses all known / open issues in the draft known
> >> to
> >>>>> the authors.
> >>>>>
> >>>>> The changes are as follows:
> >>>>> - Added groupings and yang-data descriptions
> >>>>> - Added Comments, Long Diagrams and Security Considerations
> >> sections
> >>>>> - Clarified representation of schema mount points and
> >> representation
> >>>> of
> >>>>> modules exposed using schema mount.
> >>>>> - Miscellaneous editorial changes
> >>>>>
> >>>>> Lou (for draft authors)
> >>>>>
> >>>>> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
> >>>>>>         Authors         : Martin Bjorklund
> >>>>>>                           Lou Berger
> >>>>>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
> >>>>>> Pages           : 11
> >>
> >> _______________________________________________
> >> 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
>

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




On Fri, Oct 27, 2017 at 12:40 PM, Lou Berger <lberger@labn.net><=
/span> wrote:
On 10/27/2017 01:20 PM, Jue=
rgen Schoenwaelder wrote:

> Why do we come up with such rules in the first place? It really

> depends on the modules and their relationship and it is the

> responsibility of the WG, the authors, the reviewers to produce a

> reasonable document.

>



My personal view - Because having a few knowledgeable people doesn't
scale and not all model writers are at the IETF.



It is easy to add a guideline that say=
s "a YANG tree diagram MAY be pruned
if it is too verbose, i=
n order to improve readability.".

Not so easy=
 to define "too verbose" or define what should be pruned.
This is where I agree with Juergen. The authors and reviewers have the
responsibility to make these decisions.

=
=C2=A0

Lou


Andy
=C2=
=A0



> /js

>

> On Fri, Oct 27, 2017 at 06:08:31PM +0100, t.petch wrote:

>> Lou

>>

>> Suggested text

>>

>> NEW

>>

>> 3.3 One Document Several Modules

>>

>> When a document contains several YANG modules, all the tree diagra=
ms

>> should be placed together, before all the modules.=C2=A0 Each tree=
 diagram

>> should be preceded by a brief introduction to highlight where one =
tree

>> diagram ends and another starts.

>>

>> If a document contains a single module which is logically a number=
 of

>> distinct components, the same strategy should be followed; RFC7317=


>> provides a good example of this approach.

>>

>> /NEW

>>

>> Like Juergen, I am conflicted as to at what point details like thi=
s

>> should be part of rfc6087bis; I think a paragraph like this does b=
elong

>> in 'tree-diagrams'.

>>

>> Tom Petch

>>

>> ----- Original Message -----

>> From: "Lou Berger" <lberger@labn.net>

>> To: "t.petch" <ietfc@btconnect.com>; <netmod=
@ietf.org>

>> Sent: Friday, October 27, 2017 1:38 PM

>>

>>> Tom,

>>>

>>>

>>> On 10/27/2017 7:08 AM, t.petch wrote:

>>>> Lou

>>>>

>>>> On a slightly different tack, so a slightly modified Subje=
ct: line,

>>>> when an I-D contains multiple modules, some place all the =
models

>>>> together and then all the modules, e.g.

>>>> draft-hares-i2nsf-capability-data-model-04 while othe=
rs intersperse

>> the

>>>> models and the modules, e.g. draft-ietf-lisp-yang-05 .

>>>>

>>>> I think the former is superior and should be recommended, =
especially

>>>> when, as Sue has done, there is a brief paragraph of text =
before

>> each

>>>> model, so it is very clear where a model ends and another =
begins.

>> With

>>>> the latter, models can be hard to find.

>>>

>>>> I see this as dovetailing into Juergen's comments on R=
FC7317 which,

>> to

>>>> me, is really several separate modules packaged as one, so=
 the

>>>> separation makes excellent sense to a reader.

>>>>

>>>> Where the I-D is already several modules, then do as RFC73=
17 has

>> done.

>>> Sure, Do you have text you'd like to propose?

>>>

>>>

>>>> Tom Petch

>>>>

>>>> ----- Original Message -----

>>>> From: "Lou Berger" <lberger@labn.net>

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

>>>> Sent: Wednesday, October 25, 2017 2:13 PM

>>>>

>>>>> Hi,

>>>>>

>>>>> This version addresses all known / open issues in the =
draft known

>> to

>>>>> the authors.

>>>>>

>>>>> The changes are as follows:

>>>>> - Added groupings and yang-data descriptions

>>>>> - Added Comments, Long Diagrams and Security Considera=
tions

>> sections

>>>>> - Clarified representation of schema mount points and<=
br>
>> representation

>>>> of

>>>>> modules exposed using schema mount.

>>>>> - Miscellaneous editorial changes

>>>>>

>>>>> Lou (for draft authors)

>>>>>

>>>>> On 10/25/2017 8:49 AM, 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.

>>>>>>

>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: YANG Tree Diagrams

>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0: Martin Bjorklund

>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lou Berger

>>>>>> Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-n=
etmod-yang-tree-diagrams-02.txt

>>>>>> Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 11=


>>

>> _______________________________________________

>> netmod mailing list

>> netmod@ietf.org

>> https://www.ietf.org/mailman/listinfo/netm=
od

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--f403045e5616f82a3c055c8cafca--


From nobody Sat Oct 28 04:57:17 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2824613F7B1 for ; Sat, 28 Oct 2017 04:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 9wN2Bj1wVQ3i for ; Sat, 28 Oct 2017 04:57:13 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0113.outbound.protection.outlook.com [104.47.1.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49ADC13F5EF for ; Sat, 28 Oct 2017 04:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I1z7utLbfhFAenywMs6zs9lAlqa9M7/lBbSeGTlXcUc=; b=XCW7fMSirduJ2QWJdMmwhhngU5rfVMV69pzL+iuAcVuPDEEjwH02JYOSXjg28wcsI5vKyaCyqutQduLfkxHJRiKJNMWXY94iNU1mu9xA55wtohhYLhDqoqNvOwYnvIAtse/A+b5nNpIxLxqsZ/1gwo8hrZzY9Y5XJcGEx92zr5s=
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.197.4; Sat, 28 Oct 2017 11:57:10 +0000
Message-ID: <01f701d34fe3$885ad120$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Andy Bierman" , "Lou Berger" 
Cc: 
References: <150893578927.4882.2117597388624976982@ietfa.amsl.com> <23892572-a0db-d24b-e591-a19799ace9ae@labn.net> <03bb01d34f14$2907e5c0$4001a8c0@gateway.2wire.net> <63fca2cd-e41e-5d79-2290-41e0d0541ccb@labn.net> <013401d34f46$42976740$4001a8c0@gateway.2wire.net> <20171027172027.f6ki7wljdwmwzwib@elstar.local>  
Date: Sat, 28 Oct 2017 12:54:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: DB6PR0501CA0017.eurprd05.prod.outlook.com (2603:10a6:4:8f::27) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: f08184d4-afb5-447c-4970-08d51dfb0560
X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:Wk/gAksg6PhOKmKd9PMgYaIPJmatj+jULGpQgr4qF6glzVjTxLKoNnlqUS21VGz+MFtEjXz3ikz+ZUadrqOZDKF+c+uSWrOCmx091SNcfd48bnMRBM4ZjR5gzQBGdT6XK2rd6zse3GzrrFV5f4YyvH0hE0vlmSKfHQ81ZqITKSdLcYDraiMhioYeR9MZlGWgIXYmektq3v2PaacgbEgaVPcEDLB21aNKcwI0jsHwzofFZjo3iOsg4mhysg7SdCQ5cU1mcpxFuEhL0pMDPBuTupyt6CLIioIcp0Lrr14F4hc=; 25:CUmEVHP4RAxQLPJzn/McUJe0U1E+NF2OSLb76HQKv/Xn9uPGjBCzQerS2stjhK6a7OcPqnv3OPbl7V1QFJM3VzkDk/SvSEKU+6vHkuL9Cu0RuaVEg00jnw0+QzfQEC7b9tW36JY5dXlnCOx/uwrf3m+idxlGEgsnBFu5TDFp1loQIF0ACkB9kzDkdxk4vxgMj9s9AtGv7I49qimbgrHLVsx5RwEknFfz9tK6/2jm+IRMyk31lMQiFGcxpdHk8BtCmz16QJQaUfMvP/e/JV0JD0VG7ZuniSGlz9mjj0wXFQfOkd1QCvrOnxhItjH4oMAvkwx+3Ed5ack6hf22Oo5NEA==; 31:u9CnHtxxbVvLa02gVv9oZMkf+5+Ob6ekTpgklFzD1UhYi24AZ/VVauWCLpO7GUffg8EOC1I1QA0QSbPL1whz/aLPsGAfknyMtud+YV8wqLTESm9AZjUVaKDUv1ecaLZI7NwSyH/B1AjuvOSbcAo28t9CNFQ+hdRvPwrOUYZ6h61VdncLON306hEqIRDIOwzMVCf2OwhibPar5Ng58tKLJbhTIJ7GvfKj9FTOfhMMVv8=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002:
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(192374486261705);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231020)(100000703101)(100105400095)(93006095)(93001095)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:GNqhhJhJx4zHHniOX4IPsw6VnQRYQaC27wwaYWS3nSOiHaNwkchYoffaW3cnPTHSCZEc8ltgcrVnE+gSLVU6UxgVsxh5EIM+bhm4btT4BRqyRWilTpesdtA+A1i29b6OSlagpLxi1V4CsDUHkO7z45PbkJ2/WD3bvx2eeA4vVH1zR0wSuImTyXB+iGrCYVQL0ePfe+T5r2IjX0LW0Q4LpfY9d8tBC+48rtY11zSbpMjqlQ30yLqtlNjqJgdW8U6N3/sqgR8g+E5XhOsSi0b6wGarwAl2tNXGCvwxxWCffHcmcYQZH7es+gvXRTnjsUwzsjjB5fiui+UdxaVFErjmhUM3G5GW/JPsmLsfFAlAvdw=
X-Forefront-PRVS: 04740D25F1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(13464003)(189002)(24454002)(51444003)(199003)(53936002)(8676002)(23676002)(81166006)(81156014)(62236002)(44716002)(66066001)(47776003)(68736007)(50466002)(230783001)(966005)(189998001)(25786009)(305945005)(229853002)(8936002)(116806002)(14496001)(4720700003)(478600001)(81816999)(81686999)(6486002)(76176999)(50986999)(7736002)(50226002)(16526018)(84392002)(101416001)(2906002)(44736005)(105586002)(106356001)(3846002)(230700001)(6116002)(61296003)(53546010)(5660300001)(33646002)(1556002)(86362001)(110136005)(6306002)(1456003)(4326008)(9686003)(93886005)(6246003)(6496005)(97736004)(316002)(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?MTtIRTFQUjA3MDFNQjMwMDI7MjM6R3p6M0VwblJ4SG1hSGVwei9aVHFGR2lJ?= =?utf-8?B?dmpIZXBJZlJBTWtKcll2aUZkdkpQYzJEZUpOTWxNanpQZW5mOHFJc2t1eDQ1?= =?utf-8?B?ODdGQVoxZEJuWTJYTkdMa3pTMTNBQmk2NVNoOGpqQXNIQ296aGZ1R01YdjVG?= =?utf-8?B?WGRiZlhacEV0RmtOQkpwVzFicEI5bGxucU0xYlVxRHBvTkRNa3pZWHhXaS9Y?= =?utf-8?B?ZllGd25MQnpaeVB4UVA0L2E2KzU4Z0w1Wm9ycWVIUHpnY2NCZW5SWnEwRGZ4?= =?utf-8?B?enYxcVdQVDlLN0UvdXgzTzluOVhwejZCcFBENzEvNVVpcDJpdHRzbXEweWQz?= =?utf-8?B?VisxUFZESUt0OVREMXRhQW1zb2pxWnRyQmpYbHB0STh4eGZrTzZybzkvZFFJ?= =?utf-8?B?b3JGc2l2cktiUFo1aml6Z1ZjMHNzay9iRjUvc1lBUEE0cjBCL2t0TTluL0Q0?= =?utf-8?B?Wkg5ME9xVHZoNGdrWFRpdHBqQ0dXRFN3QmRQVXVvcy9kRHFuMElaVDJFK1Bo?= =?utf-8?B?ajRnRi9nR0FJY1c2NStMWU4vOW5XM3ZtcVFnRUJxWnBSZG10MHhFUExtazBJ?= =?utf-8?B?WTZsRHFObksyUVRTQ1NRb1ZQeUx3UEJpb2VkNDgxZ2t0RFliUnoyMTRXeEZK?= =?utf-8?B?d3VQa1k4aFdJVWY1R0xRek1zZUcrd0FjTVVnQmZ0Yk5jZVpQRk1CK2FDZVhy?= =?utf-8?B?OUJkelpPKy9kOXV6Zzc2YkVMdGNWUklHaXJ2Z2pYcUxKQUFySldnMUlZdFZx?= =?utf-8?B?dGlDKzB0SlVDQkNNSTJ3bmpqdXdJS3JKWlNoWU43WDlTaEsyQW5ZazdmUjIz?= =?utf-8?B?S284YjFXMTNqQzY4clBRMi8yM3JYY3FaYytCZDBZeC9BZ2YrRkNScjRVSjht?= =?utf-8?B?aCtBY0RTOVVPVHNLTlhNMG01OEpGekRScGhSK1pLNnpVb045Njg4ZnkvMEhY?= =?utf-8?B?a3FUT1FRZTRZOERjY0NFN2E2L1grd28rRHo3cHB5T3hHeUNLVVN1d1Q3MWps?= =?utf-8?B?YzRYa1RZZGFQbWhaMkRpR1FJQndSTi9yOWxDdGFXNFdQeStva3dCZ3YxQVFM?= =?utf-8?B?azhnMlNYQjBvU3VrczV2VFlmdXlqWXV2TmRpVnRlRHlVWDRTYXl5WGc5dGRk?= =?utf-8?B?VUo3MXY3VlN1VHJuUWJtUjJDUmNaQmxkUGMyVWsvYm10R3F1UHc5K2NNQ1lv?= =?utf-8?B?NjExNyt6SmhRNjdxTkNKZ2pmSUV0ZnJoQXplK1J5aVQ2SHc5b3VwM1A1K056?= =?utf-8?B?Nm02UU1ydHJRSldTMFlCejk4Ky9vdmdiME9zeVNOZEQyN1JySkU4YmZtemtH?= =?utf-8?B?M0x5clFZaHhLNllPMmQ1S21ZN1lOMS9tMVVtWEdiM2dIanI5SlJSS0RJUnpF?= =?utf-8?B?ZEIycnhTa0RQZCtkMkNZMWo4cTBjcy9QRzZQZnI5M28vVEp5eGE3bzBraEVI?= =?utf-8?B?ZExQR01CcVU3VzY4Y0s2UHdpeXNVT2QySWovQWVYcnNYK3paV1dGaVVFTHo4?= =?utf-8?B?TWdrMGNldWJOaHRDdHFhM05iVzRSbThCeHcwTVlSK3VxZWxZU0pSYUxMUXN4?= =?utf-8?B?dEVYdDRoOFg3NEdLNWF2aDlFcGoxUnNSMUlMM0lzQ3BydytxS2RJR3J1emow?= =?utf-8?B?b2VibnZ2eHJKaEU5ZDNObDNrSkNyOGNQWXFMWVVoTHJwcVFCWlVDckRQNmta?= =?utf-8?B?S1dMSHgzbHNkbTdaZFo0Vm5jNHlHUVJSaVhZNVVBM01RNVpkTUV4NWRmdkE4?= =?utf-8?B?YmFvWjhzTStFUjFJVFRGL29QaEdTWUovektMZE9POUIxMFp1S2ZWS2ZzZzJF?= =?utf-8?B?bnUwRlZlakJIZU5Qb2srOS9Fb1owSi93TERQL0JBamQxdG5tZ1VpVWRhQk5F?= =?utf-8?B?UTJsb1U4aXFSN0RYN0pxNXZXeHE4QUdHT29zNmNUVm85bEZsV1daOUpCUStv?= =?utf-8?B?VkkvTG9wNTRRVDVSNGFselp2R3ZvQ1BMeTdVQ1ZXNUIzSzZNVTNPaWFNS2FR?= =?utf-8?B?RERBUlE3d3VVRmQ1NzdjZWRVaENXcFhDRlR3SW53PT0=?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:zhS8rgIc9TlaRKKCJ37DkJJ/VKdCxczjPVfinThapjQrzfJp+WOCdlEGCfoJSfUhbOeX+Z4PgnHlgy7lXjTkVbpRMhxj2gS588l0UF9Sik9z6TiqlaPSuqaIGx09z+cRbvShR+6x22hZ4MbciZoSwrjHJWtCLe8kfis8M+6pTmqFCMoknlsFh+FsypYbHeFFnmh9ZSM9qpkBl3IJqm5j7ghp9bUEBKENnYNFyR4z7aV4Dqj6yvhRW7H4UBmeW7VkZwBz6pc6e3kAxJFNeQFuaHzxUAd1b70qQeAp6ZdfQMEdNBZgAttoVEa8wdXRBQLL/fNq9z/9zZ5EXLWqvU1XNvGLXo3JfljnZr1+F5C2jmo=; 5:b8fbZalLGcyo3cpgX+kPK2plduA6IHb+zbQucvtgeROEGRarUK0BEXB5H0kElUJ3NTQclfGvd48thHGcDda5kxnWsCpXWIPHzg2hzrbph39WB6rkovIWgzorz1IDaVKvRwRMEwjbXTfOcSEgBQ1F1ET7rYpYuNixtshN5pLVC7w=; 24:xxh1G0JmszIbBnC4AIj2ZH7iTnkF7+bqQ2a8yvEE+k7HBq/LQz8KqFd4fVPo3fSoY4qo+bh1/oqpU2Sz+tO0FfF7RFNSM5eY0Qfb+b6x8XY=; 7:vkfUgqgYrgE4kI292ADBz5uISL8XRAYaeGbXCpKqN/McBpkT+QoZrQ0VDZ67wonJevYkS8oVk76iomfjPg4idz5PPQKo7nAjQ7Vj8NZUq3trc4EG1K1w4jxYoO4FCL9xIBKB6MCSoEVpm9S0DCsiHBzgwW4mxbeJsnMRCaY5Qj19D/KpjXVvt6K3UtXEMdP+7tiyOukomIHwUrY+hpKr4IQ5ilzulLLk9mCsoFsML6Mk9N2tgDJK38XtdOqvTOpD
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2017 11:57:10.1517 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f08184d4-afb5-447c-4970-08d51dfb0560
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: Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Oct 2017 11:57:16 -0000

----- Original Message -----
From: "Andy Bierman" 
To: "Lou Berger" 
Sent: Friday, October 27, 2017 8:56 PM

> On Fri, Oct 27, 2017 at 12:40 PM, Lou Berger  wrote:
>
> > On 10/27/2017 01:20 PM, Juergen Schoenwaelder wrote:
> > > Why do we come up with such rules in the first place? It really
> > > depends on the modules and their relationship and it is the
> > > responsibility of the WG, the authors, the reviewers to produce a
> > > reasonable document.
> > >
> >
> > My personal view - Because having a few knowledgeable people doesn't
> > scale and not all model writers are at the IETF.
> >
> It is easy to add a guideline that says "a YANG tree diagram MAY be
pruned
> if it is too verbose, in order to improve readability.".
>
> Not so easy to define "too verbose" or define what should be pruned.
> This is where I agree with Juergen. The authors and reviewers have the
> responsibility to make these decisions.

A personal take on the size of tree diagrams, based on experience.

One page, as the I-D suggests, fine.

Over five pages, probably of little or no value.

Two or more pages; take steps to reduce, the steps mentioned in the I-D
already, looking for logically separate parts (as per RFC7317), reducing
tree depth, collapsing groupings (probably with a separate tree for each
grouping, which may in turn need to have these rules applied) ....

I think that the tree diagrams I see from the Routing Area are pretty
dire, on account of their size, and that this WG can see that already
whereas other WGs may take a year or two to cotton on.

I am an engineer - I want something that works!

Tom Petch

> > Lou
> >
>
>
> Andy
>
>
> >
> > > /js
> > >
> > > On Fri, Oct 27, 2017 at 06:08:31PM +0100, t.petch wrote:
> > >> Lou
> > >>
> > >> Suggested text
> > >>
> > >> NEW
> > >>
> > >> 3.3 One Document Several Modules
> > >>
> > >> When a document contains several YANG modules, all the tree
diagrams
> > >> should be placed together, before all the modules.  Each tree
diagram
> > >> should be preceded by a brief introduction to highlight where one
tree
> > >> diagram ends and another starts.
> > >>
> > >> If a document contains a single module which is logically a
number of
> > >> distinct components, the same strategy should be followed;
RFC7317
> > >> provides a good example of this approach.
> > >>
> > >> /NEW
> > >>
> > >> Like Juergen, I am conflicted as to at what point details like
this
> > >> should be part of rfc6087bis; I think a paragraph like this does
belong
> > >> in 'tree-diagrams'.
> > >>
> > >> Tom Petch
> > >>
> > >> ----- Original Message -----
> > >> From: "Lou Berger" 
> > >> To: "t.petch" ; 
> > >> Sent: Friday, October 27, 2017 1:38 PM
> > >>
> > >>> Tom,
> > >>>
> > >>>
> > >>> On 10/27/2017 7:08 AM, t.petch wrote:
> > >>>> Lou
> > >>>>
> > >>>> On a slightly different tack, so a slightly modified Subject:
line,
> > >>>> when an I-D contains multiple modules, some place all the
models
> > >>>> together and then all the modules, e.g.
> > >>>> draft-hares-i2nsf-capability-data-model-04 while others
intersperse
> > >> the
> > >>>> models and the modules, e.g. draft-ietf-lisp-yang-05 .
> > >>>>
> > >>>> I think the former is superior and should be recommended,
especially
> > >>>> when, as Sue has done, there is a brief paragraph of text
before
> > >> each
> > >>>> model, so it is very clear where a model ends and another
begins.
> > >> With
> > >>>> the latter, models can be hard to find.
> > >>>
> > >>>> I see this as dovetailing into Juergen's comments on RFC7317
which,
> > >> to
> > >>>> me, is really several separate modules packaged as one, so the
> > >>>> separation makes excellent sense to a reader.
> > >>>>
> > >>>> Where the I-D is already several modules, then do as RFC7317
has
> > >> done.
> > >>> Sure, Do you have text you'd like to propose?
> > >>>
> > >>>
> > >>>> Tom Petch
> > >>>>
> > >>>> ----- Original Message -----
> > >>>> From: "Lou Berger" 
> > >>>> To: 
> > >>>> Sent: Wednesday, October 25, 2017 2:13 PM
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> This version addresses all known / open issues in the draft
known
> > >> to
> > >>>>> the authors.
> > >>>>>
> > >>>>> The changes are as follows:
> > >>>>> - Added groupings and yang-data descriptions
> > >>>>> - Added Comments, Long Diagrams and Security Considerations
> > >> sections
> > >>>>> - Clarified representation of schema mount points and
> > >> representation
> > >>>> of
> > >>>>> modules exposed using schema mount.
> > >>>>> - Miscellaneous editorial changes
> > >>>>>
> > >>>>> Lou (for draft authors)
> > >>>>>
> > >>>>> On 10/25/2017 8:49 AM, 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           : YANG Tree Diagrams
> > >>>>>>         Authors         : Martin Bjorklund
> > >>>>>>                           Lou Berger
> > >>>>>> Filename        : draft-ietf-netmod-yang-tree-diagrams-02.txt
> > >>>>>> Pages           : 11
> > >>
> > >> _______________________________________________
> > >> 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 Oct 29 11:52:29 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A856A13FB0D for ; Sun, 29 Oct 2017 11:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQODhAq4sRUz for ; Sun, 29 Oct 2017 11:52:26 -0700 (PDT)
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 0A65813FB0A for ; Sun, 29 Oct 2017 11:52:26 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 50648E90 for ; Sun, 29 Oct 2017 19:52:24 +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 FsUk95OafrkB for ; Sun, 29 Oct 2017 19:52:21 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Sun, 29 Oct 2017 19:52:23 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF13B2010F for ; Sun, 29 Oct 2017 19:52:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UV3mlyHfJ9-K; Sun, 29 Oct 2017 19:52:23 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 639ED2010E; Sun, 29 Oct 2017 19:52:23 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7648F414231B; Sun, 29 Oct 2017 19:50:57 +0100 (CET)
Date: Sun, 29 Oct 2017 19:50:57 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20171029185057.hecz7vgul343tjki@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/20170714 (1.8.3)
Archived-At: 
Subject: [netmod] review of draft-ietf-netmod-yang-tree-diagrams-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: Sun, 29 Oct 2017 18:52:29 -0000

Hi,

I have reviewed draft-ietf-netmod-yang-tree-diagrams-02 and here are
my comments (in document order).

- I am not sure this is correct:

  YANG Tree Diagrams were first published in [RFC7223].  Such diagrams

  I think NACM (RFC 6536) already has a tree diagram. This makes for a
  difference of ~2 years. Note sure this matter much however.

- Do we have to speak more specifically about 'schema tree diagrams'?
  Note that there can be many more 'tree' diagrams, like instance tree
  diagrams, identity derivation diagrams, type derivation diagrams,
  import relationship diagrams, ... and perhaps it makes sense to
  allow for other diagrams to be defined over time.

- Should we use 'sibling nodes' instead of 'peer nodes'? I think
  the term 'sibling' is used in RFC 7950.

- Are the empty lines mandatory or can empty lines added as one sees
  fit? In particular, is there an empty line after the module: line?
  Is there an empty line before each section of different top-level
  symbols? Does the order of top-level symbols matter? Do we really
  want to specify these details? Well, for indentation, things are
  pretty specific so I wonder what the general strategy is here.

- There was already some discussion about having a way to not always
  expand groupings by showing uses nodes. I think this makes sense in
  certain situations (possible  '-u').

- What are 'data modules'? This term does not appear in schema mount
  I think. Perhaps you wanted YANG modules instead?

- s/realted/related/

- I think Section 4.1 is not about representing _instance_ data
  trees. It is describing how a schema mounted schema looks like - and
  I think this is OK. I think this document should not specify
  instance tree formats. So change the title of section 4.1 or simply
  delete the subsection title entirely.

- If a schema mount point is used for a readonly mount, then I
  understand that only the toplevel changes to ro. Is this useful or
  potentially misleading? Was the alternative considered to change all
  nodes recursively to ro? I assume they are all effectively ro in
  this case.

- If the WG wants to include tree diagram usage guidelines in this
  document, then I think we should (if we still manage) take tree
  diagram related text out of 6087bis before it is cast into
  stone. Changes to 6087bis would be:

  - Change the subsubstitle "2.5.1.  YANG Tree Diagrams" to "2.6.
    YANG Tree Diagrams" (since the definition is in an external
    document, I think this should not be nested in 2.5 anymore).

  - Remove section 3.4.

  - Remove this from section 8 (which is not quite correct anymore
    anyway since the definition moved to a separate document).

       o  Added YANG tree diagram definition and guideline

  Since two are bug fixes anyway (I think), I think it makes sense to
  get 6087bis fixed so that the tree diagram usage text is in one
  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 Sun Oct 29 17:43:14 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8513F652 for ; Sun, 29 Oct 2017 17:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KEH62aYHp-9 for ; Sun, 29 Oct 2017 17:43:10 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFEC13F5F4 for ; Sun, 29 Oct 2017 17:43:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 5A1B01404EA6 for ; Mon, 30 Oct 2017 01:43:07 +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 lSAP1rlLGGmV for ; Mon, 30 Oct 2017 01:43:07 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 2F4321404EA1 for ; Mon, 30 Oct 2017 01:43:07 +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 OeHqMxVAGzf5 for ; Mon, 30 Oct 2017 01:43:07 +0100 (CET)
Received: from [192.168.42.98] (unknown [95.87.249.99]) by mail.transpacket.com (Postfix) with ESMTPSA id E02251404DB9 for ; Mon, 30 Oct 2017 01:43:06 +0100 (CET)
From: Vladimir Vassilev 
To: "netmod@ietf.org" 
Message-ID: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.com>
Date: Mon, 30 Oct 2017 01:43:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod]  review of draft-acee-netmod-rfc8022bis-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: Mon, 30 Oct 2017 00:43:12 -0000

Hello,

I have reviewed draft-acee-netmod-rfc8022bis-05. My conclusion is that 
the YANG modules part of the draft have been successfully modified in 
accordance with sec. '4.23.3 NMDA Transition Guidelines' of 
draft-ietf-netmod-rfc6087bis-14. The modifications are coherent with the 
ietf-interfaces@2017-08-17.yang module in 
draft-ietf-netmod-rfc7277bis-00 and ietf-ip@2017-08-21.yang module in 
draft-ietf-netmod-rfc7277bis-00.

Vladimir


Review of draft-acee-netmod-rfc8022bis-05.
Vladimir Vassilev
2017-10-30

'Abstract':
'Introduction 1':
  - Both Abstract and Sec 1. contain duplicated text which can be removed
from Abstract. The text in Sec 1. can be simplified:

OLD:
    This version of these YANG modules uses new names for these YANG
    models.  The main difference from the first version is that this
    version fully conforms to the Network Management Datastore
    Architecture (NMDA).  Consequently, this document obsoletes RFC 8022.
NEW:
    This version of the Routing Management data model supports the Network
    Management Datastore Architecture (NMDA) 
[I-D.ietf-netmod-revised-datastores].


'7.  Routing Management YANG Module':

  - Why should address-family identity be different e.g. mandatory 
"false"; for system created RIBs? I think this needs some explanation 
(Page 21):
            ...
            uses address-family {
              description
                "Address family of the RIB.

                 It is mandatory for user-controlled RIBs.  For
                 system-controlled RIBs it can be omitted; otherwise, it
                 must match the address family of the corresponding state
                 entry.";
              refine "address-family" {
                mandatory "false";
              }
            }
            ...

  - Suggested change of 'base address-family;' -> 'base 
rt:address-family;' for identity ipv4 and ipv6 (ref. 
draft-ietf-netmod-rfc6087bis-14#section-4.2):

     o The local module prefix MUST be used instead of no prefix in
     all "default" statements for an "identityref" or "instance-identifier"
         data type

'8.  IPv4 Unicast Routing Management YANG Module' 
(ietf-ipv4-unicast-routing@2017-10-14.yang):
'9.  IPv6 Unicast Routing Management YANG Module' 
(ietf-ipv6-unicast-routing@2017-10-14.yang):


  - The ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing modules 
import the ietf-routing without revision (ref. rfc6087#section-4.6):


     o The revision-date substatement within the imports statement SHOULD be
     present if any groupings are used from the external module."


'Appendix D. Data Tree Example':

  - The example in the Appendix D. has not been updated and it must be 
extended in order to demonstrate a usecase of operational datastore of 
configuration data with different origin (intended, system, etc.) 
similar to the 'Appendix C. Example Data' of 
draft-ietf-netmod-revised-datastores-05.


Nits:
  - s/Figures 1/Figure 1/
  - s/systemindependently/system independently/


From nobody Sun Oct 29 19:15:21 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B1213FD5C; Sun, 29 Oct 2017 19:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 DhymZUvK2iMA; Sun, 29 Oct 2017 19:15:13 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478C813FB2F; Sun, 29 Oct 2017 19:15:13 -0700 (PDT)
From: Alex Campbell 
To: Jiangyuanlong , "tictoc@ietf.org" 
CC: Xian Liu , Xujinchun , "netmod@ietf.org" 
Thread-Topic: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTTso91J0wdpBQm0ySMhnhc/8WWaL7pCg3
Date: Mon, 30 Oct 2017 02:15:11 +0000
Message-ID: <1509329710965.52658@Aviatnet.com>
References: <150906887826.22201.5033565145094897903.idtracker@ietfa.amsl.com>,  <3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97@dggeml507-mbx.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97@dggeml507-mbx.china.huawei.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 30 Oct 2017 02:15:15 -0000

Hi,=0A=
I've reviewed this latest draft and have some more comments.=0A=
=0A=
1. I find the introduction to be unnecessarily wordy; it feels like it was =
written with a view of not missing any information out, rather than trying =
to keep it concise.=0A=
   For example, there is no need to elaborate on YANG data types here. It i=
s also not here to sell YANG.=0A=
=0A=
OLD:=0A=
=0A=
   As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely=0A=
   supported in the carrier networks, industrial networks, automotive=0A=
   networks, and many other applications. It can provide high=0A=
   precision time synchronization as fine as nano-seconds. The=0A=
   protocol depends on a Precision Time Protocol (PTP) engine to=0A=
   decide its own state automatically, and a PTP transportation layer=0A=
   to carry the PTP timing and various quality messages. The=0A=
   configuration parameters and state data sets of IEEE 1588-2008 are=0A=
   numerous.=0A=
=0A=
   According to the concepts described in [RFC3444], IEEE 1588-2008=0A=
   itself provides an information model in its normative=0A=
   specifications for the data sets (in IEEE 1588-2008 clause 8). Some=0A=
   standardization organizations including the IETF have specified=0A=
   data models in MIBs (Management Information Bases) for IEEE 1588-=0A=
   2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are=0A=
   typically focused on retrieval of state data using the Simple=0A=
   Network Management Protocol (SNMP), furthermore, configuration of=0A=
   PTP data sets is not considered in [RFC8173].=0A=
=0A=
   Some service providers and applications require that the management=0A=
   of the IEEE 1588-2008 synchronization network be flexible and more=0A=
   Internet-based (typically overlaid on their transport networks).=0A=
   Software Defined Network (SDN) is another driving factor, which=0A=
   demands an improved configuration capability of synchronization=0A=
   networks.=0A=
=0A=
   YANG [RFC6020] is a data modeling language used to model=0A=
   configuration and state data manipulated by network management=0A=
   protocols like the Network Configuration Protocol (NETCONF)=0A=
   [RFC6241]. A small set of built-in data types are defined in=0A=
   [RFC6020], and a collection of common data types are further=0A=
   defined in [RFC6991]. Advantages of YANG include Internet based=0A=
   configuration capability, validation, rollback and so on. All of=0A=
   these characteristics make it attractive to become another=0A=
   candidate modeling language for IEEE 1588-2008.=0A=
=0A=
NEW:=0A=
=0A=
   IEEE 1588-2008 is a time protocol that provides high precision time=0A=
   synchronization as fine as nano-seconds.=0A=
=0A=
   IEEE 1588-2008 itself provides an information model in its normative=0A=
   specifications for the data sets (IEEE 1588-2008 clause 8).=0A=
   Standard information models (e.g. [RFC8173], [IEEE8021AS]) have been=0A=
   previously defined as MIBs focused on the retrieval of state data using=
=0A=
   SNMP [RFC1157].=0A=
=0A=
   YANG [RFC6020] is a data modeling language used to model configuration=
=0A=
   and state data manipulated by network management protocols like NETCONF=
=0A=
   [RFC6241].=0A=
=0A=
2. Can we refer to the system as simply PTP rather than IEEE 1588(-2008)?=
=0A=
=0A=
3. There is insufficient spacing here to separate the terms from their defi=
nitions:=0A=
OLD=0A=
=0A=
   PTP dataset  Structured attributes of clocks (an OC, BC or TC) used=0A=
   for PTP protocol decisions and for providing values for PTP message=0A=
   fields, see Section 8 of [IEEE1588].=0A=
=0A=
   PTP instance A PTP implementation in the device (i.e., an OC or BC)=0A=
   represented by a specific PTP dataset.=0A=
=0A=
NEW=0A=
=0A=
   PTP dataset=0A=
     Structured attributes of clocks (an OC, BC or TC) used=0A=
     for PTP protocol decisions and for providing values for PTP message=0A=
     fields, see Section 8 of [IEEE1588].=0A=
=0A=
   PTP instance=0A=
     A PTP implementation in the device (i.e., an OC or BC)=0A=
     represented by a specific PTP dataset.=0A=
=0A=
4. There's a singular/plural mismatch here:=0A=
=0A=
   module. Query and configuration of device wide or port specific=0A=
   configuration information and clock data set is described for this=0A=
   version.=0A=
=0A=
and here:=0A=
=0A=
   Query and configuration of clock information include:=0A=
=0A=
5. The choice of uint16 as instance-number limits implementations to 65536 =
distinct instances.=0A=
   While I have a hard time imagining a system with more than 65536 PTP ins=
tances, I would prefer to avoid imposing arbitrary limits.=0A=
   I would recommend changing instance-number to a string (and renaming it =
to instance-name or just name).=0A=
=0A=
6. I still recommend removing -ds from the YANG element names that still in=
clude it. It doesn't appear to add any value.=0A=
=0A=
7. What;s the relevance of injection attacks relevant to this YANG module?=
=0A=
=0A=
=0A=
Alex=0A=
=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of Jiangyuanlong =0A=
Sent: Friday, 27 October 2017 3:21 p.m.=0A=
To: tictoc@ietf.org=0A=
Cc: Xian Liu; Xujinchun; netmod@ietf.org=0A=
Subject: [netmod] WG Last Call resolutions incorporated in draft-ietf-ticto=
c-1588v2-yang-06=0A=
=0A=
Dear all,=0A=
=0A=
Based on all the comments we received during the WG Last Call process, we'v=
e updated the document to version 6.=0A=
We believe all the LC comments are resolved and the consensus is reflected =
in this new revision.=0A=
Many thanks to Martin, Tal, Opher, Alex, John and many others who had revie=
wed and commented on this draft.=0A=
=0A=
Cheers,=0A=
Yuanlong on behalf of all coauthors=0A=
=0A=
-----Original Message-----=0A=
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=0A=
Sent: Friday, October 27, 2017 9:48 AM=0A=
To: Xian Liu; Rodney Cummings; rodney.cummings@ni.com; Jiangyuanlong; Xujin=
chun=0A=
Subject: New Version Notification for draft-ietf-tictoc-1588v2-yang-06.txt=
=0A=
=0A=
=0A=
A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt=0A=
has been successfully submitted by Yuanlong Jiang and posted to the IETF re=
pository.=0A=
=0A=
Name:           draft-ietf-tictoc-1588v2-yang=0A=
Revision:       06=0A=
Title:          YANG Data Model for IEEE 1588-2008=0A=
Document date:  2017-10-26=0A=
Group:          tictoc=0A=
Pages:          30=0A=
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588=
v2-yang-06.txt=0A=
Status:         https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-y=
ang/=0A=
Htmlized:       https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-0=
6=0A=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-158=
8v2-yang-06=0A=
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tictoc-1588v=
2-yang-06=0A=
=0A=
Abstract:=0A=
   This document defines a YANG data model for the configuration of=0A=
   IEEE 1588-2008 devices and clocks, and also retrieval of the=0A=
   configuration information, data set and running states of IEEE=0A=
   1588-2008 clocks.=0A=
=0A=
=0A=
=0A=
=0A=
Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.=0A=
=0A=
The IETF Secretariat=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Mon Oct 30 07:38:51 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D4313F9E4 for ; Mon, 30 Oct 2017 07:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uLmC7XD5PgcN for ; Mon, 30 Oct 2017 07:38:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC213FA24 for ; Mon, 30 Oct 2017 07:38:23 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 48AE31AE01AA; Mon, 30 Oct 2017 15:38:21 +0100 (CET)
Date: Mon, 30 Oct 2017 15:36:56 +0100 (CET)
Message-Id: <20171030.153656.1325329737662426135.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20171029185057.hecz7vgul343tjki@elstar.local>
References: <20171029185057.hecz7vgul343tjki@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] review of draft-ietf-netmod-yang-tree-diagrams-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, 30 Oct 2017 14:38:49 -0000

Hi,

Thank you for this review!  Comments inline.

Juergen Schoenwaelder  wrote:
> Hi,
> 
> I have reviewed draft-ietf-netmod-yang-tree-diagrams-02 and here are
> my comments (in document order).
> 
> - I am not sure this is correct:
> 
>   YANG Tree Diagrams were first published in [RFC7223].  Such diagrams
> 
>   I think NACM (RFC 6536) already has a tree diagram. This makes for a
>   difference of ~2 years. Note sure this matter much however.

I'll fix this.

> - Do we have to speak more specifically about 'schema tree diagrams'?
>   Note that there can be many more 'tree' diagrams, like instance tree
>   diagrams, identity derivation diagrams, type derivation diagrams,
>   import relationship diagrams, ... and perhaps it makes sense to
>   allow for other diagrams to be defined over time.

I agree that there can be different types of tree.  I have to think
about this and discuss with my co-author.


> - Should we use 'sibling nodes' instead of 'peer nodes'? I think
>   the term 'sibling' is used in RFC 7950.

Yes.

> - Are the empty lines mandatory or can empty lines added as one sees
>   fit? In particular, is there an empty line after the module: line?
>   Is there an empty line before each section of different top-level
>   symbols? Does the order of top-level symbols matter? Do we really
>   want to specify these details? Well, for indentation, things are
>   pretty specific so I wonder what the general strategy is here.

For indentation, spaces a specified b/c they matter (ok, we *could*
specify some more flexible indentation rules).  Blank line do not
matter.  Do you think we should say something about this?

> - There was already some discussion about having a way to not always
>   expand groupings by showing uses nodes. I think this makes sense in
>   certain situations (possible  '-u').

Ok, I also think we should add something like this.

> - What are 'data modules'? This term does not appear in schema mount
>   I think. Perhaps you wanted YANG modules instead?

Yes.

> - s/realted/related/

Fixed.

> - I think Section 4.1 is not about representing _instance_ data
>   trees. It is describing how a schema mounted schema looks like - and
>   I think this is OK. I think this document should not specify
>   instance tree formats. So change the title of section 4.1 or simply
>   delete the subsection title entirely.

I agree.  How about "Representation of Mounted Data Trees"?

> - If a schema mount point is used for a readonly mount, then I
>   understand that only the toplevel changes to ro. Is this useful or
>   potentially misleading? Was the alternative considered to change all
>   nodes recursively to ro? I assume they are all effectively ro in
>   this case.

Hmm, I'll check w/ my co-author.  I think it should be changed
recursively.

> - If the WG wants to include tree diagram usage guidelines in this
>   document, then I think we should (if we still manage) take tree
>   diagram related text out of 6087bis before it is cast into
>   stone. Changes to 6087bis would be:
> 
>   - Change the subsubstitle "2.5.1.  YANG Tree Diagrams" to "2.6.
>     YANG Tree Diagrams" (since the definition is in an external
>     document, I think this should not be nested in 2.5 anymore).
> 
>   - Remove section 3.4.
> 
>   - Remove this from section 8 (which is not quite correct anymore
>     anyway since the definition moved to a separate document).
> 
>        o  Added YANG tree diagram definition and guideline
> 
>   Since two are bug fixes anyway (I think), I think it makes sense to
>   get 6087bis fixed so that the tree diagram usage text is in one
>   place.

I have no strong opinion, but I think I prefer to have the guidelines
for tree diagrams in the tree diagram draft.  Maybe 6087 can point to
this document.


/martin


From nobody Mon Oct 30 07:50:28 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CD313B0EA for ; Mon, 30 Oct 2017 07:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weIO7I2MBRfk for ; Mon, 30 Oct 2017 07:50:24 -0700 (PDT)
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 4FBF713FA20 for ; Mon, 30 Oct 2017 07:50:19 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id E6E251AB047 for ; Mon, 30 Oct 2017 08:50:18 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id TqqE1w00l2SSUrH01qqHdf; Mon, 30 Oct 2017 08:50:18 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=Cyd4A4qa2fozdD_9rAQA:9 a=CjuIK1q_8ugA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DM3qlQv14I/p+aiiBmEIS9jpwB/2PfP9fCcocClPvJU=; b=WwnSS+gk+EP+aJoHbOuGmAqrYq pjyvv+g4fUxp8W1Ms4mhjXWEW0otYSRqcfXshGNKrXNhkQIKZWIh9AiZcSO8YJQmAPjSvRXmhjJQR A35FGSfXpllhetj7j9y/NvtZJ;
Received: from [172.58.185.237] (port=40649 helo=[IPV6:2607:fb90:6504:3501:0:45:a4fa:7e01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1e9BOI-004GzV-KM; Mon, 30 Oct 2017 08:50:14 -0600
From: Lou Berger 
To: Martin Bjorklund , 
CC: 
Date: Mon, 30 Oct 2017 10:50:11 -0400
Message-ID: <15f6dc2e8b8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171030.153656.1325329737662426135.mbj@tail-f.com>
References: <20171029185057.hecz7vgul343tjki@elstar.local> <20171030.153656.1325329737662426135.mbj@tail-f.com>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
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: 172.58.185.237
X-Exim-ID: 1e9BOI-004GzV-KM
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:6504:3501:0:45:a4fa:7e01]) [172.58.185.237]:40649
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] review of draft-ietf-netmod-yang-tree-diagrams-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, 30 Oct 2017 14:50:26 -0000

Hi,

See below.


On October 30, 2017 10:39:31 AM Martin Bjorklund  wrote:

> Hi,
>
> Thank you for this review!  Comments inline.
>
> Juergen Schoenwaelder  wrote:
>> Hi,
>>
>> I have reviewed draft-ietf-netmod-yang-tree-diagrams-02 and here are
>> my comments (in document order).
>>
>> - I am not sure this is correct:
>>
>>   YANG Tree Diagrams were first published in [RFC7223].  Such diagrams
>>
>>   I think NACM (RFC 6536) already has a tree diagram. This makes for a
>>   difference of ~2 years. Note sure this matter much however.
>
> I'll fix this.
>
>> - Do we have to speak more specifically about 'schema tree diagrams'?
>>   Note that there can be many more 'tree' diagrams, like instance tree
>>   diagrams, identity derivation diagrams, type derivation diagrams,
>>   import relationship diagrams, ... and perhaps it makes sense to
>>   allow for other diagrams to be defined over time.
>
> I agree that there can be different types of tree.  I have to think
> about this and discuss with my co-author.
>

We can discuss off line then get back to the wg- we can try to cover this 
in our ietf100 slot.

>
>> - Should we use 'sibling nodes' instead of 'peer nodes'? I think
>>   the term 'sibling' is used in RFC 7950.
>
> Yes.
>
Wfm.

>> - Are the empty lines mandatory or can empty lines added as one sees
>>   fit? In particular, is there an empty line after the module: line?
>>   Is there an empty line before each section of different top-level
>>   symbols? Does the order of top-level symbols matter? Do we really
>>   want to specify these details? Well, for indentation, things are
>>   pretty specific so I wonder what the general strategy is here.
>
> For indentation, spaces a specified b/c they matter (ok, we *could*
> specify some more flexible indentation rules).  Blank line do not
> matter.  Do you think we should say something about this?
>
>> - There was already some discussion about having a way to not always
>>   expand groupings by showing uses nodes. I think this makes sense in
>>   certain situations (possible  '-u').
>
> Ok, I also think we should add something like this.
>

No objections.

>> - What are 'data modules'? This term does not appear in schema mount
>>   I think. Perhaps you wanted YANG modules instead?
>
> Yes.
>
>> - s/realted/related/
>
> Fixed.
>
Thanks.

>> - I think Section 4.1 is not about representing _instance_ data
>>   trees. It is describing how a schema mounted schema looks like - and
>>   I think this is OK. I think this document should not specify
>>   instance tree formats. So change the title of section 4.1 or simply
>>   delete the subsection title entirely.
>
> I agree.  How about "Representation of Mounted Data Trees"?
>

Wfm.

>> - If a schema mount point is used for a readonly mount, then I
>>   understand that only the toplevel changes to ro. Is this useful or
>>   potentially misleading? Was the alternative considered to change all
>>   nodes recursively to ro? I assume they are all effectively ro in
>>   this case.
>
> Hmm, I'll check w/ my co-author.  I think it should be changed
> recursively.
>

I think this is a good improvement.

>> - If the WG wants to include tree diagram usage guidelines in this
>>   document, then I think we should (if we still manage) take tree
>>   diagram related text out of 6087bis before it is cast into
>>   stone. Changes to 6087bis would be:
>>
>>   - Change the subsubstitle "2.5.1.  YANG Tree Diagrams" to "2.6.
>>     YANG Tree Diagrams" (since the definition is in an external
>>     document, I think this should not be nested in 2.5 anymore).
>>
>>   - Remove section 3.4.
>>
>>   - Remove this from section 8 (which is not quite correct anymore
>>     anyway since the definition moved to a separate document).
>>
>>        o  Added YANG tree diagram definition and guideline
>>
>>   Since two are bug fixes anyway (I think), I think it makes sense to
>>   get 6087bis fixed so that the tree diagram usage text is in one
>>   place.
>
> I have no strong opinion, but I think I prefer to have the guidelines
> for tree diagrams in the tree diagram draft.  Maybe 6087 can point to
> this document.
>

I agree.

Thanks,
Lou
Co-author
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



From nobody Mon Oct 30 08:07:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A173313FA5F for ; Mon, 30 Oct 2017 08:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 HRFxhBJYDkzL for ; Mon, 30 Oct 2017 08:07:48 -0700 (PDT)
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 8302F13FA68 for ; Mon, 30 Oct 2017 08:07:26 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AC2D83B; Mon, 30 Oct 2017 16:07:24 +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 0JZRZwjHbZNl; Mon, 30 Oct 2017 16:07:22 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 30 Oct 2017 16:07:24 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94ADC2010F; Mon, 30 Oct 2017 16:07:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SQ3VlkE4d72m; Mon, 30 Oct 2017 16:07:24 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0368C2010E; Mon, 30 Oct 2017 16:07:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 08FA14143AC3; Mon, 30 Oct 2017 16:05:56 +0100 (CET)
Date: Mon, 30 Oct 2017 16:05:56 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Message-ID: <20171030150556.frebbljyv26buiub@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20171029185057.hecz7vgul343tjki@elstar.local> <20171030.153656.1325329737662426135.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171030.153656.1325329737662426135.mbj@tail-f.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] review of draft-ietf-netmod-yang-tree-diagrams-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, 30 Oct 2017 15:07:50 -0000

On Mon, Oct 30, 2017 at 03:36:56PM +0100, Martin Bjorklund wrote:
> > - Are the empty lines mandatory or can empty lines added as one sees
> >   fit? In particular, is there an empty line after the module: line?
> >   Is there an empty line before each section of different top-level
> >   symbols? Does the order of top-level symbols matter? Do we really
> >   want to specify these details? Well, for indentation, things are
> >   pretty specific so I wonder what the general strategy is here.
> 
> For indentation, spaces a specified b/c they matter (ok, we *could*
> specify some more flexible indentation rules).  Blank line do not
> matter.  Do you think we should say something about this?

I would hope that nobody ever comes up with the idea of writing
programs to parse tree diagrams, hence I am fine with a rather liberal
definition (and I also do not care about the exact number of spaces
but I if it helps to describe the indentation rules then OK).

> > - I think Section 4.1 is not about representing _instance_ data
> >   trees. It is describing how a schema mounted schema looks like - and
> >   I think this is OK. I think this document should not specify
> >   instance tree formats. So change the title of section 4.1 or simply
> >   delete the subsection title entirely.
> 
> I agree.  How about "Representation of Mounted Data Trees"?

Isn't is a mounted schema tree?

> > - If a schema mount point is used for a readonly mount, then I
> >   understand that only the toplevel changes to ro. Is this useful or
> >   potentially misleading? Was the alternative considered to change all
> >   nodes recursively to ro? I assume they are all effectively ro in
> >   this case.
> 
> Hmm, I'll check w/ my co-author.  I think it should be changed
> recursively.
 
> > - If the WG wants to include tree diagram usage guidelines in this
> >   document, then I think we should (if we still manage) take tree
> >   diagram related text out of 6087bis before it is cast into
> >   stone. Changes to 6087bis would be:
> > 
> >   - Change the subsubstitle "2.5.1.  YANG Tree Diagrams" to "2.6.
> >     YANG Tree Diagrams" (since the definition is in an external
> >     document, I think this should not be nested in 2.5 anymore).
> > 
> >   - Remove section 3.4.
> > 
> >   - Remove this from section 8 (which is not quite correct anymore
> >     anyway since the definition moved to a separate document).
> > 
> >        o  Added YANG tree diagram definition and guideline
> > 
> >   Since two are bug fixes anyway (I think), I think it makes sense to
> >   get 6087bis fixed so that the tree diagram usage text is in one
> >   place.
> 
> I have no strong opinion, but I think I prefer to have the guidelines
> for tree diagrams in the tree diagram draft.  Maybe 6087 can point to
> this document.

RFC 6087bis would still point to the tree diagram if you apply the
edits above but it would no do anything more than that.

/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 Oct 30 08:11:39 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C1E13FA5B for ; Mon, 30 Oct 2017 08:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NcgfD0FGP2Kx for ; Mon, 30 Oct 2017 08:11:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8613F547 for ; Mon, 30 Oct 2017 08:10:55 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id DFC7E1AE01AA; Mon, 30 Oct 2017 16:10:53 +0100 (CET)
Date: Mon, 30 Oct 2017 16:09:29 +0100 (CET)
Message-Id: <20171030.160929.235441604951701829.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20171030150556.frebbljyv26buiub@elstar.local>
References: <20171029185057.hecz7vgul343tjki@elstar.local> <20171030.153656.1325329737662426135.mbj@tail-f.com> <20171030150556.frebbljyv26buiub@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] review of draft-ietf-netmod-yang-tree-diagrams-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, 30 Oct 2017 15:11:38 -0000

Juergen Schoenwaelder  wrote:
> On Mon, Oct 30, 2017 at 03:36:56PM +0100, Martin Bjorklund wrote:
> > > - Are the empty lines mandatory or can empty lines added as one sees
> > >   fit? In particular, is there an empty line after the module: line?
> > >   Is there an empty line before each section of different top-level
> > >   symbols? Does the order of top-level symbols matter? Do we really
> > >   want to specify these details? Well, for indentation, things are
> > >   pretty specific so I wonder what the general strategy is here.
> > 
> > For indentation, spaces a specified b/c they matter (ok, we *could*
> > specify some more flexible indentation rules).  Blank line do not
> > matter.  Do you think we should say something about this?
> 
> I would hope that nobody ever comes up with the idea of writing
> programs to parse tree diagrams, hence I am fine with a rather liberal
> definition (and I also do not care about the exact number of spaces
> but I if it helps to describe the indentation rules then OK).
> 
> > > - I think Section 4.1 is not about representing _instance_ data
> > >   trees. It is describing how a schema mounted schema looks like - and
> > >   I think this is OK. I think this document should not specify
> > >   instance tree formats. So change the title of section 4.1 or simply
> > >   delete the subsection title entirely.
> > 
> > I agree.  How about "Representation of Mounted Data Trees"?
> 
> Isn't is a mounted schema tree?

Whoops, yes:   "Representation of Mounted Schema Trees".


> > > - If a schema mount point is used for a readonly mount, then I
> > >   understand that only the toplevel changes to ro. Is this useful or
> > >   potentially misleading? Was the alternative considered to change all
> > >   nodes recursively to ro? I assume they are all effectively ro in
> > >   this case.
> > 
> > Hmm, I'll check w/ my co-author.  I think it should be changed
> > recursively.
>  
> > > - If the WG wants to include tree diagram usage guidelines in this
> > >   document, then I think we should (if we still manage) take tree
> > >   diagram related text out of 6087bis before it is cast into
> > >   stone. Changes to 6087bis would be:
> > > 
> > >   - Change the subsubstitle "2.5.1.  YANG Tree Diagrams" to "2.6.
> > >     YANG Tree Diagrams" (since the definition is in an external
> > >     document, I think this should not be nested in 2.5 anymore).
> > > 
> > >   - Remove section 3.4.
> > > 
> > >   - Remove this from section 8 (which is not quite correct anymore
> > >     anyway since the definition moved to a separate document).
> > > 
> > >        o  Added YANG tree diagram definition and guideline
> > > 
> > >   Since two are bug fixes anyway (I think), I think it makes sense to
> > >   get 6087bis fixed so that the tree diagram usage text is in one
> > >   place.
> > 
> > I have no strong opinion, but I think I prefer to have the guidelines
> > for tree diagrams in the tree diagram draft.  Maybe 6087 can point to
> > this document.
> 
> RFC 6087bis would still point to the tree diagram if you apply the
> edits above but it would no do anything more than that.

Ok.


/martin


From nobody Mon Oct 30 11:04:38 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3118F9779; Mon, 30 Oct 2017 11:04:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150938667618.7740.9329916707346317532@ietfa.amsl.com>
Date: Mon, 30 Oct 2017 11:04:36 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-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, 30 Oct 2017 18:04:36 -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 Management Datastore Architecture
        Authors         : Martin Bjorklund
                          Juergen Schoenwaelder
                          Phil Shafer
                          Kent Watsen
                          Robert Wilton
	Filename        : draft-ietf-netmod-revised-datastores-06.txt
	Pages           : 38
	Date            : 2017-10-30

Abstract:
   Datastores are a fundamental concept binding the data models written
   in the YANG data modeling language to network management protocols
   such as NETCONF and RESTCONF.  This document defines an architectural
   framework for datastores based on the experience gained with the
   initial simpler model, addressing requirements that were not well
   supported in the initial model.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-06
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-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 Mon Oct 30 15:14:06 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 746FB13AB2F; Mon, 30 Oct 2017 15:13:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150940163943.28329.16497366890826536680@ietfa.amsl.com>
Date: Mon, 30 Oct 2017 15:13:59 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-03.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, 30 Oct 2017 22:13: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           : Sub-interface VLAN YANG Data Models
        Authors         : Robert Wilton
                          David Ball
                          Tapraj Singh
                          Selvakumar Sivaraj
	Filename        : draft-ietf-netmod-sub-intf-vlan-model-03.txt
	Pages           : 27
	Date            : 2017-10-30

Abstract:
   This document defines YANG modules to add support for classifying
   traffic received on interfaces as Ethernet/VLAN framed packets to
   sub-interfaces based on the fields available in the Ethernet/VLAN
   frame headers.  These modules allow configuration of Layer 3 and
   Layer 2 sub-interfaces (e.g. attachment circuits) that can
   interoperate with IETF based forwarding protocols; such as IP and
   L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN.  The
   sub-interfaces also interoperate with VLAN tagged traffic orginating
   from an IEEE 802.1Q compliant bridge.  Primarily the classification
   is based on VLAN identifiers in the 802.1Q VLAN tags, but the model
   also has support for matching on some other layer 2 frame header
   fields and is designed to be extensible to match on other arbitrary
   header fields.

   The model differs from an IEEE 802.1Q bridge model in that the
   configuration is interface/sub-interface based as opposed to being
   based on membership of an 802.1Q VLAN bridge.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-03
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-sub-intf-vlan-model-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-03


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Oct 31 03:25:31 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228E2139507 for ; Tue, 31 Oct 2017 03:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGJJI-CDbMGZ for ; Tue, 31 Oct 2017 03:25:27 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEE9139B9F for ; Tue, 31 Oct 2017 03:25:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 178FC261846 for ; Tue, 31 Oct 2017 11:25:28 +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 nKBsV94ChuEr for ; Tue, 31 Oct 2017 11:25:25 +0100 (CET)
Received: from localhost (Mission-Control.SpriteLink.NET [195.182.5.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id BD1BF261838 for ; Tue, 31 Oct 2017 11:25:25 +0100 (CET)
Date: Tue, 31 Oct 2017 11:25:23 +0100
From: Kristian Larsson 
To: "netmod@ietf.org" 
Message-ID: <20171031102523.GB25608@spritelink.se>
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Oct 2017 10:25:30 -0000

On Fri, Oct 20, 2017 at 09:37:04PM +0000, Kent Watsen wrote:
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-acl-model-14.
> 
> The working group last call ends on November 3.
> Please send your comments to the netmod mailing list.


I initially read this draft (or an older version) close to a year
ago and meant to give feedback back then. I first wanted to read
up on the list archive on any previous discussions (since the
initial draft is reaaaally old) but ran out of time.

I have still not read all previous discussions (there are 687
emails when searching for 'acl' in the archive) and therefore
I'll apologise beforehand as I'm bound to reiterate questions or
topics that have been brought up already. I'd be grateful if
those with the history in memory can help me by providing
references to the list archive.

Anyway, to the model. There's this concept of unified ACLs. I
see two dimensions:
 * mixed layer ACLs, where we match on headers in different
   layers in the OSI/TCP/IP model, like ethernet and ipv4
 * mixed family ACLs, where we in one ACL match on different
   protocols in the same OSI model layer, like both IPv4 and
   IPv6. However, within one ACE we always just match on one
   protocol.

What I don't understand is why under the matches container there
are these other containers, like l2-acl, ipv4-acl, ipv6-acl,
l2-l3-ipv4-acl etc? Depending on the type I would input the
ethernet matches in different places. That seems suboptimal.  If
we wanted an ACL type per AFI then we could have just created a
top level list per AFI instead of trying to pretend they are
unified by putting them in one list and then splitting it up
further down under the matches container. In that case, the
attachment points would also have been made much simpler with
just a single reference instead of having two leaves like the
current model.

It seems to me that this can be modeled in a more elegant way by
having the following containers under matches:
 * ethernet
 * ipv4
 * ipv6
 * tcp
 * udp
 * icmp

The ethernet containers presence is conditioned on the acl-type
being one of l2-acl, l2-l3-ipv4-acl, l2-l3-ipv6-acl or
l2-l3-ipv4-ipv6-acl.

The ipv4 container is conditioned on the acl-type being one of
ipv4-acl, l2-l3-ipv4-acl, l2-l3-ipv4-ipv6-acl.

The ipv6 container is conditioned on the acl-type being one of
ipv6-acl, l2-l3-ipv6-acl, l2-l3-ipv4-ipv6-acl.

In addition, there is a condition that prevents both the IPv4 and
IPv6 container being present at the same time, since we can't
match on both of them with the same ACE. Another ACE in the same
ACL can however match on something else.

Similarly, there's a condition on tcp, udp and icmp preventing
them all from being configured. Perhaps it should just look
differently, like a choice? Or maybe a match on protocol=tcp/udp
and then we have a container for tcp-flags etc.  We can delve
into the details later, I just want to first understand why the
current model is thought of as a good approach for expressing
this data? IMHO it's awkward.


This brings us to the acl-type. It seems to me that this is
primarily for being able to do YANG validation when a device does
NOT support a unified model. I.e. if Linux nftables was all we
wanted to model, then we wouldn't need this and the only
(implied) acl-type would be l2-l3-ipv4-acl. In reality though, we
need acl-type because most current network devices out there have
per-AFI types and we want to be able to say:
 * this interface attachment point can only do ipv4-acl
And still be able to validate the data based on the YANG model.
Is this correct? It seems like one hell of a design trade-off to
be able to achieve that. Wouldn't we be better off with actually
having different list of ACLs, again vastly simplifying the
attachment points and making data validation much easier?

If all we want to do is limit so the source address can't be
configured to be an IPv4 address when the destination address is
IPv6 I think it's better to have a "family" leaf per ACE that
defines ipv4 or ipv6, or just let the ipv4 and ipv6 containers be
mutually exclusive through other means, as I eluded to
previously.


The current attachment points seem to be a list of interfaces
using the interface-ref type from ietf-interfaces. I guess there
was a reason we don't augment the ietf-interfaces module. What if
the device is Linux with nftables? There's no attachment to an
interface as it's a global rule list. I think this is
conceptually the same as attaching the same ACL on all interfaces
but that would be an awkward way of describing a global
attachment point. Would it not be better to if-feature wrap this
and allow a global attachment point which has a more direct
mapping to nftables? The same is of course for any device type
with a global table, like most firewalls.



Other issues / questions;
 * in 1. mentions it can be used in routing protocols - is
   that really intended?
 * in 1. says "In ordet to apply an ACL to any attachment
   point, vendors would have to augment the ACL YANG model", is
   this really true? Surely we have standard attachment points.
 * in 1. the examples of use start with policy based
   routing and then firewalls. ISTM that ACLs are primarily used for
   "packet filters" so it's weird it's not even included.
   Firewall often implies statefulness, which is not really what
   we are dealing with here and PBR is not nearly as use as
   packet filters. Maybe everyone knows this already, but then
   why write anything at all?
 * in 1. "in case vendors supports it, metadata matches apply.." why
   include a condition on if the vendors supports it? this is
   true for anything, "in case the vendor supports it, the BGP
   routing protocol works this way...". I think we can require
   certain metadata matches in the model, or just do if-feature,
   but constantly prefixing everything with a "in case vendor.."
   is unnecessary IMHO
 * in 1. ISTM: s/networked devices/networking device/
 * in 3. "each ACE has a group of match criteria and a group of action
   criteria" - no, it does not, actions are not a criteria!?
 * indent is mix of tabs and spaces
 * the icmp-off action leaf is IMHO weirdly modeled and it's a
   weird option in itself - can you point to vendors implementing
   similar options? this seems doable by just having an ACE match
   on ICMP and action=drop
 * why eth-acl vs l2-acl. this is mixing apples and pears. L2 is
   a layer in the TCP/IP model whereas ethernet is one
   implementation of an L2 protocol. Why name the identify
   eth-acl and the match container l2-acl?
 * why have the "acl-sets" container? why not just have the list
   directly?
 * the leafrefs in the interface-acl grouping are relative making
   it impossible to re-use the grouping at a different "depth"
 * letting the matched-packets be EITHER per-interface per-ACE OR
   per-ACE across all interfaces seems insane. We have to know
   what we are getting back. Better to have separate counters
   then and let vendor fill in one or the other? Or declare
   deviations? Curreny mode is not useful at all.

Again, apologies for my ignorance.

Kind regards,
   Kristian.


-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511                                kll@spritelink.net


From nobody Tue Oct 31 03:49:23 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C580C138103 for ; Tue, 31 Oct 2017 03:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liTEw4Jw4Dhz for ; Tue, 31 Oct 2017 03:49:20 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D50413B1B2 for ; Tue, 31 Oct 2017 03:49:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3138; q=dns/txt; s=iport; t=1509446959; x=1510656559; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=kYuzGXg/5wBR/lAI+0WLBloQmH8jlXe7nRksJM0E0f4=; b=DGALYdthXWzwHMfkoU2TXK+eiLo4hM4hMEXvL3A3NAMLe0QhOCQE84SK hmxFnvFZtDuMPvm0pXCOKhq8eXB7BGxZo7bnTIYgLRDJnjQWx5WVdnOkm 91ZZutPcLlj4J0t+XA91V44/P0Ans6oAqjmU2E7GhDoscaIPYBSUY81ei E=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAQD1U/hZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTGEI4sTj3cmfJVGghEHA4U7AoUmFwECAQEBAQEBAWsohR4BBAE?= =?us-ascii?q?jWwsLQgICVwYBDAgBAYoXCKg6gieLCAEBAQEBAQEDAQEBAQEBARIPgy6FQykLg?= =?us-ascii?q?kE1iCaCYQWiBIRCgiOOF4t0hzqWEoE5IAE2gWg0IQgdFUmCZYRfQIogLIIWAQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.44,323,1505779200";  d="asc'?scan'208";a="658408561"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2017 10:49:17 +0000
Received: from [10.61.239.244] ([10.61.239.244]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9VAnGMb016780; Tue, 31 Oct 2017 10:49:16 GMT
To: Kristian Larsson , "netmod@ietf.org" 
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se>
From: Eliot Lear 
Message-ID: <2c541487-2243-766f-0cdf-6545332cad83@cisco.com>
Date: Tue, 31 Oct 2017 11:47:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171031102523.GB25608@spritelink.se>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j0ePNQWjanKneEs26WnVtx1mcWSJ5L190"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Oct 2017 10:49:22 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--j0ePNQWjanKneEs26WnVtx1mcWSJ5L190
Content-Type: multipart/mixed; boundary="HRAMw8I064SV6LnXwtiCe6wHqugjvVAaN";
 protected-headers="v1"
From: Eliot Lear 
To: Kristian Larsson ,
 "netmod@ietf.org" 
Message-ID: <2c541487-2243-766f-0cdf-6545332cad83@cisco.com>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net>
 <20171031102523.GB25608@spritelink.se>
In-Reply-To: <20171031102523.GB25608@spritelink.se>

--HRAMw8I064SV6LnXwtiCe6wHqugjvVAaN
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Kristian,

Just my view below:


On 10/31/17 11:25 AM, Kristian Larsson wrote:

> This brings us to the acl-type. It seems to me that this is
> primarily for being able to do YANG validation when a device does
> NOT support a unified model. I.e. if Linux nftables was all we
> wanted to model, then we wouldn't need this and the only
> (implied) acl-type would be l2-l3-ipv4-acl. In reality though, we
> need acl-type because most current network devices out there have
> per-AFI types and we want to be able to say:
>  * this interface attachment point can only do ipv4-acl
> And still be able to validate the data based on the YANG model.
> Is this correct? It seems like one hell of a design trade-off to
> be able to achieve that. Wouldn't we be better off with actually
> having different list of ACLs, again vastly simplifying the
> attachment points and making data validation much easier?

This reflects, IMHO, the complexity of the situation.=C2=A0 You want
consistent policy implemented to the full extent of device
capabilities.=C2=A0 That means that if someone wants to generate a mixed =
mode
ACL, they can.=C2=A0 But if we attempt to separate those mixed modes on t=
he
device, can we guarantee that we have gotten the intent correct and
consistent with, say, what would have been the mixed mode?=C2=A0 I think
that's how we got here but others can speak more authoritatively.=C2=A0 A=
nd
keep in mind, all of this ties to efficient use of device resources, and
so there's a lot of h/w optimization seemingly going on here.

Eliot





--HRAMw8I064SV6LnXwtiCe6wHqugjvVAaN--

--j0ePNQWjanKneEs26WnVtx1mcWSJ5L190
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ+FTbAAoJEIe2a0bZ0nozolcIALkD+DbKNL2e4yaEwRFOkDB1
T/aAklGlh5z4LHX/pAUxQkfQFI/lkIQqEL7ePDFmF2tb6P7jud0uRcN6RcZo/ap+
pJkd9TDV+gA27D+p4tYFWbvvr9OLhbNpagLatkZThUI/hxRfdg1m55zNOHMWsYJd
kVP4EeCcQWheL9w588lGtJ1O1+zzzWEzi1UDTL/lePr7wBvHtuiigIavKkzcgV8c
Jj4v9/XOyx22TVOrd11e4tojfKL33IhAKhH+sLbMguux9D3A/AZleBOESG9425qh
jMHuC/B6vMhws/S5OQ9GDsDwk5kNFui38BTuHh+Pe1NzWVur8ohRaXeveAsj2ME=
=eKE0
-----END PGP SIGNATURE-----

--j0ePNQWjanKneEs26WnVtx1mcWSJ5L190--


From nobody Tue Oct 31 04:37:55 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3070713F439 for ; Tue, 31 Oct 2017 04:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oaWuce1ZfxMQ for ; Tue, 31 Oct 2017 04:37:51 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCEF13F62F for ; Tue, 31 Oct 2017 04:37:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id E15C2261846; Tue, 31 Oct 2017 12:37:50 +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 EeXvpfBdXsiU; Tue, 31 Oct 2017 12:37:45 +0100 (CET)
Received: from localhost (Mission-Control.SpriteLink.NET [195.182.5.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 4DBE4261838; Tue, 31 Oct 2017 12:37:45 +0100 (CET)
Date: Tue, 31 Oct 2017 12:37:43 +0100
From: Kristian Larsson 
To: Eliot Lear 
Cc: "netmod@ietf.org" 
Message-ID: <20171031113743.GC25608@spritelink.se>
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <2c541487-2243-766f-0cdf-6545332cad83@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2c541487-2243-766f-0cdf-6545332cad83@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Oct 2017 11:37:54 -0000

On Tue, Oct 31, 2017 at 11:47:54AM +0100, Eliot Lear wrote:
> Hi Kristian,
> 
> Just my view below:
> 
> 
> On 10/31/17 11:25 AM, Kristian Larsson wrote:
> 
> > This brings us to the acl-type. It seems to me that this is
> > primarily for being able to do YANG validation when a device does
> > NOT support a unified model. I.e. if Linux nftables was all we
> > wanted to model, then we wouldn't need this and the only
> > (implied) acl-type would be l2-l3-ipv4-acl. In reality though, we
> > need acl-type because most current network devices out there have
> > per-AFI types and we want to be able to say:
> >  * this interface attachment point can only do ipv4-acl
> > And still be able to validate the data based on the YANG model.
> > Is this correct? It seems like one hell of a design trade-off to
> > be able to achieve that. Wouldn't we be better off with actually
> > having different list of ACLs, again vastly simplifying the
> > attachment points and making data validation much easier?
> 
> This reflects, IMHO, the complexity of the situation.  You want
> consistent policy implemented to the full extent of device
> capabilities.

I'd argue we are not achieving that anyway because of the
previously mentioned container mess. I.e. on a a Cisco I'd have
to do matches/ipv4-acl/foo while on my Linux machine I'd do
matches/l2-l3-ipv4-ipv6-acl/foo. Thus multiple ACLs need to be
generates for any heterogenous network. We missed the goal with
the model.


>  That means that if someone wants to generate a mixed mode
> ACL, they can.  But if we attempt to separate those mixed modes on the
> device, can we guarantee that we have gotten the intent correct and
> consistent with, say, what would have been the mixed mode?  I think
> that's how we got here but others can speak more authoritatively.  And
> keep in mind, all of this ties to efficient use of device resources, and
> so there's a lot of h/w optimization seemingly going on here.

So how is the current situation better than doing:

module: ietf-access-control-list
    +--rw access-lists
       +--rw acl [acl-name] <<< this is the unified one
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ethernet
       |        |  +--rw ipv4
       |        |  +--rw ipv6
       |        ...

       +--rw ipv4-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

       +--rw ipv6-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

I'm really bothered by the compound key consisting of acl-type
and the acl-name since attachment points then need to reference
both.  It's also weird because I don't think choosing the
acl-type is really a choice of the user but more of a limitation
of the platform.

One approach would be to change the key to only be the acl-name
but let the acl-type leaf remain, perhaps make it mandatory or
default to some unified acl-type. I think it's still possible to
implement a constraint on this, right? Like if a platform only
supports a specific type at some attachment point it can add a
constraint on the acl-type by doing deref() on the leafref.

module a-vendor-module {
  list interfaces {
		leaf ingress-acl {
		  type leafref {
			  path "/acl:access-lists/acl/acl-name";
			}
			must 'yangexp:deref(.)/../acl-type="ipv4-acl"';
		}
  }
}

I think that looks much nicer. Am I missing something?

It would create a single namespace for all ACL types which is
potentially a problem for some vendors when doing backwards
mapping, like they have separate ipv4 and ipv6 acls today and
when starting to support this new model you could end up in a
collision. But if that is the case, would it not be okay to just
prefix the type to the name as part of the data translation?

Kind regards,
   Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511                                kll@spritelink.net


From nobody Tue Oct 31 07:00:58 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75EE13943F for ; Tue, 31 Oct 2017 07:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqSpbFH6Rt5m for ; Tue, 31 Oct 2017 07:00:53 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB33137C2E for ; Tue, 31 Oct 2017 07:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2569; q=dns/txt; s=iport; t=1509458453; x=1510668053; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=nZoA/qAwomdJDSTmHOc/vuAbFt3iL29NndN0kEoiWZ0=; b=ZFm8ofUY9+xJrFAgQQBfW9HxCmLlp2zUQzDKfEC/Jc2rtUEyJGNrBj9o WnvS4xgOn+AGmaj/BOjGY7nflMLzh/xTLWp++AobdyWiTpb/TDJcbTXuk jzskVZZ7thyTF/7YuyfkZOzVUdBOY9285oYaprXScHw2hclmtHXIcO38K s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAQAYgfhZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N8ih90j3kmlkIQggEKGA2ER08ChSoYAQIBAQEBAQEBayi?= =?us-ascii?q?FHgEBBAEBIQ8BBTQCGwsSBgICJgICJyIOEwYCAQGKHxCoL4IniwgBAQEBBgEBA?= =?us-ascii?q?QEBASKBD4Ifg1qBaSkLgnaDPoEgARIBa4JJgmEFogaHZo0WghVehSKDX4c6jF+?= =?us-ascii?q?BR4dsgTkfOIEDaDQhCB0VHyqCZAmEVkE2iSGCNQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,324,1505779200"; d="scan'208";a="655779732"
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; 31 Oct 2017 14:00:51 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9VE0oUi013509 for ; Tue, 31 Oct 2017 14:00:51 GMT
To: netmod@ietf.org
References: <150938667618.7740.9329916707346317532@ietfa.amsl.com>
From: Robert Wilton 
Message-ID: <4f912b72-7875-ba3a-821e-775d728a2e22@cisco.com>
Date: Tue, 31 Oct 2017 14:00:50 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <150938667618.7740.9329916707346317532@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-06.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, 31 Oct 2017 14:00:57 -0000

So this version of the draft contains the small change that defines 
"datastore schema" and describes the "datastore schema" of  
as being the superset of the datastore schema for all the configuration 
datastores.

There are two remaining issues open on the issue tracker 
(https://github.com/netmod-wg/datastore-dt/issues):

(1) Sign off that usage of RFC 2119 language is appropriate. Perhaps one 
of the proponents of this change could please verify this.
(2) The email thread regarding Actions and RPCs in NMDA.  I will send 
updated proposed text on the appropriate thread.

Thanks,
Rob


On 30/10/2017 18:04, 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 Management Datastore Architecture
>          Authors         : Martin Bjorklund
>                            Juergen Schoenwaelder
>                            Phil Shafer
>                            Kent Watsen
>                            Robert Wilton
> 	Filename        : draft-ietf-netmod-revised-datastores-06.txt
> 	Pages           : 38
> 	Date            : 2017-10-30
>
> Abstract:
>     Datastores are a fundamental concept binding the data models written
>     in the YANG data modeling language to network management protocols
>     such as NETCONF and RESTCONF.  This document defines an architectural
>     framework for datastores based on the experience gained with the
>     initial simpler model, addressing requirements that were not well
>     supported in the initial model.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-06
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-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/
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Tue Oct 31 07:10:37 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BC713F3AC for ; Tue, 31 Oct 2017 07:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=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 olymTbLb3bGV for ; Tue, 31 Oct 2017 07:10:34 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A15613B432 for ; Tue, 31 Oct 2017 07:10:27 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id t139so23531601wmt.1 for ; Tue, 31 Oct 2017 07:10:27 -0700 (PDT)
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=7IPR7Ux+s+MqGQF3w9Rjr8qUfMljZeTSaOah8zcDGG0=; b=P7bkKCH5FfBqeFbn5vN3AvPsrythX7sFMcL5IX2Z1vRboEsMaWQTIRhi0iSNTDkyDX Ou9e6bt3r+FtE40I1/PCMqBXzb/su9xeumyc/UcbhjtMS8sZopiImsojghEp0YZaMlyy 0E11t/0Bs+s3MnFryMjqj0nAgsbqHzrwEwTCf7w38YM1MRFpRNySGEFHgz7f0Viuwfki 7PUwwbDdW/OLjMaK3VspQ95kSl1Rtjo1uI7MIkR/NCN4DDHnWXVCL1SBZxRHZJMdAS0n ozvtpp75Vpcv1YqLyZIb+8ovhUkRrawtsnBbGXQwVi4HFTcNloRxvxyX68VyA/3XrZau yRRQ==
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=7IPR7Ux+s+MqGQF3w9Rjr8qUfMljZeTSaOah8zcDGG0=; b=URQRReFekJb1ILfo3/riGU9fAOFAG64URR+ZWyyxs3DQAWjsod2OsxHft6AGYs73/k BAT+UahRfO/G//wsTiRRKB5KUWr01Qrnlz4pM46VOjv9oPprCcUo5Wzd8aArDrpUSPf8 9nDONQ405WOxjMmCcTM+Kxw3mwwzZoceT23XLsef0mWhhgBkCcH0sDUzLsTrnkxPCFu6 A9yCRzi0KrDqISqk961B42D7P3LBY5GgsqYWi0iuMJGwPWuGkOxW1+Js2uXQtsvwa7gV LZEA9JWI18mXEvDQhqn2iEleJWl0GE9Kx/SamQWxGgWJ4VbNhU6V7rQo+C/a6aI65G76 sCEw==
X-Gm-Message-State: AMCzsaXup6BD2SLWHSXxVatpfQ/HcQx/0w1wij/lw5FVdsarnpp0cQqN gK3Cw1ZbSgzLC/h3QDFqx7/3mHUwBwTvTIzTplXM5A==
X-Google-Smtp-Source: ABhQp+RDEyOLBsqT/b3PuipUpSMr+vAsN/O2q/18VAmwGS0RU11kuaxfYuneErUxr0+vU+SY7UHJUMNITNnbIcK6ZVM=
X-Received: by 10.80.181.61 with SMTP id y58mr3088263edd.150.1509459025615; Tue, 31 Oct 2017 07:10:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.203.201 with HTTP; Tue, 31 Oct 2017 07:09:45 -0700 (PDT)
From: "M. Ranganathan" 
Date: Tue, 31 Oct 2017 10:09:45 -0400
Message-ID: 
To: netmod@ietf.org
Content-Type: multipart/alternative; boundary="f403045c0ac2066249055cd851ae"
Archived-At: 
Subject: [netmod] ietf-access-control-list@2017-10-03.yang : Can access-lists use a grouping?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 14:10:37 -0000

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

Re-posted from OPSAWG list :


Hello,

In the file

ietf-access-control-list@2017-10-03.yang

I see that access-lists is directly defined as a collection.


May I suggest making a grouping (say access-lists-grouping) and use a
"uses" statement in access-lists.

The use-case for this change request - I would like to use the grouping in
another YANG model using a "uses" statement.

Thanks in advance for considering it.

Regards,

Ranga.

-- 
M. Ranganathan

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


Re-posted from OPSAWG list :=



Hello,

In the file=C2=A0 

ietf-access-contr=
ol-list@2017-10-03.yang

I see that access-lists is directly def=
ined as a collection.


May I suggest making a grouping (say=
 access-lists-grouping) and use a "uses" statement in access-list=
s.

The use-case for this change request - I would like to use =
the grouping in another YANG model using a "uses" statement.
<=
br>
Thanks in advance for considering it.

Regards,
Ranga.

-- 
M.=
 Ranganathan




--f403045c0ac2066249055cd851ae--


From nobody Tue Oct 31 07:14:27 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8B713F44D for ; Tue, 31 Oct 2017 07:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 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, 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 bnsghBtzYmMD for ; Tue, 31 Oct 2017 07:14:23 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD844137C2E for ; Tue, 31 Oct 2017 07:14:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13238; q=dns/txt; s=iport; t=1509459263; x=1510668863; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=mDnVFzsDUY+ixTD8IkDka4vROaJCLukv9DT2+o3Cdlo=; b=iKJ5VYM9dYcSoioL7czAInILnCbf0eNThQIUveiUWS5O85vtsCjx1a9s 598zV04CnMp3IESlc4UTO9j4mS3xztUh82d5XvkO6ZW7KeLk21OwU1Waa unQI5lF58JIGPgoMibwhPb7tV+RKHFv+slmzKJHMUULKEOubjkf6kc1Vp I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAACmhPhZ/xbLJq1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvQoESbieDfIofdJAfkH2FRYIRChgBCoRJTwKFKxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUeAQEEAQEhSxsLDgoqAgInMAYBDAYCAQGKHxCoN4InJopkAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWDLoNagWkpgwGEe4MrgmEFogaUfIt0hzqOJodsgTk?= =?us-ascii?q?fOEKBKTQhCB0VSYJkhCA/QTaJFCyCFgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,324,1505779200";  d="scan'208,217";a="698349308"
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; 31 Oct 2017 14:14:20 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9VEEK5o014656; Tue, 31 Oct 2017 14:14:20 GMT
To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org, Randy Presuhn 
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com>
Date: Tue, 31 Oct 2017 14:14:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171027.103341.1048835221774842137.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------631D05CBC99CB4D47F6618AB"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 14:14:26 -0000

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

Hi,

Here is another attempt for proposed text for Actions/RPC statements in 
NMDA.



6.2 Invocation of RPC Operations

This section updates section 7.14 of RFC 7950.

RPCs MAY be defined as affecting the contents of a specific datastore,
any configuration datastore (e.g., ), or any datastore
(e.g., ).  The RPC definition specifies how the RPC input
data is interpreted by the server.

RPCs definitions that do not explicitly state an affected
datastore(s) modify the general operational state of the server.
Hence, if any RPC input data relates to data node instances then
those would generally resolve to data node instances in the
 data tree.


6.3 Invocation of Actions

This section updates section 7.15 of RFC 7950.

In YANG data models, the "action" statement may appear under "config
true" and "config false" schema nodes.  While instances of both
schema nodes may appear in , instances of "config true"
schema nodes may also appear in other datastores.

Actions are always invoked on a data node instance that exist in the
 data tree.  The behavior defined by an action statement
is generally expected to affect the operational state of the server
rather than directly modifying the contents of any configuration
datastore.




On a related note, I also want to confirm that it is right that RPC 
input data is always checked against operational:

Section 6.1. of the NMDA draft states:

    o  If the XPath expression is defined in a substatement to an "input"
       statement in an "rpc" or "action" statement, the accessible tree
       is the RPC or action operation instance and all operational state
       in the server.  The root node has top-level data nodes in all
       modules as children.  Additionally, for an RPC, the root node also
       has the node representing the RPC operation being defined as a
       child.  The node representing the operation being defined has the
       operation's input parameters as children.



Is  always the right datastore to evaluate RPC input/output 
data relative to?  For most RPCs this seems to be the right choice by 
default but it also seems plausible that someone may wish to define an 
RPC that wants to validate its input parameters against the contents of 
another datastore.

An example could be an "is-applied" RPC that takes a path to a subtree 
in  or  and checks whether the configuration for that 
subtree is fully represented in .

Thanks,
Rob


On 27/10/2017 09:33, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <
>> randy_presuhn@alumni.stanford.edu> wrote:
>>
>>> Hi -
>>>
>>> On 10/26/2017 10:44 AM, Robert Wilton wrote:
>>>
>>>> Hi ,
>>>>
>>>> Separating out the issue regarding which datastore action and RPC apply
>>>> to, we propose the following NEW text to the datastores draft:
>>>>
>>>> 6.2 Invocation of Actions and RPC Operations
>>>>
>>>>     This section updates section 7.15. of RFC 7950.
>>>>
>>>>     In YANG data models, the "action" statement may appear under "config
>>>>     true" and "config false" schema nodes.  While instances of both
>>>>     schema nodes may appear in , instances of "config true"
>>>>     schema nodes may also appear in other datastores.
>>>>
>>>>     An NMDA compliant server MUST execute all actions in the context of
>>>>     .  Likewise, an NMDA compliant server MUST invoke all RPC
>>>>     operations in the context of , unless the RPC is
>>>> explicitly
>>>>     defined as affecting other datastores (e.g., ).
>>>>
>>>> OK?
>>>>
>>> A question - I understand the motivation for the "unless" for RPC
>>> operations, but wonder why there is no similar "unless" for actions.
>>>
>>>
>> The  is not really in a datastore at all.
>> It may have input and output parameters with leafref and must/when
>> statements.
>> These are evaluated in the  context.
>> The  may in fact be something like 
>> which has parameters (like  to apply to
>> a specific datastore.
>>
>> The action node is embedded within some data that has to be parsed
>> in a specific datastore before the action is processed.
>> This data is required to be in .
>> It also has XPath and leafref that needs to be resolved (same as ).
>>
>> The side effects of the  or  can impact other datastores.
>> This would be defined in the description-stmt and this is not a problem.
> This is exactly right.  We need to capture this in the text.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


--------------631D05CBC99CB4D47F6618AB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi,

    
Here is another attempt for proposed text for Actions/RPC
      statements in NMDA.

    
<new>

    

    
6.2 Invocation of RPC Operations
      

      
      

      This section updates section 7.14 of RFC 7950.
      

      
      

      RPCs MAY be defined as affecting the contents of a
        specific datastore,
      

      any configuration datastore (e.g., <edit-config>),
        or any datastore
      

      (e.g., <get-data>).  The RPC definition specifies
        how the RPC input
      

      data is interpreted by the server.
      

      
      

      RPCs definitions that do not explicitly state an affected
      

      datastore(s) modify the general operational state of the
        server.
      

      Hence, if any RPC input data relates to data node
        instances then
      

      those would generally resolve to data node instances in
        the
      

      <operational> data tree.
      

      
      

      
      

      6.3 Invocation of Actions
      

      
      

      This section updates section 7.15 of RFC 7950.
      

      
      

      In YANG data models, the "action" statement may appear
        under "config
      

      true" and "config false" schema nodes.  While instances
        of both
      

      schema nodes may appear in <operational>, instances
        of "config true"
      

      schema nodes may also appear in other datastores.
      

      
      

      Actions are always invoked on a data node instance that
        exist in the
      

      <operational> data tree.  The behavior defined by
        an action statement
      

      is generally expected to affect the operational state of
        the server
      

      rather than directly modifying the contents of any
        configuration
      

      datastore.
      

    </new>

    

    

    On a related note, I also want to confirm that it is right that RPC
    input data is always checked against operational:

    

    Section 6.1. of the NMDA draft states:

    

    
   o  If the XPath expression is defined in a substatement to an "input"
      statement in an "rpc" or "action" statement, the accessible tree
      is the RPC or action operation instance and all operational state
      in the server.  The root node has top-level data nodes in all
      modules as children.  Additionally, for an RPC, the root node also
      has the node representing the RPC operation being defined as a
      child.  The node representing the operation being defined has the
      operation's input parameters as children.

    

    

    Is <operational> always the right datastore to evaluate RPC
    input/output data relative to?  For most RPCs this seems to be the
    right choice by default but it also seems plausible that someone may
    wish to define an RPC that wants to validate its input parameters
    against the contents of another datastore.

    

    An example could be an "is-applied" RPC that takes a path to a
    subtree in <running> or <intended> and checks whether
    the configuration for that subtree is fully represented in
    <operational>.

    

    Thanks,

    Rob

    

    

    
On 27/10/2017 09:33, Martin Bjorklund
      wrote:

    

    

      
Andy Bierman <andy@yumaworks.com> wrote:


      

        
On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <
randy_presuhn@alumni.stanford.edu> wrote:



        

          
Hi -

On 10/26/2017 10:44 AM, Robert Wilton wrote:



          

            
Hi ,

Separating out the issue regarding which datastore action and RPC apply
to, we propose the following NEW text to the datastores draft:

6.2 Invocation of Actions and RPC Operations

   This section updates section 7.15. of RFC 7950.

   In YANG data models, the "action" statement may appear under "config
   true" and "config false" schema nodes.  While instances of both
   schema nodes may appear in <operational>, instances of "config true"
   schema nodes may also appear in other datastores.

   An NMDA compliant server MUST execute all actions in the context of
   <operational>.  Likewise, an NMDA compliant server MUST invoke all RPC
   operations in the context of <operational>, unless the RPC is
explicitly
   defined as affecting other datastores (e.g., <edit-config>).

OK?



          

          
A question - I understand the motivation for the "unless" for RPC
operations, but wonder why there is no similar "unless" for actions.




        

        
The <rpc> is not really in a datastore at all.
It may have input and output parameters with leafref and must/when
statements.
These are evaluated in the <operational> context.
The <rpc> may in fact be something like <edit-config>
which has parameters (like <config> to apply to
a specific datastore.

The action node is embedded within some data that has to be parsed
in a specific datastore before the action is processed.
This data is required to be in <operational>.
It also has XPath and leafref that needs to be resolved (same as <rpc>).

The side effects of the <rpc> or <action> can impact other datastores.
This would be defined in the description-stmt and this is not a problem.


      

      
This is exactly right.  We need to capture this in the text.


/martin

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



    

    

  


--------------631D05CBC99CB4D47F6618AB--


From nobody Tue Oct 31 08:03:11 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B8C13F761 for ; Tue, 31 Oct 2017 08:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 bC7NpjwqX7Lf for ; Tue, 31 Oct 2017 08:03:06 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0129.outbound.protection.outlook.com [104.47.42.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 CC79713F74C for ; Tue, 31 Oct 2017 08:02:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qXIaHHKEu13AIEEv4By54THYILQaTQ7Gw6DjWBvWTbk=; b=XGVzJgKiNEUnlgopkrbAfeM83ZH360xm8NANED8RMBYeGTDbswqmyfZ1gRF9JO+TUVxw3OBPcenPrR5JFOtIb6Bx7VBemc3lbp+1NYTfXX7B37U/A5wqL8fOBxKubwWEBcJH8NVprDXIP0ZW6zTzGSpPhaSKe7KxXlvOcIV9bgY=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Tue, 31 Oct 2017 15:02:16 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0197.011; Tue, 31 Oct 2017 15:02:16 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
Thread-Index: AQHTUlk9NGc0aqOQc0KFdQBpbe8s8g==
Date: Tue, 31 Oct 2017 15:02:16 +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
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:Z+tWNnbFTT7aztRJcny+3oTwXIhKrogIT2yTXUcG0esoWT2471dIQ+KwFIH6LjIsJ4K0MVa0OOnEo11L7flG/gMATm+ewRbfDo75jBPtWVWDnhDNlvvMNsdi4KEKu13UxwBIlCuhWT6ktxrpfsMSmXuaAuqQNsB9Q9PtrhRUuqA36xPmM9a9wyEEMnNN/2eYS79k0R2Q+mUQvYNEAN1/uWhgFyME5KJCZ/yEh1mBlfzstu4TzyR8m9VM9oaeOqgrQamZKogYLFPQg+wejoH89fjFuvmjl0v+yR+14i+X4sq3JpjAtIhILU0yfElNLgTsPf/q/OuEd5I5UsdEeZMwiimMiXVVb2NqcY4NbGlAm4c=; 5:2FY5gahtQ95W+n5SPVGzYvSUFxKs/efHMAzLA+7xColSIxDH56KF30BtCUAHMzH1spiQbhHho96FkNnCuImTvoByyjD2KOXnfZ2FqXuVdTVYNZGv/zhaM/mdV8IGFptyvsmecJ5pdjXIffBqajs6hVsF6pKy0xIorYd3qFDoz04=; 24:5YYjdmtbGeCLgngyGwShtpuVlfpXKg89kum/t9mMC1IeiHrVh0ebRkjAKkXBcxwJRW5Uyr74Lxy97YmIqK/2HKLCTCslF9rb1l/FDDQKIWk=; 7:0pPLT6yy4aZ2m1kRfn3FNTd++R+HdoikTPt3olrOx+qjIv68GdlG5UL0vqqpMzOJCdEBjD4BRJEFQZHu+ARz/Smpywd0QkwaXbA+RZr0XOkDnm/2y3T0do+scyBqrMHbTq/+As9/t+Tl9A16TEfQgz9tCYL0jmlY/7il1XNC7KO0UNYDaLdPyQCSZbXxoL+Q9gy/ifeSuRosBidtkmCSt2lmKLeIUCazDh+e/Li9BwQNwo05MS76LIC21NQOmxcM
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 868a2a5c-0750-4536-4818-08d520705ffa
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603199); SRVR:BLUPR05MB275; 
x-ms-traffictypediagnostic: BLUPR05MB275:
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231020)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB275; 
x-forefront-prvs: 04772EA191
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(199003)(189002)(6246003)(229853002)(6512007)(101416001)(5660300001)(102836003)(6116002)(6306002)(3846002)(6916009)(8936002)(68736007)(36756003)(2501003)(6436002)(305945005)(33656002)(97736004)(6506006)(5640700003)(189998001)(6486002)(83716003)(2900100001)(83506002)(2906002)(50986999)(2351001)(66066001)(14454004)(82746002)(7736002)(106356001)(230783001)(105586002)(1730700003)(25786009)(54356999)(3660700001)(478600001)(81166006)(81156014)(3280700002)(99286003)(575784001)(86362001)(58126008)(8676002)(966005)(53936002)(316002)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1DC56C2509324F43B35DB02679EC345B@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 868a2a5c-0750-4536-4818-08d520705ffa
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 15:02:16.0050 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 15:03:08 -0000

DQpUaGlzIHBvbGwgaXMgbm93IGNsb3NlZC4gIA0KDQpkcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIy
YmlzLTAzIGlzIGFkb3B0ZWQuDQoNCkF1dGhvcnMsIGFzIGRpc2N1c3NlZCBiZWxvdywgcGxlYXNl
IHJlc3VibWl0IGFjZWUtMDMgYXMgaWV0Zi0wMC4NClNpbmNlIHRoZSBzdWJtaXNzaW9uIHdpbmRv
dyBoYXMgY2xvc2VkLCB0aGUgY2hhaXJzIHdpbGwgYXNrIGZvcg0KYSBzdWJtaXNzaW9uLWV4Y2Vw
dGlvbi4gIFBsZWFzZSwgc2hvcnRseSBhZnRlciBzdWJtaXR0aW5nIHRoZQ0KLTAwLCBzdWJtaXQg
YSAtMDEgcGVyIGJlbG93IChlc3NlbnRpYWxseSwgeW91ciBhY2VlLTA1KSwgc28gdGhhdA0KdGhl
IGN1cnJlbnQgcHVibGlzaGVkIHZlcnNpb24gaXMgbW9zdCBhY2N1cmF0ZS4gIElmIG5lZWRlZCwg
dGhlDQpjaGFpcnMgd2lsbCBhZ2FpbiByZXF1ZXN0IGEgc3VibWlzc2lvbi1leGNlcHRpb24uDQoN
ClRoYW5rcywNCktlbnQgLy8gY28tY2hhaXINCg0KDQotLQ0KDQpBbGwsDQoNCk5vdyB0aGF0IHdl
IGhhdmUgcmVzb2x2ZWQgdGhlIG1vZHVsZSBuYW1pbmcgaXNzdWUgb24gdGhlIGxpc3QgKGkuZS4g
DQp0aGF0IGtlZXBzIHRoZSBvcmlnaW5hbCByZmMgbW9kdWxlIG5hbWVzIGFuZCB1cGRhdGVzIHRo
ZSB1bndhbnRlZA0KbGVnYWN5IG5vZGVzIHRvIGhhdmUgc3RhdHVzICdvYnNvbGV0ZScpLCByYXRo
ZXIgdGhhbiB3YWl0IGZvciB0aGUNCmNoYW5nZXMgdG8gYmUgbWFkZSBpbiB0aGUgaW5kaXZpZHVh
bCBkb2N1bWVudCwgd2UnZCBsaWtlIHRvIG1vdmUNCmFoZWFkIHdpdGggdGhlIGFkb3B0aW9uIG5v
dywgd2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0IHRoZXNlIA0KY2hhbmdlcyB3aWxsIGJlIG1h
ZGUgaW4gdGhlIC0wMSB2ZXJzaW9uIG9mIHRoZSBhZG9wdGVkIGRyYWZ0Lg0KDQpUaGlzIGlzIHN0
YXJ0IG9mIGEgdHdvLXdlZWsgcG9sbCBvbiBtYWtpbmcgZHJhZnQtYWNlZS1uZXRtb2QtcmZjODAy
MmJpcy0wMw0KYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiAgUGxlYXNlIHNlbmQgZW1haWwgdG8g
dGhlIGxpc3QgaW5kaWNhdGluZyANCiJ5ZXMvc3VwcG9ydCIgb3IgIm5vL2RvIG5vdCBzdXBwb3J0
Ii4gIElmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZQ0KeW91ciByZXNlcnZhdGlvbnMgd2l0
aCB0aGUgZG9jdW1lbnQuICBJZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0bw0KcHJvdmlk
ZSBjb21tZW50cyB5b3UnZCBsaWtlIHRvIHNlZSBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQg
aXMgYSBXRw0KZG9jdW1lbnQuDQoNClRoZSBwb2xsIGVuZHMgT2N0IDI3Lg0KDQpUaGFua3MsDQpL
ZW50IChhbmQgTG91KQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t
YWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpC
WGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZq
SVNsYUpkY1pvJm09R25ZZ0pFaUFFMkQtRVdtMWNjVXotX3V1eWM4ZldMSWxjalpCdnZCM0lkYyZz
PWM5ZTQzanhwNG11eXRkdFVYZlg5UU9KU1lSdDJRT0R3ZU1mUEs0ZHNpbEEmZT0NCg0KDQo=


From nobody Tue Oct 31 08:20:17 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E5613F7EF for ; Tue, 31 Oct 2017 08:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnruYyI9tfjo for ; Tue, 31 Oct 2017 08:20:13 -0700 (PDT)
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 F3A0213F866 for ; Tue, 31 Oct 2017 08:15:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C10BF731; Tue, 31 Oct 2017 16:15: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 INLmIEdQGPDK; Tue, 31 Oct 2017 16:15: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; Tue, 31 Oct 2017 16:15:42 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E09420111; Tue, 31 Oct 2017 16:15:42 +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 vq_ysT21l55k; Tue, 31 Oct 2017 16:15:42 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6A0220110; Tue, 31 Oct 2017 16:15:41 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id DB6804145B17; Tue, 31 Oct 2017 16:14:15 +0100 (CET)
Date: Tue, 31 Oct 2017 16:14:15 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org, Randy Presuhn 
Message-ID: <20171031151415.o45uexttym2eqp6n@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org, Randy Presuhn 
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@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: <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 15:20:16 -0000

On Tue, Oct 31, 2017 at 02:14:20PM +0000, Robert Wilton wrote:

> Is  always the right datastore to evaluate RPC input/output
> data relative to?  For most RPCs this seems to be the right choice by
> default but it also seems plausible that someone may wish to define an RPC
> that wants to validate its input parameters against the contents of another
> datastore.

Yes.
 
> An example could be an "is-applied" RPC that takes a path to a subtree in
>  or  and checks whether the configuration for that
> subtree is fully represented in .

How is this different from say partial locks (RFC 5717)? Note that in
your example, you carry an xpath value as part of the RPC invocation
to the server and the RPC code on the server then is interpreting the
xpath value; this is not the same has having an xpath expression in
the definition of the RPC itself (e.g., as part of a constraint).

I believe we previously concluded that xpath expressions that are part
of the schema definition of an RPC / action are evaluated against
. I think this is a reasonable interpretation and we
can't affort a vaguely defined xpath context here.

/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 Oct 31 08:41:14 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E735313F8F1 for ; Tue, 31 Oct 2017 08:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 Ch3RVLExg3B9 for ; Tue, 31 Oct 2017 08:41:06 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0112.outbound.protection.outlook.com [104.47.38.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C536E13F88C for ; Tue, 31 Oct 2017 08:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hvJ8Ck2e+RJcVz1HfJ16CoAdPp77WoEzrUESLi++640=; b=OJeKC8hhIw98ioIdBBMW3fPjioIXnn4jNxzE+ATLD7SvxJj9Fo1YAi/3SS3TjtCw62MCaHmn3YvsC1s/s5cMjb/yVZ6wUcATVuY2nJfUWsHbEPCvgLs9b1PsODoGRq2OjfTEZPUCkn+LIBsXRbWp2sM68OLLasmcfzDNbigXJTY=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Tue, 31 Oct 2017 15:35:38 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0197.011; Tue, 31 Oct 2017 15:35:38 +0000
From: Kent Watsen 
To: Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn 
Thread-Topic: [netmod] Action and RPC statements
Thread-Index: AQHTTv5T3zX4hwBy8UGdfgw5IpFaUKL+BxkA///TqQA=
Date: Tue, 31 Oct 2017 15:35:38 +0000
Message-ID: 
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com>
In-Reply-To: <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:zH0xWR7AHyu65Mi+G9mdi5mA06enod9SADjsmuxFrDDCFhXtQrdDqd5w4AOhwVb/9u8g1Cd1yTnXNBD+ofiWV1pM6AG5y0hPi4pn5jFtGb7pla8qqoVyChcoNsm6+0tocr3mnU9LNKQU8DvkzJ76J9p0ix8FaQglGTRkluAfL3TCW6KVBzjy6xUFnwiK3BLOX2ayRcx0lLlN/J0fTS93PcPZw3d4m4RWy7Tp9/CbAk+ulcMy77N+9Uto3M2lxLyMBMkLMfYmFSvwr3aoqH0rvez/mxiq16jFag7LaIIyqodifAilPdh9kTYrKmJhFrEg+dr1YpaBSONzYQ8jg/btO+7RUILIEPDVrALx/bg4tJE=; 5:ejbtXHTyiC5+vZU8rQXB06ktgxQy9m2mtbg40NoOAy9JaQzQPGOIKJymR6RhX4bCyo61qfElhOmjaJwtBOv24tHCBaKl2+JcNUf39L8PagcL3NI9xFhSszT9ETsdWGB9NU5zjULK90xNd7fyylNFFIFLLZD98A2Y/9RNOGs9l6Y=; 24:ERNDXlYoUH9BwOKorbVxJ8nKl/xxEgtouXNLT91zOS2DVlmEA7VnOyGPOsl80tWk7u1dS9KSyCPmlTRDIqLBFA+MtEvVS8CC+xPhbs2lZX8=; 7:hdpBvAdd/sSZdgxD2YexlJnWF+B2UEf1ojoBXgSM0dylAo6qi+c2R7mXIo66VcP2zPApHTAEEA0M+vXh3bjpZEOlZIwRsi9mUT0VOLpq3C6WmSlAwA30Erdk6ikV4FnhRf/f+LcsM04VFqhxmoeWT7QJH/K0E40v63R42k3tOoEcEdmhOD3MbUXwboJZ6WGJ9mOAnQWyqyAHxonG8TkfHoYS12PdriTzPSZqs3Tp3C5I4Iph27nA0ZHSeTdMm4up
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: c5ddfb0e-74aa-4fb3-c468-08d52075098e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603199); SRVR:BLUPR05MB275; 
x-ms-traffictypediagnostic: BLUPR05MB275:
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231020)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB275; 
x-forefront-prvs: 04772EA191
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(199003)(76104003)(189002)(7736002)(106356001)(110136005)(105586002)(50986999)(2906002)(83506002)(82746002)(66066001)(14454004)(93886005)(8676002)(86362001)(58126008)(316002)(77096006)(53936002)(3280700002)(54356999)(3660700001)(76176999)(25786009)(99286003)(81166006)(2171002)(478600001)(81156014)(6116002)(3846002)(102836003)(5660300001)(8936002)(2950100002)(229853002)(6512007)(6246003)(101416001)(189998001)(6506006)(97736004)(6486002)(2900100001)(83716003)(6436002)(68736007)(2501003)(36756003)(305945005)(33656002)(2201001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB275; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: c5ddfb0e-74aa-4fb3-c468-08d52075098e
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2017 15:35:38.5000 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 15:41:13 -0000

DQpIaSBSb2JlcnQsDQoNCj4gNi4yIEludm9jYXRpb24gb2YgUlBDIE9wZXJhdGlvbnMgDQo+DQo+
IFRoaXMgc2VjdGlvbiB1cGRhdGVzIHNlY3Rpb24gNy4xNCBvZiBSRkMgNzk1MC4gDQo+IA0KPiBS
UENzIE1BWSBiZSBkZWZpbmVkIGFzIGFmZmVjdGluZyB0aGUgY29udGVudHMgb2YgYSBzcGVjaWZp
YyBkYXRhc3RvcmUsIA0KPiBhbnkgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgKGUuZy4sIDxlZGl0
LWNvbmZpZz4pLCBvciBhbnkgZGF0YXN0b3JlIA0KPiAoZS5nLiwgPGdldC1kYXRhPikuwqAgVGhl
IFJQQyBkZWZpbml0aW9uIHNwZWNpZmllcyBob3cgdGhlIFJQQyBpbnB1dCANCj4gZGF0YSBpcyBp
bnRlcnByZXRlZCBieSB0aGUgc2VydmVyLiANCg0Kcy9NQVkvbWF5Lz8gLSBpcyB0aGlzIGRyYWZ0
IHByb3ZpZGluZyBmb3IgdGhpcywgb3Igc2hvdWxkIGl0IGNvbWUgZnJvbQ0KZS5nLiwgUkZDIDc5
NTA/DQoNCg0KPiBSUENzIGRlZmluaXRpb25zIHRoYXQgZG8gbm90IGV4cGxpY2l0bHkgc3RhdGUg
YW4gYWZmZWN0ZWQgDQo+IGRhdGFzdG9yZShzKSBtb2RpZnkgdGhlIGdlbmVyYWwgb3BlcmF0aW9u
YWwgc3RhdGUgb2YgdGhlIHNlcnZlci4gDQo+IEhlbmNlLCBpZiBhbnkgUlBDIGlucHV0IGRhdGEg
cmVsYXRlcyB0byBkYXRhIG5vZGUgaW5zdGFuY2VzIHRoZW4gDQo+IHRob3NlIHdvdWxkIGdlbmVy
YWxseSByZXNvbHZlIHRvIGRhdGEgbm9kZSBpbnN0YW5jZXMgaW4gdGhlIA0KPiA8b3BlcmF0aW9u
YWw+IGRhdGEgdHJlZS4gDQoNCkkgcmVvcmRlcmVkIGZpcnN0IHNlbnRlbmNlLCBhbmQgYWRkZWQg
YSBjb21tYSB0byB0aGUgc2Vjb25kOg0KDQpSUENzIG1vZGlmeSB0aGUgZ2VuZXJhbCBvcGVyYXRp
b25hbCBzdGF0ZSBvZiB0aGUgc2VydmVyLCB1bmxlc3MNCmV4cGxpY2l0bHkgZGVmaW5lZCB0byBh
ZmZlY3Qgb3RoZXIgZGF0YXN0b3Jlcy4gSGVuY2UsIGlmIGFueSBSUEMNCmlucHV0IGRhdGEgcmVs
YXRlcyB0byBkYXRhIG5vZGUgaW5zdGFuY2VzLCB0aGVuIHRob3NlIHdvdWxkDQpnZW5lcmFsbHkg
cmVzb2x2ZSB0byBkYXRhIG5vZGUgaW5zdGFuY2VzIGluIHRoZSA8b3BlcmF0aW9uYWw+DQpkYXRh
IHRyZWUuIA0KDQoNCj4gNi4zIEludm9jYXRpb24gb2YgQWN0aW9ucyANCj4gDQo+IFRoaXMgc2Vj
dGlvbiB1cGRhdGVzIHNlY3Rpb24gNy4xNSBvZiBSRkMgNzk1MC4gDQo+DQo+IEluIFlBTkcgZGF0
YSBtb2RlbHMsIHRoZSAiYWN0aW9uIiBzdGF0ZW1lbnQgbWF5IGFwcGVhciB1bmRlciAiY29uZmln
IA0KPiB0cnVlIiBhbmQgImNvbmZpZyBmYWxzZSIgc2NoZW1hIG5vZGVzLsKgIFdoaWxlIGluc3Rh
bmNlcyBvZiBib3RoIA0KPiBzY2hlbWEgbm9kZXMgbWF5IGFwcGVhciBpbiA8b3BlcmF0aW9uYWw+
LCBpbnN0YW5jZXMgb2YgImNvbmZpZyB0cnVlIiANCj4gc2NoZW1hIG5vZGVzIG1heSBhbHNvIGFw
cGVhciBpbiBvdGhlciBkYXRhc3RvcmVzLiANCg0Kb2theQ0KDQo+IEFjdGlvbnMgYXJlIGFsd2F5
cyBpbnZva2VkIG9uIGEgZGF0YSBub2RlIGluc3RhbmNlIHRoYXQgZXhpc3QgaW4gdGhlIA0KPiA8
b3BlcmF0aW9uYWw+IGRhdGEgdHJlZS7CoCBUaGUgYmVoYXZpb3IgZGVmaW5lZCBieSBhbiBhY3Rp
b24gc3RhdGVtZW50IA0KPiBpcyBnZW5lcmFsbHkgZXhwZWN0ZWQgdG8gYWZmZWN0IHRoZSBvcGVy
YXRpb25hbCBzdGF0ZSBvZiB0aGUgc2VydmVyIA0KPiByYXRoZXIgdGhhbiBkaXJlY3RseSBtb2Rp
ZnlpbmcgdGhlIGNvbnRlbnRzIG9mIGFueSBjb25maWd1cmF0aW9uIA0KPiBkYXRhc3RvcmUuIA0K
DQpmaXhlZCBwbHVyYWxpdHkgaXNzdWUgaW4gZmlyc3Qgc2VudGVuY2UsIGFuZCByZW1vdmVkIHdp
c2h5LXdhc2h5IA0KbGFuZ3VhZ2UgZnJvbSB0aGUgcmVzdDoNCg0KQWN0aW9ucyBhcmUgYWx3YXlz
IGludm9rZWQgb24gYSBkYXRhIG5vZGUgaW5zdGFuY2UgdGhhdCBleGlzdHMgaW4gdGhlIA0KPG9w
ZXJhdGlvbmFsPiBkYXRhIHRyZWUuICBBY3Rpb24gc3RhdGVtZW50cyBhZmZlY3QgdGhlIG9wZXJh
dGlvbmFsDQpzdGF0ZSBvZiB0aGUgc2VydmVyLg0KDQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpL
ZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KDQoNCg==


From nobody Tue Oct 31 08:57:19 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED12B13F88C for ; Tue, 31 Oct 2017 08:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQHrizwpZsxO for ; Tue, 31 Oct 2017 08:57:07 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CEA13F82C for ; Tue, 31 Oct 2017 08:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2897; q=dns/txt; s=iport; t=1509465414; x=1510675014; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TOwz1q+MSnZWbRprNwUKTP+63q9lItDP6fdO7H6nhxc=; b=enLECYGISchXhyCP5CUjyXtRmjAniO24QCpfdSgoHrdjI0GaryTWIYz/ jgGwqNWTfIGGTTdL1PxPewgef8fNx33YNUO/Qmzy+nOQnKr2YawM9S86Q ow4m+N6MXX7yj5Of5jD2Ho8D4gWNZgVS/34zK15+DqKBghQArNiDHTN3l Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAACcmPhZ/xbLJq1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUxhCOKH3SQH5ZCEIIBCoU7AoUwGAECAQEBAQEBAWsohR0BAQE?= =?us-ascii?q?DASMPAQVRCw4KAgImAgJXBgEMCAEBihcIqF6CJ4QVAYZ6AQEBAQEBAQMBAQEBA?= =?us-ascii?q?QEigQ+CH4NaghKDAYR5AoMrgmEFogaUfIt0hzqOJodsgTkfOIFrNCEIHRWDLoQ?= =?us-ascii?q?fBAE6QYwMAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,324,1505779200"; d="scan'208";a="698351204"
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; 31 Oct 2017 15:56:52 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9VFuqOQ006037; Tue, 31 Oct 2017 15:56:52 GMT
To: Kent Watsen , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn 
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Tue, 31 Oct 2017 15:56:51 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 15:57:18 -0000

On 31/10/2017 15:35, Kent Watsen wrote:
> Hi Robert,
>
>> 6.2 Invocation of RPC Operations
>>
>> This section updates section 7.14 of RFC 7950.
>>
>> RPCs MAY be defined as affecting the contents of a specific datastore,
>> any configuration datastore (e.g., ), or any datastore
>> (e.g., ).  The RPC definition specifies how the RPC input
>> data is interpreted by the server.
> s/MAY/may/? - is this draft providing for this, or should it come from
> e.g., RFC 7950?
I think that I prefer MAY because we are stating what RPCs are allowed 
to do, but don't feel strongly on this ...

>
>> RPCs definitions that do not explicitly state an affected
>> datastore(s) modify the general operational state of the server.
>> Hence, if any RPC input data relates to data node instances then
>> those would generally resolve to data node instances in the
>>  data tree.
> I reordered first sentence, and added a comma to the second:
>
> RPCs modify the general operational state of the server, unless
> explicitly defined to affect other datastores. Hence, if any RPC
> input data relates to data node instances, then those would
> generally resolve to data node instances in the 
> data tree.
Also OK with me.


>
>
>> 6.3 Invocation of Actions
>>
>> This section updates section 7.15 of RFC 7950.
>>
>> In YANG data models, the "action" statement may appear under "config
>> true" and "config false" schema nodes.  While instances of both
>> schema nodes may appear in , instances of "config true"
>> schema nodes may also appear in other datastores.
> okay
>
>> Actions are always invoked on a data node instance that exist in the
>>  data tree.  The behavior defined by an action statement
>> is generally expected to affect the operational state of the server
>> rather than directly modifying the contents of any configuration
>> datastore.
> fixed plurality issue in first sentence, and removed wishy-washy
> language from the rest:
>
> Actions are always invoked on a data node instance that exists in the
>  data tree.  Action statements affect the operational
> state of the server.
This wishy-washy language is the tricky bit:

i) Actions are allowed to have any operational impact on the device 
(just as RPCs are), their behavior is not constrained in any way.

ii) However, as far as I can see, it doesn't make sense for an action to 
directly affect the contents of any configuration datastore, that should 
be done via a purpose built rpc (like edit-config).

My text was aimed to allow (i) but not encourage (ii)  ...  If your text 
is sufficient for this then it is fine with me - I agree that it is 
simpler, and simpler is preferable.

Thanks,
Rob


>
>
> What do you think?
>
> Kent // contributor
>
>
>
>


From nobody Tue Oct 31 09:51:29 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6859313F9B0 for ; Tue, 31 Oct 2017 09:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEEmIdxkWNGM for ; Tue, 31 Oct 2017 09:51:26 -0700 (PDT)
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 44C4913F989 for ; Tue, 31 Oct 2017 09:51:26 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D6215F6B; Tue, 31 Oct 2017 17:51:24 +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 k8_lVaU-YIGt; Tue, 31 Oct 2017 17:51:21 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 Oct 2017 17:51:24 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A080420111; Tue, 31 Oct 2017 17:51:24 +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 8k71_DQEnx00; Tue, 31 Oct 2017 17:51:24 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEA3720110; Tue, 31 Oct 2017 17:51:23 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id A28B14145C38; Tue, 31 Oct 2017 17:49:56 +0100 (CET)
Date: Tue, 31 Oct 2017 17:49:56 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Cc: Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn 
Message-ID: <20171031164956.6arcgbefiwj7dhyt@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn 
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@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: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 16:51:28 -0000

On Tue, Oct 31, 2017 at 03:35:38PM +0000, Kent Watsen wrote:
> 
> Hi Robert,
> 
> > 6.2 Invocation of RPC Operations 
> >
> > This section updates section 7.14 of RFC 7950. 
> > 
> > RPCs MAY be defined as affecting the contents of a specific datastore, 
> > any configuration datastore (e.g., ), or any datastore 
> > (e.g., ).  The RPC definition specifies how the RPC input 
> > data is interpreted by the server. 
> 
> s/MAY/may/? - is this draft providing for this, or should it come from
> e.g., RFC 7950?
> 
> 
> > RPCs definitions that do not explicitly state an affected 
> > datastore(s) modify the general operational state of the server. 
> > Hence, if any RPC input data relates to data node instances then 
> > those would generally resolve to data node instances in the 
> >  data tree. 
> 
> I reordered first sentence, and added a comma to the second:
> 
> RPCs modify the general operational state of the server, unless
> explicitly defined to affect other datastores. Hence, if any RPC
> input data relates to data node instances, then those would
> generally resolve to data node instances in the 
> data tree. 

- s/the general operational state/the operational state/
- I also do not think that RPC generally modify state.

Or simply:

  References to data nodes in RPC description statements etc. are
  interpreted as references to data nodes in  unless
  specified otherwise.
 
> > 6.3 Invocation of Actions 
> > 
> > This section updates section 7.15 of RFC 7950. 
> >
> > In YANG data models, the "action" statement may appear under "config 
> > true" and "config false" schema nodes.  While instances of both 
> > schema nodes may appear in , instances of "config true" 
> > schema nodes may also appear in other datastores. 
> 
> okay
> 
> > Actions are always invoked on a data node instance that exist in the 
> >  data tree.  The behavior defined by an action statement 
> > is generally expected to affect the operational state of the server 
> > rather than directly modifying the contents of any configuration 
> > datastore. 
> 
> fixed plurality issue in first sentence, and removed wishy-washy 
> language from the rest:
> 
> Actions are always invoked on a data node instance that exists in the 
>  data tree.  Action statements affect the operational
> state of the server.

OR:

  References to data nodes in action description statements etc. are
  interpreted as references to data nodes in  unless
  specified otherwise.

I think that the data node an action is bound to must exist in
operational state - this is consistent with the xpath context. But
what the other parameters mean is a matter of the action/RPC
semantics, as defined in the description statement. Or is there a
_technical_ reason to restrict 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 Tue Oct 31 10:13:04 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9416013F9E3 for ; Tue, 31 Oct 2017 10:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE6Qk--SOW9S for ; Tue, 31 Oct 2017 10:13:00 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF8E13F9E5 for ; Tue, 31 Oct 2017 10:12:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2013; q=dns/txt; s=iport; t=1509469979; x=1510679579; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=fd8rDaDMYeSnD1vTZ0E5B7z1RsK9F5rv18+2w6qgKRI=; b=dRPuPBAUNMk2OhG4OJUai+oXM+7A6VqlxpqXbfPhxH7AZ0LBkHOEHD/n EEBlZ2AFbVs0HLVrmmPvxRc0n2SkNI6Fe1leA8CvBog6eoZz4ZTjAPTBS 4YgNiLid2feof0+RiWC3KQ5GWnAcTBP0JssUUTZwf8zForZi01zgLYUQK A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQDirfhZ/xbLJq1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUxhCOLE5AdlkKCEQqFOwKFNBYBAgEBAQEBAQFrKIUdAQEBAwE?= =?us-ascii?q?jDwEFUQsOCgICJgICVwYBDAgBAYoXCKhogieLDQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR2BD4Ifg1qBaSmDAYR7gyuCYQWiBpR8i3SHOo4mh2yBOSYHKoFrNCEIHRW?= =?us-ascii?q?DLoJbHIEoP0GJSiyCFgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,324,1505779200"; d="scan'208";a="698352356"
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; 31 Oct 2017 17:12:57 +0000
Received: from [10.63.23.63] (dhcp-ensft1-uk-vla370-10-63-23-63.cisco.com [10.63.23.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9VHCv7c021791; Tue, 31 Oct 2017 17:12:57 GMT
To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org, Randy Presuhn 
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com> <20171031151415.o45uexttym2eqp6n@elstar.local>
From: Robert Wilton 
Message-ID: <010e52e2-689f-40a3-aa90-15cc23f0bc7e@cisco.com>
Date: Tue, 31 Oct 2017 17:12:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171031151415.o45uexttym2eqp6n@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 17:13:03 -0000

On 31/10/2017 15:14, Juergen Schoenwaelder wrote:
> On Tue, Oct 31, 2017 at 02:14:20PM +0000, Robert Wilton wrote:
>
>> Is  always the right datastore to evaluate RPC input/output
>> data relative to?  For most RPCs this seems to be the right choice by
>> default but it also seems plausible that someone may wish to define an RPC
>> that wants to validate its input parameters against the contents of another
>> datastore.
> Yes.
>   
>> An example could be an "is-applied" RPC that takes a path to a subtree in
>>  or  and checks whether the configuration for that
>> subtree is fully represented in .
> How is this different from say partial locks (RFC 5717)? Note that in
> your example, you carry an xpath value as part of the RPC invocation
> to the server and the RPC code on the server then is interpreting the
> xpath value; this is not the same has having an xpath expression in
> the definition of the RPC itself (e.g., as part of a constraint).
OK, thanks for the explanation, I get the distinction.

But what about if the input parameter was an instance-identifier (that 
you want to be resolved against the configuration datastore)? Wouldn't 
RFC 7950 section 9.13 + NMDA Sec 6.1 force that leaf in the input data 
to be resolved against  instead?

>
> I believe we previously concluded that xpath expressions that are part
> of the schema definition of an RPC / action are evaluated against
> . I think this is a reasonable interpretation and we
> can't affort a vaguely defined xpath context here.
I don't think that it would necessarily be vaguely defined, instead it 
would be the description that defines the XPath context to use, 
defaulting to operational if not specified otherwise.

However, having said that, I can't think of a realistic example of when 
a must/when statement for an RPC against a configuration datastore would 
be useful ...

Thanks,
Rob


>
> /js
>


From nobody Tue Oct 31 10:14:27 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A5B13F9D9 for ; Tue, 31 Oct 2017 10:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ux3yuJw7Ahc for ; Tue, 31 Oct 2017 10:14:22 -0700 (PDT)
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 F3E2F13F9A1 for ; Tue, 31 Oct 2017 10:14:21 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id 90so19880678lfs.13 for ; Tue, 31 Oct 2017 10:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=isBwoB2AU25wY51Kp9NMiGKhJybdgbtUg3cMjKR3cmY=; b=ftu3llFEGpOyHLzK04VheGNJ2rh0SONl7XeLL0NMH3aoo6jbkCs5ny8cze08FTC1PL 13l/noITeSlzZ3gOPOfz/br/3bJvKqekhZ9djshdL5GLctzhPg5fVvev7ZimIJWvtAOU 6Xuno4Zl1R2VADuGRi33Ww1Sq9FS7hv3tmo5d88RUMjvrtypPRNwwJ8mLTunNjmjlWZo 7orkaGqvK6TWpjL2ZcFPZPXZBw7RlCbHv2vlg/Vp5se2PzaXXvxe0AlGA6s4DxdwGlQT yi3fu5BnA/vwRwXWvoVKH0ac+iiYoIKhp5uIfjSczbqwUpHe7zoyFuT5Gminj+YsqRpA jXzQ==
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=isBwoB2AU25wY51Kp9NMiGKhJybdgbtUg3cMjKR3cmY=; b=c5VGtGUtUCC0n3cZWA4h+K2n8NqdYP0ozK+V50OdNFhY1CAMipA+KDhCMEfJabcIbn MFv6XpQX6rDrg3pOkghlpsTJfNc1jUYxQ7vHSpCLbjASK+q+2VXX8J6s828b03Hg2N3m gkD+Hk66qiSuKRCAKmlwEZz4cSAlhnFm4a/5bxmtKsSuI4zCOXRSS+CpzgD4IUJyfTYU pbe5CSYouIhYHH6iOb+5srVCUSeAXp4UdHaCZx2pgj00Ug5wYQu4Fq9XEj37xDyrUw+8 5lujL4c+1mHZvNidASx2umczpn4V16H3qAnMwcyKgS8fAt0smgRYmjDx3snkFujVBkkJ Mkug==
X-Gm-Message-State: AMCzsaVpuSYdgHrgg2hMPzO1Ydk6rFiCELp/7TFMLnpa3RU+07au0u6b zqpkxKYfvkq/tSratVG80dmAaS3d1Nl4XuopsvSDGA==
X-Google-Smtp-Source: ABhQp+QnGjud7DCHj8wxUzRcMNEg0q+paFlCoOaTS05KiczQ4i1NXjkNTNdmELHa5GYdwDYWcv52apZmoksA8TYFxiQ=
X-Received: by 10.25.22.194 with SMTP id 63mr1038973lfw.205.1509470060080; Tue, 31 Oct 2017 10:14:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Tue, 31 Oct 2017 10:14:19 -0700 (PDT)
In-Reply-To: <20171027.103341.1048835221774842137.mbj@tail-f.com>
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com>
From: Andy Bierman 
Date: Tue, 31 Oct 2017 10:14:19 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Randy Presuhn , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f2092bb10e6055cdae2e8"
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 17:14:25 -0000

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

On Fri, Oct 27, 2017 at 1:33 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <
> > randy_presuhn@alumni.stanford.edu> wrote:
> >
> ....
> >
> > The  is not really in a datastore at all.
> > It may have input and output parameters with leafref and must/when
> > statements.
> > These are evaluated in the  context.
> > The  may in fact be something like 
> > which has parameters (like  to apply to
> > a specific datastore.
> >
> > The action node is embedded within some data that has to be parsed
> > in a specific datastore before the action is processed.
> > This data is required to be in .
> > It also has XPath and leafref that needs to be resolved (same as ).
> >
> > The side effects of the  or  can impact other datastores.
> > This would be defined in the description-stmt and this is not a problem.
>
> This is exactly right.  We need to capture this in the text.
>
>
I don't think the new text is very clear.
The system side effects are irrelevant, but both the same for rpc and
action.

The only issues relevant to YANG are:
   - datastore used to evaluate action ancestor nodes
   - datastore used to evaluate input parameter leafref, must, when
   - datastore used to evaluate output parameter leafref, must, when


These properties cannot be modified by description-stmt.
Not now, not ever. Not for rpc. Not for action.

It is irrelevant to NMDA whether the rpc or action modifies a datastore,
starts a playlist on a jukebox, or makes some toast.



> /martin
>

Andy

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




On Fri, Oct 27, 2017 at 1:33 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Andy Bi=
erman <andy@yumaworks.com> =
wrote:

> On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <

> randy_presuhn@alu=
mni.stanford.edu> wrote:

>
....

>

> The <rpc> is not really in a datastore at all.

> It may have input and output parameters with leafref and must/when

> statements.

> These are evaluated in the <operational> context.

> The <rpc> may in fact be something like <edit-config>

> which has parameters (like <config> to apply to

> a specific datastore.

>

> The action node is embedded within some data that has to be parsed

> in a specific datastore before the action is processed.

> This data is required to be in <operational>.

> It also has XPath and leafref that needs to be resolved (same as <r=
pc>).

>

> The side effects of the <rpc> or <action> can impact other=
 datastores.

> This would be defined in the description-stmt and this is not a proble=
m.



This is exactly right.=C2=A0 We need to capture this in the text.



I don't think the new text is very clear.<=
/div>
The system side effects are irrelevant, but both the same for rpc=
 and action.

The only issues relevant to YANG are:=

=C2=A0 =C2=A0- datastore used to evaluate action ancestor nodes<=
/div>
=C2=A0 =C2=A0- datastore used to evaluate input parameter leafref=
, must, when=C2=A0
=C2=A0 =C2=A0- datastore used to evaluate outp=
ut parameter leafref, must, when=C2=A0


These properties cannot be modified by description-stmt.
=
Not now, not ever. Not for rpc. Not for action.

It=
 is irrelevant to NMDA whether the rpc or action modifies a datastore,
starts a playlist on a jukebox, or makes some toast.





/martin



Andy<=
/div>



--001a113f2092bb10e6055cdae2e8--


From nobody Tue Oct 31 10:22:52 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC9D13F9FE for ; Tue, 31 Oct 2017 10:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.18
X-Spam-Level: 
X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93Ifxr3iuqh5 for ; Tue, 31 Oct 2017 10:22:49 -0700 (PDT)
Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) (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 1E5D113F9F3 for ; Tue, 31 Oct 2017 10:22:49 -0700 (PDT)
Received: by mail-pf0-f181.google.com with SMTP id n89so14270948pfk.11 for ; Tue, 31 Oct 2017 10:22:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+68nnJ8T8r9Fu2UtikMVHj7yS6DPv4og8z8J5oBovEs=; b=ZTlBN8THJLmCDLwYtdlOmEX+so8XCVyiB/c6vT4/baJnoa60zgf/gI5BlJ4HxR/NWZ Et3ieX/3IbMmtGSkVhmBH2g6Fc283D/gujYszMKTIGTkEsPMyZmVNGEluhf6Tp7rpaCl QTH6NyZfilqcWQF59hQyGy8FYEYnQoZ3H6euzRCL64K45HAcB/EnHP8OnA/6D1mGmZdJ K3IVBjthiTzP0y0ygWRaV7FHBgkRyFJVXMNN5gxVei9TbLoHEY557wWF7hhffKht9ESB BNep5MRRVnMcVNE4PlQAtAyzdtsNJsW4VAwyb1zPESs5/VnOHFSA3+0JM8Y/Xu9rCq+L 5tLA==
X-Gm-Message-State: AMCzsaVOOeIOAgEhRD1cV8U3HYb1aF+ccB2/NAKVSmZhndZsku1elh1x mIRnZvzLjQ8pNyTthbZX2nMFI1qSjdE=
X-Google-Smtp-Source: ABhQp+SdsLXtoxfMO4fRhM7XIbSigdR8LENKYQ08K29li0THx2ecGBoqjDnDG43KpnZY98Qpm9dwEQ==
X-Received: by 10.99.163.97 with SMTP id v33mr2435218pgn.206.1509470568242; Tue, 31 Oct 2017 10:22:48 -0700 (PDT)
Received: from [192.168.1.102] (c-24-130-218-233.hsd1.ca.comcast.net. [24.130.218.233]) by smtp.gmail.com with ESMTPSA id o9sm4840356pfk.162.2017.10.31.10.22.46 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 10:22:47 -0700 (PDT)
Cc: "netmod@ietf.org" 
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com> 
From: Randy Presuhn 
Message-ID: <21b5f7ec-936d-c729-1ada-fdb757e1ccd4@alumni.stanford.edu>
Date: Tue, 31 Oct 2017 10:22:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; 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: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 17:22:50 -0000

Hi -

On 10/31/2017 10:14 AM, Andy Bierman wrote:
...
> The system side effects are irrelevant, but both the same for rpc and 
> action.

Knowing what the system side effects are is *ESSENTIAL* if these
things are to be of any use operationally.

> The only issues relevant to YANG are:
>     - datastore used to evaluate action ancestor nodes
>     - datastore used to evaluate input parameter leafref, must, when
>     - datastore used to evaluate output parameter leafref, must, when
> 
> 
> These properties cannot be modified by description-stmt.
> Not now, not ever. Not for rpc. Not for action.
> 
> It is irrelevant to NMDA whether the rpc or action modifies a datastore,
> starts a playlist on a jukebox, or makes some toast.

But from the an operational or interoperabilty perspective,
that information is crucial.

Randy


From nobody Tue Oct 31 10:31:46 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B02013FA08 for ; Tue, 31 Oct 2017 10:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt-JaQsh3XPJ for ; Tue, 31 Oct 2017 10:31:42 -0700 (PDT)
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 2AC1013F9F3 for ; Tue, 31 Oct 2017 10:31:42 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id e143so7852640lfg.12 for ; Tue, 31 Oct 2017 10:31:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KM/vGVRsKGftPVS1UedoMkqyjvjpRi47dQNNzouFnr8=; b=TcdeKBdhciOkyESTxm+tHkA6I9XBIIiQLEbLfloBWcXjD43kFmY8j6x2FHRAUzbFTA jPyK1JxB/vP+RDJtuemwLj3OjyB1ZuyS0ea9TzhZJCyz00eYuCrCWrsnmS7Nj1QTRSW9 OM8yK95HVLQoUhTfs21JCvRWyxgVEGLXb5qoqXvO+xvHZsl0A+i5oUJARKzJrD0EobMy Pd/KRe8lTLuedsK6oUyJwCJsvQ0Ak2WvhlRixi4Z7DHSFOIxHJsMUd15IK9vbQFVF2Yl Ng6W8fDYljYvUVkrH4HxlFV88BTFX0GmEf1A/qwakHcFqLw5XabCXS0/mcknBBV2GWVo nJRA==
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=KM/vGVRsKGftPVS1UedoMkqyjvjpRi47dQNNzouFnr8=; b=ZyEAe4gcwXjDMtsgM9jAO5oowvXItPkBNi4IVlMvRuMxQzCtM8tafK7yQ0IYDFQ9ac QdVwKnzTpfTcLwsn9qNrEtAGFHGShiAD14gd6r+bgpGAP+CjpdtuRXX6GoJk96ErMiNu NEDhq1AVBWAhulgOPUVMbYBw/oBB3UiM3NWVIMTGkqMjUI9bBBwCVYlceVaQQt55fuDr ug58y6ec9eGyYwzPK43xTD79MkWzQ3VkZo1E9ArZqwzwZJCi2XlZiKuYBjRt9AS+V8Zd tcLxlJw0rzH/FdoOI3tYKM85bZgunmrzWh55ylaJArmh19xMaTXM/BHOSLHb0t/MCgN3 khpA==
X-Gm-Message-State: AMCzsaXfAIpOLNvbzz5gHrR1Txa/MAOH9D5znoPqe/3u9WmDyp0/lMQM HI4oCVkTVcNx1zizW0/n+iKxv8WAtd+IwRo3UWXQWQ==
X-Google-Smtp-Source: ABhQp+QHoHGHKDJEbZtrLWJu3/QgZjDljuQ6wQXGDjR07pLCvCetjJOluGRWt53uK+ddVfUduuJPGzm5Tqa+jvCSJ5A=
X-Received: by 10.25.221.196 with SMTP id w65mr928884lfi.89.1509471100235; Tue, 31 Oct 2017 10:31:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.150.198 with HTTP; Tue, 31 Oct 2017 10:31:39 -0700 (PDT)
In-Reply-To: <21b5f7ec-936d-c729-1ada-fdb757e1ccd4@alumni.stanford.edu>
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com>  <21b5f7ec-936d-c729-1ada-fdb757e1ccd4@alumni.stanford.edu>
From: Andy Bierman 
Date: Tue, 31 Oct 2017 10:31:39 -0700
Message-ID: 
To: Randy Presuhn 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0c884aba953b055cdb2086"
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 17:31:44 -0000

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

On Tue, Oct 31, 2017 at 10:22 AM, Randy Presuhn <
randy_presuhn@alumni.stanford.edu> wrote:

> Hi -
>
> On 10/31/2017 10:14 AM, Andy Bierman wrote:
> ...
>
>> The system side effects are irrelevant, but both the same for rpc and
>> action.
>>
>
> Knowing what the system side effects are is *ESSENTIAL* if these
> things are to be of any use operationally.
>
> The only issues relevant to YANG are:
>>     - datastore used to evaluate action ancestor nodes
>>     - datastore used to evaluate input parameter leafref, must, when
>>     - datastore used to evaluate output parameter leafref, must, when
>>
>>
>> These properties cannot be modified by description-stmt.
>> Not now, not ever. Not for rpc. Not for action.
>>
>> It is irrelevant to NMDA whether the rpc or action modifies a datastore,
>> starts a playlist on a jukebox, or makes some toast.
>>
>
> But from the an operational or interoperabilty perspective,
> that information is crucial.
>
>
I am not saying that the description-stmt is not needed.
Of course I need to know if the system will start a jukebox,
make toast, or delete all config in all datastores owned by user "fred".

The old text about resolving YANG for rpc and action is outdated.
Instead of  + config=false floating in space, it is all
well-defined
to be in the  datastore now. That is all NMDA needs to convey.




> Randy
>
>
Andy


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

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




On Tue, Oct 31, 2017 at 10:22 AM, Randy Presuhn <<=
a href=3D"mailto:randy_presuhn@alumni.stanford.edu" target=3D"_blank">randy=
_presuhn@alumni.stanford.edu> wrote:
Hi -



On 10/31/2017 10:14 AM, Andy Bierman wrote:

...



The system side effects are irrelevant, but both the same for rpc and actio=
n.





Knowing what the system side effects are is *ESSENTIAL* if these

things are to be of any use operationally.





The only issues relevant to YANG are:

=C2=A0=C2=A0 =C2=A0- datastore used to evaluate action ancestor nodes

=C2=A0=C2=A0 =C2=A0- datastore used to evaluate input parameter leafref, mu=
st, when

=C2=A0=C2=A0 =C2=A0- datastore used to evaluate output parameter leafref, m=
ust, when





These properties cannot be modified by description-stmt.

Not now, not ever. Not for rpc. Not for action.



It is irrelevant to NMDA whether the rpc or action modifies a datastore,
starts a playlist on a jukebox, or makes some toast.





But from the an operational or interoperabilty perspective,

that information is crucial.



I am not saying that the description-s=
tmt is not needed.
Of course I need to know if the system will st=
art a jukebox,
make toast, or delete all config in all datastores=
 owned by user "fred".

The old text abou=
t resolving YANG for rpc and action is outdated.
Instead of <r=
unning> + config=3Dfalse floating in space, it is all well-defined
=

to be in the <operational> datastore now. That is all NMDA needs=
 to convey.


=C2=A0

Randy



Andy
=C2=A0

_______________________________________________

netmod mailing list

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




--94eb2c0c884aba953b055cdb2086--


From nobody Tue Oct 31 10:36:24 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1671C13FA17 for ; Tue, 31 Oct 2017 10:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 870P1oPtSEEL for ; Tue, 31 Oct 2017 10:36:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B445B13F9F3 for ; Tue, 31 Oct 2017 10:36:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYY92656; Tue, 31 Oct 2017 17:36:13 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 31 Oct 2017 17:36:12 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001;  Tue, 31 Oct 2017 10:36:06 -0700
From: Alexander Clemm 
To: Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn 
Thread-Topic: [netmod] Action and RPC statements
Thread-Index: AQHTTv5c6Thnq3+sH0epzy6XUWpHDqL+fHIA///AowA=
Date: Tue, 31 Oct 2017 17:36:06 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABACAD@sjceml521-mbx.china.huawei.com>
References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com>   <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com>
In-Reply-To: <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.48.80]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABACADsjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59F8B48E.007E, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8749b419d9e9efe6a83f53400acb7338
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Oct 2017 17:36:20 -0000

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

SGkgUm9iLA0KDQpBIGZldyBjb21tZW50cywgaW5saW5lDQoNCi0tLSBBbGV4DQoNCkZyb206IG5l
dG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0
IFdpbHRvbg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyA3OjE0IEFNDQpUbzogTWFy
dGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+OyBhbmR5QHl1bWF3b3Jrcy5jb207IG5ldG1v
ZEBpZXRmLm9yZzsgUmFuZHkgUHJlc3VobiA8cmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQu
ZWR1Pg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIEFjdGlvbiBhbmQgUlBDIHN0YXRlbWVudHMNCg0K
DQpIaSwNCg0KSGVyZSBpcyBhbm90aGVyIGF0dGVtcHQgZm9yIHByb3Bvc2VkIHRleHQgZm9yIEFj
dGlvbnMvUlBDIHN0YXRlbWVudHMgaW4gTk1EQS4NCg0KPG5ldz4NCg0KNi4yIEludm9jYXRpb24g
b2YgUlBDIE9wZXJhdGlvbnMNCg0KVGhpcyBzZWN0aW9uIHVwZGF0ZXMgc2VjdGlvbiA3LjE0IG9m
IFJGQyA3OTUwLg0KDQpSUENzIE1BWSBiZSBkZWZpbmVkIGFzIGFmZmVjdGluZyB0aGUgY29udGVu
dHMgb2YgYSBzcGVjaWZpYyBkYXRhc3RvcmUsDQphbnkgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUg
KGUuZy4sIDxlZGl0LWNvbmZpZz4pLCBvciBhbnkgZGF0YXN0b3JlDQooZS5nLiwgPGdldC1kYXRh
PikuICBUaGUgUlBDIGRlZmluaXRpb24gc3BlY2lmaWVzIGhvdyB0aGUgUlBDIGlucHV0DQpkYXRh
IGlzIGludGVycHJldGVkIGJ5IHRoZSBzZXJ2ZXIuDQoNCjxBTEVYPiB3aHkg4oCcZS5nLiwgPGdl
dC1kYXRhPuKAnT8gIERvZXMgPGdldC1kYXRhPiBhZmZlY3QgdGhlIGNvbnRlbnRzIG9mIHRoZSBk
YXRhc3RvcmUg4oCTIEkgdGhvdWdodCBpdCBqdXN0IGdldHMgZGF0YSwgaGVuY2UgdGhpcyBleGFt
cGxlIGlzIG5vdCBpZGVhbC4NCg0KVGhlcmUgaXMgYWxzbyBubyBtZW50aW9uIGFib3V0IHRoZSBz
b3VyY2Ugb2YgdGhlIOKAnGlu4oCdIHBhcmFtZXRlcnMuICBJdCBwcm9iYWJseSBtYWtlcyBzZW5z
ZSB0byBtZW50aW9uIHRoYXQgZXhwbGljaXRseS4NCg0KUGVyaGFwcyBzb21ldGhpbmcgYWxvbmcg
dGhlIGxpbmVzIG9mIOKAnFJQQ3MgTUFZIGJlIGRlZmluZWQgYXMgX3JlbGF0aW5nXyB0byB0aGUg
Y29udGVudHMgb2YgYSBzcGVjaWZpYyBkYXRhc3RvcmXigKYuICAgSW5wdXQgZGF0YSByZXNvbHZl
cyB0byA8b3BlcmF0aW9uYWw+LCBhcyBkb2VzIG91dHB1dCBkYXRhLCBhcyBkbyBSUEMgc2lkZSBl
ZmZlY3Rz4oCcLiAgVGhlbiBiZWxvdw0KDQrigJxSUENzIGRlZmluaXRpb25zIHRoYXQgZG8gbm90
IGV4cGxpY2l0bHkgc3RhdGUgYW4gYWZmZWN0ZWQNCmRhdGFzdG9yZShzKSBfcmVmZXJfdG9fICB0
aGUgZ2VuZXJhbCBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUgc2VydmVyLuKAnQ0KDQoNCg0KT25l
IG90aGVyIGNvbW1lbnQsIGl0IHdvdWxkIGJlIGdvb2QgdG8gYWxzbyBpbmRpY2F0ZSB0aGF0IHdo
ZW4gYW4gUlBDIGxlYWRzIHRvIG1vZGlmaWNhdGlvbiBvZiBkYXRhIG5vZGVzLCB3aGF0IHRoZSDi
gJxvcmlnaW7igJ0gb2YgdGhvc2UgbW9kaWZpY2F0aW9ucyBpcy4NCg0KPC9BTEVYPg0KDQoNClJQ
Q3MgZGVmaW5pdGlvbnMgdGhhdCBkbyBub3QgZXhwbGljaXRseSBzdGF0ZSBhbiBhZmZlY3RlZA0K
ZGF0YXN0b3JlKHMpIG1vZGlmeSB0aGUgZ2VuZXJhbCBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUg
c2VydmVyLg0KSGVuY2UsIGlmIGFueSBSUEMgaW5wdXQgZGF0YSByZWxhdGVzIHRvIGRhdGEgbm9k
ZSBpbnN0YW5jZXMgdGhlbg0KdGhvc2Ugd291bGQgZ2VuZXJhbGx5IHJlc29sdmUgdG8gZGF0YSBu
b2RlIGluc3RhbmNlcyBpbiB0aGUNCjxvcGVyYXRpb25hbD4gZGF0YSB0cmVlLg0KDQoNCjYuMyBJ
bnZvY2F0aW9uIG9mIEFjdGlvbnMNCg0KVGhpcyBzZWN0aW9uIHVwZGF0ZXMgc2VjdGlvbiA3LjE1
IG9mIFJGQyA3OTUwLg0KDQpJbiBZQU5HIGRhdGEgbW9kZWxzLCB0aGUgImFjdGlvbiIgc3RhdGVt
ZW50IG1heSBhcHBlYXIgdW5kZXIgImNvbmZpZw0KdHJ1ZSIgYW5kICJjb25maWcgZmFsc2UiIHNj
aGVtYSBub2Rlcy4gIFdoaWxlIGluc3RhbmNlcyBvZiBib3RoDQpzY2hlbWEgbm9kZXMgbWF5IGFw
cGVhciBpbiA8b3BlcmF0aW9uYWw+LCBpbnN0YW5jZXMgb2YgImNvbmZpZyB0cnVlIg0Kc2NoZW1h
IG5vZGVzIG1heSBhbHNvIGFwcGVhciBpbiBvdGhlciBkYXRhc3RvcmVzLg0KDQpBY3Rpb25zIGFy
ZSBhbHdheXMgaW52b2tlZCBvbiBhIGRhdGEgbm9kZSBpbnN0YW5jZSB0aGF0IGV4aXN0IGluIHRo
ZQ0KPG9wZXJhdGlvbmFsPiBkYXRhIHRyZWUuICBUaGUgYmVoYXZpb3IgZGVmaW5lZCBieSBhbiBh
Y3Rpb24gc3RhdGVtZW50DQppcyBnZW5lcmFsbHkgZXhwZWN0ZWQgdG8gYWZmZWN0IHRoZSBvcGVy
YXRpb25hbCBzdGF0ZSBvZiB0aGUgc2VydmVyDQpyYXRoZXIgdGhhbiBkaXJlY3RseSBtb2RpZnlp
bmcgdGhlIGNvbnRlbnRzIG9mIGFueSBjb25maWd1cmF0aW9uDQpkYXRhc3RvcmUuDQo8L25ldz4N
Cg0KDQpPbiBhIHJlbGF0ZWQgbm90ZSwgSSBhbHNvIHdhbnQgdG8gY29uZmlybSB0aGF0IGl0IGlz
IHJpZ2h0IHRoYXQgUlBDIGlucHV0IGRhdGEgaXMgYWx3YXlzIGNoZWNrZWQgYWdhaW5zdCBvcGVy
YXRpb25hbDoNCg0KU2VjdGlvbiA2LjEuIG9mIHRoZSBOTURBIGRyYWZ0IHN0YXRlczoNCg0KDQoN
CiAgIG8gIElmIHRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGRlZmluZWQgaW4gYSBzdWJzdGF0ZW1l
bnQgdG8gYW4gImlucHV0Ig0KDQogICAgICBzdGF0ZW1lbnQgaW4gYW4gInJwYyIgb3IgImFjdGlv
biIgc3RhdGVtZW50LCB0aGUgYWNjZXNzaWJsZSB0cmVlDQoNCiAgICAgIGlzIHRoZSBSUEMgb3Ig
YWN0aW9uIG9wZXJhdGlvbiBpbnN0YW5jZSBhbmQgYWxsIG9wZXJhdGlvbmFsIHN0YXRlDQoNCiAg
ICAgIGluIHRoZSBzZXJ2ZXIuICBUaGUgcm9vdCBub2RlIGhhcyB0b3AtbGV2ZWwgZGF0YSBub2Rl
cyBpbiBhbGwNCg0KICAgICAgbW9kdWxlcyBhcyBjaGlsZHJlbi4gIEFkZGl0aW9uYWxseSwgZm9y
IGFuIFJQQywgdGhlIHJvb3Qgbm9kZSBhbHNvDQoNCiAgICAgIGhhcyB0aGUgbm9kZSByZXByZXNl
bnRpbmcgdGhlIFJQQyBvcGVyYXRpb24gYmVpbmcgZGVmaW5lZCBhcyBhDQoNCiAgICAgIGNoaWxk
LiAgVGhlIG5vZGUgcmVwcmVzZW50aW5nIHRoZSBvcGVyYXRpb24gYmVpbmcgZGVmaW5lZCBoYXMg
dGhlDQoNCiAgICAgIG9wZXJhdGlvbidzIGlucHV0IHBhcmFtZXRlcnMgYXMgY2hpbGRyZW4uDQoN
Cg0KSXMgPG9wZXJhdGlvbmFsPiBhbHdheXMgdGhlIHJpZ2h0IGRhdGFzdG9yZSB0byBldmFsdWF0
ZSBSUEMgaW5wdXQvb3V0cHV0IGRhdGEgcmVsYXRpdmUgdG8/ICBGb3IgbW9zdCBSUENzIHRoaXMg
c2VlbXMgdG8gYmUgdGhlIHJpZ2h0IGNob2ljZSBieSBkZWZhdWx0IGJ1dCBpdCBhbHNvIHNlZW1z
IHBsYXVzaWJsZSB0aGF0IHNvbWVvbmUgbWF5IHdpc2ggdG8gZGVmaW5lIGFuIFJQQyB0aGF0IHdh
bnRzIHRvIHZhbGlkYXRlIGl0cyBpbnB1dCBwYXJhbWV0ZXJzIGFnYWluc3QgdGhlIGNvbnRlbnRz
IG9mIGFub3RoZXIgZGF0YXN0b3JlLg0KDQpBbiBleGFtcGxlIGNvdWxkIGJlIGFuICJpcy1hcHBs
aWVkIiBSUEMgdGhhdCB0YWtlcyBhIHBhdGggdG8gYSBzdWJ0cmVlIGluIDxydW5uaW5nPiBvciA8
aW50ZW5kZWQ+IGFuZCBjaGVja3Mgd2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBmb3IgdGhhdCBz
dWJ0cmVlIGlzIGZ1bGx5IHJlcHJlc2VudGVkIGluIDxvcGVyYXRpb25hbD4uDQoNClRoYW5rcywN
ClJvYg0KDQpPbiAyNy8xMC8yMDE3IDA5OjMzLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KDQpB
bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT48bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv
bT4gd3JvdGU6DQoNCk9uIFRodSwgT2N0IDI2LCAyMDE3IGF0IDExOjIyIEFNLCBSYW5keSBQcmVz
dWhuIDwNCg0KcmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1PG1haWx0bzpyYW5keV9w
cmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHU+PiB3cm90ZToNCg0KDQoNCkhpIC0NCg0KDQoNCk9u
IDEwLzI2LzIwMTcgMTA6NDQgQU0sIFJvYmVydCBXaWx0b24gd3JvdGU6DQoNCg0KDQpIaSAsDQoN
Cg0KDQpTZXBhcmF0aW5nIG91dCB0aGUgaXNzdWUgcmVnYXJkaW5nIHdoaWNoIGRhdGFzdG9yZSBh
Y3Rpb24gYW5kIFJQQyBhcHBseQ0KDQp0bywgd2UgcHJvcG9zZSB0aGUgZm9sbG93aW5nIE5FVyB0
ZXh0IHRvIHRoZSBkYXRhc3RvcmVzIGRyYWZ0Og0KDQoNCg0KNi4yIEludm9jYXRpb24gb2YgQWN0
aW9ucyBhbmQgUlBDIE9wZXJhdGlvbnMNCg0KDQoNCiAgIFRoaXMgc2VjdGlvbiB1cGRhdGVzIHNl
Y3Rpb24gNy4xNS4gb2YgUkZDIDc5NTAuDQoNCg0KDQogICBJbiBZQU5HIGRhdGEgbW9kZWxzLCB0
aGUgImFjdGlvbiIgc3RhdGVtZW50IG1heSBhcHBlYXIgdW5kZXIgImNvbmZpZw0KDQogICB0cnVl
IiBhbmQgImNvbmZpZyBmYWxzZSIgc2NoZW1hIG5vZGVzLiAgV2hpbGUgaW5zdGFuY2VzIG9mIGJv
dGgNCg0KICAgc2NoZW1hIG5vZGVzIG1heSBhcHBlYXIgaW4gPG9wZXJhdGlvbmFsPiwgaW5zdGFu
Y2VzIG9mICJjb25maWcgdHJ1ZSINCg0KICAgc2NoZW1hIG5vZGVzIG1heSBhbHNvIGFwcGVhciBp
biBvdGhlciBkYXRhc3RvcmVzLg0KDQoNCg0KICAgQW4gTk1EQSBjb21wbGlhbnQgc2VydmVyIE1V
U1QgZXhlY3V0ZSBhbGwgYWN0aW9ucyBpbiB0aGUgY29udGV4dCBvZg0KDQogICA8b3BlcmF0aW9u
YWw+LiAgTGlrZXdpc2UsIGFuIE5NREEgY29tcGxpYW50IHNlcnZlciBNVVNUIGludm9rZSBhbGwg
UlBDDQoNCiAgIG9wZXJhdGlvbnMgaW4gdGhlIGNvbnRleHQgb2YgPG9wZXJhdGlvbmFsPiwgdW5s
ZXNzIHRoZSBSUEMgaXMNCg0KZXhwbGljaXRseQ0KDQogICBkZWZpbmVkIGFzIGFmZmVjdGluZyBv
dGhlciBkYXRhc3RvcmVzIChlLmcuLCA8ZWRpdC1jb25maWc+KS4NCg0KDQoNCk9LPw0KDQoNCg0K
DQoNCkEgcXVlc3Rpb24gLSBJIHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24gZm9yIHRoZSAidW5s
ZXNzIiBmb3IgUlBDDQoNCm9wZXJhdGlvbnMsIGJ1dCB3b25kZXIgd2h5IHRoZXJlIGlzIG5vIHNp
bWlsYXIgInVubGVzcyIgZm9yIGFjdGlvbnMuDQoNCg0KDQoNCg0KDQoNClRoZSA8cnBjPiBpcyBu
b3QgcmVhbGx5IGluIGEgZGF0YXN0b3JlIGF0IGFsbC4NCg0KSXQgbWF5IGhhdmUgaW5wdXQgYW5k
IG91dHB1dCBwYXJhbWV0ZXJzIHdpdGggbGVhZnJlZiBhbmQgbXVzdC93aGVuDQoNCnN0YXRlbWVu
dHMuDQoNClRoZXNlIGFyZSBldmFsdWF0ZWQgaW4gdGhlIDxvcGVyYXRpb25hbD4gY29udGV4dC4N
Cg0KVGhlIDxycGM+IG1heSBpbiBmYWN0IGJlIHNvbWV0aGluZyBsaWtlIDxlZGl0LWNvbmZpZz4N
Cg0Kd2hpY2ggaGFzIHBhcmFtZXRlcnMgKGxpa2UgPGNvbmZpZz4gdG8gYXBwbHkgdG8NCg0KYSBz
cGVjaWZpYyBkYXRhc3RvcmUuDQoNCg0KDQpUaGUgYWN0aW9uIG5vZGUgaXMgZW1iZWRkZWQgd2l0
aGluIHNvbWUgZGF0YSB0aGF0IGhhcyB0byBiZSBwYXJzZWQNCg0KaW4gYSBzcGVjaWZpYyBkYXRh
c3RvcmUgYmVmb3JlIHRoZSBhY3Rpb24gaXMgcHJvY2Vzc2VkLg0KDQpUaGlzIGRhdGEgaXMgcmVx
dWlyZWQgdG8gYmUgaW4gPG9wZXJhdGlvbmFsPi4NCg0KSXQgYWxzbyBoYXMgWFBhdGggYW5kIGxl
YWZyZWYgdGhhdCBuZWVkcyB0byBiZSByZXNvbHZlZCAoc2FtZSBhcyA8cnBjPikuDQoNCg0KDQpU
aGUgc2lkZSBlZmZlY3RzIG9mIHRoZSA8cnBjPiBvciA8YWN0aW9uPiBjYW4gaW1wYWN0IG90aGVy
IGRhdGFzdG9yZXMuDQoNClRoaXMgd291bGQgYmUgZGVmaW5lZCBpbiB0aGUgZGVzY3JpcHRpb24t
c3RtdCBhbmQgdGhpcyBpcyBub3QgYSBwcm9ibGVtLg0KDQoNCg0KVGhpcyBpcyBleGFjdGx5IHJp
Z2h0LiAgV2UgbmVlZCB0byBjYXB0dXJlIHRoaXMgaW4gdGhlIHRleHQuDQoNCg0KDQoNCg0KL21h
cnRpbg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KbmV0bW9kIG1haWxpbmcgbGlzdA0KDQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v
ZEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QNCg0KLg0KDQoNCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs
dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnR0DQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRN
TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo
YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm
b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u
RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu
MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgUm9iLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QSBmZXcgY29tbWVudHMsIGlu
bGluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w
OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gbmV0bW9kIFttYWls
dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBX
aWx0b248YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyA3OjE0IEFN
PGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gQmpvcmtsdW5kICZsdDttYmpAdGFpbC1mLmNvbSZndDs7
IGFuZHlAeXVtYXdvcmtzLmNvbTsgbmV0bW9kQGlldGYub3JnOyBSYW5keSBQcmVzdWhuICZsdDty
YW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHUmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbbmV0bW9kXSBBY3Rpb24gYW5kIFJQQyBzdGF0ZW1lbnRzPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHA+SGksPG86cD48L286cD48L3A+DQo8cD5IZXJlIGlzIGFub3RoZXIgYXR0ZW1w
dCBmb3IgcHJvcG9zZWQgdGV4dCBmb3IgQWN0aW9ucy9SUEMgc3RhdGVtZW50cyBpbiBOTURBLjxv
OnA+PC9vOnA+PC9wPg0KPHA+Jmx0O25ldyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Ni4yIEludm9jYXRpb24gb2YgUlBDIE9wZXJhdGlv
bnMgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjxicj4NCjx0dD5UaGlzIHNlY3Rpb24gdXBk
YXRlcyBzZWN0aW9uIDcuMTQgb2YgUkZDIDc5NTAuIDwvdHQ+PGJyPg0KPGJyPg0KPHR0PlJQQ3Mg
TUFZIGJlIGRlZmluZWQgYXMgYWZmZWN0aW5nIHRoZSBjb250ZW50cyBvZiBhIHNwZWNpZmljIGRh
dGFzdG9yZSwgPC90dD48YnI+DQo8dHQ+YW55IGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIChlLmcu
LCAmbHQ7ZWRpdC1jb25maWcmZ3Q7KSwgb3IgYW55IGRhdGFzdG9yZSA8L3R0Pjxicj4NCjx0dD4o
ZS5nLiwgJmx0O2dldC1kYXRhJmd0OykuJm5ic3A7IFRoZSBSUEMgZGVmaW5pdGlvbiBzcGVjaWZp
ZXMgaG93IHRoZSBSUEMgaW5wdXQgPC90dD48YnI+DQo8dHQ+ZGF0YSBpcyBpbnRlcnByZXRlZCBi
eSB0aGUgc2VydmVyLiA8L3R0Pjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC90dD48L3A+DQo8cD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0FMRVgmZ3Q7IHdoeSDigJxlLmcuLCAmbHQ7Z2V0
LWRhdGEmZ3Q74oCdPyZuYnNwOyBEb2VzICZsdDtnZXQtZGF0YSZndDsgYWZmZWN0IHRoZSBjb250
ZW50cyBvZiB0aGUgZGF0YXN0b3JlIOKAkyBJIHRob3VnaHQgaXQganVzdCBnZXRzIGRhdGEsIGhl
bmNlIHRoaXMgZXhhbXBsZSBpcyBub3QgaWRlYWwuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgYWxzbyBubyBt
ZW50aW9uIGFib3V0IHRoZSBzb3VyY2Ugb2YgdGhlIOKAnGlu4oCdIHBhcmFtZXRlcnMuJm5ic3A7
IEl0IHByb2JhYmx5IG1ha2VzIHNlbnNlIHRvIG1lbnRpb24gdGhhdCBleHBsaWNpdGx5LiZuYnNw
Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPlBlcmhhcHMgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiDigJxSUENzIE1BWSBiZSBk
ZWZpbmVkIGFzIF88aT5yZWxhdGluZzwvaT5fIHRvIHRoZSBjb250ZW50cyBvZiBhIHNwZWNpZmlj
IGRhdGFzdG9yZeKApi4gJm5ic3A7Jm5ic3A7SW5wdXQgZGF0YSByZXNvbHZlcyB0byAmbHQ7b3Bl
cmF0aW9uYWwmZ3Q7LCBhcyBkb2VzIG91dHB1dA0KIGRhdGEsIGFzIGRvIFJQQyBzaWRlIGVmZmVj
dHPigJwuJm5ic3A7IFRoZW4gYmVsb3cgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0RTc5O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMxRjRFNzk7
bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj48c3BhbiBzdHlsZT0iY29sb3I6
d2luZG93dGV4dCI+4oCcPC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjRFNzk7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4
dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5S
UENzDQogZGVmaW5pdGlvbnMgdGhhdCBkbyBub3QgZXhwbGljaXRseSBzdGF0ZSBhbiBhZmZlY3Rl
ZCA8L3NwYW4+PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjRFNzk7bXNvLXN0
eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1h
bHBoYToxMDAuMCUiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjRF
Nzk7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZp
bGwtZmlsbC1hbHBoYToxMDAuMCUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5kYXRh
c3RvcmUocykgXzxpPnJlZmVyX3RvPC9pPl8gJm5ic3A7dGhlIGdlbmVyYWwgb3BlcmF0aW9uYWwg
c3RhdGUNCiBvZiB0aGUgc2VydmVyLjwvc3Bhbj48L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjRFNzk7bXNv
LXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmls
bC1hbHBoYToxMDAuMCUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij7igJ08bzpwPjwv
bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0RTc5O21zby1zdHlsZS10ZXh0Zmls
bC1maWxsLWNvbG9yOiMxRjRFNzk7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAl
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjRFNzk7bXNvLXN0eWxl
LXRleHRmaWxsLWZpbGwtY29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBo
YToxMDAuMCUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5PbmUgb3RoZXIgY29tbWVu
dCwgaXQgd291bGQgYmUgZ29vZCB0byBhbHNvIGluZGljYXRlIHRoYXQgd2hlbiBhbiBSUEMgbGVh
ZHMgdG8gbW9kaWZpY2F0aW9uDQogb2YgZGF0YSBub2Rlcywgd2hhdCB0aGUg4oCcb3JpZ2lu4oCd
IG9mIHRob3NlIG1vZGlmaWNhdGlvbnMgaXMuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bh
bj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjRFNzk7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzFG
NEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPjxzcGFuIHN0eWxlPSJj
b2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7L0FMRVgmZ3Q7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMUY0RTc5O21z
by1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjxicj4NCjxicj4NCjx0dD5SUENzIGRlZmluaXRpb25zIHRoYXQgZG8g
bm90IGV4cGxpY2l0bHkgc3RhdGUgYW4gYWZmZWN0ZWQgPC90dD48YnI+DQo8dHQ+ZGF0YXN0b3Jl
KHMpIG1vZGlmeSB0aGUgZ2VuZXJhbCBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUgc2VydmVyLiA8
L3R0Pjxicj4NCjx0dD5IZW5jZSwgaWYgYW55IFJQQyBpbnB1dCBkYXRhIHJlbGF0ZXMgdG8gZGF0
YSBub2RlIGluc3RhbmNlcyB0aGVuIDwvdHQ+PGJyPg0KPHR0PnRob3NlIHdvdWxkIGdlbmVyYWxs
eSByZXNvbHZlIHRvIGRhdGEgbm9kZSBpbnN0YW5jZXMgaW4gdGhlIDwvdHQ+PGJyPg0KPHR0PiZs
dDtvcGVyYXRpb25hbCZndDsgZGF0YSB0cmVlLiA8L3R0Pjxicj4NCjxicj4NCjxicj4NCjx0dD42
LjMgSW52b2NhdGlvbiBvZiBBY3Rpb25zIDwvdHQ+PGJyPg0KPGJyPg0KPHR0PlRoaXMgc2VjdGlv
biB1cGRhdGVzIHNlY3Rpb24gNy4xNSBvZiBSRkMgNzk1MC4gPC90dD48YnI+DQo8YnI+DQo8dHQ+
SW4gWUFORyBkYXRhIG1vZGVscywgdGhlICZxdW90O2FjdGlvbiZxdW90OyBzdGF0ZW1lbnQgbWF5
IGFwcGVhciB1bmRlciAmcXVvdDtjb25maWcgPC90dD48YnI+DQo8dHQ+dHJ1ZSZxdW90OyBhbmQg
JnF1b3Q7Y29uZmlnIGZhbHNlJnF1b3Q7IHNjaGVtYSBub2Rlcy4mbmJzcDsgV2hpbGUgaW5zdGFu
Y2VzIG9mIGJvdGggPC90dD48YnI+DQo8dHQ+c2NoZW1hIG5vZGVzIG1heSBhcHBlYXIgaW4gJmx0
O29wZXJhdGlvbmFsJmd0OywgaW5zdGFuY2VzIG9mICZxdW90O2NvbmZpZyB0cnVlJnF1b3Q7IDwv
dHQ+PGJyPg0KPHR0PnNjaGVtYSBub2RlcyBtYXkgYWxzbyBhcHBlYXIgaW4gb3RoZXIgZGF0YXN0
b3Jlcy4gPC90dD48YnI+DQo8YnI+DQo8dHQ+QWN0aW9ucyBhcmUgYWx3YXlzIGludm9rZWQgb24g
YSBkYXRhIG5vZGUgaW5zdGFuY2UgdGhhdCBleGlzdCBpbiB0aGUgPC90dD48YnI+DQo8dHQ+Jmx0
O29wZXJhdGlvbmFsJmd0OyBkYXRhIHRyZWUuJm5ic3A7IFRoZSBiZWhhdmlvciBkZWZpbmVkIGJ5
IGFuIGFjdGlvbiBzdGF0ZW1lbnQgPC90dD48YnI+DQo8dHQ+aXMgZ2VuZXJhbGx5IGV4cGVjdGVk
IHRvIGFmZmVjdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgb2YgdGhlIHNlcnZlciA8L3R0Pjxicj4N
Cjx0dD5yYXRoZXIgdGhhbiBkaXJlY3RseSBtb2RpZnlpbmcgdGhlIGNvbnRlbnRzIG9mIGFueSBj
b25maWd1cmF0aW9uIDwvdHQ+PGJyPg0KPHR0PmRhdGFzdG9yZS4gPC90dD48L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7L25ldyZndDs8YnI+DQo8YnI+DQo8
YnI+DQpPbiBhIHJlbGF0ZWQgbm90ZSwgSSBhbHNvIHdhbnQgdG8gY29uZmlybSB0aGF0IGl0IGlz
IHJpZ2h0IHRoYXQgUlBDIGlucHV0IGRhdGEgaXMgYWx3YXlzIGNoZWNrZWQgYWdhaW5zdCBvcGVy
YXRpb25hbDo8YnI+DQo8YnI+DQpTZWN0aW9uIDYuMS4gb2YgdGhlIE5NREEgZHJhZnQgc3RhdGVz
Ojxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1l
bnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4w
cHQgOC4wcHQgOC4wcHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwcmUgc3R5bGU9Im1h
cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs
O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+
Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgSWYgdGhlIFhQYXRoIGV4cHJlc3Npb24gaXMgZGVmaW5lZCBp
biBhIHN1YnN0YXRlbWVudCB0byBhbiAmcXVvdDtpbnB1dCZxdW90OzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE
RjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3Rh
dGVtZW50IGluIGFuICZxdW90O3JwYyZxdW90OyBvciAmcXVvdDthY3Rpb24mcXVvdDsgc3RhdGVt
ZW50LCB0aGUgYWNjZXNzaWJsZSB0cmVlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy
ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyB0aGUgUlBDIG9yIGFjdGlv
biBvcGVyYXRpb24gaW5zdGFuY2UgYW5kIGFsbCBvcGVyYXRpb25hbCBzdGF0ZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5k
OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgaW4gdGhlIHNlcnZlci4mbmJzcDsgVGhlIHJvb3Qgbm9kZSBoYXMgdG9wLWxldmVsIGRhdGEg
bm9kZXMgaW4gYWxsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3Jk
ZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtb2R1bGVzIGFzIGNoaWxkcmVuLiZuYnNwOyBBZGRp
dGlvbmFsbHksIGZvciBhbiBSUEMsIHRoZSByb290IG5vZGUgYWxzbzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE
RjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGFz
IHRoZSBub2RlIHJlcHJlc2VudGluZyB0aGUgUlBDIG9wZXJhdGlvbiBiZWluZyBkZWZpbmVkIGFz
IGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45
cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3Bh
ZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IGNoaWxkLiZuYnNwOyBUaGUgbm9kZSByZXByZXNlbnRpbmcgdGhlIG9w
ZXJhdGlvbiBiZWluZyBkZWZpbmVkIGhhcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl
YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wZXJhdGlvbidzIGlu
cHV0IHBhcmFtZXRlcnMgYXMgY2hpbGRyZW4uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy
Pg0KPGJyPg0KSXMgJmx0O29wZXJhdGlvbmFsJmd0OyBhbHdheXMgdGhlIHJpZ2h0IGRhdGFzdG9y
ZSB0byBldmFsdWF0ZSBSUEMgaW5wdXQvb3V0cHV0IGRhdGEgcmVsYXRpdmUgdG8/Jm5ic3A7IEZv
ciBtb3N0IFJQQ3MgdGhpcyBzZWVtcyB0byBiZSB0aGUgcmlnaHQgY2hvaWNlIGJ5IGRlZmF1bHQg
YnV0IGl0IGFsc28gc2VlbXMgcGxhdXNpYmxlIHRoYXQgc29tZW9uZSBtYXkgd2lzaCB0byBkZWZp
bmUgYW4gUlBDIHRoYXQgd2FudHMgdG8gdmFsaWRhdGUgaXRzIGlucHV0IHBhcmFtZXRlcnMNCiBh
Z2FpbnN0IHRoZSBjb250ZW50cyBvZiBhbm90aGVyIGRhdGFzdG9yZS48YnI+DQo8YnI+DQpBbiBl
eGFtcGxlIGNvdWxkIGJlIGFuICZxdW90O2lzLWFwcGxpZWQmcXVvdDsgUlBDIHRoYXQgdGFrZXMg
YSBwYXRoIHRvIGEgc3VidHJlZSBpbiAmbHQ7cnVubmluZyZndDsgb3IgJmx0O2ludGVuZGVkJmd0
OyBhbmQgY2hlY2tzIHdoZXRoZXIgdGhlIGNvbmZpZ3VyYXRpb24gZm9yIHRoYXQgc3VidHJlZSBp
cyBmdWxseSByZXByZXNlbnRlZCBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7Ljxicj4NCjxicj4NClRo
YW5rcyw8YnI+DQpSb2I8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiAyNy8xMC8yMDE3IDA5OjMzLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+QW5keSBCaWVybWFuIDxhIGhyZWY9Im1h
aWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPiZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7PC9hPiB3
cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPk9uIFRodSwgT2N0IDI2LCAyMDE3IGF0IDEx
OjIyIEFNLCBSYW5keSBQcmVzdWhuICZsdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVm
PSJtYWlsdG86cmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1Ij5yYW5keV9wcmVzdWhu
QGFsdW1uaS5zdGFuZm9yZC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhpIC08bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiAxMC8yNi8yMDE3IDEwOjQ0IEFN
LCBSb2JlcnQgV2lsdG9uIHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwcmU+SGkgLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNlcGFyYXRpbmcgb3V0IHRoZSBpc3N1ZSByZWdhcmRpbmcg
d2hpY2ggZGF0YXN0b3JlIGFjdGlvbiBhbmQgUlBDIGFwcGx5PG86cD48L286cD48L3ByZT4NCjxw
cmU+dG8sIHdlIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBORVcgdGV4dCB0byB0aGUgZGF0YXN0b3Jl
cyBkcmFmdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT42LjIgSW52b2NhdGlvbiBvZiBBY3Rpb25zIGFuZCBSUEMgT3BlcmF0aW9uczxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyBUaGlzIHNlY3Rpb24gdXBkYXRlcyBzZWN0aW9uIDcuMTUuIG9mIFJGQyA3OTUwLjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyBJbiBZQU5HIGRhdGEgbW9kZWxzLCB0aGUgJnF1b3Q7YWN0aW9uJnF1b3Q7IHN0YXRlbWVudCBt
YXkgYXBwZWFyIHVuZGVyICZxdW90O2NvbmZpZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyB0cnVlJnF1b3Q7IGFuZCAmcXVvdDtjb25maWcgZmFsc2UmcXVvdDsgc2NoZW1hIG5v
ZGVzLiZuYnNwOyBXaGlsZSBpbnN0YW5jZXMgb2YgYm90aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyZuYnNwOyBzY2hlbWEgbm9kZXMgbWF5IGFwcGVhciBpbiAmbHQ7b3BlcmF0aW9uYWwm
Z3Q7LCBpbnN0YW5jZXMgb2YgJnF1b3Q7Y29uZmlnIHRydWUmcXVvdDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgc2NoZW1hIG5vZGVzIG1heSBhbHNvIGFwcGVhciBpbiBvdGhl
ciBkYXRhc3RvcmVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBBbiBOTURBIGNvbXBsaWFudCBzZXJ2ZXIgTVVTVCBleGVj
dXRlIGFsbCBhY3Rpb25zIGluIHRoZSBjb250ZXh0IG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7ICZsdDtvcGVyYXRpb25hbCZndDsuJm5ic3A7IExpa2V3aXNlLCBhbiBOTURB
IGNvbXBsaWFudCBzZXJ2ZXIgTVVTVCBpbnZva2UgYWxsIFJQQzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyBvcGVyYXRpb25zIGluIHRoZSBjb250ZXh0IG9mICZsdDtvcGVyYXRp
b25hbCZndDssIHVubGVzcyB0aGUgUlBDIGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+ZXhwbGlj
aXRseTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkZWZpbmVkIGFzIGFmZmVj
dGluZyBvdGhlciBkYXRhc3RvcmVzIChlLmcuLCAmbHQ7ZWRpdC1jb25maWcmZ3Q7KS48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PSz88bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BIHF1ZXN0aW9uIC0gSSB1bmRlcnN0
YW5kIHRoZSBtb3RpdmF0aW9uIGZvciB0aGUgJnF1b3Q7dW5sZXNzJnF1b3Q7IGZvciBSUEM8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5vcGVyYXRpb25zLCBidXQgd29uZGVyIHdoeSB0aGVyZSBpcyBu
byBzaW1pbGFyICZxdW90O3VubGVzcyZxdW90OyBmb3IgYWN0aW9ucy48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5U
aGUgJmx0O3JwYyZndDsgaXMgbm90IHJlYWxseSBpbiBhIGRhdGFzdG9yZSBhdCBhbGwuPG86cD48
L286cD48L3ByZT4NCjxwcmU+SXQgbWF5IGhhdmUgaW5wdXQgYW5kIG91dHB1dCBwYXJhbWV0ZXJz
IHdpdGggbGVhZnJlZiBhbmQgbXVzdC93aGVuPG86cD48L286cD48L3ByZT4NCjxwcmU+c3RhdGVt
ZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGVzZSBhcmUgZXZhbHVhdGVkIGluIHRoZSAm
bHQ7b3BlcmF0aW9uYWwmZ3Q7IGNvbnRleHQuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlICZs
dDtycGMmZ3Q7IG1heSBpbiBmYWN0IGJlIHNvbWV0aGluZyBsaWtlICZsdDtlZGl0LWNvbmZpZyZn
dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53aGljaCBoYXMgcGFyYW1ldGVycyAobGlrZSAmbHQ7
Y29uZmlnJmd0OyB0byBhcHBseSB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgc3BlY2lmaWMg
ZGF0YXN0b3JlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPlRoZSBhY3Rpb24gbm9kZSBpcyBlbWJlZGRlZCB3aXRoaW4gc29tZSBkYXRhIHRoYXQg
aGFzIHRvIGJlIHBhcnNlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluIGEgc3BlY2lmaWMgZGF0
YXN0b3JlIGJlZm9yZSB0aGUgYWN0aW9uIGlzIHByb2Nlc3NlZC48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5UaGlzIGRhdGEgaXMgcmVxdWlyZWQgdG8gYmUgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JdCBhbHNvIGhhcyBYUGF0aCBhbmQgbGVhZnJlZiB0aGF0
IG5lZWRzIHRvIGJlIHJlc29sdmVkIChzYW1lIGFzICZsdDtycGMmZ3Q7KS48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgc2lkZSBlZmZlY3Rz
IG9mIHRoZSAmbHQ7cnBjJmd0OyBvciAmbHQ7YWN0aW9uJmd0OyBjYW4gaW1wYWN0IG90aGVyIGRh
dGFzdG9yZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyB3b3VsZCBiZSBkZWZpbmVkIGlu
IHRoZSBkZXNjcmlwdGlvbi1zdG10IGFuZCB0aGlzIGlzIG5vdCBhIHByb2JsZW0uPG86cD48L286
cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+VGhpcyBpcyBleGFjdGx5IHJpZ2h0LiZuYnNwOyBXZSBuZWVkIHRvIGNhcHR1cmUgdGhpcyBp
biB0aGUgdGV4dC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4vbWFydGluPG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5u
ZXRtb2QgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRv
Om5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABACADsjceml521mbxchi_--


From nobody Tue Oct 31 11:56:07 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D1F13F603; Tue, 31 Oct 2017 11:56:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150947616664.28388.7716025982212693801@ietfa.amsl.com>
Date: Tue, 31 Oct 2017 11:56:06 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-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: Tue, 31 Oct 2017 18:56:07 -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 Routing Management (NDMA Version)
        Authors         : Ladislav Lhotka
                          Acee Lindem
                          Yingzhen Qu
	Filename        : draft-ietf-netmod-rfc8022bis-00.txt
	Pages           : 94
	Date            : 2017-10-31

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   This version of these YANG modules uses new names for these YANG
   models.  The main difference from the first version is that this
   version fully conforms to the Network Management Datastore
   Architecture (NMDA).  Consequently, this document obsoletes RFC 8022.
   Deprecated versions of the prior YANG modules are provided as the
   NDMA conpliant modules will replace the prior modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-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 Tue Oct 31 12:11:08 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B62D138FA0 for ; Tue, 31 Oct 2017 12:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 IjwCsnjaiZJq for ; Tue, 31 Oct 2017 12:11:04 -0700 (PDT)
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 82A151388A9 for ; Tue, 31 Oct 2017 12:11:04 -0700 (PDT)
Received: from localhost (unknown [IPv6:2001:718:1:2c:7d42:8aff:48f2:9d76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id D3547400066 for ; Tue, 31 Oct 2017 20:11:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1509477060; bh=o/Gue7jQVR/MDX9HM51pYLWKHjWdG/D3O4UqnNp8Ij8=; h=From:To:Subject:Date; b=FROhoTtiCu1N0Jr1hnq6e2XVNqHDeCoP2kimCk7smWi3ACSAubx7/olWqSRIgLmSr gTWcpXu3jUlj+jdn0K4l6EgDTKRj4WEZ/eeB4jNZ3dGF95oDCS0/T/4G2E8qlhVM57 0WQx+XP1OBud7GwtYYXlfSA2oj4sadf1Tj5oqXDQ=
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= 
To: 
Date: Tue, 31 Oct 2017 20:11:00 +0100
MIME-Version: 1.0
Message-ID: 
Organization: CESNET
User-Agent: Trojita/v0.7-283-g6a841780; Qt/5.9.2; xcb; Linux; Gentoo Base System release 2.3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [netmod] =?iso-8859-1?q?YANG_model_for_netowrk_configuration_of_a?= =?iso-8859-1?q?_device=27s_management_interface?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Oct 2017 19:11:07 -0000

Hi,
I'm working on adding NETCONF support for configuring network on a few=20
management interfaces of our product, a random network appliance. I would=20
prefer not to reinvent this particular wheel, so I started searching for=20
existing models. I was surprised that it seems that all vendors essentially=20=

go creative and appear to hack together something proprietary.

Our product has a pretty modern Linux system inside. It has three network=20
interfaces -- two gigabit RJ-45 ethernets, and one SFP port. My goal is to=20=

offer an intuitive way of assigning static IPv4 or IPv6 addresses, control=20=

whether DHCP/SLAAC are enabled, and perhaps configuring one static VLAN on=20=

each of them. It would be amazing if I could bridge them together, or if=20
there was a way of configuring, say, OSPF, but that comes secondary to=20
getting basic stuff done.

So far, I was able to find the following building blocks:

- RFC 7223. Perfect -- I can simply leave out the arbitrary-names and=20
pre-provisioning features.
- RFC 7277, so that I can assign IPv4 and IPv6 addresses by hand. Good.
- RFC 8022 for static route definitions.

However, I would also like to offer one toggle which enables an IPv4 DHCP=20
client on a given interface. This is where stuff starts to get interesting:

- https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-06 and its IPv6=20=

brother, https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-04 . Wow.=20
Why is the DHCP client configuration done outside of the /if:interfaces=20
tree?

- https://tools.ietf.org/html/draft-faq-netmod-cpe-yang-profile-01 refers=20
to the above, so it seems that I'm looking in a right direction.

- https://tools.ietf.org/html/draft-ietf-rtgwg-device-model-02 looks nice=20
because it mentions a "dhcp-client" within the /if:interfaces tree.=20
However, it does not define how that node looks like!

At this point I begin to understand why vendors unleash their creativity=20
when it comes to assigning IP addresses to management interfaces of their=20
boxes :(. However, I would prefer to just use whatever is most common here,=20=

and focus on the application-specific YANG model. Is there something that I=20=

can use as-is? I would hate to implement 1000th version of this task...

With kind regards,
Jan


From nobody Tue Oct 31 13:07:01 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D09A13F67A; Tue, 31 Oct 2017 13:06:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150948041430.28316.6070479131770273612@ietfa.amsl.com>
Date: Tue, 31 Oct 2017 13:06:54 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-01.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, 31 Oct 2017 20:06:54 -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 Routing Management (NDMA Version)
        Authors         : Ladislav Lhotka
                          Acee Lindem
                          Yingzhen Qu
	Filename        : draft-ietf-netmod-rfc8022bis-01.txt
	Pages           : 72
	Date            : 2017-10-31

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model that
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control-plane
   protocols, route filters, and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   Routing Information Bases (RIBs), and control-plane protocols.

   This version of these YANG modules uses new names for these YANG
   models.  The main difference from the first version is that this
   version fully conforms to the Network Management Datastore
   Architecture (NMDA).  Consequently, this document obsoletes RFC 8022.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-01
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-01


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Oct 31 19:34:39 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C731E13F83A for ; Tue, 31 Oct 2017 19:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8__ODQeLMh6z for ; Tue, 31 Oct 2017 19:34:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0D013F81F for ; Tue, 31 Oct 2017 19:34:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRU00022; Wed, 01 Nov 2017 02:34:33 +0000 (GMT)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 1 Nov 2017 02:33:31 +0000
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0361.001; Wed, 1 Nov 2017 10:33:28 +0800
From: "dingxiaojian (A)" 
To: Alex Campbell 
CC: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-ding-netmod-arp-yang-model-00.txt
Thread-Index: AdNSuYxmkDPQfyT5S6yC51uqJHOFNw==
Date: Wed, 1 Nov 2017 02:33:28 +0000
Message-ID: <3B110B81B721B940871EC78F107D848C0102999B@DGGEMM506-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.134.227]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59F932B9.0081, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f878fea379253e5d24f6a6bdf13d3ffa
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-ding-netmod-arp-yang-model-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: Wed, 01 Nov 2017 02:34:38 -0000

SGkgQWxleCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlldyBvZiB0aGUgZHJhZnQgYW5kIHRo
b3VnaHRmdWwgY29tbWVudHMsIHNpbmNlcmVseSBhcHByZWNpYXRlZC4NClNvcnJ5IGZvciB0aGUg
ZGVsYXksIHBsZWFzZSBmaW5kIG15IGFuc3dlcnMgYW5kIG5vdGVzIGluLWxpbmUgdGFnZ2VkIERY
Sj4+Lg0KDQpSZWdhcmRzLA0KWGlhb2ppYW4NCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6
IEFsZXggQ2FtcGJlbGwgW21haWx0bzpBbGV4LkNhbXBiZWxsQEF2aWF0bmV0LmNvbV0gDQq3osvN
yrG85DogMjAxN8TqMTDUwjI3yNUgNjozMA0KytW8/sjLOiBkaW5neGlhb2ppYW4gKEEpIDxkaW5n
eGlhb2ppYW4xQGh1YXdlaS5jb20+OyBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCrOty806IG5ldG1v
ZEBpZXRmLm9yZw0K1vfM4jogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt
ZGluZy1uZXRtb2QtYXJwLXlhbmctbW9kZWwtMDAudHh0DQoNCkhpIFhpYW9qaWFuLA0KDQoqIFRo
ZSBwdWJsaXNoZWQgbW9kdWxlIGlldGYtaXAgKFJGQyA3Mjc3KSBvdmVybGFwcyB0aGUgZGF0YSBi
ZWluZyBwcm92aWRlZCBpbiB0aGlzIG1vZHVsZS4NCiAgRXNwZWNpYWxseSB5b3VyIC9hcnAvYXJw
LXRhYmxlcyBhbmQgL2FycC9hcnAtc3RhdGljLXRhYmxlcyBzZWVtIHRvIGNvcnJlc3BvbmQgdG8g
L2ludGVyZmFjZXMtc3RhdGUvaW50ZXJmYWNlL2lwdjQvbmVpZ2hib3IgYW5kIC9pbnRlcmZhY2Vz
L2ludGVyZmFjZS9pcHY0L25laWdoYm9yIGZyb20gaWV0Zi1pcC4NCiAgSSB0aGluayB3ZSBzaG91
bGQgYXZvaWQgZHVwbGljYXRpb24gb2YgZGF0YSB3aGVyZSBwb3NzaWJsZTsgY2FuIHlvdSByZWZh
Y3RvciB0aGlzIG1vZHVsZSB0byBhdWdtZW50IHdoYXQgaXMgYWxyZWFkeSB0aGVyZT8NCg0KRFhK
Pj4gIFRoYW5rIHlvdSBmb3IgcmVtaW5kIHVzICBvZiAgUkZDIDcyNzcuIA0KRm9yIC8gaW50ZXJm
YWNlcyAvIGludGVyZmFjZSAvIGlwdjQgLyBuZWlnaGJvciwgaXQgZG9lcyBkZXNjcmliZSBlbnRy
aWVzIG9mIG1hcHBpbmdzIGZyb20gSVB2NCBhZGRyZXNzZXMgdG8gbGluay1sYXllciBhZGRyZXNz
ZXMsIHdoaWNoIGlzIHNpbWlsYXIgdG8gLyBhcnAgLyBhcnAtc3RhdGljLXRhYmxlcyBpbiBvdXIg
ZHJhZnQuIFdlIHdpbGwgdGFrZSB5b3VyIHN1Z2dlc3Rpb24uIA0KRm9yIC8gaW50ZXJmYWNlcy1z
dGF0ZSAvIGludGVyZmFjZSAvIGlwdjQgL25laWdoYm9yLCB0aGUgbGlzdCBkZXNjcmliZXMgdGhl
IEFSUCBDYWNoZS4gVGhhdCBpcywgd2UgY2FuIG9ubHkgb2J0YWluIEFSUCBlbnRyaWVzIGZvciBh
biBpbnRlcmZhY2UuIEhvd2V2ZXIsIGluIG91ciAvIGFycCAvIGFycC10YWJsZXMsIHdlIGNhbiBu
b3Qgb25seSBvYnRhaW4gQVJQIGVudHJpZXMgZm9yIGFuIGludGVyZmFjZSwgYnV0IGFsc28gb2J0
YWluIEFSUCBlbnRyaWVzIGZvciBhIFZQTiAodXNlIHZyZi1uYW1lIGFzIHRoZSBrZXkpLg0KDQoq
IERhdGEgcmVsYXRpbmcgdG8gYSBzcGVjaWZpYyBpbnRlcmZhY2Ugc2hvdWxkIGJlIGluc2lkZSAv
aW50ZXJmYWNlcy9pbnRlcmZhY2UgKGFuZCAtc3RhdGUpIChpZXRmLWludGVyZmFjZXMsIFJGQyA3
MjIzKSB3aGVyZSBpdCBpcyBwb3NzaWJsZSBhbmQgcmVsZXZhbnQuDQogIEkgZG9uJ3Qgc2VlIGFu
eSByZWFzb24gdG8gaGF2ZSBhIGNvbXBsZXRlbHkgc2VwYXJhdGUgbGlzdCB3aXRoIGEgbGVhZnJl
ZiBhcyBhIGtleSwgd2hlbiB5b3UgY291bGQgdXNlICdhdWdtZW50JyB0byBoYXZlIHRoZSBkYXRh
IGFzIHBhcnQgb2YgdGhlIGludGVyZmFjZSBpdHNlbGYuDQoNCiAgRFhKPj4gR29vZCBwb2ludC4g
V2UgdGFrZSB5b3VyIHN1Z2dlc3Rpb24uICdhdWdtZW50JyBjYW4gYmUgdXNlZCB0byByZWZhY3Rv
ciB0aGUgbW9kdWxlIG9mIHBvc3NpYmxlIC8gaW50ZXJmYWNlcyAvIGludGVyZmFjZSBpbiBSRkMg
NzIyMy4NCg0KKiBBUlAgYXMgYSBmZWF0dXJlIGlzIG5vdCBkZXBlbmRlbnQgb24gVlJGcywgYnV0
IGltcGxlbWVudGluZyB0aGlzIG1vZHVsZSByZXF1aXJlcyB0aGUgc2VydmVyIHRvIGFsc28gaW1w
bGVtZW50IGlldGYtbmV0d29yay1pbnN0YW5jZXMuDQogIElmIHRoZSBBUlAtcmVsYXRlZCBkYXRh
IHdhcyB1bmRlciAvaW50ZXJmYWNlcygtc3RhdGUpIHRoZW4gdGhpcyBkcmFmdCB3b3VsZG4ndCBu
ZWVkIHRvIHJlbHkgb24gaWV0Zi1uZXR3b3JrLWluc3RhbmNlcy4NCiAgVGhlIG5ldHdvcmstaW5z
dGFuY2VzIGRyYWZ0IGFscmVhZHkgdGFrZXMgY2FyZSBvZiBtYWtpbmcgc3VyZSBlYWNoIFZSRiBo
YXMgYSBzZXBhcmF0ZSBsaXN0IG9mIGludGVyZmFjZXMuDQoNCiAgRFhKPj4gR29vZCBwb2ludC4g
QXMgZGlzY3Vzc2VkIGluIHRoZSBmaXJzdCBwYXJ0LCB2cmYgcmVsYXRlZCBlbnRyeSBpcyBkZWxl
dGVkIGluIC8gYXJwIC8gYXJwLXN0YXRpYy10YWJsZXMuDQoNCkFsZXgNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNA
aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBkaW5neGlhb2ppYW4gKEEpIDxkaW5neGlhb2ppYW4xQGh1
YXdlaS5jb20+DQpTZW50OiBUaHVyc2RheSwgMjYgT2N0b2JlciAyMDE3IDEwOjI3IHAubS4NClRv
OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJl
OiBbbmV0bW9kXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRpbmctbmV0bW9k
LWFycC15YW5nLW1vZGVsLTAwLnR4dA0KDQpIaSBhbGwsDQoNClRoZSBBUlAgWUFORyBtb2R1bGUg
ZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGhhcyBjb21tb24gcHJvcGVydGllcyB0aGF0IG5lZWQg
dG8gYmUgY29uZmlndXJlZC4NCkl0IHByb3ZpZGVzIGZyZWVkb20gZm9yIHNlcnZpY2UgcHJvdmlk
ZXJzIHRvIGFkYXB0IHRoaXMgZGF0YSBtb2RlbCB0byBkaWZmZXJlbnQgcHJvZHVjdCBpbXBsZW1l
bnRhdGlvbnMuDQoNClBsZWFzZSBoYXZlIGEgbG9vayBhbmQgcHJvdmlkZSBjb21tZW50cyBvbiB0
aGUgbGlzdC4NClRoYW5rcywNCg0KWGlhb2ppYW4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg
ZHJhZnQtZGluZy1uZXRtb2QtYXJwLXlhbmctbW9kZWwtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNz
ZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9qaWFuIERpbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy
ZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtZGluZy1uZXRtb2QtYXJwLXlhbmct
bW9kZWwNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIFlBTkcgRGF0YSBNb2Rl
bCBmb3IgQVJQDQpEb2N1bWVudCBkYXRlOiAgMjAxNy0xMC0yNg0KR3JvdXA6ICAgICAgICAgIElu
ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDE2DQpVUkw6ICAgICAgICAgICAg
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRpbmctbmV0bW9kLWFy
cC15YW5nLW1vZGVsLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWRpbmctbmV0bW9kLWFycC15YW5nLW1vZGVsLw0KSHRtbGl6ZWQ6
ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kaW5nLW5ldG1vZC1hcnAt
eWFuZy1tb2RlbC0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2h0bWwvZHJhZnQtZGluZy1uZXRtb2QtYXJwLXlhbmctbW9kZWwtMDANCg0KDQpBYnN0
cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCB0byBkZXNj
cmliZSBBZGRyZXNzDQogICBSZXNvbHV0aW9uIFByb3RvY29sIChBUlApIGNvbmZpZ3VyYXRpb25z
LiAgSXQgaXMgaW50ZW5kZWQgdGhpcyBtb2RlbA0KICAgYmUgdXNlZCBieSBzZXJ2aWNlIHByb3Zp
ZGVycyB3aG8gbWFuaXB1bGF0ZSBkZXZpY2VzIGZyb20gZGlmZmVyZW50DQogICB2ZW5kb3JzIGlu
IGEgc3RhbmRhcmQgd2F5Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg
Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo
dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu
DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Tue Oct 31 23:36:58 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F4113FDCC for ; Tue, 31 Oct 2017 23:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_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=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 H-iXVAIjiwm6 for ; Tue, 31 Oct 2017 23:36:54 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0123.outbound.protection.outlook.com [104.47.37.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC63513FDC6 for ; Tue, 31 Oct 2017 23:36:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I8QTxN7qkL1a8WSsxTXVbqMyO+UETzzBSDY0+Yj1o/Q=; b=Msf3eHFrlsr6Uu7jkh0uswPT7lBhekXCkicU95JmcI7qJIOrqLax119+tr3XxjqRxZBBC1V3a1ryrbRP4J95oCp0CMyQbmD+KhBZcmJlh74/Ovy/SsOI9QeDalt/LSwfxHtaLZDFM/W5eiGTQoRTvYbjWgxOYEVUoD9pwGdEVkc=
Received: from SN1PR05CA0037.namprd05.prod.outlook.com (10.163.68.175) by BLUPR0501MB2065.namprd05.prod.outlook.com (10.164.23.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Wed, 1 Nov 2017 06:36:53 +0000
Received: from DM3NAM05FT042.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::200) by SN1PR05CA0037.outlook.office365.com (2a01:111:e400:5197::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.197.4 via Frontend Transport; Wed, 1 Nov 2017 06:36:53 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT042.mail.protection.outlook.com (10.152.98.156) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.197.9 via Frontend Transport; Wed, 1 Nov 2017 06:36:53 +0000
Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 31 Oct 2017 23:36:36 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id vA16aXUH029261; Tue, 31 Oct 2017 23:36:34 -0700	(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 vA16aW1S027622;	Wed, 1 Nov 2017 02:36:32 -0400 (EDT)	(envelope-from phil@juniper.net)
Message-ID: <201711010636.vA16aW1S027622@idle.juniper.net>
From: Phil Shafer 
To: Robert Wilton 
CC: Kent Watsen , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27620.1509518191.1@idle.juniper.net>
Date: Wed, 1 Nov 2017 02:36:31 -0400
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(346002)(376002)(2980300002)(199003)(189002)(86362001)(6916009)(2810700001)(106466001)(50986999)(8936002)(478600001)(54356999)(105596002)(8676002)(76506005)(53416004)(81156014)(23726003)(68736007)(356003)(77096006)(229853002)(1076002)(69596002)(81166006)(316002)(8276002)(2906002)(189998001)(46406003)(305945005)(4326008)(16586007)(47776003)(97756001)(6246003)(2950100002)(7126002)(54906003)(53936002)(5660300001)(50466002)(7696004)(97736004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2065; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT042; 1:Pime64+mCm7hgzh1r6wb1Z/Ngr5DFwUyrJj1t57O3O9GtuGN/xoeGzB9BVtpNC6D3zNiYSkns9iSGtXSBplbwzVCxLNRTKTu+MvIjupCygAaoUknG3Val8Be94ksm96z
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4446d3e4-cc19-4057-409c-08d520f2f093
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:BLUPR0501MB2065; 
X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2065; 3:W+i4g+byHUc+3lz/p5+E0DL9vbm75S66SZAQrWR8qJdXjXjCvPOGKyOVJUzREHjES+u3boy9FZbqmzrZHRzeKnZLEkhBoRQ4r9yKL9ysnktOSqDixQJ0nZ6siZb6iCz/dPYvfcA4kgLwboDdIuz+Xky9kKaFj6K8l5uKax3dEODKIDMAZ2YZ5ZjOt2gpSdnZAxi9w2OPhU82F6rTkenucOV5xoSDk0o1pVyTcyG0OuT6TYZBMn+Zc7jQl3QK7BW/bggyQ1GxvOxy9PZMI3DtCXaXcDmLTVnaE0xizLwFUrelZpb5Pzl7JTUA/HO6VrjLX1kxesIZx3onYzNAxGop52drtvKImAGKYHPVHUgYhPc=; 25:5QNHltt4LhpxiODlTYlgWVj8GWmFWUQxZbkQXKAsPBvHUBAvo9+GM98/+wxq3nvxhOH/87EIDyYJllEzO0LV/gArnJZiuc/ggKWNL/+0lE93bQv7nTZ088YkcMgcdv69o5ap7/4aDXHH9KuL4RsjLx/9BuH9QxC5axGTBA/6m2lmsqNVcx5yLCryR50SlVmfsePgIcE89sgB4kieNZZtffiPFxMHXX8yAnlJQl8DyiB1AU4KbooqZX3ONIsDxJgA7keeG4XqLbmaDOVyvsUaLpSnklMVA83/vsrwrip6CFk6CEkLtubZAVHmN3mUUo4MXzihK95WAEiDfmEDQSKG9g==
X-MS-TrafficTypeDiagnostic: BLUPR0501MB2065:
X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2065; 31:3ry4hYzh5U1vXQLGZamYZyvSOakgxJB0U/rmCfTu5VJ8z+bDWvQGs2tx47Hc5QphNyaw4ZSQvVl+JKkqMHpPEvs/ebYiYMuSmIrHxmnmpSa7EAg3s41RKTH3pr8x1KHYimU5p0TyahIXC5dwf8kHuWO/jvNeaSWBRcGTTsEykRxlexS9mUjjN8Xtgqh9zHYZtAM4YFLXKIQZiwpm4BqDMs/oIj0Uf4mOz05Wla8VU+s=; 20:3xfSNx796JmK+0IY6hXXZW4wH5yuZOovCPVum1yI8Clr+RolPCv0lbjK8cqzMicEUKLoaaSTa2aUhRdGthkc9XF76PH/iDj7jZCrlQliHDibZqOSWNuSDCqC1770qvHyZ/LjhxCCr0iNyHjhUp1+9p70ECcTJNeATel8Gk2Q3NXNcXCBOHDQ3j+BO5p+/CnGulIYPCzkFSiAutP08hHbMuJiX+4N/ZstS+KCuHh0IbNB0XZRUZz0nGAii3DXXbnvkfCjFgXlMnSlee+Tc/vvfVuGgNlZ3jaz2E7F17+8nuXY3Tqa59pJdYALpHVJsxQsJJs78APc+Kp+dBdNgHv6niBsOf2yXsG/HpfOIIblGVzSQcnHnQxA3+gClxkJsCbzCuaW93j7kZ9CgbbaRjH4IZ9LI1JoaCJmRpMuAKkuVV1o/G4WwWYKdSqQA4uoBG9P6fDkcksLsV//A8fpQxw0VslIclv7t9BO0o41qT49NHOtUgEURkWMGsjroMdPtWrf
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(100000703101)(100105400095)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB2065; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB2065; 
X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2065; 4:q0xrLxOFtd8lgHltiukn73oVyehpKT9Ejwj2/ZiPn5xEJ5zxIWQm+8LWwXCXoL8ZXMdIkeiMecO4b8hNh/02ItAA/+G2yMM2RIUh+JWDQEXrwe7RnwRCsXwalIOgjE0et8rYsg/K0iE/pOn4KQQgHNo1ZHHT3frL//MQeZxNis4YtgDbzR2NGLqTpCZR2tH8EGPgFfkCAxptVz+LyaTxTaj9FZ4tay2tTZsI4bzNcVKkUl5Ho6tISYHvsCvzmRmLh05/xUe9Ww6bIyEQFP0Xiw==
X-Forefront-PRVS: 0478C23FE0
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB2065; 23:X/2kDL2LIGEv8sBjeMnbOhBIDsRk+Y5T8RraTkG?= =?us-ascii?Q?3mpGO7+ejHGb+UiASxul1qA7QOwg25mVxDcGkCmNICMhy8wa+lO8VM3+ZnOf?= =?us-ascii?Q?0YzLpvGs0eb21JT2NrukBRakgU8nUGst/NLgun2jnaZXTnfCxR7ia3pe9WAK?= =?us-ascii?Q?biLUkTF/gSuLdI8DhpYo7BtMzIwKfL1pvO/lFjoECm+V28CVztmpk2lTB40+?= =?us-ascii?Q?KMHLMB1XWThS1OgOPbALvSBNbetmSu99HZEP+bt2wO5JbhhsQ6Z/v7PRmRdj?= =?us-ascii?Q?oif+Zf0Dk1/QDTcoH6K/2oG4fGlnUxrvgNTwlJL5h0TQs7/lYit48dCxDNT5?= =?us-ascii?Q?LeC41yowyyZ7vCXV9KhYIA3iu3udS8vE0ApJ7tBUHk49oqsmf5CWvoWh7JZp?= =?us-ascii?Q?Wa3SsfEqmB2dW5w4847hATogABYEGP01GraemVI/SU9uRlN4PUdycaMKTRLq?= =?us-ascii?Q?6OuiZ+9ekuVwcH2F5lKCrgtW8esyIs1Chiauj9gHBWxvltoznWPYM3odAgM3?= =?us-ascii?Q?OLf88LHuCZnygi4/N8FPizE8k/HUhB5PC2Z5JjhNtyjEtpGCNIXhdjpyGmyq?= =?us-ascii?Q?rH74PgownO+rJvv+34d6qsSTt/0scpmInN5anFNDpNDFvLjy0toc0IRfUAHn?= =?us-ascii?Q?3MQCI7no153JmRf0uw39DvxSVtLAU55zRp51ukL7mU+ByQBBH5AVWT/IGQaz?= =?us-ascii?Q?jvg94LWNhgaQphP7CEumvriE0ZqGnHdWogSILVQtYnEdFLOtTrMRmy2cheV9?= =?us-ascii?Q?b/I9ef2LoVQKPV2jDqkRZs9epbF7iIaGw0+kWWKIvLmWdF0XBkYUYkfimR2/?= =?us-ascii?Q?mBWU3Kc3eHwG4cwALCcgfSwJiN/ZJMzr+w7ODrXjfjlZQ+nKXxChwnJkdWHt?= =?us-ascii?Q?WPyU+JLZc3qjT5Cabil8Q6og/TpEIPV9eqlXJupfuoyStcHiUNbqFqvJHLoO?= =?us-ascii?Q?vBHPl5a4ZOlXsstlAymXfu7UopnT3CYwSU9RDMdFWa95QNKkx7PDV+y5U+ab?= =?us-ascii?Q?DAdMChtA7y7KOQLZcy88ix/OUgkK53Rh3vh9SqNCePf+M+J7QUiPksm4byWB?= =?us-ascii?Q?xSbge39nrQEO17Hr1fk3b7VFYjlbE9aMOba8th7cc1WR4vI99UgQ2U8ROXU3?= =?us-ascii?Q?JROR8fQR6vEAS9aMY6QHrWhHFjkWpZ0YP4iQskuskKnTWk87VA320LJFTK6p?= =?us-ascii?Q?dAbr2gm5OCjMq8X4aERRNnbADizmC6w3A4VeD?=
X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2065; 6:78WR5ZO7r/D9rl7YgBThHZT0Z+wYM9TkUpRs80WsK26RVgmByXPYFovuu9igCR9W6n5+52HfpwjlJ7N4Mk0BpDGWftr2WuVMLkZHIcGzv/nzTFZ3qBMqU+js8ONnKdD7bGOaekgKy2Hgdez6ZI733R5glv1hbdPUvehH8n6wwp1vdQTxxRv14FtlszprG5JtDIihL1jQVf/27V+74ey7Z+o9CytoFjoNlpkpkQ9eK40Zr9jFMnlmv/1iOAf0rEYIhVpkzDRZhZAuO+FzlpsWf/eRCt6ucoKs5VV0CBmgNhjXps+sXIWw7ssy++gLP0PWQbYjkqWp/nIUcCVEuPx1Vz1Gy39o6CznylGGQ58f8x4=; 5:tKfY8NdY8Z9xUmLMiAAndyMubQJP2A/3dSRRxrfNZcZoi73wLteivicg9xcEC1P9sBOY4K7bXUUXTtr+qpVpTls9w1Yu8AKbLh/8wmxbiCSWgjf6ykmluO+5coYNilEYaiSytkov+PuVoI2H6hK0UxoGDzNdg4HU8xoY8jUL9l4=; 24:/tjyicYwAdqtsMmP8yzOt2sMYAhYLxf1QD4RyICl3xw6Yerb/GStiEj2E5xwORy1nNUnwAwHEHYdh9Ubs+M41KFsmkyVs2FuWnPd2L13A7M=; 7:j1WDohdiXF2+7yQgMC9Q8xRuWLzPGh2GiIyM2HDuyChDDIA8L+QQEdH4ZhdBjCqFNWcCHAGkZ3nN+hFsbdmTRhUjcuW6OZgfZgY3c8DXefXyArZKXG66UnkFvP/y3+45o4cxCKCu1DuCAPqyBtfeKJuBlJg3RnfUb2FPgHVMxbVALQTpMDFsquQBY0DqLE7PhfcLYaDAXtBFYonvdWPWFP12CFEVcpcFXAtl2GWayqLoF0P+efK45YxDPL2pUyzz
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2017 06:36:53.0024 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4446d3e4-cc19-4057-409c-08d520f2f093
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.12];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2065
Archived-At: 
Subject: Re: [netmod] Action and RPC statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Nov 2017 06:36:57 -0000

Robert Wilton writes:
>ii) However, as far as I can see, it doesn't make sense for an action to 
>directly affect the contents of any configuration datastore, that should 
>be done via a purpose built rpc (like edit-config).

An example action would be to retrieve the  fingerprint of an ssh
key.  I might want to get the fingerprint of a key in 
before I commit it.

Or I could have an action that sets the SNMPv3 auth key to a random
value, and I want to invoke that action against .

Seems like  might also be an interesting place to target
actions, but I can't think of a good example.

There are always scenarios where something is useful, and the problem
with ruling it out is that it becomes needed at some later point.
We've a habit of ruling out things and later wishing we had them.

Is the easy fix to just put a datastore leaf under rpc/action and
have it default to operational?  Any specific RPC can define its
own datastore leaf of hard-code the database in the description
(explicitly or implicitly ), but the  RPC only
gets this if we make a new parameter for it.

Thanks,
 Phil