From nobody Wed Nov 1 02:05: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 758D413F5D7 for ; Wed, 1 Nov 2017 02:05:10 -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 kPxRnl_y-QuM for ; Wed, 1 Nov 2017 02:05: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 B584113A902 for ; Wed, 1 Nov 2017 02:05:08 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C1A11AE03B5; Wed, 1 Nov 2017 10:05:06 +0100 (CET) Date: Wed, 01 Nov 2017 10:03:41 +0100 (CET) Message-Id: <20171101.100341.1185105458701011434.mbj@tail-f.com> To: jan.kundrat@cesnet.cz Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] YANG model for netowrk configuration of a device's 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: Wed, 01 Nov 2017 09:05:10 -0000 Hi, Jan Kundr=E1t wrote: > Hi, > I'm working on adding NETCONF support for configuring network on a fe= w > management interfaces of our product, a random network appliance. I > would prefer not to reinvent this particular wheel, so I started > searching for existing models. I was surprised that it seems that all= > vendors essentially go creative and appear to hack together something= > proprietary. > = > Our product has a pretty modern Linux system inside. It has three > network interfaces -- two gigabit RJ-45 ethernets, and one SFP > port. My goal is to offer an intuitive way of assigning static IPv4 o= r > IPv6 addresses, control whether DHCP/SLAAC are enabled, and perhaps > configuring one static VLAN on each of them. It would be amazing if I= > could bridge them together, or if there was a way of configuring, say= , > OSPF, but that comes secondary to 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= > - pre-provisioning features. > - RFC 7277, so that I can assign IPv4 and IPv6 addresses by hand. Goo= d. > - RFC 8022 for static route definitions. > = > However, I would also like to offer one toggle which enables an IPv4 > DHCP 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 it= s > - IPv6 brother, > - https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-04 . Wow. Wh= y > - is the DHCP client configuration done outside of the /if:interfaces= > - tree? So to summarize, it seems that you found published modules for what you were looking for, except for DHCP client configuration, for which you found one individual draft and one WG draft. I agree with your comment re. /if:interfaces. Since these documents are developed in the DHC WG, I suggest you send your comments to them, and hopefully you will be able to contribute to better models! /martin > = > - https://tools.ietf.org/html/draft-faq-netmod-cpe-yang-profile-01 > - refers 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 because it mentions a "dhcp-client" within the /if:interfaces > - tree. However, it does not define how that node looks like! > = > At this point I begin to understand why vendors unleash their > creativity when it comes to assigning IP addresses to management > interfaces of their boxes :(. However, I would prefer to just use > whatever is most common here, and focus on the application-specific > YANG model. Is there something that I can use as-is? I would hate to > implement 1000th version of this task... > = > With kind regards, > Jan > = > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Wed Nov 1 03:43: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 39BC813F6F3 for ; Wed, 1 Nov 2017 03:43:52 -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 ocqld3koP4J5 for ; Wed, 1 Nov 2017 03:43:49 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 B591F13B10E for ; Wed, 1 Nov 2017 03:43:49 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id i38so5087218iod.2 for ; Wed, 01 Nov 2017 03:43:49 -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=k/zbTyXS6H/pwrdO9E7kBHpVeCKeBWNPFv7NnorDJJE=; b=qM6G1VdEwmVr+lrRpfCZAxnxvZ4QvT2Zvp2eo2a090kqaDY2wMtTdKlDyHVaG4PkUQ NbD6+SdWuiL46EOdGeqYI+aoANRV4dXygv/5EiFrZOjEJGPENgn0sdnfQoIMVbxEcyu7 Mlc9v5/sI4JCOVf6NO8iLoURASs0joSCwZgKqmgJIYhm1dp30RHkRl2Pm3MXrI500Zd0 EDzFCiMAHHWWl9Bbqd84xXo5n4lEkM0+ZTDpB+iNHsiPi99zQEgu5YnQdNCt+/88Z4a+ SUM8mVyOf0w/9c3e9K+LbYYh32CNvnxCmeay2HHo32nlFrB6sUbn3PSauLh3/PSUf1Mb 8GTg== 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=k/zbTyXS6H/pwrdO9E7kBHpVeCKeBWNPFv7NnorDJJE=; b=UuYrfn5e6MpCQaM+fy/AHKppVDgs0mmmqrPjUp+A3S2sSV6FktYVhfVpxJqm4UljbJ BMaVUSSCw4Q8wcp6N2K898720x/GNCUFryfAuEuWgLo+7ca4joO1GSYHEwQE/DDRgcPw VczetKYU6dhZ+o7+NCmvhB2WE7//mVi9MLnYLoVQEOvECFPJ2a3i0/eNT3Nm8O//yzYm ZAK3tF+bt4RD+JQi4zGnEc+d7ZgcGoh1XC3lyNkxkH4BInnORFViky1XlH492mpB7Dp+ Hkx8vWV35Jw+KYPy8jpcsfeNTiuNqsyU2xAZVTh32g/uIBWeq0d6nbgHsE/9EbM2MoxD M/Nw== X-Gm-Message-State: AMCzsaWNONWogMF2pCfFUxCyZgXZscF6tVuTsoocgac3IgWfDUYMiZrA DMrx9Fo8PxAo5AJG05O/fhgqfeH1 X-Google-Smtp-Source: ABhQp+QT3UgRt8sXemyM1wN/kahOh+jQIfCMmDM03M5jeyr0gYXSPNlJOKJOzeFA0cGcD9vuO+O+VQ== X-Received: by 10.107.199.132 with SMTP id x126mr6308088iof.264.1509533028775; Wed, 01 Nov 2017 03:43:48 -0700 (PDT) Received: from [192.168.99.103] ([103.42.216.254]) by smtp.gmail.com with ESMTPSA id p17sm109275iod.40.2017.11.01.03.43.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Nov 2017 03:43:47 -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: <20171031102523.GB25608@spritelink.se> Date: Wed, 1 Nov 2017 17:13:18 +0630 Cc: "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> To: Kristian Larsson 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: Wed, 01 Nov 2017 10:43:52 -0000 Kristian, I think there is confusion in how the ACL model is going to be = implemented by vendors and used by customers. As Eliot alluded to, the model is trying to address the issue of the = capabilities of each platform as they exist across the industry but also = within each vendor. So the first thing an implementation would do is to = pick which feature they do support. A low end platform that supports = only layer 2 ACL will pick l2-acl as their feature, while a high end = router capable of support l2 and l3, ipv4 and ipv6 ACL will declare = l2-l3-ipv4-ipv6 as the feature they support. That pretty much takes out = all the other containers in the matches container. The additional = features they might want to choose include support for TCP, UDP and = ICMP. For a high end router this boils down to having definitions for - ethernet - ipv4 - ipv6 - tcp - udp - icmp which is the list you have in mind, but this time making sure that the = platform is capable of supporting each one of the definitions. Imagine = if the low end platform advertised a model for all the above = capabilities only to reject them when you tried to configure a ipv6 = address that it already knows it cannot support. Similarly the condition on tcp/udp/icmp container is to make sure the = platform is capable of supporting them. Only if the platform declares = tcp-acl, udp-acl, and icmp-acl feature, will those containers be visible = from a configuration perspective. The acl-type is used as a check to make sure the user is aware what kind = of ACL the platform supports and the ACL they are trying to configure = matches the acl-type. If the platform declared the feature l2-acl and if = the user tries to set the ACL type to l2-l3-ipv4-ipv6 then the = configuration would be rejected. In the Linux/nftables case, the = platform should declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, = and icmp-acl if that is what it wants to support. The interface = attachment point has been defined but it is not mandatory that a = configuration has to define it. So if in Linux, the ACL list is global, = one would not define a attachment point, which implies it is a global = list. I will take a look at the remaining issues/comments you raise, but I = wanted to make sure that the overall design of the model was clear, = which from this email I can only guess could be made more clear. Cheers. > On Oct 31, 2017, at 4:55 PM, Kristian Larsson = wrote: >=20 > On Fri, Oct 20, 2017 at 09:37:04PM +0000, Kent Watsen wrote: >>=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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 >=20 > 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. >=20 > The ipv4 container is conditioned on the acl-type being one of > ipv4-acl, l2-l3-ipv4-acl, l2-l3-ipv4-ipv6-acl. >=20 > The ipv6 container is conditioned on the acl-type being one of > ipv6-acl, l2-l3-ipv6-acl, l2-l3-ipv4-ipv6-acl. >=20 > 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. >=20 > 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=3Dtcp/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. >=20 >=20 > 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? >=20 > 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. >=20 >=20 > 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. >=20 >=20 >=20 > 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=3Ddrop > * 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. >=20 > Again, apologies for my ignorance. >=20 > Kind regards, > Kristian. >=20 >=20 > --=20 > Kristian Larsson KLL-RIPE > +46 704 264511 kll@spritelink.net >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Nov 1 04: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 66A8713F4D1 for ; Wed, 1 Nov 2017 04:24:22 -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 aZKt_xF8C873 for ; Wed, 1 Nov 2017 04:24: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 7E67B13AF23 for ; Wed, 1 Nov 2017 04:24: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 4ED5FF78; Wed, 1 Nov 2017 12:24:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id G1x5jv5Gr_vU; Wed, 1 Nov 2017 12:24:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Nov 2017 12:24:18 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3199D20111; Wed, 1 Nov 2017 12:24:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V6CWuDMfcTOp; Wed, 1 Nov 2017 12:24:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99B0220110; Wed, 1 Nov 2017 12:24:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B01E54146CB4; Wed, 1 Nov 2017 12:22:49 +0100 (CET) Date: Wed, 1 Nov 2017 12:22:49 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Cc: Kristian Larsson , "netmod@ietf.org" Message-ID: <20171101112249.wmq4ggx2ixgn4kqo@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mahesh Jethanandani , Kristian Larsson , "netmod@ietf.org" References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> 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-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, 01 Nov 2017 11:24:22 -0000 Mahesh, I think the question is why we need to have different match containers for each possible feature set combination instead of having a single match container with groups of leafs in it marked as features. This would seem to cut down the size of the module and the tree diagram significantly. I think this will also make clients simpler sicne they do not have to select a certain container based on the feature set announced. BTW, how do I filter on TCP flags in combination with a source IP address? There seem to be reasonable combinations of features not even covered. /js On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote: > Kristian, > > I think there is confusion in how the ACL model is going to be implemented by vendors and used by customers. > > As Eliot alluded to, the model is trying to address the issue of the capabilities of each platform as they exist across the industry but also within each vendor. So the first thing an implementation would do is to pick which feature they do support. A low end platform that supports only layer 2 ACL will pick l2-acl as their feature, while a high end router capable of support l2 and l3, ipv4 and ipv6 ACL will declare l2-l3-ipv4-ipv6 as the feature they support. That pretty much takes out all the other containers in the matches container. The additional features they might want to choose include support for TCP, UDP and ICMP. For a high end router this boils down to having definitions for > > - ethernet > - ipv4 > - ipv6 > - tcp > - udp > - icmp > > which is the list you have in mind, but this time making sure that the platform is capable of supporting each one of the definitions. Imagine if the low end platform advertised a model for all the above capabilities only to reject them when you tried to configure a ipv6 address that it already knows it cannot support. > > Similarly the condition on tcp/udp/icmp container is to make sure the platform is capable of supporting them. Only if the platform declares tcp-acl, udp-acl, and icmp-acl feature, will those containers be visible from a configuration perspective. > > The acl-type is used as a check to make sure the user is aware what kind of ACL the platform supports and the ACL they are trying to configure matches the acl-type. If the platform declared the feature l2-acl and if the user tries to set the ACL type to l2-l3-ipv4-ipv6 then the configuration would be rejected. In the Linux/nftables case, the platform should declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and icmp-acl if that is what it wants to support. The interface attachment point has been defined but it is not mandatory that a configuration has to define it. So if in Linux, the ACL list is global, one would not define a attachment point, which implies it is a global list. > > I will take a look at the remaining issues/comments you raise, but I wanted to make sure that the overall design of the model was clear, which from this email I can only guess could be made more clear. > > Cheers. > > > On Oct 31, 2017, at 4:55 PM, Kristian Larsson wrote: > > > > 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 > > > > _______________________________________________ > > 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 -- 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 Nov 1 04:24: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 CD03E13F6FE for ; Wed, 1 Nov 2017 04:24:45 -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 AqLiUZkbIlt9 for ; Wed, 1 Nov 2017 04:24:44 -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 6687313F701 for ; Wed, 1 Nov 2017 04:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2652; q=dns/txt; s=iport; t=1509535482; x=1510745082; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=KFCQdGIhvf0bF7mQTVdNTZLrA2y5wkXaSHSi4dzCIFk=; b=Modb93adkIuKIP9WulfdPzAkXBwgzH9z04H6/Zn+gnLAGzGTrb2o99me 2ggxKzoq4r3Fz2ti41haaL4eg2qFuDiy13HCyuPaY2urGmQVv/ZkKgUgT 2S6g+rM66GqP7wtIqH5X97+R3LuNsqDDSfTGZpTxHQu64cVQo3BbYMdCl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7AAAWrvlZ/xbLJq1cDgwBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYUxhCSKH3SQIJZDghEKhTsChTsYAQIBAQEBAQEBayiFHQEBAQMBIw8?= =?us-ascii?q?BBVELGAICJgICVwYBDAgBAYoXCKg8gieEFQGGeQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR2BD4Ifg1qCEoJMNYgmgmEFogqUfIt2hzqOJ4dsgTkfOFyBEDQhCB0Vgy6?= =?us-ascii?q?EHwQBOkGNIwEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,327,1505779200"; d="scan'208";a="655799396" 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; 01 Nov 2017 11:24:40 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA1BOdDk004237; Wed, 1 Nov 2017 11:24:39 GMT To: Phil Shafer , Kent Watsen , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn References: <201711010636.vA16aW1S027622@idle.juniper.net> From: Robert Wilton Message-ID: Date: Wed, 1 Nov 2017 11:24:39 +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: <201711010636.vA16aW1S027622@idle.juniper.net> 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: Wed, 01 Nov 2017 11:24:46 -0000 On 01/11/2017 06:36, Phil Shafer wrote: > 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. Yes, I have this concern. > > 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. I think that an action/rpc statement should indicate in the schema where its input/output arguments are resolved against.  I.e. "configuration", "state", or "client-provided".  This would be specified by a new optional "resolve-to" YANG sub-statement to action/rpc, that defaults to "state" if not specified. (i) Actions/rpcs that "resolve-to state" would resolve against (the default behaviour). (ii) Actions/rpcs that "resolve-to configuration" would probably resolve against . (iii) Actions/rpcs that "resolve-to client-provided" would require that an explicit datastore be specified as an input parameter to the action/rpc. Actions of type "resolve-to client-provided" would be required to be invoked with a new RPC that has a new target datastore input parameter. RPCs of type "resolve-to client-provided" would be required to have an input parameter named "datastore" that is a leafref to a datastore. Finally, I would propose that we defer defining the new "resolved-to" YANG statement and RPC to YANG/NETCONF/RESTCONF 2.0, so that for the moment actions/rpcs always resolve against because that will be the default behaviour today, but with the understanding that this could be extended in future. Thanks, Rob > > Thanks, > Phil > . > From nobody Wed Nov 1 04:42: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 AE25F13F706 for ; Wed, 1 Nov 2017 04:42:49 -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 cGpsgpiU7b4W for ; Wed, 1 Nov 2017 04:42:47 -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 7DADF13F703 for ; Wed, 1 Nov 2017 04:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29219; q=dns/txt; s=iport; t=1509536566; x=1510746166; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=9oLs9fH3m96fMAUwHqnrAh6PRofxF60xwxqOeTfJyjk=; b=OnLNIR4EAOSvIq3gmdJ45vKBITHYb2nvRJ+KGaplok77A9g8xLONrP28 h0OuMqgS8eXvT+5Bj+xdfuURCpxHzPvmYYzgP8jvie0FsVpsHlZ7YRoEb p3GnLnnB3RbSQQfYhts5vglvVLjowCe4DeBi9Dxy4Yt8BhVARzXqqkGCV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADFsvlZ/xbLJq1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvQoESbieDfYofdJAglkOCDgMKGAEKhElPAoU7GAECAQEBAQE?= =?us-ascii?q?BAWsohR0BAQEDAQEBIQpBEAsJAhEEAQEBDRMBBgMCAicfCQgGAQwGAgEBihcIE?= =?us-ascii?q?IpCnWeCJyaDbwGGeQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgy6DWoFpKYMBhHt?= =?us-ascii?q?Mgl+CYQWZBIkGlHyLdoc6jieHbIE5HzhCgSo0IQgdFUmCZIQgBAE6QTaKKyyCF?= =?us-ascii?q?gEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,327,1505779200"; d="scan'208,217";a="655799679" 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; 01 Nov 2017 11:42:44 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA1BghUH007806; Wed, 1 Nov 2017 11:42:44 GMT To: Alexander Clemm , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn , Phil Shafer References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com> <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABACAD@sjceml521-mbx.china.huawei.com> From: Robert Wilton Message-ID: <4679d0f6-d884-e0a9-94de-0099735a1172@cisco.com> Date: Wed, 1 Nov 2017 11:42:43 +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: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABACAD@sjceml521-mbx.china.huawei.com> Content-Type: multipart/alternative; boundary="------------FECE63FACC8B2118F3332CBB" 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: Wed, 01 Nov 2017 11:42:49 -0000 This is a multi-part message in MIME format. --------------FECE63FACC8B2118F3332CBB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Alex, On 31/10/2017 17:36, Alexander Clemm wrote: > > Hi Rob, > > A few comments, inline > > --- Alex > > *From:*netmod [mailto:netmod-bounces@ietf.org] *On Behalf Of *Robert > Wilton > *Sent:* Tuesday, October 31, 2017 7:14 AM > *To:* Martin Bjorklund ; andy@yumaworks.com; > netmod@ietf.org; Randy Presuhn > *Subject:* Re: [netmod] Action and RPC statements > > 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. > > why “e.g., ”?  Does affect the contents of > the datastore – I thought it just gets data, hence this example is not > ideal. > > There is also no mention about the source of the “in” parameters.  It > probably makes sense to mention that explicitly. > > Perhaps something along the lines of “RPCs MAY be defined as > _/relating/_ to the contents of a specific datastore….   Input data > resolves to , as does output data, as do RPC side > effects“.  Then below > > “RPCs definitions that do not explicitly state an affected > datastore(s) _/refer_to/_  the general operational state of the server.” > Yes, that makes sense. > One other comment, it would be good to also indicate that when an RPC > leads to modification of data nodes, what the “origin” of those > modifications is. > That is an interesting question. To describe this as a concrete example, if you have a single config true YANG list for dynamic/configuration subscriptions then a subscription can be created either via configuration or as an RPC operation. I would probably classify this as "learned", and I think that we could extend the definition of the "learned" origin to cover this case. Thanks, Rob > > > > > 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 > > . > --------------FECE63FACC8B2118F3332CBB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Alex,


On 31/10/2017 17:36, Alexander Clemm wrote:

Hi Rob,

 

A few comments, inline

 

--- Alex

 

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: Tuesday, October 31, 2017 7:14 AM
To: Martin Bjorklund <mbj@tail-f.com>; andy@yumaworks.com; netmod@ietf.org; Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Subject: Re: [netmod] Action and RPC statements

 

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.

<ALEX> why “e.g., <get-data>”?  Does <get-data> affect the contents of the datastore – I thought it just gets data, hence this example is not ideal. 

There is also no mention about the source of the “in” parameters.  It probably makes sense to mention that explicitly. 

Perhaps something along the lines of “RPCs MAY be defined as _relating_ to the contents of a specific datastore….   Input data resolves to <operational>, as does output data, as do RPC side effects“.  Then below   

“RPCs definitions that do not explicitly state an affected
datastore(s) _refer_to_  the general operational state of the server.”

Yes, that makes sense.

 

One other comment, it would be good to also indicate that when an RPC leads to modification of data nodes, what the “origin” of those modifications is.

That is an interesting question.

To describe this as a concrete example, if you have a single config true YANG list for dynamic/configuration subscriptions then a subscription can be created either via configuration or as an RPC operation.

I would probably classify this as "learned", and I think that we could extend the definition of the "learned" origin to cover this case.

Thanks,
Rob


</ALEX>



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
.
 

 


--------------FECE63FACC8B2118F3332CBB-- From nobody Wed Nov 1 04:54: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 2B94C13A044 for ; Wed, 1 Nov 2017 04:54: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, 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 t7IY1Rc3XHAH for ; Wed, 1 Nov 2017 04:54:36 -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 7E67213942F for ; Wed, 1 Nov 2017 04:54:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 41090EF3; Wed, 1 Nov 2017 12:54:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 1yKnicp_6dDs; Wed, 1 Nov 2017 12:54:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Nov 2017 12:54:35 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B2BD20111; Wed, 1 Nov 2017 12:54:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gU3kERmbUncA; Wed, 1 Nov 2017 12:54:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DF6F20110; Wed, 1 Nov 2017 12:54:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 740C94146D55; Wed, 1 Nov 2017 12:53:08 +0100 (CET) Date: Wed, 1 Nov 2017 12:53:08 +0100 From: Juergen Schoenwaelder To: Robert Wilton Cc: Alexander Clemm , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn , Phil Shafer Message-ID: <20171101115308.gxgns54u6qdmxkx2@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Alexander Clemm , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn , Phil Shafer References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com> <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABACAD@sjceml521-mbx.china.huawei.com> <4679d0f6-d884-e0a9-94de-0099735a1172@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <4679d0f6-d884-e0a9-94de-0099735a1172@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: Wed, 01 Nov 2017 11:54:38 -0000 On Wed, Nov 01, 2017 at 11:42:43AM +0000, Robert Wilton wrote: > > > One other comment, it would be good to also indicate that when an RPC > > leads to modification of data nodes, what the “origin” of those > > modifications is. > > > That is an interesting question. > > To describe this as a concrete example, if you have a single config true > YANG list for dynamic/configuration subscriptions then a subscription can be > created either via configuration or as an RPC operation. > > I would probably classify this as "learned", and I think that we could > extend the definition of the "learned" origin to cover this case. I do not think any changes are needed, section 5.3.4 is pretty clear that the origin 'intended' applies to configuration provided by . If you at the options, there is pretty much only 'learned' applicable. /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 Nov 1 06:26: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 A998A13F501 for ; Wed, 1 Nov 2017 06:26: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 fO9mDpMxLupt for ; Wed, 1 Nov 2017 06:26:35 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id E188713942F for ; Wed, 1 Nov 2017 06:26:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 3C842261846; Wed, 1 Nov 2017 14:26:35 +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 UgbJmxztSdEZ; Wed, 1 Nov 2017 14:26:33 +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 084A6261838; Wed, 1 Nov 2017 14:26:33 +0100 (CET) Date: Wed, 1 Nov 2017 14:26:31 +0100 From: Kristian Larsson To: Mahesh Jethanandani Cc: "netmod@ietf.org" Message-ID: <20171101132631.GD25608@spritelink.se> References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Wed, 01 Nov 2017 13:26:38 -0000 Mahesh, On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote: > I think there is confusion in how the ACL model is going to be > implemented by vendors and used by customers. > > As Eliot alluded to, the model is trying to address the issue > of the capabilities of each platform as they exist across the > industry but also within each vendor. So the first thing an > implementation would do is to pick which feature they do > support. A low end platform that supports only layer 2 ACL will > pick l2-acl as their feature, while a high end router capable > of support l2 and l3, ipv4 and ipv6 ACL will declare > l2-l3-ipv4-ipv6 as the feature they support. That pretty much > takes out all the other containers in the matches container. > The additional features they might want to choose include > support for TCP, UDP and ICMP. For a high end router this boils > down to having definitions for > > - ethernet > - ipv4 > - ipv6 > - tcp > - udp > - icmp > > which is the list you have in mind, but this time making sure > that the platform is capable of supporting each one of the > definitions. Imagine if the low end platform advertised a model > for all the above capabilities only to reject them when you > tried to configure a ipv6 address that it already knows it > cannot support. You imply that the low end platform would advertise features that it doesn't support. Why would it do that? I don't suggest removing features - only restructure where the data is held. In my example, under the ethernet container I can do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the device supports a given feature so why are you saying that we need different containers for the ethernet matching part of an ACL of type eth-acl vs say eth-ipv4-acl? Right now the features themselves affect the structure of the model and thus the data, which I rather dislike. The config to match e.g. ethernet headers should always go in the same place. The model gives the illusion of supporting "unified" ACLs but actually doesn't at all. > Similarly the condition on tcp/udp/icmp container is to make > sure the platform is capable of supporting them. Only if the > platform declares tcp-acl, udp-acl, and icmp-acl feature, will > those containers be visible from a configuration perspective. And if the device supports all of those features I can write an ACE that matches on TCP flags at and ICMP types.. and it would validate according to the model but cleary makes no sense. > The acl-type is used as a check to make sure the user is aware > what kind of ACL the platform supports and the ACL they are > trying to configure matches the acl-type. If the platform > declared the feature l2-acl and if the user tries to set the > ACL type to l2-l3-ipv4-ipv6 then the configuration would be > rejected. Another way of structuring this is to have completely different lists of ACLs where each type of ACL is its own list, e.g. * eth-acl * ipv4-acl * ipv6-acl * eth-ipv4-ipv6-acl What advantage do you think your currently proposed model holds over such an approach? What are your thoughts on the attachment point using two leaves? Are you satisfied with this? > In the Linux/nftables case, the platform should > declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and > icmp-acl if that is what it wants to support. The interface > attachment point has been defined but it is not mandatory that > a configuration has to define it. So if in Linux, the ACL list > is global, one would not define a attachment point, which > implies it is a global list. Naturally one has to define an attachment point or the system wouldn't know which one of potentially multiple ACLs to apply to nftables. It might however be up to another YANG model to define that attachment point. The list of features seem to align poorly with reality. How can we have a list of attachment points in the model but without if-feature wrapping it? Surely a Linux machine must be able to announce that it doesn't support per-interface ACLs? A side question is why that attachment list exists in the first place - why isn't it an augmentation of the interfaces module? kll -- Kristian Larsson KLL-RIPE +46 704 264511 kll@spritelink.net From nobody Wed Nov 1 06:58: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 BB4AC13F46E for ; Wed, 1 Nov 2017 06:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gUr_1GBlZazB for ; Wed, 1 Nov 2017 06:58: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 F33AE13F3E6 for ; Wed, 1 Nov 2017 06:58:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id CEF0E1405F04; Wed, 1 Nov 2017 14:58:13 +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 6IQ0VfeqnMEQ; Wed, 1 Nov 2017 14:58:13 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9F7261405FAB; Wed, 1 Nov 2017 14:58:13 +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 MJomef_SHb4Q; Wed, 1 Nov 2017 14:58:13 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 762A81405FA8; Wed, 1 Nov 2017 14:58:13 +0100 (CET) From: Vladimir Vassilev To: Martin Bjorklund , jan.kundrat@cesnet.cz References: <20171101.100341.1185105458701011434.mbj@tail-f.com> Cc: netmod@ietf.org Message-ID: <9e8ff3a9-eed5-72d9-1621-e9a5fca922c6@transpacket.com> Date: Wed, 1 Nov 2017 14:58:13 +0100 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: <20171101.100341.1185105458701011434.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] YANG model for netowrk configuration of a device's 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: Wed, 01 Nov 2017 13:58:19 -0000 On 11/01/2017 10:03 AM, Martin Bjorklund wrote: > Hi, > > Jan Kundr=E1t wrote: >> Hi, >> I'm working on adding NETCONF support for configuring network on a few >> management interfaces of our product, a random network appliance. I >> would prefer not to reinvent this particular wheel, so I started >> searching for existing models. I was surprised that it seems that all >> vendors essentially go creative and appear to hack together something >> proprietary. >> >> Our product has a pretty modern Linux system inside. It has three >> network interfaces -- two gigabit RJ-45 ethernets, and one SFP >> port. My goal is to offer an intuitive way of assigning static IPv4 or >> IPv6 addresses, control whether DHCP/SLAAC are enabled, and perhaps >> configuring one static VLAN on each of them. It would be amazing if I >> could bridge them together, or if there was a way of configuring, say, >> OSPF, but that comes secondary to 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 >> - 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 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 brother, >> -https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-04 . Wow. Why >> - is the DHCP client configuration done outside of the /if:interfaces >> - tree? > So to summarize, it seems that you found published modules for what > you were looking for, except for DHCP client configuration, for which > you found one individual draft and one WG draft. I agree with your > comment re. /if:interfaces. Since these documents are developed in > the DHC WG, I suggest you send your comments to them, and hopefully > you will be able to contribute to better models! +1 The design of a ietf-dhcp(v4) and ietf-dhcpv6 modules must have=20 "something" in common. I get it that the DHC WG is concentrated on v6=20 but v4 is what is a mandatory requirement if there will be any point in=20 implementing the ietf model. > > > /martin > > > > >> -https://tools.ietf.org/html/draft-faq-netmod-cpe-yang-profile-01 >> - refers 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 because it mentions a "dhcp-client" within the /if:interfaces >> - tree. However, it does not define how that node looks like! >> >> At this point I begin to understand why vendors unleash their >> creativity when it comes to assigning IP addresses to management >> interfaces of their boxes :(. However, I would prefer to just use >> whatever is most common here, and focus on the application-specific >> YANG model. Is there something that I can use as-is? I would hate to >> implement 1000th version of this task... >> >> With kind regards, >> Jan >> >> _______________________________________________ >> 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 Nov 1 08:58: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 1D10F13F742 for ; Wed, 1 Nov 2017 08:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 StVYA09GdLuI for ; Wed, 1 Nov 2017 08:58:04 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id E34E213F781 for ; Wed, 1 Nov 2017 08:58:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 65149261846; Wed, 1 Nov 2017 16:58:03 +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 BUY1jmLCKOGg; Wed, 1 Nov 2017 16:58:00 +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 C4EC0261838; Wed, 1 Nov 2017 16:58:00 +0100 (CET) Date: Wed, 1 Nov 2017 16:57:58 +0100 From: Kristian Larsson To: Mahesh Jethanandani Cc: "netmod@ietf.org" Message-ID: <20171101155758.GB12688@spritelink.se> References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <20171101132631.GD25608@spritelink.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171101132631.GD25608@spritelink.se> 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: Wed, 01 Nov 2017 15:58:07 -0000 I think there's a problem with the current approach for features where it conflates the limitations of the device with the limitations of an attachment point. Ultimately it is the limitations of the attachment point that matter. Creating an ACL in config on a device doesn't actually mean anything until you attach it somewhere. It's not hard to imagine a device where different limitations apply, let's say a fairly simple Ethernet switch built on some commodity chip. It consists of, say: * 24 * 10GE on a commodity chip * some control plane (a x86 PC) connected to that commodity chip The commodity chip supports matching ethernet headers, so ACLs attached to those ports are "eth-acl". The control plane on the other hand supports complex matching on anything you can imagine. What YANG features should such a device advertise? kll On Wed, Nov 01, 2017 at 02:26:31PM +0100, Kristian Larsson wrote: > Mahesh, > > On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote: > > I think there is confusion in how the ACL model is going to be > > implemented by vendors and used by customers. > > > > As Eliot alluded to, the model is trying to address the issue > > of the capabilities of each platform as they exist across the > > industry but also within each vendor. So the first thing an > > implementation would do is to pick which feature they do > > support. A low end platform that supports only layer 2 ACL will > > pick l2-acl as their feature, while a high end router capable > > of support l2 and l3, ipv4 and ipv6 ACL will declare > > l2-l3-ipv4-ipv6 as the feature they support. That pretty much > > takes out all the other containers in the matches container. > > The additional features they might want to choose include > > support for TCP, UDP and ICMP. For a high end router this boils > > down to having definitions for > > > > - ethernet > > - ipv4 > > - ipv6 > > - tcp > > - udp > > - icmp > > > > which is the list you have in mind, but this time making sure > > that the platform is capable of supporting each one of the > > definitions. Imagine if the low end platform advertised a model > > for all the above capabilities only to reject them when you > > tried to configure a ipv6 address that it already knows it > > cannot support. > > You imply that the low end platform would advertise features that > it doesn't support. Why would it do that? > > I don't suggest removing features - only restructure where the > data is held. In my example, under the ethernet container I can > do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the > device supports a given feature so why are you saying that we > need different containers for the ethernet matching part of an > ACL of type eth-acl vs say eth-ipv4-acl? > > Right now the features themselves affect the structure of the > model and thus the data, which I rather dislike. The config to > match e.g. ethernet headers should always go in the same place. > > The model gives the illusion of supporting "unified" ACLs but > actually doesn't at all. > > > > Similarly the condition on tcp/udp/icmp container is to make > > sure the platform is capable of supporting them. Only if the > > platform declares tcp-acl, udp-acl, and icmp-acl feature, will > > those containers be visible from a configuration perspective. > > And if the device supports all of those features I can write an > ACE that matches on TCP flags at and ICMP types.. and it would > validate according to the model but cleary makes no sense. > > > The acl-type is used as a check to make sure the user is aware > > what kind of ACL the platform supports and the ACL they are > > trying to configure matches the acl-type. If the platform > > declared the feature l2-acl and if the user tries to set the > > ACL type to l2-l3-ipv4-ipv6 then the configuration would be > > rejected. > > Another way of structuring this is to have completely different > lists of ACLs where each type of ACL is its own list, e.g. > * eth-acl > * ipv4-acl > * ipv6-acl > * eth-ipv4-ipv6-acl > > What advantage do you think your currently proposed model holds > over such an approach? > > What are your thoughts on the attachment point using two leaves? > Are you satisfied with this? > > > > In the Linux/nftables case, the platform should > > declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and > > icmp-acl if that is what it wants to support. The interface > > attachment point has been defined but it is not mandatory that > > a configuration has to define it. So if in Linux, the ACL list > > is global, one would not define a attachment point, which > > implies it is a global list. > > Naturally one has to define an attachment point or the system > wouldn't know which one of potentially multiple ACLs to apply to > nftables. It might however be up to another YANG model to define > that attachment point. > > The list of features seem to align poorly with reality. How can > we have a list of attachment points in the model but without > if-feature wrapping it? Surely a Linux machine must be able to > announce that it doesn't support per-interface ACLs? A side > question is why that attachment list exists in the first place - > why isn't it an augmentation of the interfaces module? > > kll > > -- > Kristian Larsson KLL-RIPE > +46 704 264511 kll@spritelink.net > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Kristian Larsson KLL-RIPE +46 704 264511 kll@spritelink.net From nobody Wed Nov 1 09:45: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 D3E5A13F70A for ; Wed, 1 Nov 2017 09:44:55 -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 xFyKMoGluovI for ; Wed, 1 Nov 2017 09:44:52 -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 A22F113F7D7 for ; Wed, 1 Nov 2017 09:44:47 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id a132so3224030lfa.7 for ; Wed, 01 Nov 2017 09:44: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=HpwkEkzzMmvzwCT2mocnThFI5E4kmoMe/hszpymXMxg=; b=vgVLwicb/6jPKgMs9knEA23H1zDLHeGbMP2U4AKLiIhwKecF2OkVDb8ZFIKRQWgmsY amgwkGrBBGrVhaphxeO/vCGMRskEGfyqydq19YnyZY12iTYKc9KVQBTPzArOzc/BSR6l mjRNWv6mge5895KgTAd+98MRQAlvON8ocvVGVbXJfT8Dssrzox+bLFLSl6xKhTaYI5wi gEmiuqvy6+q01ZZLwAn5f5/O0NeCEjSdMVdPLGbdMMHElcCoxLv4TpKZ+/XRmKO88l/k g0tch/Md4L25oYrnuiktIVE2TOX3CiEKTG8srjQpAzWjexmRj4pwESIhBwAnmE1oo68K CdoA== 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=HpwkEkzzMmvzwCT2mocnThFI5E4kmoMe/hszpymXMxg=; b=Co3G8lAmUzEitbrcfyWPM4LOTWcRP3dw8ZIQEn7TXnPxSD78UN8AS95Mx09TpyRvQr E9Olvsy6F38mN+9tonrv9bkdZH90PkWg8sbb2NeNZCmCfuRf1z2SUT4orReVw8uWH0nT vrJWmazJlM9xy2mzlXJaKZQdsVwFHzaWFuqydfgg1fWjVNAxW4ff4kdq6FzxLRklqTny hFZJyst4Dm3clLR2+yhdciqvNJNT6rAK7OapYGapCjwp5HjRt8R8gZ6R4aTfNCu7tw1N XdyXrKCT9acfUTtoGWlqRxgAJtNO5ofyeQB9TwhdAjg52N5UEoiAsLQeVOXGxItmHECE FJAA== X-Gm-Message-State: AJaThX42oU2kkyjJUghX8uSxMllhHOeXDYhHgBAd0g1g5feglAGlHN5e AXQJ05eclP6SRCZAwLum10LNjIRHyz5UhF/Z25ExsA== X-Google-Smtp-Source: ABhQp+TKJE+kvxvNYYSelieG3lxHH6SSHtoNp5JukAcTfjRhkV82nBxEDtxWfUvKTGU8vPX8iIq+qg6DrgVTvlhjsQc= X-Received: by 10.25.161.201 with SMTP id k192mr146719lfe.45.1509554685917; Wed, 01 Nov 2017 09:44:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.150.198 with HTTP; Wed, 1 Nov 2017 09:44:44 -0700 (PDT) In-Reply-To: <201711010636.vA16aW1S027622@idle.juniper.net> References: <201711010636.vA16aW1S027622@idle.juniper.net> From: Andy Bierman Date: Wed, 1 Nov 2017 09:44:44 -0700 Message-ID: To: Phil Shafer Cc: Robert Wilton , Kent Watsen , Martin Bjorklund , "netmod@ietf.org" , Randy Presuhn Content-Type: multipart/alternative; boundary="001a11411b0ad2d58d055cee96cb" 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 16:44:56 -0000 --001a11411b0ad2d58d055cee96cb Content-Type: text/plain; charset="UTF-8" Hi, So a server will be required to guess the correct datastore until it finds the right one that matches the action instance? 10 candidate The server will guess the datastore in some proprietary order and parse instances of /top/ and /top/list1. Then it finds the action and parses the input to get to the datastore and find out the real datastore to use. If the server guessed wrong, then it reparses the against the requested datastore. Hopefully the schema trees match up. Will vendors do all the extra work required to support this sort of thing? I doubt it. Andy On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer wrote: > 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 > --001a11411b0ad2d58d055cee96cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

So a server will be required to gue= ss the correct datastore until it
finds the right one that matche= s the action instance?

=C2=A0 =C2=A0<action>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate</datas= tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</do-= test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </list1>
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0 </a= ction>

The server will guess the datastore in s= ome proprietary order and parse
instances of /top/ and /top/list1= .=C2=A0 Then it finds the <do-test> action
and parses the i= nput to get to the datastore and find out the real datastore
to u= se.=C2=A0 If the server guessed wrong, then it reparses the <action> = against
the requested datastore.=C2=A0 Hopefully the schema trees= match up.

Will vendors do all the extra work requ= ired to support this sort of thing?
I doubt it.


Andy




On Tue, O= ct 31, 2017 at 11:36 PM, Phil Shafer <phil@juniper.net> wrote= :
Robert Wilton writes:
>ii) However, as far as I can see, it doesn't make sense for an acti= on to
>directly affect the contents of any configuration datastore, that shoul= d
>be done via a purpose built rpc (like edit-config).

An example action would be to retrieve the=C2=A0 fingerprint of an ssh
key.=C2=A0 I might want to get the fingerprint of a key in <candidate>= ;
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 <candidate>.

Seems like <startup> 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?=C2=A0 Any specific RPC can define its
own datastore leaf of hard-code the database in the description
(explicitly or implicitly <operational>), but the <action> RPC = only
gets this if we make a new parameter for it.

Thanks,
=C2=A0Phil

--001a11411b0ad2d58d055cee96cb-- From nobody Wed Nov 1 11:00: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 BA44713F9E6 for ; Wed, 1 Nov 2017 11:00:36 -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 SiYTkTp2dwgb for ; Wed, 1 Nov 2017 11:00: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 0851E13F9C5 for ; Wed, 1 Nov 2017 11:00:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRW02760; Wed, 01 Nov 2017 18:00:33 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 1 Nov 2017 18:00:31 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Wed, 1 Nov 2017 11:00:16 -0700 From: Alexander Clemm To: Juergen Schoenwaelder , "Robert Wilton" CC: Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn , Phil Shafer Thread-Topic: [netmod] Action and RPC statements Thread-Index: AQHTTv5c6Thnq3+sH0epzy6XUWpHDqL+fHIA///AowCAAadVgIAAAukA///vI+A= Date: Wed, 1 Nov 2017 18:00:15 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB25E@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> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABACAD@sjceml521-mbx.china.huawei.com> <4679d0f6-d884-e0a9-94de-0099735a1172@cisco.com> <20171101115308.gxgns54u6qdmxkx2@elstar.local> In-Reply-To: <20171101115308.gxgns54u6qdmxkx2@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.61] 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.0A020202.59FA0BC1.027E, 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: fa3987f3b39d45412b988ca8da762214 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 18:00:37 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQouLi4NCj4gPiBUaGF0IGlzIGFuIGludGVy ZXN0aW5nIHF1ZXN0aW9uLg0KPiA+DQo+ID4gVG8gZGVzY3JpYmUgdGhpcyBhcyBhIGNvbmNyZXRl IGV4YW1wbGUsIGlmIHlvdSBoYXZlIGEgc2luZ2xlIGNvbmZpZw0KPiA+IHRydWUgWUFORyBsaXN0 IGZvciBkeW5hbWljL2NvbmZpZ3VyYXRpb24gc3Vic2NyaXB0aW9ucyB0aGVuIGENCj4gPiBzdWJz Y3JpcHRpb24gY2FuIGJlIGNyZWF0ZWQgZWl0aGVyIHZpYSBjb25maWd1cmF0aW9uIG9yIGFzIGFu IFJQQyBvcGVyYXRpb24uDQo+ID4NCj4gPiBJIHdvdWxkIHByb2JhYmx5IGNsYXNzaWZ5IHRoaXMg YXMgImxlYXJuZWQiLCBhbmQgSSB0aGluayB0aGF0IHdlIGNvdWxkDQo+ID4gZXh0ZW5kIHRoZSBk ZWZpbml0aW9uIG9mIHRoZSAibGVhcm5lZCIgb3JpZ2luIHRvIGNvdmVyIHRoaXMgY2FzZS4NCj4g DQo+IEkgZG8gbm90IHRoaW5rIGFueSBjaGFuZ2VzIGFyZSBuZWVkZWQsIHNlY3Rpb24gNS4zLjQg aXMgcHJldHR5IGNsZWFyIHRoYXQgdGhlDQo+IG9yaWdpbiAnaW50ZW5kZWQnIGFwcGxpZXMgdG8g Y29uZmlndXJhdGlvbiBwcm92aWRlZCBieSA8aW50ZW5kZWQ+LiBJZiB5b3UgYXQNCj4gdGhlIG9w dGlvbnMsIHRoZXJlIGlzIHByZXR0eSBtdWNoIG9ubHkgJ2xlYXJuZWQnIGFwcGxpY2FibGUuDQo+ IA0KDQpJdCBtYXkgYmUgY2xlYXIgdGhhdCAiaW50ZW5kZWQiIG1heSBub3QgYmUgdGhlIHJpZ2h0 IGNob2ljZSwgYnV0IHdoYXQgaXM/ICBJIHRoaW5rIGl0IGRvZXMgbm90IGh1cnQgdG8gYmUgZXhw bGljaXQgYWJvdXQgaXQuICBUaGlzIHdheSwgcGVvcGxlIGRvbid0IGhhdmUgdG8gZ3Vlc3MgaWYg aXQgc2hvdWxkIGJlIGxlYXJuZWQsIG9yIG1heWJlIHN5c3RlbSwgb3IgcG9zc2libHkgZXZlbiB1 bmtub3duLiAgSW4gaXRzIGN1cnJlbnQgZGVmaW5pdGlvbiwgImxlYXJuZWQiIG9ubHkgdGFsa3Mg YWJvdXQgInByb3RvY29sIGludGVyYWN0aW9ucyB3aXRoIG90aGVyIHN5c3RlbXMgLi4uIHN1Y2gg YXMgcm91dGluZyBwcm90b2NvbHMsIERIQ1AsIGV0Yy4iIElmIGl0IGlzICJsZWFybmVkIiB0aGVu IHVwZGF0ZSBpdHMgZGVmaW5pdGlvbiB0byBzb21ldGhpbmcgbGlrZQ0KDQpsZWFybmVkOiByZXBy ZXNlbnRzIGNvbmZpZ3VyYXRpb24gdGhhdCBoYXMgYmVlbiBsZWFybmVkIHZpYQ0KICAgICAgcHJv dG9jb2wgaW50ZXJhY3Rpb25zIHdpdGggb3RoZXIgc3lzdGVtcywgaW5jbHVkaW5nIHByb3RvY29s cyBzdWNoDQogICAgICBhcyBsaW5rLWxheWVyIG5lZ290aWF0aW9ucywgcm91dGluZyBwcm90b2Nv bHMsIERIQ1AsIGV0Yywgb3IgYXMgYSBzaWRlIGVmZmVjdCBvZiBSUENzLiANCg0KLS0tIEFsZXgN Cg0K From nobody Wed Nov 1 11:31: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 525BB13FA2C for ; Wed, 1 Nov 2017 11:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, 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 kiWpsrjKeL5D for ; Wed, 1 Nov 2017 11:31:07 -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 2152B13943F for ; Wed, 1 Nov 2017 11:31:05 -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 DRW04745; Wed, 01 Nov 2017 18:31:03 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 1 Nov 2017 18:31:02 +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; Wed, 1 Nov 2017 11:30:57 -0700 From: Alexander Clemm To: Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn , "Phil Shafer" Thread-Topic: [netmod] Action and RPC statements Thread-Index: AQHTTv5c6Thnq3+sH0epzy6XUWpHDqL+fHIA///AowCAAadVgP///J9w Date: Wed, 1 Nov 2017 18:30:56 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB2BC@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> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABACAD@sjceml521-mbx.china.huawei.com> <4679d0f6-d884-e0a9-94de-0099735a1172@cisco.com> In-Reply-To: <4679d0f6-d884-e0a9-94de-0099735a1172@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.61] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABB2BCsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.59FA12E8.0044, 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: fa3987f3b39d45412b988ca8da762214 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 18:31:10 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABB2BCsjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBSb2INCi0tLSBBbGV4DQoNCkZyb206IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2ls dG9uQGNpc2NvLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDEsIDIwMTcgNDo0MyBB TQ0KVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+OyBNYXJ0 aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT47IGFuZHlAeXVtYXdvcmtzLmNvbTsgbmV0bW9k QGlldGYub3JnOyBSYW5keSBQcmVzdWhuIDxyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5l ZHU+OyBQaGlsIFNoYWZlciA8cGhpbEBqdW5pcGVyLm5ldD4NClN1YmplY3Q6IFJlOiBbbmV0bW9k XSBBY3Rpb24gYW5kIFJQQyBzdGF0ZW1lbnRzDQoNCg0KSGkgQWxleCwNCg0KT24gMzEvMTAvMjAx NyAxNzozNiwgQWxleGFuZGVyIENsZW1tIHdyb3RlOg0KSGkgUm9iLA0KDQpBIGZldyBjb21tZW50 cywgaW5saW5lDQoNCi0tLSBBbGV4DQoNCkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFdpbHRvbg0KU2VudDogVHVlc2RheSwg T2N0b2JlciAzMSwgMjAxNyA3OjE0IEFNDQpUbzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwt Zi5jb20+PG1haWx0bzptYmpAdGFpbC1mLmNvbT47IGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86 YW5keUB5dW1hd29ya3MuY29tPjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+OyBSYW5keSBQcmVzdWhuIDxyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHU+PG1h aWx0bzpyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHU+DQpTdWJqZWN0OiBSZTogW25l dG1vZF0gQWN0aW9uIGFuZCBSUEMgc3RhdGVtZW50cw0KDQoNCkhpLA0KDQpIZXJlIGlzIGFub3Ro ZXIgYXR0ZW1wdCBmb3IgcHJvcG9zZWQgdGV4dCBmb3IgQWN0aW9ucy9SUEMgc3RhdGVtZW50cyBp biBOTURBLg0KDQo8bmV3Pg0KDQo2LjIgSW52b2NhdGlvbiBvZiBSUEMgT3BlcmF0aW9ucw0KDQpU aGlzIHNlY3Rpb24gdXBkYXRlcyBzZWN0aW9uIDcuMTQgb2YgUkZDIDc5NTAuDQoNClJQQ3MgTUFZ IGJlIGRlZmluZWQgYXMgYWZmZWN0aW5nIHRoZSBjb250ZW50cyBvZiBhIHNwZWNpZmljIGRhdGFz dG9yZSwNCmFueSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSAoZS5nLiwgPGVkaXQtY29uZmlnPiks IG9yIGFueSBkYXRhc3RvcmUNCihlLmcuLCA8Z2V0LWRhdGE+KS4gIFRoZSBSUEMgZGVmaW5pdGlv biBzcGVjaWZpZXMgaG93IHRoZSBSUEMgaW5wdXQNCmRhdGEgaXMgaW50ZXJwcmV0ZWQgYnkgdGhl IHNlcnZlci4NCg0KPEFMRVg+IHdoeSDigJxlLmcuLCA8Z2V0LWRhdGE+4oCdPyAgRG9lcyA8Z2V0 LWRhdGE+IGFmZmVjdCB0aGUgY29udGVudHMgb2YgdGhlIGRhdGFzdG9yZSDigJMgSSB0aG91Z2h0 IGl0IGp1c3QgZ2V0cyBkYXRhLCBoZW5jZSB0aGlzIGV4YW1wbGUgaXMgbm90IGlkZWFsLg0KDQpU aGVyZSBpcyBhbHNvIG5vIG1lbnRpb24gYWJvdXQgdGhlIHNvdXJjZSBvZiB0aGUg4oCcaW7igJ0g cGFyYW1ldGVycy4gIEl0IHByb2JhYmx5IG1ha2VzIHNlbnNlIHRvIG1lbnRpb24gdGhhdCBleHBs aWNpdGx5Lg0KDQpQZXJoYXBzIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcUlBDcyBN QVkgYmUgZGVmaW5lZCBhcyBfcmVsYXRpbmdfIHRvIHRoZSBjb250ZW50cyBvZiBhIHNwZWNpZmlj IGRhdGFzdG9yZeKApi4gICBJbnB1dCBkYXRhIHJlc29sdmVzIHRvIDxvcGVyYXRpb25hbD4sIGFz IGRvZXMgb3V0cHV0IGRhdGEsIGFzIGRvIFJQQyBzaWRlIGVmZmVjdHPigJwuICBUaGVuIGJlbG93 DQoNCuKAnFJQQ3MgZGVmaW5pdGlvbnMgdGhhdCBkbyBub3QgZXhwbGljaXRseSBzdGF0ZSBhbiBh ZmZlY3RlZA0KZGF0YXN0b3JlKHMpIF9yZWZlcl90b18gIHRoZSBnZW5lcmFsIG9wZXJhdGlvbmFs IHN0YXRlIG9mIHRoZSBzZXJ2ZXIu4oCdDQpZZXMsIHRoYXQgbWFrZXMgc2Vuc2UuDQoNCg0KDQoN Cg0KT25lIG90aGVyIGNvbW1lbnQsIGl0IHdvdWxkIGJlIGdvb2QgdG8gYWxzbyBpbmRpY2F0ZSB0 aGF0IHdoZW4gYW4gUlBDIGxlYWRzIHRvIG1vZGlmaWNhdGlvbiBvZiBkYXRhIG5vZGVzLCB3aGF0 IHRoZSDigJxvcmlnaW7igJ0gb2YgdGhvc2UgbW9kaWZpY2F0aW9ucyBpcy4NClRoYXQgaXMgYW4g aW50ZXJlc3RpbmcgcXVlc3Rpb24uDQoNClRvIGRlc2NyaWJlIHRoaXMgYXMgYSBjb25jcmV0ZSBl eGFtcGxlLCBpZiB5b3UgaGF2ZSBhIHNpbmdsZSBjb25maWcgdHJ1ZSBZQU5HIGxpc3QgZm9yIGR5 bmFtaWMvY29uZmlndXJhdGlvbiBzdWJzY3JpcHRpb25zIHRoZW4gYSBzdWJzY3JpcHRpb24gY2Fu IGJlIGNyZWF0ZWQgZWl0aGVyIHZpYSBjb25maWd1cmF0aW9uIG9yIGFzIGFuIFJQQyBvcGVyYXRp b24uDQoNCkkgd291bGQgcHJvYmFibHkgY2xhc3NpZnkgdGhpcyBhcyAibGVhcm5lZCIsIGFuZCBJ IHRoaW5rIHRoYXQgd2UgY291bGQgZXh0ZW5kIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAibGVhcm5l ZCIgb3JpZ2luIHRvIGNvdmVyIHRoaXMgY2FzZS4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KDQoNCjwv QUxFWD4NCg0KDQpSUENzIGRlZmluaXRpb25zIHRoYXQgZG8gbm90IGV4cGxpY2l0bHkgc3RhdGUg YW4gYWZmZWN0ZWQNCmRhdGFzdG9yZShzKSBtb2RpZnkgdGhlIGdlbmVyYWwgb3BlcmF0aW9uYWwg c3RhdGUgb2YgdGhlIHNlcnZlci4NCkhlbmNlLCBpZiBhbnkgUlBDIGlucHV0IGRhdGEgcmVsYXRl cyB0byBkYXRhIG5vZGUgaW5zdGFuY2VzIHRoZW4NCnRob3NlIHdvdWxkIGdlbmVyYWxseSByZXNv bHZlIHRvIGRhdGEgbm9kZSBpbnN0YW5jZXMgaW4gdGhlDQo8b3BlcmF0aW9uYWw+IGRhdGEgdHJl ZS4NCg0KDQo2LjMgSW52b2NhdGlvbiBvZiBBY3Rpb25zDQoNClRoaXMgc2VjdGlvbiB1cGRhdGVz IHNlY3Rpb24gNy4xNSBvZiBSRkMgNzk1MC4NCg0KSW4gWUFORyBkYXRhIG1vZGVscywgdGhlICJh Y3Rpb24iIHN0YXRlbWVudCBtYXkgYXBwZWFyIHVuZGVyICJjb25maWcNCnRydWUiIGFuZCAiY29u ZmlnIGZhbHNlIiBzY2hlbWEgbm9kZXMuICBXaGlsZSBpbnN0YW5jZXMgb2YgYm90aA0Kc2NoZW1h IG5vZGVzIG1heSBhcHBlYXIgaW4gPG9wZXJhdGlvbmFsPiwgaW5zdGFuY2VzIG9mICJjb25maWcg dHJ1ZSINCnNjaGVtYSBub2RlcyBtYXkgYWxzbyBhcHBlYXIgaW4gb3RoZXIgZGF0YXN0b3Jlcy4N Cg0KQWN0aW9ucyBhcmUgYWx3YXlzIGludm9rZWQgb24gYSBkYXRhIG5vZGUgaW5zdGFuY2UgdGhh dCBleGlzdCBpbiB0aGUNCjxvcGVyYXRpb25hbD4gZGF0YSB0cmVlLiAgVGhlIGJlaGF2aW9yIGRl ZmluZWQgYnkgYW4gYWN0aW9uIHN0YXRlbWVudA0KaXMgZ2VuZXJhbGx5IGV4cGVjdGVkIHRvIGFm ZmVjdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgb2YgdGhlIHNlcnZlcg0KcmF0aGVyIHRoYW4gZGly ZWN0bHkgbW9kaWZ5aW5nIHRoZSBjb250ZW50cyBvZiBhbnkgY29uZmlndXJhdGlvbg0KZGF0YXN0 b3JlLg0KPC9uZXc+DQoNCg0KT24gYSByZWxhdGVkIG5vdGUsIEkgYWxzbyB3YW50IHRvIGNvbmZp cm0gdGhhdCBpdCBpcyByaWdodCB0aGF0IFJQQyBpbnB1dCBkYXRhIGlzIGFsd2F5cyBjaGVja2Vk IGFnYWluc3Qgb3BlcmF0aW9uYWw6DQoNClNlY3Rpb24gNi4xLiBvZiB0aGUgTk1EQSBkcmFmdCBz dGF0ZXM6DQoNCg0KDQoNCiAgIG8gIElmIHRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGRlZmluZWQg aW4gYSBzdWJzdGF0ZW1lbnQgdG8gYW4gImlucHV0Ig0KDQogICAgICBzdGF0ZW1lbnQgaW4gYW4g InJwYyIgb3IgImFjdGlvbiIgc3RhdGVtZW50LCB0aGUgYWNjZXNzaWJsZSB0cmVlDQoNCiAgICAg IGlzIHRoZSBSUEMgb3IgYWN0aW9uIG9wZXJhdGlvbiBpbnN0YW5jZSBhbmQgYWxsIG9wZXJhdGlv bmFsIHN0YXRlDQoNCiAgICAgIGluIHRoZSBzZXJ2ZXIuICBUaGUgcm9vdCBub2RlIGhhcyB0b3At bGV2ZWwgZGF0YSBub2RlcyBpbiBhbGwNCg0KICAgICAgbW9kdWxlcyBhcyBjaGlsZHJlbi4gIEFk ZGl0aW9uYWxseSwgZm9yIGFuIFJQQywgdGhlIHJvb3Qgbm9kZSBhbHNvDQoNCiAgICAgIGhhcyB0 aGUgbm9kZSByZXByZXNlbnRpbmcgdGhlIFJQQyBvcGVyYXRpb24gYmVpbmcgZGVmaW5lZCBhcyBh DQoNCiAgICAgIGNoaWxkLiAgVGhlIG5vZGUgcmVwcmVzZW50aW5nIHRoZSBvcGVyYXRpb24gYmVp bmcgZGVmaW5lZCBoYXMgdGhlDQoNCiAgICAgIG9wZXJhdGlvbidzIGlucHV0IHBhcmFtZXRlcnMg YXMgY2hpbGRyZW4uDQoNCg0KSXMgPG9wZXJhdGlvbmFsPiBhbHdheXMgdGhlIHJpZ2h0IGRhdGFz dG9yZSB0byBldmFsdWF0ZSBSUEMgaW5wdXQvb3V0cHV0IGRhdGEgcmVsYXRpdmUgdG8/ICBGb3Ig bW9zdCBSUENzIHRoaXMgc2VlbXMgdG8gYmUgdGhlIHJpZ2h0IGNob2ljZSBieSBkZWZhdWx0IGJ1 dCBpdCBhbHNvIHNlZW1zIHBsYXVzaWJsZSB0aGF0IHNvbWVvbmUgbWF5IHdpc2ggdG8gZGVmaW5l IGFuIFJQQyB0aGF0IHdhbnRzIHRvIHZhbGlkYXRlIGl0cyBpbnB1dCBwYXJhbWV0ZXJzIGFnYWlu c3QgdGhlIGNvbnRlbnRzIG9mIGFub3RoZXIgZGF0YXN0b3JlLg0KDQpBbiBleGFtcGxlIGNvdWxk IGJlIGFuICJpcy1hcHBsaWVkIiBSUEMgdGhhdCB0YWtlcyBhIHBhdGggdG8gYSBzdWJ0cmVlIGlu IDxydW5uaW5nPiBvciA8aW50ZW5kZWQ+IGFuZCBjaGVja3Mgd2hldGhlciB0aGUgY29uZmlndXJh dGlvbiBmb3IgdGhhdCBzdWJ0cmVlIGlzIGZ1bGx5IHJlcHJlc2VudGVkIGluIDxvcGVyYXRpb25h bD4uDQoNClRoYW5rcywNClJvYg0KDQoNCk9uIDI3LzEwLzIwMTcgMDk6MzMsIE1hcnRpbiBCam9y a2x1bmQgd3JvdGU6DQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPjxtYWlsdG86 YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCg0KT24gVGh1LCBPY3QgMjYsIDIwMTcgYXQgMTE6 MjIgQU0sIFJhbmR5IFByZXN1aG4gPA0KDQpyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5l ZHU8bWFpbHRvOnJhbmR5X3ByZXN1aG5AYWx1bW5pLnN0YW5mb3JkLmVkdT4+IHdyb3RlOg0KDQoN Cg0KSGkgLQ0KDQoNCg0KT24gMTAvMjYvMjAxNyAxMDo0NCBBTSwgUm9iZXJ0IFdpbHRvbiB3cm90 ZToNCg0KDQoNCkhpICwNCg0KDQoNClNlcGFyYXRpbmcgb3V0IHRoZSBpc3N1ZSByZWdhcmRpbmcg d2hpY2ggZGF0YXN0b3JlIGFjdGlvbiBhbmQgUlBDIGFwcGx5DQoNCnRvLCB3ZSBwcm9wb3NlIHRo ZSBmb2xsb3dpbmcgTkVXIHRleHQgdG8gdGhlIGRhdGFzdG9yZXMgZHJhZnQ6DQoNCg0KDQo2LjIg SW52b2NhdGlvbiBvZiBBY3Rpb25zIGFuZCBSUEMgT3BlcmF0aW9ucw0KDQoNCg0KICAgVGhpcyBz ZWN0aW9uIHVwZGF0ZXMgc2VjdGlvbiA3LjE1LiBvZiBSRkMgNzk1MC4NCg0KDQoNCiAgIEluIFlB TkcgZGF0YSBtb2RlbHMsIHRoZSAiYWN0aW9uIiBzdGF0ZW1lbnQgbWF5IGFwcGVhciB1bmRlciAi Y29uZmlnDQoNCiAgIHRydWUiIGFuZCAiY29uZmlnIGZhbHNlIiBzY2hlbWEgbm9kZXMuICBXaGls ZSBpbnN0YW5jZXMgb2YgYm90aA0KDQogICBzY2hlbWEgbm9kZXMgbWF5IGFwcGVhciBpbiA8b3Bl cmF0aW9uYWw+LCBpbnN0YW5jZXMgb2YgImNvbmZpZyB0cnVlIg0KDQogICBzY2hlbWEgbm9kZXMg bWF5IGFsc28gYXBwZWFyIGluIG90aGVyIGRhdGFzdG9yZXMuDQoNCg0KDQogICBBbiBOTURBIGNv bXBsaWFudCBzZXJ2ZXIgTVVTVCBleGVjdXRlIGFsbCBhY3Rpb25zIGluIHRoZSBjb250ZXh0IG9m DQoNCiAgIDxvcGVyYXRpb25hbD4uICBMaWtld2lzZSwgYW4gTk1EQSBjb21wbGlhbnQgc2VydmVy IE1VU1QgaW52b2tlIGFsbCBSUEMNCg0KICAgb3BlcmF0aW9ucyBpbiB0aGUgY29udGV4dCBvZiA8 b3BlcmF0aW9uYWw+LCB1bmxlc3MgdGhlIFJQQyBpcw0KDQpleHBsaWNpdGx5DQoNCiAgIGRlZmlu ZWQgYXMgYWZmZWN0aW5nIG90aGVyIGRhdGFzdG9yZXMgKGUuZy4sIDxlZGl0LWNvbmZpZz4pLg0K DQoNCg0KT0s/DQoNCg0KDQoNCg0KQSBxdWVzdGlvbiAtIEkgdW5kZXJzdGFuZCB0aGUgbW90aXZh dGlvbiBmb3IgdGhlICJ1bmxlc3MiIGZvciBSUEMNCg0Kb3BlcmF0aW9ucywgYnV0IHdvbmRlciB3 aHkgdGhlcmUgaXMgbm8gc2ltaWxhciAidW5sZXNzIiBmb3IgYWN0aW9ucy4NCg0KDQoNCg0KDQoN Cg0KVGhlIDxycGM+IGlzIG5vdCByZWFsbHkgaW4gYSBkYXRhc3RvcmUgYXQgYWxsLg0KDQpJdCBt YXkgaGF2ZSBpbnB1dCBhbmQgb3V0cHV0IHBhcmFtZXRlcnMgd2l0aCBsZWFmcmVmIGFuZCBtdXN0 L3doZW4NCg0Kc3RhdGVtZW50cy4NCg0KVGhlc2UgYXJlIGV2YWx1YXRlZCBpbiB0aGUgPG9wZXJh dGlvbmFsPiBjb250ZXh0Lg0KDQpUaGUgPHJwYz4gbWF5IGluIGZhY3QgYmUgc29tZXRoaW5nIGxp a2UgPGVkaXQtY29uZmlnPg0KDQp3aGljaCBoYXMgcGFyYW1ldGVycyAobGlrZSA8Y29uZmlnPiB0 byBhcHBseSB0bw0KDQphIHNwZWNpZmljIGRhdGFzdG9yZS4NCg0KDQoNClRoZSBhY3Rpb24gbm9k ZSBpcyBlbWJlZGRlZCB3aXRoaW4gc29tZSBkYXRhIHRoYXQgaGFzIHRvIGJlIHBhcnNlZA0KDQpp biBhIHNwZWNpZmljIGRhdGFzdG9yZSBiZWZvcmUgdGhlIGFjdGlvbiBpcyBwcm9jZXNzZWQuDQoN ClRoaXMgZGF0YSBpcyByZXF1aXJlZCB0byBiZSBpbiA8b3BlcmF0aW9uYWw+Lg0KDQpJdCBhbHNv IGhhcyBYUGF0aCBhbmQgbGVhZnJlZiB0aGF0IG5lZWRzIHRvIGJlIHJlc29sdmVkIChzYW1lIGFz IDxycGM+KS4NCg0KDQoNClRoZSBzaWRlIGVmZmVjdHMgb2YgdGhlIDxycGM+IG9yIDxhY3Rpb24+ IGNhbiBpbXBhY3Qgb3RoZXIgZGF0YXN0b3Jlcy4NCg0KVGhpcyB3b3VsZCBiZSBkZWZpbmVkIGlu IHRoZSBkZXNjcmlwdGlvbi1zdG10IGFuZCB0aGlzIGlzIG5vdCBhIHByb2JsZW0uDQoNCg0KDQpU aGlzIGlzIGV4YWN0bHkgcmlnaHQuICBXZSBuZWVkIHRvIGNhcHR1cmUgdGhpcyBpbiB0aGUgdGV4 dC4NCg0KDQoNCg0KDQovbWFydGluDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpuZXRtb2QgbWFpbGluZyBsaXN0DQoNCm5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZA0KDQouDQoNCg0KDQoNCg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABB2BCsjceml521mbxchi_ 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 Cglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnR0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsIFJvYjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPiBSb2JlcnQgV2lsdG9uIFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAwMSwgMjAxNyA0OjQzIEFNPGJy Pg0KPGI+VG86PC9iPiBBbGV4YW5kZXIgQ2xlbW0gJmx0O2FsZXhhbmRlci5jbGVtbUBodWF3ZWku Y29tJmd0OzsgTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7OyBhbmR5QHl1 bWF3b3Jrcy5jb207IG5ldG1vZEBpZXRmLm9yZzsgUmFuZHkgUHJlc3VobiAmbHQ7cmFuZHlfcHJl c3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1Jmd0OzsgUGhpbCBTaGFmZXIgJmx0O3BoaWxAanVuaXBl ci5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBBY3Rpb24gYW5kIFJQ QyBzdGF0ZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGkgQWxleCw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMxLzEwLzIwMTcgMTc6MzYsIEFsZXhhbmRlciBD bGVtbSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgUm9iLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QSBmZXcgY29tbWVudHMsIGlubGluZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gbmV0bW9kIFs8YSBocmVmPSJtYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBXaWx0b248YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyA3OjE0IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4g QmpvcmtsdW5kIDxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+Jmx0O21iakB0YWlsLWYu Y29tJmd0OzwvYT47DQo8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1 bWF3b3Jrcy5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj4NCm5ldG1v ZEBpZXRmLm9yZzwvYT47IFJhbmR5IFByZXN1aG4gPGEgaHJlZj0ibWFpbHRvOnJhbmR5X3ByZXN1 aG5AYWx1bW5pLnN0YW5mb3JkLmVkdSI+DQombHQ7cmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZv cmQuZWR1Jmd0OzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIEFjdGlvbiBh bmQgUlBDIHN0YXRlbWVudHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5IaSw8bzpwPjwv bzpwPjwvcD4NCjxwPkhlcmUgaXMgYW5vdGhlciBhdHRlbXB0IGZvciBwcm9wb3NlZCB0ZXh0IGZv ciBBY3Rpb25zL1JQQyBzdGF0ZW1lbnRzIGluIE5NREEuPG86cD48L286cD48L3A+DQo8cD4mbHQ7 bmV3Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij42LjIgSW52b2NhdGlvbiBvZiBSUEMgT3BlcmF0aW9ucyA8L3NwYW4+PC90dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZiI+PGJyPg0KPGJyPg0KPHR0PlRoaXMgc2VjdGlvbiB1cGRhdGVzIHNlY3Rpb24gNy4x NCBvZiBSRkMgNzk1MC4gPC90dD48YnI+DQo8YnI+DQo8dHQ+UlBDcyBNQVkgYmUgZGVmaW5lZCBh cyBhZmZlY3RpbmcgdGhlIGNvbnRlbnRzIG9mIGEgc3BlY2lmaWMgZGF0YXN0b3JlLCA8L3R0Pjxi cj4NCjx0dD5hbnkgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgKGUuZy4sICZsdDtlZGl0LWNvbmZp ZyZndDspLCBvciBhbnkgZGF0YXN0b3JlIDwvdHQ+PGJyPg0KPHR0PihlLmcuLCAmbHQ7Z2V0LWRh dGEmZ3Q7KS4mbmJzcDsgVGhlIFJQQyBkZWZpbml0aW9uIHNwZWNpZmllcyBob3cgdGhlIFJQQyBp bnB1dCA8L3R0Pjxicj4NCjx0dD5kYXRhIGlzIGludGVycHJldGVkIGJ5IHRoZSBzZXJ2ZXIuIDwv dHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZsdDtBTEVYJmd0OyB3aHkg4oCcZS5nLiwgJmx0O2dldC1kYXRhJmd0O+KAnT8mbmJzcDsg RG9lcyAmbHQ7Z2V0LWRhdGEmZ3Q7IGFmZmVjdCB0aGUgY29udGVudHMgb2YgdGhlIGRhdGFzdG9y ZSDigJMgSSB0aG91Z2h0IGl0IGp1c3QgZ2V0cyBkYXRhLCBoZW5jZSB0aGlzIGV4YW1wbGUgaXMg bm90IGlkZWFsLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGlzIGFsc28gbm8gbWVudGlvbiBhYm91dCB0aGUgc291 cmNlIG9mIHRoZSDigJxpbuKAnSBwYXJhbWV0ZXJzLiZuYnNwOyBJdCBwcm9iYWJseSBtYWtlcyBz ZW5zZSB0byBtZW50aW9uIHRoYXQgZXhwbGljaXRseS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QZXJoYXBzIHNvbWV0aGlu ZyBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcUlBDcyBNQVkgYmUgZGVmaW5lZCBhcyBfPGk+cmVsYXRp bmc8L2k+XyB0byB0aGUgY29udGVudHMgb2YgYSBzcGVjaWZpYyBkYXRhc3RvcmXigKYuICZuYnNw OyZuYnNwO0lucHV0IGRhdGEgcmVzb2x2ZXMgdG8gJmx0O29wZXJhdGlvbmFsJmd0OywgYXMgZG9l cyBvdXRwdXQNCiBkYXRhLCBhcyBkbyBSUEMgc2lkZSBlZmZlY3Rz4oCcLiZuYnNwOyBUaGVuIGJl bG93ICZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNEU3OSI+ 4oCcPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNEU3OSI+UlBDcyBkZWZpbml0 aW9ucyB0aGF0IGRvIG5vdCBleHBsaWNpdGx5IHN0YXRlIGFuIGFmZmVjdGVkDQo8L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNEU3OSI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNEU3OSI+ZGF0YXN0b3JlKHMpIF88aT5yZWZlcl90bzwvaT5fICZu YnNwO3RoZSBnZW5lcmFsIG9wZXJhdGlvbmFsIHN0YXRlIG9mIHRoZSBzZXJ2ZXIuPC9zcGFuPjwv dHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0RTc5Ij7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhhdCBtYWtlcyBzZW5zZS48YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNEU3OSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0RTc5Ij5PbmUgb3RoZXIgY29tbWVudCwgaXQgd291bGQgYmUgZ29vZCB0byBhbHNvIGluZGlj YXRlIHRoYXQgd2hlbiBhbiBSUEMgbGVhZHMgdG8gbW9kaWZpY2F0aW9uIG9mIGRhdGEgbm9kZXMs IHdoYXQgdGhlIOKAnG9yaWdpbuKAnSBvZiB0aG9zZSBtb2RpZmljYXRpb25zIGlzLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF0IGlzIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uLjxicj4NCjxicj4NClRvIGRlc2Ny aWJlIHRoaXMgYXMgYSBjb25jcmV0ZSBleGFtcGxlLCBpZiB5b3UgaGF2ZSBhIHNpbmdsZSBjb25m aWcgdHJ1ZSBZQU5HIGxpc3QgZm9yIGR5bmFtaWMvY29uZmlndXJhdGlvbiBzdWJzY3JpcHRpb25z IHRoZW4gYSBzdWJzY3JpcHRpb24gY2FuIGJlIGNyZWF0ZWQgZWl0aGVyIHZpYSBjb25maWd1cmF0 aW9uIG9yIGFzIGFuIFJQQyBvcGVyYXRpb24uPGJyPg0KPGJyPg0KSSB3b3VsZCBwcm9iYWJseSBj bGFzc2lmeSB0aGlzIGFzICZxdW90O2xlYXJuZWQmcXVvdDssIGFuZCBJIHRoaW5rIHRoYXQgd2Ug Y291bGQgZXh0ZW5kIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAmcXVvdDtsZWFybmVkJnF1b3Q7IG9y aWdpbiB0byBjb3ZlciB0aGlzIGNhc2UuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJvYjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0RTc5Ij4mbHQ7L0FMRVgmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPjxicj4NCjxicj4NCjx0dD5SUENzIGRlZmluaXRpb25zIHRo YXQgZG8gbm90IGV4cGxpY2l0bHkgc3RhdGUgYW4gYWZmZWN0ZWQgPC90dD48YnI+DQo8dHQ+ZGF0 YXN0b3JlKHMpIG1vZGlmeSB0aGUgZ2VuZXJhbCBvcGVyYXRpb25hbCBzdGF0ZSBvZiB0aGUgc2Vy dmVyLiA8L3R0Pjxicj4NCjx0dD5IZW5jZSwgaWYgYW55IFJQQyBpbnB1dCBkYXRhIHJlbGF0ZXMg dG8gZGF0YSBub2RlIGluc3RhbmNlcyB0aGVuIDwvdHQ+PGJyPg0KPHR0PnRob3NlIHdvdWxkIGdl bmVyYWxseSByZXNvbHZlIHRvIGRhdGEgbm9kZSBpbnN0YW5jZXMgaW4gdGhlIDwvdHQ+PGJyPg0K PHR0PiZsdDtvcGVyYXRpb25hbCZndDsgZGF0YSB0cmVlLiA8L3R0Pjxicj4NCjxicj4NCjxicj4N Cjx0dD42LjMgSW52b2NhdGlvbiBvZiBBY3Rpb25zIDwvdHQ+PGJyPg0KPGJyPg0KPHR0PlRoaXMg c2VjdGlvbiB1cGRhdGVzIHNlY3Rpb24gNy4xNSBvZiBSRkMgNzk1MC4gPC90dD48YnI+DQo8YnI+ DQo8dHQ+SW4gWUFORyBkYXRhIG1vZGVscywgdGhlICZxdW90O2FjdGlvbiZxdW90OyBzdGF0ZW1l bnQgbWF5IGFwcGVhciB1bmRlciAmcXVvdDtjb25maWcgPC90dD48YnI+DQo8dHQ+dHJ1ZSZxdW90 OyBhbmQgJnF1b3Q7Y29uZmlnIGZhbHNlJnF1b3Q7IHNjaGVtYSBub2Rlcy4mbmJzcDsgV2hpbGUg aW5zdGFuY2VzIG9mIGJvdGggPC90dD48YnI+DQo8dHQ+c2NoZW1hIG5vZGVzIG1heSBhcHBlYXIg aW4gJmx0O29wZXJhdGlvbmFsJmd0OywgaW5zdGFuY2VzIG9mICZxdW90O2NvbmZpZyB0cnVlJnF1 b3Q7IDwvdHQ+PGJyPg0KPHR0PnNjaGVtYSBub2RlcyBtYXkgYWxzbyBhcHBlYXIgaW4gb3RoZXIg ZGF0YXN0b3Jlcy4gPC90dD48YnI+DQo8YnI+DQo8dHQ+QWN0aW9ucyBhcmUgYWx3YXlzIGludm9r ZWQgb24gYSBkYXRhIG5vZGUgaW5zdGFuY2UgdGhhdCBleGlzdCBpbiB0aGUgPC90dD48YnI+DQo8 dHQ+Jmx0O29wZXJhdGlvbmFsJmd0OyBkYXRhIHRyZWUuJm5ic3A7IFRoZSBiZWhhdmlvciBkZWZp bmVkIGJ5IGFuIGFjdGlvbiBzdGF0ZW1lbnQgPC90dD48YnI+DQo8dHQ+aXMgZ2VuZXJhbGx5IGV4 cGVjdGVkIHRvIGFmZmVjdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgb2YgdGhlIHNlcnZlciA8L3R0 Pjxicj4NCjx0dD5yYXRoZXIgdGhhbiBkaXJlY3RseSBtb2RpZnlpbmcgdGhlIGNvbnRlbnRzIG9m IGFueSBjb25maWd1cmF0aW9uIDwvdHQ+PGJyPg0KPHR0PmRhdGFzdG9yZS4gPC90dD48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7L25ldyZndDs8YnI+DQo8 YnI+DQo8YnI+DQpPbiBhIHJlbGF0ZWQgbm90ZSwgSSBhbHNvIHdhbnQgdG8gY29uZmlybSB0aGF0 IGl0IGlzIHJpZ2h0IHRoYXQgUlBDIGlucHV0IGRhdGEgaXMgYWx3YXlzIGNoZWNrZWQgYWdhaW5z dCBvcGVyYXRpb25hbDo8YnI+DQo8YnI+DQpTZWN0aW9uIDYuMS4gb2YgdGhlIE5NREEgZHJhZnQg c3RhdGVzOjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4 LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG NTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZu YnNwOyZuYnNwOyBvJm5ic3A7IElmIHRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGRlZmluZWQgaW4g YSBzdWJzdGF0ZW1lbnQgdG8gYW4gJnF1b3Q7aW5wdXQmcXVvdDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0YXRlbWVudCBpbiBhbiAmcXVvdDtycGMmcXVv dDsgb3IgJnF1b3Q7YWN0aW9uJnF1b3Q7IHN0YXRlbWVudCwgdGhlIGFjY2Vzc2libGUgdHJlZTwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgdGhlIFJQQyBv ciBhY3Rpb24gb3BlcmF0aW9uIGluc3RhbmNlIGFuZCBhbGwgb3BlcmF0aW9uYWwgc3RhdGU8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIHRoZSBzZXJ2ZXIu Jm5ic3A7IFRoZSByb290IG5vZGUgaGFzIHRvcC1sZXZlbCBkYXRhIG5vZGVzIGluIGFsbDwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9kdWxlcyBhcyBjaGls ZHJlbi4mbmJzcDsgQWRkaXRpb25hbGx5LCBmb3IgYW4gUlBDLCB0aGUgcm9vdCBub2RlIGFsc288 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7 YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhcyB0aGUgbm9k ZSByZXByZXNlbnRpbmcgdGhlIFJQQyBvcGVyYXRpb24gYmVpbmcgZGVmaW5lZCBhcyBhPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjaGlsZC4mbmJzcDsgVGhl IG5vZGUgcmVwcmVzZW50aW5nIHRoZSBvcGVyYXRpb24gYmVpbmcgZGVmaW5lZCBoYXMgdGhlPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvcGVyYXRpb24ncyBp bnB1dCBwYXJhbWV0ZXJzIGFzIGNoaWxkcmVuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCjxicj4NCklzICZsdDtvcGVyYXRpb25hbCZndDsgYWx3YXlzIHRoZSByaWdodCBkYXRhc3Rv cmUgdG8gZXZhbHVhdGUgUlBDIGlucHV0L291dHB1dCBkYXRhIHJlbGF0aXZlIHRvPyZuYnNwOyBG b3IgbW9zdCBSUENzIHRoaXMgc2VlbXMgdG8gYmUgdGhlIHJpZ2h0IGNob2ljZSBieSBkZWZhdWx0 IGJ1dCBpdCBhbHNvIHNlZW1zIHBsYXVzaWJsZSB0aGF0IHNvbWVvbmUgbWF5IHdpc2ggdG8gZGVm aW5lIGFuIFJQQyB0aGF0IHdhbnRzIHRvIHZhbGlkYXRlIGl0cyBpbnB1dCBwYXJhbWV0ZXJzDQog YWdhaW5zdCB0aGUgY29udGVudHMgb2YgYW5vdGhlciBkYXRhc3RvcmUuPGJyPg0KPGJyPg0KQW4g ZXhhbXBsZSBjb3VsZCBiZSBhbiAmcXVvdDtpcy1hcHBsaWVkJnF1b3Q7IFJQQyB0aGF0IHRha2Vz IGEgcGF0aCB0byBhIHN1YnRyZWUgaW4gJmx0O3J1bm5pbmcmZ3Q7IG9yICZsdDtpbnRlbmRlZCZn dDsgYW5kIGNoZWNrcyB3aGV0aGVyIHRoZSBjb25maWd1cmF0aW9uIGZvciB0aGF0IHN1YnRyZWUg aXMgZnVsbHkgcmVwcmVzZW50ZWQgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy48YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KUm9iPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjcvMTAvMjAxNyAwOTozMywgTWFydGluIEJqb3JrbHVu ZCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkFuZHkgQmllcm1hbiA8YSBo cmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj4mbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0 OzwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5PbiBUaHUsIE9jdCAyNiwgMjAx NyBhdCAxMToyMiBBTSwgUmFuZHkgUHJlc3VobiAmbHQ7PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0ibWFpbHRvOnJhbmR5X3ByZXN1aG5AYWx1bW5pLnN0YW5mb3JkLmVkdSI+cmFuZHlf cHJlc3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IaSAtPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+T24gMTAvMjYvMjAxNyAx MDo0NCBBTSwgUm9iZXJ0IFdpbHRvbiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhpICw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZXBhcmF0aW5nIG91dCB0aGUgaXNzdWUgcmVn YXJkaW5nIHdoaWNoIGRhdGFzdG9yZSBhY3Rpb24gYW5kIFJQQyBhcHBseTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPnRvLCB3ZSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgTkVXIHRleHQgdG8gdGhlIGRh dGFzdG9yZXMgZHJhZnQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+Ni4yIEludm9jYXRpb24gb2YgQWN0aW9ucyBhbmQgUlBDIE9wZXJhdGlvbnM8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgVGhpcyBzZWN0aW9uIHVwZGF0ZXMgc2VjdGlvbiA3LjE1LiBvZiBSRkMgNzk1MC48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgSW4gWUFORyBkYXRhIG1vZGVscywgdGhlICZxdW90O2FjdGlvbiZxdW90OyBzdGF0 ZW1lbnQgbWF5IGFwcGVhciB1bmRlciAmcXVvdDtjb25maWc8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgdHJ1ZSZxdW90OyBhbmQgJnF1b3Q7Y29uZmlnIGZhbHNlJnF1b3Q7IHNj aGVtYSBub2Rlcy4mbmJzcDsgV2hpbGUgaW5zdGFuY2VzIG9mIGJvdGg8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgc2NoZW1hIG5vZGVzIG1heSBhcHBlYXIgaW4gJmx0O29wZXJh dGlvbmFsJmd0OywgaW5zdGFuY2VzIG9mICZxdW90O2NvbmZpZyB0cnVlJnF1b3Q7PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNjaGVtYSBub2RlcyBtYXkgYWxzbyBhcHBlYXIg aW4gb3RoZXIgZGF0YXN0b3Jlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQW4gTk1EQSBjb21wbGlhbnQgc2VydmVyIE1V U1QgZXhlY3V0ZSBhbGwgYWN0aW9ucyBpbiB0aGUgY29udGV4dCBvZjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiZuYnNwOyBMaWtld2lzZSwg YW4gTk1EQSBjb21wbGlhbnQgc2VydmVyIE1VU1QgaW52b2tlIGFsbCBSUEM8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgb3BlcmF0aW9ucyBpbiB0aGUgY29udGV4dCBvZiAmbHQ7 b3BlcmF0aW9uYWwmZ3Q7LCB1bmxlc3MgdGhlIFJQQyBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmV4cGxpY2l0bHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZGVmaW5lZCBh cyBhZmZlY3Rpbmcgb3RoZXIgZGF0YXN0b3JlcyAoZS5nLiwgJmx0O2VkaXQtY29uZmlnJmd0Oyku PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+T0s/ PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx dW90ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+QSBxdWVzdGlvbiAtIEkg dW5kZXJzdGFuZCB0aGUgbW90aXZhdGlvbiBmb3IgdGhlICZxdW90O3VubGVzcyZxdW90OyBmb3Ig UlBDPG86cD48L286cD48L3ByZT4NCjxwcmU+b3BlcmF0aW9ucywgYnV0IHdvbmRlciB3aHkgdGhl cmUgaXMgbm8gc2ltaWxhciAmcXVvdDt1bmxlc3MmcXVvdDsgZm9yIGFjdGlvbnMuPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmU+VGhlICZsdDtycGMmZ3Q7IGlzIG5vdCByZWFsbHkgaW4gYSBkYXRhc3RvcmUgYXQgYWxs LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkl0IG1heSBoYXZlIGlucHV0IGFuZCBvdXRwdXQgcGFy YW1ldGVycyB3aXRoIGxlYWZyZWYgYW5kIG11c3Qvd2hlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PnN0YXRlbWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlc2UgYXJlIGV2YWx1YXRlZCBp biB0aGUgJmx0O29wZXJhdGlvbmFsJmd0OyBjb250ZXh0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PlRoZSAmbHQ7cnBjJmd0OyBtYXkgaW4gZmFjdCBiZSBzb21ldGhpbmcgbGlrZSAmbHQ7ZWRpdC1j b25maWcmZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+d2hpY2ggaGFzIHBhcmFtZXRlcnMgKGxp a2UgJmx0O2NvbmZpZyZndDsgdG8gYXBwbHkgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIHNw ZWNpZmljIGRhdGFzdG9yZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5UaGUgYWN0aW9uIG5vZGUgaXMgZW1iZWRkZWQgd2l0aGluIHNvbWUgZGF0 YSB0aGF0IGhhcyB0byBiZSBwYXJzZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbiBhIHNwZWNp ZmljIGRhdGFzdG9yZSBiZWZvcmUgdGhlIGFjdGlvbiBpcyBwcm9jZXNzZWQuPG86cD48L286cD48 L3ByZT4NCjxwcmU+VGhpcyBkYXRhIGlzIHJlcXVpcmVkIHRvIGJlIGluICZsdDtvcGVyYXRpb25h bCZndDsuPG86cD48L286cD48L3ByZT4NCjxwcmU+SXQgYWxzbyBoYXMgWFBhdGggYW5kIGxlYWZy ZWYgdGhhdCBuZWVkcyB0byBiZSByZXNvbHZlZCAoc2FtZSBhcyAmbHQ7cnBjJmd0OykuPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIHNpZGUg ZWZmZWN0cyBvZiB0aGUgJmx0O3JwYyZndDsgb3IgJmx0O2FjdGlvbiZndDsgY2FuIGltcGFjdCBv dGhlciBkYXRhc3RvcmVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgd291bGQgYmUgZGVm aW5lZCBpbiB0aGUgZGVzY3JpcHRpb24tc3RtdCBhbmQgdGhpcyBpcyBub3QgYSBwcm9ibGVtLjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPlRoaXMgaXMgZXhhY3RseSByaWdodC4mbmJzcDsgV2UgbmVlZCB0byBjYXB0dXJl IHRoaXMgaW4gdGhlIHRleHQuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+L21hcnRpbjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4N CjxwcmU+bmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+ PG86cD48L286cD48L3ByZT4NCjxwcmU+LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EABB2BCsjceml521mbxchi_-- From nobody Wed Nov 1 12:28: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 0833B13F5F6 for ; Wed, 1 Nov 2017 12:28:31 -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 HUuMndc3JY7I for ; Wed, 1 Nov 2017 12:28:24 -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 B3AD713F58C for ; Wed, 1 Nov 2017 12:28:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 816D66A0; Wed, 1 Nov 2017 20:28:22 +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 w9SryUGZPo_V; Wed, 1 Nov 2017 20:28: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; Wed, 1 Nov 2017 20:28:22 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E38B20116; Wed, 1 Nov 2017 20:28:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UFW4KhcFKJHM; Wed, 1 Nov 2017 20:28:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73F9A20114; Wed, 1 Nov 2017 20:28:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 44C1341477CA; Wed, 1 Nov 2017 20:26:55 +0100 (CET) Date: Wed, 1 Nov 2017 20:26:54 +0100 From: Juergen Schoenwaelder To: Alexander Clemm Cc: Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn , Phil Shafer Message-ID: <20171101192654.tn7cjntbxijfit6c@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alexander Clemm , Robert Wilton , Martin Bjorklund , "andy@yumaworks.com" , "netmod@ietf.org" , Randy Presuhn , Phil Shafer References: <4d2030ca-3d75-72db-1afd-76a8597b615c@cisco.com> <20171027.103341.1048835221774842137.mbj@tail-f.com> <9645422a-05a2-9d24-e50e-799d964f021f@cisco.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABACAD@sjceml521-mbx.china.huawei.com> <4679d0f6-d884-e0a9-94de-0099735a1172@cisco.com> <20171101115308.gxgns54u6qdmxkx2@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB25E@sjceml521-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EABB25E@sjceml521-mbx.china.huawei.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: Wed, 01 Nov 2017 19:28:31 -0000 On Wed, Nov 01, 2017 at 06:00:15PM +0000, Alexander Clemm wrote: > > > -----Original Message----- > ... > > > That is an interesting question. > > > > > > To describe this as a concrete example, if you have a single config > > > true YANG list for dynamic/configuration subscriptions then a > > > subscription can be created either via configuration or as an RPC operation. > > > > > > I would probably classify this as "learned", and I think that we could > > > extend the definition of the "learned" origin to cover this case. > > > > I do not think any changes are needed, section 5.3.4 is pretty clear that the > > origin 'intended' applies to configuration provided by . If you at > > the options, there is pretty much only 'learned' applicable. > > > > It may be clear that "intended" may not be the right choice, but what is? I think it does not hurt to be explicit about it. This way, people don't have to guess if it should be learned, or maybe system, or possibly even unknown. In its current definition, "learned" only talks about "protocol interactions with other systems ... such as routing protocols, DHCP, etc." If it is "learned" then update its definition to something like > > learned: represents configuration that has been learned via > protocol interactions with other systems, including protocols such > as link-layer negotiations, routing protocols, DHCP, etc, or as a side effect of RPCs. > I do think that the choice is clear enough if you read the origin value definitions. The point is that we can't cover all cases. Even if we name side effects of RPCs (which is BTW not correct since some RPCs do as a side effect modify configuration datastores), the next person is going to say we do not cover YANG actions or certain SNMP sets or. /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 Nov 1 12: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 5662E13FEA2 for ; Wed, 1 Nov 2017 12:50:01 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqePGqEo6O0k for ; Wed, 1 Nov 2017 12:49:59 -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 406F813FE8B for ; Wed, 1 Nov 2017 12:49:59 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id a2so3787430lfh.11 for ; Wed, 01 Nov 2017 12:49:59 -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 :content-transfer-encoding:thread-index:content-language; bh=BrMw9Oyunt/dQfPCrA4XnPFSg9Yx5YehIQGsTxeOYbc=; b=UixvLO3y8BhVfM59runjkcy2M99vGTv9O8xjFl1DN3XMnQI8KqGxmETXdhsyOvXBJc yz43Akm2MHHcajbuuaFfc5VcBrGj0WvkGmAdAxoTVYK0D7eqD2B6Cqvo6hcJm4uVk4+u +gGdIsBqjxE21FlTpOrVE5Tc2spYuYJN2xuYnG0AokP1ri42M/CBm0sxxDKxiik6ZUCe mLGuoEu7IxrlWvHuTx6ZS3vScEBBT1Nal5tZ4mZJFo+1bF89QEnGUdWwVBWWtlzCKZe0 dH9RYPRGROrOwCs4DLIj+TCOSVD5PZyiYCoWQsfeAYxNtT1uUWHTb4GOB5ONxWglIWoK ceiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=BrMw9Oyunt/dQfPCrA4XnPFSg9Yx5YehIQGsTxeOYbc=; b=dvU8zzud+bCgRhHgCHm6cKkcCe6CjtOiUCemGIkbspJepllP/Y14seyzNmOTTZhYkO NUK3GKFJKpMW08JQKNyqGW2C+zv2bI8bxXAVNU/2V0vQJLDMfGjpC+dFx1LS0MI3sdEo P6fmJ2Wi5KYyIQIuRSgYDIWddKMC0CzRK+AoPHgFQSRu7e9SLCBh3fQqypVaZnE3k4/d 7gjNsraX5hk9TD031E8mtvqxHPVVsFI7XcZzZVdjoStAnz9e3y0TNuXBJQfbEgr+kThr jZx1iAknb2+bjyJnuIt2ObNT/jzkyjU0d2z8w0GywOgyl0Gt8FZ1SWF6IcPHKAZ0Gosi 8bUQ== X-Gm-Message-State: AMCzsaXAdSeR8qY09EB/HmwaWcUmNMGfXwvTRYfbql+3hDVStbDVQh3e GTgpXD1N8xUM0PFjuSA8pug= X-Google-Smtp-Source: ABhQp+SdEFUwRybCyiuRfc986tyi7CczlnP4Z6HFkDLzSVnil5OjSDSTQ6ZdpRqbICEvKaUsBM5fOw== X-Received: by 10.46.93.136 with SMTP id v8mr361564lje.168.1509565797547; Wed, 01 Nov 2017 12:49:57 -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 g79sm284911lji.90.2017.11.01.12.49.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Nov 2017 12:49:56 -0700 (PDT) From: "Xufeng Liu" To: "'Kent Watsen'" , References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> In-Reply-To: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> Date: Wed, 1 Nov 2017 15:49:53 -0400 Message-ID: <001c01d3534a$97f29860$c7d7c920$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIYMQhSaL4XogxOYiMUWbllTouW56J2MwMw Content-Language: en-us x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWQyZWM4YmJiLWJmM2QtMTFlNy05YzJlLTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxkMmVjOGJiZC1iZjNkLTExZTctOWMyZS0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjEwOTEiIHQ9IjEzMTU0MDM5MzkzMjI1NjQ3NSIgaD0icy92bHBKMVY2QWg2b0psYXQzUmxpa0Uwd0o0PSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg== 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: Wed, 01 Nov 2017 19:50:01 -0000 Yes/support. Thanks, - Xufeng > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Friday, October 20, 2017 5:38 PM > To: netmod@ietf.org > Subject: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07 > > 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 Wed Nov 1 12:56: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 ED1A313F7FA for ; Wed, 1 Nov 2017 12:56:55 -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 YSrVhGNXXdbe for ; Wed, 1 Nov 2017 12:56:54 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA7713F6BF for ; Wed, 1 Nov 2017 12:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1672; q=dns/txt; s=iport; t=1509566214; x=1510775814; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=L1wl9yooAQdEwOeFevEFxvWLwXZylrkKgJkxzAWSspI=; b=DOoYNhqg9Du0gVaAt895we5sL+nEN0qktTq27CkRQX8xHZpm68DAA/M6 N0c5amOLHqlrluX+S4OVpbvH1uLdtzVd92bA1ZDe+T6K+Sm+fMikVuM5g 0FvMUSlgRT5DhUxOclVtwLbDY2pq5Wlddd1czxFRiGfoy4/DQ9T5b72kq s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAACVJvpZ/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHg3aKH48YgXyDNpMOEIIBChgLhElPAhqEZj8YAQIBAQE?= =?us-ascii?q?BAQEBayiFHQEBAQEDAQEhEToXBAIBCA4DBAEBAwIjAwICAiULFAEICAIEARKKI?= =?us-ascii?q?xCoRYInixABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgh+CB4ZmhF4BEgEfgxW?= =?us-ascii?q?CYQWiCgKUeoIVhgGLGpVmAhEZAYE4AR84gQNpehVJgmSEX3eKQYEkgREBAQE?= X-IronPort-AV: E=Sophos;i="5.44,330,1505779200"; d="scan'208";a="25349856" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2017 19:56:53 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA1Jurm7015422 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2017 19:56:53 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; Wed, 1 Nov 2017 15:56:52 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 1 Nov 2017 15:56:52 -0400 From: "Acee Lindem (acee)" To: "'Kent Watsen'" , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07 Thread-Index: AQHTSeuhw0xDu0vOR0WJhy7BMtYgnKMARGKA//++rYA= Date: Wed, 1 Nov 2017 19:56:52 +0000 Message-ID: References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <001c01d3534a$97f29860$c7d7c920$@gmail.com> In-Reply-To: <001c01d3534a$97f29860$c7d7c920$@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.196] Content-Type: text/plain; charset="utf-8" Content-ID: <695BFC288BCB6B4F98848EF5F21A5ED1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Wed, 01 Nov 2017 19:56:56 -0000 SGkgWHVmZW5nLCANCg0KSSBzdXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQoN ClRoYW5rcywNCkFjZWUgDQoNCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2Vu dCBXYXRzZW4NCj4+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAyMCwgMjAxNyA1OjM4IFBNDQo+PiBU bzogbmV0bW9kQGlldGYub3JnDQo+PiBTdWJqZWN0OiBbbmV0bW9kXSBXRyBMYXN0IENhbGw6IGRy YWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC0wNw0KPj4gDQo+PiBBbGwsDQo+PiANCj4+IFRo aXMgc3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj5kcmFmdC1p ZXRmLW5ldG1vZC1zY2hlbWEtDQo+PiBtb3VudC0wNy4NCj4+IA0KPj4gVGhlIHdvcmtpbmcgZ3Jv dXAgbGFzdCBjYWxsIGVuZHMgb24gTm92ZW1iZXIgMy4NCj4+IFBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3QuDQo+PiANCj4+IFBvc2l0aXZlIGNvbW1l bnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlz DQo+cmVhZHkgZm9yDQo+PiBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KPj4gVGhpcyBpcyB1 c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuDQo+PiANCj4+IENvdWxkIHRo ZSBhdXRob3JzLCBleHBsaWNpdGx5IENDLWVkIG9uIHRoaXMgZW1haWwsIHBsZWFzZSBhbHNvIGNv bmZpcm0NCj4+b25lDQo+bW9yZQ0KPj4gdGltZSB0aGF0IHRoZXkgYXJlIHVuYXdhcmUgb2YgYW55 IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQo+PiANCj4+IFRoYW5rIHlvdSwNCj4+IE5ldG1v ZCBDaGFpcnMNCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1h aWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kDQoNCg== From nobody Wed Nov 1 15:18: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 F01C313FF09 for ; Wed, 1 Nov 2017 15:18:45 -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 yFgw0QlsrJkl for ; Wed, 1 Nov 2017 15:18:44 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0097.outbound.protection.outlook.com [104.47.33.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 1A83D13FF03 for ; Wed, 1 Nov 2017 15:18:44 -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=M2jhsNtqefnu/tZtVosjy1vy3OODDrVq+JqY0JpLv/s=; b=Y8VQ2ANpjbHA/28tuMvcxBriFiZnFd8pBocgdo7Hsl2Hsa+HzSW+VYJ4d9wn8ZI+kAZgv5FdtGqr9fqO6YSGEZKTA67yxHgzz949cj+U4+fMKvWLWjZLqwfcV1n/p0WrrjVv7wiq0L2eaJjBi4iLzMpwSv6k9/cfN2JNBWWX30Q= 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.197.4; Wed, 1 Nov 2017 22:18:42 +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.013; Wed, 1 Nov 2017 22:18:41 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: draft agenda posted Thread-Index: AQHTU19f2YulA5S1WUepk77S2wCXeg== Date: Wed, 1 Nov 2017 22:18:41 +0000 Message-ID: <49D533F4-476E-4031-9D7E-B60B7FBEF678@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.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:uBdDt1a07/eLobROZYHAspFkChkWUCF0pURO5+VOFoVzjtR53FnExpqhyx4UEDjy5qQVrgSKKPa87+Vy27YVUwC1ZZL0CUxd+11wYUzrSgDPPQ2FBBGL1bTMrxzoKRLmY2R28I2x9qH9r8WrKQN7HHvbGh0Ep0nWmwYtwptcUAPbaA/CNI0XGDSGIUOxhBPU3AdWviYA/7z+7FpY29LB2EmL69in2SU5WveqcENueouEIZinIQB5HPSoR5wzJMomZXTUtx6NRWyYGLHW/1yoY8dYHqqlS2EHMk6XsbnyR6ZFhjQPulcPAXBml1/H+ChdPSBaFdZT7pqdNxN28Oo53SjJGxYxOXqyls2MWxZc1FI=; 5:CVMM6IE3F/fh1PM0DHdYfcPUJiKSl1JwA2ykc9DKpuP7NzCCjI3WxHc7okpHk0nIRD1je1zXlv+qIOAKai7aeuhT50VPiP5XJHTThTmFOQGHsbav0hkT6HPBPBIJ4kBXR43Eca2Hhuc26KKft5AWi0cuDluNs9AqCcowj6/h4OQ=; 24:unrrK3nA2PQ6jkvK7J8dNixZunYvDmkZS0v9NW2WvXaczJ9umXFx/mv8TQX5CaYw8rKepXHhmOEkV3j2rSi42xjrkWM7L6a0QkBUQJ9Pcj8=; 7:mabo7TPGeCTLsqWlBo8iK+4sHdCRJX3h63iVMcpBbR55H2kUSmjWS1G061seUi0/tFMHQaTeDZzOSV7gr8trQn3YGxUcOLu2NuOkifkGuv626zAtGHuUy4z3WTbuigYlkKc2vH8UR9/DCI+NVgWG0a8l4O3B1A5ggTn1bPOlE602Ok1Qi/BCSwegwLDkTwMKUVDUcImo2fCLdvNfro9u4zqAiQwgxqnaImphkco2Z+0pAJ9CoczKtYy0VWqt7p2z x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3891f5ca-f1e0-4094-d767-08d52176824b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(48565401081)(2017052603199); SRVR:BLUPR05MB274; x-ms-traffictypediagnostic: BLUPR05MB274: 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)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(3231020)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(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: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(189002)(199003)(6306002)(36756003)(5640700003)(6486002)(77096006)(6436002)(6916009)(14454004)(6506006)(316002)(58126008)(2501003)(54356999)(53936002)(99286004)(50986999)(83716003)(86362001)(97736004)(3480700004)(83506002)(6512007)(966005)(3280700002)(33656002)(3660700001)(478600001)(6116002)(3846002)(102836003)(101416001)(82746002)(2900100001)(2906002)(68736007)(5660300001)(2351001)(7116003)(106356001)(66066001)(1730700003)(105586002)(81156014)(8936002)(305945005)(81166006)(8676002)(7736002)(189998001)(25786009)(133083001); 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: <9DB578781D660C4CA8FDC810A6392AEA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 3891f5ca-f1e0-4094-d767-08d52176824b X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2017 22:18:41.7877 (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] draft agenda posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 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 22:18:46 -0000 DQpUaGUgZHJhZnQgYWdlbmRhIGZvciB0aGUgTkVUTU9EIHNlc3Npb25zIGhhcyBiZWVuIHBvc3Rl ZDoNCg0KICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAwL21hdGVyaWFs cy9hZ2VuZGEtMTAwLW5ldG1vZC8NCg0KVGhlcmUgYXJlIG5vIHNlc3Npb25zIGxpc3RlZCBmb3Ig dGhlIHRocmVlIE5NREEtdXBkYXRlDQptb2RlbCBkcmFmdHMgKHJmYzcyMjNiaXMsIHJmYzcyNzdi aXMsIHJmYzgwMjJiaXMpLiAgVGhleQ0Kd2lsbCBiZSBjb3ZlcmVkIHRvZ2V0aGVyIGJ5IHRoZSBj aGFpcnMgaW4gdGhlIGJlZ2lubmluZw0Kb2YgU2Vzc2lvbiAxLg0KDQpDaGVlcnMsIA0KS2VudCAo YW5kIExvdSkNCg0KDQoNCg== From nobody Wed Nov 1 15:35: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 DB3B513FF0B for ; Wed, 1 Nov 2017 15:35: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, 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 A5NJN_89KTQQ for ; Wed, 1 Nov 2017 15:35: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 AF63313F70B for ; Wed, 1 Nov 2017 15:35: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 7CC3AEE0; Wed, 1 Nov 2017 23:35:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id SOlUjTiwR532; Wed, 1 Nov 2017 23:35:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Nov 2017 23:35:18 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6910B20116; Wed, 1 Nov 2017 23:35:18 +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 y15tDcazyqA4; Wed, 1 Nov 2017 23:35:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1039920114; Wed, 1 Nov 2017 23:35:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1E7D54147B59; Wed, 1 Nov 2017 23:33:52 +0100 (CET) Date: Wed, 1 Nov 2017 23:33:52 +0100 From: Juergen Schoenwaelder To: Xufeng Liu Cc: 'Kent Watsen' , netmod@ietf.org Message-ID: <20171101223352.3es542cyjtsmrknp@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Xufeng Liu , 'Kent Watsen' , netmod@ietf.org References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <001c01d3534a$97f29860$c7d7c920$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001c01d3534a$97f29860$c7d7c920$@gmail.com> User-Agent: NeoMutt/20170714 (1.8.3) 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: Wed, 01 Nov 2017 22:35:22 -0000 Does 'Yes/support' imply "I've reviewed this document and believe it is ready for publication"? /js On Wed, Nov 01, 2017 at 03:49:53PM -0400, Xufeng Liu wrote: > Yes/support. > > Thanks, > - Xufeng > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > > Sent: Friday, October 20, 2017 5:38 PM > > To: netmod@ietf.org > > Subject: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07 > > > > 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 > > _______________________________________________ > 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 Nov 1 15:56: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 9C2B813FF09 for ; Wed, 1 Nov 2017 15:56:19 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja8SFKDEovQA for ; Wed, 1 Nov 2017 15:56:17 -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 A8BCF13F6A4 for ; Wed, 1 Nov 2017 15:56:17 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id k123so4694361qke.3 for ; Wed, 01 Nov 2017 15:56:17 -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=iJtbrRE9jNYKfhQTbL9DS2e7v1r0wGuRW5xAPk2RqEw=; b=K71jo7/8EaEKJTsV+F+7+J/VV0ZZhIA8c/Yi+MtOxNa6e+WGMLAo4vCmZrUSS76XWM m8KKbr226nM5Il8ApN2+waz/tRsk5njJTewaYW0MAvw27fj52ldLosuTAAqqYOjlN6fi VFSeubdE7ji/n/XZCHF+FNcJ9Qh9iElJFVCx5cCBKXm687yCTqOr2SG4CqRRAPkgjY8t WKiQhiQcJU56wHD3Q6BX5bF8orO3fl6qxllWhy6YsndzkA5hHx9CCjO5MICHod+8xEZ/ TGpvY4Tnlk4JUWeRu1vvez+vo5NptxPGS08AilsqOGAQyAmx3ria7t/RUFyXo4c4YVGi Pfwg== 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=iJtbrRE9jNYKfhQTbL9DS2e7v1r0wGuRW5xAPk2RqEw=; b=YiQvD1ujosGFJp0X7gli8bo8kBkxbAANHj7CLLJVqe4QkjWaVnH9sZD7iTBOBaItdg oAa0FiY3EDf/+BWhIR0f+St92dHSimVI9x+JWWsJJdzYV9BPZ7j0YgAPKitsCrjHekKa S5hgj7dmcfyAdVkhsIjJERaLL3vOG3XWfPSV1pd546QckDneawoLv+Oh0pMVG7ob9NdM 7fZe78Lm/Rkt+jaScQtOIc26xYapVfl+wMIKlPMN9gNQTqdVcG0ayViFAC2Wb4FzrKE0 Nyx+61bELUAeSG2cAOtrlJ0vQ0PXQTJio0AoZ2UIa39o/GXrWwlfofE5zY30QGHLj9q+ s4Mw== X-Gm-Message-State: AJaThX6RYbCmbvrD6hQzEnBWPvW8NweJc0gsLCUYBt3kBfw/jwA9R0N5 AMErjojaPHdKlZLGIIlzZc+ndTzo X-Google-Smtp-Source: ABhQp+SdRuJ+gkHRG+oSVRZbVplzFRDN+G1oxvxpRaSs8m2EdUYOTGqkQLx1yugLBwS+YieARp23uw== X-Received: by 10.55.19.228 with SMTP id 97mr2169447qkt.271.1509576976596; Wed, 01 Nov 2017 15:56:16 -0700 (PDT) Received: from [192.168.128.129] ([144.121.38.165]) by smtp.gmail.com with ESMTPSA id y62sm1137050qkb.92.2017.11.01.15.56.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Nov 2017 15:56:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dean Bogdanovic In-Reply-To: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> Date: Wed, 1 Nov 2017 18:56:15 -0400 Cc: "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4B6D7BB7-1986-4957-B36F-E2349DB55BBA@gmail.com> References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> To: Kent Watsen X-Mailer: Apple Mail (2.3273) 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: Wed, 01 Nov 2017 22:56:19 -0000 Kent, As other work I have authored depends on it, I have read the document = and think it's ready for publication.=20 Dean > On Oct 20, 2017, at 5:37 PM, Kent Watsen wrote: >=20 > All, >=20 > This starts a two-week working group last call on > draft-ietf-netmod-schema-mount-07. >=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=20 > 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,=20 > please also confirm one more time that they are=20 > 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 From nobody Wed Nov 1 16:43: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 2C9EC13F7D5 for ; Wed, 1 Nov 2017 16:43:15 -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 Z_t8Hk2DFFxP for ; Wed, 1 Nov 2017 16:43:11 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 334B6138BD6 for ; Wed, 1 Nov 2017 16:43:11 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id b85so3130109pfj.13 for ; Wed, 01 Nov 2017 16:43:11 -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=FgpnA02Jm/tj+279oEwwslFnWxFYFTPVTIQ2qJDTjac=; b=s+BXob94MXR9V4v0/WivxmGA/Mc0WyyinJA7zCPdP3TYD3RNFf++OoRyIzdV2358F7 3xM1m8qLn9fFjMC9FidTeYS01EoXhdrIrNWfdxerFB+Mcf857a6xvbsRAk0C9zvyFBFI 8Sqsv4u3M/i0xg4LVPJALP8BEd4W7V5hO0fKOuWxeDWJlWYSAN2Ra2Wv3lhbuyVBtpSC SOSz273AFhO7/RP/X2ZgpEUw9wvjBJFmqNYuqodBGn5l9oK48B55wzalNc/EeRM3ShFX d7qkLOtDeBwU74hvYc8roj7ssTdI/yzP16/MQj8J6smIml/KHmL1AbbPD0BFtmfgY/1a 7NrQ== 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=FgpnA02Jm/tj+279oEwwslFnWxFYFTPVTIQ2qJDTjac=; b=lyKEH4ovnlwCQktfAnOhvYtJ2+9lNS55o0o6MS3/uPyW+r1GyrIbWD0bSXRr1LyD4u 7Fs93VviCEF70pT77K8LKvVv9QIT5g0xZqxMJQk36cLI7z6CaC/WLdancnPbcR6yPiYu dkp+ViuRXrQnuRv0Sx0bp3UDfxDWQ8adFafdv/HyqODCZK++2PPXwbacP1DT7anP5Sfw 8ntmTVqvG5eyYCyeTkKxKpDBV2+TzQVK3m/onS0csMGjxZm6GYoo3JmLdXMnnI2ADJ1c sRPCQovpfnA2/8kviZBIG0q8QSAX6yyiXB9Go48nMcD5D7USDMQ2nLaPNy1ZxSl7eS8c k8rw== X-Gm-Message-State: AMCzsaX2BwVa/lGeYjx3wxEdepJekMXwzzc3vK3UT8y2+twKAQv+eVoK K4FPcf6qBv9+cuf3kQKaXgi0zQZ2 X-Google-Smtp-Source: ABhQp+S4p/Cb3k/k2LhdpiTTxZvE+huqB62l/ux/6WCH3zjoksYBme+mKFmHe6uNlmVQ4Hl0qwsoLA== X-Received: by 10.101.64.198 with SMTP id u6mr1541003pgp.44.1509579790555; Wed, 01 Nov 2017 16:43:10 -0700 (PDT) Received: from [192.168.99.103] ([103.42.216.254]) by smtp.gmail.com with ESMTPSA id 125sm2791758pff.14.2017.11.01.16.43.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Nov 2017 16:43:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8C4B3D5E-D3BE-433A-AEA5-5DF21A62C3D2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <20171101112249.wmq4ggx2ixgn4kqo@elstar.local> Date: Thu, 2 Nov 2017 06:13:04 +0630 Cc: Kristian Larsson , "netmod@ietf.org" Message-Id: References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <20171101112249.wmq4ggx2ixgn4kqo@elstar.local> To: Juergen Schoenwaelder 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: Wed, 01 Nov 2017 23:43:15 -0000 --Apple-Mail=_8C4B3D5E-D3BE-433A-AEA5-5DF21A62C3D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Juergen, > On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder = wrote: >=20 > Mahesh, >=20 > I think the question is why we need to have different match containers > for each possible feature set combination instead of having a single > match container with groups of leafs in it marked as features. This > would seem to cut down the size of the module and the tree diagram > significantly. I think this will also make clients simpler sicne they > do not have to select a certain container based on the feature set > announced.=20 The current design of match containers was chosen to allow platforms to = select one container that matched what the hardware supported from a l2, = l3 and ipv{4,6} perspective. I would argue that even though the overall = diagram is bigger with this design, once the platform selects the = container of choice, the tree and the configuration itself would be a = little simpler/smaller.=20 Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The = current tree looks like this: | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}? | | | +--rw destination-mac-address? = yang:mac-address | | | +--rw destination-mac-address-mask? = yang:mac-address | | | +--rw source-mac-address? = yang:mac-address | | | +--rw source-mac-address-mask? = yang:mac-address | | | +--rw ethertype? = eth:ethertype | | | +--rw dscp? inet:dscp | | | +--rw ecn? uint8 | | | +--rw length? uint16 | | | +--rw ttl? uint8 | | | +--rw protocol? uint8 | | | +--rw source-port-range! | | | | +--rw lower-port inet:port-number | | | | +--rw upper-port? inet:port-number | | | | +--rw operation? operator | | | +--rw destination-port-range! | | | | +--rw lower-port inet:port-number | | | | +--rw upper-port? inet:port-number | | | | +--rw operations? operator | | | +--rw ihl? uint8 | | | +--rw flags? bits | | | +--rw offset? uint16 | | | +--rw identification? uint16 | | | +--rw destination-ipv4-network? = inet:ipv4-prefix | | | +--rw source-ipv4-network? = inet:ipv4-prefix | | | +--rw next-header? uint8 | | | +--rw destination-ipv6-network? = inet:ipv6-prefix | | | +--rw source-ipv6-network? = inet:ipv6-prefix | | | +--rw flow-label? | | | inet:ipv6-flow-label whereas, if the design went with one match container with each group of = leafs in their own container (to support the if-feature statement for = that container), the tree would look like this: | | +--rw l2-acl {l2-acl}? | | | +--rw destination-mac-address? = yang:mac-address | | | +--rw destination-mac-address-mask? = yang:mac-address | | | +--rw source-mac-address? = yang:mac-address | | | +--rw source-mac-address-mask? = yang:mac-address | | | +--rw ethertype? = eth:ethertype | | +--rw ipv4-acl {ipv4-acl}? | | | +--rw dscp? inet:dscp | | | +--rw ecn? uint8 | | | +--rw length? uint16 | | | +--rw ttl? uint8 | | | +--rw protocol? uint8 | | | +--rw source-port-range! | | | | +--rw lower-port inet:port-number | | | | +--rw upper-port? inet:port-number | | | | +--rw operation? operator | | | +--rw destination-port-range! | | | | +--rw lower-port inet:port-number | | | | +--rw upper-port? inet:port-number | | | | +--rw operations? operator | | | +--rw ihl? uint8 | | | +--rw flags? bits | | | +--rw offset? uint16 | | | +--rw identification? uint16 | | | +--rw destination-ipv4-network? = inet:ipv4-prefix | | | +--rw source-ipv4-network? = inet:ipv4-prefix | | +--rw ipv6-acl {ipv6-acl}? | | | +--rw dscp? inet:dscp | | | +--rw ecn? uint8 | | | +--rw length? uint16 | | | +--rw ttl? uint8 | | | +--rw protocol? uint8 | | | +--rw source-port-range! | | | | +--rw lower-port inet:port-number | | | | +--rw upper-port? inet:port-number | | | | +--rw operation? operator | | | +--rw destination-port-range! | | | | +--rw lower-port inet:port-number | | | | +--rw upper-port? inet:port-number | | | | +--rw operations? operator | | | +--rw next-header? uint8 | | | +--rw destination-ipv6-network? = inet:ipv6-prefix | | | +--rw source-ipv6-network? = inet:ipv6-prefix | | | +--rw flow-label? = inet:ipv6-flow-label The difference though is small and comes down to a preference. Select = one feature statement and get one container with everything in it, or = define multiple feature statements and assemble together the pieces to = define the ACE entry. > BTW, how do I filter on TCP flags in combination with > a source IP address? There seem to be reasonable combinations of > features not even covered. If the platform has declared support for feature that includes ipv4 = (and/or ipv6) and tcp-acl, for a given ACE entry, it should be able to = define a match filter that includes both the source IP address and the = TCP flags. Do you see something that prevents it? Thanks. >=20 > /js >=20 > On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote: >> Kristian, >>=20 >> I think there is confusion in how the ACL model is going to be = implemented by vendors and used by customers. >>=20 >> As Eliot alluded to, the model is trying to address the issue of the = capabilities of each platform as they exist across the industry but also = within each vendor. So the first thing an implementation would do is to = pick which feature they do support. A low end platform that supports = only layer 2 ACL will pick l2-acl as their feature, while a high end = router capable of support l2 and l3, ipv4 and ipv6 ACL will declare = l2-l3-ipv4-ipv6 as the feature they support. That pretty much takes out = all the other containers in the matches container. The additional = features they might want to choose include support for TCP, UDP and = ICMP. For a high end router this boils down to having definitions for >>=20 >> - ethernet >> - ipv4 >> - ipv6 >> - tcp >> - udp >> - icmp >>=20 >> which is the list you have in mind, but this time making sure that = the platform is capable of supporting each one of the definitions. = Imagine if the low end platform advertised a model for all the above = capabilities only to reject them when you tried to configure a ipv6 = address that it already knows it cannot support. >>=20 >> Similarly the condition on tcp/udp/icmp container is to make sure the = platform is capable of supporting them. Only if the platform declares = tcp-acl, udp-acl, and icmp-acl feature, will those containers be visible = from a configuration perspective. >>=20 >> The acl-type is used as a check to make sure the user is aware what = kind of ACL the platform supports and the ACL they are trying to = configure matches the acl-type. If the platform declared the feature = l2-acl and if the user tries to set the ACL type to l2-l3-ipv4-ipv6 then = the configuration would be rejected. In the Linux/nftables case, the = platform should declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, = and icmp-acl if that is what it wants to support. The interface = attachment point has been defined but it is not mandatory that a = configuration has to define it. So if in Linux, the ACL list is global, = one would not define a attachment point, which implies it is a global = list. >>=20 >> I will take a look at the remaining issues/comments you raise, but I = wanted to make sure that the overall design of the model was clear, = which from this email I can only guess could be made more clear. >>=20 >> Cheers. >>=20 >>> On Oct 31, 2017, at 4:55 PM, Kristian Larsson = wrote: >>>=20 >>> On Fri, Oct 20, 2017 at 09:37:04PM +0000, Kent Watsen wrote: >>>>=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 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>> 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. >>>=20 >>> The ipv4 container is conditioned on the acl-type being one of >>> ipv4-acl, l2-l3-ipv4-acl, l2-l3-ipv4-ipv6-acl. >>>=20 >>> The ipv6 container is conditioned on the acl-type being one of >>> ipv6-acl, l2-l3-ipv6-acl, l2-l3-ipv4-ipv6-acl. >>>=20 >>> 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. >>>=20 >>> 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=3Dtcp/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. >>>=20 >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>>=20 >>> 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. >>>=20 >>>=20 >>>=20 >>> 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=3Ddrop >>> * 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. >>>=20 >>> Again, apologies for my ignorance. >>>=20 >>> Kind regards, >>> Kristian. >>>=20 >>>=20 >>> --=20 >>> Kristian Larsson KLL-RIPE >>> +46 704 264511 kll@spritelink.net >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_8C4B3D5E-D3BE-433A-AEA5-5DF21A62C3D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Juergen,

On Nov 1, 2017, at 5:52 PM, = Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

Mahesh,

I think the question is = why we need to have different match containers
for each = possible feature set combination instead of having a single
match container with groups of leafs in it marked as = features. This
would seem to cut down the size of the = module and the tree diagram
significantly. I think this = will also make clients simpler sicne they
do not have to = select a certain container based on the feature set
announced. 

The = current design of match containers was chosen to allow platforms to = select one container that matched what the hardware supported from a l2, = l3 and ipv{4,6} perspective. I would argue that even though the overall = diagram is bigger with this design, once the platform selects the = container of choice, the tree and the configuration itself would be a = little simpler/smaller. 

Take = the case where the desired selection is l2,-l3, ipv4 and ipv6. The = current tree looks like this:

        |        |  +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}?
        |        |  |  +--rw destination-mac-address?        =
yang:mac-address
        |        |  |  +--rw destination-mac-address-mask?   =
yang:mac-address
        |        |  |  +--rw source-mac-address?             =
yang:mac-address
        |        |  |  +--rw source-mac-address-mask?        =
yang:mac-address
        |        |  |  +--rw ethertype?                      =
eth:ethertype
        |        |  |  +--rw dscp?                           inet:dscp
        |        |  |  +--rw ecn?                            uint8
        |        |  |  +--rw length?                         uint16
        |        |  |  +--rw ttl?                            uint8
        |        |  |  +--rw protocol?                       uint8
        |        |  |  +--rw source-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operation?    operator
        |        |  |  +--rw destination-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operations?   operator
        |        |  |  +--rw ihl?                            uint8
        |        |  |  +--rw flags?                          bits
        |        |  |  +--rw offset?                         uint16
        |        |  |  +--rw identification?                 uint16
        |        |  |  +--rw destination-ipv4-network?       =
inet:ipv4-prefix
        |        |  |  +--rw source-ipv4-network?            =
inet:ipv4-prefix
        |        |  |  +--rw next-header?                    uint8
        |        |  |  +--rw destination-ipv6-network?       =
inet:ipv6-prefix
        |        |  |  +--rw source-ipv6-network?            =
inet:ipv6-prefix

        |        |  |  +--rw flow-label?
        |        |  |          inet:ipv6-flow-label


whereas, if the design went with one match = container with each group of leafs in their own container (to support = the if-feature statement for that container), the tree would look like = this:

        |        =
|  +--rw l2-acl {l2-acl}?
        |        |  |  +--rw destination-mac-address?        =
yang:mac-address
        |        |  |  +--rw destination-mac-address-mask?   =
yang:mac-address
        |        |  |  +--rw source-mac-address?             =
yang:mac-address
        |        |  |  +--rw source-mac-address-mask?        =
yang:mac-address
        |        |  |  +--rw ethertype?                      =
eth:ethertype

        |        |  +--rw ipv4-acl {ipv4-acl}?
        |        |  |  +--rw dscp?                       inet:dscp
        |        |  |  +--rw ecn?                        uint8
        |        |  |  +--rw length?                     uint16
        |        |  |  +--rw ttl?                        uint8
        |        |  |  +--rw protocol?                   uint8
        |        |  |  +--rw source-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operation?    operator
        |        |  |  +--rw destination-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operations?   operator
        |        |  |  +--rw ihl?                        uint8
        |        |  |  +--rw flags?                      bits
        |        |  |  +--rw offset?                     uint16
        |        |  |  +--rw identification?             uint16
        |        |  |  +--rw destination-ipv4-network?   =
inet:ipv4-prefix
        |        |  |  +--rw source-ipv4-network?        =
inet:ipv4-prefix
        |        |  +--rw ipv6-acl {ipv6-acl}?
        |        |  |  +--rw dscp?                       inet:dscp
        |        |  |  +--rw ecn?                        uint8
        |        |  |  +--rw length?                     uint16
        |        |  |  +--rw ttl?                        uint8
        |        |  |  +--rw protocol?                   uint8
        |        |  |  +--rw source-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operation?    operator
        |        |  |  +--rw destination-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operations?   operator
        |        |  |  +--rw next-header?                uint8
        |        |  |  +--rw destination-ipv6-network?   =
inet:ipv6-prefix
        |        |  |  +--rw source-ipv6-network?        =
inet:ipv6-prefix
        |        |  |  +--rw flow-label?                 =
inet:ipv6-flow-label

The difference though is small and comes down to a = preference. Select one feature statement and get one container with = everything in it, or define multiple feature statements and assemble = together the pieces to define the ACE entry.

BTW, how do I filter on TCP flags in combination with
a source IP address? There seem to be reasonable combinations = of
features not even covered.

If the platform has declared support for feature that = includes ipv4 (and/or ipv6) and tcp-acl, for a given ACE entry, it = should be able to define a match filter that includes both the source IP = address and the TCP flags. Do you see something that prevents = it?

Thanks.


/js

On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani = wrote:
Kristian,

I think there is confusion in how the ACL = model is going to be implemented by vendors and used by customers.

As Eliot alluded to, the model is trying to = address the issue of the capabilities of each platform as they exist = across the industry but also within each vendor. So the first thing an = implementation would do is to pick which feature they do support. A low = end platform that supports only layer 2 ACL will pick l2-acl as their = feature, while a high end router capable of support l2 and l3, ipv4 and = ipv6 ACL will declare l2-l3-ipv4-ipv6 as the feature they support. That = pretty much takes out all the other containers in the matches container. = The additional features they might want to choose include support for = TCP, UDP and ICMP. For a high end router this boils down to having = definitions for

- ethernet
- = ipv4
- ipv6
- tcp
- udp
- icmp

which is the list you = have in mind, but this time making sure that the platform is capable of = supporting each one of the definitions. Imagine if the low end platform = advertised a model for all the above capabilities only to reject them = when you tried to configure a ipv6 address that it already knows it = cannot support.

Similarly the condition on = tcp/udp/icmp container is to make sure the platform is capable of = supporting them. Only if the platform declares tcp-acl, udp-acl, and = icmp-acl feature, will those containers be visible from a configuration = perspective.

The acl-type is used as a = check to make sure the user is aware what kind of ACL the platform = supports and the ACL they are trying to configure matches the acl-type. = If the platform declared the feature l2-acl and if the user tries to set = the ACL type to l2-l3-ipv4-ipv6 then the configuration would be = rejected. In the Linux/nftables case, the platform should declare the = feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and icmp-acl if that is what = it wants to support. The interface attachment point has been defined but = it is not mandatory that a configuration has to define it. So if in = Linux, the ACL list is global, one would not define a attachment point, = which implies it is a global list.

I will = take a look at the remaining issues/comments you raise, but I wanted to = make sure that the overall design of the model was clear, which from = this email I can only guess could be made more clear.

Cheers.

On Oct 31, 2017, at 4:55 PM, Kristian Larsson <kristian@spritelink.net> wrote:

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=3Dtcp/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=3Ddrop
* 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 =             &n= bsp;           &nbs= p;            =   KLL-RIPE
+46 704 264511 =             &n= bsp;           &nbs= p;      kll@spritelink.net

_______________________________________________
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

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

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_8C4B3D5E-D3BE-433A-AEA5-5DF21A62C3D2-- From nobody Wed Nov 1 17:05:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7445013F43E for ; Wed, 1 Nov 2017 17:05:33 -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 Ga4zZZtOsnCs for ; Wed, 1 Nov 2017 17:05:30 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 9580E13942C for ; Wed, 1 Nov 2017 17:05:30 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id s75so3492985pgs.0 for ; Wed, 01 Nov 2017 17:05:30 -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=b0HxWBccIaMNyg/0HAWP4Kx6cgNLLVRFKSCNIDYZLKU=; b=Kao7cPtrn+ky3ZB1M/o/ol61nj0URANfT14NRdHPUgR7zbzNj1YH3/o5iIDKFPj4mu tu0+8LBDl3vnaHX08BllQytT/RQcP9kDJosEd1P9BCHnmY3b80XYtfP0fiUwZNb9VsOT 3Rh9D8C6HvkEZwQqx5glPxLurMV8+lCBVwgI6tLwMZp9qStV7wDrLDxlb2rgky6ZSFyq UrE90tvS9WqWqqKPBkNBs2h4Y6rx3w/5NF/dUCAE44nU/eeudy6Est1MIRaiYhnk9F3k QsexVMMXo6ZBOI9MlRncwe6Q8bADzJgls3efF3ARx8DMz4j8okNutOYjN2fYjiqf9XY8 YUxQ== 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=b0HxWBccIaMNyg/0HAWP4Kx6cgNLLVRFKSCNIDYZLKU=; b=BIRpue0Sy1WLv+kzSQXXAHc01gCpNgk/1c63vFiWQke3xHxdqGWNmcoKUmGPtiNZE2 qspHUveZEd7fxj2nSDODeaMCVOlCoYGNSz1WlKB+KJOorw2gVkMJ63h3m4Nt5/ZtbC0b qPyk7o9ZOemLpjPdab78eoBWl5OVUSqS1yKU3daCfSuJlDPDZEvMA6HkI3Znh9bOZTzV La5sGq+eLaHifIy0gZH0RqfemvT9i74ELxbnpdqLSFs7SWNVAs8vv2CmgVSmxZrlTj3l 9+aDEi2DcFbfECGYpW17GvyiLan3NW1N1St0UzjYb5fZ6UsrWmDH/3QJPid/yU+OL5uT bB4g== X-Gm-Message-State: AMCzsaUcS4QVNkhUNiEm8Hz38o46dErCuUHB0dsWo8pSi9M9PoYhuEm2 VDENYlI1CBje/Z+dMFgOkA8= X-Google-Smtp-Source: ABhQp+QRrFadKEuIl633wvXra++I0JPkk9yLGc/lNKFFJReNShqfNZeLJM1sjFAXzaO/Q7bDMDyTaA== X-Received: by 10.84.244.6 with SMTP id g6mr1288375pll.148.1509581130050; Wed, 01 Nov 2017 17:05:30 -0700 (PDT) Received: from [192.168.99.103] ([103.42.216.254]) by smtp.gmail.com with ESMTPSA id h67sm3475509pfh.74.2017.11.01.17.05.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Nov 2017 17:05:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B3FB1FA1-4A1B-4C35-BC18-E00946D1969A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <20171101155758.GB12688@spritelink.se> Date: Thu, 2 Nov 2017 06:35:25 +0630 Cc: "netmod@ietf.org" Message-Id: References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <20171101132631.GD25608@spritelink.se> <20171101155758.GB12688@spritelink.se> To: Kristian Larsson 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, 02 Nov 2017 00:05:33 -0000 --Apple-Mail=_B3FB1FA1-4A1B-4C35-BC18-E00946D1969A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kristian, > On Nov 1, 2017, at 10:27 PM, Kristian Larsson = wrote: >=20 > I think there's a problem with the current approach for features > where it conflates the limitations of the device with the > limitations of an attachment point. Ultimately it is the > limitations of the attachment point that matter. Creating an ACL > in config on a device doesn't actually mean anything until you > attach it somewhere. >=20 > It's not hard to imagine a device where different limitations > apply, let's say a fairly simple Ethernet switch built on some > commodity chip. It consists of, say: > * 24 * 10GE on a commodity chip > * some control plane (a x86 PC) connected to that commodity chip >=20 > The commodity chip supports matching ethernet headers, so ACLs > attached to those ports are "eth-acl". The control plane on the > other hand supports complex matching on anything you can imagine. > What YANG features should such a device advertise? The feature statement is a =E2=80=9Cstatic=E2=80=9D statement that a = particular implementation defines for what it supports across the entire = device. YANG does not allow for a feature to be defined for a particular = node in the model.=20 For the behavior you desire, one would define a feature statement that = covers everything the device supports, and will have to use must = statements to control what parts of the model get supported by the ports = and what parts of the model are supported in the control plane. That = will usually be a implementation level detail that this model cannot = cover. Thanks. >=20 > kll >=20 >=20 >=20 >=20 > On Wed, Nov 01, 2017 at 02:26:31PM +0100, Kristian Larsson wrote: >> Mahesh, >>=20 >> On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote: >>> I think there is confusion in how the ACL model is going to be >>> implemented by vendors and used by customers. >>>=20 >>> As Eliot alluded to, the model is trying to address the issue >>> of the capabilities of each platform as they exist across the >>> industry but also within each vendor. So the first thing an >>> implementation would do is to pick which feature they do >>> support. A low end platform that supports only layer 2 ACL will >>> pick l2-acl as their feature, while a high end router capable >>> of support l2 and l3, ipv4 and ipv6 ACL will declare >>> l2-l3-ipv4-ipv6 as the feature they support. That pretty much >>> takes out all the other containers in the matches container. >>> The additional features they might want to choose include >>> support for TCP, UDP and ICMP. For a high end router this boils >>> down to having definitions for >>>=20 >>> - ethernet >>> - ipv4 >>> - ipv6 >>> - tcp >>> - udp >>> - icmp >>>=20 >>> which is the list you have in mind, but this time making sure >>> that the platform is capable of supporting each one of the >>> definitions. Imagine if the low end platform advertised a model >>> for all the above capabilities only to reject them when you >>> tried to configure a ipv6 address that it already knows it >>> cannot support. >>=20 >> You imply that the low end platform would advertise features that >> it doesn't support. Why would it do that? >>=20 >> I don't suggest removing features - only restructure where the >> data is held. In my example, under the ethernet container I can >> do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the >> device supports a given feature so why are you saying that we >> need different containers for the ethernet matching part of an >> ACL of type eth-acl vs say eth-ipv4-acl? >>=20 >> Right now the features themselves affect the structure of the >> model and thus the data, which I rather dislike. The config to >> match e.g. ethernet headers should always go in the same place. >>=20 >> The model gives the illusion of supporting "unified" ACLs but >> actually doesn't at all. >>=20 >>=20 >>> Similarly the condition on tcp/udp/icmp container is to make >>> sure the platform is capable of supporting them. Only if the >>> platform declares tcp-acl, udp-acl, and icmp-acl feature, will >>> those containers be visible from a configuration perspective. >>=20 >> And if the device supports all of those features I can write an >> ACE that matches on TCP flags at and ICMP types.. and it would >> validate according to the model but cleary makes no sense. >>=20 >>> The acl-type is used as a check to make sure the user is aware >>> what kind of ACL the platform supports and the ACL they are >>> trying to configure matches the acl-type. If the platform >>> declared the feature l2-acl and if the user tries to set the >>> ACL type to l2-l3-ipv4-ipv6 then the configuration would be >>> rejected. >>=20 >> Another way of structuring this is to have completely different >> lists of ACLs where each type of ACL is its own list, e.g. >> * eth-acl >> * ipv4-acl >> * ipv6-acl >> * eth-ipv4-ipv6-acl >>=20 >> What advantage do you think your currently proposed model holds >> over such an approach? >>=20 >> What are your thoughts on the attachment point using two leaves? >> Are you satisfied with this? >>=20 >>=20 >>> In the Linux/nftables case, the platform should >>> declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and >>> icmp-acl if that is what it wants to support. The interface >>> attachment point has been defined but it is not mandatory that >>> a configuration has to define it. So if in Linux, the ACL list >>> is global, one would not define a attachment point, which >>> implies it is a global list. >>=20 >> Naturally one has to define an attachment point or the system >> wouldn't know which one of potentially multiple ACLs to apply to >> nftables. It might however be up to another YANG model to define >> that attachment point. >>=20 >> The list of features seem to align poorly with reality. How can >> we have a list of attachment points in the model but without >> if-feature wrapping it? Surely a Linux machine must be able to >> announce that it doesn't support per-interface ACLs? A side >> question is why that attachment list exists in the first place - >> why isn't it an augmentation of the interfaces module? >>=20 >> kll >>=20 >> --=20 >> Kristian Larsson KLL-RIPE >> +46 704 264511 kll@spritelink.net >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Kristian Larsson KLL-RIPE > +46 704 264511 kll@spritelink.net Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_B3FB1FA1-4A1B-4C35-BC18-E00946D1969A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kristian,

On Nov 1, 2017, at 10:27 PM, = Kristian Larsson <kristian@spritelink.net> wrote:

I = think there's a problem with the current approach for features
where it conflates the limitations of the device with the
limitations of an attachment point.  Ultimately it is = the
limitations of the attachment point that matter. = Creating an ACL
in config on a device doesn't actually = mean anything until you
attach it somewhere.

It's not hard to imagine a device where = different limitations
apply, let's say a fairly simple = Ethernet switch built on some
commodity chip. It consists = of, say:
* 24 * 10GE on a commodity chip
* = some control plane (a x86 PC) connected to that commodity chip

The commodity chip supports matching ethernet = headers, so ACLs
attached to those ports are "eth-acl". = The control plane on the
other hand supports complex = matching on anything you can imagine.
What YANG features = should such a device advertise?

The = feature statement is a =E2=80=9Cstatic=E2=80=9D statement that a = particular implementation defines for what it supports across the entire device. YANG does not allow for a = feature to be defined for a particular node in the = model. 

For the behavior you = desire, one would define a feature statement that covers everything the = device supports, and will have to use must statements to control what = parts of the model get supported by the ports and what parts of the = model are supported in the control plane. That will usually be a = implementation level detail that this model cannot cover.

Thanks.


=   kll




On Wed, Nov 01, 2017 at 02:26:31PM +0100, = Kristian Larsson wrote:
Mahesh,

On Wed, Nov 01, 2017 at = 05:13:18PM +0630, Mahesh Jethanandani wrote:
I think there is confusion in how the ACL model = is going to be
implemented by vendors and used by = customers.

As Eliot alluded to, the model = is trying to address the issue
of the capabilities of each = platform as they exist across the
industry but also within = each vendor. So the first thing an
implementation would do = is to pick which feature they do
support. A low end = platform that supports only layer 2 ACL will
pick l2-acl = as their feature, while a high end router capable
of = support l2 and l3, ipv4 and ipv6 ACL will declare
l2-l3-ipv4-ipv6 as the feature they support. That pretty = much
takes out all the other containers in the matches = container.
The additional features they might want to = choose include
support for TCP, UDP and ICMP. For a high = end router this boils
down to having definitions for

- ethernet
- ipv4
- = ipv6
- tcp
- udp
- icmp

which is the list you have in mind, but this = time making sure
that the platform is capable of = supporting each one of the
definitions. Imagine if the low = end platform advertised a model
for all the above = capabilities only to reject them when you
tried to = configure a ipv6 address that it already knows it
cannot = support.

You imply that the = low end platform would advertise features that
it doesn't = support. Why would it do that?

I don't = suggest removing features - only restructure where the
data = is held.  In my example, under the ethernet container I can
do: if-feature "eth-acl or eth-ipv4-acl..."; to check if = the
device supports a given feature so why are you saying = that we
need different containers for the ethernet = matching part of an
ACL of type eth-acl vs say = eth-ipv4-acl?

Right now the features = themselves affect the structure of the
model and thus the = data, which I rather dislike. The config to
match e.g. = ethernet headers should always go in the same place.

The model gives the illusion of supporting "unified" ACLs = but
actually doesn't at all.


Similarly = the condition on tcp/udp/icmp container is to make
sure = the platform is capable of supporting them. Only if the
platform declares tcp-acl, udp-acl, and icmp-acl feature, = will
those containers be visible from a configuration = perspective.

And if the device = supports all of those features I can write an
ACE that = matches on TCP flags at and ICMP types.. and it would
validate according to the model but cleary makes no sense.

The = acl-type is used as a check to make sure the user is aware
what kind of ACL the platform supports and the ACL they = are
trying to configure matches the acl-type. If the = platform
declared the feature l2-acl and if the user tries = to set the
ACL type to l2-l3-ipv4-ipv6 then the = configuration would be
rejected.

Another way of structuring this = is to have completely different
lists of ACLs where each = type of ACL is its own list, e.g.
* eth-acl
= * ipv4-acl
* ipv6-acl
* = eth-ipv4-ipv6-acl

What advantage do you = think your currently proposed model holds
over such an = approach?

What are your thoughts on the = attachment point using two leaves?
Are you satisfied with = this?


In the Linux/nftables case, the platform = should
declare the feature l2-l3-ipv4-ipv6, tcp-acl, = udp-acl, and
icmp-acl if that is what it wants to support. = The interface
attachment point has been defined but it is = not mandatory that
a configuration has to define it. So if = in Linux, the ACL list
is global, one would not define a = attachment point, which
implies it is a global list.

Naturally one has to define an = attachment point or the system
wouldn't know which one of = potentially multiple ACLs to apply to
nftables. It might = however be up to another YANG model to define
that = attachment point.

The list of features seem = to align poorly with reality. How can
we have a list of = attachment points in the model but without
if-feature = wrapping it? Surely a Linux machine must be able to
announce= that it doesn't support per-interface ACLs? A side
question= is why that attachment list exists in the first place -
why= isn't it an augmentation of the interfaces module?

  kll

--
Kristian Larsson =             &n= bsp;           &nbs= p;            =   KLL-RIPE
+46 704 264511 =             &n= bsp;           &nbs= p;      kll@spritelink.net

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

--
Kristian = Larsson =             &n= bsp;           &nbs= p;            =   KLL-RIPE
+46 704 264511 =             &n= bsp;           &nbs= p;      kll@spritelink.net

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_B3FB1FA1-4A1B-4C35-BC18-E00946D1969A-- From nobody Wed Nov 1 17:12: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 90BFE13F63E for ; Wed, 1 Nov 2017 17:12: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 WI3ZbmDLyysI for ; Wed, 1 Nov 2017 17:12:28 -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 1DC7C1385C2 for ; Wed, 1 Nov 2017 17:12:28 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id a2so4390699lfh.11 for ; Wed, 01 Nov 2017 17:12: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=J99lEPDkOBr9KDNaDOmzZtNsEjEnZx3B4kDFrnnUiMk=; b=EaM6EGaHUuA8tOoaZTqE97RXQfxrMcSphELZR71k/mCmzHhAgCpjFDEUmE4uCLCN4m DylOtAw08UB+eCiGkQNCO1MVqjSKXMlM57ytc8G9pYGxOvLOSNB2tUflG/IIUGYy/d4W wWBH/eVFhkwPRI5BE20iKSxZNXD9CfM7LfIqUHhOSX1k7khDEsAExlLRfsHiM3pIWttC iiezKerDKcjTUSe7kZQOX7ZDtvmBfj+qe7W7mF8KuDKDLQvAu0Yjd5WjtHkfK6LwDt3U HMYt8dmMRwATAWny/CgzEPtwcgAlXla5koy4UZOm19skAnjDQ9t7irBJKwYAJsICWQZI k0+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J99lEPDkOBr9KDNaDOmzZtNsEjEnZx3B4kDFrnnUiMk=; b=JDlvvX4U8q6OPChtWIkj+z0aKs070DnUxq9qdDOQJ4I6CHdiz7vEIvD8R/rrU6BBnw 8OeEqDsp5zHsEBeBiitIjcD/pXQITaVSn9nVMhIYNzZTDh8ftyftgYfwoWHRImCGkfJV KcfnW+zL1fxAa+ZVkblkTKOm170TkbPaOxLudvMhHeHaW6HX9XD3eUATncFHqOMHGhJc FvK6/YgABIN1nnfRPdw5UXBEvPUlADV9nYi7+ilEowac3nrO8IJ48T2jN2xINGsV7A1v pGkFdbWwB5sawIGdIjHGn61iVCYfxeU/8dCAt13ce1/96rgKSk0iOaNTDrrTqJJ+tXeB 5PiQ== X-Gm-Message-State: AJaThX5HxaJUsxfjhOfMO7M1DQeLvTZiwbsE8R7hOXm2a6RHlKZHq58i 3ZbUm5NYVVagrXJMWSc1ID7pdgj6aqNYuZabaubBRw== X-Google-Smtp-Source: ABhQp+Q3mf4I+3TG1g94OSkleH8y/SjzSzY+8XKkJ1RCyB8Ylt7LL6TM/waL1vbMpR5Y66Jij40T0LnCbINujnXpUSk= X-Received: by 10.25.156.66 with SMTP id f63mr505328lfe.194.1509581546349; Wed, 01 Nov 2017 17:12:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.81.211 with HTTP; Wed, 1 Nov 2017 17:12:24 -0700 (PDT) In-Reply-To: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> From: Andy Bierman Date: Wed, 1 Nov 2017 17:12:24 -0700 Message-ID: To: Kent Watsen Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a11411bc6d47b8c055cf4d757" 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: Thu, 02 Nov 2017 00:12:30 -0000 --001a11411bc6d47b8c055cf4d757 Content-Type: text/plain; charset="UTF-8" Hi, I have read this draft a few times. I have not implemented the draft but it seems reasonably constrained. here are some comments. Sec 1: seems like a lot of background on YANG and then some explanation of the solution. The problem statement is never really explained. Some discussion of building blocks for virtual servers might help. Sec. 3.3: there are no examples of multiple level schema -mounts. What is the use-case for this complexity? Sec. 4: an instance document showing the config for the example would help Sec. 5: A NETCONF example of an RPC converted to action would help. Also mention action converted to deeper nested action would help. Sec. A.4 has a very terse RESTCONF example. Sec. 8: There are no examples using the mount-point extension-stmt Why is this restriction in the text? It is not explained. The 'mount-point' statement MUST NOT be used in a YANG version 1 module, neither explicitly nor via a 'uses' statement. I do not understand why the mount-point subtree is needed twice in the YANG module. Why is the list duplicated under each schema entry? An example showing the entire YANG module would help. Seems like a lot of duplication of the YANG library. Why is the entire schema-mounts container config=false? There is no standard way to configure the schema mounts? All this data is configured via proprietary models, probably with even more copies of the YANG library? Andy On Fri, Oct 20, 2017 at 2:37 PM, 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 > --001a11411bc6d47b8c055cf4d757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have read this draft a few times.=
I have not implemented the draft but it seems reasonably constra= ined.

here are some comments.

=
Sec 1: seems like a lot of background on YANG and then some explanatio= n
of the solution.=C2=A0 The problem statement is never really ex= plained.
Some discussion of building blocks for virtual servers m= ight help.

Sec. 3.3: there are no examples of mult= iple level schema -mounts.
What is the use-case for this complexi= ty?

Sec. 4: an instance document showing the confi= g for the example would help

Sec. 5: A NETCONF exa= mple of an RPC converted to action would help.
Also mention actio= n converted to deeper nested action would help.
Sec. A.4 has a ve= ry terse RESTCONF example.

Sec. 8: There are no ex= amples using the mount-point extension-stmt
Why is this restricti= on in the text? It is not explained.
          The 'mount-point' statement MUST NOT be used in a Y=
ANG
          version 1 module, neither explicitly nor via a 'uses'
          statement.

I do not understand why the mount-point sub= tree is needed twice in the YANG module.
Why is the list duplicat= ed under each schema entry?
An example showing the entire YANG mo= dule would help.
Seems like a lot of duplication of the YANG libr= ary.

Why is the entire schema-mounts container con= fig=3Dfalse?
There is no standard way to configure the schema mou= nts?
All this data is configured via proprietary models, probably=
with even more copies of the YANG library?

<= div>

Andy


<= div>

On Fri, Oct 20, 2017 at 2:37 PM, Kent Watsen <kwatsen@juniper.net= > 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

--001a11411bc6d47b8c055cf4d757-- From nobody Wed Nov 1 20:32: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 76E4F13FBCF for ; Wed, 1 Nov 2017 20:32:37 -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 Lm5LdCm1-3kq for ; Wed, 1 Nov 2017 20:32:35 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 C250F13F844 for ; Wed, 1 Nov 2017 20:32:35 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id k7so3890795pga.3 for ; Wed, 01 Nov 2017 20:32:35 -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=T4pyYEU7vUBaaJVGDYqSpqqmv/JoP/HvGzi0qHpYac8=; b=iAdTzwKPJla6UED//gXBAtQhtIWwqcDFs9pOx2IkTT9IBu27F+J7xxBDP3/Y95GuPS 4l6bGfYC0FlREFLX3U6iqDh8dP2iAhVFA9WnZhTy4qANGr/+O6xfaq2rRxD/v5QVjv4V 9bd+n79LLpy+CtEdwEAPtURAwwZzhFdn+9arMJnylPWKmOL1Htwb/zHbvffY/7CRIKvA YuZGotbvkjahBxrXFU76ShIfxPimZ+KC9w+iXLOtpAU0of86eZJfw6yn5UxEuW/DrUe8 78El81BtUBo14G0czjWimLCn2c9dgzvWLUCokmXBxVJgfy22Y/G4ede8JhB4hUM6jpIO 0TUw== 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=T4pyYEU7vUBaaJVGDYqSpqqmv/JoP/HvGzi0qHpYac8=; b=oolexFncxW3YMj0MgkpnksayxTTaRw3FN5HBWHu+felzjhDVoggt8NC9xgxFUlu56y Cfsan4ST771l713dDtMnxZH6i/V8LHD8RWanvp9w+4z4x5ql9d4k8nlEWLISDrEKBd/9 ki2vv9TinEDjDlT7M3a75o3E+oZsWcWbbXNCMoQXavo/nkSoo7nTPyPqc1DhtqTILo9E C6z7d2mbFWriGFjMxvHmGfrfRHVdOf/umijQDpNTl5qHuHpV93olQVDNUYmo/3l0dwJT ln13nU/EpuLpDz5sFw1FdUAQ6UgnbBezoIUyJ/fHwCUNlwd4s+zWkuC5R5txMt2KsPx8 kaMw== X-Gm-Message-State: AMCzsaXwDarJy3hveMQqGQyhsMXgU/MvpYIAtUyCGzrkdHgMeWqcEaOV fgO2fHAbtHWWKvaoti1IzFe1r4jI X-Google-Smtp-Source: ABhQp+Td+IttLMuiKPVTjADye2ec4HAgOUhtKKQo55Q9CJ/pOjL+5GOJ9Y7TIRfMTGK3MQGWCT3naw== X-Received: by 10.159.194.18 with SMTP id x18mr1769515pln.273.1509593555075; Wed, 01 Nov 2017 20:32:35 -0700 (PDT) Received: from [192.168.99.103] ([103.42.216.254]) by smtp.gmail.com with ESMTPSA id t63sm3386402pgc.19.2017.11.01.20.32.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Nov 2017 20:32:34 -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: Date: Thu, 2 Nov 2017 10:02:30 +0630 Cc: netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com> References: To: "M. Ranganathan" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [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: Thu, 02 Nov 2017 03:32:37 -0000 Ranga, Is there a reason why you do not want to consider augmenting the model, = particularly since you seem to want to use the entire model? > On Oct 31, 2017, at 8:39 PM, M. Ranganathan wrote: >=20 > Re-posted from OPSAWG list : >=20 >=20 > Hello, >=20 > In the file =20 >=20 > ietf-access-control-list@2017-10-03.yang >=20 > I see that access-lists is directly defined as a collection. >=20 >=20 > May I suggest making a grouping (say access-lists-grouping) and use a = "uses" statement in access-lists. >=20 > The use-case for this change request - I would like to use the = grouping in another YANG model using a "uses" statement. >=20 > Thanks in advance for considering it. >=20 > Regards, >=20 > Ranga. >=20 > --=20 > M. Ranganathan > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Nov 2 00:43: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 5545413F9EB for ; Thu, 2 Nov 2017 00:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs2dQjONAFZ1 for ; Thu, 2 Nov 2017 00:43:22 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 520EF13F5FE for ; Thu, 2 Nov 2017 00:43:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 8E684261846; Thu, 2 Nov 2017 08:43:22 +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 bgsvFNWB+O0S; Thu, 2 Nov 2017 08:43:20 +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 34AB9261838; Thu, 2 Nov 2017 08:43:20 +0100 (CET) Date: Thu, 2 Nov 2017 08:43:18 +0100 From: Kristian Larsson To: Mahesh Jethanandani Cc: Juergen Schoenwaelder , "netmod@ietf.org" Message-ID: <20171102074318.GC12688@spritelink.se> References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <20171101112249.wmq4ggx2ixgn4kqo@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 02 Nov 2017 07:43:25 -0000 On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: > On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > Mahesh, > > I think the question is why we need to have different match containers > for each possible feature set combination instead of having a single > match container with groups of leafs in it marked as features. This > would seem to cut down the size of the module and the tree diagram > significantly. I think this will also make clients simpler sicne they > do not have to select a certain container based on the feature set > announced. > > > The current design of match containers was chosen to allow platforms to select > one container that matched what the hardware supported from a l2, l3 and ipv > {4,6} perspective. Sure, but you are conflating the structure of the model with the feature-wraps. Without changing the features of the model, we can structure it in a different way where there is not a 1:1 mapping between features and containers under the matches container. > I would argue that even though the overall diagram is bigger > with this design, once the platform selects the container of choice, the tree > and the configuration itself would be a little simpler/smaller. I am arguing the opposite. It's really awkward to place the same type of data, like IPv4 match conditions, under different paths based on a feature. If the system model had done the same we would have: /system /system-with-ntp /system-with-ntp-and-radius How do you augment in new leaves? While you are using groupings which allows for a reuse of data across all these containers, someone who is augmenting can't, since you can't augment a container, only where it is used. Someone wishing to add a leaf to the model needs to augment in three different locations to support a new match condition for IPv4 (let's say some meta-data attribute). > Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The current > tree looks like this: > > > | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}? > | | | +--rw destination-mac-address? yang:mac-address > | | | +--rw destination-mac-address-mask? yang:mac-address > | | | +--rw source-mac-address? yang:mac-address > | | | +--rw source-mac-address-mask? yang:mac-address > | | | +--rw ethertype? eth:ethertype > | | | +--rw dscp? inet:dscp > | | | +--rw ecn? uint8 > | | | +--rw length? uint16 > | | | +--rw ttl? uint8 > | | | +--rw protocol? uint8 > | | | +--rw source-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operation? operator > | | | +--rw destination-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operations? operator > | | | +--rw ihl? uint8 > | | | +--rw flags? bits > | | | +--rw offset? uint16 > | | | +--rw identification? uint16 > | | | +--rw destination-ipv4-network? inet:ipv4-prefix > | | | +--rw source-ipv4-network? inet:ipv4-prefix > | | | +--rw next-header? uint8 > | | | +--rw destination-ipv6-network? inet:ipv6-prefix > | | | +--rw source-ipv6-network? inet:ipv6-prefix > > | | | +--rw flow-label? > | | | inet:ipv6-flow-label > > > > whereas, if the design went with one match container with each group of leafs > in their own container (to support the if-feature statement for that > container), the tree would look like this: > > > | | +--rw l2-acl {l2-acl}? > | | | +--rw destination-mac-address? yang:mac-address > | | | +--rw destination-mac-address-mask? yang:mac-address > | | | +--rw source-mac-address? yang:mac-address > | | | +--rw source-mac-address-mask? yang:mac-address > | | | +--rw ethertype? eth:ethertype > > | | +--rw ipv4-acl {ipv4-acl}? > | | | +--rw dscp? inet:dscp > | | | +--rw ecn? uint8 > | | | +--rw length? uint16 > | | | +--rw ttl? uint8 > | | | +--rw protocol? uint8 > | | | +--rw source-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operation? operator > | | | +--rw destination-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operations? operator > | | | +--rw ihl? uint8 > | | | +--rw flags? bits > | | | +--rw offset? uint16 > | | | +--rw identification? uint16 > | | | +--rw destination-ipv4-network? inet:ipv4-prefix > | | | +--rw source-ipv4-network? inet:ipv4-prefix > | | +--rw ipv6-acl {ipv6-acl}? > | | | +--rw dscp? inet:dscp > | | | +--rw ecn? uint8 > | | | +--rw length? uint16 > | | | +--rw ttl? uint8 > | | | +--rw protocol? uint8 > | | | +--rw source-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operation? operator > | | | +--rw destination-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operations? operator > | | | +--rw next-header? uint8 > | | | +--rw destination-ipv6-network? inet:ipv6-prefix > | | | +--rw source-ipv6-network? inet:ipv6-prefix > | | | +--rw flow-label? inet:ipv6-flow-label > > > The difference though is small and comes down to a preference. Select one > feature statement and get one container with everything in it, or define > multiple feature statements and assemble together the pieces to define the ACE > entry. Again, I think you mix up the features available vs the structure of the data. This is the current list of features (which again, I want to change but that's separate): * l2-acl * ipv4-acl * ipv6-acl * mixed-ipv4-acl * mixed-ipv6-acl * l2-l3-ipv4-ipv6-acl * tcp-acl * udp-acl * icmp-acl * any-acl As per your second example above we have an ipv4-acl container under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl. It is only possible to define ipv4 matches if one of the following features are present: * ipv4-acl * mixed-ipv4-acl * l2-l3-ipv4-ipv6-acl Thus you write an if-feature statement to reflect that, like this: if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl"; So you see, the tight coupling you have between the data structure and the if-features isn't necessary. I think the structure should first be established without features and then features can be inserted where they make sense to make part of the model optional. Starting with the list of features and then designing the structure around them makes for a much less natural data structure IMHO. Kind regards, Kristian. From nobody Thu Nov 2 01:21: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 1FBD313FA6F for ; Thu, 2 Nov 2017 01:21:22 -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 JOph4wV1W3SN for ; Thu, 2 Nov 2017 01:21: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 7557413F772 for ; Thu, 2 Nov 2017 01:21: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 43A9569; Thu, 2 Nov 2017 09:21:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ZU8hMd9O4JvR; Thu, 2 Nov 2017 09:21:17 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Nov 2017 09:21:18 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10E5620116; Thu, 2 Nov 2017 09:21:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id a109rRPjtaep; Thu, 2 Nov 2017 09:21:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99AC120114; Thu, 2 Nov 2017 09:21:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8670E41481DC; Thu, 2 Nov 2017 09:19:50 +0100 (CET) Date: Thu, 2 Nov 2017 09:19:50 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Cc: Kristian Larsson , "netmod@ietf.org" Message-ID: <20171102081950.osk2tqkfkertbg2b@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mahesh Jethanandani , Kristian Larsson , "netmod@ietf.org" References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <20171101112249.wmq4ggx2ixgn4kqo@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-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, 02 Nov 2017 08:21:22 -0000 On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: > > Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The current tree looks like this: > [...] > whereas, if the design went with one match container with each group of leafs in their own container (to support the if-feature statement for that container), the tree would look like this: [...] > The difference though is small and comes down to a preference. Select one feature statement and get one container with everything in it, or define multiple feature statements and assemble together the pieces to define the ACE entry. Well, you leave out all the duplication you have and you leave out that the client needs to calculate where to configure an acl based on the feature set of a server. Copying the acl from one system to another requires to adjust containers for not good reason. The number of feature combinations will grow soon out of control and things get worse if vendors follow the direction and define vendor specific feature combinations and associated containers. > > BTW, how do I filter on TCP flags in combination with > > a source IP address? There seem to be reasonable combinations of > > features not even covered. > > If the platform has declared support for feature that includes ipv4 (and/or ipv6) and tcp-acl, for a given ACE entry, it should be able to define a match filter that includes both the source IP address and the TCP flags. Do you see something that prevents it? So if tcp-acl can be combined with other acls, why do I need in other places of the data model combinations like l2-l3-ipv4-ipv6-acl? Why do I not have tcp-acl, eth-acl, ipv4-acl, and ipv6-acl? (Note that l2-acl is somewhat a misnomer - hence I used eth-acl instead.) /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 Nov 2 01:50: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 2316613FA74 for ; Thu, 2 Nov 2017 01:50:40 -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 fi_65-Avr_f2 for ; Thu, 2 Nov 2017 01:50:38 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 2269113F89D for ; Thu, 2 Nov 2017 01:50:38 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id p186so12165041ioe.12 for ; Thu, 02 Nov 2017 01:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=DJG+f+xFnibAc9FibBFS/C416QXBQw3ibFR90Fbjsk0=; b=RzV3GtOLaiqTAQ/QMnfT5qjqCOuUlhFyGnsiwfMEy1DoR8/6H2d2iBaI3Iri6Pat1j dLkz2yRG0CAVNX8RpcZ4RjgD2H4o2msGZtK/Km1qAHkCpMF+ZlEkC9UOu1OxfWog7E2c cpBn5twU5sYpZTsAuTXIWhP3aoA4967IWafgCnYsUWifeqji/FQHOt4t/TEB0c3s3uyt 2jw1cYl/njSR1fXVTZWuO7gYyBA2M2TcxG4aX+O+spzKUNBNxnLBXBfZeXmZwT44wBw3 URFCHrsprAqYMfGxHgX5iyjIO4DMJINaeoSWItPhGYvIYzuhEaUz0ifpFNZY0K7wjDXW bHvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=DJG+f+xFnibAc9FibBFS/C416QXBQw3ibFR90Fbjsk0=; b=HC6wws3+ZJMuZq9ZdEl5Oe2w+XjdqZhRk44/rsTYD5ilnPHHN1TjD2i6bVKvqJS7lm O3POOV+npiSFMYqfxeqohtJ36DpELH0X+Nj0cKcswfxU420px3fMZ7bdyT2SRLO5Osi5 YMYZiHV/ONbqjTa+VwqJwKSNOYCG3SMVZ9+rYrvXM0HZIJX3P6sJY+Lti/XZYOymC9e5 loPAmP4VkK3dKLsULpktZF9qwEzi4byX7moyo2Eicac5neBgmxy1N0swArDQSCMASBhT rwXCPJJC/V2jy9JNMXTjjI2IQKKeC8g4A5CxjRGXtFt4TeFXlulba9ZLxSweBmMX8/zJ Tu8Q== X-Gm-Message-State: AJaThX5NtXvEstvfLjfjlATybVfbAeqjpsJypBhtXrxos/r7uw8YHpuZ 6bEHMJDvRX/L4NmKuOUZIFCeCY/W X-Google-Smtp-Source: ABhQp+RBBZMzOg4OZx52p4Nh53G5N7uBqfeFKqzfiU6DMQ7Kyov23bxGUL/Ek9ELpu0v2+DYeohoHA== X-Received: by 10.107.68.10 with SMTP id r10mr3579366ioa.202.1509612637349; Thu, 02 Nov 2017 01:50:37 -0700 (PDT) Received: from [192.168.1.199] ([103.25.76.180]) by smtp.gmail.com with ESMTPSA id x137sm1540308itb.37.2017.11.02.01.50.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Nov 2017 01:50:36 -0700 (PDT) References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <20171101112249.wmq4ggx2ixgn4kqo@elstar.local> <20171102074318.GC12688@spritelink.se> Mime-Version: 1.0 (1.0) In-Reply-To: <20171102074318.GC12688@spritelink.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> Cc: Juergen Schoenwaelder , "netmod@ietf.org" X-Mailer: iPad Mail (13G36) From: Mahesh Jethanandani Date: Thu, 2 Nov 2017 15:20:34 +0630 To: Kristian Larsson 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, 02 Nov 2017 08:50:40 -0000 Kristian, I hear you. What I am providing is the rational for the current design.=20 I would like to hear from others in the WG. We have been reviewing this draf= t for the last couple of years, and we are now at the tail end of the LC. I w= ould really like to see this draft move forward, particularly since it is no= t broken. Thanks. > On Nov 2, 2017, at 2:13 PM, Kristian Larsson wro= te: >=20 >> On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: >> On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >>=20 >> Mahesh, >>=20 >> I think the question is why we need to have different match containers= >> for each possible feature set combination instead of having a single >> match container with groups of leafs in it marked as features. This >> would seem to cut down the size of the module and the tree diagram >> significantly. I think this will also make clients simpler sicne they >> do not have to select a certain container based on the feature set >> announced.=20 >>=20 >>=20 >> The current design of match containers was chosen to allow platforms to s= elect >> one container that matched what the hardware supported from a l2, l3 and i= pv >> {4,6} perspective. >=20 > Sure, but you are conflating the structure of the model with the > feature-wraps. Without changing the features of the model, we can > structure it in a different way where there is not a 1:1 mapping > between features and containers under the matches container. >=20 >=20 >> I would argue that even though the overall diagram is bigger >> with this design, once the platform selects the container of choice, the t= ree >> and the configuration itself would be a little simpler/smaller. >=20 > I am arguing the opposite. It's really awkward to place the same > type of data, like IPv4 match conditions, under different paths > based on a feature. >=20 > If the system model had done the same we would have: > /system > /system-with-ntp > /system-with-ntp-and-radius >=20 > How do you augment in new leaves? While you are using groupings > which allows for a reuse of data across all these containers, > someone who is augmenting can't, since you can't augment a > container, only where it is used. Someone wishing to add a leaf > to the model needs to augment in three different locations to > support a new match condition for IPv4 (let's say some meta-data > attribute). >=20 >=20 >> Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The c= urrent >> tree looks like this: >>=20 >>=20 >> | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}? >> | | | +--rw destination-mac-address? yang:mac-addr= ess >> | | | +--rw destination-mac-address-mask? yang:mac-addr= ess >> | | | +--rw source-mac-address? yang:mac-addr= ess >> | | | +--rw source-mac-address-mask? yang:mac-addr= ess >> | | | +--rw ethertype? eth:ethertype= >> | | | +--rw dscp? inet:dscp >> | | | +--rw ecn? uint8 >> | | | +--rw length? uint16 >> | | | +--rw ttl? uint8 >> | | | +--rw protocol? uint8 >> | | | +--rw source-port-range! >> | | | | +--rw lower-port inet:port-number >> | | | | +--rw upper-port? inet:port-number >> | | | | +--rw operation? operator >> | | | +--rw destination-port-range! >> | | | | +--rw lower-port inet:port-number >> | | | | +--rw upper-port? inet:port-number >> | | | | +--rw operations? operator >> | | | +--rw ihl? uint8 >> | | | +--rw flags? bits >> | | | +--rw offset? uint16 >> | | | +--rw identification? uint16 >> | | | +--rw destination-ipv4-network? inet:ipv4-pre= fix >> | | | +--rw source-ipv4-network? inet:ipv4-pre= fix >> | | | +--rw next-header? uint8 >> | | | +--rw destination-ipv6-network? inet:ipv6-pre= fix >> | | | +--rw source-ipv6-network? inet:ipv6-pre= fix >>=20 >> | | | +--rw flow-label? >> | | | inet:ipv6-flow-label >>=20 >>=20 >>=20 >> whereas, if the design went with one match container with each group of l= eafs >> in their own container (to support the if-feature statement for that >> container), the tree would look like this: >>=20 >>=20 >> | | +--rw l2-acl {l2-acl}? >> | | | +--rw destination-mac-address? yang:mac-addr= ess >> | | | +--rw destination-mac-address-mask? yang:mac-addr= ess >> | | | +--rw source-mac-address? yang:mac-addr= ess >> | | | +--rw source-mac-address-mask? yang:mac-addr= ess >> | | | +--rw ethertype? eth:ethertype= >>=20 >> | | +--rw ipv4-acl {ipv4-acl}? >> | | | +--rw dscp? inet:dscp >> | | | +--rw ecn? uint8 >> | | | +--rw length? uint16 >> | | | +--rw ttl? uint8 >> | | | +--rw protocol? uint8 >> | | | +--rw source-port-range! >> | | | | +--rw lower-port inet:port-number >> | | | | +--rw upper-port? inet:port-number >> | | | | +--rw operation? operator >> | | | +--rw destination-port-range! >> | | | | +--rw lower-port inet:port-number >> | | | | +--rw upper-port? inet:port-number >> | | | | +--rw operations? operator >> | | | +--rw ihl? uint8 >> | | | +--rw flags? bits >> | | | +--rw offset? uint16 >> | | | +--rw identification? uint16 >> | | | +--rw destination-ipv4-network? inet:ipv4-prefix >> | | | +--rw source-ipv4-network? inet:ipv4-prefix >> | | +--rw ipv6-acl {ipv6-acl}? >> | | | +--rw dscp? inet:dscp >> | | | +--rw ecn? uint8 >> | | | +--rw length? uint16 >> | | | +--rw ttl? uint8 >> | | | +--rw protocol? uint8 >> | | | +--rw source-port-range! >> | | | | +--rw lower-port inet:port-number >> | | | | +--rw upper-port? inet:port-number >> | | | | +--rw operation? operator >> | | | +--rw destination-port-range! >> | | | | +--rw lower-port inet:port-number >> | | | | +--rw upper-port? inet:port-number >> | | | | +--rw operations? operator >> | | | +--rw next-header? uint8 >> | | | +--rw destination-ipv6-network? inet:ipv6-prefix >> | | | +--rw source-ipv6-network? inet:ipv6-prefix >> | | | +--rw flow-label? inet:ipv6-flow-la= bel >>=20 >>=20 >> The difference though is small and comes down to a preference. Select one= >> feature statement and get one container with everything in it, or define >> multiple feature statements and assemble together the pieces to define th= e ACE >> entry. >=20 > Again, I think you mix up the features available vs the structure > of the data. >=20 > This is the current list of features (which again, I want to > change but that's separate): > * l2-acl > * ipv4-acl > * ipv6-acl > * mixed-ipv4-acl > * mixed-ipv6-acl > * l2-l3-ipv4-ipv6-acl > * tcp-acl > * udp-acl > * icmp-acl > * any-acl >=20 > As per your second example above we have an ipv4-acl container > under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl. > It is only possible to define ipv4 matches if one of the > following features are present: > * ipv4-acl > * mixed-ipv4-acl > * l2-l3-ipv4-ipv6-acl >=20 > Thus you write an if-feature statement to reflect that, like > this: >=20 > if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl"; >=20 > So you see, the tight coupling you have between the data > structure and the if-features isn't necessary. >=20 > I think the structure should first be established without > features and then features can be inserted where they make sense > to make part of the model optional. Starting with the list of > features and then designing the structure around them makes for a > much less natural data structure IMHO. >=20 > Kind regards, > Kristian. Mahesh Jethanandani mjethanandani@gmail.com= From nobody Thu Nov 2 03:36: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 E7E5013F66E for ; Thu, 2 Nov 2017 03:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Iiv7mWdK6XYg for ; Thu, 2 Nov 2017 03:36:07 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 1D2BF13F666 for ; Thu, 2 Nov 2017 03:36:07 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id b15so5780981qkg.9 for ; Thu, 02 Nov 2017 03:36:07 -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=Ti1aabCZaAYs1BKuemfWAEMxm1NPF9EROA664+ZS3gI=; b=Tr5rlaO3GufKnbYZ0p6JMdlxSh9HjKkYYykzOFOegmk5xwCnc1oMS5B/pkUfCtVSfO iVNB0qa61dQJJtHrfl8gRX05onQ9ZUpk2RQMJIcV6l8qvxo+zM4+pUcB4gK41HMIK/8s HJr84bIGlhzvFVqTZ3EY9BPVF4848RRkMxKZ3L1vY0LG2sbLQJMNtRmvu95iA92ASkgM rSkK+g2D7YZf93VQs9tWKIEXvIzyVKWTD4K4KLVIRiUjs7d/8P/6XgKIirtxBIDzkPjE CVemcGOSZNuf36eetHXdbT1YgA4jSM5VolrR7qhRfWXUK7TOVbLCOYiZmvw3iclKKkW8 i7bA== 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=Ti1aabCZaAYs1BKuemfWAEMxm1NPF9EROA664+ZS3gI=; b=YiQQgBCtFeevhP5zHP8oXBFvHPdEzCG5IzX1p4cFdAhyjyZeZQYfNHtSoNQT7Xs+lr ufBkBd9sRTagpNzL0GB3r3raO+nCqaIpBaMydmoj9cfSxAtDzB8kKjyIV4xARaqdn/nd AsMp87kkTB79OWN+wfTfJJCaeSb6WMd9mP2G8Q5CfYOZ+rOqeIG0wH+y08VoRPhjpFGC BI78GbSM7gjIEmQbBzXB5bBlxEQgxHxPPI/Vam8qH9myya7FNMtvoZvMyqGUWKg832oh zVpGgFXVdlGB2DZN4yQeIlgLLYKeUCBL0uBieeYLB7grC7PzYuzBqwD1/bIZKyHktMfK AAsQ== X-Gm-Message-State: AMCzsaVYgREOJiDVmA/BUzNaqXCV8/CdWRHWfFEHOzMcHtWFEW4v6Wfw Je1378di0OAgG+iilVPhWhQ= X-Google-Smtp-Source: ABhQp+S4EY0m0LwYF7C6wyCRE2frmFnNfeCK7z/QOOI9gfmex/RjptnchCiV3cmxlANhjOfoncGXeA== X-Received: by 10.55.191.195 with SMTP id p186mr4064757qkf.152.1509618966118; Thu, 02 Nov 2017 03:36:06 -0700 (PDT) Received: from ?IPv6:2601:19b:880:14c8:683e:6d99:664a:3459? ([2601:19b:880:14c8:683e:6d99:664a:3459]) by smtp.gmail.com with ESMTPSA id m6sm1878459qkh.90.2017.11.02.03.36.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 03:36:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dean Bogdanovic In-Reply-To: <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> Date: Thu, 2 Nov 2017 06:36:03 -0400 Cc: Kristian Larsson , "netmod@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0BDDF286-4B72-4EE6-9CC2-07BBCDA6F53E@gmail.com> References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <20171101112249.wmq4ggx2ixgn4kqo@elstar.local> <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.3273) 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, 02 Nov 2017 10:36:09 -0000 I agree with points raised by Juergen and Kristian. Because of design = changes I have stepped down as co-author of the draft. > On Nov 2, 2017, at 4:50 AM, Mahesh Jethanandani = wrote: >=20 > Kristian, >=20 > I hear you. What I am providing is the rational for the current = design.=20 >=20 > I would like to hear from others in the WG. We have been reviewing = this draft for the last couple of years, and we are now at the tail end = of the LC. I would really like to see this draft move forward, = particularly since it is not broken. >=20 > Thanks. >=20 >> On Nov 2, 2017, at 2:13 PM, Kristian Larsson = wrote: >>=20 >>> On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: >>> On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>>=20 >>> Mahesh, >>>=20 >>> I think the question is why we need to have different match = containers >>> for each possible feature set combination instead of having a = single >>> match container with groups of leafs in it marked as features. = This >>> would seem to cut down the size of the module and the tree diagram >>> significantly. I think this will also make clients simpler sicne = they >>> do not have to select a certain container based on the feature set >>> announced.=20 >>>=20 >>>=20 >>> The current design of match containers was chosen to allow platforms = to select >>> one container that matched what the hardware supported from a l2, l3 = and ipv >>> {4,6} perspective. >>=20 >> Sure, but you are conflating the structure of the model with the >> feature-wraps. Without changing the features of the model, we can >> structure it in a different way where there is not a 1:1 mapping >> between features and containers under the matches container. >>=20 >>=20 >>> I would argue that even though the overall diagram is bigger >>> with this design, once the platform selects the container of choice, = the tree >>> and the configuration itself would be a little simpler/smaller. >>=20 >> I am arguing the opposite. It's really awkward to place the same >> type of data, like IPv4 match conditions, under different paths >> based on a feature. >>=20 >> If the system model had done the same we would have: >> /system >> /system-with-ntp >> /system-with-ntp-and-radius >>=20 >> How do you augment in new leaves? While you are using groupings >> which allows for a reuse of data across all these containers, >> someone who is augmenting can't, since you can't augment a >> container, only where it is used. Someone wishing to add a leaf >> to the model needs to augment in three different locations to >> support a new match condition for IPv4 (let's say some meta-data >> attribute). >>=20 >>=20 >>> Take the case where the desired selection is l2,-l3, ipv4 and ipv6. = The current >>> tree looks like this: >>>=20 >>>=20 >>> | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}? >>> | | | +--rw destination-mac-address? = yang:mac-address >>> | | | +--rw destination-mac-address-mask? = yang:mac-address >>> | | | +--rw source-mac-address? = yang:mac-address >>> | | | +--rw source-mac-address-mask? = yang:mac-address >>> | | | +--rw ethertype? = eth:ethertype >>> | | | +--rw dscp? inet:dscp >>> | | | +--rw ecn? uint8 >>> | | | +--rw length? uint16 >>> | | | +--rw ttl? uint8 >>> | | | +--rw protocol? uint8 >>> | | | +--rw source-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operation? operator >>> | | | +--rw destination-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operations? operator >>> | | | +--rw ihl? uint8 >>> | | | +--rw flags? bits >>> | | | +--rw offset? uint16 >>> | | | +--rw identification? uint16 >>> | | | +--rw destination-ipv4-network? = inet:ipv4-prefix >>> | | | +--rw source-ipv4-network? = inet:ipv4-prefix >>> | | | +--rw next-header? uint8 >>> | | | +--rw destination-ipv6-network? = inet:ipv6-prefix >>> | | | +--rw source-ipv6-network? = inet:ipv6-prefix >>>=20 >>> | | | +--rw flow-label? >>> | | | inet:ipv6-flow-label >>>=20 >>>=20 >>>=20 >>> whereas, if the design went with one match container with each group = of leafs >>> in their own container (to support the if-feature statement for that >>> container), the tree would look like this: >>>=20 >>>=20 >>> | | +--rw l2-acl {l2-acl}? >>> | | | +--rw destination-mac-address? = yang:mac-address >>> | | | +--rw destination-mac-address-mask? = yang:mac-address >>> | | | +--rw source-mac-address? = yang:mac-address >>> | | | +--rw source-mac-address-mask? = yang:mac-address >>> | | | +--rw ethertype? = eth:ethertype >>>=20 >>> | | +--rw ipv4-acl {ipv4-acl}? >>> | | | +--rw dscp? inet:dscp >>> | | | +--rw ecn? uint8 >>> | | | +--rw length? uint16 >>> | | | +--rw ttl? uint8 >>> | | | +--rw protocol? uint8 >>> | | | +--rw source-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operation? operator >>> | | | +--rw destination-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operations? operator >>> | | | +--rw ihl? uint8 >>> | | | +--rw flags? bits >>> | | | +--rw offset? uint16 >>> | | | +--rw identification? uint16 >>> | | | +--rw destination-ipv4-network? = inet:ipv4-prefix >>> | | | +--rw source-ipv4-network? = inet:ipv4-prefix >>> | | +--rw ipv6-acl {ipv6-acl}? >>> | | | +--rw dscp? inet:dscp >>> | | | +--rw ecn? uint8 >>> | | | +--rw length? uint16 >>> | | | +--rw ttl? uint8 >>> | | | +--rw protocol? uint8 >>> | | | +--rw source-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operation? operator >>> | | | +--rw destination-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operations? operator >>> | | | +--rw next-header? uint8 >>> | | | +--rw destination-ipv6-network? = inet:ipv6-prefix >>> | | | +--rw source-ipv6-network? = inet:ipv6-prefix >>> | | | +--rw flow-label? = inet:ipv6-flow-label >>>=20 >>>=20 >>> The difference though is small and comes down to a preference. = Select one >>> feature statement and get one container with everything in it, or = define >>> multiple feature statements and assemble together the pieces to = define the ACE >>> entry. >>=20 >> Again, I think you mix up the features available vs the structure >> of the data. >>=20 >> This is the current list of features (which again, I want to >> change but that's separate): >> * l2-acl >> * ipv4-acl >> * ipv6-acl >> * mixed-ipv4-acl >> * mixed-ipv6-acl >> * l2-l3-ipv4-ipv6-acl >> * tcp-acl >> * udp-acl >> * icmp-acl >> * any-acl >>=20 >> As per your second example above we have an ipv4-acl container >> under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl. >> It is only possible to define ipv4 matches if one of the >> following features are present: >> * ipv4-acl >> * mixed-ipv4-acl >> * l2-l3-ipv4-ipv6-acl >>=20 >> Thus you write an if-feature statement to reflect that, like >> this: >>=20 >> if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl"; >>=20 >> So you see, the tight coupling you have between the data >> structure and the if-features isn't necessary. >>=20 >> I think the structure should first be established without >> features and then features can be inserted where they make sense >> to make part of the model optional. Starting with the list of >> features and then designing the structure around them makes for a >> much less natural data structure IMHO. >>=20 >> Kind regards, >> Kristian. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Nov 2 04: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 0D5BB13F6F9 for ; Thu, 2 Nov 2017 04: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, 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 HK_k8IM5Feoy for ; Thu, 2 Nov 2017 04:24:44 -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 995DE139982 for ; Thu, 2 Nov 2017 04:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26845; q=dns/txt; s=iport; t=1509621883; x=1510831483; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=O3PalZ/cdjSpERq8Cco+pQS0/tZHdrFzqcQkvj9kKfU=; b=XD6/JsGIIieslkV6UdzvH47lgB1e4gn9DAZdCuVJaOYF0dEFE391cpUL Qlmocv0lECKEBnkIfHf1xJXra6+US9fQoPATVDBMytI4RBAzcIj2rhuoi 1cdL5y75os7wW/WaJQYnRa36egiC3f7BnxTgrVcBGd4pmv3RQE1755h2J Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAACj+/pZ/xbLJq1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEQoESbieDfYofdJAjiFCNdYIRChgBCoRJTwKFIhgBAQEBAQE?= =?us-ascii?q?BAQFrKIUeAQEBAwEBIUsbCw4CCCoCAiEGMAYBDAYCAQGKBwMVEKh1gicmhxsNg?= =?us-ascii?q?0gBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMug1qBaSmDAYJqgX2DP4JiBZFej3M?= =?us-ascii?q?8kAOEeYt4hzqNGoEPh22BOR84gWw0IQgdFUmCZIRfQTaMaQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,333,1505779200"; d="scan'208,217";a="10335" 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; 02 Nov 2017 11:24:41 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA2BOe0I006772; Thu, 2 Nov 2017 11:24:40 GMT To: Mahesh Jethanandani , Kristian Larsson , "netmod@ietf.org" References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <20171101112249.wmq4ggx2ixgn4kqo@elstar.local> <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> From: Robert Wilton Message-ID: Date: Thu, 2 Nov 2017 11:24:40 +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: <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> Content-Type: multipart/alternative; boundary="------------2C58D819A851B20E92B99A5A" Content-Language: en-US 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, 02 Nov 2017 11:24:47 -0000 This is a multi-part message in MIME format. --------------2C58D819A851B20E92B99A5A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Mahesh, I also think that the model would be cleaner if you don't have separate containers for each "type of ACL".  In particular, I think that the model is easier for clients, and perhaps easier to implement, if a given ACE field is always on the same path rather that being on a different path based on ACL type.  I've suggested a minor change to the model that may retain the same benefits, but keep consistent paths for the ACE fields. Hence, would the following help improve the model? 1) Move the L2, IPv4, IPv6 match fields under their own containers, as Juergen/Kristian have suggested. 2) Under each of those containers remove the "if-feature", and change the "must" statement to a "when statement". 3) Add if-feature statements under the acl-type identity definitions, allowing a device to control what acl-types mixes they support. E.g. // ACL features defined as below. // ACL type identities updated to: identity ipv4-acl { base acl:acl-base; if-feature "ipv4-acl"; } identity ipv6-acl { base acl:acl-base; if-feature "ipv6-acl";  } identity eth-acl { base acl:acl-base; if-feature "l2-acl";  } identity mixed-l2-l3-ipv4-acl { base "acl:ipv4-acl"; base "acl:eth-acl"; if-feature "mixed-ipv4-acl";  } identity mixed-l2-l3-ipv6-acl { base "acl:ipv6-acl"; base "acl:eth-acl"; if-feature "mixed-ipv6-acl";  } ... ... leaf acl-type { type acl-type; } container aces { list ace { key "rule-name"; ordered-by user; leaf rule-name ... container matches { container l2 { when "derived-from(../../../../acl-type, 'acl:eth-acl')"; uses packet-fields:acl-eth-header-fields; description "Rule set for L2 ACL."; } container ipv4 { when "derived-from(../../../../acl-type, acl:ipv4-acl')"; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields; description "Rule set that supports IPv4 headers."; } container ipv6 { ... } Thanks, Rob On 02/11/2017 08:50, Mahesh Jethanandani wrote: > Kristian, > > I hear you. What I am providing is the rational for the current design. > > I would like to hear from others in the WG. We have been reviewing this draft for the last couple of years, and we are now at the tail end of the LC. I would really like to see this draft move forward, particularly since it is not broken. > > Thanks. > >> On Nov 2, 2017, at 2:13 PM, Kristian Larsson wrote: >> >>> On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: >>> On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>> >>> Mahesh, >>> >>> I think the question is why we need to have different match containers >>> for each possible feature set combination instead of having a single >>> match container with groups of leafs in it marked as features. This >>> would seem to cut down the size of the module and the tree diagram >>> significantly. I think this will also make clients simpler sicne they >>> do not have to select a certain container based on the feature set >>> announced. >>> >>> >>> The current design of match containers was chosen to allow platforms to select >>> one container that matched what the hardware supported from a l2, l3 and ipv >>> {4,6} perspective. >> Sure, but you are conflating the structure of the model with the >> feature-wraps. Without changing the features of the model, we can >> structure it in a different way where there is not a 1:1 mapping >> between features and containers under the matches container. >> >> >>> I would argue that even though the overall diagram is bigger >>> with this design, once the platform selects the container of choice, the tree >>> and the configuration itself would be a little simpler/smaller. >> I am arguing the opposite. It's really awkward to place the same >> type of data, like IPv4 match conditions, under different paths >> based on a feature. >> >> If the system model had done the same we would have: >> /system >> /system-with-ntp >> /system-with-ntp-and-radius >> >> How do you augment in new leaves? While you are using groupings >> which allows for a reuse of data across all these containers, >> someone who is augmenting can't, since you can't augment a >> container, only where it is used. Someone wishing to add a leaf >> to the model needs to augment in three different locations to >> support a new match condition for IPv4 (let's say some meta-data >> attribute). >> >> >>> Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The current >>> tree looks like this: >>> >>> >>> | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}? >>> | | | +--rw destination-mac-address? yang:mac-address >>> | | | +--rw destination-mac-address-mask? yang:mac-address >>> | | | +--rw source-mac-address? yang:mac-address >>> | | | +--rw source-mac-address-mask? yang:mac-address >>> | | | +--rw ethertype? eth:ethertype >>> | | | +--rw dscp? inet:dscp >>> | | | +--rw ecn? uint8 >>> | | | +--rw length? uint16 >>> | | | +--rw ttl? uint8 >>> | | | +--rw protocol? uint8 >>> | | | +--rw source-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operation? operator >>> | | | +--rw destination-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operations? operator >>> | | | +--rw ihl? uint8 >>> | | | +--rw flags? bits >>> | | | +--rw offset? uint16 >>> | | | +--rw identification? uint16 >>> | | | +--rw destination-ipv4-network? inet:ipv4-prefix >>> | | | +--rw source-ipv4-network? inet:ipv4-prefix >>> | | | +--rw next-header? uint8 >>> | | | +--rw destination-ipv6-network? inet:ipv6-prefix >>> | | | +--rw source-ipv6-network? inet:ipv6-prefix >>> >>> | | | +--rw flow-label? >>> | | | inet:ipv6-flow-label >>> >>> >>> >>> whereas, if the design went with one match container with each group of leafs >>> in their own container (to support the if-feature statement for that >>> container), the tree would look like this: >>> >>> >>> | | +--rw l2-acl {l2-acl}? >>> | | | +--rw destination-mac-address? yang:mac-address >>> | | | +--rw destination-mac-address-mask? yang:mac-address >>> | | | +--rw source-mac-address? yang:mac-address >>> | | | +--rw source-mac-address-mask? yang:mac-address >>> | | | +--rw ethertype? eth:ethertype >>> >>> | | +--rw ipv4-acl {ipv4-acl}? >>> | | | +--rw dscp? inet:dscp >>> | | | +--rw ecn? uint8 >>> | | | +--rw length? uint16 >>> | | | +--rw ttl? uint8 >>> | | | +--rw protocol? uint8 >>> | | | +--rw source-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operation? operator >>> | | | +--rw destination-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operations? operator >>> | | | +--rw ihl? uint8 >>> | | | +--rw flags? bits >>> | | | +--rw offset? uint16 >>> | | | +--rw identification? uint16 >>> | | | +--rw destination-ipv4-network? inet:ipv4-prefix >>> | | | +--rw source-ipv4-network? inet:ipv4-prefix >>> | | +--rw ipv6-acl {ipv6-acl}? >>> | | | +--rw dscp? inet:dscp >>> | | | +--rw ecn? uint8 >>> | | | +--rw length? uint16 >>> | | | +--rw ttl? uint8 >>> | | | +--rw protocol? uint8 >>> | | | +--rw source-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operation? operator >>> | | | +--rw destination-port-range! >>> | | | | +--rw lower-port inet:port-number >>> | | | | +--rw upper-port? inet:port-number >>> | | | | +--rw operations? operator >>> | | | +--rw next-header? uint8 >>> | | | +--rw destination-ipv6-network? inet:ipv6-prefix >>> | | | +--rw source-ipv6-network? inet:ipv6-prefix >>> | | | +--rw flow-label? inet:ipv6-flow-label >>> >>> >>> The difference though is small and comes down to a preference. Select one >>> feature statement and get one container with everything in it, or define >>> multiple feature statements and assemble together the pieces to define the ACE >>> entry. >> Again, I think you mix up the features available vs the structure >> of the data. >> >> This is the current list of features (which again, I want to >> change but that's separate): >> * l2-acl >> * ipv4-acl >> * ipv6-acl >> * mixed-ipv4-acl >> * mixed-ipv6-acl >> * l2-l3-ipv4-ipv6-acl >> * tcp-acl >> * udp-acl >> * icmp-acl >> * any-acl >> >> As per your second example above we have an ipv4-acl container >> under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl. >> It is only possible to define ipv4 matches if one of the >> following features are present: >> * ipv4-acl >> * mixed-ipv4-acl >> * l2-l3-ipv4-ipv6-acl >> >> Thus you write an if-feature statement to reflect that, like >> this: >> >> if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl"; >> >> So you see, the tight coupling you have between the data >> structure and the if-features isn't necessary. >> >> I think the structure should first be established without >> features and then features can be inserted where they make sense >> to make part of the model optional. Starting with the list of >> features and then designing the structure around them makes for a >> much less natural data structure IMHO. >> >> Kind regards, >> Kristian. > Mahesh Jethanandani > mjethanandani@gmail.com > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > --------------2C58D819A851B20E92B99A5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Mahesh,

I also think that the model would be cleaner if you don't have separate containers for each "type of ACL".  In particular, I think that the model is easier for clients, and perhaps easier to implement, if a given ACE field is always on the same path rather that being on a different path based on ACL type.  I've suggested a minor change to the model that may retain the same benefits, but keep consistent paths for the ACE fields.

Hence, would the following help improve the model?

1) Move the L2, IPv4, IPv6 match fields under their own containers, as Juergen/Kristian have suggested.
2) Under each of those containers remove the "if-feature", and change the "must" statement to a "when statement".
3) Add if-feature statements under the acl-type identity definitions, allowing a device to control what acl-types mixes they support.

E.g. 

  // ACL features defined as below. 

  // ACL type identities updated to:
  identity ipv4-acl {
    base acl:acl-base;
    if-feature "ipv4-acl";
  }
  identity ipv6-acl {
    base acl:acl-base;
    if-feature "ipv6-acl";
 }
  identity eth-acl {
    base acl:acl-base;
    if-feature "l2-acl";
 }
  identity mixed-l2-l3-ipv4-acl {
    base "acl:ipv4-acl";
    base "acl:eth-acl";
    if-feature "mixed-ipv4-acl";
 }
  identity mixed-l2-l3-ipv6-acl {
    base "acl:ipv6-acl";
    base "acl:eth-acl";
    if-feature "mixed-ipv6-acl";
 }

...

...
      leaf acl-type {
        type acl-type;
      }
      container aces {
        list ace {
          key "rule-name";
          ordered-by user;
          leaf rule-name ...

          container matches {
            container l2 {
              when "derived-from(../../../../acl-type, 'acl:eth-acl')";
              uses packet-fields:acl-eth-header-fields;
              description
                "Rule set for L2 ACL.";
            }
            container ipv4 {
              when "derived-from(../../../../acl-type, acl:ipv4-acl')";
              uses packet-fields:acl-ip-header-fields;
                    uses packet-fields:acl-ipv4-header-fields;
              description
                "Rule set that supports IPv4 headers.";
            }
            container ipv6 {
              ...
            }

Thanks,
Rob


On 02/11/2017 08:50, Mahesh Jethanandani wrote:
Kristian,

I hear you. What I am providing is the rational for the current design. 

I would like to hear from others in the WG. We have been reviewing this draft for the last couple of years, and we are now at the tail end of the LC. I would really like to see this draft move forward, particularly since it is not broken.

Thanks.


On Nov 2, 2017, at 2:13 PM, Kristian Larsson <kristian@spritelink.net> wrote:


On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote:
   On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder <
   j.schoenwaelder@jacobs-university.de> wrote:

   Mahesh,

   I think the question is why we need to have different match containers
   for each possible feature set combination instead of having a single
   match container with groups of leafs in it marked as features. This
   would seem to cut down the size of the module and the tree diagram
   significantly. I think this will also make clients simpler sicne they
   do not have to select a certain container based on the feature set
   announced. 


The current design of match containers was chosen to allow platforms to select
one container that matched what the hardware supported from a l2, l3 and ipv
{4,6} perspective.

Sure, but you are conflating the structure of the model with the
feature-wraps. Without changing the features of the model, we can
structure it in a different way where there is not a 1:1 mapping
between features and containers under the matches container.



I would argue that even though the overall diagram is bigger
with this design, once the platform selects the container of choice, the tree
and the configuration itself would be a little simpler/smaller.

I am arguing the opposite. It's really awkward to place the same
type of data, like IPv4 match conditions, under different paths
based on a feature.

If the system model had done the same we would have:
/system
/system-with-ntp
/system-with-ntp-and-radius

How do you augment in new leaves? While you are using groupings
which allows for a reuse of data across all these containers,
someone who is augmenting can't, since you can't augment a
container, only where it is used. Someone wishing to add a leaf
to the model needs to augment in three different locations to
support a new match condition for IPv4 (let's say some meta-data
attribute).



Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The current
tree looks like this:


       |        |  +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}?
       |        |  |  +--rw destination-mac-address?        yang:mac-address
       |        |  |  +--rw destination-mac-address-mask?   yang:mac-address
       |        |  |  +--rw source-mac-address?             yang:mac-address
       |        |  |  +--rw source-mac-address-mask?        yang:mac-address
       |        |  |  +--rw ethertype?                      eth:ethertype
       |        |  |  +--rw dscp?                           inet:dscp
       |        |  |  +--rw ecn?                            uint8
       |        |  |  +--rw length?                         uint16
       |        |  |  +--rw ttl?                            uint8
       |        |  |  +--rw protocol?                       uint8
       |        |  |  +--rw source-port-range!
       |        |  |  |  +--rw lower-port    inet:port-number
       |        |  |  |  +--rw upper-port?   inet:port-number
       |        |  |  |  +--rw operation?    operator
       |        |  |  +--rw destination-port-range!
       |        |  |  |  +--rw lower-port    inet:port-number
       |        |  |  |  +--rw upper-port?   inet:port-number
       |        |  |  |  +--rw operations?   operator
       |        |  |  +--rw ihl?                            uint8
       |        |  |  +--rw flags?                          bits
       |        |  |  +--rw offset?                         uint16
       |        |  |  +--rw identification?                 uint16
       |        |  |  +--rw destination-ipv4-network?       inet:ipv4-prefix
       |        |  |  +--rw source-ipv4-network?            inet:ipv4-prefix
       |        |  |  +--rw next-header?                    uint8
       |        |  |  +--rw destination-ipv6-network?       inet:ipv6-prefix
       |        |  |  +--rw source-ipv6-network?            inet:ipv6-prefix

       |        |  |  +--rw flow-label?
       |        |  |          inet:ipv6-flow-label



whereas, if the design went with one match container with each group of leafs
in their own container (to support the if-feature statement for that
container), the tree would look like this:


       |        |  +--rw l2-acl {l2-acl}?
       |        |  |  +--rw destination-mac-address?        yang:mac-address
       |        |  |  +--rw destination-mac-address-mask?   yang:mac-address
       |        |  |  +--rw source-mac-address?             yang:mac-address
       |        |  |  +--rw source-mac-address-mask?        yang:mac-address
       |        |  |  +--rw ethertype?                      eth:ethertype

       |        |  +--rw ipv4-acl {ipv4-acl}?
       |        |  |  +--rw dscp?                       inet:dscp
       |        |  |  +--rw ecn?                        uint8
       |        |  |  +--rw length?                     uint16
       |        |  |  +--rw ttl?                        uint8
       |        |  |  +--rw protocol?                   uint8
       |        |  |  +--rw source-port-range!
       |        |  |  |  +--rw lower-port    inet:port-number
       |        |  |  |  +--rw upper-port?   inet:port-number
       |        |  |  |  +--rw operation?    operator
       |        |  |  +--rw destination-port-range!
       |        |  |  |  +--rw lower-port    inet:port-number
       |        |  |  |  +--rw upper-port?   inet:port-number
       |        |  |  |  +--rw operations?   operator
       |        |  |  +--rw ihl?                        uint8
       |        |  |  +--rw flags?                      bits
       |        |  |  +--rw offset?                     uint16
       |        |  |  +--rw identification?             uint16
       |        |  |  +--rw destination-ipv4-network?   inet:ipv4-prefix
       |        |  |  +--rw source-ipv4-network?        inet:ipv4-prefix
       |        |  +--rw ipv6-acl {ipv6-acl}?
       |        |  |  +--rw dscp?                       inet:dscp
       |        |  |  +--rw ecn?                        uint8
       |        |  |  +--rw length?                     uint16
       |        |  |  +--rw ttl?                        uint8
       |        |  |  +--rw protocol?                   uint8
       |        |  |  +--rw source-port-range!
       |        |  |  |  +--rw lower-port    inet:port-number
       |        |  |  |  +--rw upper-port?   inet:port-number
       |        |  |  |  +--rw operation?    operator
       |        |  |  +--rw destination-port-range!
       |        |  |  |  +--rw lower-port    inet:port-number
       |        |  |  |  +--rw upper-port?   inet:port-number
       |        |  |  |  +--rw operations?   operator
       |        |  |  +--rw next-header?                uint8
       |        |  |  +--rw destination-ipv6-network?   inet:ipv6-prefix
       |        |  |  +--rw source-ipv6-network?        inet:ipv6-prefix
       |        |  |  +--rw flow-label?                 inet:ipv6-flow-label


The difference though is small and comes down to a preference. Select one
feature statement and get one container with everything in it, or define
multiple feature statements and assemble together the pieces to define the ACE
entry.

Again, I think you mix up the features available vs the structure
of the data.

This is the current list of features (which again, I want to
change but that's separate):
* l2-acl
* ipv4-acl
* ipv6-acl
* mixed-ipv4-acl
* mixed-ipv6-acl
* l2-l3-ipv4-ipv6-acl
* tcp-acl
* udp-acl
* icmp-acl
* any-acl

As per your second example above we have an ipv4-acl container
under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl.
It is only possible to define ipv4 matches if one of the
following features are present:
* ipv4-acl
* mixed-ipv4-acl
* l2-l3-ipv4-ipv6-acl

Thus you write an if-feature statement to reflect that, like
this:

if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl";

So you see, the tight coupling you have between the data
structure and the if-features isn't necessary.

I think the structure should first be established without
features and then features can be inserted where they make sense
to make part of the model optional. Starting with the list of
features and then designing the structure around them makes for a
much less natural data structure IMHO.

Kind regards,
  Kristian.

Mahesh Jethanandani
mjethanandani@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.

--------------2C58D819A851B20E92B99A5A-- From nobody Thu Nov 2 05:28: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 CEA8113F585 for ; Thu, 2 Nov 2017 05:28: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 4pt5DlRiuMsk for ; Thu, 2 Nov 2017 05:28:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0A613B133 for ; Thu, 2 Nov 2017 05:28:00 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 0C75D1AE01AA; Thu, 2 Nov 2017 13:27:58 +0100 (CET) Date: Thu, 02 Nov 2017 13:26:34 +0100 (CET) Message-Id: <20171102.132634.1363976895007772742.mbj@tail-f.com> To: rwilton@cisco.com Cc: mjethanandani@gmail.com, kristian@spritelink.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@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=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 02 Nov 2017 12:28:04 -0000 Robert Wilton wrote: > Hi Mahesh, > = > I also think that the model would be cleaner if you don't have > separate containers for each "type of ACL".=A0 In particular, I think= > that the model is easier for clients, and perhaps easier to implement= , > if a given ACE field is always on the same path rather that being on = a > different path based on ACL type. +1 > I've suggested a minor change to > the model that may retain the same benefits, but keep consistent path= s > for the ACE fields. > = > Hence, would the following help improve the model? > = > 1) Move the L2, IPv4, IPv6 match fields under their own containers, a= s > Juergen/Kristian have suggested. > 2) Under each of those containers remove the "if-feature", and change= > the "must" statement to a "when statement". > 3) Add if-feature statements under the acl-type identity definitions,= > allowing a device to control what acl-types mixes they support. > = > E.g. > = > // ACL features defined as below. > = > // ACL type identities updated to: > identity ipv4-acl { > base acl:acl-base; > if-feature "ipv4-acl"; > } > identity ipv6-acl { > base acl:acl-base; > if-feature "ipv6-acl"; > =A0} > identity eth-acl { > base acl:acl-base; > if-feature "l2-acl"; > =A0} > identity mixed-l2-l3-ipv4-acl { > base "acl:ipv4-acl"; > base "acl:eth-acl"; > if-feature "mixed-ipv4-acl"; > =A0} There seem to be some inconsistencies in these names. For example, why is the identity called "eth-acl" but the feature "l2-acl"? And when the identity for eth is used with "mixed-" it is called "l2". Also, why is "mixed-l2-l3-ipv4-acl" not called "mixed-l2-ipv4-acl"? And why is the corresponding feature just called "mixed-ipv4-acl"? /martin > identity mixed-l2-l3-ipv6-acl { > base "acl:ipv6-acl"; > base "acl:eth-acl"; > if-feature "mixed-ipv6-acl"; > =A0} > = > ... > = > ... > leaf acl-type { > type acl-type; > } > container aces { > list ace { > key "rule-name"; > ordered-by user; > leaf rule-name ... > = > container matches { > container l2 { > when "derived-from(../../../../acl-type, 'acl:eth-acl')= "; > uses packet-fields:acl-eth-header-fields; > description > "Rule set for L2 ACL."; > } > container ipv4 { > when "derived-from(../../../../acl-type, acl:ipv4-acl')= "; > uses packet-fields:acl-ip-header-fields; > uses packet-fields:acl-ipv4-header-fields; > description > "Rule set that supports IPv4 headers."; > } > container ipv6 { > ... > } > = > = > Thanks, > Rob > = > = > On 02/11/2017 08:50, Mahesh Jethanandani wrote: > > Kristian, > > > > I hear you. What I am providing is the rational for the current > > design. > > > > I would like to hear from others in the WG. We have been reviewing > > this draft for the last couple of years, and we are now at the tail= > > end of the LC. I would really like to see this draft move forward, > > particularly since it is not broken. > > > > Thanks. > > > >> On Nov 2, 2017, at 2:13 PM, Kristian Larsson > >> wrote: > >> > >>> On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wro= te: > >>> On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < > >>> j.schoenwaelder@jacobs-university.de> wrote: > >>> > >>> Mahesh, > >>> > >>> I think the question is why we need to have different match c= ontainers > >>> for each possible feature set combination instead of having a= single > >>> match container with groups of leafs in it marked as features= . This > >>> would seem to cut down the size of the module and the tree di= agram > >>> significantly. I think this will also make clients simpler si= cne they > >>> do not have to select a certain container based on the featur= e set > >>> announced. > >>> > >>> > >>> The current design of match containers was chosen to allow platfo= rms > >>> to select > >>> one container that matched what the hardware supported from a l2,= l3 > >>> and ipv > >>> {4,6} perspective. > >> Sure, but you are conflating the structure of the model with the > >> feature-wraps. Without changing the features of the model, we can > >> structure it in a different way where there is not a 1:1 mapping > >> between features and containers under the matches container. > >> > >> > >>> I would argue that even though the overall diagram is bigger > >>> with this design, once the platform selects the container of choi= ce, > >>> the tree > >>> and the configuration itself would be a little simpler/smaller. > >> I am arguing the opposite. It's really awkward to place the same > >> type of data, like IPv4 match conditions, under different paths > >> based on a feature. > >> > >> If the system model had done the same we would have: > >> /system > >> /system-with-ntp > >> /system-with-ntp-and-radius > >> > >> How do you augment in new leaves? While you are using groupings > >> which allows for a reuse of data across all these containers, > >> someone who is augmenting can't, since you can't augment a > >> container, only where it is used. Someone wishing to add a leaf > >> to the model needs to augment in three different locations to > >> support a new match condition for IPv4 (let's say some meta-data > >> attribute). > >> > >> > >>> Take the case where the desired selection is l2,-l3, ipv4 and > >>> ipv6. The current > >>> tree looks like this: > >>> > >>> > >>> | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-ac= l}? > >>> | | | +--rw destination-mac-address? yang:mac-a= ddress > >>> | | | +--rw destination-mac-address-mask? > >>> | | | yang:mac-address > >>> | | | +--rw source-mac-address? yang:mac-addres= s > >>> | | | +--rw source-mac-address-mask? yang:mac-a= ddress > >>> | | | +--rw ethertype? eth:= ethertype > >>> | | | +--rw dscp? inet= :dscp > >>> | | | +--rw ecn? uint= 8 > >>> | | | +--rw length? uint= 16 > >>> | | | +--rw ttl? uint= 8 > >>> | | | +--rw protocol? uint= 8 > >>> | | | +--rw source-port-range! > >>> | | | | +--rw lower-port inet:port-number > >>> | | | | +--rw upper-port? inet:port-number > >>> | | | | +--rw operation? operator > >>> | | | +--rw destination-port-range! > >>> | | | | +--rw lower-port inet:port-number > >>> | | | | +--rw upper-port? inet:port-number > >>> | | | | +--rw operations? operator > >>> | | | +--rw ihl? uint= 8 > >>> | | | +--rw flags? bits= > >>> | | | +--rw offset? uint= 16 > >>> | | | +--rw identification? uint= 16 > >>> | | | +--rw destination-ipv4-network? inet:ipv4= -prefix > >>> | | | +--rw source-ipv4-network? inet:ipv4-pref= ix > >>> | | | +--rw next-header? uint= 8 > >>> | | | +--rw destination-ipv6-network? inet:ipv6= -prefix > >>> | | | +--rw source-ipv6-network? inet:ipv6-pref= ix > >>> > >>> | | | +--rw flow-label? > >>> | | | inet:ipv6-flow-label > >>> > >>> > >>> > >>> whereas, if the design went with one match container with each gr= oup > >>> of leafs > >>> in their own container (to support the if-feature statement for t= hat > >>> container), the tree would look like this: > >>> > >>> > >>> | | +--rw l2-acl {l2-acl}? > >>> | | | +--rw destination-mac-address? yang:mac-a= ddress > >>> | | | +--rw destination-mac-address-mask? > >>> | | | yang:mac-address > >>> | | | +--rw source-mac-address? yang:mac-addres= s > >>> | | | +--rw source-mac-address-mask? yang:mac-a= ddress > >>> | | | +--rw ethertype? eth:= ethertype > >>> > >>> | | +--rw ipv4-acl {ipv4-acl}? > >>> | | | +--rw dscp? inet:dsc= p > >>> | | | +--rw ecn? uint8 > >>> | | | +--rw length? uint16 > >>> | | | +--rw ttl? uint8 > >>> | | | +--rw protocol? uint8 > >>> | | | +--rw source-port-range! > >>> | | | | +--rw lower-port inet:port-number > >>> | | | | +--rw upper-port? inet:port-number > >>> | | | | +--rw operation? operator > >>> | | | +--rw destination-port-range! > >>> | | | | +--rw lower-port inet:port-number > >>> | | | | +--rw upper-port? inet:port-number > >>> | | | | +--rw operations? operator > >>> | | | +--rw ihl? uint8 > >>> | | | +--rw flags? bits > >>> | | | +--rw offset? uint16 > >>> | | | +--rw identification? uint16 > >>> | | | +--rw destination-ipv4-network? inet:ipv= 4-prefix > >>> | | | +--rw source-ipv4-network? inet:ipv= 4-prefix > >>> | | +--rw ipv6-acl {ipv6-acl}? > >>> | | | +--rw dscp? inet:dsc= p > >>> | | | +--rw ecn? uint8 > >>> | | | +--rw length? uint16 > >>> | | | +--rw ttl? uint8 > >>> | | | +--rw protocol? uint8 > >>> | | | +--rw source-port-range! > >>> | | | | +--rw lower-port inet:port-number > >>> | | | | +--rw upper-port? inet:port-number > >>> | | | | +--rw operation? operator > >>> | | | +--rw destination-port-range! > >>> | | | | +--rw lower-port inet:port-number > >>> | | | | +--rw upper-port? inet:port-number > >>> | | | | +--rw operations? operator > >>> | | | +--rw next-header? uint8 > >>> | | | +--rw destination-ipv6-network? inet:ipv= 6-prefix > >>> | | | +--rw source-ipv6-network? inet:ipv= 6-prefix > >>> | | | +--rw flow-label? inet:ipv6-flow-label > >>> > >>> > >>> The difference though is small and comes down to a preference. Se= lect > >>> one > >>> feature statement and get one container with everything in it, or= > >>> define > >>> multiple feature statements and assemble together the pieces to d= efine > >>> the ACE > >>> entry. > >> Again, I think you mix up the features available vs the structure > >> of the data. > >> > >> This is the current list of features (which again, I want to > >> change but that's separate): > >> * l2-acl > >> * ipv4-acl > >> * ipv6-acl > >> * mixed-ipv4-acl > >> * mixed-ipv6-acl > >> * l2-l3-ipv4-ipv6-acl > >> * tcp-acl > >> * udp-acl > >> * icmp-acl > >> * any-acl > >> > >> As per your second example above we have an ipv4-acl container > >> under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl. > >> It is only possible to define ipv4 matches if one of the > >> following features are present: > >> * ipv4-acl > >> * mixed-ipv4-acl > >> * l2-l3-ipv4-ipv6-acl > >> > >> Thus you write an if-feature statement to reflect that, like > >> this: > >> > >> if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl"; > >> > >> So you see, the tight coupling you have between the data > >> structure and the if-features isn't necessary. > >> > >> I think the structure should first be established without > >> features and then features can be inserted where they make sense > >> to make part of the model optional. Starting with the list of > >> features and then designing the structure around them makes for a > >> much less natural data structure IMHO. > >> > >> Kind regards, > >> Kristian. > > Mahesh Jethanandani > > mjethanandani@gmail.com > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > = From nobody Thu Nov 2 05:40: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 3EC7213F45D for ; Thu, 2 Nov 2017 05:40:38 -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 2SSYatVyxwKE for ; Thu, 2 Nov 2017 05:40:35 -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 3796B138103 for ; Thu, 2 Nov 2017 05:40:34 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id s75so5016463pgs.0 for ; Thu, 02 Nov 2017 05:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=XmrXz4ouSzlECnIMEtal33kqMuJqgzdsqmP5r7yoquM=; b=Qw61WfAv9zWQwOWHXVYp42jF3yfFtsh0OsI4ZmPMcQmc1iM63KOEkm51oho1qaWN9K Sss0wHYUvQP2h5kVfoX5o6rUec9HVhH8W3s1hqcOw3Dbsd4WUInuHxAGqzTPc1gYaVop 0+vGIFdqo9PDa2WwwuacC/gVAHl5Auq4AFBESB9zFRWm2pOB8SnYlVlvpK5MzX/eNP68 JHbsF/pXvInv+noVgIVa1HZCwZQR9lUrNnBCstGV2vvd0f9KDDYKtXNjr69XlR90BVum eEKYnS6OSHmGMx59otk3pAic8ZI6Ol9d/lm/5CNcqDRFk2dGtSl8xeXN0RMagRWAqZmM V9JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=XmrXz4ouSzlECnIMEtal33kqMuJqgzdsqmP5r7yoquM=; b=DO7M5FJ58bu05DXzpAvSpEn4GkGBAy3QDurmuMJxCl+BjYADOjSvPlBkBw0ax4PZFY E6mnO9pVDg649NscJOeHCwGcY3/HdjXYrb8p1ofb3P/RuKmz46TAwBtUsaBkrGIzDhiU acxicJSCq/mgaKRpehX6vJZGzbBM6M9XNjw43LXo1kXL1Upa6LLjs0sNfOfx2IaCXSAZ CMaBBywF7X3+rUHCTeSl5mvo0wVuT31bweu94G/cBeuLk2Rp+zL3wC+F+yQbz4XuL3+r mWQgy9Hb3bGqpS2Bez2Kwy2lebA4DDh7wNJGbfktnf7yTvK43alqClnoqRGC0BqSkCxi p5qg== X-Gm-Message-State: AMCzsaVkvqugV/dmIQ1TVyKFbm4GWVJeH9XpoAjLllaUy9Auzd7ObSbC nFwGNrZlyJQ19w4DwkFHZOg= X-Google-Smtp-Source: ABhQp+TOPi3A1DLuo6eLDx2MhPOFHc9xNj7kOR9B3J4TYarinnobBlTFXeG2vYcsZpVR5UWLfyDf7A== X-Received: by 10.98.15.22 with SMTP id x22mr3629784pfi.13.1509626433554; Thu, 02 Nov 2017 05:40:33 -0700 (PDT) Received: from [10.116.192.241] ([115.132.156.192]) by smtp.gmail.com with ESMTPSA id c22sm6677988pfe.177.2017.11.02.05.40.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Nov 2017 05:40:32 -0700 (PDT) References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20171102.132634.1363976895007772742.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <51CEDFCB-88CF-4066-8428-55BF7521D1F0@gmail.com> Cc: rwilton@cisco.com, kristian@spritelink.net, netmod@ietf.org X-Mailer: iPad Mail (13G36) From: Mahesh Jethanandani Date: Thu, 2 Nov 2017 19:10:30 +0630 To: Martin Bjorklund 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, 02 Nov 2017 12:40:38 -0000 Ok. Will update the model to reflect the discussion on this thread. Mahesh Jethanandani mjethanandani@gmail.com > On Nov 2, 2017, at 6:56 PM, Martin Bjorklund wrote: >=20 > Robert Wilton wrote: >> Hi Mahesh, >>=20 >> I also think that the model would be cleaner if you don't have >> separate containers for each "type of ACL". In particular, I think >> that the model is easier for clients, and perhaps easier to implement, >> if a given ACE field is always on the same path rather that being on a >> different path based on ACL type. >=20 > +1 >=20 >> I've suggested a minor change to >> the model that may retain the same benefits, but keep consistent paths >> for the ACE fields. >>=20 >> Hence, would the following help improve the model? >>=20 >> 1) Move the L2, IPv4, IPv6 match fields under their own containers, as >> Juergen/Kristian have suggested. >> 2) Under each of those containers remove the "if-feature", and change >> the "must" statement to a "when statement". >> 3) Add if-feature statements under the acl-type identity definitions, >> allowing a device to control what acl-types mixes they support. >>=20 >> E.g. >>=20 >> // ACL features defined as below. >>=20 >> // ACL type identities updated to: >> identity ipv4-acl { >> base acl:acl-base; >> if-feature "ipv4-acl"; >> } >> identity ipv6-acl { >> base acl:acl-base; >> if-feature "ipv6-acl"; >> } >> identity eth-acl { >> base acl:acl-base; >> if-feature "l2-acl"; >> } >> identity mixed-l2-l3-ipv4-acl { >> base "acl:ipv4-acl"; >> base "acl:eth-acl"; >> if-feature "mixed-ipv4-acl"; >> } >=20 > There seem to be some inconsistencies in these names. For example, > why is the identity called "eth-acl" but the feature "l2-acl"? And > when the identity for eth is used with "mixed-" it is called "l2". >=20 > Also, why is "mixed-l2-l3-ipv4-acl" not called "mixed-l2-ipv4-acl"? > And why is the corresponding feature just called "mixed-ipv4-acl"? >=20 >=20 >=20 > /martin >=20 >=20 >=20 >=20 >=20 >> identity mixed-l2-l3-ipv6-acl { >> base "acl:ipv6-acl"; >> base "acl:eth-acl"; >> if-feature "mixed-ipv6-acl"; >> } >>=20 >> ... >>=20 >> ... >> leaf acl-type { >> type acl-type; >> } >> container aces { >> list ace { >> key "rule-name"; >> ordered-by user; >> leaf rule-name ... >>=20 >> container matches { >> container l2 { >> when "derived-from(../../../../acl-type, 'acl:eth-acl')"; >> uses packet-fields:acl-eth-header-fields; >> description >> "Rule set for L2 ACL."; >> } >> container ipv4 { >> when "derived-from(../../../../acl-type, acl:ipv4-acl')"; >> uses packet-fields:acl-ip-header-fields; >> uses packet-fields:acl-ipv4-header-fields; >> description >> "Rule set that supports IPv4 headers."; >> } >> container ipv6 { >> ... >> } >>=20 >>=20 >> Thanks, >> Rob >>=20 >>=20 >>> On 02/11/2017 08:50, Mahesh Jethanandani wrote: >>> Kristian, >>>=20 >>> I hear you. What I am providing is the rational for the current >>> design. >>>=20 >>> I would like to hear from others in the WG. We have been reviewing >>> this draft for the last couple of years, and we are now at the tail >>> end of the LC. I would really like to see this draft move forward, >>> particularly since it is not broken. >>>=20 >>> Thanks. >>>=20 >>>> On Nov 2, 2017, at 2:13 PM, Kristian Larsson >>>> wrote: >>>>=20 >>>>> On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: >>>>> On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < >>>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>>=20 >>>>> Mahesh, >>>>>=20 >>>>> I think the question is why we need to have different match contain= ers >>>>> for each possible feature set combination instead of having a singl= e >>>>> match container with groups of leafs in it marked as features. This= >>>>> would seem to cut down the size of the module and the tree diagram >>>>> significantly. I think this will also make clients simpler sicne th= ey >>>>> do not have to select a certain container based on the feature set >>>>> announced. >>>>>=20 >>>>>=20 >>>>> The current design of match containers was chosen to allow platforms >>>>> to select >>>>> one container that matched what the hardware supported from a l2, l3 >>>>> and ipv >>>>> {4,6} perspective. >>>> Sure, but you are conflating the structure of the model with the >>>> feature-wraps. Without changing the features of the model, we can >>>> structure it in a different way where there is not a 1:1 mapping >>>> between features and containers under the matches container. >>>>=20 >>>>=20 >>>>> I would argue that even though the overall diagram is bigger >>>>> with this design, once the platform selects the container of choice, >>>>> the tree >>>>> and the configuration itself would be a little simpler/smaller. >>>> I am arguing the opposite. It's really awkward to place the same >>>> type of data, like IPv4 match conditions, under different paths >>>> based on a feature. >>>>=20 >>>> If the system model had done the same we would have: >>>> /system >>>> /system-with-ntp >>>> /system-with-ntp-and-radius >>>>=20 >>>> How do you augment in new leaves? While you are using groupings >>>> which allows for a reuse of data across all these containers, >>>> someone who is augmenting can't, since you can't augment a >>>> container, only where it is used. Someone wishing to add a leaf >>>> to the model needs to augment in three different locations to >>>> support a new match condition for IPv4 (let's say some meta-data >>>> attribute). >>>>=20 >>>>=20 >>>>> Take the case where the desired selection is l2,-l3, ipv4 and >>>>> ipv6. The current >>>>> tree looks like this: >>>>>=20 >>>>>=20 >>>>> | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}? >>>>> | | | +--rw destination-mac-address? yang:mac-address= >>>>> | | | +--rw destination-mac-address-mask? >>>>> | | | yang:mac-address >>>>> | | | +--rw source-mac-address? yang:mac-address >>>>> | | | +--rw source-mac-address-mask? yang:mac-address= >>>>> | | | +--rw ethertype? eth:ethert= ype >>>>> | | | +--rw dscp? inet:dscp >>>>> | | | +--rw ecn? uint8 >>>>> | | | +--rw length? uint16 >>>>> | | | +--rw ttl? uint8 >>>>> | | | +--rw protocol? uint8 >>>>> | | | +--rw source-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operation? operator >>>>> | | | +--rw destination-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operations? operator >>>>> | | | +--rw ihl? uint8 >>>>> | | | +--rw flags? bits >>>>> | | | +--rw offset? uint16 >>>>> | | | +--rw identification? uint16 >>>>> | | | +--rw destination-ipv4-network? inet:ipv4-prefi= x >>>>> | | | +--rw source-ipv4-network? inet:ipv4-prefix >>>>> | | | +--rw next-header? uint8 >>>>> | | | +--rw destination-ipv6-network? inet:ipv6-prefi= x >>>>> | | | +--rw source-ipv6-network? inet:ipv6-prefix >>>>>=20 >>>>> | | | +--rw flow-label? >>>>> | | | inet:ipv6-flow-label >>>>>=20 >>>>>=20 >>>>>=20 >>>>> whereas, if the design went with one match container with each group >>>>> of leafs >>>>> in their own container (to support the if-feature statement for that >>>>> container), the tree would look like this: >>>>>=20 >>>>>=20 >>>>> | | +--rw l2-acl {l2-acl}? >>>>> | | | +--rw destination-mac-address? yang:mac-address= >>>>> | | | +--rw destination-mac-address-mask? >>>>> | | | yang:mac-address >>>>> | | | +--rw source-mac-address? yang:mac-address >>>>> | | | +--rw source-mac-address-mask? yang:mac-address= >>>>> | | | +--rw ethertype? eth:ethert= ype >>>>>=20 >>>>> | | +--rw ipv4-acl {ipv4-acl}? >>>>> | | | +--rw dscp? inet:dscp >>>>> | | | +--rw ecn? uint8 >>>>> | | | +--rw length? uint16 >>>>> | | | +--rw ttl? uint8 >>>>> | | | +--rw protocol? uint8 >>>>> | | | +--rw source-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operation? operator >>>>> | | | +--rw destination-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operations? operator >>>>> | | | +--rw ihl? uint8 >>>>> | | | +--rw flags? bits >>>>> | | | +--rw offset? uint16 >>>>> | | | +--rw identification? uint16 >>>>> | | | +--rw destination-ipv4-network? inet:ipv4-pref= ix >>>>> | | | +--rw source-ipv4-network? inet:ipv4-pref= ix >>>>> | | +--rw ipv6-acl {ipv6-acl}? >>>>> | | | +--rw dscp? inet:dscp >>>>> | | | +--rw ecn? uint8 >>>>> | | | +--rw length? uint16 >>>>> | | | +--rw ttl? uint8 >>>>> | | | +--rw protocol? uint8 >>>>> | | | +--rw source-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operation? operator >>>>> | | | +--rw destination-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operations? operator >>>>> | | | +--rw next-header? uint8 >>>>> | | | +--rw destination-ipv6-network? inet:ipv6-pref= ix >>>>> | | | +--rw source-ipv6-network? inet:ipv6-pref= ix >>>>> | | | +--rw flow-label? inet:ipv6-flow-label >>>>>=20 >>>>>=20 >>>>> The difference though is small and comes down to a preference. Select >>>>> one >>>>> feature statement and get one container with everything in it, or >>>>> define >>>>> multiple feature statements and assemble together the pieces to define= >>>>> the ACE >>>>> entry. >>>> Again, I think you mix up the features available vs the structure >>>> of the data. >>>>=20 >>>> This is the current list of features (which again, I want to >>>> change but that's separate): >>>> * l2-acl >>>> * ipv4-acl >>>> * ipv6-acl >>>> * mixed-ipv4-acl >>>> * mixed-ipv6-acl >>>> * l2-l3-ipv4-ipv6-acl >>>> * tcp-acl >>>> * udp-acl >>>> * icmp-acl >>>> * any-acl >>>>=20 >>>> As per your second example above we have an ipv4-acl container >>>> under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl. >>>> It is only possible to define ipv4 matches if one of the >>>> following features are present: >>>> * ipv4-acl >>>> * mixed-ipv4-acl >>>> * l2-l3-ipv4-ipv6-acl >>>>=20 >>>> Thus you write an if-feature statement to reflect that, like >>>> this: >>>>=20 >>>> if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl"; >>>>=20 >>>> So you see, the tight coupling you have between the data >>>> structure and the if-features isn't necessary. >>>>=20 >>>> I think the structure should first be established without >>>> features and then features can be inserted where they make sense >>>> to make part of the model optional. Starting with the list of >>>> features and then designing the structure around them makes for a >>>> much less natural data structure IMHO. >>>>=20 >>>> Kind regards, >>>> Kristian. >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>=20 From nobody Thu Nov 2 05:53: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 CDE0B13F45D for ; Thu, 2 Nov 2017 05:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 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_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbzxGS1LlAcA for ; Thu, 2 Nov 2017 05:53:33 -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 87607138103 for ; Thu, 2 Nov 2017 05:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34439; q=dns/txt; s=iport; t=1509627212; x=1510836812; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=AfK25Ra2W/iGFgKUF/LdqnlZsOs+EHeUwi4bS0/rrFc=; b=V8ZL0M8c1sIxQlrlD8d+mbDjgxEQ5Do+PpfV457KQ0bTaPca4NmtK0cr rgtHM4jMGdofUJhYmAPPs4kM/1UiEvZwlc1JxC88DWxfvDMe0d06Imj35 iv2u8/IzgSpAYccFcLjNn67cL4gHkpkS5O2Byf2AVkhLxhxdW8WWWGVT/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAADmE/tZ/xbLJq1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEQoESbieDfYofdI99JohQjXWCEQoYAQqESU8ChQ0YAQEBAQE?= =?us-ascii?q?BAQEBayiFHgEBBAEBGAlLCxALDgIIIAoCAiEGMAYBDAYCAQGKBwMVEKhngicmh?= =?us-ascii?q?xwNg0gBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMug1qBaSkLgnaCaoF9gz+CYgW?= =?us-ascii?q?RXo9zPJADhHmLeIc6jRqBD4dtgTkfOIFsNCEIHRVJgmSEX0E2jUMBAQE?= X-IronPort-AV: E=Sophos;i="5.44,334,1505779200"; d="scan'208,217";a="12364" 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; 02 Nov 2017 12:53:30 +0000 Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA2CrUF9000999; Thu, 2 Nov 2017 12:53:30 GMT To: Martin Bjorklund , mjethanandani@gmail.com, netmod@ietf.org References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Thu, 2 Nov 2017 12:53:29 +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: <20171102.132634.1363976895007772742.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------7242F4202282C92A9E9E246A" Content-Language: en-US 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, 02 Nov 2017 12:53:36 -0000 This is a multi-part message in MIME format. --------------7242F4202282C92A9E9E246A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 02/11/2017 12:26, Martin Bjorklund wrote: > Robert Wilton wrote: >> Hi Mahesh, >> >> I also think that the model would be cleaner if you don't have >> separate containers for each "type of ACL".  In particular, I think >> that the model is easier for clients, and perhaps easier to implement, >> if a given ACE field is always on the same path rather that being on a >> different path based on ACL type. > +1 > >> I've suggested a minor change to >> the model that may retain the same benefits, but keep consistent paths >> for the ACE fields. >> >> Hence, would the following help improve the model? >> >> 1) Move the L2, IPv4, IPv6 match fields under their own containers, as >> Juergen/Kristian have suggested. >> 2) Under each of those containers remove the "if-feature", and change >> the "must" statement to a "when statement". >> 3) Add if-feature statements under the acl-type identity definitions, >> allowing a device to control what acl-types mixes they support. >> >> E.g. >> >> // ACL features defined as below. >> >> // ACL type identities updated to: >> identity ipv4-acl { >> base acl:acl-base; >> if-feature "ipv4-acl"; >> } >> identity ipv6-acl { >> base acl:acl-base; >> if-feature "ipv6-acl"; >>  } >> identity eth-acl { >> base acl:acl-base; >> if-feature "l2-acl"; >>  } >> identity mixed-l2-l3-ipv4-acl { >> base "acl:ipv4-acl"; >> base "acl:eth-acl"; >> if-feature "mixed-ipv4-acl"; >>  } > There seem to be some inconsistencies in these names. For example, > why is the identity called "eth-acl" but the feature "l2-acl"? And > when the identity for eth is used with "mixed-" it is called "l2". > > Also, why is "mixed-l2-l3-ipv4-acl" not called "mixed-l2-ipv4-acl"? > And why is the corresponding feature just called "mixed-ipv4-acl"? I agree that aligning the feature names and identity names would be helpful.   In my example of how the model could be tweaked (and below) I was just reusing the existing ones that are currently defined in the draft. One further refinement might also be to make the ACL type features a bit more hierarchical as well, but I don't know if that makes it too complex? For example, the model could define separate features for what type of ACE matching is supported by the device, separately from what types of ACE combinations are allowed. E.g. // New 'match type' features. feature match-on-l2-eth-hdr { // Device can match on L2 Ethernet header fields. } feature match-on-ipv4-hdr { // Device can match on IPv4 header fields. } feature match-on-ipv6-hdr { // Device can match on IPv6 header fields. } The existing ACL type features could then depend on these: feature l2-acl { if-feature "match-on-l2-eth-hdr";  description "Layer 2 ACL supported"; } feature ipv4-acl { if-feature "match-on-ipv4-hdr";  description "Layer 3 IPv4 ACL supported"; } feature ipv6-acl { if-feature "match-on-ipv6-hdr";  description "Layer 3 IPv6 ACL supported"; } feature mixed-ipv4-acl { if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";  description "Layer 2 and Layer 3 IPv4 ACL supported"; } ... This then means that the ACE match fields can be predicated on a "match type" if-feature statement: ... container matches { container l2 { *if-feature "**match-on-l2-eth-hdr**";*  when "derived-from(../../../../acl-type, 'acl:eth-acl')"; uses packet-fields:acl-eth-header-fields; description "Rule set for L2 ACL."; } container ipv4 { *if-feature "**match-on-ipv4-hdr**";*  when "derived-from(../../../../acl-type, acl:ipv4-acl')"; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields; description "Rule set that supports IPv4 headers."; } container ipv6 { *if-feature "**match-on-ipv6-hdr**";*  ... } This would keep the actual model a bit smaller for devices that don't support all match types (regardless of what combinations they support). Thanks, Rob > > > > /martin > > > > > >> identity mixed-l2-l3-ipv6-acl { >> base "acl:ipv6-acl"; >> base "acl:eth-acl"; >> if-feature "mixed-ipv6-acl"; >>  } >> >> ... >> >> ... >> leaf acl-type { >> type acl-type; >> } >> container aces { >> list ace { >> key "rule-name"; >> ordered-by user; >> leaf rule-name ... >> >> container matches { >> container l2 { >> when "derived-from(../../../../acl-type, 'acl:eth-acl')"; >> uses packet-fields:acl-eth-header-fields; >> description >> "Rule set for L2 ACL."; >> } >> container ipv4 { >> when "derived-from(../../../../acl-type, acl:ipv4-acl')"; >> uses packet-fields:acl-ip-header-fields; >> uses packet-fields:acl-ipv4-header-fields; >> description >> "Rule set that supports IPv4 headers."; >> } >> container ipv6 { >> ... >> } >> >> >> Thanks, >> Rob >> >> >> On 02/11/2017 08:50, Mahesh Jethanandani wrote: >>> Kristian, >>> >>> I hear you. What I am providing is the rational for the current >>> design. >>> >>> I would like to hear from others in the WG. We have been reviewing >>> this draft for the last couple of years, and we are now at the tail >>> end of the LC. I would really like to see this draft move forward, >>> particularly since it is not broken. >>> >>> Thanks. >>> >>>> On Nov 2, 2017, at 2:13 PM, Kristian Larsson >>>> wrote: >>>> >>>>> On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: >>>>> On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < >>>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>> >>>>> Mahesh, >>>>> >>>>> I think the question is why we need to have different match containers >>>>> for each possible feature set combination instead of having a single >>>>> match container with groups of leafs in it marked as features. This >>>>> would seem to cut down the size of the module and the tree diagram >>>>> significantly. I think this will also make clients simpler sicne they >>>>> do not have to select a certain container based on the feature set >>>>> announced. >>>>> >>>>> >>>>> The current design of match containers was chosen to allow platforms >>>>> to select >>>>> one container that matched what the hardware supported from a l2, l3 >>>>> and ipv >>>>> {4,6} perspective. >>>> Sure, but you are conflating the structure of the model with the >>>> feature-wraps. Without changing the features of the model, we can >>>> structure it in a different way where there is not a 1:1 mapping >>>> between features and containers under the matches container. >>>> >>>> >>>>> I would argue that even though the overall diagram is bigger >>>>> with this design, once the platform selects the container of choice, >>>>> the tree >>>>> and the configuration itself would be a little simpler/smaller. >>>> I am arguing the opposite. It's really awkward to place the same >>>> type of data, like IPv4 match conditions, under different paths >>>> based on a feature. >>>> >>>> If the system model had done the same we would have: >>>> /system >>>> /system-with-ntp >>>> /system-with-ntp-and-radius >>>> >>>> How do you augment in new leaves? While you are using groupings >>>> which allows for a reuse of data across all these containers, >>>> someone who is augmenting can't, since you can't augment a >>>> container, only where it is used. Someone wishing to add a leaf >>>> to the model needs to augment in three different locations to >>>> support a new match condition for IPv4 (let's say some meta-data >>>> attribute). >>>> >>>> >>>>> Take the case where the desired selection is l2,-l3, ipv4 and >>>>> ipv6. The current >>>>> tree looks like this: >>>>> >>>>> >>>>> | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}? >>>>> | | | +--rw destination-mac-address? yang:mac-address >>>>> | | | +--rw destination-mac-address-mask? >>>>> | | | yang:mac-address >>>>> | | | +--rw source-mac-address? yang:mac-address >>>>> | | | +--rw source-mac-address-mask? yang:mac-address >>>>> | | | +--rw ethertype? eth:ethertype >>>>> | | | +--rw dscp? inet:dscp >>>>> | | | +--rw ecn? uint8 >>>>> | | | +--rw length? uint16 >>>>> | | | +--rw ttl? uint8 >>>>> | | | +--rw protocol? uint8 >>>>> | | | +--rw source-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operation? operator >>>>> | | | +--rw destination-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operations? operator >>>>> | | | +--rw ihl? uint8 >>>>> | | | +--rw flags? bits >>>>> | | | +--rw offset? uint16 >>>>> | | | +--rw identification? uint16 >>>>> | | | +--rw destination-ipv4-network? inet:ipv4-prefix >>>>> | | | +--rw source-ipv4-network? inet:ipv4-prefix >>>>> | | | +--rw next-header? uint8 >>>>> | | | +--rw destination-ipv6-network? inet:ipv6-prefix >>>>> | | | +--rw source-ipv6-network? inet:ipv6-prefix >>>>> >>>>> | | | +--rw flow-label? >>>>> | | | inet:ipv6-flow-label >>>>> >>>>> >>>>> >>>>> whereas, if the design went with one match container with each group >>>>> of leafs >>>>> in their own container (to support the if-feature statement for that >>>>> container), the tree would look like this: >>>>> >>>>> >>>>> | | +--rw l2-acl {l2-acl}? >>>>> | | | +--rw destination-mac-address? yang:mac-address >>>>> | | | +--rw destination-mac-address-mask? >>>>> | | | yang:mac-address >>>>> | | | +--rw source-mac-address? yang:mac-address >>>>> | | | +--rw source-mac-address-mask? yang:mac-address >>>>> | | | +--rw ethertype? eth:ethertype >>>>> >>>>> | | +--rw ipv4-acl {ipv4-acl}? >>>>> | | | +--rw dscp? inet:dscp >>>>> | | | +--rw ecn? uint8 >>>>> | | | +--rw length? uint16 >>>>> | | | +--rw ttl? uint8 >>>>> | | | +--rw protocol? uint8 >>>>> | | | +--rw source-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operation? operator >>>>> | | | +--rw destination-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operations? operator >>>>> | | | +--rw ihl? uint8 >>>>> | | | +--rw flags? bits >>>>> | | | +--rw offset? uint16 >>>>> | | | +--rw identification? uint16 >>>>> | | | +--rw destination-ipv4-network? inet:ipv4-prefix >>>>> | | | +--rw source-ipv4-network? inet:ipv4-prefix >>>>> | | +--rw ipv6-acl {ipv6-acl}? >>>>> | | | +--rw dscp? inet:dscp >>>>> | | | +--rw ecn? uint8 >>>>> | | | +--rw length? uint16 >>>>> | | | +--rw ttl? uint8 >>>>> | | | +--rw protocol? uint8 >>>>> | | | +--rw source-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operation? operator >>>>> | | | +--rw destination-port-range! >>>>> | | | | +--rw lower-port inet:port-number >>>>> | | | | +--rw upper-port? inet:port-number >>>>> | | | | +--rw operations? operator >>>>> | | | +--rw next-header? uint8 >>>>> | | | +--rw destination-ipv6-network? inet:ipv6-prefix >>>>> | | | +--rw source-ipv6-network? inet:ipv6-prefix >>>>> | | | +--rw flow-label? inet:ipv6-flow-label >>>>> >>>>> >>>>> The difference though is small and comes down to a preference. Select >>>>> one >>>>> feature statement and get one container with everything in it, or >>>>> define >>>>> multiple feature statements and assemble together the pieces to define >>>>> the ACE >>>>> entry. >>>> Again, I think you mix up the features available vs the structure >>>> of the data. >>>> >>>> This is the current list of features (which again, I want to >>>> change but that's separate): >>>> * l2-acl >>>> * ipv4-acl >>>> * ipv6-acl >>>> * mixed-ipv4-acl >>>> * mixed-ipv6-acl >>>> * l2-l3-ipv4-ipv6-acl >>>> * tcp-acl >>>> * udp-acl >>>> * icmp-acl >>>> * any-acl >>>> >>>> As per your second example above we have an ipv4-acl container >>>> under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl. >>>> It is only possible to define ipv4 matches if one of the >>>> following features are present: >>>> * ipv4-acl >>>> * mixed-ipv4-acl >>>> * l2-l3-ipv4-ipv6-acl >>>> >>>> Thus you write an if-feature statement to reflect that, like >>>> this: >>>> >>>> if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl"; >>>> >>>> So you see, the tight coupling you have between the data >>>> structure and the if-features isn't necessary. >>>> >>>> I think the structure should first be established without >>>> features and then features can be inserted where they make sense >>>> to make part of the model optional. Starting with the list of >>>> features and then designing the structure around them makes for a >>>> much less natural data structure IMHO. >>>> >>>> Kind regards, >>>> Kristian. >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> > . > --------------7242F4202282C92A9E9E246A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 02/11/2017 12:26, Martin Bjorklund wrote:
Robert Wilton <rwilton@cisco.com> wrote:

Hi Mahesh,

I also think that the model would be cleaner if you don't have
separate containers for each "type of ACL".  In particular, I think
that the model is easier for clients, and perhaps easier to implement,
if a given ACE field is always on the same path rather that being on a
different path based on ACL type.

+1


I've suggested a minor change to
the model that may retain the same benefits, but keep consistent paths
for the ACE fields.

Hence, would the following help improve the model?

1) Move the L2, IPv4, IPv6 match fields under their own containers, as
Juergen/Kristian have suggested.
2) Under each of those containers remove the "if-feature", and change
the "must" statement to a "when statement".
3) Add if-feature statements under the acl-type identity definitions,
allowing a device to control what acl-types mixes they support.

E.g.

  // ACL features defined as below.

  // ACL type identities updated to:
  identity ipv4-acl {
    base acl:acl-base;
    if-feature "ipv4-acl";
  }
  identity ipv6-acl {
    base acl:acl-base;
    if-feature "ipv6-acl";
 }
  identity eth-acl {
    base acl:acl-base;
    if-feature "l2-acl";
 }
  identity mixed-l2-l3-ipv4-acl {
    base "acl:ipv4-acl";
    base "acl:eth-acl";
    if-feature "mixed-ipv4-acl";
 }

There seem to be some inconsistencies in these names.  For example,
why is the identity called "eth-acl" but the feature "l2-acl"?  And
when the identity for eth is used with "mixed-" it is called "l2".

Also, why is "mixed-l2-l3-ipv4-acl" not called "mixed-l2-ipv4-acl"?
And why is the corresponding feature just called "mixed-ipv4-acl"?
I agree that aligning the feature names and identity names would be helpful.   In my example of how the model could be tweaked (and below) I was just reusing the existing ones that are currently defined in the draft.

One further refinement might also be to make the ACL type features a bit more hierarchical as well, but I don't know if that makes it too complex?

For example, the model could define separate features for what type of ACE matching is supported by the device, separately from what types of ACE combinations are allowed.

E.g.
// New 'match type' features.

feature match-on-l2-eth-hdr {
   // Device can match on L2 Ethernet header fields.
}
feature match-on-ipv4-hdr {
   // Device can match on IPv4 header fields.
}
feature match-on-ipv6-hdr {
   // Device can match on IPv6 header fields.
}

The existing ACL type features could then depend on these:

  feature l2-acl {
    if-feature "match-on-l2-eth-hdr";
    description "Layer 2 ACL supported";
  }

  feature ipv4-acl {
    if-feature "match-on-ipv4-hdr";
    description "Layer 3 IPv4 ACL supported";
  }

  feature ipv6-acl {  
   if-feature "match-on-ipv6-hdr";
   description "Layer 3 IPv6 ACL supported";
  }

  feature mixed-ipv4-acl {    
    if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
    description "Layer 2 and Layer 3 IPv4 ACL supported";
  }
  ...

This then means that the ACE match fields can be predicated on a "match type" if-feature statement:

  ...
          container matches {
            container l2 {
              if-feature "match-on-l2-eth-hdr";
              when "derived-from(../../../../acl-type, 'acl:eth-acl')";
              uses packet-fields:acl-eth-header-fields;
              description
                "Rule set for L2 ACL.";
            }
            container ipv4 {
              if-feature "match-on-ipv4-hdr";
              when "derived-from(../../../../acl-type, acl:ipv4-acl')";
              uses packet-fields:acl-ip-header-fields;
                    uses packet-fields:acl-ipv4-header-fields;
              description
                "Rule set that supports IPv4 headers.";
            }
            container ipv6 {
              if-feature "match-on-ipv6-hdr";
              ...
            }

This would keep the actual model a bit smaller for devices that don't support all match types (regardless of what combinations they support).

Thanks,
Rob





/martin






  identity mixed-l2-l3-ipv6-acl {
    base "acl:ipv6-acl";
    base "acl:eth-acl";
    if-feature "mixed-ipv6-acl";
 }

...

...
      leaf acl-type {
        type acl-type;
      }
      container aces {
        list ace {
          key "rule-name";
          ordered-by user;
          leaf rule-name ...

          container matches {
            container l2 {
              when "derived-from(../../../../acl-type, 'acl:eth-acl')";
              uses packet-fields:acl-eth-header-fields;
              description
                "Rule set for L2 ACL.";
            }
            container ipv4 {
              when "derived-from(../../../../acl-type, acl:ipv4-acl')";
              uses packet-fields:acl-ip-header-fields;
                    uses packet-fields:acl-ipv4-header-fields;
              description
                "Rule set that supports IPv4 headers.";
            }
            container ipv6 {
              ...
            }


Thanks,
Rob


On 02/11/2017 08:50, Mahesh Jethanandani wrote:

Kristian,

I hear you. What I am providing is the rational for the current
design.

I would like to hear from others in the WG. We have been reviewing
this draft for the last couple of years, and we are now at the tail
end of the LC. I would really like to see this draft move forward,
particularly since it is not broken.

Thanks.


On Nov 2, 2017, at 2:13 PM, Kristian Larsson <kristian@spritelink.net>
wrote:


On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote:
    On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder <
    j.schoenwaelder@jacobs-university.de> wrote:

    Mahesh,

    I think the question is why we need to have different match containers
    for each possible feature set combination instead of having a single
    match container with groups of leafs in it marked as features. This
    would seem to cut down the size of the module and the tree diagram
    significantly. I think this will also make clients simpler sicne they
    do not have to select a certain container based on the feature set
    announced.


The current design of match containers was chosen to allow platforms
to select
one container that matched what the hardware supported from a l2, l3
and ipv
{4,6} perspective.

Sure, but you are conflating the structure of the model with the
feature-wraps. Without changing the features of the model, we can
structure it in a different way where there is not a 1:1 mapping
between features and containers under the matches container.



I would argue that even though the overall diagram is bigger
with this design, once the platform selects the container of choice,
the tree
and the configuration itself would be a little simpler/smaller.

I am arguing the opposite. It's really awkward to place the same
type of data, like IPv4 match conditions, under different paths
based on a feature.

If the system model had done the same we would have:
/system
/system-with-ntp
/system-with-ntp-and-radius

How do you augment in new leaves? While you are using groupings
which allows for a reuse of data across all these containers,
someone who is augmenting can't, since you can't augment a
container, only where it is used. Someone wishing to add a leaf
to the model needs to augment in three different locations to
support a new match condition for IPv4 (let's say some meta-data
attribute).



Take the case where the desired selection is l2,-l3, ipv4 and
ipv6. The current
tree looks like this:


        |        |  +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}?
        |        |  |  +--rw destination-mac-address?  yang:mac-address
        |        |  |  +--rw destination-mac-address-mask?
        |        |  |  yang:mac-address
        |        |  |  +--rw source-mac-address?  yang:mac-address
        |        |  |  +--rw source-mac-address-mask?  yang:mac-address
        |        |  |  +--rw ethertype?                      eth:ethertype
        |        |  |  +--rw dscp?                           inet:dscp
        |        |  |  +--rw ecn?                            uint8
        |        |  |  +--rw length?                         uint16
        |        |  |  +--rw ttl?                            uint8
        |        |  |  +--rw protocol?                       uint8
        |        |  |  +--rw source-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operation?    operator
        |        |  |  +--rw destination-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operations?   operator
        |        |  |  +--rw ihl?                            uint8
        |        |  |  +--rw flags?                          bits
        |        |  |  +--rw offset?                         uint16
        |        |  |  +--rw identification?                 uint16
        |        |  |  +--rw destination-ipv4-network?  inet:ipv4-prefix
        |        |  |  +--rw source-ipv4-network?  inet:ipv4-prefix
        |        |  |  +--rw next-header?                    uint8
        |        |  |  +--rw destination-ipv6-network?  inet:ipv6-prefix
        |        |  |  +--rw source-ipv6-network?  inet:ipv6-prefix

        |        |  |  +--rw flow-label?
        |        |  |          inet:ipv6-flow-label



whereas, if the design went with one match container with each group
of leafs
in their own container (to support the if-feature statement for that
container), the tree would look like this:


        |        |  +--rw l2-acl {l2-acl}?
        |        |  |  +--rw destination-mac-address?  yang:mac-address
        |        |  |  +--rw destination-mac-address-mask?
        |        |  |  yang:mac-address
        |        |  |  +--rw source-mac-address?  yang:mac-address
        |        |  |  +--rw source-mac-address-mask?  yang:mac-address
        |        |  |  +--rw ethertype?                      eth:ethertype

        |        |  +--rw ipv4-acl {ipv4-acl}?
        |        |  |  +--rw dscp?                       inet:dscp
        |        |  |  +--rw ecn?                        uint8
        |        |  |  +--rw length?                     uint16
        |        |  |  +--rw ttl?                        uint8
        |        |  |  +--rw protocol?                   uint8
        |        |  |  +--rw source-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operation?    operator
        |        |  |  +--rw destination-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operations?   operator
        |        |  |  +--rw ihl?                        uint8
        |        |  |  +--rw flags?                      bits
        |        |  |  +--rw offset?                     uint16
        |        |  |  +--rw identification?             uint16
        |        |  |  +--rw destination-ipv4-network?   inet:ipv4-prefix
        |        |  |  +--rw source-ipv4-network?        inet:ipv4-prefix
        |        |  +--rw ipv6-acl {ipv6-acl}?
        |        |  |  +--rw dscp?                       inet:dscp
        |        |  |  +--rw ecn?                        uint8
        |        |  |  +--rw length?                     uint16
        |        |  |  +--rw ttl?                        uint8
        |        |  |  +--rw protocol?                   uint8
        |        |  |  +--rw source-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operation?    operator
        |        |  |  +--rw destination-port-range!
        |        |  |  |  +--rw lower-port    inet:port-number
        |        |  |  |  +--rw upper-port?   inet:port-number
        |        |  |  |  +--rw operations?   operator
        |        |  |  +--rw next-header?                uint8
        |        |  |  +--rw destination-ipv6-network?   inet:ipv6-prefix
        |        |  |  +--rw source-ipv6-network?        inet:ipv6-prefix
        |        |  |  +--rw flow-label?  inet:ipv6-flow-label


The difference though is small and comes down to a preference. Select
one
feature statement and get one container with everything in it, or
define
multiple feature statements and assemble together the pieces to define
the ACE
entry.

Again, I think you mix up the features available vs the structure
of the data.

This is the current list of features (which again, I want to
change but that's separate):
* l2-acl
* ipv4-acl
* ipv6-acl
* mixed-ipv4-acl
* mixed-ipv6-acl
* l2-l3-ipv4-ipv6-acl
* tcp-acl
* udp-acl
* icmp-acl
* any-acl

As per your second example above we have an ipv4-acl container
under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl.
It is only possible to define ipv4 matches if one of the
following features are present:
* ipv4-acl
* mixed-ipv4-acl
* l2-l3-ipv4-ipv6-acl

Thus you write an if-feature statement to reflect that, like
this:

if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl";

So you see, the tight coupling you have between the data
structure and the if-features isn't necessary.

I think the structure should first be established without
features and then features can be inserted where they make sense
to make part of the model optional. Starting with the list of
features and then designing the structure around them makes for a
much less natural data structure IMHO.

Kind regards,
   Kristian.

Mahesh Jethanandani
mjethanandani@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.



      

      
.



    

    

  


--------------7242F4202282C92A9E9E246A--


From nobody Thu Nov  2 06:28: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 D4B3913F65E for ; Thu,  2 Nov 2017 06:28:11 -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 ojjjwVjTnhLg for ; Thu,  2 Nov 2017 06:28:09 -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 CCE2613F45D for ; Thu,  2 Nov 2017 06:28:07 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id l23so6466718lfk.10 for ; Thu, 02 Nov 2017 06:28:07 -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:content-transfer-encoding:thread-index :content-language; bh=lBX+2lhz3UqT5NU3fw0G59m7xFBslrorOJBUSpyh4jo=; b=j3WT3BdtqS4X+mp4DL76BytQeYu94aiUm7zpUav8tVws7Iaff7diEjds8ryZSVFXJl wvnU2Ymj8CPnUMp7K3xhB/pe/tPDv/NnpHqmrHZGEI1MU6QEaadnl0O9eoqKkapfzJ5P gpjVLAj6SQJ7SRgqTOM8F32Aoy91haPEdbScLPoMtNFQqyRjiYByLTY58DCYSN2j7s4D ia/FkmqnQLCVl3wM8Sal/aYSELST04trehrJR+izkYviZgA1Q6ZpwAVY7QRicS/hHfiN 9sWNW5pDggQTOliJYpoTiicoZUkr3K1dxZTTGCBmh1Q8+qNoDbSooJK3JXiiRTSHZiiH ttlA==
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:content-transfer-encoding:thread-index :content-language; bh=lBX+2lhz3UqT5NU3fw0G59m7xFBslrorOJBUSpyh4jo=; b=QOMfiJ4f6FznF0o0mbjEQHhpqr9ILUUdf+qHpSQT7t1bmz3dV9rRhZW9jQUfGn3t/1 4/neyvJCaeV2+ujV2+DGdfJVk1TP7aLBPNH/oB+Vsexq/HdjQdqQmSRZ/MM4g7acZ055 naC0/VzIRfAw5GGCiYGI9G09JqPvcdtM2eiM8ne77osTJP1ePO05IHjLyqQ+VlCfQcQv Gh4cNscj2PnYlOVdK7B6SoA/4U8lP4JQ6hb4r24eop2as8/PCan95DFto8+/d80ZD1gS ggpqSF+vyvQ/hr6GU/RrOFFu7FCcVcZ8bttmqxibVEivuYxFBiOds5Cu4lzvfZy79zwq mmiQ==
X-Gm-Message-State: AMCzsaWCLiekkYD4xILW7sOIx8A9ztKfXGALgj/3ztUUtItYGgEj7Xo/ flh9MmJbhAMW+/QrqWyF/nvnDSI+
X-Google-Smtp-Source: ABhQp+Sqkl0lduClDStRZ3pCwZ2LkyJjcupB1FhazAVKGGrUeckontKUOLZelSg22757SCqexFYh0Q==
X-Received: by 10.46.68.73 with SMTP id r70mr1536732lja.174.1509629286065; Thu, 02 Nov 2017 06:28:06 -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 r90sm667833ljb.64.2017.11.02.06.28.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 06:28:05 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Juergen Schoenwaelder'" 
Cc: "'Kent Watsen'" , 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <001c01d3534a$97f29860$c7d7c920$@gmail.com> <20171101223352.3es542cyjtsmrknp@elstar.local>
In-Reply-To: <20171101223352.3es542cyjtsmrknp@elstar.local>
Date: Thu, 2 Nov 2017 09:28:02 -0400
Message-ID: <005401d353de$6a4a3690$3edea3b0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIYMQhSaL4XogxOYiMUWbllTouW5wLQqxtgAJUZ7uKiXCvsUA==
Content-Language: en-us
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWE1MzhmMDZjLWJmZDEtMTFlNy05YzJlLTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxhNTM4ZjA2ZS1iZmQxLTExZTctOWMyZS0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjIzNTciIHQ9IjEzMTU0MTAyODgyMDA2MjUzOSIgaD0iQ1krZ3RtYkoxNFU5Zm5GQUpwY0dzK1IyZGZvPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
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: Thu, 02 Nov 2017 13:28:12 -0000

Yes. I've reviewed this document and believe it is ready for publication.
There are other works that are in progress and depend on this document. It
would be good to see this one published.

Thanks,
- Xufeng

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Wednesday, November 1, 2017 6:34 PM
> To: Xufeng Liu 
> Cc: 'Kent Watsen' ; netmod@ietf.org
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
> 
> Does 'Yes/support' imply "I've reviewed this document and believe it is
ready for
> publication"?
> 
> /js
> 
> On Wed, Nov 01, 2017 at 03:49:53PM -0400, Xufeng Liu wrote:
> > Yes/support.
> >
> > Thanks,
> > - Xufeng
> >
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent
> > > Watsen
> > > Sent: Friday, October 20, 2017 5:38 PM
> > > To: netmod@ietf.org
> > > Subject: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
> > >
> > > 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
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Thu Nov  2 07:28: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 06FF513F91E for ; Thu,  2 Nov 2017 07:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58gKBSO6P0yJ for ; Thu,  2 Nov 2017 07:28:37 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 D0737139689 for ; Thu,  2 Nov 2017 07:28:37 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id b6so4753042pfh.7 for ; Thu, 02 Nov 2017 07:28:37 -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:cc; bh=Q6j7KwVrOQHUapPgkGIBCTVcsCkjkZ9qKiRPTg878uU=; b=kWSb6puBNahiFljuHdINJWThmYrorKZKYL/PeCSNjiwxopIRMxkYyNKUA7Da+knTun mkD0fFzSmszL5JpAZQJvfwy/NTyeIECVsg+4+guUxSocYbZMFHJKUUSx5Hf0qtwEN2TI R1zuIdXvlByp+p6zYHk+P3SK2BLLXa6+03+XtuRTlwlIvfBwdwsgrfPlL3VNJu/VRDni 2byCDi47FByuW+6JOeDc1TNrnJPNiOVzL0svQHnXn1sYRGV07duFEjHI6tlEzK8qDOPd o+RatwZ1WvZsIsbrP6n4trG7hV2iBi87gZ1eCIU3ftaYsJ/B0AbueDezbIin8PR+X6Wp CaKg==
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:cc; bh=Q6j7KwVrOQHUapPgkGIBCTVcsCkjkZ9qKiRPTg878uU=; b=tamvgqAS/XCbSJ3/IaeuA7DYWbGu12teyYX0WDj2az0Pm8KB4Ogl7zSnxmpWY2M0/m Gee1iysBALPPwDVaJaDToUK5iTGEDAHjXDVWKlqfYnaJF8MB7FPgaM9e/4uf5DUJNUbD NfchOXlDo4WslxUf+RhRumb4bq7OE6j+bxEN36EsXqYdyF5FJDZogWf42euQxP0mMfmF o+lir0rOJuXBdVvN56PCKQsdRfLcIZ5+ziYzupgCCMQFL1e9xha+pVJidx3CJgQhmd45 WMDXmXnJ3vv8KB5+l6HdA1dWwHW4Bp0ZDaTjG/CGvAiEGeGjBRZjLIGKw5O075sg2lPw j8HQ==
X-Gm-Message-State: AMCzsaVe+jWKE3/CTQNZ5YWvnvdQVVnyUoiCVebzx/YjbZtaEBI1WCiC O0dPH014WUkvl8vjI4b6OR4+4b5EpEuV2fPKLwKLVw==
X-Google-Smtp-Source: ABhQp+TPkVm3DAow8FU0tYGvKrt4MvXS7g8UyiljTLqRku/yrYzUHWTlEFQpJjQ5EWI5tRKeFKtcKm8lXb+Nh6vsa0Q=
X-Received: by 10.99.188.9 with SMTP id q9mr3824716pge.104.1509632916749; Thu, 02 Nov 2017 07:28:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.161.194 with HTTP; Thu, 2 Nov 2017 07:28:36 -0700 (PDT)
From: nicola sambo 
Date: Thu, 2 Nov 2017 15:28:36 +0100
Message-ID: 
To: netmod@ietf.org
Cc: Fioccola Giuseppe , Haoyu song ,  Tianran Zhou , n.sambo@sssup.it
Content-Type: multipart/alternative; boundary="f403045e3ba2be82cf055d00cd5c"
Archived-At: 
Subject: [netmod] YANG model for finite state machine
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 14:28:40 -0000

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

Dear all,

we submitted a draft on a YANG model for finite state machine. At the time
of IETF 99 it was originally submitted in OPSAWG and discussed in Prague.

We reviewed the draft based on the comments in Prague and placed it in
NETMOD. In particular, we made it more generic and we included three use
cases of applications: i) reconfiguration of optical flexible transponders;
ii) network telemetry; iii) monitoring of packet loss and delay.

Any comment/suggestion is welcome to improve it and start a discussion.

Here the link: *https://datatracker.ietf.org/doc/draft-sambo-netmod-yang-fsm/?include_text=1
*

Thanks. Best regards,
Nicola

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


Dear all,

we submitt=
ed a draft on a YANG model for finite state machine. At the time of IETF 99=
 it was originally submitted in OPSAWG and discussed in Prague.=C2=A0
=


W=
e reviewed the draft based on the comments in Prague and placed it in NETMO=
D. In particular, we made it more generic and we included three use cases o=
f applications: i) reconfiguration of optical flexible transponders; ii) ne=
twork telemetry; iii)=C2=A0monitoring of p=
acket=C2=A0loss and delay.

Any comment/suggestion is welcome to im=
prove it and start a discussion.=C2=A0

<=
br>
Thanks. Best regards,
Nicola


--f403045e3ba2be82cf055d00cd5c--


From nobody Thu Nov  2 07:50: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 0CB1713FA8C for ; Thu,  2 Nov 2017 07:50:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOiWasKtHYft for ; Thu,  2 Nov 2017 07:50:50 -0700 (PDT)
Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 7E0F913FA3C for ; Thu,  2 Nov 2017 07:50:50 -0700 (PDT)
Received: by mail-ot0-x22c.google.com with SMTP id d36so1628974otf.1 for ; Thu, 02 Nov 2017 07:50:50 -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=WOtK1nRA1Vrbf3F/hSp76TB/wxD0tiiEYIoU/pKXiTY=; b=Nhrnah8gss64jgiFeeiNTXUk/xEQxHGtpWGsBLNf1W2WT0G5jWUyIvIdjEC9tXdS5V qAW+D/9dVnkAncyOVmYsWMmXqYKihvTD6DHb0n3iMN/iG8Ku8QBaAvKI3CjbXiMltTm1 5xJq6EXIc7gzNvhuIhINdj7QYBz6bzeFngLWElZ7zBm40sQgxcPFbW+CQ3tnMAsduVrp VhIC4YN+PyM7u1y3WWt7y//V11wl4SzSBSZ8A1Ssz+DZ+C1GDCsnmi2TVteRSXBPyM9s MwYfh7y+foIU8y0y4EnIZd27WR6EBWRWugOWMjc7X1bLmrh1yE/CuY9olyoF5klHQxWP 8VEQ==
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=WOtK1nRA1Vrbf3F/hSp76TB/wxD0tiiEYIoU/pKXiTY=; b=eT4WEekaaPP311qENf0W05hWh5daCM07/10r69B/xb0Oi3yBDtb+zwKsbEEpulZOoE pjpcbyk3dSqM5cBqqk0ggfjPVeAOaIdcDhCtYHEWtjWvCYnEkRMxg05lSH1pQPoqIR2v gV/r41zpiubWLF78GdyAW6m7U4yE/FCanBVIJoJKmeU/pBvT8H2ElIIhuHnesxKqhASZ YMlSYKkuNWb4uJdNx7vzAJ6TrOWJyLZtNvxAlKtv0umqfK6tDhFo5YDM6dOAPRkCBjop ss3fagLgRIvRu9sGo1gYAS3h1ZFwZues8RCNdKZmJz0G75+ngOpA4X8WlfiaNPWAGtaj WVjg==
X-Gm-Message-State: AJaThX4UzV/TTdFWa4TH2GKT23syS8GyC4EE8GCQN16j3tYWK37Ta6rv BtYw3oddbNT2/K2FuBIQCLrzhJm86+dYoMrcOZ0=
X-Google-Smtp-Source: ABhQp+TLkIYYRLUbnacE9/JougSdPZ3vlmVxAeNWFcGvIYzM3Sxib7meTx5sLkaJiF698NWCaF+Mj4ERnVgxg+1d4bw=
X-Received: by 10.157.48.124 with SMTP id w57mr2385481otd.440.1509634249610; Thu, 02 Nov 2017 07:50:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.133 with HTTP; Thu, 2 Nov 2017 07:50:09 -0700 (PDT)
In-Reply-To: <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com>
References:  <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com>
From: "M. Ranganathan" 
Date: Thu, 2 Nov 2017 10:50:09 -0400
Message-ID: 
To: Mahesh Jethanandani 
Cc: netmod@ietf.org
Content-Type: multipart/alternative; boundary="001a113b1bbc305af0055d011d19"
Archived-At: 
Subject: Re: [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: Thu, 02 Nov 2017 14:50:52 -0000

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

Hi Mahesh,



On Wed, Nov 1, 2017 at 11:32 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> Ranga,
>
> Is there a reason why you do not want to consider augmenting the model,
> particularly since you seem to want to use the entire model?
>


Yes. I want to include other metadata (specifically MUD + other management
data modeled using YANG) associated with the ACL in a container in my own
model. For this I want to import access-lists from the ACL YANG model but
as it currently stands, I can't.

With the way it has been defined (i.e. as a container and not a grouping),
I cannot include it in another YANG model. It would be perfect if the
access-lists could be made into a grouping as suggested. Nothing else needs
to change as far as I am concerned.

Thanks!

Regards,

Ranga.





>
> > On Oct 31, 2017, at 8:39 PM, M. Ranganathan  wrote:
> >
> > 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
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>


-- 
M. Ranganathan

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


Hi Mahesh,



On Wed, Nov 1, 2017 at 11:32 PM, Mahesh Je=
thanandani <mjethanandani@gmail.com> wrote:
Ranga,



Is there a reason why you do not want to consider augmenting the model, par=
ticularly since you seem to want to use the entire model?
<=
div>

Yes. I want to include other metadata (specifically =
MUD + other management data modeled using YANG) associated with the ACL in =
a container in my own model. For this I want to import access-lists from th=
e ACL YANG model but as it currently stands, I can't.

With the way it has been defined (i.e. as a container and not a grouping),=
 I cannot include it in another YANG model. It would be perfect if the acce=
ss-lists could be made into a grouping as suggested. Nothing else needs to =
change as far as I am concerned.

Thanks!
Regards,

Ranga.


=


=C2=A0




> On Oct 31, 2017, at 8:39 PM, M. Ranganathan <mranga@gmail.com> wrote:

>

> 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 groupin=
g in another YANG model using a "uses" statement.

>

> Thanks in advance for considering it.

>

> Regards,

>

> Ranga.

>

> --

> M. Ranganathan


> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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



Mahesh Jethanandani

mjethanandani@gmail.com







-- 
M. Ranganathan
=





--001a113b1bbc305af0055d011d19--


From nobody Thu Nov  2 08:01: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 4640E13F66C for ; Thu,  2 Nov 2017 08:00: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, 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 HveWToOfmppg for ; Thu,  2 Nov 2017 08:00:51 -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 3745A13FA9D for ; Thu,  2 Nov 2017 08:00:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8779; q=dns/txt; s=iport; t=1509634851; x=1510844451; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=EvZlhyoZxdChn9mhF9Lm9mf3JS6NDTGHKOgwPPdIvEM=; b=PaXqK42fHgpxc0nxEomyexnwr5y9uqyajE65x/vO0D9cjKtEMJlG48dH N4CuNsTc9LSyouEuAWDsvUVTj77kH8uhQTFVz1VSptmsfCo6qljNFjwzV PnJfgxrHIhE5f2YYxglD4LgGX/mXwjh++OEnBkMzrL3RBJQJT5iNMjoc6 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAADXMvtZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhBhuJ4N9ih90kCOIUIgvhUaCEQoYAQqESU8ChQ4YAQEBAQEBAQE?= =?us-ascii?q?BayiFHQEBAQMBAQEhSwsFCwsYJwMCAiEGHxEGAQwGAgEBigcDDQgQqG2CJyaHH?= =?us-ascii?q?A2DSAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgy6DWoISgwGBSIEihTyCYgWZBoh?= =?us-ascii?q?LPJADhHmLeIc6jRqBD4dtgTkfOIFsNCEIHRVJgmSCI0UpgU5BNo1DAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,334,1505779200";  d="scan'208,217";a="658467688"
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 Nov 2017 15:00:49 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA2F0mBc014167; Thu, 2 Nov 2017 15:00:48 GMT
To: "M. Ranganathan" , Mahesh Jethanandani 
Cc: netmod@ietf.org
References:  <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com> 
From: Robert Wilton 
Message-ID: 
Date: Thu, 2 Nov 2017 15:00:48 +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: multipart/alternative; boundary="------------25933ABD8FF4B517F3A98740"
Content-Language: en-US
Archived-At: 
Subject: Re: [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: Thu, 02 Nov 2017 15:00:58 -0000

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

Hi Ranga,

Presumably another choice would to keep ACLs defined in one place (i.e. 
no grouping required), augment with ACL model with your extra MUD + 
other mgmt data, and then have a reference to that ACL from your model.

Thanks,
Rob


On 02/11/2017 14:50, M. Ranganathan wrote:
> Hi Mahesh,
>
>
>
> On Wed, Nov 1, 2017 at 11:32 PM, Mahesh Jethanandani 
> > wrote:
>
>     Ranga,
>
>     Is there a reason why you do not want to consider augmenting the
>     model, particularly since you seem to want to use the entire model?
>
>
>
> Yes. I want to include other metadata (specifically MUD + other 
> management data modeled using YANG) associated with the ACL in a 
> container in my own model. For this I want to import access-lists from 
> the ACL YANG model but as it currently stands, I can't.
>
> With the way it has been defined (i.e. as a container and not a 
> grouping), I cannot include it in another YANG model. It would be 
> perfect if the access-lists could be made into a grouping as 
> suggested. Nothing else needs to change as far as I am concerned.
>
> Thanks!
>
> Regards,
>
> Ranga.
>
>
>
>
>
>     > On Oct 31, 2017, at 8:39 PM, M. Ranganathan      > wrote:
>     >
>     > 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
>     > _______________________________________________
>     > netmod mailing list
>     > netmod@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/netmod
>     
>
>     Mahesh Jethanandani
>     mjethanandani@gmail.com 
>
>
>
>
> -- 
> M. Ranganathan
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    
Hi Ranga,

    
Presumably another choice would to keep ACLs defined in one place
      (i.e. no grouping required), augment with ACL model with your
      extra MUD + other mgmt data, and then have a reference to that ACL
      from your model.

    
Thanks,

      Rob

    

    

    
On 02/11/2017 14:50, M. Ranganathan
      wrote:

    

    

      
      

        
Hi Mahesh,

          

        

        

        


          
On Wed, Nov 1, 2017 at 11:32 PM,
            Mahesh Jethanandani <mjethanandani@gmail.com>
            wrote:

            
Ranga,

              

              Is there a reason why you do not want to consider
              augmenting the model, particularly since you seem to want
              to use the entire model?

            

            


              

            

            
Yes. I want to include other metadata (specifically MUD
              + other management data modeled using YANG) associated
              with the ACL in a container in my own model. For this I
              want to import access-lists from the ACL YANG model but as
              it currently stands, I can't.

              

            

            
With the way it has been defined (i.e. as a container
              and not a grouping), I cannot include it in another YANG
              model. It would be perfect if the access-lists could be
              made into a grouping as suggested. Nothing else needs to
              change as far as I am concerned.

              

            

            
Thanks!

            

            


            

            
Regards,

              

            

            
Ranga.

            

            


              

            

            


               

            

            

              

                


                  > On Oct 31, 2017, at 8:39 PM, M. Ranganathan <mranga@gmail.com>
                  wrote:

                  >

                  > 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

                

              

              > _______________________________________________

              > netmod mailing list

              > netmod@ietf.org

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

              

                  Mahesh Jethanandani

                  mjethanandani@gmail.com

                  

                

          

          

          

          

          -- 

          
M.
            Ranganathan

          

        

      

      

      

      

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


    

    

  


--------------25933ABD8FF4B517F3A98740--


From nobody Thu Nov  2 08:35: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 C232113FAB8 for ; Thu,  2 Nov 2017 08:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MfK2Wh7lznNb for ; Thu,  2 Nov 2017 08:35:18 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 D516813FAB3 for ; Thu,  2 Nov 2017 08:35:17 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id a132so9182360oih.11 for ; Thu, 02 Nov 2017 08:35:17 -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=gREjYiIwR4FY54pGc8ICJPPOwLPmfaV76rt+qZ2MZEk=; b=ICzOp3quhlTgNBBxzf0Xtq/gaeoLn9pYGwwjz28bGd0usHiVbrQvCY5Fr5nOnjVWik E4vCwqkQg2CucvcU98KLtpGLII8Iozp2ohpI/P4JwDBdlJBBCcRg7qY20zVaEBZUHSUU x6r4YXKui7lWLwQIeLXaNPc6XUsmZNCu2iAuDZz0n9ZJEiS7twbkQVgW9gEOc58rRVeN UOD4Gb61FZXPGIx6Fc5qb51iQn6gwhxiwzjUlkFACRYOnlpkwgEMf2mhS2R92R9gvg97 jc3f+k3nL0G93vYHBn2KsqAZxs6MmvlReKMOvJNOHuYgaVxCk0BZrLEtuOgtG9/xstmY jW+w==
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=gREjYiIwR4FY54pGc8ICJPPOwLPmfaV76rt+qZ2MZEk=; b=dsttUdGtdbuzcSqPMc1+3TlJnJ+TmKTbyDXT8t7fodQr1ZczpBfMYzUEclTHp3+9y4 eVq/EKV5rgwpxNOvkspACWtOCIRI3p+YQe19z2y6vc/o3nBJnc1mxx1W0YLKJSRwb0hk d8tVzQ93M1vFnLjETDqJv29vC876SbsRwup59YwqV8pMQ9rcx5lAIdTv3d7QJxg3+7cn e4yEYnRg9I/9WDjHpMusSr9RP0fjWgAtprLuWt732KXNfvBk8k3LLePDWeTrJy5NLs1w RkebGbOiaBcMcWfBVrsoI+P6Z7iMmyUYYCH5J/2MjV/qnjfAW/2GUmbpvHvcKIXfPrnx CpCA==
X-Gm-Message-State: AJaThX5Q4fqH3EAsqEfOVLF5YgDuy3uDuU4gZzAm2TaXDnO/XEH+pOtb UfJLcM2jCdYYyACU8MDu9z61AzpH6/CmOBJbzU8=
X-Google-Smtp-Source: ABhQp+RCMK5oMfGNcMUxGlDEWwDWLc/oabeUJ6c4gUr25lH7vAHZOqk/06A/y9u0Cr3TAsXxZG4nsuiWkFF/WGEPqII=
X-Received: by 10.157.48.124 with SMTP id w57mr2493460otd.440.1509636916972; Thu, 02 Nov 2017 08:35:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.133 with HTTP; Thu, 2 Nov 2017 08:34:36 -0700 (PDT)
In-Reply-To: 
References:  <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com>  
From: "M. Ranganathan" 
Date: Thu, 2 Nov 2017 11:34:36 -0400
Message-ID: 
To: Robert Wilton 
Cc: Mahesh Jethanandani , netmod@ietf.org
Content-Type: multipart/alternative; boundary="001a113b1bbc2d130d055d01bce0"
Archived-At: 
Subject: Re: [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: Thu, 02 Nov 2017 15:35:20 -0000

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

Hi Rob, Mahesh,

Thanks for reading.

On Thu, Nov 2, 2017 at 11:00 AM, Robert Wilton  wrote:

> Hi Ranga,
>
> Presumably another choice would to keep ACLs defined in one place (i.e. no
> grouping required), augment with ACL model with your extra MUD + other mgmt
> data, and then have a reference to that ACL from your model.
>
> Thanks,
> Rob
>

 In the case of MUD ( which is just a use case driving this need ), there
are local references from MUD to the ACL. MUD itself augments the ACL
model.

Augmentation would make (logical and design) sense if you were adding nodes
that are in some way related to the ACL itself.

If I wanted to Augment ACL with something that is not directly ACL relevant
then Augmentation makes less sense to me from a design perspective (lets
say I wanted to define a new YANG model that includes the ACL with some
other system-relavant meta-data that has nothing to do with ACLs but is
needed by the system in order to install an ACL).

Making access-lists into a grouping and then using it in a container does
not alter the ACL model as it currently stands but allows designers to use
the ACL model with either augmentation or inclusion in other YANG models.
Hence it improves the usability of the ACL model without altering the
semantics of the current model. It is just a re-structuring but it helps
the implementer.


Regards,

Ranga


> On 02/11/2017 14:50, M. Ranganathan wrote:
>
> Hi Mahesh,
>
>
>
> On Wed, Nov 1, 2017 at 11:32 PM, Mahesh Jethanandani <
> mjethanandani@gmail.com> wrote:
>
>> Ranga,
>>
>> Is there a reason why you do not want to consider augmenting the model,
>> particularly since you seem to want to use the entire model?
>>
>
>
> Yes. I want to include other metadata (specifically MUD + other management
> data modeled using YANG) associated with the ACL in a container in my own
> model. For this I want to import access-lists from the ACL YANG model but
> as it currently stands, I can't.
>
> With the way it has been defined (i.e. as a container and not a grouping),
> I cannot include it in another YANG model. It would be perfect if the
> access-lists could be made into a grouping as suggested. Nothing else needs
> to change as far as I am concerned.
>
> Thanks!
>
> Regards,
>
> Ranga.
>
>
>
>
>
>>
>> > On Oct 31, 2017, at 8:39 PM, M. Ranganathan  wrote:
>> >
>> > 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
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
>>
>
>
> --
> M. Ranganathan
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>


-- 
M. Ranganathan

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


Hi Rob, Mahesh,

Thanks for reading.
<=
div>

On Thu, =
Nov 2, 2017 at 11:00 AM, Robert Wilton <rwilton@cisco.com> w=
rote:

 =20
   =20
 =20
  

    
Hi Ranga,

    
Presumably another choice would to keep ACLs defined in one place
      (i.e. no grouping required), augment with ACL model with your
      extra MUD + other mgmt data, and then have a reference to that ACL
      from your model.

    
Thanks,

      Rob

=C2=A0In the case o=
f MUD ( which is just a use case driving this need ), there are local refer=
ences from MUD to the ACL. MUD itself augments the ACL model. 

Augmentation would make (logical and design) sense if you were adding=
 nodes that are in some way related to the ACL itself.

If=
 I wanted to Augment ACL with something that is not directly ACL relevant t=
hen Augmentation makes less sense to me from a design perspective (lets say=
 I wanted to define a new YANG model that includes the ACL with some other =
system-relavant meta-data that has nothing to do with ACLs but is needed by=
 the system in order to install an ACL).

Making access-li=
sts into a grouping and then using it in a container does not alter the ACL=
 model as it currently stands but allows designers to use the ACL model wit=
h either augmentation or inclusion in other YANG models. Hence it improves =
the usability of the ACL model without altering the semantics of the curren=
t model. It is just a re-structuring but it helps the implementer. 

=

Regards,

Ranga


    

    

    
On 02/11/2017 14:50,=
 M. Ranganathan
      wrote:

    

    

     =20
      

        
Hi Mahesh,

          

        

        

        


          
On Wed, Nov 1, 2017 at 11:32 PM,
            Mahesh Jethanandani <mjethanandani@gmail.com>
            wrote:

            
Ranga,

              

              Is there a reason why you do not want to consider
              augmenting the model, particularly since you seem to want
              to use the entire model?

            

            


              

            

            
Yes. I want to include other metadata (specifically MUD
              + other management data modeled using YANG) associated
              with the ACL in a container in my own model. For this I
              want to import access-lists from the ACL YANG model but as
              it currently stands, I can't.

              

            

            
With the way it has been defined (i.e. as a container
              and not a grouping), I cannot include it in another YANG
              model. It would be perfect if the access-lists could be
              made into a grouping as suggested. Nothing else needs to
              change as far as I am concerned.

              

            

            
Thanks!

            

            


            

            
Regards,

              

            

            
Ranga.

            

            


              

            

            


              =C2=A0

            

            

              

                


                  > On Oct 31, 2017, at 8:39 PM, M. Ranganathan <mranga@gmail.com>
                  wrote:

                  >

                  > 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" stateme=
nt 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

                

              

              > _______________________________________________

              > netmod mailing list

              > net=
mod@ietf.org

              > https://www.ietf.org/mailman/lis=
tinfo/netmod

              

                  Mahesh Jethanandani

                  mjethanandani@gmail.com

                  

                

          

          

          

          

          -- 

          
M.
            Ranganathan

          

        

      

      

      

      

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


    

    

  






-- 
M. Ranganathan




--001a113b1bbc2d130d055d01bce0--


From nobody Thu Nov  2 08:55: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 C6980139504 for ; Thu,  2 Nov 2017 08:55:55 -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 ho3vXOohmtPn for ; Thu,  2 Nov 2017 08:55:53 -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 A7A421386A2 for ; Thu,  2 Nov 2017 08:55:52 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id g70so4008lfl.3 for ; Thu, 02 Nov 2017 08:55:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IsxtXCe/Y2KOn6nPLN78bVjkZmy0hj3P05Lii/4sQSc=; b=zA8xqEzJIvsju2JNT9q9lLNecIkhLq5LOwqQeMCXonc7Y4S40Ew3+z5A7EbCi5xIrM Yrp9DQ8nAVLc46UJKRnt6GatsFanrp76dklO50YYmcZl/XlMkOQZP0+wjw13t8AlCxvc yjog6QTWB7IkJrWDS5Ar+TARc6NoV+kHeA9NtLZ2UkFpkMnx+0PU/GkbiWAz7sRCtJJM UtA+ViOWlzpG77S/xQq2O7tnhwePIy3vH3G4uWGHeIffmuMsjFfzumP1wsieJ/aoKY7A JORdz0wHHdn7QFUnnXoLLdUFg4J+x1HfEM5ZJ3HkpExYPAprhCg4iNwPqFXr1UT9LTDb Pecg==
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=IsxtXCe/Y2KOn6nPLN78bVjkZmy0hj3P05Lii/4sQSc=; b=st+i2GxFVqi2Ylt5UHPBMm14UATfcJF2IkTnTc3ltMxSWRDXZKyWE5AZ4VULG/39wn PZF9y/fiYO7POtwy5qQd79erfhfEkteOZenbtv2yFUEUYinO6N9LlQL4czSMZ9me+kX0 IRWSjIIbHjl2wn2twT8H6rMg3hos7/Y27mihrsuX1bPpIEQGBe1t/19VHtpeCeZFpy67 o9ostixO+pkBCBOBKWHMmdK9l7O0qTcmmLy/l0SD+QuRlHe4H4Lb77pYVOtJ+Ksz+HDr ewObR/g0L8Eyje8NVB7KP/Koh5+FIoU0j0t8+O8+UUra/6aRe88Zq67QnvqDRik8DB7l 36Aw==
X-Gm-Message-State: AJaThX6q9tU3UI0xG2RV+noUbEkBVYjfCzuG7xJXTH9aVqCsaHkZAhX3 Y7R3nESnFWUIgVUji628gMdx0MEyW02b4959vBWtMQ==
X-Google-Smtp-Source: ABhQp+Sbk71HgBJUkbff3u7QsOD/7cn7yJuv5mFII4/hBxEBO0kFypuo+SfmFq6vRs16zrUx9AgMKeTLhhAw/h/OWIY=
X-Received: by 10.25.204.81 with SMTP id c78mr1561700lfg.49.1509638150937; Thu, 02 Nov 2017 08:55:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 2 Nov 2017 08:55:50 -0700 (PDT)
In-Reply-To: 
References:  <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com>   
From: Andy Bierman 
Date: Thu, 2 Nov 2017 08:55:50 -0700
Message-ID: 
To: "M. Ranganathan" 
Cc: Robert Wilton , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1a17c4b9f6b0055d020523"
Archived-At: 
Subject: Re: [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: Thu, 02 Nov 2017 15:55:56 -0000

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

On Thu, Nov 2, 2017 at 8:34 AM, M. Ranganathan  wrote:

> Hi Rob, Mahesh,
>
> Thanks for reading.
>
> On Thu, Nov 2, 2017 at 11:00 AM, Robert Wilton  wrote:
>
>> Hi Ranga,
>>
>> Presumably another choice would to keep ACLs defined in one place (i.e.
>> no grouping required), augment with ACL model with your extra MUD + other
>> mgmt data, and then have a reference to that ACL from your model.
>>
>> Thanks,
>> Rob
>>
>
>  In the case of MUD ( which is just a use case driving this need ), there
> are local references from MUD to the ACL. MUD itself augments the ACL
> model.
>
> Augmentation would make (logical and design) sense if you were adding
> nodes that are in some way related to the ACL itself.
>
> If I wanted to Augment ACL with something that is not directly ACL
> relevant then Augmentation makes less sense to me from a design perspective
> (lets say I wanted to define a new YANG model that includes the ACL with
> some other system-relavant meta-data that has nothing to do with ACLs but
> is needed by the system in order to install an ACL).
>
> Making access-lists into a grouping and then using it in a container does
> not alter the ACL model as it currently stands but allows designers to use
> the ACL model with either augmentation or inclusion in other YANG models.
> Hence it improves the usability of the ACL model without altering the
> semantics of the current model. It is just a re-structuring but it helps
> the implementer.
>
>
Loosely coupled tables should use leafref.
The main concern of the NETMOD WG should be the usability of the primary
solution.


>
> Regards,
>
> Ranga
>
>

Andy


>
>> On 02/11/2017 14:50, M. Ranganathan wrote:
>>
>> Hi Mahesh,
>>
>>
>>
>> On Wed, Nov 1, 2017 at 11:32 PM, Mahesh Jethanandani <
>> mjethanandani@gmail.com> wrote:
>>
>>> Ranga,
>>>
>>> Is there a reason why you do not want to consider augmenting the model,
>>> particularly since you seem to want to use the entire model?
>>>
>>
>>
>> Yes. I want to include other metadata (specifically MUD + other
>> management data modeled using YANG) associated with the ACL in a container
>> in my own model. For this I want to import access-lists from the ACL YANG
>> model but as it currently stands, I can't.
>>
>> With the way it has been defined (i.e. as a container and not a
>> grouping), I cannot include it in another YANG model. It would be perfect
>> if the access-lists could be made into a grouping as suggested. Nothing
>> else needs to change as far as I am concerned.
>>
>> Thanks!
>>
>> Regards,
>>
>> Ranga.
>>
>>
>>
>>
>>
>>>
>>> > On Oct 31, 2017, at 8:39 PM, M. Ranganathan  wrote:
>>> >
>>> > 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
>>> > _______________________________________________
>>> > netmod mailing list
>>> > netmod@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com
>>>
>>>
>>
>>
>> --
>> M. Ranganathan
>>
>>
>> _______________________________________________
>> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>
>
> --
> M. Ranganathan
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Thu, Nov 2, 2017 at 8:34 AM, M. Ranganathan <mranga@gmail.com>=
; wrote:
Hi =
Rob, Mahesh,

Thanks for reading.

On Thu, Nov 2, 2017 at 11:00 AM, =
Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Ranga,

    
Presumably another choice would to keep ACLs defined in one place
      (i.e. no grouping required), augment with ACL model with your
      extra MUD + other mgmt data, and then have a reference to that ACL
      from your model.

    
Thanks,

      Rob

=C2=A0In the case o=
f MUD ( which is just a use case driving this need ), there are local refer=
ences from MUD to the ACL. MUD itself augments the ACL model. 

Augmentation would make (logical and design) sense if you were adding=
 nodes that are in some way related to the ACL itself.

If=
 I wanted to Augment ACL with something that is not directly ACL relevant t=
hen Augmentation makes less sense to me from a design perspective (lets say=
 I wanted to define a new YANG model that includes the ACL with some other =
system-relavant meta-data that has nothing to do with ACLs but is needed by=
 the system in order to install an ACL).

Making access-li=
sts into a grouping and then using it in a container does not alter the ACL=
 model as it currently stands but allows designers to use the ACL model wit=
h either augmentation or inclusion in other YANG models. Hence it improves =
the usability of the ACL model without altering the semantics of the curren=
t model. It is just a re-structuring but it helps the implementer. 

=


Loosel=
y coupled tables should use leafref.
The main concern of the NETM=
OD WG should be the usability of the primary solution.
=C2=A0

Regards,

=

Ranga



Andy
=C2=A0
=


    

    

    
On 02/11/2017 14:50, M. Ranganathan
      wrote:

    

    

     =20
      

        
Hi Mahesh,

          

        

        

        


          
On Wed, Nov 1, 2017 at 11:32 PM,
            Mahesh Jethanandani <mjethanandani@gmail.com>
            wrote:

            
Ranga,

              

              Is there a reason why you do not want to consider
              augmenting the model, particularly since you seem to want
              to use the entire model?

            

            


              

            

            
Yes. I want to include other metadata (specifically MUD
              + other management data modeled using YANG) associated
              with the ACL in a container in my own model. For this I
              want to import access-lists from the ACL YANG model but as
              it currently stands, I can't.

              

            

            
With the way it has been defined (i.e. as a container
              and not a grouping), I cannot include it in another YANG
              model. It would be perfect if the access-lists could be
              made into a grouping as suggested. Nothing else needs to
              change as far as I am concerned.

              

            

            
Thanks!

            

            


            

            
Regards,

              

            

            
Ranga.

            

            


              

            

            


              =C2=A0

            

            

              

                
=


                  > On Oct 31, 2017, at 8:39 PM, M. Ranganathan <mranga@gmail.com>
                  wrote:

                  >

                  > 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" stateme=
nt 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

                

              

              > _______________________________________________

              > netmod mailing list

              > net=
mod@ietf.org

              > https://www.ietf.org/mailman/lis=
tinfo/netmod

              

                  Mahesh Jethanandani

                  mjethanandani@gmail.com

                  

                

          

          

          

          

          -- 

          
M.
            Ranganathan

          

        

      

      

      

      

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


    

    

  






-- 
M. Ranganathan




_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1a17c4b9f6b0055d020523--


From nobody Thu Nov  2 09:26: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 EAC0A13F729 for ; Thu,  2 Nov 2017 09:26:44 -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 1dpz6AI0Odcf for ; Thu,  2 Nov 2017 09:26:43 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 C87B613F5D1 for ; Thu,  2 Nov 2017 09:26:42 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id q4so91313oic.7 for ; Thu, 02 Nov 2017 09:26:42 -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=0Cjx1VEPirnLLL7N1qWyvrYSgGYe3yHyx2P5Xb2xQuY=; b=Dxa+BdrvRAsKpAi+Kbl1Et1RYYv/XGuukvuZ3gVbg99FZOWcPZj2doLHjmBDuCAPQL +nNeXU7zlrhoVV2gSfA0ATGnv7bjRmVzRHW4y+/uTJFha1U4Sma87wC5IpwCUk9HaQkS XdomNtAvVmBC4+jVbFFNuqr8InHU8fypizzWF5iz00kPDyw6oUTCYfrDyekD2Jn5VIQF JwUgGoewOgyp/Zw6eqfp46yyHczfJwMU6P+A1DjUEqjukjzVyBeuZjdo+dmfnxed6lR4 V6jDdu3Oq1uyVEBsfVXBBV+zmVbHGlc78zeTS60nu0ruIzhcoQ22Xm9WvngwaaEGfaFp az3Q==
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=0Cjx1VEPirnLLL7N1qWyvrYSgGYe3yHyx2P5Xb2xQuY=; b=YW2zTMKVzWYJqrg6IClFRFgH7VY3sQzbx+nNwDyNN/WalZhgCSyiq2+LfB2ORZ8Vei RIxK35ZfFBy8CHloQLypbS42oih9VOKB9XoSRy2hSdgLsDZGfrbTgoyo4rQlJTTyATKU iqhRZZkbqYv7WokI7/9MnDPUj0dlEPa+ENt1iPaSw/0HkMmiTAr1J4OyosMbwt/Th8Gr FiJBccO8zACz9ARK3N8Tp9spCpJMVjX2tu5SfZ6pOEqWwIMA7Lb/KHsaM61RSbfnRTcl dkh0AGNcoorKJLo4lldSSi4WhA6bgWFf6JTTdT4cjWE058oMTUUpfNPNRMXSIcb2B0kK E4pA==
X-Gm-Message-State: AMCzsaXGKlyg6tTkuSYKqosmCpk/OP3ZBeaVX6NKg6ZPNwcRLx2wnnrx Yrkx0uQ/gNZu51C1y7ISFPYPQPsyV2BnD/OmFT8=
X-Google-Smtp-Source: ABhQp+SosvMzX0WP86POEtEXOgGz5N19biFg/m3wE3uclbLxzGrF7HOonmTtG1nOgRTXchu5S745DUOe68y3eJirvZo=
X-Received: by 10.202.97.215 with SMTP id v206mr2187991oib.367.1509640002017;  Thu, 02 Nov 2017 09:26:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.133 with HTTP; Thu, 2 Nov 2017 09:26:01 -0700 (PDT)
In-Reply-To: 
References:  <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com>    
From: "M. Ranganathan" 
Date: Thu, 2 Nov 2017 12:26:01 -0400
Message-ID: 
To: Andy Bierman 
Cc: Robert Wilton , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113d21d40f1f29055d027474"
Archived-At: 
Subject: Re: [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: Thu, 02 Nov 2017 16:26:45 -0000

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

Hi Andy

On Thu, Nov 2, 2017 at 11:55 AM, Andy Bierman  wrote:

>
>
> On Thu, Nov 2, 2017 at 8:34 AM, M. Ranganathan  wrote:
>
>> Hi Rob, Mahesh,
>>
>> Thanks for reading.
>>
>> On Thu, Nov 2, 2017 at 11:00 AM, Robert Wilton  wrote:
>>
>>> Hi Ranga,
>>>
>>> Presumably another choice would to keep ACLs defined in one place (i.e.
>>> no grouping required), augment with ACL model with your extra MUD + other
>>> mgmt data, and then have a reference to that ACL from your model.
>>>
>>> Thanks,
>>> Rob
>>>
>>
>>  In the case of MUD ( which is just a use case driving this need ), there
>> are local references from MUD to the ACL. MUD itself augments the ACL
>> model.
>>
>> Augmentation would make (logical and design) sense if you were adding
>> nodes that are in some way related to the ACL itself.
>>
>> If I wanted to Augment ACL with something that is not directly ACL
>> relevant then Augmentation makes less sense to me from a design perspective
>> (lets say I wanted to define a new YANG model that includes the ACL with
>> some other system-relavant meta-data that has nothing to do with ACLs but
>> is needed by the system in order to install an ACL).
>>
>> Making access-lists into a grouping and then using it in a container does
>> not alter the ACL model as it currently stands but allows designers to use
>> the ACL model with either augmentation or inclusion in other YANG models.
>> Hence it improves the usability of the ACL model without altering the
>> semantics of the current model. It is just a re-structuring but it helps
>> the implementer.
>>
>>
> Loosely coupled tables should use leafref.
> The main concern of the NETMOD WG should be the usability of the primary
> solution.
>
>
>

Not sure I understand the suggestion of using a leafref (please excuse my
ignorance -- I am not a YANG expert by any stretch). If I used leafref,
what leaf would I be referring to if I wanted to point to the access
control list from another YANG model?

Also I note from the description of Access Control Lists the following that
would indicate that it is a primary solution that one may like to re-use in
another model.

 description
      "This is a top level container for Access Control Lists.
       It can have one or more Access Control Lists.";



If the requested change were made, would it result in excessive churn ?

Thanks

Regards,

Ranga.


-- 
M. Ranganathan

>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
>>
>>
>> --
>> M. Ranganathan
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>


-- 
M. Ranganathan

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


Hi Andy

On Thu, Nov 2, 2017 at 11:55 AM, Andy Bierman =
<andy@yumaworks.=
com> wrote:


On Thu, Nov 2, 2017 at 8:34 AM, M. Ranganath=
an <mranga@gmail.com> wrote:
Hi Rob, Mahesh,

Tha=
nks for reading.

On Thu, Nov 2, 2017 at 11:00 AM, Robert Wilton <rwilton@cisco=
.com> wrote:

 =20
   =20
 =20
  

    
Hi Ranga,

    
Presumably another choice would to keep ACLs defined in one place
      (i.e. no grouping required), augment with ACL model with your
      extra MUD + other mgmt data, and then have a reference to that ACL
      from your model.

    
Thanks,

      Rob

=C2=A0In the case o=
f MUD ( which is just a use case driving this need ), there are local refer=
ences from MUD to the ACL. MUD itself augments the ACL model. 

Augmentation would make (logical and design) sense if you were adding=
 nodes that are in some way related to the ACL itself.

If=
 I wanted to Augment ACL with something that is not directly ACL relevant t=
hen Augmentation makes less sense to me from a design perspective (lets say=
 I wanted to define a new YANG model that includes the ACL with some other =
system-relavant meta-data that has nothing to do with ACLs but is needed by=
 the system in order to install an ACL).

Making access-li=
sts into a grouping and then using it in a container does not alter the ACL=
 model as it currently stands but allows designers to use the ACL model wit=
h either augmentation or inclusion in other YANG models. Hence it improves =
the usability of the ACL model without altering the semantics of the curren=
t model. It is just a re-structuring but it helps the implementer. 

=


Loosely coupled tables should use leafref.
The main concern of t=
he NETMOD WG should be the usability of the primary solution.
=C2=
=A0

=C2=
=A0

Not sure I understand the sugge=
stion of using a leafref (please excuse my ignorance -- I am not a YANG exp=
ert by any stretch). If I used leafref, what leaf would I be referring to i=
f I wanted to point to the access control list from another YANG model?
=

Also I note from the description of Ac=
cess Control Lists the following that would indicate that it is a primary s=
olution that one may like to re-use in another model.
 description
      "This is a top level container for Access Control Lists.
       It can have one or more Access Control Lists.";


If the requested change were made, would it =
result in excessive churn ?

Thanks =


Regards,

Ranga.


<=
div class=3D"gmail_extra">
          -- 

          
M.
            Ranganathan

          

        
<=
div>

      

      

      

      

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


    

    

  





-- 
M. Ranganathan



--001a113d21d40f1f29055d027474--


From nobody Thu Nov  2 09:37:35 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D506C13F4F4 for ; Thu,  2 Nov 2017 09:37:33 -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 x31klb0xcIhU for ; Thu,  2 Nov 2017 09:37:31 -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 6A87413B262 for ; Thu,  2 Nov 2017 09:37:31 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id e143so123226lfg.12 for ; Thu, 02 Nov 2017 09:37:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7vEjUllkOGmvVcsvOQYpklPL0IbvvszJXpVinfAAE+s=; b=ZTzRDubaMtdxJ6bMk4uk0QAAXt5Owj/WNqn4ZUXsf9AojSpYaP2Jp/tNFnFUSvqYZB 0C/CZP4YF5YdcxlsdgIQFYDle00ujQP4wSbWuTswGMdFwzLmvhu76V7V//rAt8lkZpGx kiEfthGiMYtdx3o5kefq+jJx/PHdVkF94NbG8BC85h81ZwP8XN3ks+8eEZv3sNA8TlZY Uy2w6XiBuvX6MZgnYlHXTWTiqdGlbd7b4qyC/DSjoInHPcehRFbLCEdDD5N5v6pTeG4b ociQpkBYlhqRvgAADWZENVl7TA1kYJun8heTYyk5QUDwPbJppkxySogF2Rbxe1ExWsbU aofg==
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=7vEjUllkOGmvVcsvOQYpklPL0IbvvszJXpVinfAAE+s=; b=nW8fesK1Jq9VzBSg4G/xJPsKL8LmQ4/mB/+XhWEeXZ2Yo2tAvhVwfaZ+kfoG19kYJy SNabpJf+iPYL6Ey38xSnrxpfpn7xTXW4drKuZzMA7sd9ZHucNIUe6w384SuYKjHxXnze X7bonLzWh6ADND49oN3lupP31DdWPR9Arf4b4kHjrOJ09h46gWdddvJ7qbOXWYm+wsUB DOA2Gq9hP3oXJNp8TJu6h4aigKeUm+Z0772OHPDsw9flH15/yNBluevb1XShqk2rxiJY F+CHl62IYOcMf3fnFT4dscR5R/+XPlgHFYdxiOHzVLU37/o52yeHSKd2cp9QacpPZzkd 4C8w==
X-Gm-Message-State: AMCzsaWnW0EghbXRK+fYnVykjiMJWB8V7tSsCgJeKyTlcC1HoMxHQ54v LhYy/aahp2fCGgQU2vjXzRl6E9j2JGYxrOEXDFCCMA==
X-Google-Smtp-Source: ABhQp+SbUvco1Tpsq+nivdYZRkpCRYl63BJUN82SCGuqERhi02EYDLAmG1vcJ7kOTECXwuPAGZuLi44OkY/jHvfDjvs=
X-Received: by 10.25.23.165 with SMTP id 37mr1502563lfx.202.1509640649491; Thu, 02 Nov 2017 09:37:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 2 Nov 2017 09:37:28 -0700 (PDT)
In-Reply-To: 
References:  <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com>     
From: Andy Bierman 
Date: Thu, 2 Nov 2017 09:37:28 -0700
Message-ID: 
To: "M. Ranganathan" 
Cc: Robert Wilton , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11401a04a6d7d0055d029a02"
Archived-At: 
Subject: Re: [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: Thu, 02 Nov 2017 16:37:34 -0000

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

On Thu, Nov 2, 2017 at 9:26 AM, M. Ranganathan  wrote:

> Hi Andy
>
> On Thu, Nov 2, 2017 at 11:55 AM, Andy Bierman  wrote:
>
>>
>>
>> On Thu, Nov 2, 2017 at 8:34 AM, M. Ranganathan  wrote:
>>
>>> Hi Rob, Mahesh,
>>>
>>> Thanks for reading.
>>>
>>> On Thu, Nov 2, 2017 at 11:00 AM, Robert Wilton 
>>> wrote:
>>>
>>>> Hi Ranga,
>>>>
>>>> Presumably another choice would to keep ACLs defined in one place (i.e.
>>>> no grouping required), augment with ACL model with your extra MUD + other
>>>> mgmt data, and then have a reference to that ACL from your model.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>
>>>  In the case of MUD ( which is just a use case driving this need ),
>>> there are local references from MUD to the ACL. MUD itself augments the ACL
>>> model.
>>>
>>> Augmentation would make (logical and design) sense if you were adding
>>> nodes that are in some way related to the ACL itself.
>>>
>>> If I wanted to Augment ACL with something that is not directly ACL
>>> relevant then Augmentation makes less sense to me from a design perspective
>>> (lets say I wanted to define a new YANG model that includes the ACL with
>>> some other system-relavant meta-data that has nothing to do with ACLs but
>>> is needed by the system in order to install an ACL).
>>>
>>> Making access-lists into a grouping and then using it in a container
>>> does not alter the ACL model as it currently stands but allows designers to
>>> use the ACL model with either augmentation or inclusion in other YANG
>>> models. Hence it improves the usability of the ACL model without altering
>>> the semantics of the current model. It is just a re-structuring but it
>>> helps the implementer.
>>>
>>>
>> Loosely coupled tables should use leafref.
>> The main concern of the NETMOD WG should be the usability of the primary
>> solution.
>>
>>
>>
>
> Not sure I understand the suggestion of using a leafref (please excuse my
> ignorance -- I am not a YANG expert by any stretch). If I used leafref,
> what leaf would I be referring to if I wanted to point to the access
> control list from another YANG model?
>


Augment is not the only way to couple data models.
You can have another list just define a foreign key (called a leafref in
YANG
since it does not have to reference a key)




>
> Also I note from the description of Access Control Lists the following
> that would indicate that it is a primary solution that one may like to
> re-use in another model.
>
>  description
>       "This is a top level container for Access Control Lists.
>        It can have one or more Access Control Lists.";
>
>
>
> If the requested change were made, would it result in excessive churn ?
>
>
I never understood why the WG wanted to change the ACL model
to its current form with containers.  Seems complicated to me.



> Thanks
>
> Regards,
>
> Ranga.
>
>
Andy


>
> --
> M. Ranganathan
>
>>
>>
>> _______________________________________________
>> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>>>
>>>
>>> --
>>> M. Ranganathan
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>
>
>
> --
> M. Ranganathan
>

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




On Thu, Nov 2, 2017 at 9:26 AM, M. Ranganathan <mranga@gmail.com>=
; wrote:
Hi Andy<=
br>

On Thu, Nov 2,=
 2017 at 11:55 AM, Andy Bierman <andy@yumaworks.com> wrote:=


=


On Thu, Nov 2, 2017 at 8:34 AM, M. Ranganathan =
<mranga@gmail.com> wrote:
Hi Rob, Mahesh,

Thanks=
 for reading.

On Thu, Nov 2, 2017 at 11:00 AM, Robert Wilton =
<rwilton@cisco.co=
m> wrote:

    
Hi Ranga,

    
Presumably another choice would to keep ACLs defined in one place
      (i.e. no grouping required), augment with ACL model with your
      extra MUD + other mgmt data, and then have a reference to that ACL
      from your model.

    
Thanks,

      Rob

=C2=A0In the case o=
f MUD ( which is just a use case driving this need ), there are local refer=
ences from MUD to the ACL. MUD itself augments the ACL model. 

Augmentation would make (logical and design) sense if you were adding=
 nodes that are in some way related to the ACL itself.

If=
 I wanted to Augment ACL with something that is not directly ACL relevant t=
hen Augmentation makes less sense to me from a design perspective (lets say=
 I wanted to define a new YANG model that includes the ACL with some other =
system-relavant meta-data that has nothing to do with ACLs but is needed by=
 the system in order to install an ACL).

Making access-li=
sts into a grouping and then using it in a container does not alter the ACL=
 model as it currently stands but allows designers to use the ACL model wit=
h either augmentation or inclusion in other YANG models. Hence it improves =
the usability of the ACL model without altering the semantics of the curren=
t model. It is just a re-structuring but it helps the implementer. 

=


Loosely coupled tables should use leafref.
The main concern of t=
he NETMOD WG should be the usability of the primary solution.
=C2=
=A0

=C2=
=A0

Not sure I understand the sugge=
stion of using a leafref (please excuse my ignorance -- I am not a YANG exp=
ert by any stretch). If I used leafref, what leaf would I be referring to i=
f I wanted to point to the access control list from another YANG model?
=



Aug=
ment is not the only way to couple data models.
You can have anot=
her list just define a foreign key (called a leafref in YANG
sinc=
e it does not have to reference a key)


<=
div>=C2=A0

=

Also I note from the description of Access=
 Control Lists the following that would indicate that it is a primary solut=
ion that one may like to re-use in another model.
 description
      "This is a top level container for Access Control Lists.
       It can have one or more Access Control Lists.";


If the requested change were made, would it =
result in excessive churn ?


I never understood why the WG wanted to change the ACL mod=
el
to its current form with containers.=C2=A0 Seems complicated t=
o me.

=C2=A0
<=
div dir=3D"ltr">
Thanks 

Regards,

Ranga.


Andy
=C2=A0

<=
span class=3D"m_-2106291025590631329gmail-m_-723456738062909504HOEnZb">
          -- 

          
M.
            Ranganathan

          

        
<=
div>

      

      

      

      

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


    

    

  






-- 
M. Ranganathan


=


_______________________________________________

netmod mailing list

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


<=
font color=3D"#888888">




-- 
M. Ranganathan






--001a11401a04a6d7d0055d029a02--


From nobody Thu Nov  2 09:41: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 3153513F706 for ; Thu,  2 Nov 2017 09:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKuFH9XBvvtn for ; Thu,  2 Nov 2017 09:41:52 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99513F736 for ; Thu,  2 Nov 2017 09:41:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 8E35A261846; Thu,  2 Nov 2017 17:41:53 +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 ELUSx69oS3Gy; Thu,  2 Nov 2017 17:41:51 +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 61DD3261838; Thu,  2 Nov 2017 17:41:51 +0100 (CET)
Date: Thu, 2 Nov 2017 17:41:49 +0100
From: Kristian Larsson 
To: Robert Wilton 
Cc: Martin Bjorklund , mjethanandani@gmail.com, netmod@ietf.org
Message-ID: <20171102164149.GD12688@spritelink.se>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
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: Thu, 02 Nov 2017 16:41:55 -0000

On Thu, Nov 02, 2017 at 12:53:29PM +0000, Robert Wilton wrote:
> One further refinement might also be to make the ACL type features a bit more
> hierarchical as well, but I don't know if that makes it too complex?

I was pondering this for a bit but I'm not sure it actually
helps.

> For example, the model could define separate features for what type of ACE
> matching is supported by the device, separately from what types of ACE
> combinations are allowed.
> 
> E.g.
> 
> // New 'match type' features.
> 
> feature match-on-l2-eth-hdr {
>    // Device can match on L2 Ethernet header fields.
> }
> feature match-on-ipv4-hdr {
>    // Device can match on IPv4 header fields.
> }
> feature match-on-ipv6-hdr {
>    // Device can match on IPv6 header fields.
> }
> 
> 
> The existing ACL type features could then depend on these:
> 
> 
>   feature l2-acl {
>     if-feature "match-on-l2-eth-hdr";
>    description "Layer 2 ACL supported";
>   }
> 
>   feature ipv4-acl {
>     if-feature "match-on-ipv4-hdr";
>    description "Layer 3 IPv4 ACL supported";
>   }
> 
>   feature ipv6-acl {
>    if-feature "match-on-ipv6-hdr";
>   description "Layer 3 IPv6 ACL supported";
>   }
> 
>   feature mixed-ipv4-acl {
>     if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
>    description "Layer 2 and Layer 3 IPv4 ACL supported";
>   }
>   ...

Features dependent on features... inception. I didn't even know
this was possible with YANG. Learned something today \o/

Anyway, I don't think you can actually deduce that a device
supports an ACL that maches on ethernet and IPv4 based on that it
supports matching on Ethernet headers and IPv4 headers.

For example, on IOS XR there are "ethernet-service access-list"
which can match on Ethernet headers but they are distinct from
ipv4 access-list and they use different attachment points under
an interface. IPv6 is yet another ACL with its own attachment
point... you cannot mix them in the same ACL. I guess they are
logically evaluated in order, so ethernet first, and if it passes
that then the ipvX ACL is evaluated. I believe the situation is
similar on JUNOS.

Which brings us to how to define attachment points. By using YANG
features a device can declare what ACL types it supports but if
the device has different attachment points then there should
probably be some constraint on what ACL type is attached where.

Are we seeking to have a single style of attachment points? I
think that's difficult in reality. Linux has one style, where a
single global "ACL" is defined. Most routers use per interface
ACL and as seen, they split it up on ethernet vs IP (and v4 vs
v6). I doubt one can be said to be better than the other so
trying to argue that everyone should converge on one way is
pointless. Similarly supporting every different style is also
futile as it's completely against the point of standardisation.

The pragmatic compromies is likely to support a few ways and any
vendor that needs something radically different need to build
their own model, do augment, deviate, refine or whatever. Other
thoughts?

An example (from the top of my head so excuse syntax errors):


grouping interface-attach {
  choice attach-style {
    case mixed {
      if-feature mixed-acl;
      leaf-list mixed {
        description "Any type of ACL that can match on ethernet, ipv4, ipv6 or anything else";
        ordered-by user;
        type leafref {
          path "/access-list/acl/acl-name"; // we can apply any acl-type
        }
      }
    }

    case specific-acl {
      if-feature specific-acl;

      leaf-list ethernet {
        description "ACL for Ethernet";
        ordered-by user;
        type leafref {
          path "/access-list/acl/acl-name";
        }
        must 'derived-from(deref(.)/../acl-type, eth-acl)';
      }

      leaf-list ipv4 {
        description "ACL for IPv4";
        ordered-by user;
        type leafref {
          path "/access-list/acl/acl-name";
        }
        must 'derived-from(deref(.)/../acl-type, ipv4-acl)';
      }

      leaf-list ipv6 {
        description "ACL for IPv6";
        ordered-by user;
        type leafref {
          path "/access-list/acl/acl-name";
        }
        must 'derived-from(deref(.)/../acl-type, ipv6-acl)';
      }
    }
  }
}

// ACLs attached under interface, like most big routers do it
augment "/if:interfaces/if:interface" {
  if-feature interface-acl;
  container acl {
    description
      "ACL attachment point";

    container ingress {
      uses interface-attach;
    }
    container egress {
      uses interface-attach;
    }
  }
}


// ACL globally attached, like on a Linux machine
augment /access-list {
  if-feature global-attach;
  leaf system-acl {
    type leafref {
      path "/access-list/acl/acl-name";
    }
  }
}


Kind regards,
   Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511                                kll@spritelink.net


From nobody Thu Nov  2 10:07: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 081E213F7A2 for ; Thu,  2 Nov 2017 10:07: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 t0ATbi0mdRgG for ; Thu,  2 Nov 2017 10:06: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 1DF3D13F7AE for ; Thu,  2 Nov 2017 10:06:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3530; q=dns/txt; s=iport; t=1509642417; x=1510852017; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/kJZR3iJbHVbXopdyS+cUWh1pbDi4WbiCO3DvH0vOK4=; b=A3Xbdr07LEskCdq+o7bNDtK16fA4LwnQZrGWHkXet3vc90GkYZokio0/ /ufyG/zFOlUS5E0Stt2Yej7L/ZH3EYKcAJnwrrzfGkIQ0FhiBIFBnN3cH 7etObIdMYtwbSgNpo5EnPKT1E6zpg27RNEZVTuGXf9SXY9tZKScABHNYm 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAABrUPtZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhBhuJ4N9ih90kCKWRRCCAQoYC4RJTwKFDxgBAQEBAQEBAQFrKIU?= =?us-ascii?q?eAQEEAQEhDwEFNgsQCxgCAiYCAicwBgEMBgIBAYofEKkZgieLEwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgQ+CH4NagWkpgwGEXgESAQmDK4JiBZFekC+UfIIVhgO?= =?us-ascii?q?DYCSHFo4ph22BOR84QkFpNCEIHRVJgmSEX0E2iw6CNQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,335,1505779200";  d="scan'208";a="17740"
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 Nov 2017 17:06:34 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA2H6YuV009780; Thu, 2 Nov 2017 17:06:34 GMT
To: "netmod@ietf.org" , Martin Bjorklund , Ladislav Lhotka 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net>
From: Robert Wilton 
Message-ID: <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com>
Date: Thu, 2 Nov 2017 17:06:34 +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: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.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-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: Thu, 02 Nov 2017 17:07:03 -0000

Hi,

I have read this document and think that is almost ready for publication.

I have one general comment regarding the YANG module library (at the 
end), and a few nits, but otherwise the draft looks good.

1. Sec 1. Introduction paragraph 2, "internal node".  It wasn't 
absolutely clear to me what an internal node is, so I wonder whether 
this would be more clear as  "internal (i.e. non root) node".

2. Sec 1. Introduction, page 4, paragraph starting "2. 
Implementation-time ...".  This section states that it is a stable as 
YANG library, and hence cannot change due to a server reboot. However, 
YANG library doesn't appear to have that restriction, and hence this 
doesn't seem to align with RFC 7895, introduction paragraph 2.

3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined 
anywhere (RFC 7950 doesn't define this).  Should it be defined here?  
The NMDA datastores draft had a similar issue and we choose to define 
"datastore schema" instead.

4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.  
The text "same management session" might be more clear as "same client 
management protocol session".

5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" => 
"are possible, and as such, needs"

6. Sec 3.2 paragraph 5.  Would it useful to state that even though the 
schema is the same, the data is different and not necessarily related.

7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "

8.  Sec 6 Implementation Notes.  Would this section be better named 
"Implementation Considerations"?

9. Structure of ietf-yang-schema-mount module:
   - Should "uri" under namespace be marked as "mandatory" so that it 
doesn't appear to be optional in the tree diagram.
   - Should the "module" name be included under the namespace.  It seems 
that lots of other "module bindings" are done via the module name rather 
than the namespace?

10. Example A.3.  This contains some features that are enabled. Possibly 
it would be useful in the description to point this out, and state that 
unless the features are listed they wouldn't be enabled.

My last general comment relates generally to the structure of the 
Iietf-yang-schema-mount.  As Lada has pointed out previously, this 
module and YANG library bis could be more closely aligned (e.g. along 
the lines of reusing module-sets for the "schema" list).  It would have 
been nice if this module could augment YANG library (so that you can 
easily get the modules and schema mount information in a single simple 
request), however that would put an undesired dependency delaying 
publishing this draft until YANG library bis is completed.

Thanks,
Rob


On 20/10/2017 22: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 Thu Nov  2 10:38: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 7584B13F6ED for ; Thu,  2 Nov 2017 10:38: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 hp8m-cG6Rmc6 for ; Thu,  2 Nov 2017 10:38:06 -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 DB5F013F474 for ; Thu,  2 Nov 2017 10:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7441; q=dns/txt; s=iport; t=1509644286; x=1510853886; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yldBb0evydy/T25cDSPo1sys4PfoaPwGfr13CFw4qMk=; b=HK0PFnNz37YN50b5e6VkM0oOEhoU8D8966bQ7zcYBxbKkpgRB1Tme0Pm alIAHKpuHD42NyPL9I0kRbxknhE2FtbhjsAku/5G4egayXBbCCxwNhqyX exSLhsaBeIJ+GqICSWMtABOtT/jE5luzlww8V0B6AElP83V3QvEUptVGD I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAABTV/tZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIofdJAilkWCEQqFOwKFDxgBAQEBAQEBAQFrKIUdAQEBAwE?= =?us-ascii?q?jDwEFQRALGAICJgICVwYNCAEBihcIqSmCJ4sTAQEBAQEBAQEBAQEBAQEBAQEhg?= =?us-ascii?q?Q+CH4NaghKDAYgmgmIFkV6QL4tNiS+LeIc6jimHbYE5HziBbDQhCB0VSYJlgls?= =?us-ascii?q?cgWdBjXkBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,335,1505779200";  d="scan'208";a="18273"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 17:38:04 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA2Hc2ND005396; Thu, 2 Nov 2017 17:38:02 GMT
To: Kristian Larsson 
Cc: Martin Bjorklund , mjethanandani@gmail.com, netmod@ietf.org
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com>  <20171102164149.GD12688@spritelink.se>
From: Robert Wilton 
Message-ID: <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com>
Date: Thu, 2 Nov 2017 17:38:02 +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: <20171102164149.GD12688@spritelink.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-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, 02 Nov 2017 17:38:08 -0000

On 02/11/2017 16:41, Kristian Larsson wrote:
> On Thu, Nov 02, 2017 at 12:53:29PM +0000, Robert Wilton wrote:
>> One further refinement might also be to make the ACL type features a bit more
>> hierarchical as well, but I don't know if that makes it too complex?
> I was pondering this for a bit but I'm not sure it actually
> helps.
>
>> For example, the model could define separate features for what type of ACE
>> matching is supported by the device, separately from what types of ACE
>> combinations are allowed.
>>
>> E.g.
>>
>> // New 'match type' features.
>>
>> feature match-on-l2-eth-hdr {
>>     // Device can match on L2 Ethernet header fields.
>> }
>> feature match-on-ipv4-hdr {
>>     // Device can match on IPv4 header fields.
>> }
>> feature match-on-ipv6-hdr {
>>     // Device can match on IPv6 header fields.
>> }
>>
>>
>> The existing ACL type features could then depend on these:
>>
>>
>>    feature l2-acl {
>>      if-feature "match-on-l2-eth-hdr";
>>      description "Layer 2 ACL supported";
>>    }
>>
>>    feature ipv4-acl {
>>      if-feature "match-on-ipv4-hdr";
>>      description "Layer 3 IPv4 ACL supported";
>>    }
>>
>>    feature ipv6-acl {
>>     if-feature "match-on-ipv6-hdr";
>>     description "Layer 3 IPv6 ACL supported";
>>    }
>>
>>    feature mixed-ipv4-acl {
>>      if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
>>      description "Layer 2 and Layer 3 IPv4 ACL supported";
>>    }
>>    ...
> Features dependent on features... inception. I didn't even know
> this was possible with YANG. Learned something today \o/
This just means that a device cannot say that it supports a 
"mixed-ipv4-acl" ACL unless it supports classifying traffic on Ethernet 
and classifying traffic on IPv4.

So the 'match type' feature specify what header fields the hardware is 
capable of match on.  E.g. a basic L2 device might say that is only 
matches on the Ethernet header.

The "ACL types" features specify what combination of header fields can 
be combined into a single ACL.

The real benefit for defining "match type" is that the unsupported 
fields in the ACL can then be cleanly left out of the device schema.  
E.g. a hypothetical new breed of IPv6 only routers that only support 
matching on match-on-ipv6-hdr, and don't want to carry v4 baggage.

>
> Anyway, I don't think you can actually deduce that a device
> supports an ACL that maches on ethernet and IPv4 based on that it
> supports matching on Ethernet headers and IPv4 headers.
The YANG is stating the reverse:
  - You can enable the feature that matches on mixed ACLs, if and only 
if, you support matching on Ethernet header fields and IPv4 header fields.


>
> For example, on IOS XR there are "ethernet-service access-list"
> which can match on Ethernet headers but they are distinct from
> ipv4 access-list and they use different attachment points under
> an interface. IPv6 is yet another ACL with its own attachment
> point... you cannot mix them in the same ACL. I guess they are
> logically evaluated in order, so ethernet first, and if it passes
> that then the ipvX ACL is evaluated. I believe the situation is
> similar on JUNOS.
So for XR, you might just list the following features:

feature match-on-l2-eth-hdr;
feature match-on-ipv4-hdr;
feature match-on-ipv6-hdr;
feature l2-acl;
feature ipv4-acl;
feature ipv6-acl;

I.e. it individually supports L2, v4, and v6 ACLs, but a given ACL cannot have mixed entries.

Probably the vendors would need to augment this module with addition configuration restrictions to which ACLs can be applied together on an interface.  E.g. either an L2 or L3 ACL.  If an L3 ACL it can either be a v4 ACL, a v6 ACL, or one of each.

>
> Which brings us to how to define attachment points. By using YANG
> features a device can declare what ACL types it supports but if
> the device has different attachment points then there should
> probably be some constraint on what ACL type is attached where.
I think that this is probably hard to encode in a generic model.  As per 
above, I suspect that such constraints may be more cleanly implemented 
as vendor specific deviations.

>
> Are we seeking to have a single style of attachment points? I
> think that's difficult in reality. Linux has one style, where a
> single global "ACL" is defined. Most routers use per interface
> ACL and as seen, they split it up on ethernet vs IP (and v4 vs
> v6). I doubt one can be said to be better than the other so
> trying to argue that everyone should converge on one way is
> pointless. Similarly supporting every different style is also
> futile as it's completely against the point of standardisation.
>
> The pragmatic compromies is likely to support a few ways and any
> vendor that needs something radically different need to build
> their own model, do augment, deviate, refine or whatever. Other
> thoughts?
For interface attachments I think that the approach in the draft looks 
OK, and reasonably generic, but will need vendor deviations. This is 
probably OK.

Personally, I would put the ACL interface attachment points as an 
augmentation of if:interfaces/interface rather than having a separate 
top level list, but perhaps that is just want I am used to ...

Thanks,
Rob


>
> An example (from the top of my head so excuse syntax errors):
>
>
> grouping interface-attach {
>    choice attach-style {
>      case mixed {
>        if-feature mixed-acl;
>        leaf-list mixed {
>          description "Any type of ACL that can match on ethernet, ipv4, ipv6 or anything else";
>          ordered-by user;
>          type leafref {
>            path "/access-list/acl/acl-name"; // we can apply any acl-type
>          }
>        }
>      }
>
>      case specific-acl {
>        if-feature specific-acl;
>
>        leaf-list ethernet {
>          description "ACL for Ethernet";
>          ordered-by user;
>          type leafref {
>            path "/access-list/acl/acl-name";
>          }
>          must 'derived-from(deref(.)/../acl-type, eth-acl)';
>        }
>
>        leaf-list ipv4 {
>          description "ACL for IPv4";
>          ordered-by user;
>          type leafref {
>            path "/access-list/acl/acl-name";
>          }
>          must 'derived-from(deref(.)/../acl-type, ipv4-acl)';
>        }
>
>        leaf-list ipv6 {
>          description "ACL for IPv6";
>          ordered-by user;
>          type leafref {
>            path "/access-list/acl/acl-name";
>          }
>          must 'derived-from(deref(.)/../acl-type, ipv6-acl)';
>        }
>      }
>    }
> }
>
> // ACLs attached under interface, like most big routers do it
> augment "/if:interfaces/if:interface" {
>    if-feature interface-acl;
>    container acl {
>      description
>        "ACL attachment point";
>
>      container ingress {
>        uses interface-attach;
>      }
>      container egress {
>        uses interface-attach;
>      }
>    }
> }
I think that the existing model is g
>
>
> // ACL globally attached, like on a Linux machine
> augment /access-list {
>    if-feature global-attach;
>    leaf system-acl {
>      type leafref {
>        path "/access-list/acl/acl-name";
>      }
>    }
> }
>
>
> Kind regards,
>     Kristian.
>


From nobody Thu Nov  2 11:51: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 139C813F898 for ; Thu,  2 Nov 2017 11:51:04 -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 btwchZleE67x for ; Thu,  2 Nov 2017 11:51:01 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0104.outbound.protection.outlook.com [104.47.2.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 D579B13F885 for ; Thu,  2 Nov 2017 11:51:00 -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=5WXg9aEwiicaan3DfnydH+hVbQiFDudRKoQ7cufjLTc=; b=VhN1O+o4F7z8QQ0ardZwnnNDwG9y9UPX1WnTtEFblUgpQUOuFb8kHz57E57l3nqMjKdegprQqRliKP7KMLx5CAPA1kV2B/iQuKiVB2oO505qHlSQhMDpWlfi8InQaE/9KrfZsa4AC+JaKf27qfbH3URJiRcAojnP/PtNQQWLCpw=
Received: from AM3PR07MB1124.eurprd07.prod.outlook.com (10.163.187.158) by AM3PR07MB1123.eurprd07.prod.outlook.com (10.163.187.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Thu, 2 Nov 2017 18:50:58 +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.0218.004; Thu, 2 Nov 2017 18:50:58 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: revised-datastores and commonality of schemas
Thread-Index: AdNUCoHtyAS1CimASZeXYMa36mq5Dg==
Date: Thu, 2 Nov 2017 18:50:58 +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; AM3PR07MB1123; 6:rct/tEu6oK3lUXlbwAM6q4j1Wg/NziCF/ZCSgEIY5PBqxpJ0fuuLk4GoaRMfzdqJn/6KC57mHDRecntN4ipkpHpNShOyFrFRTM/7UcSq/WGefb7DJFtRl3VYcPtD9iCRT1wsPWkbClAhAbN7ubchfkSoyCiB8Yroe/s8bjg55DwwdQ1WtpVdkjIWyZcDOejvNc4GKEMQl7xUWZ1Ogd1ifK0sUdY6Y5Q3IIwfBCA9A3RI7GnzdSyUBuTrn05TspqVWbY8dKyShmTuTHhMbEh+SWZ5PyuBtwBuDNCgwr+HKeEfGoxIoXw1jFwxEcy7S5PHPXuxVs+tMWWVd2UubTsM1WiG0tFp8NDcomGfyZonv64=; 5:zjVdSIB/YfP1imdPeRcOgN6x2YacjGjwFPGDU3v9y4xB7hBYNR9AxytSTnpAZyuWgRH4YB4ZgLFL70iFX/0RfbOk6F6Dy8xYWpq+qsCJUsjjgU+cPh7gJGfoWLxCZJBIPYWrqS4wjI617aJJdhxr1oqygbdVzb3nnI5ZFZBcXpE=; 24:fOZp5I7tX0x37Uh/85vl6LradcGbQ53pdmqpyA+6gGRhPp7Sd1t+5zhRroelcTheNPZxJDAhrPJjvEbQqLlgMaOikJPihJ+f1oa/l4H17V0=; 7:R5LOahNtaM0jk4QRUNMQPq9S0wSv8W8H54vB0RV1zHKrFxCSqNrDHOylyFFd2KWtJBY4loYvHSlujscWD7mEdX6a62UpHvxSYTtQ/v5UBDP+4yi1C2nqZi9ayXTUCk3GLjIZRoOtmJNiUbBnT8gvQ/iHSI6i+wjGu+zfcVWlsFXWDKu+A1pZRLkdcEDi5kQBxe81hoIj0IqiWviXRP93nr6mVKMgXIMKkmCFsoIZ0RJlBT7DP4xu6LpK6ymBIRtb
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b2987c29-03c6-4fc3-efba-08d52222a7e6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603238); SRVR:AM3PR07MB1123; 
x-ms-traffictypediagnostic: AM3PR07MB1123:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820);
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)(100000703101)(100105400095)(3002001)(93006095)(93001095)(3231020)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1123; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1123; 
x-forefront-prvs: 047999FF16
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(24454002)(13464003)(199003)(189002)(377424004)(5250100002)(478600001)(2501003)(86362001)(4001150100001)(33656002)(9686003)(81156014)(55016002)(8936002)(316002)(81166006)(8676002)(6306002)(97736004)(3660700001)(966005)(3280700002)(2906002)(66066001)(99286004)(6116002)(3846002)(25786009)(102836003)(68736007)(189998001)(6436002)(101416001)(106356001)(14454004)(53936002)(74316002)(305945005)(7736002)(53546010)(2900100001)(105586002)(110136005)(50986999)(7696004)(54356999)(6506006)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1123; 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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b2987c29-03c6-4fc3-efba-08d52222a7e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 18:50:58.3486 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1123
Archived-At: 
Subject: [netmod] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 18:51:04 -0000

SGkgZ3V5cywNCg0KVGVtcGxhdGVzIGFyZSBzb21ldGhpbmcgdGhhdCBtYXkgYmUgcHJvYmxlbWF0
aWMgZm9yIHRoaXMgY29uY2VwdCBvZiBjb21tb24gc2NoZW1hcyBhY3Jvc3MgdGhlIHJ1bm5pbmcv
Y2FuZGlkYXRlL2ludGVuZGVkIERTZXMgYW5kIHRoZW4gb3BlcmF0aW9uYWwgYmVpbmcgYSBzdXBl
cnNldC4NCg0KVGhlIDxydW5uaW5nPiBEUyBuZWVkcyB0byBoYXZlIGJvdGggdGhlIHRlbXBsYXRl
IGl0c2VsZiBpbiB0aGUgc2NoZW1hIGFzIHdlbGwgYXMgd2hhdGV2ZXIgbm9kZXMgYXJlIHVzZWQg
dG8gaG9sZCAnZXhwbG9kZWQnIGRhdGEuICBCdXQgd2hhdCBhYm91dCBpbnRlbmRlZCBhbmQgb3Bl
cmF0aW9uYWwgPw0KDQpGb3IgZXhhbXBsZSwgaW1hZ2luZSB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcg
aW5zdGFuY2UgZGF0YSBpbiBhIGNhbmRpZGF0ZSAmIHJ1bm5pbmcgRFM6DQoxKSBhIHRlbXBsYXRl
IHRoYXQgc2V0cyBhbiBhZG1pbi1zdGF0ZSBsZWFmIHRvICdlbmFibGVkJyBpbiBhbGwgaW50ZXJm
YWNlcw0KMikgYSBzZXQgb2YgMyBpbnRlcmZhY2VzIHdpdGggYSBmZXcgbGVhZnMgb2YgY29uZmln
IGluIHRoZW0gKGFkZHJlc3MsIGV0YykNCg0KQ2xlYXJseSB0aGUgc2NoZW1hIGZvciB0aGUgY2Fu
ZGlkYXRlL3J1bm5pbmcgRFNlcyBjb250YWluIGJvdGggdGhlIHRlbXBsYXRlIGFuZCB0aGUgaW50
ZXJmYWNlIHNjaGVtYSBub2Rlcy4NCg0KQnV0IGRvZXMgdGhlIHNjaGVtYSBmb3IgdGhlIGludGVu
ZGVkIERTIGFjdHVhbGx5IGhhdmUgdGhlIHRlbXBsYXRlIHNjaGVtYSBub2RlcyA/ICAgSW4gdGhl
b3J5IGl0IGRvZXNuJ3QgKm5lZWQqIHRvIChzaW5jZSB0ZW1wbGF0ZXMgYXJlIGV4cGxvZGVkIGJl
dHdlZW4gcnVubmluZyAmIGludGVuZGVkKSwgYW5kIGl0IGZlZWxzIHN0cmFuZ2UgdG8gaGF2ZSB0
aG9zZSBpbiB0aGVyZSwgYnV0IEkgc3VwcG9zZSBpdCBjb3VsZCBoYXZlIHRoZW0uICBJZiB0aGV5
IGFyZSB0aGVyZSwgdGhlbiBhIHJlYWQgb2YgdGhlIGludGVuZGVkIHdvdWxkIHNob3cgImFkbWlu
LXN0YXRlIGVuYWJsZWQiIGluIHRoZSB0ZW1wbGF0ZSAqYW5kKiBpbiB0aGUgMyBpbnRlcmZhY2Vz
Lg0KDQpEb2VzIHRoZSBvcGVyYXRpb25hbCBEUyBjb250YWluIHRoZSB0ZW1wbGF0ZSBzY2hlbWEg
bm9kZXMgPyAgSWYgeWVzLCB0aGVuIEkgc3VwcG9zZSB3ZSB3b3VsZCBjb25zaWRlciBhbGwgdGVt
cGxhdGVzIGFzICdhcHBsaWVkJyBpbXBsaWNpdGx5ID8NCg0KUmdkcywNCkphc29uDQoNCg0KPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydA0KPiBXaWx0b24NCj4gU2VudDog
VHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyAxMDowMQ0KPiBUbzogbmV0bW9kQGlldGYub3JnDQo+
IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW5ldG1vZC1yZXZp
c2VkLWRhdGFzdG9yZXMtDQo+IDA2LnR4dA0KPiANCj4gU28gdGhpcyB2ZXJzaW9uIG9mIHRoZSBk
cmFmdCBjb250YWlucyB0aGUgc21hbGwgY2hhbmdlIHRoYXQgZGVmaW5lcyAiZGF0YXN0b3JlDQo+
IHNjaGVtYSIgYW5kIGRlc2NyaWJlcyB0aGUgImRhdGFzdG9yZSBzY2hlbWEiIG9mIDxvcGVyYXRp
b25hbD4gYXMgYmVpbmcgdGhlDQo+IHN1cGVyc2V0IG9mIHRoZSBkYXRhc3RvcmUgc2NoZW1hIGZv
ciBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jlcy4NCj4gDQo+IFRoZXJlIGFyZSB0d28g
cmVtYWluaW5nIGlzc3VlcyBvcGVuIG9uIHRoZSBpc3N1ZSB0cmFja2VyDQo+IChodHRwczovL2dp
dGh1Yi5jb20vbmV0bW9kLXdnL2RhdGFzdG9yZS1kdC9pc3N1ZXMpOg0KPiANCj4gKDEpIFNpZ24g
b2ZmIHRoYXQgdXNhZ2Ugb2YgUkZDIDIxMTkgbGFuZ3VhZ2UgaXMgYXBwcm9wcmlhdGUuIFBlcmhh
cHMgb25lIG9mDQo+IHRoZSBwcm9wb25lbnRzIG9mIHRoaXMgY2hhbmdlIGNvdWxkIHBsZWFzZSB2
ZXJpZnkgdGhpcy4NCj4gKDIpIFRoZSBlbWFpbCB0aHJlYWQgcmVnYXJkaW5nIEFjdGlvbnMgYW5k
IFJQQ3MgaW4gTk1EQS7CoCBJIHdpbGwgc2VuZA0KPiB1cGRhdGVkIHByb3Bvc2VkIHRleHQgb24g
dGhlIGFwcHJvcHJpYXRlIHRocmVhZC4NCj4gDQo+IFRoYW5rcywNCj4gUm9iDQo+IA0KPiANCj4g
T24gMzAvMTAvMjAxNyAxODowNCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiA+
IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy
bmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt
IG9mIHRoZSBOZXR3b3JrIE1vZGVsaW5nIFdHIG9mIHRoZSBJRVRGLg0KPiA+DQo+ID4gICAgICAg
ICAgVGl0bGUgICAgICAgICAgIDogTmV0d29yayBNYW5hZ2VtZW50IERhdGFzdG9yZSBBcmNoaXRl
Y3R1cmUNCj4gPiAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBNYXJ0aW4gQmpvcmtsdW5kDQo+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+ID4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgUGhpbCBTaGFmZXINCj4gPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBLZW50IFdhdHNlbg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
IFJvYmVydCBXaWx0b24NCj4gPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRtb2Qt
cmV2aXNlZC1kYXRhc3RvcmVzLTA2LnR4dA0KPiA+IAlQYWdlcyAgICAgICAgICAgOiAzOA0KPiA+
IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTEwLTMwDQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAg
ICAgRGF0YXN0b3JlcyBhcmUgYSBmdW5kYW1lbnRhbCBjb25jZXB0IGJpbmRpbmcgdGhlIGRhdGEg
bW9kZWxzIHdyaXR0ZW4NCj4gPiAgICAgaW4gdGhlIFlBTkcgZGF0YSBtb2RlbGluZyBsYW5ndWFn
ZSB0byBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzDQo+ID4gICAgIHN1Y2ggYXMgTkVUQ09O
RiBhbmQgUkVTVENPTkYuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gYXJjaGl0ZWN0dXJhbA0K
PiA+ICAgICBmcmFtZXdvcmsgZm9yIGRhdGFzdG9yZXMgYmFzZWQgb24gdGhlIGV4cGVyaWVuY2Ug
Z2FpbmVkIHdpdGggdGhlDQo+ID4gICAgIGluaXRpYWwgc2ltcGxlciBtb2RlbCwgYWRkcmVzc2lu
ZyByZXF1aXJlbWVudHMgdGhhdCB3ZXJlIG5vdCB3ZWxsDQo+ID4gICAgIHN1cHBvcnRlZCBpbiB0
aGUgaW5pdGlhbCBtb2RlbC4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh
dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm
Lm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLw0KPiA+DQo+ID4g
VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9y
ZXMtMDYNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll
dGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0DQo+ID4gb3Jlcy0wNg0KPiA+DQo+ID4gQSBkaWZmIGZy
b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+IGh0dHBzOi8vd3d3
LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9y
ZXMNCj4gPiAtMDYNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh
IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGls
IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0
Zi5vcmcuDQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu
b255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N
Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gLg0KPiA+DQo+IA0K
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRt
b2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Thu Nov  2 13:31: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 2662813F692 for ; Thu,  2 Nov 2017 13:31:19 -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 zK-DbXJeLmjs for ; Thu,  2 Nov 2017 13:31:15 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0109.outbound.protection.outlook.com [104.47.42.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 5027113F93F for ; Thu,  2 Nov 2017 13:31:13 -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=hQjg6jdrUBnVGFLYZBp+vNJhfYePFr3eSpFiG62HOok=; b=jNcX/pMm2WhQPZfuhr2sieRiEV3d82TPv03//m4hfJS3Ui3f1i2rYQ7ej4YqDjinugEQ7twQtIvDvACh+XnnrIBTM/jC8WcMtTbgiNs9Wxr3fGOxIZx0HCZnZ8+WI6u+GVhRYMVlIx5DyVpeFaXdcWByL8vuCWgRUN4ogHp1rW0=
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; Thu, 2 Nov 2017 20:31:11 +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.013; Thu, 2 Nov 2017 20:31:11 +0000
From: Kent Watsen 
To: "Sterne, Jason (Nokia - CA/Ottawa)" , "Robert Wilton" , "netmod@ietf.org" 
Thread-Topic: [netmod] revised-datastores and commonality of schemas
Thread-Index: AQHTVBmF43E0D8ha602Z4L7V9HBU3A==
Date: Thu, 2 Nov 2017 20:31:11 +0000
Message-ID: <076270A6-B2C1-44BC-8F02-F4E96675E76F@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.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:pq0/BB/2gFQcLwwRVVel/Q5YZyMiPJvUeaDsKY9E7a4Qw4eF+OW+PgJoiSsgC3u+i7yc2h8DgrdJI9ZVx2enH15dKXQi+S63k81ZHuUjOAKixiQPwABw6Xag+yy0r8VteUwgLkb7ZeCUkVpp68HeQiJJ7joBIE2lt72VSW6EB4D9HsubusWqTh3Zl+6GvrrMvM+J48Hfb7saWLGXIxMxQOkhYVC8y346NRL9YwxCCzfsQCU3ysJbqMKhAlftrOf2N5X+xzWbYa3zhxmWvy9LBbjW38zDDqCmsAyNxs/dMSCnijZlmueifBxPtUXPK60fXPcTfzXI111w60eBEUzaLXnlPpphgpkINlIYhr8oKZA=; 5:g7/r7eQdRb5nYi8CfcpcSYUVmpkVwk3Qa5qla5AF6AP3ZcptGa6p2Y6idTDkWXvreFALpEV3hCIB6qHvOKW/8FjbyrxeeOJhH7qZT0X7BDAHqVRPKlJDDDRD1YScKqHJ9UZFCfn2xbOcav33xddGZDilovvFYvSopEt2bylTlLw=; 24:l0Z5vbO2TZ2KYv3ZmsRwgAt8+uV6Z9MfFDMDBXPJrL+HEPcD/tTwtLtY6jxAA1O9lmMvIbYG9GqDtEKVehZmMexwSAkGOGrhK8tQeJnImAo=; 7:b6nNKbh0s2dY3Z6ZTMZ/fA1n7B/C3pfzzD+/ZGtZCsu24TEVpAfKdKtAfQBZyUYvGyovb1DhaR0Refbw4RQBbl/Ec+td7sKLZ8nqA7O30LRENeCJGjYBnguwmvudRLTdrcy7/cwJoQmcMP7dEEnllQOj0CqxeT45qmqP1LKftUf2XytJPbzOFCYK2tyJdObn/oV4FODeMGhOn36/oNFODtX53Nzol4udbrOzw7ztBQEax2bB9Ucuj2MOcOmj6sA6
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 0571089f-fcb1-4294-90c4-08d52230a804
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(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)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(3231020)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(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: 047999FF16
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(199003)(377424004)(13464003)(189002)(24454002)(316002)(68736007)(7736002)(58126008)(25786009)(81156014)(81166006)(82746002)(8656006)(966005)(110136005)(305945005)(101416001)(3660700001)(53546010)(33656002)(4001150100001)(3846002)(6116002)(8936002)(99286004)(97736004)(102836003)(83506002)(5660300001)(8676002)(83716003)(229853002)(575784001)(86362001)(6436002)(6506006)(53936002)(2501003)(6246003)(106356001)(6486002)(6512007)(77096006)(105586002)(6306002)(66066001)(14454004)(478600001)(2900100001)(54356999)(50986999)(36756003)(189998001)(2906002)(3280700002); 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: <3D16EF3910135F44A9EB99A7DDB2983A@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 0571089f-fcb1-4294-90c4-08d52230a804
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 20:31:11.4345 (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] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 20:31:19 -0000

SGkgSmFzb24sDQoNCkFsbCB0aG9zZSBkZXRhaWxzIHdvdWxkIG5lZWQgdG8gYmUgc3BlY2lmaWVk
IGJ5IHNvbWUgZnV0dXJlIHRlbXBsYXRpbmcgZHJhZnRzLiAgSW4gdGhpcyBkcmFmdCwgdGhlcmUg
aXMgb25seSB0aGUgcHJvdmlzaW9uIGZvciAiY29uZmlndXJhdGlvbiB0cmFuc2Zvcm1hdGlvbnMi
IHRvIGtlZXAgdGhhdCBkb29yIG9wZW4uDQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQotLQ0K
DQpIaSBndXlzLA0KDQoNCg0KVGVtcGxhdGVzIGFyZSBzb21ldGhpbmcgdGhhdCBtYXkgYmUgcHJv
YmxlbWF0aWMgZm9yIHRoaXMgY29uY2VwdCBvZiBjb21tb24gc2NoZW1hcyBhY3Jvc3MgdGhlIHJ1
bm5pbmcvY2FuZGlkYXRlL2ludGVuZGVkIERTZXMgYW5kIHRoZW4gb3BlcmF0aW9uYWwgYmVpbmcg
YSBzdXBlcnNldC4NCg0KDQoNClRoZSA8cnVubmluZz4gRFMgbmVlZHMgdG8gaGF2ZSBib3RoIHRo
ZSB0ZW1wbGF0ZSBpdHNlbGYgaW4gdGhlIHNjaGVtYSBhcyB3ZWxsIGFzIHdoYXRldmVyIG5vZGVz
IGFyZSB1c2VkIHRvIGhvbGQgJ2V4cGxvZGVkJyBkYXRhLiAgQnV0IHdoYXQgYWJvdXQgaW50ZW5k
ZWQgYW5kIG9wZXJhdGlvbmFsID8NCg0KDQoNCkZvciBleGFtcGxlLCBpbWFnaW5lIHdlIGhhdmUg
dGhlIGZvbGxvd2luZyBpbnN0YW5jZSBkYXRhIGluIGEgY2FuZGlkYXRlICYgcnVubmluZyBEUzoN
Cg0KMSkgYSB0ZW1wbGF0ZSB0aGF0IHNldHMgYW4gYWRtaW4tc3RhdGUgbGVhZiB0byAnZW5hYmxl
ZCcgaW4gYWxsIGludGVyZmFjZXMNCg0KMikgYSBzZXQgb2YgMyBpbnRlcmZhY2VzIHdpdGggYSBm
ZXcgbGVhZnMgb2YgY29uZmlnIGluIHRoZW0gKGFkZHJlc3MsIGV0YykNCg0KDQoNCkNsZWFybHkg
dGhlIHNjaGVtYSBmb3IgdGhlIGNhbmRpZGF0ZS9ydW5uaW5nIERTZXMgY29udGFpbiBib3RoIHRo
ZSB0ZW1wbGF0ZSBhbmQgdGhlIGludGVyZmFjZSBzY2hlbWEgbm9kZXMuDQoNCg0KDQpCdXQgZG9l
cyB0aGUgc2NoZW1hIGZvciB0aGUgaW50ZW5kZWQgRFMgYWN0dWFsbHkgaGF2ZSB0aGUgdGVtcGxh
dGUgc2NoZW1hIG5vZGVzID8gICBJbiB0aGVvcnkgaXQgZG9lc24ndCAqbmVlZCogdG8gKHNpbmNl
IHRlbXBsYXRlcyBhcmUgZXhwbG9kZWQgYmV0d2VlbiBydW5uaW5nICYgaW50ZW5kZWQpLCBhbmQg
aXQgZmVlbHMgc3RyYW5nZSB0byBoYXZlIHRob3NlIGluIHRoZXJlLCBidXQgSSBzdXBwb3NlIGl0
IGNvdWxkIGhhdmUgdGhlbS4gIElmIHRoZXkgYXJlIHRoZXJlLCB0aGVuIGEgcmVhZCBvZiB0aGUg
aW50ZW5kZWQgd291bGQgc2hvdyAiYWRtaW4tc3RhdGUgZW5hYmxlZCIgaW4gdGhlIHRlbXBsYXRl
ICphbmQqIGluIHRoZSAzIGludGVyZmFjZXMuDQoNCg0KDQpEb2VzIHRoZSBvcGVyYXRpb25hbCBE
UyBjb250YWluIHRoZSB0ZW1wbGF0ZSBzY2hlbWEgbm9kZXMgPyAgSWYgeWVzLCB0aGVuIEkgc3Vw
cG9zZSB3ZSB3b3VsZCBjb25zaWRlciBhbGwgdGVtcGxhdGVzIGFzICdhcHBsaWVkJyBpbXBsaWNp
dGx5ID8NCg0KDQoNClJnZHMsDQoNCkphc29uDQoNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KDQo+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0DQoNCj4gV2lsdG9uDQoNCj4gU2VudDogVHVlc2RheSwg
T2N0b2JlciAzMSwgMjAxNyAxMDowMQ0KDQo+IFRvOiBuZXRtb2RAaWV0Zi5vcmcNCg0KPiBTdWJq
ZWN0OiBSZTogW25ldG1vZF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1k
YXRhc3RvcmVzLQ0KDQo+IDA2LnR4dA0KDQo+IA0KDQo+IFNvIHRoaXMgdmVyc2lvbiBvZiB0aGUg
ZHJhZnQgY29udGFpbnMgdGhlIHNtYWxsIGNoYW5nZSB0aGF0IGRlZmluZXMgImRhdGFzdG9yZQ0K
DQo+IHNjaGVtYSIgYW5kIGRlc2NyaWJlcyB0aGUgImRhdGFzdG9yZSBzY2hlbWEiIG9mIDxvcGVy
YXRpb25hbD4gYXMgYmVpbmcgdGhlDQoNCj4gc3VwZXJzZXQgb2YgdGhlIGRhdGFzdG9yZSBzY2hl
bWEgZm9yIGFsbCB0aGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLg0KDQo+IA0KDQo+IFRoZXJl
IGFyZSB0d28gcmVtYWluaW5nIGlzc3VlcyBvcGVuIG9uIHRoZSBpc3N1ZSB0cmFja2VyDQoNCj4g
KGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0
aHViLmNvbV9uZXRtb2QtMkR3Z19kYXRhc3RvcmUtMkRkdF9pc3N1ZXMmZD1Ed0lHYVEmYz1IQWtZ
dWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlF
UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5z
NUpuRjNCckZhWVhQV1lvc2cmcz1PaDcwVG9CMnZVVHZ0Zk9HbEpGeHE5Yi1WZEp2SXE3Tnc2UzY5
Zk5nY1RBJmU9KToNCg0KPiANCg0KPiAoMSkgU2lnbiBvZmYgdGhhdCB1c2FnZSBvZiBSRkMgMjEx
OSBsYW5ndWFnZSBpcyBhcHByb3ByaWF0ZS4gUGVyaGFwcyBvbmUgb2YNCg0KPiB0aGUgcHJvcG9u
ZW50cyBvZiB0aGlzIGNoYW5nZSBjb3VsZCBwbGVhc2UgdmVyaWZ5IHRoaXMuDQoNCj4gKDIpIFRo
ZSBlbWFpbCB0aHJlYWQgcmVnYXJkaW5nIEFjdGlvbnMgYW5kIFJQQ3MgaW4gTk1EQS4gIEkgd2ls
bCBzZW5kDQoNCj4gdXBkYXRlZCBwcm9wb3NlZCB0ZXh0IG9uIHRoZSBhcHByb3ByaWF0ZSB0aHJl
YWQuDQoNCj4gDQoNCj4gVGhhbmtzLA0KDQo+IFJvYg0KDQo+IA0KDQo+IA0KDQo+IE9uIDMwLzEw
LzIwMTcgMTg6MDQsIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCg0KPiA+IEEgTmV3
IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy
YWZ0cw0KDQo+IGRpcmVjdG9yaWVzLg0KDQo+ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv
ZiB0aGUgTmV0d29yayBNb2RlbGluZyBXRyBvZiB0aGUgSUVURi4NCg0KPiA+DQoNCj4gPiAgICAg
ICAgICBUaXRsZSAgICAgICAgICAgOiBOZXR3b3JrIE1hbmFnZW1lbnQgRGF0YXN0b3JlIEFyY2hp
dGVjdHVyZQ0KDQo+ID4gICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogTWFydGluIEJqb3JrbHVu
ZA0KDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVlcmdlbiBTY2hvZW53YWVsZGVy
DQoNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsIFNoYWZlcg0KDQo+ID4gICAg
ICAgICAgICAgICAgICAgICAgICAgICAgS2VudCBXYXRzZW4NCg0KPiA+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFJvYmVydCBXaWx0b24NCg0KPiA+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFm
dC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDYudHh0DQoNCj4gPiAJUGFnZXMgICAg
ICAgICAgIDogMzgNCg0KPiA+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTEwLTMwDQoNCj4gPg0K
DQo+ID4gQWJzdHJhY3Q6DQoNCj4gPiAgICAgRGF0YXN0b3JlcyBhcmUgYSBmdW5kYW1lbnRhbCBj
b25jZXB0IGJpbmRpbmcgdGhlIGRhdGEgbW9kZWxzIHdyaXR0ZW4NCg0KPiA+ICAgICBpbiB0aGUg
WUFORyBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIHRvIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2Nv
bHMNCg0KPiA+ICAgICBzdWNoIGFzIE5FVENPTkYgYW5kIFJFU1RDT05GLiAgVGhpcyBkb2N1bWVu
dCBkZWZpbmVzIGFuIGFyY2hpdGVjdHVyYWwNCg0KPiA+ICAgICBmcmFtZXdvcmsgZm9yIGRhdGFz
dG9yZXMgYmFzZWQgb24gdGhlIGV4cGVyaWVuY2UgZ2FpbmVkIHdpdGggdGhlDQoNCj4gPiAgICAg
aW5pdGlhbCBzaW1wbGVyIG1vZGVsLCBhZGRyZXNzaW5nIHJlcXVpcmVtZW50cyB0aGF0IHdlcmUg
bm90IHdlbGwNCg0KPiA+ICAgICBzdXBwb3J0ZWQgaW4gdGhlIGluaXRpYWwgbW9kZWwuDQoNCj4g
Pg0KDQo+ID4NCg0KPiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz
IGRyYWZ0IGlzOg0KDQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEbmV0
bW9kLTJEcmV2aXNlZC0yRGRhdGFzdG9yZXNfJmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2Jm
aDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ
YUdUdmpJU2xhSmRjWm8mbT1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZ
b3NnJnM9a250YmdwSEpuckJ5SFluUDYtZ0lRYXdGeXh6dUI0cXFBOGE3c0o3M1lybyZlPQ0KDQo+
ID4NCg0KPiA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoN
Cg0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRuZXRtb2QtMkRyZXZpc2VkLTJE
ZGF0YXN0b3Jlcy0yRDA2JmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5k
YjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRj
Wm8mbT1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZb3NnJnM9bDhXZXJN
TnZmdmdaVkpDbklFcXhQb2ZiZ016X1FfRXpTaUlvR2JDUWdOSSZlPQ0KDQo+ID4gaHR0cHM6Ly91
cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5p
ZXRmLm9yZ19kb2NfaHRtbF9kcmFmdC0yRGlldGYtMkRuZXRtb2QtMkRyZXZpc2VkLTJEZGF0YXN0
JmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZy
PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1IbWxBN2hTQUND
SkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZb3NnJnM9V0N1T28xbmlBa3lzY1FVS3pJWW1U
dUx2YWpGaDBqbjhNdG1SbWM2ampobyZlPQ0KDQo+ID4gb3Jlcy0wNg0KDQo+ID4NCg0KPiA+IEEg
ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KPiA+IGh0
dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll
dGYub3JnX3JmY2RpZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmV2aXNlZC0y
RGRhdGFzdG9yZXMmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3Zv
RFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZt
PUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpuRjNCckZhWVhQV1lvc2cmcz1MN25RSk1pWDNN
X3lYTFN3UEFTWmVmVWRXN1ltQTRseTlNaW9jWFZHaDQwJmU9DQoNCj4gPiAtMDYNCg0KPiA+DQoN
Cj4gPg0KDQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51
dGVzIGZyb20gdGhlIHRpbWUgb2YNCg0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk
IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KPiA+
DQoNCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG
VFAgYXQ6DQoNCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
ZnRwLTNBX19mdHAuaWV0Zi5vcmdfaW50ZXJuZXQtMkRkcmFmdHNfJmQ9RHdJR2FRJmM9SEFrWXVo
NjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBv
T0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVK
bkYzQnJGYVlYUFdZb3NnJnM9ZV9tUWV5WFpieEVUeXZyMC1nY3ZrUGVXcXY0bVNjc0ZhNXVlQXJU
S29RUSZlPQ0KDQo+ID4NCg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQoNCj4gPiBuZXRtb2RAaWV0
Zi5vcmcNCg0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o
dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJR2FRJmM9
SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZa
R0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1IbWxBN2hTQUNDSkJtak5vbWJYc2RT
THhOczVKbkYzQnJGYVlYUFdZb3NnJnM9TDJ4UXlqXzkzOGFWY3Y0UXlGTUhsTndYa1g5dFQ4TDQ2
TTFQWGM2TG5oNCZlPQ0KDQo+ID4gLg0KDQo+ID4NCg0KPiANCg0KPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QN
Cg0KPiBuZXRtb2RAaWV0Zi5vcmcNCg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1v
ZCZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0km
cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09SG1sQTdoU0FD
Q0pCbWpOb21iWHNkU0x4TnM1Sm5GM0JyRmFZWFBXWW9zZyZzPUwyeFF5al85MzhhVmN2NFF5Rk1I
bE53WGtYOXRUOEw0Nk0xUFhjNkxuaDQmZT0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9y
Zw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193
d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lHYVEmYz1IQWtZdWg2M3Jz
dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZ
aHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpuRjNC
ckZhWVhQV1lvc2cmcz1MMnhReWpfOTM4YVZjdjRReUZNSGxOd1hrWDl0VDhMNDZNMVBYYzZMbmg0
JmU9DQoNCg0K


From nobody Thu Nov  2 13:40: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 A57C213AB34 for ; Thu,  2 Nov 2017 13:40:31 -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 SM5MjuL6phrX for ; Thu,  2 Nov 2017 13:40:29 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0132.outbound.protection.outlook.com [104.47.1.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 CEB5C134916 for ; Thu,  2 Nov 2017 13:40:28 -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=/iZCq4NE2em+Gs2HallSqtaY3DhumN7QN0TKkQLZRLM=; b=snKQW8iMhtJcdHbuqrOoQAFLf8kM+D7bWrLOJCAWpaXF7nHxZkMeAJc7zj5FKZDmt0F/F5oMNyGcvMlM/ByQaGuoOUUflsEu9R4XnU80DfZpe8eWQrVUQPSjbFe7vgU5KA+iTlBTxv1+3auypWTVr4Cxa3lO/g4xhIu3VZzqU/s=
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.218.6; Thu, 2 Nov 2017 20:40:25 +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.0218.004; Thu, 2 Nov 2017 20:40:25 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Kent Watsen , Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] revised-datastores and commonality of schemas
Thread-Index: AQHTVBmF43E0D8ha602Z4L7V9HBU3KMBjGKA
Date: Thu, 2 Nov 2017 20:40:25 +0000
Message-ID: 
References: <076270A6-B2C1-44BC-8F02-F4E96675E76F@juniper.net>
In-Reply-To: <076270A6-B2C1-44BC-8F02-F4E96675E76F@juniper.net>
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.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1122; 6:DLi7XHkJoUfoZ2z3W/XloLo9+1D6c7axX4WIWyIbSXcvzlkv4rS7DqKZhVBHm3dGBoilzWtnDCTQALuoLITXFh/6Vi4KZQwdYMXrZYZNuV8PrYlpvFlqM00mlKErByu8P0RjeCYv3N6PKy9NKlLvFryPPYizg6qZytMESPyUOUcQYWforo1vnQW8hqKFOnGD/MXHgdfQSCnKBIvsBxQhQCsKtr4tUl0+XpkM+0bUpqYl0Qlbt769ubmVH6rEe9EjfJMJh4drfgClJwJScwOm2A8Y/Bj+seuaM36qCwD++a0cGEmMt3WGJ+kTGaKAlLELqWCP+3wtg0jVSexF9c3/KgXTYLLJpOTOAtGgjN958Fo=; 5:RkcWkmDdJK8paYsDr2KNJyZxMLGk9d2ik4L2HgrwBAwOxDgd4O03X53NgEsHg1f7kZ/2THESSwItaXHyhNttsPkNsWEaGqj/i0G70hftKCclUbEfG2vVEir41qZd2GMpZDyJjgOQGASoPF5zsTtcMnpQW94Ds8XQQCyR+wFojJE=; 24:8RwV3ckr5Cs3vzQngkEiWwDZsUG2l8fUPWmDW0t80hNZhmt2sAnK54jwGRNQs34WvxbXrsWH2JD/MWVxRHRXNB/4DVXmodh6XuQpcUT0hsE=; 7:9DXg5u8N7kNmLQFQifQN64h6j6zlF5bwtLX4PqDP2K1WAtdWRwHB7HNfT1sBBGDCOm+v3yMqY24AYr/4qMPbion8NurQ+LiPCxwoA1kU/4Uu/eJOdy1H+CQcAcHNq832RA34HsWl1WlvH1xxrEK7WxmOEToUXpDufnt/3YfO8sT/X/YdkPQPBcALXB071kC3i5SqKYEugTXddlPRzwDMUmyxCFU5M8KDxoH4zO2x8rwc+pHslcVDQGtciFdCMeDc
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 2d21fe7f-131d-43e3-c51b-08d52231f269
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM3PR07MB1122; 
x-ms-traffictypediagnostic: AM3PR07MB1122:
x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008)(82608151540597)(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)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3231020)(3002001)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(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: 047999FF16
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(24454002)(377424004)(13464003)(106356001)(6306002)(102836003)(2900100001)(316002)(105586002)(189998001)(110136005)(33656002)(3846002)(74316002)(6116002)(7736002)(305945005)(101416001)(6246003)(81156014)(53936002)(8666007)(81166006)(9686003)(8676002)(55016002)(8936002)(6506006)(53546010)(5660300001)(2950100002)(6436002)(229853002)(7696004)(68736007)(50986999)(86362001)(14454004)(66066001)(5250100002)(478600001)(1941001)(3660700001)(2501003)(25786009)(575784001)(54356999)(966005)(99286004)(4001150100001)(3280700002)(97736004)(2906002)(76176999)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1122; 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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d21fe7f-131d-43e3-c51b-08d52231f269
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 20:40:25.7615 (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] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 20:40:31 -0000

SGkgS2VudCwNClllYWggLSBJIHJlYWxpemUgdGhhdCBJJ20ganVtcGluZyBhaGVhZCBvZiB3aGVy
ZSB3ZSBhcmUuICBJJ20gYSBiaXQgd29ycmllZCB0aGF0IHdlJ3JlIG1ha2luZyBmb3J3YXJkIGxv
b2tpbmcgYXNzdW1wdGlvbnMgdGhhdCB3ZSdsbCBiZSBhYmxlIHRvIHN0aWNrIHRvIHRob3NlIGNv
bnN0cmFpbnRzIHRoYXQgd2UncmUgZGVmaW5pbmcgaW4gcmV2aXNlZC1kYXRhc3RvcmVzLCBhbmQg
d2UgbWF5IGZpbmQgdGhhdCBkaWZmaWN1bHQgbGF0ZXIuDQpGb3IgdGhpcyBzcGVjaWZpYyBpc3N1
ZSBJIHN1cHBvc2UgdGhlcmUgaXMgYXQgbGVhc3QgdGhlIHBvc3NpYmlsaXR5IHRoYXQgd2UgKmNv
dWxkKiBoYXZlIGEgY29tbW9uIHNjaGVtYSAoYW5kIGhhdmUgb3BlcmF0aW9uYWwgYmUgYSBzdXBl
cnNldCkuDQpSZ2RzLA0KSmFzb24NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG
cm9tOiBLZW50IFdhdHNlbiBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXRdDQo+IFNlbnQ6IFRo
dXJzZGF5LCBOb3ZlbWJlciAwMiwgMjAxNyAxNjozMQ0KPiBUbzogU3Rlcm5lLCBKYXNvbiAoTm9r
aWEgLSBDQS9PdHRhd2EpIDxqYXNvbi5zdGVybmVAbm9raWEuY29tPjsgUm9iZXJ0DQo+IFdpbHRv
biA8cndpbHRvbkBjaXNjby5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtu
ZXRtb2RdIHJldmlzZWQtZGF0YXN0b3JlcyBhbmQgY29tbW9uYWxpdHkgb2Ygc2NoZW1hcw0KPiAN
Cj4gSGkgSmFzb24sDQo+IA0KPiBBbGwgdGhvc2UgZGV0YWlscyB3b3VsZCBuZWVkIHRvIGJlIHNw
ZWNpZmllZCBieSBzb21lIGZ1dHVyZSB0ZW1wbGF0aW5nDQo+IGRyYWZ0cy4gIEluIHRoaXMgZHJh
ZnQsIHRoZXJlIGlzIG9ubHkgdGhlIHByb3Zpc2lvbiBmb3IgImNvbmZpZ3VyYXRpb24NCj4gdHJh
bnNmb3JtYXRpb25zIiB0byBrZWVwIHRoYXQgZG9vciBvcGVuLg0KPiANCj4gS2VudCAvLyBjb250
cmlidXRvcg0KPiANCj4gDQo+IC0tDQo+IA0KPiBIaSBndXlzLA0KPiANCj4gDQo+IA0KPiBUZW1w
bGF0ZXMgYXJlIHNvbWV0aGluZyB0aGF0IG1heSBiZSBwcm9ibGVtYXRpYyBmb3IgdGhpcyBjb25j
ZXB0IG9mDQo+IGNvbW1vbiBzY2hlbWFzIGFjcm9zcyB0aGUgcnVubmluZy9jYW5kaWRhdGUvaW50
ZW5kZWQgRFNlcyBhbmQgdGhlbg0KPiBvcGVyYXRpb25hbCBiZWluZyBhIHN1cGVyc2V0Lg0KPiAN
Cj4gDQo+IA0KPiBUaGUgPHJ1bm5pbmc+IERTIG5lZWRzIHRvIGhhdmUgYm90aCB0aGUgdGVtcGxh
dGUgaXRzZWxmIGluIHRoZSBzY2hlbWEgYXMNCj4gd2VsbCBhcyB3aGF0ZXZlciBub2RlcyBhcmUg
dXNlZCB0byBob2xkICdleHBsb2RlZCcgZGF0YS4gIEJ1dCB3aGF0IGFib3V0DQo+IGludGVuZGVk
IGFuZCBvcGVyYXRpb25hbCA/DQo+IA0KPiANCj4gDQo+IEZvciBleGFtcGxlLCBpbWFnaW5lIHdl
IGhhdmUgdGhlIGZvbGxvd2luZyBpbnN0YW5jZSBkYXRhIGluIGEgY2FuZGlkYXRlICYNCj4gcnVu
bmluZyBEUzoNCj4gDQo+IDEpIGEgdGVtcGxhdGUgdGhhdCBzZXRzIGFuIGFkbWluLXN0YXRlIGxl
YWYgdG8gJ2VuYWJsZWQnIGluIGFsbCBpbnRlcmZhY2VzDQo+IA0KPiAyKSBhIHNldCBvZiAzIGlu
dGVyZmFjZXMgd2l0aCBhIGZldyBsZWFmcyBvZiBjb25maWcgaW4gdGhlbSAoYWRkcmVzcywgZXRj
KQ0KPiANCj4gDQo+IA0KPiBDbGVhcmx5IHRoZSBzY2hlbWEgZm9yIHRoZSBjYW5kaWRhdGUvcnVu
bmluZyBEU2VzIGNvbnRhaW4gYm90aCB0aGUNCj4gdGVtcGxhdGUgYW5kIHRoZSBpbnRlcmZhY2Ug
c2NoZW1hIG5vZGVzLg0KPiANCj4gDQo+IA0KPiBCdXQgZG9lcyB0aGUgc2NoZW1hIGZvciB0aGUg
aW50ZW5kZWQgRFMgYWN0dWFsbHkgaGF2ZSB0aGUgdGVtcGxhdGUgc2NoZW1hDQo+IG5vZGVzID8g
ICBJbiB0aGVvcnkgaXQgZG9lc24ndCAqbmVlZCogdG8gKHNpbmNlIHRlbXBsYXRlcyBhcmUgZXhw
bG9kZWQNCj4gYmV0d2VlbiBydW5uaW5nICYgaW50ZW5kZWQpLCBhbmQgaXQgZmVlbHMgc3RyYW5n
ZSB0byBoYXZlIHRob3NlIGluIHRoZXJlLA0KPiBidXQgSSBzdXBwb3NlIGl0IGNvdWxkIGhhdmUg
dGhlbS4gIElmIHRoZXkgYXJlIHRoZXJlLCB0aGVuIGEgcmVhZCBvZiB0aGUNCj4gaW50ZW5kZWQg
d291bGQgc2hvdyAiYWRtaW4tc3RhdGUgZW5hYmxlZCIgaW4gdGhlIHRlbXBsYXRlICphbmQqIGlu
IHRoZSAzDQo+IGludGVyZmFjZXMuDQo+IA0KPiANCj4gDQo+IERvZXMgdGhlIG9wZXJhdGlvbmFs
IERTIGNvbnRhaW4gdGhlIHRlbXBsYXRlIHNjaGVtYSBub2RlcyA/ICBJZiB5ZXMsIHRoZW4gSQ0K
PiBzdXBwb3NlIHdlIHdvdWxkIGNvbnNpZGVyIGFsbCB0ZW1wbGF0ZXMgYXMgJ2FwcGxpZWQnIGlt
cGxpY2l0bHkgPw0KPiANCj4gDQo+IA0KPiBSZ2RzLA0KPiANCj4gSmFzb24NCj4gDQo+IA0KPiAN
Cj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IA0KPiA+IEZyb206IG5l
dG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0
DQo+IA0KPiA+IFdpbHRvbg0KPiANCj4gPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3
IDEwOjAxDQo+IA0KPiA+IFRvOiBuZXRtb2RAaWV0Zi5vcmcNCj4gDQo+ID4gU3ViamVjdDogUmU6
IFtuZXRtb2RdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jl
cy0NCj4gDQo+ID4gMDYudHh0DQo+IA0KPiA+DQo+IA0KPiA+IFNvIHRoaXMgdmVyc2lvbiBvZiB0
aGUgZHJhZnQgY29udGFpbnMgdGhlIHNtYWxsIGNoYW5nZSB0aGF0IGRlZmluZXMNCj4gImRhdGFz
dG9yZQ0KPiANCj4gPiBzY2hlbWEiIGFuZCBkZXNjcmliZXMgdGhlICJkYXRhc3RvcmUgc2NoZW1h
IiBvZiA8b3BlcmF0aW9uYWw+IGFzIGJlaW5nDQo+IHRoZQ0KPiANCj4gPiBzdXBlcnNldCBvZiB0
aGUgZGF0YXN0b3JlIHNjaGVtYSBmb3IgYWxsIHRoZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMu
DQo+IA0KPiA+DQo+IA0KPiA+IFRoZXJlIGFyZSB0d28gcmVtYWluaW5nIGlzc3VlcyBvcGVuIG9u
IHRoZSBpc3N1ZSB0cmFja2VyDQo+IA0KPiA+IChodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu
dC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19naXRodWIuY29tX25ldG1vZC0yRHdnX2RhdGFz
dG9yZS0NCj4gMkRkdF9pc3N1ZXMmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhl
TUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdU
dmpJU2xhSmRjWm8mbQ0KPiA9SG1sQTdoU0FDQ0pCbWpOb21iWHNkU0x4TnM1Sm5GM0JyRmFZWFBX
WW9zZyZzPU9oNzBUb0IydlVUdnRmDQo+IE9HbEpGeHE5Yi1WZEp2SXE3Tnc2UzY5Zk5nY1RBJmU9
KToNCj4gDQo+ID4NCj4gDQo+ID4gKDEpIFNpZ24gb2ZmIHRoYXQgdXNhZ2Ugb2YgUkZDIDIxMTkg
bGFuZ3VhZ2UgaXMgYXBwcm9wcmlhdGUuIFBlcmhhcHMgb25lIG9mDQo+IA0KPiA+IHRoZSBwcm9w
b25lbnRzIG9mIHRoaXMgY2hhbmdlIGNvdWxkIHBsZWFzZSB2ZXJpZnkgdGhpcy4NCj4gDQo+ID4g
KDIpIFRoZSBlbWFpbCB0aHJlYWQgcmVnYXJkaW5nIEFjdGlvbnMgYW5kIFJQQ3MgaW4gTk1EQS4g
IEkgd2lsbCBzZW5kDQo+IA0KPiA+IHVwZGF0ZWQgcHJvcG9zZWQgdGV4dCBvbiB0aGUgYXBwcm9w
cmlhdGUgdGhyZWFkLg0KPiANCj4gPg0KPiANCj4gPiBUaGFua3MsDQo+IA0KPiA+IFJvYg0KPiAN
Cj4gPg0KPiANCj4gPg0KPiANCj4gPiBPbiAzMC8xMC8yMDE3IDE4OjA0LCBpbnRlcm5ldC1kcmFm
dHNAaWV0Zi5vcmcgd3JvdGU6DQo+IA0KPiA+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh
aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IA0KPiA+IGRpcmVjdG9y
aWVzLg0KPiANCj4gPiA+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsg
TW9kZWxpbmcgV0cgb2YgdGhlIElFVEYuDQo+IA0KPiA+ID4NCj4gDQo+ID4gPiAgICAgICAgICBU
aXRsZSAgICAgICAgICAgOiBOZXR3b3JrIE1hbmFnZW1lbnQgRGF0YXN0b3JlIEFyY2hpdGVjdHVy
ZQ0KPiANCj4gPiA+ICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1hcnRpbiBCam9ya2x1bmQN
Cj4gDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdWVyZ2VuIFNjaG9lbndhZWxk
ZXINCj4gDQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsIFNoYWZlcg0KPiAN
Cj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEtlbnQgV2F0c2VuDQo+IA0KPiA+ID4g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9iZXJ0IFdpbHRvbg0KPiANCj4gPiA+IAlGaWxl
bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDYudHh0
DQo+IA0KPiA+ID4gCVBhZ2VzICAgICAgICAgICA6IDM4DQo+IA0KPiA+ID4gCURhdGUgICAgICAg
ICAgICA6IDIwMTctMTAtMzANCj4gDQo+ID4gPg0KPiANCj4gPiA+IEFic3RyYWN0Og0KPiANCj4g
PiA+ICAgICBEYXRhc3RvcmVzIGFyZSBhIGZ1bmRhbWVudGFsIGNvbmNlcHQgYmluZGluZyB0aGUg
ZGF0YSBtb2RlbHMgd3JpdHRlbg0KPiANCj4gPiA+ICAgICBpbiB0aGUgWUFORyBkYXRhIG1vZGVs
aW5nIGxhbmd1YWdlIHRvIG5ldHdvcmsgbWFuYWdlbWVudA0KPiBwcm90b2NvbHMNCj4gDQo+ID4g
PiAgICAgc3VjaCBhcyBORVRDT05GIGFuZCBSRVNUQ09ORi4gIFRoaXMgZG9jdW1lbnQgZGVmaW5l
cyBhbg0KPiBhcmNoaXRlY3R1cmFsDQo+IA0KPiA+ID4gICAgIGZyYW1ld29yayBmb3IgZGF0YXN0
b3JlcyBiYXNlZCBvbiB0aGUgZXhwZXJpZW5jZSBnYWluZWQgd2l0aCB0aGUNCj4gDQo+ID4gPiAg
ICAgaW5pdGlhbCBzaW1wbGVyIG1vZGVsLCBhZGRyZXNzaW5nIHJlcXVpcmVtZW50cyB0aGF0IHdl
cmUgbm90IHdlbGwNCj4gDQo+ID4gPiAgICAgc3VwcG9ydGVkIGluIHRoZSBpbml0aWFsIG1vZGVs
Lg0KPiANCj4gPiA+DQo+IA0KPiA+ID4NCj4gDQo+ID4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBz
dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gDQo+ID4gPiBodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19kYXRhdHJhY2tlci5pZXRm
Lm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmV2aXNlZC0NCj4gMkRkYXRhc3RvcmVz
XyZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6
b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtDQo+ID1I
bWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZb3NnJnM9a250YmdwSEpuckJ5
SFkNCj4gblA2LWdJUWF3Rnl4enVCNHFxQThhN3NKNzNZcm8mZT0NCj4gDQo+ID4gPg0KPiANCj4g
PiA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gDQo+
ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+
IDNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRG5ldG1vZC0yRHJldmlzZWQt
MkRkYXRhc3RvcmVzLQ0KPiAyRDA2JmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJY
ZU1LLQ0KPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFH
VHZqSVNsYUpkY1pvJm0NCj4gPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpuRjNCckZhWVhQ
V1lvc2cmcz1sOFdlck1OdmZ2Z1pWSg0KPiBDbklFcXhQb2ZiZ016X1FfRXpTaUlvR2JDUWdOSSZl
PQ0KPiANCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o
dHRwcy0NCj4gM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19odG1sX2RyYWZ0LTJEaWV0Zi0y
RG5ldG1vZC0yRHJldmlzZWQtDQo+IDJEZGF0YXN0JmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZT
Y2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo
cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm0NCj4gPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpu
RjNCckZhWVhQV1lvc2cmcz1XQ3VPbzFuaUFreXNjDQo+IFFVS3pJWW1UdUx2YWpGaDBqbjhNdG1S
bWM2ampobyZlPQ0KPiANCj4gPiA+IG9yZXMtMDYNCj4gDQo+ID4gPg0KPiANCj4gPiA+IEEgZGlm
ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gDQo+ID4gPiBo
dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193
d3cuaWV0Zi5vcmdfcmZjZGlmZi0zRnVybDItM0RkcmFmdC0yRGlldGYtMkRuZXRtb2QtMkRyZXZp
c2VkLQ0KPiAyRGRhdGFzdG9yZXMmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhl
TUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdU
dmpJU2xhSmRjWm8mbQ0KPiA9SG1sQTdoU0FDQ0pCbWpOb21iWHNkU0x4TnM1Sm5GM0JyRmFZWFBX
WW9zZyZzPUw3blFKTWlYM01feVgNCj4gTFN3UEFTWmVmVWRXN1ltQTRseTlNaW9jWFZHaDQwJmU9
DQo+IA0KPiA+ID4gLTA2DQo+IA0KPiA+ID4NCj4gDQo+ID4gPg0KPiANCj4gPiA+IFBsZWFzZSBu
b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m
DQo+IA0KPiA+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm
ZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiANCj4gPiA+DQo+IA0KPiA+
ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0
Og0KPiANCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1m
dHAtDQo+IDNBX19mdHAuaWV0Zi5vcmdfaW50ZXJuZXQtDQo+IDJEZHJhZnRzXyZkPUR3SUdhUSZj
PUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4
bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtDQo+ID1IbWxBN2hTQUNDSkJt
ak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZb3NnJnM9ZV9tUWV5WFpieEVUeQ0KPiB2cjAtZ2N2
a1BlV3F2NG1TY3NGYTV1ZUFyVEtvUVEmZT0NCj4gDQo+ID4gPg0KPiANCj4gPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiA+ID4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPiANCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiANCj4gPiA+IGh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5p
ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1aA0K
PiByNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBv
T0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbQ0KPiA9SG1sQTdoU0FDQ0pCbWpOb21iWHNkU0x4
TnM1Sm5GM0JyRmFZWFBXWW9zZyZzPUwyeFF5al85MzhhVmN2NA0KPiBReUZNSGxOd1hrWDl0VDhM
NDZNMVBYYzZMbmg0JmU9DQo+IA0KPiA+ID4gLg0KPiANCj4gPiA+DQo+IA0KPiA+DQo+IA0KPiA+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiA+
IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gDQo+ID4gbmV0bW9kQGlldGYub3JnDQo+IA0KPiA+IGh0
dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3
dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1
aA0KPiByNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5
RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbQ0KPiA9SG1sQTdoU0FDQ0pCbWpOb21iWHNk
U0x4TnM1Sm5GM0JyRmFZWFBXWW9zZyZzPUwyeFF5al85MzhhVmN2NA0KPiBReUZNSGxOd1hrWDl0
VDhMNDZNMVBYYzZMbmg0JmU9DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9y
Zw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+
IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lHYVEmYz1IQWtZ
dWg2M3JzdWgNCj4gcjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhu
SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm0NCj4gPUhtbEE3aFNBQ0NKQm1q
Tm9tYlhzZFNMeE5zNUpuRjNCckZhWVhQV1lvc2cmcz1MMnhReWpfOTM4YVZjdjQNCj4gUXlGTUhs
TndYa1g5dFQ4TDQ2TTFQWGM2TG5oNCZlPQ0KPiANCg0K


From nobody Thu Nov  2 13:58: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 67AA913F95E for ; Thu,  2 Nov 2017 13:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJja21XYP98E for ; Thu,  2 Nov 2017 13:58:15 -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 3049A13F682 for ; Thu,  2 Nov 2017 13:58:15 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id r135so927319lfe.5 for ; Thu, 02 Nov 2017 13:58:15 -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=WfFpJjH6iCrNqvcs36BVm7CPL6cKK2rRoMu+YD3MZwM=; b=yQAZIAP9VPFH6w2OKR0FctDP997lpuuDhnrglMUJaTUEATP43fXyFEmeKw9uSzGUtx G/xhZusIA+2LhxCowyxPtOzanVMNknq2mfTp/G4714yntitcwlY9PnBAOYW+WbLPTFYH BWyesSsFvpjOGT7UTvdA7pPmYfvPAYpm15osEg6Hf8pjvLLJW83QGtKdbYGURh68bwcA 3qUO7QAd3+znFtdfyHt/yziZVcQrcvyvIr8Un9ziUQiZXE09D4qyO+tEIHvzUSxppt3j f6WSJlNx1rqv18RJTz+hpmv1HhAG08gMOsW80hf5oZADFsa1Yx2gH4ssIiTjTYch3i7S QGzg==
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=WfFpJjH6iCrNqvcs36BVm7CPL6cKK2rRoMu+YD3MZwM=; b=doysVGf7gFX+qEqOe0r19a3i2ARwvBWS+/7d1mNby1bEwZHKRmALBbdqDxHO4zPGdo 2mfKWuQRR7NbU3QhA7hfDjKrqPK3wuN7cJNTQMro7xgaxjPTrZygSTQaLFh6NdtyJ8qx DSgNYtg/LFeGHMJ+O8n0qgRp/bz5ukM4FxBsKhICn9+jp1RNc7022oHGxVd/pA0fnygi xR3byiAF7iyLKhLVVVcRiwbt+/39R5xe0Up1CKhbmn57yRW+5eOo+iaGeHQcjWgrbQ53 s2B3zq6B5gb63SMvT9flywZ9RP6a5WclknEX7NnPngVUBdQtQF8q1ZQoSqd/3m6XbudA WjjQ==
X-Gm-Message-State: AJaThX5D7Ka61SIdYBK3YRQo8VpLbLllKSbH2YsgRPXM8tq4jt0NF11U ogyDuVA4hZUQZmnP1/U7j3X7QG/fsjfSLsuzMaWiFA==
X-Google-Smtp-Source: ABhQp+Tz8J5iMdjLq2aNianbxJQGObFOXM33sut5aZci8KZdnRcVZsl7xff+gq26AH4SCcuWAfjYwTu924vO8OSnwDo=
X-Received: by 10.25.211.73 with SMTP id k70mr1742195lfg.51.1509656293362; Thu, 02 Nov 2017 13:58:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 2 Nov 2017 13:58:12 -0700 (PDT)
In-Reply-To: 
References: <076270A6-B2C1-44BC-8F02-F4E96675E76F@juniper.net> 
From: Andy Bierman 
Date: Thu, 2 Nov 2017 13:58:12 -0700
Message-ID: 
To: "Sterne, Jason (Nokia - CA/Ottawa)" 
Cc: Kent Watsen , Robert Wilton ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114188aa1965cd055d063f1a"
Archived-At: 
Subject: Re: [netmod] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 20:58:18 -0000

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

Hi,


On Thu, Nov 2, 2017 at 1:40 PM, Sterne, Jason (Nokia - CA/Ottawa) <
jason.sterne@nokia.com> wrote:

> Hi Kent,
> Yeah - I realize that I'm jumping ahead of where we are.  I'm a bit
> worried that we're making forward looking assumptions that we'll be able to
> stick to those constraints that we're defining in revised-datastores, and
> we may find that difficult later.
> For this specific issue I suppose there is at least the possibility that
> we *could* have a common schema (and have operational be a superset).
>


What problem is caused by having a template appear in  or
?
If none (appears that way) then no special rules are needed for templates.
What if I have a special RPC to override part of a template, so the
operational
value of the template is actually different than the configured value?
Since it is all proprietary at this point, better to leave templates for
later.



> Rgds,
> Jason
>


Andy


>
> > -----Original Message-----
> > From: Kent Watsen [mailto:kwatsen@juniper.net]
> > Sent: Thursday, November 02, 2017 16:31
> > To: Sterne, Jason (Nokia - CA/Ottawa) ; Robert
> > Wilton ; netmod@ietf.org
> > Subject: Re: [netmod] revised-datastores and commonality of schemas
> >
> > Hi Jason,
> >
> > All those details would need to be specified by some future templating
> > drafts.  In this draft, there is only the provision for "configuration
> > transformations" to keep that door open.
> >
> > Kent // contributor
> >
> >
> > --
> >
> > Hi guys,
> >
> >
> >
> > Templates are something that may be problematic for this concept of
> > common schemas across the running/candidate/intended DSes and then
> > operational being a superset.
> >
> >
> >
> > The  DS needs to have both the template itself in the schema as
> > well as whatever nodes are used to hold 'exploded' data.  But what about
> > intended and operational ?
> >
> >
> >
> > For example, imagine we have the following instance data in a candidate &
> > running DS:
> >
> > 1) a template that sets an admin-state leaf to 'enabled' in all
> interfaces
> >
> > 2) a set of 3 interfaces with a few leafs of config in them (address,
> etc)
> >
> >
> >
> > Clearly the schema for the candidate/running DSes contain both the
> > template and the interface schema nodes.
> >
> >
> >
> > But does the schema for the intended DS actually have the template schema
> > nodes ?   In theory it doesn't *need* to (since templates are exploded
> > between running & intended), and it feels strange to have those in there,
> > but I suppose it could have them.  If they are there, then a read of the
> > intended would show "admin-state enabled" in the template *and* in the 3
> > interfaces.
> >
> >
> >
> > Does the operational DS contain the template schema nodes ?  If yes,
> then I
> > suppose we would consider all templates as 'applied' implicitly ?
> >
> >
> >
> > Rgds,
> >
> > Jason
> >
> >
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
> >
> > > Wilton
> >
> > > Sent: Tuesday, October 31, 2017 10:01
> >
> > > To: netmod@ietf.org
> >
> > > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-
> datastores-
> >
> > > 06.txt
> >
> > >
> >
> > > 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://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__github.com_netmod-2Dwg_datastore-
> > 2Ddt_issues&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=Oh70ToB2vUTvtf
> > OGlJFxq9b-VdJvIq7Nw6S69fNgcTA&e=):
> >
> > >
> >
> > > (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://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised-
> > 2Ddatastores_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=kntbgpHJnrByHY
> > nP6-gIQawFyxzuB4qqA8a7sJ73Yro&e=
> >
> > > >
> >
> > > > There are also htmlized versions available at:
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores-
> > 2D06&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=l8WerMNvfvgZVJ
> > CnIEqxPofbgMz_Q_EzSiIoGbCQgNI&e=
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetmod-2Drevised-
> > 2Ddatast&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=WCuOo1niAkysc
> > QUKzIYmTuLvajFh0jn8MtmRmc6jjho&e=
> >
> > > > ores-06
> >
> > > >
> >
> > > > A diff from the previous version is available at:
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetmod-2Drevised-
> > 2Ddatastores&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=L7nQJMiX3M_yX
> > LSwPASZefUdW7YmA4ly9MiocXVGh40&e=
> >
> > > > -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:
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=ftp-
> > 3A__ftp.ietf.org_internet-
> > 2Ddrafts_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=e_mQeyXZbxETy
> > vr0-gcvkPeWqv4mScsFa5ueArTKoQQ&e=
> >
> > > >
> >
> > > > _______________________________________________
> >
> > > > netmod mailing list
> >
> > > > netmod@ietf.org
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuh
> > r6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=L2xQyj_938aVcv4
> > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=
> >
> > > > .
> >
> > > >
> >
> > >
> >
> > > _______________________________________________
> >
> > > netmod mailing list
> >
> > > netmod@ietf.org
> >
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuh
> > r6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=L2xQyj_938aVcv4
> > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=DwIGaQ&c=HAkYuh63rsuh
> > r6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =HmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=L2xQyj_938aVcv4
> > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,


On Thu, Nov 2, 2017 at 1:40 PM, Sterne, Jason (Nokia - CA/Ottaw=
a) <jason.sterne@nokia.com> wrote:
Hi Kent,

Yeah - I realize that I'm jumping ahead of where we are.=C2=A0 I'm =
a bit worried that we're making forward looking assumptions that we'=
;ll be able to stick to those constraints that we're defining in revise=
d-datastores, and we may find that difficult later.

For this specific issue I suppose there is at least the possibility that we=
 *could* have a common schema (and have operational be a superset).


What problem is caused by havin=
g a template appear in <operational> or <intended>?
I=
f none (appears that way) then no special rules are needed for templates.
What if I have a special RPC to override part of a template, so th=
e operational
value of the template is actually different than th=
e configured value?
Since it is all proprietary at this point, be=
tter to leave templates for later.

=C2=A0

Rgds,

Jason


Andy
=C2=
=A0



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

> From: Kent Watsen [mailto:kwats=
en@juniper.net]

> Sent: Thursday, November 02, 2017 16:31

> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; Robert

> Wilton <rwilton@cisco.com&=
gt;; netmod@ietf.org

> Subject: Re: [netmod] revised-datastores and commonality of schemas
>

> Hi Jason,

>

> All those details would need to be specified by some future templating=


> drafts.=C2=A0 In this draft, there is only the provision for "con=
figuration

> transformations" to keep that door open.

>

> Kent // contributor

>

>

> --

>

> Hi guys,

>

>

>

> Templates are something that may be problematic for this concept of
> common schemas across the running/candidate/intended DSes and then

> operational being a superset.

>

>

>

> The <running> DS needs to have both the template itself in the s=
chema as

> well as whatever nodes are used to hold 'exploded' data.=C2=A0=
 But what about

> intended and operational ?

>

>

>

> For example, imagine we have the following instance data in a candidat=
e &

> running DS:

>

> 1) a template that sets an admin-state leaf to 'enabled' in al=
l interfaces

>

> 2) a set of 3 interfaces with a few leafs of config in them (address, =
etc)

>

>

>

> Clearly the schema for the candidate/running DSes contain both the

> template and the interface schema nodes.

>

>

>

> But does the schema for the intended DS actually have the template sch=
ema

> nodes ?=C2=A0 =C2=A0In theory it doesn't *need* to (since template=
s are exploded

> between running & intended), and it feels strange to have those in=
 there,

> but I suppose it could have them.=C2=A0 If they are there, then a read=
 of the

> intended would show "admin-state enabled" in the template *a=
nd* in the 3

> interfaces.

>

>

>

> Does the operational DS contain the template schema nodes ?=C2=A0 If y=
es, then I

> suppose we would consider all templates as 'applied' implicitl=
y ?

>

>

>

> Rgds,

>

> Jason

>

>

>

>

>

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

>

> > From: netmod [mailto:n=
etmod-bounces@ietf.org] On Behalf Of Robert

>

> > Wilton

>

> > Sent: Tuesday, October 31, 2017 10:01

>

> > To: netmod@ietf.org

>

> > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-=
datastores-

>

> > 06.txt

>

> >

>

> > So this version of the draft contains the small change that defin=
es

> "datastore

>

> > schema" and describes the "datastore schema" of &l=
t;operational> as being

> the

>

> > superset of the datastore schema for all the configuration datast=
ores.

>

> >

>

> > There are two remaining issues open on the issue tracker

>

> > (https://urldefense.proofpoint.com=
/v2/url?u=3Dhttps-

> 3A__github.com_netmod-2Dwg_datastore-

> 2Ddt_issues&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DOh70T=
oB2vUTvtf

> OGlJFxq9b-VdJvIq7Nw6S69fNgcTA&e=3D):

>

> >

>

> > (1) Sign off that usage of RFC 2119 language is appropriate. Perh=
aps one of

>

> > the proponents of this change could please verify this.

>

> > (2) The email thread regarding Actions and RPCs in NMDA.=C2=A0 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.

>

> > >

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0: Network Management Datastore Architecture

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=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=A0 Juergen Schoenwaelder

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil Shafer

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kent Watsen

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Robert Wilton

>

> > >=C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf=
-netmod-revised-datastores-06.txt

>

> > >=C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =
38

>

> > >=C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =
2017-10-30

>

> > >

>

> > > Abstract:

>

> > >=C2=A0 =C2=A0 =C2=A0Datastores are a fundamental concept bind=
ing the data models written

>

> > >=C2=A0 =C2=A0 =C2=A0in the YANG data modeling language to net=
work management

> protocols

>

> > >=C2=A0 =C2=A0 =C2=A0such as NETCONF and RESTCONF.=C2=A0 This =
document defines an

> architectural

>

> > >=C2=A0 =C2=A0 =C2=A0framework for datastores based on the exp=
erience gained with the

>

> > >=C2=A0 =C2=A0 =C2=A0initial simpler model, addressing require=
ments that were not well

>

> > >=C2=A0 =C2=A0 =C2=A0supported in the initial model.

>

> > >

>

> > >

>

> > > The IETF datatracker status page for this draft is:

>

> > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised=
-

> 2Ddatastores_&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-=


> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3Dkntbg=
pHJnrByHY

> nP6-gIQawFyxzuB4qqA8a7sJ73Yro&e=3D

>

> > >

>

> > > There are also htmlized versions available at:

>

> > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drevised-2Dda=
tastores-

> 2D06&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3Dl8Wer=
MNvfvgZVJ

> CnIEqxPofbgMz_Q_EzSiIoGbCQgNI&e=3D

>

> > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetmod-2Dre=
vised-

> 2Ddatast&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DWCuOo=
1niAkysc

> QUKzIYmTuLvajFh0jn8MtmRmc6jjho&e=3D

>

> > > ores-06

>

> > >

>

> > > A diff from the previous version is available at:

>

> > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetmod-2Dre=
vised-

> 2Ddatastores&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-<=
br>
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL7nQJ=
MiX3M_yX

> LSwPASZefUdW7YmA4ly9MiocXVGh40&e=3D

>

> > > -06

>

> > >

>

> > >

>

> > > Please note that it may take a couple of minutes from the ti=
me of

>

> > > submission until the htmlized version and diff are available=
 at

> tools.ietf.org.

>

> > >

>

> > > Internet-Drafts are also available by anonymous FTP at:

>

> > > https://urldefense.proofpoint.c=
om/v2/url?u=3Dftp-

> 3A__ftp.ietf.org_internet-

> 2Ddrafts_&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3De_mQe=
yXZbxETy

> vr0-gcvkPeWqv4mScsFa5ueArTKoQQ&e=3D

>

> > >

>

> > > _______________________________________________

>

> > > netmod mailing list

>

> > > netmod@ietf.org

>

> > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3D<=
wbr>HAkYuh63rsuh

> r6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQy=
j_938aVcv4

> QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D

>

> > > .

>

> > >

>

> >

>

> > _______________________________________________

>

> > netmod mailing list

>

> > netmod@ietf.org

>

> > https://urldefense.proofpoint.com/=
v2/url?u=3Dhttps-

> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3D<=
wbr>HAkYuh63rsuh

> r6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQy=
j_938aVcv4

> QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://urldefense.proofpoint.com/v2/ur=
l?u=3Dhttps-

> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3D<=
wbr>HAkYuh63rsuh

> r6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQy=
j_938aVcv4

> QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a114188aa1965cd055d063f1a--


From nobody Thu Nov  2 14:04: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 CFA8E13F974 for ; Thu,  2 Nov 2017 14:04: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 fm5c5_uTaY2d for ; Thu,  2 Nov 2017 14:04:41 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0094.outbound.protection.outlook.com [104.47.36.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12CC313F986 for ; Thu,  2 Nov 2017 14:04: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=mOp8k1t7iLl227a0+wUpyQn3+CNqdNCkIb6tHJmULTE=; b=MoUyfEXvX2V9M4qLuurOT000oDJJPL/EKTwBctcaFQtNt8fb6XyqfyZFnIm/nINLM26Xiz1TI8wbws9tUAFk55JArXsJu/nPwY3zHeytKU3Y0MgjQ4tIP8WpiPGvNosw71cpAvrpyOu71itvFp45TZt29qtV1ywpF1dy49RpHRA=
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_128_CBC_SHA256_P256) id 15.20.218.6; Thu, 2 Nov 2017 21:04:29 +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.013; Thu, 2 Nov 2017 21:04:29 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: review of draft-ietf-netmod-schema-mount-08
Thread-Index: AQHTVB4smPzO0RNFj02ycL7IpPSiYg==
Date: Thu, 2 Nov 2017 21:04:29 +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.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:PptPqM1gnp2QZTt2nlQc/tsXFquKhzqrrEGksRgQBoagMK6uJIzckmMz/bD6UzzLlZzKDOrHlXnNMvKwQh75LfjMOaA5fdu6AmW22M7pU5ubZMjWr+ssOS+Qh9ucgbldVZjv31V8H76lupzgNeSEQvMrsZcgcCZ669LUydF3ejm7KgDSY1cz1VDUBYd2pjEgBnrf8G5cL4oqrakOD5RtqgYoLYtwS6PRtNdgLmko6zhGrlpKSDjf5x1IWZBwqlGW7HstrjWxP7832x91UIs3toVCWSUS+oKxMlAw2RsUd4QpkM4tTfClhQsTt/t5BmC4xtt18wtqjIzKobESUjyN5XFUlLsdjjEMsG98FMM8+/k=; 5:J2hHso+wc03GKJ5Vpgds5WYXi+w4YlJ5prBnkRsG8eOZR/OFCWQIeIlUP4fm3PydAO/4FekTPfq+dN1LaLqfkz3A6F9OLliyXHLKvxOLpKUR3wzXhq/RfRXROmkx41U+vA8NbJ+dn4beGYk89TaXQ1l7h86FWooJ12lDV9QBO6I=; 24:MzIw0sqYBhqiQk2dBwmQb8UyRZ2JZi4Z435DDaNNIaOQDnywbZCvVDG4mnXvKAjQDxiodayp9uueuyjsI1GNjiUfFGZR7X63KhK8OTV/k4k=; 7:8tL3iRt8bTiSqvTS4mViPmhxBMEf9OiYjnbjHJKiC/Q+6/W0V2rw7H8nhPrZKA+EO/Kst/eHAJn5kOxpRIIJqgdzzOV7/g2dcsYuvHnsWbqcHjdTZOpBF5O8V8yHNxtV/st0v47kt8XNzFpCN5/V5WbqJK9B5p4xez2vi5SH7gE7VKb4wPr8ChTqIdb4P3T1pGLlGuM72eWNi5i+l8GBzpCYjs6GD8A4JrIEgZNbrCfXKwGXxg9XwZaDV8ZCCB8d
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 4e44526d-c791-4410-d117-08d522354ebb
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603238); SRVR:BLUPR05MB273; 
x-ms-traffictypediagnostic: BLUPR05MB273:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(17755550239193); 
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)(93006095)(93001095)(100000703101)(100105400095)(3231020)(6055026)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(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: 047999FF16
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(199003)(189002)(43784003)(81166006)(1730700003)(81156014)(8676002)(106356001)(83506002)(6116002)(3846002)(102836003)(33656002)(8936002)(105586002)(25786009)(68736007)(2351001)(54356999)(50986999)(83716003)(101416001)(58126008)(2900100001)(36756003)(305945005)(6916009)(189998001)(316002)(82746002)(7736002)(2501003)(230783001)(2906002)(6512007)(6506006)(66066001)(3280700002)(6486002)(77096006)(478600001)(86362001)(97736004)(99286004)(53936002)(5640700003)(5660300001)(14454004)(6436002)(3660700001); 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: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e44526d-c791-4410-d117-08d522354ebb
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 21:04:29.1710 (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: [netmod] review of 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: Thu, 02 Nov 2017 21:04:43 -0000

SGksDQoNCkkgaGF2ZSByZWFkIHRoaXMgZG9jdW1lbnQgYW5kIHRoaW5rIHRoYXQgaXMgYWxtb3N0
IHJlYWR5IGZvciANCnB1YmxpY2F0aW9uLiAgSSBoYXZlIGZpdmUgZGlzY3VzcyBpdGVtcyBhbmQg
YSBidW5jaCBvZiBuaXRzLg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KMS4gRnJvbSBTZWN0
aW9uIDQ6DQoNCiAgIFJvdXRpbmcgY29uZmlndXJhdGlvbiBpbnNpZGUgYW4gTkkgb2Z0ZW4gbmVl
ZHMgdG8gcmVmZXIgdG8gaW50ZXJmYWNlcyAoYXQNCiAgIGxlYXN0IHRob3NlIHRoYXQgYXJlIGFz
c2lnbmVkIHRvIHRoZSBOSSksIHdoaWNoIGlzIGltcG9zc2libGUgdW5sZXNzIHN1Y2gNCiAgIGEg
cmVmZXJlbmNlIGNhbiBwb2ludCB0byBhIG5vZGUgaW4gdGhlIHBhcmVudCBzY2hlbWEgKGludGVy
ZmFjZSBuYW1lKS4NCg0KVGhpcyBzZWVtcyBvdmVyc3RhdGVkLiAgUmF0aGVyIGl0IGlzIGEgcmVz
dWx0IG9mIGFuIGVhcmxpZXIgZGVzaWduIGRlY2lzaW9uLg0KQW4gYWx0ZXJuYXRlIHNvbHV0aW9u
IG1pZ2h0IGhhdmUgZXhwb3J0ZWQgdGhlIGdsb2JhbCBpbnRlcmZhY2VzIGludG8gYSANCmNvbmZp
ZyBmYWxzZSBsaXN0IGluc2lkZSB0aGUgbW91bnQgamFpbC4gICBXYXMgc3VjaCBhIHNvbHV0aW9u
IGRpc2N1c3NlZD8NCg0KCQ0KMi4gQWxzbyBmcm9tIFNlY3Rpb24gNDoNCg0KICAgRm9yIGV2ZXJ5
IHNjaGVtYSBtb3VudGVkIHVzaW5nIHRoZSAidXNlLXNjaGVtYSIgbWV0aG9kLCBpdCBpcyBwb3Nz
aWJsZSANCiAgIHRvIHNwZWNpZnkgYSBsZWFmLWxpc3QgbmFtZWQgInBhcmVudC1yZWZlcmVuY2Ui
IHRoYXQgY29udGFpbnMgemVybyBvciBtb3JlDQogICBYUGF0aCAxLjAgZXhwcmVzc2lvbnMuICBF
YWNoIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVkIHdpdGggdGhlIG5vZGUgaW4gdGhlDQogICBwYXJl
bnQgZGF0YSB0cmVlIHdoZXJlIHRoZSBtb3VudCBwb2ludCBpcyBkZWZpbmVkIGFzIHRoZSBjb250
ZXh0IG5vZGUuICANCg0KSWYgeW91IGNhbiBuZXN0ZWQtbW91bnRzLCBjYW4geW91IGFsc28gaGF2
ZSBuZXN0ZWQgcGFyZW50LXJlZmVyZW5jZXM/DQoNCg0KMy4gQWxzbyBmcm9tIFNlY3Rpb24gNCAo
c2FtZSBwYXJhZ3JhcGgpOg0KDQogICBGb3IgdGhlIHB1cnBvc2VzIG9mDQogICBldmFsdWF0aW5n
IFhQYXRoIGV4cHJlc3Npb25zIHdpdGhpbiB0aGUgbW91bnRlZCBkYXRhIHRyZWUsIHRoZSB1bmlv
bg0KICAgb2YgYWxsIHN1Y2ggbm9kZXNldHMgaXMgYWRkZWQgdG8gdGhlIGFjY2Vzc2libGUgZGF0
YSB0cmVlLg0KDQpDb3VsZCB0aGlzIGV2ZXIgcmVzdWx0IGluIG5hbWUgY29sbGlzaW9uPw0KDQoN
CjQuIFJlZ2FyZGluZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgd2hhdCBhYm91dCAveWFuZ21u
dDpzY2hlbWEtbW91bnRzPw0KQWxzbywgc2hvdWxkIGhvdyBOQUNNIGludGVyYWN0cyB3aXRoIG1v
dW50ZWQgaW5zdGFuY2UgZGF0YSBiZSBzcGVjaWZpZWQ/DQoNCg0KNS4gVGhpcyBkb2N1bWVudCBk
b2VzIG5vdCBzYXkgYW55dGhpbmcgYWJvdXQgaG93IGl0IHJlbGF0ZXMgdG8gTk1EQS4gIENsZWFy
bHkgYWxsIHRoaXMgaXMgdGFyZ2V0ZWQgdG8gdGhlIGNvbnZlbnRpb25hbCBkYXRhc3RvcmVzLCBi
dXQgaG93IGlzIGl0IHJlZmxlY3RlZCBpbiBlLmcuLCA8b3BlcmF0aW9uYWw+PyAgRG9lcyBhbnl0
aGluZyBuZWVkIHRvIGJlIHNhaWQgaGVyZT8NCldoYXQgaWYgdGhlIG1vdW50ZWQgc2NoZW1hIGhh
cyBkZXZpYXRpb25zIGluIDxvcGVyYXRpb25hbD4uDQoNCg0KTml0cyAobGluZS1icmVhayBzZXBh
cmF0ZWQpOg0KDQpJcyAib3RoZXIgb3B0aW9uYWwgY2hvaWNlcyIgYmVpbmcgdmFndWUgb24gcHVy
cG9zZT8gIFNob3VsZCBpdCBqdXN0IGNhbGwgb3V0IGZlYXR1cmVzIGFuZCBkZXZpYXRpb25zPw0K
DQoidGhlIFlBTkcgbGlicmFyeSBkYXRhIiBzZWVtcyBvZGQuICBNYXliZSAidGhlIGluc3RhbmNl
IG9mIHRoZSBZQU5HIExpYnJhcnkgbW9kdWxlIj8NCg0KLSBkb2N1bWVudCwgYW5kIGNvdWxkIGJl
IHBvc3NpYmx5IGRlYWx0IHdpdGggaW4gYSBmdXR1cmUgcmV2aXNpb24gb2YgdGhlIFlBTkcgZGF0
YSBtb2RlbGluZyBsYW5ndWFnZQ0KKyBkb2N1bWVudCwgYXMgaXQgbmVlZHMgdG8gYmUgZGVhbHQg
d2l0aCBhcyBhbiB1cGRhdGUgdG8gdGhlIFlBTkcgZGF0YSBtb2RlbGluZyBsYW5ndWFnZQ0KDQot
IFNjaGVtYSBtb3VudCBhcHBsaWVzIHRvIHRoZSBkYXRhIG1vZGVsDQorIFNjaGVtYSBtb3VudCBy
ZWdhcmRzIHRoZSBkYXRhIG1vZGVsICANCg0KLSBUaGlzIGRvY3VtZW50IGFsbG93cyBtb3VudGlu
ZyBvZiBjb21wbGV0ZSBkYXRhIG1vZGVscyBvbmx5Lg0KKyBUaGlzIGRvY3VtZW50IGFsbG93cyBt
b3VudGluZyBvZiBjb21wbGV0ZSBtb2R1bGVzIG9ubHkuDQoNCi0gbWF5IGV4dGVuZCB0aGlzIG1v
ZGVsIGJ5IGRlZmluaW5nDQorIG1heSBleHRlbmQgdGhpcyBzb2x1dGlvbiBieSBkZWZpbmluZw0K
DQpJbiBTMywgcmVwbGFjZSAiWUFORyAxLjEiIHdpdGggIllBTkcgMS4xIGFuZCBpdHMgY29udGlu
dWFuY2VzIj8NCg0KLSBBICJjb250YWluZXIiIG9yICJsaXN0IiBub2RlDQorIEEgJ2NvbnRhaW5l
cicgb3IgJ2xpc3QnIG5vZGUNCgkNCi0gb2YgImNvbnRhaW5lciIgYW5kICJsaXN0IiBzdGF0ZW1l
bnRzLg0KKyBvZiB0aGUgImNvbnRhaW5lciIgYW5kICJsaXN0IiBzdGF0ZW1lbnRzLg0KDQotIE1v
dW50ZWQgc2NoZW1hcyBmb3IgYWxsIG1vdW50IHBvaW50cw0KKyBUaGUgc2NoZW1hIGZvciBhbGwg
bW91bnQgcG9pbnRzDQoNCi0gaW4gdGhlICJ5YW5nbW50OnNjaGVtYS1tb3VudHMiIGNvbnRhaW5l
ci4NCisgaW4gdGhlIHRvcC1sZXZlbCAieWFuZ21udDpzY2hlbWEtbW91bnRzIiBjb250YWluZXIg
ZGVmaW5lZCBpbiB0aGUgImlldGYteWFuZy1zY2hlbWEtbW91bnQiIG1vZHVsZSBkZWZpbmVkIGlu
IFtTZWN0aW9uIDhdLg0KDQogVGhlICJyZWZlcnMgdGhyb3VnaCBpdHMga2V5IiBwYXJ0IGlzIG5v
dCBjbGVhciAtIGFyZSB5b3UgdGFsa2luZyBhYm91dCB0aGUgbW91bnQtcG9pbnQncyBhcmd1bWVu
dC9sYWJlbD8NCg0KSSBkb24ndCB1bmRlcnN0YW5kICJhYm92ZSB0aG9zZSB0aGF0IGFyZSBkZWZp
bmVkIGluIHRoZSBwYXJlbnQgc2NoZW1hLiIgIC0gbW9zdGx5IHRoZSB3b3JkICJhYm92ZSIgaXMg
dGhyb3dpbmcgbWXigKYNCg0KLSBJZiBtdWx0aXBsZSBtb3VudCBwb2ludHMgd2l0aCB0aGUgc2Ft
ZSBuYW1lDQorIElmIG11bHRpcGxlIG1vdW50IHBvaW50cyB3aXRoIHRoZSBzYW1lIGxhYmVsICAg
ICh3YXNuJ3QgaXQgY2FsbGVkIGEgImxhYmVsIiBiZWZvcmU/KQ0KDQpSZWdhcmRpbmcgIk5vdGUs
IHRoYXQgaW4gdGhpcyBjYXNlIGEgbW91bnQgcG9pbnQiLCBiZXlvbmQgdGhlIG1pc3NpbmcgY29t
bWEsIGFuIGV4YW1wbGUgd291bGQgYmUgdmVyeSBoZWxwZnVsLiAgSSBkb24ndCBrbm93IGlmIEkg
dW5kZXJzdGFuZCBpdCByaWdodC4NCg0KSW4gdGhlIFlBTkcgaXRzZWxmLCAiU3RhdGUgZGF0YSBu
b2RlcyIgZGlkbid0IHBhcnNlIHdlbGwsICJQcm90b2NvbCBhY2Nlc3NpYmxlIG5vZGVzIiBpbnN0
ZWFkPw0KDQpSZWdhcmRpbmcgdGhlIGZpcnN0IHBhcmFncmFwaCBpbiBBcHBlbmRpeCBBLCBJIHRv
b2sgbWUgc29tZSB0aW1lIHRvIHJlYWxpemUgdGhhdCB0aGUgcnRnd2ctZGV2aWNlLW1vZGVsIGlu
Y2x1ZGVkIA0KaWV0Zi1uZXR3b3JrLWluc3RhbmNlIGFuZCB0aGF0IHRob3NlIG1vZHVsZXMgZGVm
aW5lIG1vdW50LXBvaW50cyBhbmQgd2hlcmUuICAgUGxlYXNlIG1ha2UgdGhpcyBlYXNpZXIgZm9y
IGZpcnN0LXRpbWUgcmVhZGVycy4NCg0KSW4gQTEsIGlzIGlldGYtbmV0d29yay1pbnN0YW5jZSBt
aXNzaW5nPyAgLSBtaWdodCB3YW50IHRvIGRvdWJsZS1jaGVjayBhbGwNCg0KSW4gYWxsIHRoZSBl
eGFtcGxlcywgYnV0IGJlZ2lubmluZyB3aXRoIEEyLCBpdCBtaWdodCBoZWxwIHRvIHNob3cgdGhl
IFJFU1RTQ09ORiBwcm90b2NvbCBvcGVyYXRpb24gdGhhdCBpbGx1c3RyYXRlcyB0aGUgcmVzdWx0
LCBzbyB0aGF0IGl0J3MgY2xlYXIgd2hlcmUgaW4gdGhlIGRhdGEgbW9kZWwgdGhlIHBhcnRpY3Vs
YXIgaW5zdGFuY2UgaXMgbG9jYXRlZC4gIEFueXRoaW5nIHRoYXQgY2FuIGJlIGRvbmUgdG8gcHJv
dmlkZSBtb3JlIGNvbnRleHQgd291bGQgYmUgaGVscGZ1bC4NCg0KRm9yIHRoZSAybmQgaGFsZiBv
ZiBBMiwgd2hhdCBoYXBwZW5zIGlmIHRoZXJlIGlzIGFuICJsbmUtMiIsIHdpbGwgaXQgYWxzbyBn
ZXQgImV0aDAiPw0KDQotIHdoaWNoIHNob3VsZCBpbmNsdWRlIGF0IGxlYXN0DQorIHdoaWNoIHNo
b3VsZCBpbmNsdWRlIGF0IGxlYXN0IGFuIGluc3RhbmNlIG9mIGlldGYteWFuZy1saWJyYXJ5Om1v
ZHVsZXMtc3RhdGUgYW5kIGlldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzLXN0YXRlLCBhcyBmb2xs
b3dzOiANCg0KDQpUaGFua3MgYWdhaW4sDQpLZW50DQoNCg0K


From nobody Thu Nov  2 14: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 185CA13F6E1 for ; Thu,  2 Nov 2017 14:13:01 -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 eqyO-4m_rVSz for ; Thu,  2 Nov 2017 14:12:57 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50117.outbound.protection.outlook.com [40.107.5.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 F333813F5D8 for ; Thu,  2 Nov 2017 14:12:56 -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=xDibQfWGaZWmfLdn6Id54SVv96x2Ph0eokFAxdEc00A=; b=IEqwuRd3LVX2gdqGbZut62AivIVFTYCsX3RK0W4YvOWuqCrdJL8yXKxtA8yKwKaA0LpTnxtRRZ41jetb/S+Ba3kEOHJwh7ZqBVvxK5TOPPncATkc/E1gbm0JdY+N8OSifGTUrwXaIebxqxKDs0SDONQKAvq0Zw/SpCMepn4PIrg=
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.218.6; Thu, 2 Nov 2017 21:12:54 +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.0218.004; Thu, 2 Nov 2017 21:12:54 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Andy Bierman 
CC: Kent Watsen , Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] revised-datastores and commonality of schemas
Thread-Index: AQHTVBmF43E0D8ha602Z4L7V9HBU3KMBjGKAgAAGAQCAAANPUA==
Date: Thu, 2 Nov 2017 21:12:53 +0000
Message-ID: 
References: <076270A6-B2C1-44BC-8F02-F4E96675E76F@juniper.net>  
In-Reply-To: 
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.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1121; 6:wizCLcjA9x1FxCvZBM+dCftG4hluQbotSjpY43Y0w6N2jiu+oTWQCjWXYkJlONnDQRhGrEQ1bnjHegZCOEIEhllyPTt+066XteD+RayD1CuejzACLgiVAD4Cf7h1jbc9DwA6MB3pREBFBOz84ZAIiqW8zwyEUcuQqiNzt20NrTjHlpzBR5RyPR5luefKHK6R1djJ6A+LMVxRxqAWO+YojBay6jVLGjYS8dVa251euKVCFPyHDDEXtOs/9qGERyQuToQfLo66mSJ5MkjOCC4SsU5ugLZAM6vE9Wv1LLLx3dwsUFCM5yAL5lKPmQmC5w642dDf3ro4/wgBL/DEyDWOZGLovousZmbDZfq71McLEI4=; 5:FHSsA2uXUPPYDjxcqnv9lmbC9pWhdtj8VfHgeiOkIMtuhKtxpP9ZIm31fNhf/1HxsO/qrC2erEUkO400/SHJbLmQreTzdALZ386ZOOxKu9lduKI1WZiakWrxVGPgA89I8EihE1+EwYjBtt3Rzo/ArfV6mdeayCP4Qfv0M4vnLSM=; 24:9CV+tvgB7jAi6gNvQxzuepeFe1UWzx7u4PJ6l9kPJnEI1zKS1YC/yrqEZ/0cg7veIYTpKzNtlFgAM1jfCxyPE3KENaVmE+5tZqgyEwAuD0k=; 7:ULR1B+vnlDyBvLEkpgAked5L2DEDevrdNwZTZbL90T+ELKrVJakPZZwydeSkK+1eQoJJV2rPw6JbvopotTKduN9Etg9+PKSUE8x6soE57Szyw3nBppcGd4PndCXuZguW7ctckzKlwrl56DOFrE6OOdttcMkQ4NiGNCDix6+vYgBTF+YIPJdsb6d/9gEwnVsaayHjLcP1zwOhpHMwh+vyPb22jQ9QUfu+u7HLQZ6e/NBGeusi2cHayssoNbehk/PT
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: f9690a1e-66f3-4f86-5e79-08d522367ba9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM3PR07MB1121; 
x-ms-traffictypediagnostic: AM3PR07MB1121:
x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008)(82608151540597)(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)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3231020)(3002001)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(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: 047999FF16
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(189002)(377424004)(199003)(24454002)(13464003)(229853002)(68736007)(6916009)(6116002)(3846002)(102836003)(790700001)(2950100002)(7696004)(606006)(106356001)(5250100002)(105586002)(66066001)(9326002)(14454004)(316002)(53546010)(4001150100001)(6506006)(6436002)(3660700001)(33656002)(189998001)(3280700002)(5660300001)(54906003)(97736004)(81166006)(81156014)(2906002)(8936002)(8676002)(14971765001)(54896002)(7736002)(9686003)(6306002)(4326008)(101416001)(966005)(54356999)(8666007)(236005)(76176999)(575784001)(50986999)(478600001)(6246003)(53386004)(74316002)(55016002)(2900100001)(86362001)(19609705001)(53936002)(99286004)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1121; 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_AM3PR07MB11246458D70D5355704191099B5C0AM3PR07MB1124eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f9690a1e-66f3-4f86-5e79-08d522367ba9
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 21:12:53.9975 (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] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 21:13:01 -0000

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

SGkgQW5keSwNCg0KSSBjYW7igJl0IHRoaW5rIG9mIGEgc3BlY2lmaWMgcHJvYmxlbSBpbW1lZGlh
dGVseS4gIEJ1dCBJIHRoaW5rIGl0IG1lYW5zIHRlbXBsYXRlcyB3b3VsZCBiZSBjb25zaWRlcmVk
IGFzIOKAnGFwcGxpZWTigJ0gYWx3YXlzIHJpZ2h0ID8gIE9yIGRvIHlvdSBzZWUgY2FzZXMgd2hl
cmUgdGVtcGxhdGVzIGRvbuKAmXQgc2hvdyB1cCB3aGVuIDxvcGVyYXRpb25hbD4gaXMgcmVhZCA/
DQoNClNwZWNpYWwgcnVsZXMgYXJlIGxpa2VseSB0byBiZSBuZWVkZWQgZm9yIHZhbGlkYXRpb24g
dGhvdWdoLiAgQSBEUyAod2l0aCB0ZW1wbGF0ZXMpIHdvbuKAmXQgYmUgdmFsaWQgdW5sZXNzIHlv
dSB2YWxpZGF0ZSBhbiBleHBsb2RlZCB2aWV3Lg0KDQpKYXNvbg0KDQpGcm9tOiBBbmR5IEJpZXJt
YW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIg
MDIsIDIwMTcgMTY6NTgNClRvOiBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgPGph
c29uLnN0ZXJuZUBub2tpYS5jb20+DQpDYzogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5u
ZXQ+OyBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNpc2NvLmNvbT47IG5ldG1vZEBpZXRmLm9yZw0K
U3ViamVjdDogUmU6IFtuZXRtb2RdIHJldmlzZWQtZGF0YXN0b3JlcyBhbmQgY29tbW9uYWxpdHkg
b2Ygc2NoZW1hcw0KDQpIaSwNCg0KDQpPbiBUaHUsIE5vdiAyLCAyMDE3IGF0IDE6NDAgUE0sIFN0
ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EvT3R0YXdhKSA8amFzb24uc3Rlcm5lQG5va2lhLmNvbTxt
YWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbT4+IHdyb3RlOg0KSGkgS2VudCwNClllYWggLSBJ
IHJlYWxpemUgdGhhdCBJJ20ganVtcGluZyBhaGVhZCBvZiB3aGVyZSB3ZSBhcmUuICBJJ20gYSBi
aXQgd29ycmllZCB0aGF0IHdlJ3JlIG1ha2luZyBmb3J3YXJkIGxvb2tpbmcgYXNzdW1wdGlvbnMg
dGhhdCB3ZSdsbCBiZSBhYmxlIHRvIHN0aWNrIHRvIHRob3NlIGNvbnN0cmFpbnRzIHRoYXQgd2Un
cmUgZGVmaW5pbmcgaW4gcmV2aXNlZC1kYXRhc3RvcmVzLCBhbmQgd2UgbWF5IGZpbmQgdGhhdCBk
aWZmaWN1bHQgbGF0ZXIuDQpGb3IgdGhpcyBzcGVjaWZpYyBpc3N1ZSBJIHN1cHBvc2UgdGhlcmUg
aXMgYXQgbGVhc3QgdGhlIHBvc3NpYmlsaXR5IHRoYXQgd2UgKmNvdWxkKiBoYXZlIGEgY29tbW9u
IHNjaGVtYSAoYW5kIGhhdmUgb3BlcmF0aW9uYWwgYmUgYSBzdXBlcnNldCkuDQoNCg0KV2hhdCBw
cm9ibGVtIGlzIGNhdXNlZCBieSBoYXZpbmcgYSB0ZW1wbGF0ZSBhcHBlYXIgaW4gPG9wZXJhdGlv
bmFsPiBvciA8aW50ZW5kZWQ+Pw0KSWYgbm9uZSAoYXBwZWFycyB0aGF0IHdheSkgdGhlbiBubyBz
cGVjaWFsIHJ1bGVzIGFyZSBuZWVkZWQgZm9yIHRlbXBsYXRlcy4NCldoYXQgaWYgSSBoYXZlIGEg
c3BlY2lhbCBSUEMgdG8gb3ZlcnJpZGUgcGFydCBvZiBhIHRlbXBsYXRlLCBzbyB0aGUgb3BlcmF0
aW9uYWwNCnZhbHVlIG9mIHRoZSB0ZW1wbGF0ZSBpcyBhY3R1YWxseSBkaWZmZXJlbnQgdGhhbiB0
aGUgY29uZmlndXJlZCB2YWx1ZT8NClNpbmNlIGl0IGlzIGFsbCBwcm9wcmlldGFyeSBhdCB0aGlz
IHBvaW50LCBiZXR0ZXIgdG8gbGVhdmUgdGVtcGxhdGVzIGZvciBsYXRlci4NCg0KDQpSZ2RzLA0K
SmFzb24NCg0KDQpBbmR5DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t
OiBLZW50IFdhdHNlbiBbbWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5A
anVuaXBlci5uZXQ+XQ0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDIsIDIwMTcgMTY6MzEN
Cj4gVG86IFN0ZXJuZSwgSmFzb24gKE5va2lhIC0gQ0EvT3R0YXdhKSA8amFzb24uc3Rlcm5lQG5v
a2lhLmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQG5va2lhLmNvbT4+OyBSb2JlcnQNCj4gV2lsdG9u
IDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PjsgbmV0bW9kQGll
dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBy
ZXZpc2VkLWRhdGFzdG9yZXMgYW5kIGNvbW1vbmFsaXR5IG9mIHNjaGVtYXMNCj4NCj4gSGkgSmFz
b24sDQo+DQo+IEFsbCB0aG9zZSBkZXRhaWxzIHdvdWxkIG5lZWQgdG8gYmUgc3BlY2lmaWVkIGJ5
IHNvbWUgZnV0dXJlIHRlbXBsYXRpbmcNCj4gZHJhZnRzLiAgSW4gdGhpcyBkcmFmdCwgdGhlcmUg
aXMgb25seSB0aGUgcHJvdmlzaW9uIGZvciAiY29uZmlndXJhdGlvbg0KPiB0cmFuc2Zvcm1hdGlv
bnMiIHRvIGtlZXAgdGhhdCBkb29yIG9wZW4uDQo+DQo+IEtlbnQgLy8gY29udHJpYnV0b3INCj4N
Cj4NCj4gLS0NCj4NCj4gSGkgZ3V5cywNCj4NCj4NCj4NCj4gVGVtcGxhdGVzIGFyZSBzb21ldGhp
bmcgdGhhdCBtYXkgYmUgcHJvYmxlbWF0aWMgZm9yIHRoaXMgY29uY2VwdCBvZg0KPiBjb21tb24g
c2NoZW1hcyBhY3Jvc3MgdGhlIHJ1bm5pbmcvY2FuZGlkYXRlL2ludGVuZGVkIERTZXMgYW5kIHRo
ZW4NCj4gb3BlcmF0aW9uYWwgYmVpbmcgYSBzdXBlcnNldC4NCj4NCj4NCj4NCj4gVGhlIDxydW5u
aW5nPiBEUyBuZWVkcyB0byBoYXZlIGJvdGggdGhlIHRlbXBsYXRlIGl0c2VsZiBpbiB0aGUgc2No
ZW1hIGFzDQo+IHdlbGwgYXMgd2hhdGV2ZXIgbm9kZXMgYXJlIHVzZWQgdG8gaG9sZCAnZXhwbG9k
ZWQnIGRhdGEuICBCdXQgd2hhdCBhYm91dA0KPiBpbnRlbmRlZCBhbmQgb3BlcmF0aW9uYWwgPw0K
Pg0KPg0KPg0KPiBGb3IgZXhhbXBsZSwgaW1hZ2luZSB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgaW5z
dGFuY2UgZGF0YSBpbiBhIGNhbmRpZGF0ZSAmDQo+IHJ1bm5pbmcgRFM6DQo+DQo+IDEpIGEgdGVt
cGxhdGUgdGhhdCBzZXRzIGFuIGFkbWluLXN0YXRlIGxlYWYgdG8gJ2VuYWJsZWQnIGluIGFsbCBp
bnRlcmZhY2VzDQo+DQo+IDIpIGEgc2V0IG9mIDMgaW50ZXJmYWNlcyB3aXRoIGEgZmV3IGxlYWZz
IG9mIGNvbmZpZyBpbiB0aGVtIChhZGRyZXNzLCBldGMpDQo+DQo+DQo+DQo+IENsZWFybHkgdGhl
IHNjaGVtYSBmb3IgdGhlIGNhbmRpZGF0ZS9ydW5uaW5nIERTZXMgY29udGFpbiBib3RoIHRoZQ0K
PiB0ZW1wbGF0ZSBhbmQgdGhlIGludGVyZmFjZSBzY2hlbWEgbm9kZXMuDQo+DQo+DQo+DQo+IEJ1
dCBkb2VzIHRoZSBzY2hlbWEgZm9yIHRoZSBpbnRlbmRlZCBEUyBhY3R1YWxseSBoYXZlIHRoZSB0
ZW1wbGF0ZSBzY2hlbWENCj4gbm9kZXMgPyAgIEluIHRoZW9yeSBpdCBkb2Vzbid0ICpuZWVkKiB0
byAoc2luY2UgdGVtcGxhdGVzIGFyZSBleHBsb2RlZA0KPiBiZXR3ZWVuIHJ1bm5pbmcgJiBpbnRl
bmRlZCksIGFuZCBpdCBmZWVscyBzdHJhbmdlIHRvIGhhdmUgdGhvc2UgaW4gdGhlcmUsDQo+IGJ1
dCBJIHN1cHBvc2UgaXQgY291bGQgaGF2ZSB0aGVtLiAgSWYgdGhleSBhcmUgdGhlcmUsIHRoZW4g
YSByZWFkIG9mIHRoZQ0KPiBpbnRlbmRlZCB3b3VsZCBzaG93ICJhZG1pbi1zdGF0ZSBlbmFibGVk
IiBpbiB0aGUgdGVtcGxhdGUgKmFuZCogaW4gdGhlIDMNCj4gaW50ZXJmYWNlcy4NCj4NCj4NCj4N
Cj4gRG9lcyB0aGUgb3BlcmF0aW9uYWwgRFMgY29udGFpbiB0aGUgdGVtcGxhdGUgc2NoZW1hIG5v
ZGVzID8gIElmIHllcywgdGhlbiBJDQo+IHN1cHBvc2Ugd2Ugd291bGQgY29uc2lkZXIgYWxsIHRl
bXBsYXRlcyBhcyAnYXBwbGllZCcgaW1wbGljaXRseSA/DQo+DQo+DQo+DQo+IFJnZHMsDQo+DQo+
IEphc29uDQo+DQo+DQo+DQo+DQo+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4N
Cj4gPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86
bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0DQo+DQo+ID4gV2ls
dG9uDQo+DQo+ID4gU2VudDogVHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyAxMDowMQ0KPg0KPiA+
IFRvOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4NCj4gPiBTdWJq
ZWN0OiBSZTogW25ldG1vZF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1k
YXRhc3RvcmVzLQ0KPg0KPiA+IDA2LnR4dA0KPg0KPiA+DQo+DQo+ID4gU28gdGhpcyB2ZXJzaW9u
IG9mIHRoZSBkcmFmdCBjb250YWlucyB0aGUgc21hbGwgY2hhbmdlIHRoYXQgZGVmaW5lcw0KPiAi
ZGF0YXN0b3JlDQo+DQo+ID4gc2NoZW1hIiBhbmQgZGVzY3JpYmVzIHRoZSAiZGF0YXN0b3JlIHNj
aGVtYSIgb2YgPG9wZXJhdGlvbmFsPiBhcyBiZWluZw0KPiB0aGUNCj4NCj4gPiBzdXBlcnNldCBv
ZiB0aGUgZGF0YXN0b3JlIHNjaGVtYSBmb3IgYWxsIHRoZSBjb25maWd1cmF0aW9uIGRhdGFzdG9y
ZXMuDQo+DQo+ID4NCj4NCj4gPiBUaGVyZSBhcmUgdHdvIHJlbWFpbmluZyBpc3N1ZXMgb3BlbiBv
biB0aGUgaXNzdWUgdHJhY2tlcg0KPg0KPiA+IChodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu
dC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19naXRodWIuY29tX25ldG1vZC0yRHdnX2RhdGFz
dG9yZS0NCj4gMkRkdF9pc3N1ZXMmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhl
TUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdU
dmpJU2xhSmRjWm8mbQ0KPiA9SG1sQTdoU0FDQ0pCbWpOb21iWHNkU0x4TnM1Sm5GM0JyRmFZWFBX
WW9zZyZzPU9oNzBUb0IydlVUdnRmDQo+IE9HbEpGeHE5Yi1WZEp2SXE3Tnc2UzY5Zk5nY1RBJmU9
KToNCj4NCj4gPg0KPg0KPiA+ICgxKSBTaWduIG9mZiB0aGF0IHVzYWdlIG9mIFJGQyAyMTE5IGxh
bmd1YWdlIGlzIGFwcHJvcHJpYXRlLiBQZXJoYXBzIG9uZSBvZg0KPg0KPiA+IHRoZSBwcm9wb25l
bnRzIG9mIHRoaXMgY2hhbmdlIGNvdWxkIHBsZWFzZSB2ZXJpZnkgdGhpcy4NCj4NCj4gPiAoMikg
VGhlIGVtYWlsIHRocmVhZCByZWdhcmRpbmcgQWN0aW9ucyBhbmQgUlBDcyBpbiBOTURBLiAgSSB3
aWxsIHNlbmQNCj4NCj4gPiB1cGRhdGVkIHByb3Bvc2VkIHRleHQgb24gdGhlIGFwcHJvcHJpYXRl
IHRocmVhZC4NCj4NCj4gPg0KPg0KPiA+IFRoYW5rcywNCj4NCj4gPiBSb2INCj4NCj4gPg0KPg0K
PiA+DQo+DQo+ID4gT24gMzAvMTAvMjAxNyAxODowNCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
PG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KPg0KPiA+ID4gQSBOZXcg
SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh
ZnRzDQo+DQo+ID4gZGlyZWN0b3JpZXMuDQo+DQo+ID4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBp
dGVtIG9mIHRoZSBOZXR3b3JrIE1vZGVsaW5nIFdHIG9mIHRoZSBJRVRGLg0KPg0KPiA+ID4NCj4N
Cj4gPiA+ICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IE5ldHdvcmsgTWFuYWdlbWVudCBEYXRh
c3RvcmUgQXJjaGl0ZWN0dXJlDQo+DQo+ID4gPiAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBN
YXJ0aW4gQmpvcmtsdW5kDQo+DQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdWVy
Z2VuIFNjaG9lbndhZWxkZXINCj4NCj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBo
aWwgU2hhZmVyDQo+DQo+ID4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBLZW50IFdhdHNl
bg0KPg0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9iZXJ0IFdpbHRvbg0KPg0K
PiA+ID4gICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFz
dG9yZXMtMDYudHh0DQo+DQo+ID4gPiAgIFBhZ2VzICAgICAgICAgICA6IDM4DQo+DQo+ID4gPiAg
IERhdGUgICAgICAgICAgICA6IDIwMTctMTAtMzANCj4NCj4gPiA+DQo+DQo+ID4gPiBBYnN0cmFj
dDoNCj4NCj4gPiA+ICAgICBEYXRhc3RvcmVzIGFyZSBhIGZ1bmRhbWVudGFsIGNvbmNlcHQgYmlu
ZGluZyB0aGUgZGF0YSBtb2RlbHMgd3JpdHRlbg0KPg0KPiA+ID4gICAgIGluIHRoZSBZQU5HIGRh
dGEgbW9kZWxpbmcgbGFuZ3VhZ2UgdG8gbmV0d29yayBtYW5hZ2VtZW50DQo+IHByb3RvY29scw0K
Pg0KPiA+ID4gICAgIHN1Y2ggYXMgTkVUQ09ORiBhbmQgUkVTVENPTkYuICBUaGlzIGRvY3VtZW50
IGRlZmluZXMgYW4NCj4gYXJjaGl0ZWN0dXJhbA0KPg0KPiA+ID4gICAgIGZyYW1ld29yayBmb3Ig
ZGF0YXN0b3JlcyBiYXNlZCBvbiB0aGUgZXhwZXJpZW5jZSBnYWluZWQgd2l0aCB0aGUNCj4NCj4g
PiA+ICAgICBpbml0aWFsIHNpbXBsZXIgbW9kZWwsIGFkZHJlc3NpbmcgcmVxdWlyZW1lbnRzIHRo
YXQgd2VyZSBub3Qgd2VsbA0KPg0KPiA+ID4gICAgIHN1cHBvcnRlZCBpbiB0aGUgaW5pdGlhbCBt
b2RlbC4NCj4NCj4gPiA+DQo+DQo+ID4gPg0KPg0KPiA+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIg
c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+DQo+ID4gPiBodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX19kYXRhdHJhY2tlci5pZXRm
Lm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmV2aXNlZC0NCj4gMkRkYXRhc3RvcmVz
XyZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRYY1d6
b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtDQo+ID1I
bWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZb3NnJnM9a250YmdwSEpuckJ5
SFkNCj4gblA2LWdJUWF3Rnl4enVCNHFxQThhN3NKNzNZcm8mZT0NCj4NCj4gPiA+DQo+DQo+ID4g
PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+DQo+ID4g
PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNB
X190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRG5ldG1vZC0yRHJldmlzZWQtMkRk
YXRhc3RvcmVzLQ0KPiAyRDA2JmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LQ0KPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZq
SVNsYUpkY1pvJm0NCj4gPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpuRjNCckZhWVhQV1lv
c2cmcz1sOFdlck1OdmZ2Z1pWSg0KPiBDbklFcXhQb2ZiZ016X1FfRXpTaUlvR2JDUWdOSSZlPQ0K
Pg0KPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz
LQ0KPiAzQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2h0bWxfZHJhZnQtMkRpZXRmLTJEbmV0
bW9kLTJEcmV2aXNlZC0NCj4gMkRkYXRhc3QmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZo
MFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJn
c0JZYUdUdmpJU2xhSmRjWm8mbQ0KPiA9SG1sQTdoU0FDQ0pCbWpOb21iWHNkU0x4TnM1Sm5GM0Jy
RmFZWFBXWW9zZyZzPVdDdU9vMW5pQWt5c2MNCj4gUVVLeklZbVR1THZhakZoMGpuOE10bVJtYzZq
amhvJmU9DQo+DQo+ID4gPiBvcmVzLTA2DQo+DQo+ID4gPg0KPg0KPiA+ID4gQSBkaWZmIGZyb20g
dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPg0KPiA+ID4gaHR0cHM6Ly91
cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYu
b3JnX3JmY2RpZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmV2aXNlZC0NCj4g
MkRkYXRhc3RvcmVzJmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLQ0KPiBu
ZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk
Y1pvJm0NCj4gPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpuRjNCckZhWVhQV1lvc2cmcz1M
N25RSk1pWDNNX3lYDQo+IExTd1BBU1plZlVkVzdZbUE0bHk5TWlvY1hWR2g0MCZlPQ0KPg0KPiA+
ID4gLTA2DQo+DQo+ID4gPg0KPg0KPiA+ID4NCj4NCj4gPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQg
bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+DQo+ID4gPiBz
dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi
bGUgYXQNCj4gdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4NCj4gPiA+
DQo+DQo+ID4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91
cyBGVFAgYXQ6DQo+DQo+ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9ZnRwLQ0KPiAzQV9fZnRwLmlldGYub3JnX2ludGVybmV0LQ0KPiAyRGRyYWZ0c18mZD1E
d0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNXem9DSSZy
PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbQ0KPiA9SG1sQTdo
U0FDQ0pCbWpOb21iWHNkU0x4TnM1Sm5GM0JyRmFZWFBXWW9zZyZzPWVfbVFleVhaYnhFVHkNCj4g
dnIwLWdjdmtQZVdxdjRtU2NzRmE1dWVBclRLb1FRJmU9DQo+DQo+ID4gPg0KPg0KPiA+ID4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4gPiA+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4NCj4gPiA+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k
QGlldGYub3JnPg0KPg0KPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9k
JmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VoDQo+IHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRY
Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtDQo+
ID1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZb3NnJnM9TDJ4UXlqXzkz
OGFWY3Y0DQo+IFF5Rk1IbE53WGtYOXRUOEw0Nk0xUFhjNkxuaDQmZT0NCj4NCj4gPiA+IC4NCj4N
Cj4gPiA+DQo+DQo+ID4NCj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPg0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4NCj4gPiBuZXRtb2RA
aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4NCj4gPiBodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFp
bG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWgNCj4gcjZTY2JmaDBV
akJYZU1LLQ0KPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NC
WWFHVHZqSVNsYUpkY1pvJm0NCj4gPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpuRjNCckZh
WVhQV1lvc2cmcz1MMnhReWpfOTM4YVZjdjQNCj4gUXlGTUhsTndYa1g5dFQ4TDQ2TTFQWGM2TG5o
NCZlPQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k
QGlldGYub3JnPg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lH
YVEmYz1IQWtZdWg2M3JzdWgNCj4gcjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFhjV3pvQ0km
cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm0NCj4gPUhtbEE3
aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpuRjNCckZhWVhQV1lvc2cmcz1MMnhReWpfOTM4YVZjdjQN
Cj4gUXlGTUhsTndYa1g5dFQ4TDQ2TTFQWGM2TG5oNCZlPQ0KPg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0
bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I
aSBBbmR5LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNhbuKAmXQgdGhpbmsgb2YgYSBzcGVj
aWZpYyBwcm9ibGVtIGltbWVkaWF0ZWx5LiZuYnNwOyBCdXQgSSB0aGluayBpdCBtZWFucyB0ZW1w
bGF0ZXMgd291bGQgYmUgY29uc2lkZXJlZCBhcyDigJxhcHBsaWVk4oCdIGFsd2F5cyByaWdodCA/
Jm5ic3A7IE9yIGRvIHlvdSBzZWUgY2FzZXMgd2hlcmUgdGVtcGxhdGVzIGRvbuKAmXQgc2hvdyB1
cCB3aGVuICZsdDtvcGVyYXRpb25hbCZndDsgaXMgcmVhZCA/PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlNwZWNpYWwgcnVsZXMgYXJlIGxpa2VseSB0byBiZSBuZWVkZWQgZm9yIHZhbGlkYXRpb24g
dGhvdWdoLiZuYnNwOyBBIERTICh3aXRoIHRlbXBsYXRlcykgd29u4oCZdCBiZSB2YWxpZCB1bmxl
c3MgeW91IHZhbGlkYXRlIGFuIGV4cGxvZGVkIHZpZXcuPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pkphc29uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg
MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu
IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFuZHkgQmllcm1h
biBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5
LCBOb3ZlbWJlciAwMiwgMjAxNyAxNjo1ODxicj4NCjxiPlRvOjwvYj4gU3Rlcm5lLCBKYXNvbiAo
Tm9raWEgLSBDQS9PdHRhd2EpICZsdDtqYXNvbi5zdGVybmVAbm9raWEuY29tJmd0Ozxicj4NCjxi
PkNjOjwvYj4gS2VudCBXYXRzZW4gJmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7OyBSb2JlcnQg
V2lsdG9uICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDs7IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gcmV2aXNlZC1kYXRhc3RvcmVzIGFuZCBjb21tb25h
bGl0eSBvZiBzY2hlbWFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBOb3YgMiwg
MjAxNyBhdCAxOjQwIFBNLCBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgJmx0Ozxh
IGhyZWY9Im1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFz
b24uc3Rlcm5lQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6
MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEtlbnQsPGJyPg0KWWVhaCAtIEkgcmVhbGl6
ZSB0aGF0IEknbSBqdW1waW5nIGFoZWFkIG9mIHdoZXJlIHdlIGFyZS4mbmJzcDsgSSdtIGEgYml0
IHdvcnJpZWQgdGhhdCB3ZSdyZSBtYWtpbmcgZm9yd2FyZCBsb29raW5nIGFzc3VtcHRpb25zIHRo
YXQgd2UnbGwgYmUgYWJsZSB0byBzdGljayB0byB0aG9zZSBjb25zdHJhaW50cyB0aGF0IHdlJ3Jl
IGRlZmluaW5nIGluIHJldmlzZWQtZGF0YXN0b3JlcywgYW5kIHdlIG1heSBmaW5kIHRoYXQgZGlm
ZmljdWx0IGxhdGVyLjxicj4NCkZvciB0aGlzIHNwZWNpZmljIGlzc3VlIEkgc3VwcG9zZSB0aGVy
ZSBpcyBhdCBsZWFzdCB0aGUgcG9zc2liaWxpdHkgdGhhdCB3ZSAqY291bGQqIGhhdmUgYSBjb21t
b24gc2NoZW1hIChhbmQgaGF2ZSBvcGVyYXRpb25hbCBiZSBhIHN1cGVyc2V0KS48bzpwPjwvbzpw
PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hh
dCBwcm9ibGVtIGlzIGNhdXNlZCBieSBoYXZpbmcgYSB0ZW1wbGF0ZSBhcHBlYXIgaW4gJmx0O29w
ZXJhdGlvbmFsJmd0OyBvciAmbHQ7aW50ZW5kZWQmZ3Q7PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgbm9uZSAoYXBwZWFycyB0aGF0IHdheSkg
dGhlbiBubyBzcGVjaWFsIHJ1bGVzIGFyZSBuZWVkZWQgZm9yIHRlbXBsYXRlcy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgaWYgSSBoYXZl
IGEgc3BlY2lhbCBSUEMgdG8gb3ZlcnJpZGUgcGFydCBvZiBhIHRlbXBsYXRlLCBzbyB0aGUgb3Bl
cmF0aW9uYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPnZhbHVlIG9mIHRoZSB0ZW1wbGF0ZSBpcyBhY3R1YWxseSBkaWZmZXJlbnQgdGhhbiB0aGUg
Y29uZmlndXJlZCB2YWx1ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlNpbmNlIGl0IGlzIGFsbCBwcm9wcmlldGFyeSBhdCB0aGlzIHBvaW50LCBi
ZXR0ZXIgdG8gbGVhdmUgdGVtcGxhdGVzIGZvciBsYXRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj
Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7
bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZ2RzLDxicj4NCkphc29u
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N
CiZndDsgRnJvbTogS2VudCBXYXRzZW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBq
dW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT5dPGJyPg0KJmd0OyBTZW50OiBUaHVy
c2RheSwgTm92ZW1iZXIgMDIsIDIwMTcgMTY6MzE8YnI+DQomZ3Q7IFRvOiBTdGVybmUsIEphc29u
IChOb2tpYSAtIENBL090dGF3YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYXNvbi5zdGVybmVAbm9r
aWEuY29tIj5qYXNvbi5zdGVybmVAbm9raWEuY29tPC9hPiZndDs7IFJvYmVydDxicj4NCiZndDsg
V2lsdG9uICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3aWx0b25AY2lz
Y28uY29tPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPg0KbmV0bW9k
QGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtuZXRtb2RdIHJldmlzZWQtZGF0
YXN0b3JlcyBhbmQgY29tbW9uYWxpdHkgb2Ygc2NoZW1hczxicj4NCiZndDs8YnI+DQomZ3Q7IEhp
IEphc29uLDxicj4NCiZndDs8YnI+DQomZ3Q7IEFsbCB0aG9zZSBkZXRhaWxzIHdvdWxkIG5lZWQg
dG8gYmUgc3BlY2lmaWVkIGJ5IHNvbWUgZnV0dXJlIHRlbXBsYXRpbmc8YnI+DQomZ3Q7IGRyYWZ0
cy4mbmJzcDsgSW4gdGhpcyBkcmFmdCwgdGhlcmUgaXMgb25seSB0aGUgcHJvdmlzaW9uIGZvciAm
cXVvdDtjb25maWd1cmF0aW9uPGJyPg0KJmd0OyB0cmFuc2Zvcm1hdGlvbnMmcXVvdDsgdG8ga2Vl
cCB0aGF0IGRvb3Igb3Blbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBLZW50IC8vIGNvbnRyaWJ1dG9y
PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0Ozxicj4NCiZndDsgSGkg
Z3V5cyw8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRlbXBsYXRlcyBh
cmUgc29tZXRoaW5nIHRoYXQgbWF5IGJlIHByb2JsZW1hdGljIGZvciB0aGlzIGNvbmNlcHQgb2Y8
YnI+DQomZ3Q7IGNvbW1vbiBzY2hlbWFzIGFjcm9zcyB0aGUgcnVubmluZy9jYW5kaWRhdGUvaW50
ZW5kZWQgRFNlcyBhbmQgdGhlbjxicj4NCiZndDsgb3BlcmF0aW9uYWwgYmVpbmcgYSBzdXBlcnNl
dC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSAmbHQ7cnVubmlu
ZyZndDsgRFMgbmVlZHMgdG8gaGF2ZSBib3RoIHRoZSB0ZW1wbGF0ZSBpdHNlbGYgaW4gdGhlIHNj
aGVtYSBhczxicj4NCiZndDsgd2VsbCBhcyB3aGF0ZXZlciBub2RlcyBhcmUgdXNlZCB0byBob2xk
ICdleHBsb2RlZCcgZGF0YS4mbmJzcDsgQnV0IHdoYXQgYWJvdXQ8YnI+DQomZ3Q7IGludGVuZGVk
IGFuZCBvcGVyYXRpb25hbCA/PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0
OyBGb3IgZXhhbXBsZSwgaW1hZ2luZSB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgaW5zdGFuY2UgZGF0
YSBpbiBhIGNhbmRpZGF0ZSAmYW1wOzxicj4NCiZndDsgcnVubmluZyBEUzo8YnI+DQomZ3Q7PGJy
Pg0KJmd0OyAxKSBhIHRlbXBsYXRlIHRoYXQgc2V0cyBhbiBhZG1pbi1zdGF0ZSBsZWFmIHRvICdl
bmFibGVkJyBpbiBhbGwgaW50ZXJmYWNlczxicj4NCiZndDs8YnI+DQomZ3Q7IDIpIGEgc2V0IG9m
IDMgaW50ZXJmYWNlcyB3aXRoIGEgZmV3IGxlYWZzIG9mIGNvbmZpZyBpbiB0aGVtIChhZGRyZXNz
LCBldGMpPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDbGVhcmx5IHRo
ZSBzY2hlbWEgZm9yIHRoZSBjYW5kaWRhdGUvcnVubmluZyBEU2VzIGNvbnRhaW4gYm90aCB0aGU8
YnI+DQomZ3Q7IHRlbXBsYXRlIGFuZCB0aGUgaW50ZXJmYWNlIHNjaGVtYSBub2Rlcy48YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEJ1dCBkb2VzIHRoZSBzY2hlbWEgZm9y
IHRoZSBpbnRlbmRlZCBEUyBhY3R1YWxseSBoYXZlIHRoZSB0ZW1wbGF0ZSBzY2hlbWE8YnI+DQom
Z3Q7IG5vZGVzID8mbmJzcDsgJm5ic3A7SW4gdGhlb3J5IGl0IGRvZXNuJ3QgKm5lZWQqIHRvIChz
aW5jZSB0ZW1wbGF0ZXMgYXJlIGV4cGxvZGVkPGJyPg0KJmd0OyBiZXR3ZWVuIHJ1bm5pbmcgJmFt
cDsgaW50ZW5kZWQpLCBhbmQgaXQgZmVlbHMgc3RyYW5nZSB0byBoYXZlIHRob3NlIGluIHRoZXJl
LDxicj4NCiZndDsgYnV0IEkgc3VwcG9zZSBpdCBjb3VsZCBoYXZlIHRoZW0uJm5ic3A7IElmIHRo
ZXkgYXJlIHRoZXJlLCB0aGVuIGEgcmVhZCBvZiB0aGU8YnI+DQomZ3Q7IGludGVuZGVkIHdvdWxk
IHNob3cgJnF1b3Q7YWRtaW4tc3RhdGUgZW5hYmxlZCZxdW90OyBpbiB0aGUgdGVtcGxhdGUgKmFu
ZCogaW4gdGhlIDM8YnI+DQomZ3Q7IGludGVyZmFjZXMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+
DQomZ3Q7PGJyPg0KJmd0OyBEb2VzIHRoZSBvcGVyYXRpb25hbCBEUyBjb250YWluIHRoZSB0ZW1w
bGF0ZSBzY2hlbWEgbm9kZXMgPyZuYnNwOyBJZiB5ZXMsIHRoZW4gSTxicj4NCiZndDsgc3VwcG9z
ZSB3ZSB3b3VsZCBjb25zaWRlciBhbGwgdGVtcGxhdGVzIGFzICdhcHBsaWVkJyBpbXBsaWNpdGx5
ID88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFJnZHMsPGJyPg0KJmd0
Ozxicj4NCiZndDsgSmFzb248YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N
CiZndDs8YnI+DQomZ3Q7ICZndDsgRnJvbTogbmV0bW9kIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv
Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u
IEJlaGFsZiBPZiBSb2JlcnQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFdpbHRvbjxicj4NCiZn
dDs8YnI+DQomZ3Q7ICZndDsgU2VudDogVHVlc2RheSwgT2N0b2JlciAzMSwgMjAxNyAxMDowMTxi
cj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v
cmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6
IFJlOiBbbmV0bW9kXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFz
dG9yZXMtPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAwNi50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0
OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBTbyB0aGlzIHZlcnNpb24gb2YgdGhlIGRy
YWZ0IGNvbnRhaW5zIHRoZSBzbWFsbCBjaGFuZ2UgdGhhdCBkZWZpbmVzPGJyPg0KJmd0OyAmcXVv
dDtkYXRhc3RvcmU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IHNjaGVtYSZxdW90OyBhbmQgZGVz
Y3JpYmVzIHRoZSAmcXVvdDtkYXRhc3RvcmUgc2NoZW1hJnF1b3Q7IG9mICZsdDtvcGVyYXRpb25h
bCZndDsgYXMgYmVpbmc8YnI+DQomZ3Q7IHRoZTxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgc3Vw
ZXJzZXQgb2YgdGhlIGRhdGFzdG9yZSBzY2hlbWEgZm9yIGFsbCB0aGUgY29uZmlndXJhdGlvbiBk
YXRhc3RvcmVzLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm
Z3Q7IFRoZXJlIGFyZSB0d28gcmVtYWluaW5nIGlzc3VlcyBvcGVuIG9uIHRoZSBpc3N1ZSB0cmFj
a2VyPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAoPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy08L2E+PGJyPg0KJmd0OyAz
QV9fZ2l0aHViLmNvbV9uZXRtb2QtMkR3Z19kYXRhc3RvcmUtPGJyPg0KJmd0OyAyRGR0X2lzc3Vl
cyZhbXA7ZD1Ed0lHYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLTxicj4NCiZn
dDsgbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdU
dmpJU2xhSmRjWm8mYW1wO208YnI+DQomZ3Q7ID1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVK
bkYzQnJGYVlYUFdZb3NnJmFtcDtzPU9oNzBUb0IydlVUdnRmPGJyPg0KJmd0OyBPR2xKRnhxOWIt
VmRKdklxN053NlM2OWZOZ2NUQSZhbXA7ZT0pOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICgxKSBTaWduIG9mZiB0aGF0IHVzYWdlIG9mIFJGQyAyMTE5
IGxhbmd1YWdlIGlzIGFwcHJvcHJpYXRlLiBQZXJoYXBzIG9uZSBvZjxicj4NCiZndDs8YnI+DQom
Z3Q7ICZndDsgdGhlIHByb3BvbmVudHMgb2YgdGhpcyBjaGFuZ2UgY291bGQgcGxlYXNlIHZlcmlm
eSB0aGlzLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgKDIpIFRoZSBlbWFpbCB0aHJlYWQgcmVn
YXJkaW5nIEFjdGlvbnMgYW5kIFJQQ3MgaW4gTk1EQS4mbmJzcDsgSSB3aWxsIHNlbmQ8YnI+DQom
Z3Q7PGJyPg0KJmd0OyAmZ3Q7IHVwZGF0ZWQgcHJvcG9zZWQgdGV4dCBvbiB0aGUgYXBwcm9wcmlh
dGUgdGhyZWFkLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm
Z3Q7IFRoYW5rcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFJvYjxicj4NCiZndDs8YnI+DQom
Z3Q7ICZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0
OyBPbiAzMC8xMC8yMDE3IDE4OjA0LCA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll
dGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IHdyb3RlOjxicj4NCiZndDs8YnI+
DQomZ3Q7ICZndDsgJmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0
aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGRpcmVj
dG9yaWVzLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGlzIGRyYWZ0IGlzIGEgd29y
ayBpdGVtIG9mIHRoZSBOZXR3b3JrIE1vZGVsaW5nIFdHIG9mIHRoZSBJRVRGLjxicj4NCiZndDs8
YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOzogTmV0d29yayBNYW5hZ2VtZW50IERhdGFzdG9yZSBBcmNoaXRlY3R1
cmU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBNYXJ0
aW4gQmpvcmtsdW5kPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI8YnI+DQomZ3Q7
PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IFBoaWwgU2hhZmVyPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLZW50IFdhdHNlbjxicj4NCiZndDs8YnI+DQom
Z3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUm9i
ZXJ0IFdpbHRvbjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDtGaWxl
bmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtbmV0bW9kLXJldmlz
ZWQtZGF0YXN0b3Jlcy0wNi50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsg
Jm5ic3A7UGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMzg8
YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7RGF0ZSZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAxNy0xMC0zMDxicj4NCiZndDs8YnI+
DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBBYnN0cmFjdDo8
YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGFzdG9y
ZXMgYXJlIGEgZnVuZGFtZW50YWwgY29uY2VwdCBiaW5kaW5nIHRoZSBkYXRhIG1vZGVscyB3cml0
dGVuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtpbiB0
aGUgWUFORyBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIHRvIG5ldHdvcmsgbWFuYWdlbWVudDxicj4N
CiZndDsgcHJvdG9jb2xzPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw
OyAmbmJzcDtzdWNoIGFzIE5FVENPTkYgYW5kIFJFU1RDT05GLiZuYnNwOyBUaGlzIGRvY3VtZW50
IGRlZmluZXMgYW48YnI+DQomZ3Q7IGFyY2hpdGVjdHVyYWw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm
Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2ZyYW1ld29yayBmb3IgZGF0YXN0b3JlcyBiYXNl
ZCBvbiB0aGUgZXhwZXJpZW5jZSBnYWluZWQgd2l0aCB0aGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm
Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2luaXRpYWwgc2ltcGxlciBtb2RlbCwgYWRkcmVz
c2luZyByZXF1aXJlbWVudHMgdGhhdCB3ZXJlIG5vdCB3ZWxsPGJyPg0KJmd0Ozxicj4NCiZndDsg
Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzdXBwb3J0ZWQgaW4gdGhlIGluaXRpYWwgbW9k
ZWwuPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2Vy
IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsg
Jmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtPC9hPjxicj4NCiZndDsgM0FfX2RhdGF0cmFja2VyLmlldGYub3Jn
X2RvY19kcmFmdC0yRGlldGYtMkRuZXRtb2QtMkRyZXZpc2VkLTxicj4NCiZndDsgMkRkYXRhc3Rv
cmVzXyZhbXA7ZD1Ed0lHYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLTxicj4N
CiZndDsgbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ
YUdUdmpJU2xhSmRjWm8mYW1wO208YnI+DQomZ3Q7ID1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhO
czVKbkYzQnJGYVlYUFdZb3NnJmFtcDtzPWtudGJncEhKbnJCeUhZPGJyPg0KJmd0OyBuUDYtZ0lR
YXdGeXh6dUI0cXFBOGE3c0o3M1lybyZhbXA7ZT08YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn
dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg
dmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBo
cmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtIiB0
YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cHMtPC9hPjxicj4NCiZndDsgM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRp
ZXRmLTJEbmV0bW9kLTJEcmV2aXNlZC0yRGRhdGFzdG9yZXMtPGJyPg0KJmd0OyAyRDA2JmFtcDtk
PUR3SUdhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstPGJyPg0KJmd0OyBuZGIz
dm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZhbXA7bTxicj4NCiZndDsgPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5zNUpuRjNCckZh
WVhQV1lvc2cmYW1wO3M9bDhXZXJNTnZmdmdaVko8YnI+DQomZ3Q7IENuSUVxeFBvZmJnTXpfUV9F
elNpSW9HYkNRZ05JJmFtcDtlPTxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVm
PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtIiB0YXJn
ZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtPC9hPjxicj4NCiZndDsgM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19odG1sX2Ry
YWZ0LTJEaWV0Zi0yRG5ldG1vZC0yRHJldmlzZWQtPGJyPg0KJmd0OyAyRGRhdGFzdCZhbXA7ZD1E
d0lHYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLTxicj4NCiZndDsgbmRiM3Zv
RFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRj
Wm8mYW1wO208YnI+DQomZ3Q7ID1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlY
UFdZb3NnJmFtcDtzPVdDdU9vMW5pQWt5c2M8YnI+DQomZ3Q7IFFVS3pJWW1UdUx2YWpGaDBqbjhN
dG1SbWM2ampobyZhbXA7ZT08YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgb3Jlcy0wNjxi
cj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0
OyBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0K
Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJs
ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy08L2E+PGJyPg0KJmd0OyAzQV9f
d3d3LmlldGYub3JnX3JmY2RpZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJEbmV0bW9kLTJEcmV2
aXNlZC08YnI+DQomZ3Q7IDJEZGF0YXN0b3JlcyZhbXA7ZD1Ed0lHYVEmYW1wO2M9SEFrWXVoNjNy
c3VocjZTY2JmaDBVakJYZU1LLTxicj4NCiZndDsgbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1Aw
eG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO208YnI+DQomZ3Q7ID1I
bWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZb3NnJmFtcDtzPUw3blFKTWlY
M01feVg8YnI+DQomZ3Q7IExTd1BBU1plZlVkVzdZbUE0bHk5TWlvY1hWR2g0MCZhbXA7ZT08YnI+
DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLTA2PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAm
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm
cm9tIHRoZSB0aW1lIG9mPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IHN1Ym1pc3Npb24g
dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdDxicj4N
CiZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9v
bHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDs8
YnI+DQomZ3Q7ICZndDsgJmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5
IGFub255bW91cyBGVFAgYXQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9
Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1mdHAtIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWZ0cC08
L2E+PGJyPg0KJmd0OyAzQV9fZnRwLmlldGYub3JnX2ludGVybmV0LTxicj4NCiZndDsgMkRkcmFm
dHNfJmFtcDtkPUR3SUdhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstPGJyPg0K
Jmd0OyBuZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh
R1R2aklTbGFKZGNabyZhbXA7bTxicj4NCiZndDsgPUhtbEE3aFNBQ0NKQm1qTm9tYlhzZFNMeE5z
NUpuRjNCckZhWVhQV1lvc2cmYW1wO3M9ZV9tUWV5WFpieEVUeTxicj4NCiZndDsgdnIwLWdjdmtQ
ZVdxdjRtU2NzRmE1dWVBclRLb1FRJmFtcDtlPTxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0
Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBuZXRt
b2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1h
aWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t
L3YyL3VybD91PWh0dHBzLSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTwvYT48YnI+DQomZ3Q7IDNBX193d3cuaWV0Zi5v
cmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJR2FRJmFtcDtjPUhBa1l1aDYzcnN1
aDxicj4NCiZndDsgcjZTY2JmaDBVakJYZU1LLTxicj4NCiZndDsgbmRiM3ZvRFRYY1d6b0NJJmFt
cDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO208YnI+
DQomZ3Q7ID1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlYUFdZb3NnJmFtcDtz
PUwyeFF5al85MzhhVmN2NDxicj4NCiZndDsgUXlGTUhsTndYa1g5dFQ4TDQ2TTFQWGM2TG5oNCZh
bXA7ZT08YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLjxicj4NCiZndDs8YnI+DQomZ3Q7
ICZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm
Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
Jmd0Ozxicj4NCiZndDsgJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0Ozxicj4NCiZn
dDsgJmd0OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8
L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91
cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTwvYT48YnI+DQomZ3Q7IDNB
X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJR2FRJmFtcDtj
PUhBa1l1aDYzcnN1aDxicj4NCiZndDsgcjZTY2JmaDBVakJYZU1LLTxicj4NCiZndDsgbmRiM3Zv
RFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRj
Wm8mYW1wO208YnI+DQomZ3Q7ID1IbWxBN2hTQUNDSkJtak5vbWJYc2RTTHhOczVKbkYzQnJGYVlY
UFdZb3NnJmFtcDtzPUwyeFF5al85MzhhVmN2NDxicj4NCiZndDsgUXlGTUhsTndYa1g5dFQ4TDQ2
TTFQWGM2TG5oNCZhbXA7ZT08YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbmV0bW9kIG1haWxpbmcgbGlz
dDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYu
b3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5w
cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy08L2E+PGJyPg0KJmd0OyAzQV9fd3d3LmlldGYu
b3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3SUdhUSZhbXA7Yz1IQWtZdWg2M3Jz
dWg8YnI+DQomZ3Q7IHI2U2NiZmgwVWpCWGVNSy08YnI+DQomZ3Q7IG5kYjN2b0RUWGNXem9DSSZh
bXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPGJy
Pg0KJmd0OyA9SG1sQTdoU0FDQ0pCbWpOb21iWHNkU0x4TnM1Sm5GM0JyRmFZWFBXWW9zZyZhbXA7
cz1MMnhReWpfOTM4YVZjdjQ8YnI+DQomZ3Q7IFF5Rk1IbE53WGtYOXRUOEw0Nk0xUFhjNkxuaDQm
YW1wO2U9PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9
Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxv
OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_AM3PR07MB11246458D70D5355704191099B5C0AM3PR07MB1124eurp_--


From nobody Thu Nov  2 14:16: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 8CCBB13F989 for ; Thu,  2 Nov 2017 14:16:40 -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 iFQjN9mDLLoc for ; Thu,  2 Nov 2017 14:16:38 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0133.outbound.protection.outlook.com [104.47.33.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 5912513F987 for ; Thu,  2 Nov 2017 14:16:38 -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=+fsry1pnfvIdmR3DSvwYQFygUSnEftFfA78Lj+jQDt8=; b=VgqEi++UrJgQgFT7LmYTt45w3iQDaQcTinOWD6DqO7zriB5YsUgh071iugakytZaoI+dgbF9Ho/wMRNHfDn+SiU5Z7r/HIkdWDU9lg8RnQRFCofeWUl+dO2n7HVDBkINStO1Lid6Gzpqql7RmrpL0Xn9GXjRJC5b1bvRdFvLZ5k=
Received: from BN3PR05CA0019.namprd05.prod.outlook.com (10.174.64.29) by SN1PR0501MB2079.namprd05.prod.outlook.com (10.163.227.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Thu, 2 Nov 2017 21:16:36 +0000
Received: from DM3NAM05FT039.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::207) by BN3PR05CA0019.outlook.office365.com (2603:10b6:400::29) 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, 2 Nov 2017 21:16:35 +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 DM3NAM05FT039.mail.protection.outlook.com (10.152.98.153) 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; Thu, 2 Nov 2017 21:16:35 +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, 2 Nov 2017 14:16:34 -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 vA2LGVqp004499;	Thu, 2 Nov 2017 14:16:32 -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 vA2LGTB3044617;	Thu, 2 Nov 2017 17:16:30 -0400 (EDT)	(envelope-from phil@juniper.net)
Message-ID: <201711022116.vA2LGTB3044617@idle.juniper.net>
From: Phil Shafer 
To: Andy Bierman 
CC: Robert Wilton , Kent Watsen , Martin Bjorklund , "netmod@ietf.org" , "Randy Presuhn" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <44615.1509657389.1@idle.juniper.net>
Date: Thu, 2 Nov 2017 17:16:29 -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)(376002)(39860400002)(346002)(2980300002)(199003)(189002)(24454002)(6246003)(53936002)(356003)(69596002)(106466001)(189998001)(8276002)(8676002)(2810700001)(86362001)(4326008)(575784001)(68736007)(236005)(97736004)(50466002)(105596002)(81156014)(2906002)(81166006)(8936002)(50986999)(7696004)(47776003)(54906003)(53416004)(7126002)(305945005)(46406003)(97756001)(1076002)(23726003)(76506005)(478600001)(54356999)(229853002)(6916009)(316002)(2950100002)(16586007)(5660300001)(77096006)(512874002)(299355004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2079; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT039; 1:T6tWoSXShtFmGVeaOsLKXwQN0cF70SexGnpKJQytgNxj95b38keGQZ3i/FJbl2IevoTahd3Ekj0HfCcclMAh0g9ixFhOAKHkBqH6iDJ4bAo3jp/hSVxJS53K4jwgggkK
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4e427515-304f-4c39-58de-08d52236ffb1
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:SN1PR0501MB2079; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2079; 3:Fh9EQcKJ1/I9f7NgdbWzGeIvgk+bu6TGUEQqzZzrP8OyDaoKjMtvd7O+NDJE4EQ2z/TylYIleIBb1BhOyGfhr0Qd5n6OIIiR2mXN5nVAzDAqoXcv5m7ozasois8pqoSytGFPk6EIZ7NNsOEtulRg7yBdac2xn3ZSzN4L613wLLpcZ9jVkfNdyYkjIFeSiZ17Yc1isEQhWRMYuRHHFXQ6zQCh4AVs7FuM5nI3dZxWXiijOoTzaW5PD4EGkoUqdEmWz08vDOXC5axeipwBREiXU29z3G7/pDLvem3is+OM2pagXTCdJ4rLvS7VcGpG1MW4Rjc+l5MJhlD7K0bPSOiQaJBjWMh60n12O0zITtnekXs=; 25:Dt9ct6fRoxOMRmAdEZfeN2DUIXHZzj+51YOMGS1mX8EJwZKrYj3nzjiB6+rz9nc4mYP/BN2jMbqe2xzfkSGpMswOI8g7/81SU95WorL2tOUKrfxxDR6R/bJIjcoslL3KnBLE+aA+woEt+G0rkSMPRZS4oiavKzWukmWVqCtrhwibXM7Deh4tfFKTB6qxr2ex2T1l7+72p0HhrPyYDo1b6mDZrQPcOB9nnXUfeNksOk9V4bNDPZR7G5aYzMoyJFCszWzmTctUdDV/c0okUK87tHa7mJDk3GzDkcyn4n3jfYbHao6UuixO4zPQdPh6UDPD/mt+c3g1DzRopTwidSXulw==
X-MS-TrafficTypeDiagnostic: SN1PR0501MB2079:
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2079; 31:BL39uCadFe6R61It/xQ/Mlhs/DIvN5a+TBSHIZWKp2B8NODjXB9b0rrIm52pTZ9kgu9k2IYj0YJqh+UuN1zPxm5yGuPglY8ZHer9njCkm8YxwGOZnXAVdTC3JJhE4s3fxupXI6Tb9FCxM0M02Xep/BewO4xYzDtwok1YzmzWhpMJiqsCgYDADKIDgA1MByp4bZ8udsM1ymV0q+Os5UbbUeqZhIacffMVbnVZX9cVspU=; 20:my7UZur7qhuvJuCYidbeiwootG8ODi7KYMJHTDDAKyHjpPZ6IPpvuEB0KIa35tWNLxz2qGhol1wdqy8eFTsDz8jJlbScrWOTbsbfn5MoYzY8sx8TI+wp9yzgGsxuFFUJ5sqTB4ADwx735EFHYLTBPUTl/tguFyZHYBxDFxLkYHFjYggHzFtgPHWRnkyVpQbzO/nT8IaMMpy4f7YsK2UGixGoTRaC0uAbjMSMzaRPYVRBrL7ZHxPzjzHdCYujYpqy4clDMHl7Pbjg6XJGb3g/raMNMQXLRct7hzz4/Y7OtwURwbPkIHCWzE/dY/7gvB1PX87NHCO18OwMGmZLdNBFwhrmGdgAWWnLt0vBJtI2X16SlEIyota0wBgwrhpF/PlUoDIPxCu9ZwMKR+YW7tZ+xKSawLjSX3ZPr8BriZ6XPnnOOehHvL/v1B90nb9J2TKoGNq/KDymf9fKt0vjPrVI4jDLlZpRqYVhyLGp5n/hAoM46eTprub68fC2E/7XYMJC
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(138986009662008);
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)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0501MB2079; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0501MB2079; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2079; 4:CzTfXDZMjpH35pXuHHXiuQRV/uzIHbvJN8l95+nCbiv5sBBa/VCMPcP9E9xyoagZOqaXVl3NpIU2an9nz3fGsbAR2h9V3Gf9EzDYA+chIh8++q3CnPEpr+4UzI840/bcqiDK0CA/sK04faAvNROLGj1SDCl+GX8R0znsIFQtmsanCatv6xvFPORjw1mYTc51WKD5LTcPg4wddom48FRcg9m+naY7XPnqvt/XU25XtpoF4GbXHv3jPcwr6busfJlcy3vgAWNYTnca0LxnsvHpAbSQFOyICE3+txOOIlb760FhI+e50ykikUssS44HK5o/uFRnajkAk6vjWi24mUaeySa0zIcwbP0z4GsYniqzBvQ=
X-Forefront-PRVS: 047999FF16
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB2079; 23:GJn03fAMY3Cunf4QDnorX/7It4rGsgdF0d4kA3i?= =?us-ascii?Q?yhUA6rySy6wKyTRTH0yzTw9UHc0fbnNSkSs1fBZerjH9dtZqSQud7Kl/Zp8b?= =?us-ascii?Q?efxvS9pNCjLkFmZ0Hr8bQjJgPsB34ps/LGe7vd7dhLpz5D1mLfENhIEPjcRF?= =?us-ascii?Q?aMTp6bwkoqUA5dh2IVEQpmyuj3mvGHnIGyqz6/2vfZ1fdSVrCLq17sYojil/?= =?us-ascii?Q?CWr9NV/JdgwEP3+bs65V9dW8umoUR91NSZvZjL4xC8w+sCyrkuCoGGwczo1b?= =?us-ascii?Q?d+Xg1o0MssoVXj3s+AUL42QD/2KOfZqxpiptanOfCNCmt+IHaZYAIYWbP/CO?= =?us-ascii?Q?SR7DtVqV2DlUtCTRd0eLH/tMmMFJlyCdNNEh6sVfg3JV8NGMZVe4VMARNl8c?= =?us-ascii?Q?wN1AWbgWy1wCEalCCdpuJtDCPSkflICbyuaebKEryOvmf2LjwsVl+5ePqBpg?= =?us-ascii?Q?YimK8aS9Vt56tFWVWQRZUGocap70oDIwDdxzyP/7ixNObNxDbX/LvqjotRbt?= =?us-ascii?Q?MZR2qwJnX23kf3Zo0Y3fUOhFWsmM+54HazPI8GJdq9oKQHWQHJH+8cPunU5I?= =?us-ascii?Q?HcVCmIr4nfYs7SBYilwkWCn8XnO95VrznvmBo3n+piKYtNOzzdtspIm0GOF3?= =?us-ascii?Q?84yTv3es+MWstttU++n0I3atgEfOuwYnS1n4qwMybP9nPgNOoOj7EJUSmCtz?= =?us-ascii?Q?NGuLlA5odj0JoBMH/NqN0zlG4TQg/NxyKDOmns3/OURkboeDUo50T1kTYmvb?= =?us-ascii?Q?vAxuPVGKGg4nPCoF3MofCSSaNHpyqNCOZ9cxnA+nsBU0n1tAhToaE3laZ6xl?= =?us-ascii?Q?KjE0lPJ2WS7oMgevM8qWWwGSt4rU209+SJ48tQQAmZHW/m90NjXe+tLbojmK?= =?us-ascii?Q?5s0gMkh1mMHeCEeMSJHoasxOrVC1zR0ASqk/yXPGEFBSvB6Z5d/TwjE4XUsU?= =?us-ascii?Q?bfczWvmczWIYSYBetgD3NEMtVJq+oRvOGEkl1NMLj7jgrvoW5qD7HisaSj+T?= =?us-ascii?Q?r4YfL9mx5V392lS9Er0sGeWSs6uJrIircSxg0+/zEpj2ZN2qw7DfPk1WC0vO?= =?us-ascii?Q?0k0qeGprwFOvfkSwakOwRRy2tdKEovv2JZYiJT5CG2aZV5SjI6tpNqU0JLDH?= =?us-ascii?Q?4iymJq+vc/7L4BLOLud8rCmMNtrwmcAjh7AdaMHLw7vUDDjnRm3LnEEiR0ey?= =?us-ascii?Q?OQ7uyuRVoKMswlWT2ZUV5oZe7C79oMdGOzonEqphjRJVJM15j5DNTwNa1OQ?= =?us-ascii?Q?=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2079; 6:ejRbdD7Vf0i2QlpPRAvao7rl3EFbgBvXh1k7nHHOrvTkPv3t/a80ldmmxzmYpfi/8RibbW1LQ/plYfu0HgtX83kB3Bx5pv/qsVYZlGzCtPQ6ObK06RpLHEy51gngc+W6b3f6ROEA7kvQijt23BXb73zexc4p65boLnploBSrbpmv94J0GlhYqOKfu0rXwK4RZYmdWMQSVcOvDjqENVz8EOnzxyUx3CleSNgb3yJPSM5udDZoVDt9qKFrD0ZhwAg0kg2jcJ6bQBAUwjxjpbmBqHzOWruZfwd77Fi+JGFHHNQY+5wo9WwRwFKIoV38rBRDElrj1i/XA48xWGXPdvXQoKDtRJzzQTNlHM+IzETIUqE=; 5:FYPVL105+EAuL5HwUAk+JqBIADuMrcz+RL3RxoOLJ2XQ5LDYkpzk39AZMk2sgBwB5u3GSaxAekWd9zMUZ0QjlmISU3ksJV2K08eOnRRNXrRx2qG4ngkk5Dvpa//17lg6zll3Ilsqh8d3gImYa50OjHKCRZO/EFDaaXaJhHx2GgE=; 24:J2OSf0PwvdtCzztAqZgSqwN3s5r4wXXHMlrZItOJ1qtaKWL+QTmjHD3akntl+uPbjhphTXjuAkEKz837+yqNqiP8ykPuIZJNJzMJJuXpibs=; 7:Hzw68dGLEDgbJFLAT5QsIMV5FDKj2UWxblQws5WIyxYJx+YPsZi1XnTbrm36CIuSGykMqSTr3YUUFs24j//z7CngkUK5Vrk3MO+v9VAN/m6F+b5tixcjJxGERSvT1ErZKR3QQlKc6X9nHjzg4GoW5oziuYejLpDC3gxuWk+zCzGZY2ze/ZAjpUUNlfDcZZ6YBvz3rUSIcdXcBZNfp10sNU+J3t4hBP9XduR0IjL3uC8+61Ion4FXx8kB9bDQnpU1
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2017 21:16:35.2899 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e427515-304f-4c39-58de-08d52236ffb1
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: SN1PR0501MB2079
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: Thu, 02 Nov 2017 21:16:41 -0000

Sorry, if I wasn't clear.  I meant the  element would
be directly under , so the system knows where to start
looking for data.  Guessing is bad.

Thanks,
 Phil


Andy Bierman writes:
>So a server will be required to guess the correct datastore until it
>finds the right one that matches the action instance?
>
>   
>       
>          
>             10
>             
>                candidate
>             
>          
>        
>    
>
>The server will guess the datastore in some proprietary order and parse
>instances of /top/ and /top/list1.  Then it finds the  action
>and parses the input to get to the datastore and find out the real datastore
>to use.  If the server guessed wrong, then it reparses the  against
>the requested datastore.  Hopefully the schema trees match up.
>
>Will vendors do all the extra work required to support this sort of thing?
>I doubt it.
>
>
>Andy
>
>
>
>
>On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer  wrote:
>
>> 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
>>
>
>--001a11411b0ad2d58d055cee96cb
>Content-Type: text/html; charset="UTF-8"
>Content-Transfer-Encoding: quoted-printable
>
>
Hi,

So a server will be required to gue=
>ss the correct datastore until it
finds the right one that matche=
>s the action instance?

=C2=A0 =C2=A0<action>=
>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>
=C2=A0 =C2=A0 =
>=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
>=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 =C2=A0 =C2=
>=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>
=C2=A0 =C2=A0 =C2=
>=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate</datas=
>tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</do-=
>test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </list1>
<=
>div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0 </a=
>ction>

The server will guess the datastore in s=
>ome proprietary order and parse
instances of /top/ and /top/list1=
>.=C2=A0 Then it finds the <do-test> action
and parses the i=
>nput to get to the datastore and find out the real datastore
to u=
>se.=C2=A0 If the server guessed wrong, then it reparses the <action> =
>against
the requested datastore.=C2=A0 Hopefully the schema trees=
> match up.

Will vendors do all the extra work requ=
>ired to support this sort of thing?
I doubt it.

iv>

Andy



iv>

On Tue, O=
>ct 31, 2017 at 11:36 PM, Phil Shafer <o:phil@juniper.net" target=3D"_blank">phil@juniper.net> wrote=
>:
ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

>>ii) However, as far as I can see, it doesn't make sense for an acti=
>on to

>>directly affect the contents of any configuration datastore, that shoul=
>d

>>be done via a purpose built rpc (like edit-config).

>

>An example action would be to retrieve the=C2=A0 fingerprint of an ssh

>key.=C2=A0 I might want to get the fingerprint of a key in <candidate>=
>;

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

>

>Seems like <startup> 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?=C2=A0 Any specific RPC can define its

>own datastore leaf of hard-code the database in the description

>(explicitly or implicitly <operational>), but the <action> RPC =
>only

>gets this if we make a new parameter for it.

>

>Thanks,

>=C2=A0Phil

>


>
>--001a11411b0ad2d58d055cee96cb--


From nobody Thu Nov  2 14:31: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 7413313F9D2 for ; Thu,  2 Nov 2017 14:31:35 -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 RYRh6sZuQSHK for ; Thu,  2 Nov 2017 14:31:33 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0134.outbound.protection.outlook.com [104.47.42.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 ACF2013F9DB for ; Thu,  2 Nov 2017 14:31: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=JxrT4KQh3igPe7QC8S7sFnFaeOmEcJqMOmCtOi4q6BM=; b=OXsKMGiCLVioQ3L6hjgUnYi6d1kg6/xedZCKPpx/LL7+5kmJwj9ZeP6+ofUfIWr0i0aNUdDEkXAu8KAJtUe9YPzA1I5mMgJnrpWdXO1IxfZhEGtrQCLFOqAZBOSEFfwiW7hmwtIoeQXmHvRJXkUWUnPB0szSzeRaI/P5zR3EL84=
Received: from SN4PR0501CA0080.namprd05.prod.outlook.com (10.171.32.146) by SN1PR0501MB2078.namprd05.prod.outlook.com (10.163.227.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Thu, 2 Nov 2017 21:31:32 +0000
Received: from BY2NAM05FT041.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::202) by SN4PR0501CA0080.outlook.office365.com (2603:10b6:803:22::18) 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, 2 Nov 2017 21:31:32 +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 BY2NAM05FT041.mail.protection.outlook.com (10.152.100.178) 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; Thu, 2 Nov 2017 21:31:32 +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, 2 Nov 2017 14:31:30 -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 vA2LVS2F008558;	Thu, 2 Nov 2017 14:31:29 -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 vA2LVRjs044715;	Thu, 2 Nov 2017 17:31:28 -0400 (EDT)	(envelope-from phil@juniper.net)
Message-ID: <201711022131.vA2LVRjs044715@idle.juniper.net>
From: Phil Shafer 
To: "Sterne, Jason (Nokia - CA/Ottawa)" 
CC: Robert Wilton , "netmod@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <44713.1509658287.1@idle.juniper.net>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 2 Nov 2017 17:31:27 -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)(189002)(199003)(86362001)(50986999)(4326008)(54356999)(7696004)(6916009)(478600001)(2950100002)(7126002)(68736007)(53416004)(105596002)(106466001)(8656006)(23726003)(53936002)(1076002)(50466002)(2810700001)(97756001)(5660300001)(6246003)(76506005)(189998001)(46406003)(2906002)(77096006)(229853002)(97736004)(8936002)(47776003)(54906003)(81166006)(81156014)(8276002)(8746002)(356003)(8676002)(316002)(305945005)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2078; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT041; 1:NFNE4j++ISiClmLCJ59UZoC6Lra0iH/3tGE8ZnD3gIQCXHCLSdWxKyXo3o6uNOzBE7+g5XRsqp6tGC1VD9rVfIORLlg2h4dVYwG0dKqvd/9+HwNieOTWyZR2ZfXSstqB
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 329354b6-45bb-429e-37e1-08d522391660
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:SN1PR0501MB2078; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2078; 3:Hb4J45jeGEjouFGLEQKQuRP7cHOrWJIyfgNnUoYRjm3fE9U6OY2ZDwS9mwAsR/rps71wc3I56sPo+tJrHupSxXD7SQgDgLbpD7y6E3xQOJtIx9Y2AggRbpKF74k8K1mqszUE1cObR64RRMW0TU2M2O6esUkCJsXaDqehnOY+I/7Djh/Qi/F4J0CRci/Q6RYLPjGBn0vnzN2VcOeELJSHSmimSpVd4VNrgfh0ySmGNk/GBpwAw4g/Bvoy0TjtAtYL88ezdRMG0K08sBrAmc2Ht7x77k4mbsLR/ZqMuRFUNf8bopcSucbyLjkQSMSk+1Lj124XGd4sLaUQqRyiyx1Jj4P2S0vbQ1WH1kFCtkDNLe8=; 25:yNJTxSXMda1+2n7FKqBw2h/VK9xHHPJqhrtc/bvry+YQqdmfG3h8zt1z08m0UIfMJUpyP/VamtYCQf7KtU8F7jDg5XczZHVW1GNqrBhrmBz7JbJt4DZx+SUYGkk7KSRxhHp5DhBSJRe8f2L529Lkmg6yAzh7Fcj2SRIahXUVNvBPlFKi3e/WGIayOp944ryaH86WxROcIzxxxh1uEXHHHHUSK92gTt4X/5f/mIlXSpHWfKIwo1vM2bYhjcLMbjAw8s+NBV4CrHPvaT3Rmq3rWhRw32nlmZAAf8byULdGFsXU0FHBfn9RvMiOsFj9Lgp5MBeYCcMP02dr2nR4YZrfEw==
X-MS-TrafficTypeDiagnostic: SN1PR0501MB2078:
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2078; 31:xdfneZSBIoeiHQfyJN9qxxzkdquOvu5PruId0Bd3AVdtl71bXtPk28w4S2iPU6o05rnB+4pawlyXziZWeg93g+AQnvP/erKfvf1HcmBLHwMUCT+QiXi6jBrVX5jbayKe6Iyihi4FbQgszEihK7lRWLcPYGVK6gfZET67M1emPuUaJ6BmD1ZUFLTfIDqnFe/lmP3LbnwBu75/Wgfs3vR9emMK9W+OmsPr/BE95H+CGME=; 20:Yu5jfAqRwReoHGEwRA5YdORktKXXwhBqpEVm7SkpiK0fXSxM0misiInnYFtSNqyjSQPsyosEd2YrLcEofH6Pzz/AaHwF9vGAVumeHQwIpc3qYtYIKOuRaiG5gZOSmuY5rcP2wSQFwrJygA1HcZcCL5dXxeGjg58o8RGoExs4WCaI9NhSmdYdUabQlJ+VMMTs3hiWgw5mtKQoZa0kKMvmIClgw/sOjOAL/5lwtJTYvV6yKGXJgfZ1nd8+cx1uI8267fTJdGVswN48Mlrj5ssMG/L9THOH2x3s0VAPWXB9SNvaG4+nnqARzoW7L0AGjs+2HIsQ1bX1wzSfPPIY3F69oV05ao0lCPC0ZHPLKNyCGlSmt2v8r5dfMoKdfFQuTWV7d/ToUHqFWAKZ/hLaiTY8qOh6hdL2N37vmJgNSdZfKl4rvgEUVRgnnhZyb0jh0JGqB/O3P6NO817/H+RMqD3sr28qFVzPd/w1IScGdQxx5GmmtDlYcQUZXAYmZa6eNDMi
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)(93003095)(3231020)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0501MB2078; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0501MB2078; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2078; 4:yRGny1qqp55XrjQkzQs7+3/7527mMxybxBPdqQCY0UoZ1jQ6TSotrYZAELhlEzfWLPGzXIsnliI49zFWlZZuOnJ4Jhq3ndwfea2DcIMUrVP2SylukzreUqNhbvpXGrNGJOUQfHhoSHueG9mR0n3Uifl4pbKIpLyFfyssryInN1gGaen1E6DPABLt9XXArFSlSHDqNzB45kGbkP03lcBrcVmuuTJ/PyqQoiDDmhapDfkayp1Bi+razDmWFxEYWBlJQ18rmT1qKv7BEWMmlZlQHA==
X-Forefront-PRVS: 047999FF16
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB2078; 23:Q9sAfKh04fIKHP1ZEgYhzVCSgGQ18Z6lmSoZHps?= =?us-ascii?Q?pNvnMsfLwuUPXacZCmXs7OWQ7PUl+p9pudCqHMtCmNk/shdPucnMN+1enpnU?= =?us-ascii?Q?WF080xbDpW0B7/l8KYLiJQyZ40XwiLJE5k3HjQ+h87eG65pWisDeF8N9xFW7?= =?us-ascii?Q?o8++47eq5v7t0J874+pzANgeqQHxChxom7FdR3J+krV437Yb3DnfDU9tDUuz?= =?us-ascii?Q?5nrxtn1ghHmYjddmVv4blRbCt9kP2rvhcA23lENXYtZsrSvN9YEsjQoi7XSW?= =?us-ascii?Q?1LACoMw159j/n2VzONpFB+vyuT2L8fRBnUEMyAtGGTSbhQDhmljoajEl94nh?= =?us-ascii?Q?4EgD4gSqgMOWIIRWmiG1BDH4a7pTYee2dwNORv7kzcs19FoIkbIe3b6jz14y?= =?us-ascii?Q?IT3YDDDw7VYUkPgMlQCZs4f1dwf0Rfoce1j7VQuDLGz+0BNZx2Yq7sSltkxl?= =?us-ascii?Q?WzRoBdgG0GBrvxFbqmd5L9Xkte04l3V34Eqp3ucuNC8ZvmS16+pL70s5Zex7?= =?us-ascii?Q?9oPwGxUddifip5nOcebRuJF//zHvqPBZHWza9fP9+joZxBOBMqcLTgjATSb5?= =?us-ascii?Q?cO0qBozR1yJrcqudT3sLd54EIVGu6eU8eMHb/o/+6Pd3bIEK5ofBGIIbO7AF?= =?us-ascii?Q?WYBeLtwEOi1yo9Q+ASL8qtt13/kQahDFHZVS+0hSQGB9GxE2lSNUTZktfL9Q?= =?us-ascii?Q?ucCHsV8jSl3rQ5+TCr8g0Xvm29d73O1fRXoWFOZMwFuxpBb2dPOhKdTou4PM?= =?us-ascii?Q?pHbCZGTIpTeGbUFWi9kS6Mvz1Moc3tvU0H/g92Ve7iLmrlIzBHo3yCR5C4UG?= =?us-ascii?Q?QkQLoN2QYTjIk2OjXUP6v4w7c1M6YZPRMYQTtsAdenBu1QyQPXgorb8SGkoR?= =?us-ascii?Q?Ake7+TcaGUjuuoxQ1VGKPMYoqI471SC301O3S22h2FCAuw0Qh4xdMuiRfjmR?= =?us-ascii?Q?695myrRKApsJ+pERUbvoWWY+kyb6RN6L0/4WYlGQrMD2EgMuCpk9Ng15ueq8?= =?us-ascii?Q?yGRXUDdlSAysaruJVpsT82PJY47SG2BRsrDEcGnQPZH8re9n1Imf0/ThtMu6?= =?us-ascii?Q?O7eio6HhC+WlzUvcnLJaziqvW/9zOloA3pmP0ewKAF1imwrFcRIAUuABHj3n?= =?us-ascii?Q?6tzPsmoCYW90=3D?=
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB2078; 6:O3s5ky5H2xem52Wmw03qD5WMeUmIsLszP9ndwNeAiDefOBwdlr4BotSPrvrcg/zZYC82MPAE71vjkBQWAQybZa+ReNvgKb6cliA9iyZehYktBB+44EYrpDeneJ/L9qWU9uWmP0fmFrFT6Lp0tkR7ilhL2XNC0wQDC06MoaS5RZpa2o7RAdh1ZAgCvA9fcX06L1nDY0Qt3lkArTZ0nopK3zKer5dcjEKrV711NhtDupq273JhHvd7DDbl25pRxkJVzZVtiYbnrKuU+w0mMJb5vq4LVkrdiLL9/DeUlui+Mo9kigAyyrbTad9461zuLN+hNZuiFN5t5nBR3zRRzC5+jRKq59/W+hiQRpGbciFNHEM=; 5:a2j33qc8q1gjGJSdDjgMBF6UWlP/myjUttIZPDlbAOhixoFkgvkCMHPbTamPIXltLYyE+Bep4mCsKnRm6uD4pHqCxOxpW/hoBf4QCv28olOtr6d/+/gteCQWqat0QJfjf/RELyC2Gx/7PVvYc/j/ZKST/7EtTZidGq6FNXqER1g=; 24:MeVauPa9ubKoLG8iA9PSAtmDtqa72YGBhFqvZBgoXdnqzMBarSLim3offTznUJXPBbQQucBVvToTgBedYDII85OYtthPBm+7TXHUCjtWDyk=; 7:LzdIkXMUK2DhThXRA+O1It+C2fSIt5deVLVvoMcXgwcpj25aDTWfS6fqRefXelSBJm9/L2wM8IJBtwz1D9KGSsXx2l60BayDEBGqGpGiQQtZ0vlvfHerrX9HuqL8qjn9E513VImOnDd+lsdZYJvzc7WFhMYf29/MYeErpOEPMQ604yn3UQr9hn/MY6CrPUYxhxVbHlHZloomtNVqobyIhkPbuTWUk74+crDJ67l7qqhO4rHSLyX+ZTHurRC/1pII
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2017 21:31:32.4318 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 329354b6-45bb-429e-37e1-08d522391660
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: SN1PR0501MB2078
Archived-At: 
Subject: Re: [netmod] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 21:31:35 -0000

"Sterne, Jason (Nokia - CA/Ottawa)" writes:
>The  DS needs to have both the template itself in the schema as =
well as
>whatever nodes are used to hold 'exploded' data.  But what about intended=
 and
>operational ?

For JUNOS, we carry both the raw and expanded views, though nothing
in JUNOS is looking at the raw data outside of the UI code.  But we
carry it, so that scripts can access this information and find the
original "intent" for config.

For example, if my interface template looked like:

interfaces {
    apply-macro so-0/0/0 {
        inet-address 10.3.2.1/30;
        role customer-facing;
    }
}

and then my commit script turned this into traditional JUNOS
config, like:

interfaces {
    so-0/0/0 {
        unit 0 {
            family inet {
                address 10.3.2.1/30;
                filter customer-facing;
             }
             family mpls;
             family iso;
        }
    }
}
protocols {
    bgp {
        group customer-facing {
            peer 10.3.2.2 {
                local-address 10.3.2.1;
                policy customer-facing;
...

And whatever else "customer-facing" means.

Both sets of config will be in  and  so that
when I find an interface that's down, I can look (in )
at the original apply-macro and see the role of the interface to know
how loud an alarm I should be raising.

Thanks,
 Phil


From nobody Thu Nov  2 14:31: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 5E42A13F9D6 for ; Thu,  2 Nov 2017 14:31:57 -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 XGPEXCwbcFFA for ; Thu,  2 Nov 2017 14:31:53 -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 46D9613F9D2 for ; Thu,  2 Nov 2017 14:31:52 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id k40so1011828lfi.4 for ; Thu, 02 Nov 2017 14:31:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lySuCP+IQpN0xUK2Nmn9oBxmNfcd5tI/pvuayiniAOI=; b=f1hLNc8n+lkgFdV68/MWO0MEmniSDjbUpn5WjiYoFm/VOcfjE3qpOppWAfzIbgp95x c01PvGUVirD0oR5yX4f+/c1bvwr/s8HSXj+e3DF65vqvIVg5ct4g1bFzgU89W8X1yiHg umwdlHBT0V4EV7EAM84oqCpo6LL1+ZHRp0seArNrQKlm+qwrHR70jvyfFM2PKjidX1Yp z3EUVg+CLoFIRzG1XxXMGOWo4nY6AwU0B+vBBnMZSd9u6MUwlJjvY9VaPYKlHnlZGgU2 6Q2lRQtyi5G/zqxFa9oep9C/kxdovfQcmvhdYfnpj/Jh+BZJGLwr/lQ3R9nUaYmd6Ouq rW0g==
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=lySuCP+IQpN0xUK2Nmn9oBxmNfcd5tI/pvuayiniAOI=; b=gicX8T0+BTGyzBnr2R6PExejCii5JZ6eCe7oZbjcWkcytIwFfmn5o6lPHpyd8+sRP6 4CEaXjbqBsfPBML2+RwgQoSmar4tOC3YnNvwfJc5NNDiVIEa6Jgko3d8gtvjNZww6ynL ke0Cvt07kHruDSdNOv4KjLvKwV3q0K3wIFaZ3rsS9hRp/uLvRUSjTP7xR/dBgm1KZ2Kf sAguCAIzz/jHg1d9m8g0iLuYljDB1q5nlwIuEQVqGUjdwNeK7JLm4xJtO4dHpxr5x53r 5WCMRBvyKxNOwbKtrpw5qu4XmsNvmeAKluitbwuK0J9tUELuBFXDEeODp44x9AQDUsV6 Ry6A==
X-Gm-Message-State: AJaThX7XTVlWOVZ6UAgoclCiaY34/EnsRhW/AUA3qCTSP8BWKEMGbMxZ P16FIEXgAcWL6ogWkgW0yIGmtMscter3JBAwo81CRA==
X-Google-Smtp-Source: ABhQp+SDilI8LX6GaLYTE/QWN3lr9lemNv/WyNqufhGUwHVLgUwCc7aAfl7meOQiA9WNBAq5KXuZvvmi4xLXzsO1ekE=
X-Received: by 10.25.156.66 with SMTP id f63mr1751465lfe.194.1509658310448; Thu, 02 Nov 2017 14:31:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 2 Nov 2017 14:31:49 -0700 (PDT)
In-Reply-To: 
References: <076270A6-B2C1-44BC-8F02-F4E96675E76F@juniper.net>   
From: Andy Bierman 
Date: Thu, 2 Nov 2017 14:31:49 -0700
Message-ID: 
To: "Sterne, Jason (Nokia - CA/Ottawa)" 
Cc: Kent Watsen , Robert Wilton ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11411bc653ab38055d06b772"
Archived-At: 
Subject: Re: [netmod] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 21:31:57 -0000

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

On Thu, Nov 2, 2017 at 2:12 PM, Sterne, Jason (Nokia - CA/Ottawa) <
jason.sterne@nokia.com> wrote:

> Hi Andy,
>
>
>
> I can=E2=80=99t think of a specific problem immediately.  But I think it =
means
> templates would be considered as =E2=80=9Capplied=E2=80=9D always right ?=
  Or do you see
> cases where templates don=E2=80=99t show up when  is read ?
>
>
>


The operational value of the template would be read.


> Special rules are likely to be needed for validation though.  A DS (with
> templates) won=E2=80=99t be valid unless you validate an exploded view.
>


In our server, templates are valid YANG and there is no problem at all with
validation.
It is very useful that 'anydata' is opaque to YANG validation.


>
>
> Jason
>

Andy


>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Thursday, November 02, 2017 16:58
> *To:* Sterne, Jason (Nokia - CA/Ottawa) 
> *Cc:* Kent Watsen ; Robert Wilton ;
> netmod@ietf.org
> *Subject:* Re: [netmod] revised-datastores and commonality of schemas
>
>
>
> Hi,
>
>
>
>
>
> On Thu, Nov 2, 2017 at 1:40 PM, Sterne, Jason (Nokia - CA/Ottawa) <
> jason.sterne@nokia.com> wrote:
>
> Hi Kent,
> Yeah - I realize that I'm jumping ahead of where we are.  I'm a bit
> worried that we're making forward looking assumptions that we'll be able =
to
> stick to those constraints that we're defining in revised-datastores, and
> we may find that difficult later.
> For this specific issue I suppose there is at least the possibility that
> we *could* have a common schema (and have operational be a superset).
>
>
>
>
>
> What problem is caused by having a template appear in  or
> ?
>
> If none (appears that way) then no special rules are needed for templates=
.
>
> What if I have a special RPC to override part of a template, so the
> operational
>
> value of the template is actually different than the configured value?
>
> Since it is all proprietary at this point, better to leave templates for
> later.
>
>
>
>
>
> Rgds,
> Jason
>
>
>
>
>
> Andy
>
>
>
>
> > -----Original Message-----
> > From: Kent Watsen [mailto:kwatsen@juniper.net]
> > Sent: Thursday, November 02, 2017 16:31
> > To: Sterne, Jason (Nokia - CA/Ottawa) ; Robert
> > Wilton ; netmod@ietf.org
> > Subject: Re: [netmod] revised-datastores and commonality of schemas
> >
> > Hi Jason,
> >
> > All those details would need to be specified by some future templating
> > drafts.  In this draft, there is only the provision for "configuration
> > transformations" to keep that door open.
> >
> > Kent // contributor
> >
> >
> > --
> >
> > Hi guys,
> >
> >
> >
> > Templates are something that may be problematic for this concept of
> > common schemas across the running/candidate/intended DSes and then
> > operational being a superset.
> >
> >
> >
> > The  DS needs to have both the template itself in the schema a=
s
> > well as whatever nodes are used to hold 'exploded' data.  But what abou=
t
> > intended and operational ?
> >
> >
> >
> > For example, imagine we have the following instance data in a candidate=
 &
> > running DS:
> >
> > 1) a template that sets an admin-state leaf to 'enabled' in all
> interfaces
> >
> > 2) a set of 3 interfaces with a few leafs of config in them (address,
> etc)
> >
> >
> >
> > Clearly the schema for the candidate/running DSes contain both the
> > template and the interface schema nodes.
> >
> >
> >
> > But does the schema for the intended DS actually have the template sche=
ma
> > nodes ?   In theory it doesn't *need* to (since templates are exploded
> > between running & intended), and it feels strange to have those in ther=
e,
> > but I suppose it could have them.  If they are there, then a read of th=
e
> > intended would show "admin-state enabled" in the template *and* in the =
3
> > interfaces.
> >
> >
> >
> > Does the operational DS contain the template schema nodes ?  If yes,
> then I
> > suppose we would consider all templates as 'applied' implicitly ?
> >
> >
> >
> > Rgds,
> >
> > Jason
> >
> >
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
> >
> > > Wilton
> >
> > > Sent: Tuesday, October 31, 2017 10:01
> >
> > > To: netmod@ietf.org
> >
> > > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-
> datastores-
> >
> > > 06.txt
> >
> > >
> >
> > > So this version of the draft contains the small change that defines
> > "datastore
> >
> > > schema" and describes the "datastore schema" of  as bein=
g
> > the
> >
> > > superset of the datastore schema for all the configuration datastores=
.
> >
> > >
> >
> > > There are two remaining issues open on the issue tracker
> >
> > > (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__github.com_netmod-2Dwg_datastore-
> > 2Ddt_issues&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DOh70ToB2vUTvtf
> > OGlJFxq9b-VdJvIq7Nw6S69fNgcTA&e=3D):
> >
> > >
> >
> > > (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 Architectur=
e
> >
> > > >          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 th=
e
> >
> > > >     initial simpler model, addressing requirements that were not we=
ll
> >
> > > >     supported in the initial model.
> >
> > > >
> >
> > > >
> >
> > > > The IETF datatracker status page for this draft is:
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised-
> > 2Ddatastores_&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DkntbgpHJnrByHY
> > nP6-gIQawFyxzuB4qqA8a7sJ73Yro&e=3D
> >
> > > >
> >
> > > > There are also htmlized versions available at:
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores-
> > 2D06&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3Dl8WerMNvfvgZVJ
> > CnIEqxPofbgMz_Q_EzSiIoGbCQgNI&e=3D
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetmod-2Drevised-
> > 2Ddatast&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DWCuOo1niAkysc
> > QUKzIYmTuLvajFh0jn8MtmRmc6jjho&e=3D
> >
> > > > ores-06
> >
> > > >
> >
> > > > A diff from the previous version is available at:
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetmod-2Drevised-
> > 2Ddatastores&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL7nQJMiX3M_yX
> > LSwPASZefUdW7YmA4ly9MiocXVGh40&e=3D
> >
> > > > -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:
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dftp-
> > 3A__ftp.ietf.org_internet-
> > 2Ddrafts_&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3De_mQeyXZbxETy
> > vr0-gcvkPeWqv4mScsFa5ueArTKoQQ&e=3D
> >
> > > >
> >
> > > > _______________________________________________
> >
> > > > netmod mailing list
> >
> > > > netmod@ietf.org
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3DHAkYuh63rsuh
> > r6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQyj_938aVcv4
> > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D
> >
> > > > .
> >
> > > >
> >
> > >
> >
> > > _______________________________________________
> >
> > > netmod mailing list
> >
> > > netmod@ietf.org
> >
> > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3DHAkYuh63rsuh
> > r6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQyj_938aVcv4
> > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> > 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3DHAkYuh63rsuh
> > r6Scbfh0UjBXeMK-
> > ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m
> > =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQyj_938aVcv4
> > QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>

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




On Thu, Nov 2, 2017 at 2:12 PM, Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:











Hi Andy,


=C2=A0


I can=E2=80=99t think of a specific problem immediat=
ely.=C2=A0 But I think it means templates would be considered as =E2=80=9Ca=
pplied=E2=80=9D always right ?=C2=A0 Or do you see cases where templates do=
n=E2=80=99t show up when <operational> is read ?


=C2=A0

<=
/div>

The operational value of the template would be rea=
d.
=C2=A0


Special rules are likely to be needed for validation=
 though.=C2=A0 A DS (with templates) won=E2=80=99t be valid unless you vali=
date an exploded view.


=

In our server, templates are valid YANG and there is no problem =
at all with validation.
It is very useful that 'anydata' =
is opaque to YANG validation.
=C2=A0


=C2=A0


Jason

Andy
=C2=A0


=C2=A0








From: Andy Bierman [mailto:andy@yumaworks.com] 

Sent: Thursday, November 02, 2017 16:58

To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>

Cc: Kent Watsen <kwatsen@juniper.net>; Robert Wilton <rwilton@cisco.com>; netmod@ietf.org

Subject: Re: [netmod] revised-datastores and commonality of schemas<=
u>






=C2=A0




Hi,




=C2=A0




=C2=A0




On Thu, Nov 2, 2017 at 1:40 PM, Sterne, Jason (Nokia=
 - CA/Ottawa) <jason.sterne@nokia.com> wrote:




Hi Kent,

Yeah - I realize that I'm jumping ahead of where we are.=C2=A0 I'm =
a bit worried that we're making forward looking assumptions that we'=
;ll be able to stick to those constraints that we're defining in revise=
d-datastores, and we may find that difficult later.

For this specific issue I suppose there is at least the possibility that we=
 *could* have a common schema (and have operational be a superset).<=
u>






=C2=A0






=C2=A0






What problem is caused by having a template appear i=
n <operational> or <intended>?






If none (appears that way) then no special rules are=
 needed for templates.






What if I have a special RPC to override part of a t=
emplate, so the operational






value of the template is actually different than the=
 configured value?






Since it is all proprietary at this point, better to=
 leave templates for later.






=C2=A0






=C2=A0






Rgds,

Jason






=C2=A0






=C2=A0






Andy






=C2=A0








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

> From: Kent Watsen [mailto:kwatsen@juniper.net]

> Sent: Thursday, November 02, 2017 16:31

> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; Robert

> Wilton <rwil=
ton@cisco.com>; 
netmod@ietf.org

> Subject: Re: [netmod] revised-datastores and commonality of schemas
>

> Hi Jason,

>

> All those details would need to be specified by some future templating=


> drafts.=C2=A0 In this draft, there is only the provision for "con=
figuration

> transformations" to keep that door open.

>

> Kent // contributor

>

>

> --

>

> Hi guys,

>

>

>

> Templates are something that may be problematic for this concept of
> common schemas across the running/candidate/intended DSes and then

> operational being a superset.

>

>

>

> The <running> DS needs to have both the template itself in the s=
chema as

> well as whatever nodes are used to hold 'exploded' data.=C2=A0=
 But what about

> intended and operational ?

>

>

>

> For example, imagine we have the following instance data in a candidat=
e &

> running DS:

>

> 1) a template that sets an admin-state leaf to 'enabled' in al=
l interfaces

>

> 2) a set of 3 interfaces with a few leafs of config in them (address, =
etc)

>

>

>

> Clearly the schema for the candidate/running DSes contain both the

> template and the interface schema nodes.

>

>

>

> But does the schema for the intended DS actually have the template sch=
ema

> nodes ?=C2=A0 =C2=A0In theory it doesn't *need* to (since template=
s are exploded

> between running & intended), and it feels strange to have those in=
 there,

> but I suppose it could have them.=C2=A0 If they are there, then a read=
 of the

> intended would show "admin-state enabled" in the template *a=
nd* in the 3

> interfaces.

>

>

>

> Does the operational DS contain the template schema nodes ?=C2=A0 If y=
es, then I

> suppose we would consider all templates as 'applied' implicitl=
y ?

>

>

>

> Rgds,

>

> Jason

>

>

>

>

>

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

>

> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert

>

> > Wilton

>

> > Sent: Tuesday, October 31, 2017 10:01

>

> > To: netmod@i=
etf.org

>

> > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-=
datastores-

>

> > 06.txt

>

> >

>

> > So this version of the draft contains the small change that defin=
es

> "datastore

>

> > schema" and describes the "datastore schema" of &l=
t;operational> as being

> the

>

> > superset of the datastore schema for all the configuration datast=
ores.

>

> >

>

> > There are two remaining issues open on the issue tracker

>

> > (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-<=
/a>

> 3A__github.com_netmod-2Dwg_datastore-

> 2Ddt_issues&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DOh70T=
oB2vUTvtf

> OGlJFxq9b-VdJvIq7Nw6S69fNgcTA&e=3D):

>

> >

>

> > (1) Sign off that usage of RFC 2119 language is appropriate. Perh=
aps one of

>

> > the proponents of this change could please verify this.

>

> > (2) The email thread regarding Actions and RPCs in NMDA.=C2=A0 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.

>

> > >

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0: Network Management Datastore Architecture

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=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=A0 Juergen Schoenwaelder

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phil Shafer

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kent Watsen

>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Robert Wilton

>

> > >=C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf=
-netmod-revised-datastores-06.txt

>

> > >=C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =
38

>

> > >=C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =
2017-10-30

>

> > >

>

> > > Abstract:

>

> > >=C2=A0 =C2=A0 =C2=A0Datastores are a fundamental concept bind=
ing the data models written

>

> > >=C2=A0 =C2=A0 =C2=A0in the YANG data modeling language to net=
work management

> protocols

>

> > >=C2=A0 =C2=A0 =C2=A0such as NETCONF and RESTCONF.=C2=A0 This =
document defines an

> architectural

>

> > >=C2=A0 =C2=A0 =C2=A0framework for datastores based on the exp=
erience gained with the

>

> > >=C2=A0 =C2=A0 =C2=A0initial simpler model, addressing require=
ments that were not well

>

> > >=C2=A0 =C2=A0 =C2=A0supported in the initial model.

>

> > >

>

> > >

>

> > > The IETF datatracker status page for this draft is:

>

> > > 
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised=
-

> 2Ddatastores_&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-=


> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3Dkntbg=
pHJnrByHY

> nP6-gIQawFyxzuB4qqA8a7sJ73Yro&e=3D

>

> > >

>

> > > There are also htmlized versions available at:

>

> > > 
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drevised-2Dda=
tastores-

> 2D06&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3Dl8Wer=
MNvfvgZVJ

> CnIEqxPofbgMz_Q_EzSiIoGbCQgNI&e=3D

>

> > > 
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetmod-2Dre=
vised-

> 2Ddatast&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DWCuOo=
1niAkysc

> QUKzIYmTuLvajFh0jn8MtmRmc6jjho&e=3D

>

> > > ores-06

>

> > >

>

> > > A diff from the previous version is available at:

>

> > > 
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetmod-2Dre=
vised-

> 2Ddatastores&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-<=
br>
> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL7nQJ=
MiX3M_yX

> LSwPASZefUdW7YmA4ly9MiocXVGh40&e=3D

>

> > > -06

>

> > >

>

> > >

>

> > > Please note that it may take a couple of minutes from the ti=
me of

>

> > > submission until the htmlized version and diff are available=
 at

> tools.ietf.org=
.

>

> > >

>

> > > Internet-Drafts are also available by anonymous FTP at:

>

> > > https://urldefense.proofpoint.com/v2/url?u=3Dftp-<=
/a>

> 3A__ftp.ietf.org_internet-

> 2Ddrafts_&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3De_mQe=
yXZbxETy

> vr0-gcvkPeWqv4mScsFa5ueArTKoQQ&e=3D

>

> > >

>

> > > _______________________________________________

>

> > > netmod mailing list

>

> > > netmod@=
ietf.org

>

> > > 
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3D<=
wbr>HAkYuh63rsuh

> r6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQy=
j_938aVcv4

> QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D

>

> > > .

>

> > >

>

> >

>

> > _______________________________________________

>

> > netmod mailing list

>

> > netmod@ietf.=
org

>

> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-

> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3D<=
wbr>HAkYuh63rsuh

> r6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQy=
j_938aVcv4

> QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3D<=
wbr>HAkYuh63rsuh

> r6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjIS=
laJdcZo&m

> =3DHmlA7hSACCJBmjNombXsdSLxNs5JnF3BrFaYXPWYosg&s=3DL2xQy=
j_938aVcv4

> QyFMHlNwXkX9tT8L46M1PXc6Lnh4&e=3D

>



_______________________________________________

netmod mailing list

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






=C2=A0


















--001a11411bc653ab38055d06b772--


From nobody Thu Nov  2 14:35: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 D5B6913F9BE for ; Thu,  2 Nov 2017 14:35:37 -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 1hsVwoPd4pYS for ; Thu,  2 Nov 2017 14:35:35 -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 1210813F70B for ; Thu,  2 Nov 2017 14:35:35 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id w21so1011542lfc.6 for ; Thu, 02 Nov 2017 14:35:34 -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=ngg7JpUCaTJs1I+QqDlNGLXmZnmA/9TaqGlPlCNFBM4=; b=oNO5WTG+ZF7EqpEMEeg+obzSykkXtV9mWPjnMVCwbhcqMyNaSVlljsO8lKVvQ49tCn sBNy8WdpqU/GWy8JkZ3+bdiex0K2/FcaIOqb29I+4pmG4p9nEDa/x7gJ1WN2pQWRpi7F L9/R04Pq/Ycd2ucnJWYyhhNvBKAN6/RDuCOl7NB/WxdWqr9RsdBXV4xPIfIRnHRBf3Jt yEd6UBw1WcpDdbsbQxkOgKpL2qZhsXGorGlJeHns20mKCgzJqhxrNspOg1tbtpl01Im5 YE6MvrufEhd/P05B2fnWiOVVD/riTTIG9MQgK4oqgWH5kUprdhY3PPlgkT8bOiQt5Ls+ IMXw==
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=ngg7JpUCaTJs1I+QqDlNGLXmZnmA/9TaqGlPlCNFBM4=; b=GsfgCb7iBv0M2P/aezMjEUGxppsMkZEDqLjkWTCV5QGsbyjQtz+6Lm4kLXqeus1ATt XSKnEcYU8m6AWJfBlY01XLrbmrPry/sAWoArgRbOQeTKhQvKFVc0WGMcaYJtdNUKN9+I aDFGOhxFYGBXC1ZWev40JDxtgcQj6bcyvpVvcdD08sISmNmZ/0GDgTVyfQWg6h33n6DJ h5Ruoj3GnT8gZZnBSJTafthnI1cFjLYK/xu3XP4WQ6htAyAgl/kAplOZVj66e+BAqjyh JAT2lhWJTBoucEWO9baKpGY/o2NjGmNgDRmH2RkwJe50aW9TzjEu3NPwaFdMWrluOeXu YuAg==
X-Gm-Message-State: AMCzsaWPpkVQiQDrh4kj6o9CD01nIreB0e9gAR2/h1vq7hTep3y+pkXa FXrRbY1ddwXcKIHHppS4yFydlwI2UZd8i9YAlMl8iw==
X-Google-Smtp-Source: ABhQp+SZLdvwYJyKY1gpJZmc4P9ZKgn8yyRNIf8Br6Yhd/wXuuablH0E4LuAe/0jwtqLpZ6QR76PYNIT5AJLqQAF+k8=
X-Received: by 10.46.85.136 with SMTP id g8mr2013760lje.84.1509658533378; Thu, 02 Nov 2017 14:35:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 2 Nov 2017 14:35:32 -0700 (PDT)
In-Reply-To: <201711022116.vA2LGTB3044617@idle.juniper.net>
References:  <201711022116.vA2LGTB3044617@idle.juniper.net>
From: Andy Bierman 
Date: Thu, 2 Nov 2017 14:35:32 -0700
Message-ID: 
To: Phil Shafer 
Cc: Robert Wilton , Kent Watsen ,  Martin Bjorklund , "netmod@ietf.org" ,  Randy Presuhn 
Content-Type: multipart/alternative; boundary="94eb2c1cdc449d5a1f055d06c4dd"
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: Thu, 02 Nov 2017 21:35:38 -0000

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

On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:

> Sorry, if I wasn't clear.  I meant the  element would
> be directly under , so the system knows where to start
> looking for data.  Guessing is bad.
>
>
Totally agree guessing is bad.
Did you see the  proposal in a previous email?
That is exactly what I proposed, except I do not want to
overload  so the new template would be a different name.

I realize the expanded name of the datastore element prevents it from
being confused with top-level YANG nodes, but the conformance
is more clear with a new name.




> Thanks,
>  Phil
>

Andy


>
>
> Andy Bierman writes:
> >So a server will be required to guess the correct datastore until it
> >finds the right one that matches the action instance?
> >
> >   
> >       
> >          
> >             10
> >             
> >                candidate
> >             
> >          
> >        
> >    
> >
> >The server will guess the datastore in some proprietary order and parse
> >instances of /top/ and /top/list1.  Then it finds the  action
> >and parses the input to get to the datastore and find out the real
> datastore
> >to use.  If the server guessed wrong, then it reparses the 
> against
> >the requested datastore.  Hopefully the schema trees match up.
> >
> >Will vendors do all the extra work required to support this sort of thing?
> >I doubt it.
> >
> >
> >Andy
> >
> >
> >
> >
> >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer  wrote:
> >
> >> 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
> >>
> >
> >--001a11411b0ad2d58d055cee96cb
> >Content-Type: text/html; charset="UTF-8"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
Hi,

So a server will be required to
> gue=
> >ss the correct datastore until it
finds the right one that
> matche=
> >s the action instance?

=C2=A0
> =C2=A0<action>=
> >
=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>
=C2=A0
> =C2=A0 =
> >=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> >=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 =C2=A0
> =C2=
> >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>
=C2=A0 =C2=A0
> =C2=
> >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate<
> /datas=
> >tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> =C2=A0</do-=
> >test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> </list1>
<=
> >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0
> </a=
> >ction>

The server will guess the datastore
> in s=
> >ome proprietary order and parse
instances of /top/ and
> /top/list1=
> >.=C2=A0 Then it finds the <do-test> action
and parses the
> i=
> >nput to get to the datastore and find out the real datastore
to
> u=
> >se.=C2=A0 If the server guessed wrong, then it reparses the
> <action> =
> >against
the requested datastore.=C2=A0 Hopefully the schema
> trees=
> > match up.

Will vendors do all the extra work
> requ=
> >ired to support this sort of thing?
I doubt
> it.

 >iv>

Andy


 div>

 >iv>

On Tue,
> O=
> >ct 31, 2017 at 11:36 PM, Phil Shafer < href=3D"mailt=
> >o:phil@juniper.net" target=3D"_blank">phil@juniper.net>
> wrote=
> >:
 .8ex;border-le=
> >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

> >>ii) However, as far as I can see, it doesn't make sense for an
> acti=
> >on to

> >>directly affect the contents of any configuration datastore, that
> shoul=
> >d

> >>be done via a purpose built rpc (like edit-config).

> >

> >An example action would be to retrieve the=C2=A0 fingerprint of an ssh

> >key.=C2=A0 I might want to get the fingerprint of a key in
> <candidate>=
> >;

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

> >

> >Seems like <startup> 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?=C2=A0 Any specific RPC can define its

> >own datastore leaf of hard-code the database in the description

> >(explicitly or implicitly <operational>), but the <action>
> RPC =
> >only

> >gets this if we make a new parameter for it.

> >

> >Thanks,

> >=C2=A0Phil

> >


> >
> >--001a11411b0ad2d58d055cee96cb--
>

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




On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer <phil@juniper.net> wrote:
Sorry, if I wasn't clear=
.=C2=A0 I meant the <datastore> element would

be directly under <action>, so the system knows where to start

looking for data.=C2=A0 Guessing is bad.



Totally agree guessing is bad.
Did you see the <action2> proposal in a previous email?
=
That is exactly what I proposed, except I do not want to
overload=
 <action> so the new template would be a different name.
I realize the expanded name of the datastore element prevents =
it from
being confused with top-level YANG nodes, but the conform=
ance
is more clear with a new name.


=

=C2=A0

Thanks,

=C2=A0Phil

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




Andy Bierman writes:

>So a server will be required to guess the correct datastore until it
>finds the right one that matches the action instance?

>

>=C2=A0 =C2=A0<action>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <list1>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<key>10</key&g=
t;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore&g=
t;candidate</datastore>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</do-test>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </list1>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>

>=C2=A0 =C2=A0 </action>

>

>The server will guess the datastore in some proprietary order and parse=


>instances of /top/ and /top/list1.=C2=A0 Then it finds the <do-test&=
gt; action

>and parses the input to get to the datastore and find out the real data=
store

>to use.=C2=A0 If the server guessed wrong, then it reparses the <act=
ion> against

>the requested datastore.=C2=A0 Hopefully the schema trees match up.

>

>Will vendors do all the extra work required to support this sort of thi=
ng?

>I doubt it.

>

>

>Andy

>

>

>

>

>On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer <phil@juniper.net> wrote:

>

>> Robert Wilton writes:

>> >ii) However, as far as I can see, it doesn't make sense fo=
r an action to

>> >directly affect the contents of any configuration datastore, t=
hat should

>> >be done via a purpose built rpc (like edit-config).

>>

>> An example action would be to retrieve the=C2=A0 fingerprint of an=
 ssh

>> key.=C2=A0 I might want to get the fingerprint of a key in <can=
didate>

>> before I commit it.

>>

>> Or I could have an action that sets the SNMPv3 auth key to a rando=
m

>> value, and I want to invoke that action against <candidate>.=


>>

>> Seems like <startup> might also be an interesting place to t=
arget

>> actions, but I can't think of a good example.

>>

>> There are always scenarios where something is useful, and the prob=
lem

>> with ruling it out is that it becomes needed at some later point.<=
br>
>> We've a habit of ruling out things and later wishing we had th=
em.

>>

>> Is the easy fix to just put a datastore leaf under rpc/action and<=
br>
>> have it default to operational?=C2=A0 Any specific RPC can define =
its

>> own datastore leaf of hard-code the database in the description
>> (explicitly or implicitly <operational>), but the <action=
> RPC only

>> gets this if we make a new parameter for it.

>>

>> Thanks,

>>=C2=A0 Phil

>>

>

>--001a11411b0ad2d58d055cee96cb

>Content-Type: text/html; charset=3D"UTF-8"

>Content-Transfer-Encoding: quoted-printable

>

><div dir=3D3D"ltr">Hi,<div><br></div>=
<div>So a server will be required to gue=3D

>ss the correct datastore until it</div><div>finds the right=
 one that matche=3D

>s the action instance?</div><div><br></div><div>=3DC2=3DA0 =3DC2=3DA0&lt;action&gt;=3D

></div><div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0&=
lt;top&gt;</div><div>=3DC2=3DA0 =3DC2=3DA0 =3D

>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 &lt;list1&gt;</div><d=
iv>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D

>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0&lt;key&gt;10&lt;/key&<=
wbr>gt;</div><div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3D

>=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0&lt;do-test&gt=
;</div><div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3D

>=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 &lt;da=
tastore&gt;candidate&lt;/datas=3D

>tore&gt;</div><div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D=
C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0&lt;/do-=3D

>test&gt;</div><div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D=
C2=3DA0 =3DC2=3DA0 &lt;/list1&gt;</div><=3D

>div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 &lt;/top&gt;=
</div><div>=3DC2=3DA0 =3DC2=3DA0 &lt;/a=3D

>ction&gt;</div><div><br></div><div&=
gt;The server will guess the datastore in s=3D

>ome proprietary order and parse</div><div>instances of /top=
/ and /top/list1=3D

>.=3DC2=3DA0 Then it finds the &lt;do-test&gt; action</div>=
;<div>and parses the i=3D

>nput to get to the datastore and find out the real datastore</div>=
;<div>to u=3D

>se.=3DC2=3DA0 If the server guessed wrong, then it reparses the &lt=
;action&gt; =3D

>against</div><div>the requested datastore.=3DC2=3DA0 Hopefu=
lly the schema trees=3D

> match up.</div><div><br></div><div>=
Will vendors do all the extra work requ=3D

>ired to support this sort of thing?</div><div>I doubt it.&l=
t;/div><div><br></d=3D

>iv><div><br></div><div>Andy</div>=
<div><br></div><div><br></div><=
div><br></d=3D

>iv><div><div class=3D3D"gmail_extra"><br>=
;<div class=3D3D"gmail_quote">On Tue, O=3D

>ct 31, 2017 at 11:36 PM, Phil Shafer <span dir=3D3D"ltr"&g=
t;&lt;<a href=3D3D"mailt=3D

>o:phil@juniper.net" ta=
rget=3D3D"_blank">phil@juniper.net</a>&gt;</span> wrote=3D

>:<br><blockquote class=3D3D"gmail_quote" style=3D3D&=
quot;margin:0 0 0 .8ex;border-le=3D

>ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:<br=
>

>&gt;ii) However, as far as I can see, it doesn&#39;t make sense=
 for an acti=3D

>on to<br>

>&gt;directly affect the contents of any configuration datastore, th=
at shoul=3D

>d<br>

>&gt;be done via a purpose built rpc (like edit-config).<br>
><br>

>An example action would be to retrieve the=3DC2=3DA0 fingerprint of an =
ssh<br>

>key.=3DC2=3DA0 I might want to get the fingerprint of a key in &lt;=
candidate&gt=3D

>;<br>

>before I commit it.<br>

><br>

>Or I could have an action that sets the SNMPv3 auth key to a random<=
br>

>value, and I want to invoke that action against &lt;candidate&g=
t;.<br>

><br>

>Seems like &lt;startup&gt; might also be an interesting place t=
o target<br>

>actions, but I can&#39;t think of a good example.<br>

><br>

>There are always scenarios where something is useful, and the problem&l=
t;br>

>with ruling it out is that it becomes needed at some later point.<br=
>

>We&#39;ve a habit of ruling out things and later wishing we had the=
m.<br>

><br>

>Is the easy fix to just put a datastore leaf under rpc/action and<br=
>

>have it default to operational?=3DC2=3DA0 Any specific RPC can define i=
ts<br>

>own datastore leaf of hard-code the database in the description<br&g=
t;

>(explicitly or implicitly &lt;operational&gt;), but the &lt=
;action&gt; RPC =3D

>only<br>

>gets this if we make a new parameter for it.<br>

><br>

>Thanks,<br>

>=3DC2=3DA0Phil<br>

></blockquote></div><br></div></div>&=
lt;/div>

>

>--001a11411b0ad2d58d055cee96cb--





--94eb2c1cdc449d5a1f055d06c4dd--


From nobody Thu Nov  2 15:12: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 326FC13FA05 for ; Thu,  2 Nov 2017 15:12:15 -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_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 WBZi3hd92-RR for ; Thu,  2 Nov 2017 15:12:14 -0700 (PDT)
Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com [209.85.192.172]) (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 3069B13F9E0 for ; Thu,  2 Nov 2017 15:12:14 -0700 (PDT)
Received: by mail-pf0-f172.google.com with SMTP id b79so713689pfk.5 for ; Thu, 02 Nov 2017 15:12:14 -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=tYFIznU7H1DiICRLdGLFbEORTlKSII8pKh17duYcj48=; b=HWxDWU/7KXYgiH2BygTI0ZzKX3Tk60obK9KRRw8TN3AAvRALvteVuGUBnGlgXlTDUi XX8BmhObHI6KajzO6QN5zZKPcDC9LR2DedzJ+583UcpfYhlaCrLgPx2+OkYVKMBez2+y MiPuO15dGwd1MUDYcf+l2POLZm3PXCo+/ZU6RiqVPhTPmCHAKuxI4s7kfsaeCrjOSN3U +8OPN4sm+7TMmv6xnU6oIO4EfC80SgvlLMq8MFTrE9OznPmfkNXnKjMr3twiCoikASFm JvMwoeMEDJPv7GAMLanC2B1MdymgdMSAAscruQGx2NpkWAcsflcua7nKioCtM8ufsyeL +r8Q==
X-Gm-Message-State: AMCzsaXYjXQmmrecuGtHbr43RGf55njj1S06MCfoHKTTtMRJnmQ0XG92 YBUlHFId2IKuLe2UFuZTIZFri4BPOqy7qA==
X-Google-Smtp-Source: ABhQp+S0fYSQ0QReocCVo2n+M/x/+8w47h9TSAS9c/im83s5XZQGt52ZBMEpQxQgDF5xlCKSChlmnA==
X-Received: by 10.84.233.69 with SMTP id k5mr4819778plt.189.1509660733333; Thu, 02 Nov 2017 15:12:13 -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 b6sm6435169pgc.2.2017.11.02.15.12.12 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 15:12:12 -0700 (PDT)
To: netmod@ietf.org
References: <076270A6-B2C1-44BC-8F02-F4E96675E76F@juniper.net>   
From: Randy Presuhn 
Message-ID: <7c48a435-1a1b-4bae-786b-068ac39ffab1@alumni.stanford.edu>
Date: Thu, 2 Nov 2017 15:12:17 -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] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Nov 2017 22:12:15 -0000

Hi -

On 11/2/2017 2:12 PM, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> I can’t think of a specific problem immediately.  But I think it means 
> templates would be considered as “applied” always right ?  Or do you see 
> cases where templates don’t show up when  is read ?

Pure speculation...
consider the case of templates belonging to a provisioned
(but not yet inserted, much less activated) line card...

> Special rules are likely to be needed for validation though.  A DS (with 
> templates) won’t be valid unless you validate an exploded view.

That really depends on how one models templates.  A template
doesn't *have* to be the same "kind of thing" (e.g. class) as
the thing being instantiated/initialized from it, and consequently
is not necessarily going to have the same validation properties.
Consider the way "create with reference object" worked in another
universe.

Randy


From nobody Fri Nov  3 01:42: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 B126313FD07 for ; Fri,  3 Nov 2017 01:42:36 -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 DS1ABC-9q8lJ for ; Fri,  3 Nov 2017 01:42:34 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1350E13FD06 for ; Fri,  3 Nov 2017 01:42:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 44D12261846; Fri,  3 Nov 2017 09:42:35 +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 AR2khmS6boop; Fri,  3 Nov 2017 09:42:33 +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 0F34E261838; Fri,  3 Nov 2017 09:42:33 +0100 (CET)
Date: Fri, 3 Nov 2017 09:42:31 +0100
From: Kristian Larsson 
To: Robert Wilton 
Cc: Martin Bjorklund , mjethanandani@gmail.com, netmod@ietf.org
Message-ID: <20171103084231.GE12688@spritelink.se>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com>  <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@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: Fri, 03 Nov 2017 08:42:37 -0000

On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
> 
> 
> On 02/11/2017 16:41, Kristian Larsson wrote:
> >On Thu, Nov 02, 2017 at 12:53:29PM +0000, Robert Wilton wrote:
> >>   feature mixed-ipv4-acl {
> >>     if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
> >>    description "Layer 2 and Layer 3 IPv4 ACL supported";
> >>   }
> >>   ...
> >Features dependent on features... inception. I didn't even know
> >this was possible with YANG. Learned something today \o/
> This just means that a device cannot say that it supports a "mixed-ipv4-acl"
> ACL unless it supports classifying traffic on Ethernet and classifying
> traffic on IPv4.
> 
> So the 'match type' feature specify what header fields the hardware is
> capable of match on. E.g. a basic L2 device might say that is only matches
> on the Ethernet header.
> 
> The "ACL types" features specify what combination of header fields can be
> combined into a single ACL.

Ah, right. Sorry, I was thinking that match-on-l2-eth-hdr and
match-on-ipv4-hdr would imply mixed-ipv4-acl. My bad.


> The real benefit for defining "match type" is that the unsupported fields in
> the ACL can then be cleanly left out of the device schema. E.g. a
> hypothetical new breed of IPv6 only routers that only support matching on
> match-on-ipv6-hdr, and don't want to carry v4 baggage.

Since I work for a network that aspires of being v6 only I quite
like this ;)


> >Are we seeking to have a single style of attachment points? I
> >think that's difficult in reality. Linux has one style, where a
> >single global "ACL" is defined. Most routers use per interface
> >ACL and as seen, they split it up on ethernet vs IP (and v4 vs
> >v6). I doubt one can be said to be better than the other so
> >trying to argue that everyone should converge on one way is
> >pointless. Similarly supporting every different style is also
> >futile as it's completely against the point of standardisation.
> >
> >The pragmatic compromies is likely to support a few ways and any
> >vendor that needs something radically different need to build
> >their own model, do augment, deviate, refine or whatever. Other
> >thoughts?
> For interface attachments I think that the approach in the draft looks OK,
> and reasonably generic, but will need vendor deviations. This is probably
> OK.

I don't agree. Given the length we've gone in trying to convey the
match capabilities of the platform I think we can afford to give
implementors some options when it comes to attachment too! :)

Arguing that one way of doing ACL attachment is better than
another is futile and my personal opinion is that there simply is
no one way that's better than all else. A single global
attachment point like what Linux does is not better or worse from
the per interface ACL style that most router vendors employ. It's
just different. I believe the model should allow vendors and
users to express the most common forms we currently have. Not all
ways, but the two or three most common ways, which probably
covers the vast majority of all platforms.

The current model is an ill fit for platforms that attach filters
globally, like most host firewalls (Linux *tables, OpenBSD pf,
FreeBSD ipfw etc) or the vast majority of firewalls (Juniper SRX,
Cisco ASA, Checkpoint etc). There must be different attachment
options for "per interface" vs "global". 

As for the per-interface style options
 * current draft; a list of ACLs of varying "type", evaluated in
   specified order, per-interface and per direction
 * three separate ACLs for ethernet, ipv4 and ipv6 and
   per-interface and per direction

The only vendor I know of that have a single attachment point on
an interface is Huawei. However, it's not just an attachment
point for ACLs but for what Huawei calls a "traffic-policy" which
mixes in ACLs and QoS in the same place. It is so different from
everything else that deviations or augmentations will no doubt be
required to express what they have. The other large router
vendors; Cisco, Juniper and Nokia, all use separate attachment
points for ipv4, ipv6 and ethernet.

Shouldn't we have a model that supports;
 * virtually all host network stacks
 * virtually all firewalls
 * the vast majority of high end routers

Rather than:
 * no currently existing platform (or is there one I don't know of?)


> Personally, I would put the ACL interface attachment points as an
> augmentation of if:interfaces/interface rather than having a separate top
> level list, but perhaps that is just want I am used to ...

+1 on augmentation of interfaces.

   kll

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511                                kll@spritelink.net


From nobody Fri Nov  3 01:51: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 C85D713FD07 for ; Fri,  3 Nov 2017 01:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fNOo4SHJT68b for ; Fri,  3 Nov 2017 01:51:09 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE4013FD04 for ; Fri,  3 Nov 2017 01:51:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 837A1261846; Fri,  3 Nov 2017 09:51:10 +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 yGm+d3vd6dqJ; Fri,  3 Nov 2017 09:51:08 +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 6D374261838; Fri,  3 Nov 2017 09:51:08 +0100 (CET)
Date: Fri, 3 Nov 2017 09:51:06 +0100
From: Kristian Larsson 
To: Mahesh Jethanandani 
Cc: Juergen Schoenwaelder , "netmod@ietf.org" 
Message-ID: <20171103085106.GF12688@spritelink.se>
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se>  <20171101112249.wmq4ggx2ixgn4kqo@elstar.local>  <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.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: Fri, 03 Nov 2017 08:51:13 -0000

On Thu, Nov 02, 2017 at 03:20:34PM +0630, Mahesh Jethanandani wrote:
> Kristian,
> 
> I hear you. What I am providing is the rational for the current design. 

Ok, thank you! That is valuable to me so please don't stop :)


> I would like to hear from others in the WG. We have been
> reviewing this draft for the last couple of years, and we are
> now at the tail end of the LC.

Believe me, I have no intention of stopping this draft. I just
want to improve it.

I actually wanted to start using it earlier this year but found
the structure so unwieldy to work with that I eventually gave up
and instead decided to try and improve the model. It took a wee
bit longer than I intended but here I am.

For the interested, I wanted to build a YANG translation service
in NCS (now Cisco NSO) that could translate ACLs from one format
into the native format of four different vendors. I currently
keep feature parity across four different platforms and doing
that for something like ACLs is highly error prone.


> I would really like to see this draft move forward,
> particularly since it is not broken.

I want to have a standard ACL model too.

I am not complaining just for the sake of complaining, it is
because I found the structure unnatural or otherwise difficult to
use. I will try my best to not just criticise but instead provide
actual suggestions on how to improve things.

Kind regards,
   Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511                                kll@spritelink.net


From nobody Fri Nov  3 01:52: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 BF8F613FD0C for ; Fri,  3 Nov 2017 01:52:48 -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 01k9eiyNvjX6 for ; Fri,  3 Nov 2017 01:52:48 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id B96AB13FD0A for ; Fri,  3 Nov 2017 01:52:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id EDED7261846; Fri,  3 Nov 2017 09:52:48 +0100 (CET)
X-Virus-Scanned: amavisd-new at SpriteLink.NET
Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c435LqEDWOPY; Fri,  3 Nov 2017 09:52:46 +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 DA541261838; Fri,  3 Nov 2017 09:52:46 +0100 (CET)
Date: Fri, 3 Nov 2017 09:52:45 +0100
From: Kristian Larsson 
To: Mahesh Jethanandani 
Cc: Martin Bjorklund , rwilton@cisco.com, netmod@ietf.org
Message-ID: <20171103085244.GG12688@spritelink.se>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com> <51CEDFCB-88CF-4066-8428-55BF7521D1F0@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <51CEDFCB-88CF-4066-8428-55BF7521D1F0@gmail.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: Fri, 03 Nov 2017 08:52:49 -0000

On Thu, Nov 02, 2017 at 07:10:30PM +0630, Mahesh Jethanandani wrote:
> Ok. Will update the model to reflect the discussion on this thread.

Mahesh, would it be helpful if I prepared changes in the form of
pull requests on the github repo?

I can write code, we can discuss it here and merge once agreed?

   kll

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511                                kll@spritelink.net


From nobody Fri Nov  3 02:03: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 DEFB613FD15 for ; Fri,  3 Nov 2017 02:03: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, 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 wvK3QNr4mZmk for ; Fri,  3 Nov 2017 02:03:47 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id B0A8613FB53 for ; Fri,  3 Nov 2017 02:03:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id BC36B261846 for ; Fri,  3 Nov 2017 10:03:47 +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 X9KjtMp1-EKK for ; Fri,  3 Nov 2017 10:03:41 +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 023BE261838 for ; Fri,  3 Nov 2017 10:03:41 +0100 (CET)
Date: Fri, 3 Nov 2017 10:03:39 +0100
From: Kristian Larsson 
To: netmod@ietf.org
Message-ID: <20171103090339.GH12688@spritelink.se>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com>  <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171103084231.GE12688@spritelink.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 - acl-type in list key?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 03 Nov 2017 09:03:48 -0000

Another question somewhat related to attachment point. Why is
acl-type part of the list key?

I think compound keys are really quite clunky and should be
avoided if possible. In this case I really don't see why acl-type
needs to be part of the list key.

For the list of ACLs it means that the acl-name needs to be
unique instead of the combination of the type and name. This
seems rather uncontroversial to me.

Is it because we want to have constraints on the acl-type? ISTM
that we can apply such constraints anyway.

I just don't understand why it's part of the list key. Can it
please be removed?

   kll

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511                                kll@spritelink.net


From nobody Fri Nov  3 02: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 EB3F113FD30 for ; Fri,  3 Nov 2017 02:30:05 -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 tij8I2hzZTLK for ; Fri,  3 Nov 2017 02:30:04 -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 7950313FD2D for ; Fri,  3 Nov 2017 02:30:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5810; q=dns/txt; s=iport; t=1509701403; x=1510911003; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vO0zUZ/Mz05chjvseXfrrMxIp149Z46W2b+18kCDG6A=; b=Cc1uKEdl0kT9/UCgQQt+c0N7WReqp/PJF6qBXpPs1wJQnx7I4A2/Fo+V +2STxZFs37S87EICbazFQsBR0GXrNtY0ahcEXdB31qdQ2FYstS4paOl3H bKxtO96YZ3B11vqyH9fhywuW9LU0QrFYivJbqguV0yg//TgpoR2rehNps 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAAACMvxZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJHeJKHSQJJZFghEKhTsChRMYAQEBAQEBAQEBayiFHQEBAQE?= =?us-ascii?q?CASMPAQVBEAsYAgImAgJXBg0IAQGKFwioMoInixEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?SGBD4Ifg1qCEoMBiCaCYgWiDotNiS+LeIc8jimHbYE5HziBbDQhCB0VSYJlgls?= =?us-ascii?q?cgWdBjRsBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,338,1505779200";  d="scan'208";a="40822"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2017 09:30:01 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA39U1ke026416; Fri, 3 Nov 2017 09:30:01 GMT
To: Kristian Larsson 
Cc: Martin Bjorklund , mjethanandani@gmail.com, netmod@ietf.org
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com>  <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se>
From: Robert Wilton 
Message-ID: <22bb1ad7-070b-68e1-b35a-bce01204b840@cisco.com>
Date: Fri, 3 Nov 2017 09:30:01 +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: <20171103084231.GE12688@spritelink.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-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, 03 Nov 2017 09:30:06 -0000

On 03/11/2017 08:42, Kristian Larsson wrote:
> On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
>>
>> On 02/11/2017 16:41, Kristian Larsson wrote:
>>> On Thu, Nov 02, 2017 at 12:53:29PM +0000, Robert Wilton wrote:
>>>>    feature mixed-ipv4-acl {
>>>>      if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
>>>>      description "Layer 2 and Layer 3 IPv4 ACL supported";
>>>>    }
>>>>    ...
>>> Features dependent on features... inception. I didn't even know
>>> this was possible with YANG. Learned something today \o/
>> This just means that a device cannot say that it supports a "mixed-ipv4-acl"
>> ACL unless it supports classifying traffic on Ethernet and classifying
>> traffic on IPv4.
>>
>> So the 'match type' feature specify what header fields the hardware is
>> capable of match on.  E.g. a basic L2 device might say that is only matches
>> on the Ethernet header.
>>
>> The "ACL types" features specify what combination of header fields can be
>> combined into a single ACL.
> Ah, right. Sorry, I was thinking that match-on-l2-eth-hdr and
> match-on-ipv4-hdr would imply mixed-ipv4-acl. My bad.
>
>
>> The real benefit for defining "match type" is that the unsupported fields in
>> the ACL can then be cleanly left out of the device schema.  E.g. a
>> hypothetical new breed of IPv6 only routers that only support matching on
>> match-on-ipv6-hdr, and don't want to carry v4 baggage.
> Since I work for a network that aspires of being v6 only I quite
> like this ;)
>
>
>>> Are we seeking to have a single style of attachment points? I
>>> think that's difficult in reality. Linux has one style, where a
>>> single global "ACL" is defined. Most routers use per interface
>>> ACL and as seen, they split it up on ethernet vs IP (and v4 vs
>>> v6). I doubt one can be said to be better than the other so
>>> trying to argue that everyone should converge on one way is
>>> pointless. Similarly supporting every different style is also
>>> futile as it's completely against the point of standardisation.
>>>
>>> The pragmatic compromies is likely to support a few ways and any
>>> vendor that needs something radically different need to build
>>> their own model, do augment, deviate, refine or whatever. Other
>>> thoughts?
>> For interface attachments I think that the approach in the draft looks OK,
>> and reasonably generic, but will need vendor deviations. This is probably
>> OK.
> I don't agree. Given the length we've gone in trying to convey the
> match capabilities of the platform I think we can afford to give
> implementors some options when it comes to attachment too! :)
I  agree that interface vs global are two different styles, and happy if 
the model supports both.

But for interface attachments, if there can be one generic way that can 
apply to all platforms (perhaps with further constraints) then that will 
be easier for clients to code to.

If different vendors do interface attachment in different ways then that 
ends up being more code on the client side.

>
> Arguing that one way of doing ACL attachment is better than
> another is futile and my personal opinion is that there simply is
> no one way that's better than all else. A single global
> attachment point like what Linux does is not better or worse from
> the per interface ACL style that most router vendors employ. It's
> just different. I believe the model should allow vendors and
> users to express the most common forms we currently have. Not all
> ways, but the two or three most common ways, which probably
> covers the vast majority of all platforms.
OK, would be happy for 2 ways:
  - interfaces
  - global

With each of them generic enough to apply reasonably widely.

>
> The current model is an ill fit for platforms that attach filters
> globally, like most host firewalls (Linux *tables, OpenBSD pf,
> FreeBSD ipfw etc) or the vast majority of firewalls (Juniper SRX,
> Cisco ASA, Checkpoint etc). There must be different attachment
> options for "per interface" vs "global".
Sure.

>   
>
> As for the per-interface style options
>   * current draft; a list of ACLs of varying "type", evaluated in
>     specified order, per-interface and per direction
>   * three separate ACLs for ethernet, ipv4 and ipv6 and
>     per-interface and per direction
I think that the current model accommodates both of these.

For the 3 separate ACLs, the vendor would "deviate" the model with 
additional constraints so that there could only be one ACL of each type 
in the list for an interface.

Given that the model allows mixed ACLs, this approach still seems 
reasonable and quite generic to me.

>
> The only vendor I know of that have a single attachment point on
> an interface is Huawei. However, it's not just an attachment
> point for ACLs but for what Huawei calls a "traffic-policy" which
> mixes in ACLs and QoS in the same place. It is so different from
> everything else that deviations or augmentations will no doubt be
> required to express what they have. The other large router
> vendors; Cisco, Juniper and Nokia, all use separate attachment
> points for ipv4, ipv6 and ethernet.
>
> Shouldn't we have a model that supports;
>   * virtually all host network stacks
>   * virtually all firewalls
>   * the vast majority of high end routers
Yes, if we can.

Thanks,
Rob


>
> Rather than:
>   * no currently existing platform (or is there one I don't know of?)
>
>
>> Personally, I would put the ACL interface attachment points as an
>> augmentation of if:interfaces/interface rather than having a separate top
>> level list, but perhaps that is just want I am used to ...
> +1 on augmentation of interfaces.
>
>     kll
>


From nobody Fri Nov  3 02:39: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 0502913FD31 for ; Fri,  3 Nov 2017 02:39:20 -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 mHPENXSE651i for ; Fri,  3 Nov 2017 02:39:19 -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 93ECE13FD2D for ; Fri,  3 Nov 2017 02:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2281; q=dns/txt; s=iport; t=1509701958; x=1510911558; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NCgdpcZNT3T06Mq+5IBXxOHqWxfc/Mzi2Ws+cqJdNOo=; b=UNzbnqY39IARykqRMPR2F7nxpL+PnqB95iSJspBRg4cJecmixg5rNLWK Wrk2yrRzU8vDwDh1MZQ0q2kPl6NHnxwrRfcOh92NS/pv/Kd+w86k/+jNe evldvCsgl1Iz47Np0eqBqYIqYZNZ4ty2Wy6gQTz+dpaFkPbcEA7qiyCN2 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAAABOPxZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIofdI9+JpZFghEKhTsChRQYAQEBAQEBAQEBayiFHgEFIw8?= =?us-ascii?q?BBUEQCxgCAiYCAlcGDQgBAYofqCGCJ4sRAQEBAQEBAQEBAQEBAQEBAQEhgQ+CH?= =?us-ascii?q?4NaghILgnaIJoJiBZkGiQiUfAKLdoc8jimHbYE5HziBbDQhCB0Vgy6EXkGNGwE?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.44,338,1505779200";  d="scan'208";a="42028"
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; 03 Nov 2017 09:39:16 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA39dG7Z028784; Fri, 3 Nov 2017 09:39:16 GMT
To: Phil Shafer , "Sterne, Jason (Nokia - CA/Ottawa)" 
Cc: "netmod@ietf.org" 
References: <201711022131.vA2LVRjs044715@idle.juniper.net>
From: Robert Wilton 
Message-ID: <71639489-a7d3-a5a2-4634-f539fe8877bb@cisco.com>
Date: Fri, 3 Nov 2017 09:39:16 +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: <201711022131.vA2LVRjs044715@idle.juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] revised-datastores and commonality of schemas
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 03 Nov 2017 09:39:20 -0000

I agree.

I think that a configuration template is just another form of 
configuration, and hence would expect that the template itself appear in 
candidate, startup, running, intended, operational.

There could also be "system templates" that are not directly 
configurable, and do not appear in configuration (e.g. I think that a 
system defined Loopback0 interface could be thought to be part of a 
"system template").  E.g. basically just configuration that the system 
always merges in from running to intended.  Today, I would not expect to 
"see" these system templates, only the affect of them in  and 
.

Thanks,
Rob


On 02/11/2017 21:31, Phil Shafer wrote:
> "Sterne, Jason (Nokia - CA/Ottawa)" writes:
>> The  DS needs to have both the template itself in the schema as well as
>> whatever nodes are used to hold 'exploded' data.  But what about intended and
>> operational ?
> For JUNOS, we carry both the raw and expanded views, though nothing
> in JUNOS is looking at the raw data outside of the UI code.  But we
> carry it, so that scripts can access this information and find the
> original "intent" for config.
>
> For example, if my interface template looked like:
>
> interfaces {
>      apply-macro so-0/0/0 {
>          inet-address 10.3.2.1/30;
>          role customer-facing;
>      }
> }
>
> and then my commit script turned this into traditional JUNOS
> config, like:
>
> interfaces {
>      so-0/0/0 {
>          unit 0 {
>              family inet {
>                  address 10.3.2.1/30;
>                  filter customer-facing;
>               }
>               family mpls;
>               family iso;
>          }
>      }
> }
> protocols {
>      bgp {
>          group customer-facing {
>              peer 10.3.2.2 {
>                  local-address 10.3.2.1;
>                  policy customer-facing;
> ...
>
> And whatever else "customer-facing" means.
>
> Both sets of config will be in  and  so that
> when I find an interface that's down, I can look (in )
> at the original apply-macro and see the role of the interface to know
> how loud an alarm I should be raising.
>
> Thanks,
>   Phil
> .
>


From nobody Fri Nov  3 03:12: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 2EF6313FD53 for ; Fri,  3 Nov 2017 03:12: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 g-Qr404DVKXr for ; Fri,  3 Nov 2017 03:12:32 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFAE13FD3E for ; Fri,  3 Nov 2017 03:12:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 5EC39261846; Fri,  3 Nov 2017 11:12:29 +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 dcHFvlW8SDH1; Fri,  3 Nov 2017 11:12:27 +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 F2537261838; Fri,  3 Nov 2017 11:12:26 +0100 (CET)
Date: Fri, 3 Nov 2017 11:12:25 +0100
From: Kristian Larsson 
To: Robert Wilton 
Cc: Martin Bjorklund , mjethanandani@gmail.com, netmod@ietf.org
Message-ID: <20171103101225.GJ12688@spritelink.se>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com>  <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <22bb1ad7-070b-68e1-b35a-bce01204b840@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <22bb1ad7-070b-68e1-b35a-bce01204b840@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: Fri, 03 Nov 2017 10:12:34 -0000

On Fri, Nov 03, 2017 at 09:30:01AM +0000, Robert Wilton wrote:
> 
> 
> On 03/11/2017 08:42, Kristian Larsson wrote:
> >On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
> >>
> >>On 02/11/2017 16:41, Kristian Larsson wrote:
> >>>Are we seeking to have a single style of attachment points? I
> >>>think that's difficult in reality. Linux has one style, where a
> >>>single global "ACL" is defined. Most routers use per interface
> >>>ACL and as seen, they split it up on ethernet vs IP (and v4 vs
> >>>v6). I doubt one can be said to be better than the other so
> >>>trying to argue that everyone should converge on one way is
> >>>pointless. Similarly supporting every different style is also
> >>>futile as it's completely against the point of standardisation.
> >>>
> >>>The pragmatic compromies is likely to support a few ways and any
> >>>vendor that needs something radically different need to build
> >>>their own model, do augment, deviate, refine or whatever. Other
> >>>thoughts?
> >>For interface attachments I think that the approach in the draft looks OK,
> >>and reasonably generic, but will need vendor deviations. This is probably
> >>OK.
> >I don't agree. Given the length we've gone in trying to convey the
> >match capabilities of the platform I think we can afford to give
> >implementors some options when it comes to attachment too! :)
> I agree that interface vs global are two different styles, and happy if the
> model supports both.

Cool.



> >As for the per-interface style options
> >  * current draft; a list of ACLs of varying "type", evaluated in
> >    specified order, per-interface and per direction
> >  * three separate ACLs for ethernet, ipv4 and ipv6 and
> >    per-interface and per direction
> I think that the current model accommodates both of these.
> 
> For the 3 separate ACLs, the vendor would "deviate" the model with
> additional constraints so that there could only be one ACL of each type in
> the list for an interface.

Fair enough. I actually discussed this solution off-list
yesterday evening but failed to bring it up as a potential
solution now ;)


> Given that the model allows mixed ACLs, this approach still seems reasonable
> and quite generic to me.

Sure. I guess the XPath on IOS XR, which supports one eth acl,
one ipv4 acl and one ipv6 acl per interface becomes a little
tricky. Like we have to do count() based on acl-type I guess to
prevent two ACLs of the same type being set (or say that the
translation mechanism should logically merge multiple ACLs).

JUNOS also has different attachment points that each accept a
list of ACLs so it's just a matter of putting a constraint on
accepted acl-type and the translation mechanism just sorts based
on acl-type.

I'm happy with this :)

   kll

-- 
Kristian Larsson                                        KLL-RIPE
+46 72 5479985                                kll@spritelink.net


From nobody Fri Nov  3 03:40: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 9BF5E13FB3A for ; Fri,  3 Nov 2017 03:40: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 pnOv8nHhvetX for ; Fri,  3 Nov 2017 03:40:20 -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 8655113FD6C for ; Fri,  3 Nov 2017 03:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3377; q=dns/txt; s=iport; t=1509705619; x=1510915219; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=EqpLOfEX6i8JHdGJp1pR5e1qK3odTzHAy+6j1jl8/Pc=; b=CgBV+JL1uiuPxova5P9JNpD2cMJxSOQSLVT76zGRVXtb5j5QRjJgNXMI 6XcoSadFaj/QbL8c6kRxE8XlZfr/YQ25xyt0CnFj9+ImM51Xd1c5Khnll dP9P8blNtauwLPwsN36B+F01thfwLI91gzlmpYYIS7oNtvco4iERLqb7G A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAABPRPxZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJHeJKHSQI5ZFghEKhTsChRQYAQEBAQEBAQEBayiFHQEBAQM?= =?us-ascii?q?BIw8BBUEFCwsYAgImAgJXBg0IAQEXigAIp32CJ4sQAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEhgQ+CH4NaghKDAYgmgmIFih+HP4FtjkOLTYkvi3iHPI4ph22BOR84gWw0IQg?= =?us-ascii?q?dFUmCZYJbHIFnQY1sAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,338,1505779200";  d="scan'208";a="163"
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; 03 Nov 2017 10:40:17 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA3AeHtg026532; Fri, 3 Nov 2017 10:40:17 GMT
To: Kristian Larsson 
Cc: Martin Bjorklund , mjethanandani@gmail.com, netmod@ietf.org
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com>  <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <22bb1ad7-070b-68e1-b35a-bce01204b840@cisco.com> <20171103101225.GJ12688@spritelink.se>
From: Robert Wilton 
Message-ID: <63d922fe-0f83-f5e7-44a0-7d8abe58aa12@cisco.com>
Date: Fri, 3 Nov 2017 10:40:16 +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: <20171103101225.GJ12688@spritelink.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-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, 03 Nov 2017 10:40:22 -0000

On 03/11/2017 10:12, Kristian Larsson wrote:
> On Fri, Nov 03, 2017 at 09:30:01AM +0000, Robert Wilton wrote:
>>
>> On 03/11/2017 08:42, Kristian Larsson wrote:
>>> On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
>>>> On 02/11/2017 16:41, Kristian Larsson wrote:
>>>>> Are we seeking to have a single style of attachment points? I
>>>>> think that's difficult in reality. Linux has one style, where a
>>>>> single global "ACL" is defined. Most routers use per interface
>>>>> ACL and as seen, they split it up on ethernet vs IP (and v4 vs
>>>>> v6). I doubt one can be said to be better than the other so
>>>>> trying to argue that everyone should converge on one way is
>>>>> pointless. Similarly supporting every different style is also
>>>>> futile as it's completely against the point of standardisation.
>>>>>
>>>>> The pragmatic compromies is likely to support a few ways and any
>>>>> vendor that needs something radically different need to build
>>>>> their own model, do augment, deviate, refine or whatever. Other
>>>>> thoughts?
>>>> For interface attachments I think that the approach in the draft looks OK,
>>>> and reasonably generic, but will need vendor deviations. This is probably
>>>> OK.
>>> I don't agree. Given the length we've gone in trying to convey the
>>> match capabilities of the platform I think we can afford to give
>>> implementors some options when it comes to attachment too! :)
>> I  agree that interface vs global are two different styles, and happy if the
>> model supports both.
> Cool.
>
>
>
>>> As for the per-interface style options
>>>   * current draft; a list of ACLs of varying "type", evaluated in
>>>     specified order, per-interface and per direction
>>>   * three separate ACLs for ethernet, ipv4 and ipv6 and
>>>     per-interface and per direction
>> I think that the current model accommodates both of these.
>>
>> For the 3 separate ACLs, the vendor would "deviate" the model with
>> additional constraints so that there could only be one ACL of each type in
>> the list for an interface.
> Fair enough. I actually discussed this solution off-list
> yesterday evening but failed to bring it up as a potential
> solution now ;)
>
>
>> Given that the model allows mixed ACLs, this approach still seems reasonable
>> and quite generic to me.
> Sure. I guess the XPath on IOS XR, which supports one eth acl,
> one ipv4 acl and one ipv6 acl per interface becomes a little
> tricky. Like we have to do count() based on acl-type I guess to
> prevent two ACLs of the same type being set (or say that the
> translation mechanism should logically merge multiple ACLs).
Yes.  I thought XR either allowed a v4 and  a v6 ACLs, or no IP ACL and 
just an Ethernet ACL.

If so the constraint should be something very roughly like:
- deviate add max-elements 2
- deviate add unique "type"
- deviate add must (count(set-name) != 2, or acl_type != eth).

Or, if one of each type is allowed, then this would just be:
- deviate add max-elements 3
- deviate add unique "type"

>
> JUNOS also has different attachment points that each accept a
> list of ACLs so it's just a matter of putting a constraint on
> accepted acl-type and the translation mechanism just sorts based
> on acl-type.
>
> I'm happy with this :)
Cool.

Rob

>
>     kll
>


From nobody Fri Nov  3 05:44: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 B489C13FDE6 for ; Fri,  3 Nov 2017 05:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.336
X-Spam-Level: *
X-Spam-Status: No, score=1.336 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, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfYLV1pnNmOM for ; Fri,  3 Nov 2017 05:44:23 -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 AB9A813FDDE for ; Fri,  3 Nov 2017 05:44:23 -0700 (PDT)
Received: by mail-pg0-x241.google.com with SMTP id l24so2363160pgu.11 for ; Fri, 03 Nov 2017 05:44: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=q9zB0b5ivgYbBBW81JnGGozIQvpi1f8PELa4eC/VYwo=; b=IVtQOjBiVEZzf7HeqPTIfExpOwHSH85DllUPiN3wvzn3dM3Tqs3Q97mVvRicfslOY2 /pEKl9hiR/emEOS6RB4J57+KqNZvxeArbw3RJIWX3s/aTu7TwVU+f3eO5vR1n9w0AbOS Boep5XIrZnGpoLw3ZlI1UPDhC/jb+3zo1o7A7hVjwLJ0eb7NKcdZLlX8clIRgjmWg7Zf 1p+lUZA2rufzNBCZKrAeaPpVquwsiWsybBe8wd4pzg4FLRoiaF6kLzYXEgvvTZfIbLY3 trXfZOCGoq8V5piw9W4l9o/AI2RuYZsgJpaO1YnXJbmbF8eQK5SaoH0lw8ez9if560cT lAXw==
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=q9zB0b5ivgYbBBW81JnGGozIQvpi1f8PELa4eC/VYwo=; b=L7SDna9JaJHES2nYj/q9eWrnd9tYLHd8ip5PFDmS9bIdhnpJFOn6MY5vs/umXbyRqh KFBl7nuTO5GZIxYNTFtK198FcOuSBF2PiGg7/T9m6FBYmoyGRyr+EohRCUqhoJ1fmllW ox5ysb2Dkxx0ykGOjOqoam9Zpj1ewP1YjU+0ofwmDM+iI+Ns1J295Dp0EQH9C5VSk7yw 7/q3SEjSXXk7oHe5DzfLfBejUDyxml8lDhSqLDaTiB7FmsHWJuBRXVKIiGzlkR4UMMwL M7sAbQdV697HguJ9ay16gLSGnVbYwAO6XJPVocFSzEeRZb3DCPItTD/8D4faRyTAwRuR a1+Q==
X-Gm-Message-State: AMCzsaXYRPFeG7lORv3nvXYz7s06XlPl4Sxjq61DKO1OHMLS4DoAKsQC C45YDvua16BpMFnEaSCE4Ku6T32x
X-Google-Smtp-Source: ABhQp+S5ym1HEXL47Nhpcch/G8W4WTSs0Pk3W0yB1XGs3p0AShFM+QzSES9WQwa3WNhUpWarXUxLuA==
X-Received: by 10.84.133.163 with SMTP id f32mr6729914plf.385.1509713062933; Fri, 03 Nov 2017 05:44:22 -0700 (PDT)
Received: from [172.20.10.3] ([101.2.190.9]) by smtp.gmail.com with ESMTPSA id b23sm11348795pfm.148.2017.11.03.05.44.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Nov 2017 05:44:22 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Mahesh Jethanandani 
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <20171103085244.GG12688@spritelink.se>
Date: Fri, 3 Nov 2017 18:14:11 +0530
Cc: Martin Bjorklund , rwilton@cisco.com, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0587EC2C-6B31-409D-B2A4-649EECEEB45A@gmail.com>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com> <51CEDFCB-88CF-4066-8428-55BF7521D1F0@gmail.com> <20171103085244.GG12688@spritelink.se>
To: Kristian Larsson 
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, 03 Nov 2017 12:44:25 -0000

Please do, and we can discuss the changes on the mailing list.=20

Thanks.=20

Mahesh Jethanandani=20
mjethanandani@gmail.com

> On Nov 3, 2017, at 2:22 PM, Kristian Larsson  wro=
te:
>=20
>> On Thu, Nov 02, 2017 at 07:10:30PM +0630, Mahesh Jethanandani wrote:
>> Ok. Will update the model to reflect the discussion on this thread.
>=20
> Mahesh, would it be helpful if I prepared changes in the form of
> pull requests on the github repo?
>=20
> I can write code, we can discuss it here and merge once agreed?
>=20
>   kll
>=20
> --=20
> Kristian Larsson                                        KLL-RIPE
> +46 704 264511                                kll@spritelink.net


From nobody Fri Nov  3 06:36: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 F2A2913FAEF for ; Fri,  3 Nov 2017 06:36:46 -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 5BQy9WFV7W8L for ; Fri,  3 Nov 2017 06:36:44 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 460B713FAC5 for ; Fri,  3 Nov 2017 06:36:43 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 599FB1820F79; Fri,  3 Nov 2017 14:36:35 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 54E7618201B0; Fri,  3 Nov 2017 14:36:32 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman , Kent Watsen 
Cc: "netmod\@ietf.org" 
In-Reply-To: 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> 
Mail-Followup-To: Andy Bierman , Kent Watsen , "netmod\@ietf.org" 
Date: Fri, 03 Nov 2017 14:37:41 +0100
Message-ID: <87shdva3fe.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
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: Fri, 03 Nov 2017 13:36:47 -0000

Hi Andy,

thanks for the comments, see inline.

Andy Bierman  writes:

> Hi,
>
> I have read this draft a few times.
> I have not implemented the draft but it seems reasonably constrained.
>
> here are some comments.
>
> Sec 1: seems like a lot of background on YANG and then some explanation
> of the solution.  The problem statement is never really explained.
> Some discussion of building blocks for virtual servers might help.

The third paragraph starts with:

   In some cases these mechanisms are not sufficient; it is often
   necessary that an existing module (or a set of modules) is added to
   the data model starting at a non-root location.

I think this and the subsequent text explains the problem
sufficiently. Do you have any suggestions as to what needs to be said?


>
> Sec. 3.3: there are no examples of multiple level schema -mounts.
> What is the use-case for this complexity?

One use case are the LNE and NI levels combined. Details are in appendix A.

>
> Sec. 4: an instance document showing the config for the example would
> help

Such an example is in appendix A.3. Sec. 4 should refer to it though.

>
> Sec. 5: A NETCONF example of an RPC converted to action would help.

This is a good idea. We can expand appendix A.4 by showing the action to
which the ietf-isis:clear-adjacency RPC is conceptually converted

> Also mention action converted to deeper nested action would help.

An action is attached to a node, and it is actually that node that
becomes nested. It is pretty much the same as actions defined inside a
grouping, so I don't think it needs extra explanation.

> Sec. A.4 has a very terse RESTCONF example.
>
> Sec. 8: There are no examples using the mount-point extension-stmt

We are referring to the LNE and NI modules that use this extension
statement.

> Why is this restriction in the text? It is not explained.
>
>           The 'mount-point' statement MUST NOT be used in a YANG
>           version 1 module, neither explicitly nor via a 'uses'
>           statement.

I don't know the reason for this CLR. Martin?

>
>
> I do not understand why the mount-point subtree is needed twice in the YANG
> module.
> Why is the list duplicated under each schema entry?

Because the structure is recursive, thus allowing any number of mount
levels. We need to refer to mount points at the top level, but then there
can be mount points inside each subschema.

> An example showing the entire YANG module would help.

What do you mean by the entire YANG module? Section 8 shows it in its
entirety.

> Seems like a lot of duplication of the YANG library.

Well, yes, we could simplify it by integrating YANG library with
"schema-mounts" data. This is what I proposed earlier:

https://www.ietf.org/mail-archive/web/netmod/current/msg18045.html

>
> Why is the entire schema-mounts container config=false?

For the same reason why YANG library is config=false. The schema is an
implementation-time thing and the client shouldn't be allowed to tinker
with it at run time.

> There is no standard way to configure the schema mounts?

To some extent you can do it using the "inline" method, which I
personally don't like. I am seriously concerned that we keep mixing up
schema and instance data, see also the recent discussions about tree
diagrams.

Likewise, I could ask: There is no standard way to configure YANG
library?

> All this data is configured via proprietary models, probably
> with even more copies of the YANG library?

I would prefer to treat YANG library, schema mount data and the
specification of available datastores not as normal data but rather as
special metadata that is known beforehand and cannot be changed.

Lada

>
>
>
> Andy
>
>
>
>
> On Fri, Oct 20, 2017 at 2:37 PM, 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
>>
> _______________________________________________
> 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 Nov  3 08:52: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 C3B5313FEA2 for ; Fri,  3 Nov 2017 08:52:11 -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 nPMWjR0x5AsY for ; Fri,  3 Nov 2017 08:52:08 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF9813FE87 for ; Fri,  3 Nov 2017 08:52:07 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 4A3541820F78; Fri,  3 Nov 2017 16:51:59 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id F38B518201B0; Fri,  3 Nov 2017 16:51:56 +0100 (CET)
From: Ladislav Lhotka 
To: Kent Watsen , "netmod\@ietf.org" 
In-Reply-To: 
References: 
Mail-Followup-To: Kent Watsen , "netmod\@ietf.org" 
Date: Fri, 03 Nov 2017 16:53:06 +0100
Message-ID: <87po8z9x5p.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] review of 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: Fri, 03 Nov 2017 15:52:12 -0000

Hi Kent,

thanks for the thorough review, see my responses inline.

Kent Watsen  writes:

> Hi,
>
> I have read this document and think that is almost ready for=20
> publication.  I have five discuss items and a bunch of nits.
>
> Kent // contributor
>
>
> 1. From Section 4:
>
>    Routing configuration inside an NI often needs to refer to interfaces =
(at
>    least those that are assigned to the NI), which is impossible unless s=
uch
>    a reference can point to a node in the parent schema (interface name).
>
> This seems overstated.  Rather it is a result of an earlier design decisi=
on.
> An alternate solution might have exported the global interfaces into a=20
> config false list inside the mount jail.   Was such a solution
> discussed?

Do you mean something like having "symlinks" to interfaces inside the
mount jail? Yes, this was discussed and rejected. According to Martin,
tail-f had made a very bad experience with this approach.

>
>=20=09
> 2. Also from Section 4:
>
>    For every schema mounted using the "use-schema" method, it is possible=
=20
>    to specify a leaf-list named "parent-reference" that contains zero or =
more
>    XPath 1.0 expressions.  Each expression is evaluated with the node in =
the
>    parent data tree where the mount point is defined as the context node.=
=20=20
>
> If you can nested-mounts, can you also have nested parent-references?

Yes, but you can only refer to the level directly above.

>
>
> 3. Also from Section 4 (same paragraph):
>
>    For the purposes of
>    evaluating XPath expressions within the mounted data tree, the union
>    of all such nodesets is added to the accessible data tree.
>
> Could this ever result in name collision?

Potentially yes, but sibling nodes with the same name are not an issue
for XPath evaluation.=20

>
>
> 4. Regarding Security Considerations, what about
> /yangmnt:schema-mounts?

You are right, the security considerations should be similar to those in
RFC 7895. It is the same type of risk.

> Also, should how NACM interacts with mounted instance data be
> specified?

This is a good question because, in principle, top-level NACM rules can
address instances of mounted schemas. On the other hand,
ietf-netconf-acm can also be a part of the mounted schema - and if so,
can its rules also address instances in the parent schema via the
parent-reference mechanism?

But I would say it is up to rfc6536bis to deal with these questions.

>
>
> 5. This document does not say anything about how it relates to NMDA.
> Clearly all this is targeted to the conventional datastores, but how
> is it reflected in e.g., ?  Does anything need to be said
> here?

The "use-schema" case shouldn't pose big problems because it is
essentially an externally specified augment. The "inline" case is
somewhat disturbing though: could the embedded YANG library instances be
different in different datastores?

> What if the mounted schema has deviations in .

I don't understand why this could be an issue.

>
>
> Nits (line-break separated):
>
> Is "other optional choices" being vague on purpose?  Should it just
> call out features and deviations?

Yes, it should.

>
> "the YANG library data" seems odd.  Maybe "the instance of the YANG
> Library module"?

It is the same but I prefer the former. Note that the term "instance" is no=
t defined in RFC 7950.

>
> - document, and could be possibly dealt with in a future revision of the =
YANG data modeling language
> + document, as it needs to be dealt with as an update to the YANG data mo=
deling language
>

I am not sure that it *needs* to be done, because it could have
far-reaching consequences.

> - Schema mount applies to the data model
> + Schema mount regards the data model

OK

>
> - This document allows mounting of complete data models only.
> + This document allows mounting of complete modules only.

Correct

>
> - may extend this model by defining
> + may extend this solution by defining

Or perhaps "approach"? I would leave "solution" to marketing folks.

>
> In S3, replace "YANG 1.1" with "YANG 1.1 and its continuances"?

Not sure. For example, next version of YANG can/should turn "mount-point" i=
nto
a built-in statement.

>
> - A "container" or "list" node
> + A 'container' or 'list' node

Actually, following RFC 7950 conventions, no quotes should be used here.

>=20=09
> - of "container" and "list" statements.
> + of the "container" and "list" statements.

OK

>
> - Mounted schemas for all mount points
> + The schema for all mount points

OK

>
> - in the "yangmnt:schema-mounts" container.
> + in the top-level "yangmnt:schema-mounts" container defined in the
> "ietf-yang-schema-mount" module defined in [Section 8].

Section 2.2 defines the relationship between the "yangmnt" prefix and
that module.

>
>  The "refers through its key" part is not clear - are you talking
>  about the mount-point's argument/label?

Yes. Would it be more clear to say this?

   Every entry of this list refers through its key to a mount point
   label and specifies the schema for all mount points with that label.

>
> I don't understand "above those that are defined in the parent
> schema."  - mostly the word "above" is throwing me=E2=80=A6

Yes, "apart from" is better.

>
> - If multiple mount points with the same name
> + If multiple mount points with the same label    (wasn't it called a
> "label" before?)

Right

>
> Regarding "Note, that in this case a mount point", beyond the missing
> comma, an example would be very helpful.  I don't know if I understand
> it right.

You don't, because that sentence is completely wrong - it is yet another
example of mixing up the schema and instance. The idea is that if (for
some strange reason) the mounted schema includes the ietf-yang-library
module, then all *instances* of this (mounted) YANG library must be
identical and have the same content as the "use-schema" data.

This is another reason why I would prefer to have only one YANG library
at the top - it is not regular state data.

>
> In the YANG itself, "State data nodes" didn't parse well, "Protocol
> accessible nodes" instead?

Do you mean the comment? The same or similar comment is in many existing
modules - for example, ietf-yang-library has "Operational state data
nodes". It is true though that it doesn't make much sense here as long
as there are no configuration data.

>
> Regarding the first paragraph in Appendix A, I took me some time to reali=
ze that the rtgwg-device-model included=20
> ietf-network-instance and that those modules define mount-points and
> where.   Please make this easier for first-time readers.

OK, we should try.

>
> In A1, is ietf-network-instance missing?  - might want to double-check
> all

No, because A1 describes only the top (device) level,
ietf-network-instance is a part of the LNE schema in A.2.

>
> In all the examples, but beginning with A2, it might help to show the
> RESTSCONF protocol operation that illustrates the result, so that it's
> clear where in the data model the particular instance is located.
> Anything that can be done to provide more context would be helpful.

It seems to make sense in A.3 - to demonstrate an URI of a resource
inside an NI.

>
> For the 2nd half of A2, what happens if there is an "lne-2", will it
> also get "eth0"?

I think "ietf-logical-network-element:bind-lne-name" leaf should contain
the name of a LNE to to which the interface "eth0" is assigned, so it
looks like a mistake.

>
> - which should include at least
> + which should include at least an instance of
> ietf-yang-library:modules-state and ietf-interfaces:interfaces-state,
> as follows:

But the important point is that only interfaces assigned to the LNE need
to be included, so it is not just "an instance of
ietf-interfaces:interfaces-state". Why do you think the existing text
isn't OK?

Lada

>
>
> Thanks again,
> Kent
>
>
> _______________________________________________
> 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 Nov  3 09:49: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 5D1D813FEF1 for ; Fri,  3 Nov 2017 09:49:44 -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 0toTiiRqFmph for ; Fri,  3 Nov 2017 09:49:38 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE2213FE2A for ; Fri,  3 Nov 2017 09:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5724; q=dns/txt; s=iport; t=1509727777; x=1510937377; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2+mWqbIFHkMnPJ7Nsi5T6trjUXr9GdINtRHaV0pPgnE=; b=UfCpeCz5AysA660KGiPTFoWDXrLZjtvW7Jdptmh4bI+EhmcIUDx2qAt2 qBI3SzAPyI6EPgjY5udXhJDC34Hyy/tH3mWnlr5HguzOP3A4I3e3Lm+mt Xq7BnutaSat72KIqaNczAMOj06NsP3xC7aqhsDzyWZzfU6ZizjHnBtF7n M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAABUnfxZ/4ENJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM0ZG4nB4N2ih+PG5hBEIIBChgLhElPAhqEPT8YAQEBAQEBAQE?= =?us-ascii?q?BayiFHgIEAQEhBA06GwIBCBIIAiYCAgIlCxUCDgIEARKKIxCnFYFtOosQAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEZBYEPgh+CB4M8gyqEZxIYgxWCYgWiDgKLS4kvkzS?= =?us-ascii?q?VaQIRGQGBOAEfOIFsehVJgmSEX3eMIYERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,339,1505779200"; d="scan'208";a="305719415"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2017 16:49:36 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vA3GnaqY030224 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Nov 2017 16:49:36 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, 3 Nov 2017 12:49: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; Fri, 3 Nov 2017 12:49:35 -0400
From: "Acee Lindem (acee)" 
To: Vladimir Vassilev , "netmod@ietf.org" 
Thread-Topic: [netmod]  review of draft-acee-netmod-rfc8022bis-05
Thread-Index: AQHTURgXctumRTeJeEWoGQznR4XUZ6MC5TwA
Date: Fri, 3 Nov 2017 16:49:35 +0000
Message-ID: 
References: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.com>
In-Reply-To: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.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.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [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: Fri, 03 Nov 2017 16:49:44 -0000

SGkgVmxhZGltaXIsIA0KDQpUaGFua3MgZm9yIGNvbW1lbnRzIC0gc2VlIGlubGluZS4NCg0KT24g
MTAvMjkvMTcsIDg6NDMgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIFZsYWRpbWlyIFZhc3NpbGV2
Ig0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB2bGFkaW1pckB0cmFuc3Bh
Y2tldC5jb20+IHdyb3RlOg0KDQo+SGVsbG8sDQo+DQo+SSBoYXZlIHJldmlld2VkIGRyYWZ0LWFj
ZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDUuIE15IGNvbmNsdXNpb24gaXMgdGhhdA0KPnRoZSBZQU5H
IG1vZHVsZXMgcGFydCBvZiB0aGUgZHJhZnQgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSBtb2RpZmll
ZCBpbg0KPmFjY29yZGFuY2Ugd2l0aCBzZWMuICc0LjIzLjMgTk1EQSBUcmFuc2l0aW9uIEd1aWRl
bGluZXMnIG9mDQo+ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2Jpcy0xNC4gVGhlIG1vZGlmaWNh
dGlvbnMgYXJlIGNvaGVyZW50IHdpdGggdGhlDQo+aWV0Zi1pbnRlcmZhY2VzQDIwMTctMDgtMTcu
eWFuZyBtb2R1bGUgaW4NCj5kcmFmdC1pZXRmLW5ldG1vZC1yZmM3Mjc3YmlzLTAwIGFuZCBpZXRm
LWlwQDIwMTctMDgtMjEueWFuZyBtb2R1bGUgaW4NCj5kcmFmdC1pZXRmLW5ldG1vZC1yZmM3Mjc3
YmlzLTAwLg0KPg0KPlZsYWRpbWlyDQo+DQo+DQo+UmV2aWV3IG9mIGRyYWZ0LWFjZWUtbmV0bW9k
LXJmYzgwMjJiaXMtMDUuDQo+VmxhZGltaXIgVmFzc2lsZXYNCj4yMDE3LTEwLTMwDQo+DQo+J0Fi
c3RyYWN0JzoNCj4nSW50cm9kdWN0aW9uIDEnOg0KPiAgLSBCb3RoIEFic3RyYWN0IGFuZCBTZWMg
MS4gY29udGFpbiBkdXBsaWNhdGVkIHRleHQgd2hpY2ggY2FuIGJlIHJlbW92ZWQNCj5mcm9tIEFi
c3RyYWN0LiBUaGUgdGV4dCBpbiBTZWMgMS4gY2FuIGJlIHNpbXBsaWZpZWQ6DQo+DQo+T0xEOg0K
PiAgICBUaGlzIHZlcnNpb24gb2YgdGhlc2UgWUFORyBtb2R1bGVzIHVzZXMgbmV3IG5hbWVzIGZv
ciB0aGVzZSBZQU5HDQo+ICAgIG1vZGVscy4gIFRoZSBtYWluIGRpZmZlcmVuY2UgZnJvbSB0aGUg
Zmlyc3QgdmVyc2lvbiBpcyB0aGF0IHRoaXMNCj4gICAgdmVyc2lvbiBmdWxseSBjb25mb3JtcyB0
byB0aGUgTmV0d29yayBNYW5hZ2VtZW50IERhdGFzdG9yZQ0KPiAgICBBcmNoaXRlY3R1cmUgKE5N
REEpLiAgQ29uc2VxdWVudGx5LCB0aGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgODAyMi4NCj5O
RVc6DQo+ICAgIFRoaXMgdmVyc2lvbiBvZiB0aGUgUm91dGluZyBNYW5hZ2VtZW50IGRhdGEgbW9k
ZWwgc3VwcG9ydHMgdGhlIE5ldHdvcmsNCj4gICAgTWFuYWdlbWVudCBEYXRhc3RvcmUgQXJjaGl0
ZWN0dXJlIChOTURBKQ0KPltJLUQuaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzXS4NCg0K
VGhlIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24gc2VjdGlvbnMgYXJlIGluZGVwZW5kZW50IGFu
ZCB0aGUgaW5mb3JtYXRpb24NCmlzIHBlcnRpbmVudCB0byBib3RoLg0KDQo+DQo+DQo+JzcuICBS
b3V0aW5nIE1hbmFnZW1lbnQgWUFORyBNb2R1bGUnOg0KPg0KPiAgLSBXaHkgc2hvdWxkIGFkZHJl
c3MtZmFtaWx5IGlkZW50aXR5IGJlIGRpZmZlcmVudCBlLmcuIG1hbmRhdG9yeQ0KPiJmYWxzZSI7
IGZvciBzeXN0ZW0gY3JlYXRlZCBSSUJzPyBJIHRoaW5rIHRoaXMgbmVlZHMgc29tZSBleHBsYW5h
dGlvbg0KPihQYWdlIDIxKToNCj4gICAgICAgICAgICAuLi4NCj4gICAgICAgICAgICB1c2VzIGFk
ZHJlc3MtZmFtaWx5IHsNCj4gICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAg
ICAgICJBZGRyZXNzIGZhbWlseSBvZiB0aGUgUklCLg0KPg0KPiAgICAgICAgICAgICAgICAgSXQg
aXMgbWFuZGF0b3J5IGZvciB1c2VyLWNvbnRyb2xsZWQgUklCcy4gIEZvcg0KPiAgICAgICAgICAg
ICAgICAgc3lzdGVtLWNvbnRyb2xsZWQgUklCcyBpdCBjYW4gYmUgb21pdHRlZDsgb3RoZXJ3aXNl
LCBpdA0KPiAgICAgICAgICAgICAgICAgbXVzdCBtYXRjaCB0aGUgYWRkcmVzcyBmYW1pbHkgb2Yg
dGhlIGNvcnJlc3BvbmRpbmcgc3RhdGUNCj4gICAgICAgICAgICAgICAgIGVudHJ5LiI7DQo+ICAg
ICAgICAgICAgICByZWZpbmUgImFkZHJlc3MtZmFtaWx5IiB7DQo+ICAgICAgICAgICAgICAgIG1h
bmRhdG9yeSAiZmFsc2UiOw0KPiAgICAgICAgICAgICAgfQ0KPiAgICAgICAgICAgIH0NCj4gICAg
ICAgICAgICAuLi4NCg0KSSB3aWxsIGRpc2N1c3MgdGhpcyB3aXRoIG15IGNvLWF1dGhvcnMuDQo+
DQo+ICAtIFN1Z2dlc3RlZCBjaGFuZ2Ugb2YgJ2Jhc2UgYWRkcmVzcy1mYW1pbHk7JyAtPiAnYmFz
ZQ0KPnJ0OmFkZHJlc3MtZmFtaWx5OycgZm9yIGlkZW50aXR5IGlwdjQgYW5kIGlwdjYgKHJlZi4N
Cj5kcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTE0I3NlY3Rpb24tNC4yKToNCj4NCj4gICAg
IG8gVGhlIGxvY2FsIG1vZHVsZSBwcmVmaXggTVVTVCBiZSB1c2VkIGluc3RlYWQgb2Ygbm8gcHJl
Zml4IGluDQo+ICAgICBhbGwgImRlZmF1bHQiIHN0YXRlbWVudHMgZm9yIGFuICJpZGVudGl0eXJl
ZiIgb3INCj4iaW5zdGFuY2UtaWRlbnRpZmllciINCj4gICAgICAgICBkYXRhIHR5cGUNCg0KSSBh
ZGRlZCDigJxydDrigJ0gd2hlcmUgaXQgd2FzIG1pc3NpbmcgdG8gdGhlIGlkZW50aXR5cmVmIHN0
YXRlbWVudHMuIFRoaXMNCndpbGwgYmUgaW4gdGhlIG5leHQgcmV2aXNpb24uDQo+DQo+JzguICBJ
UHY0IFVuaWNhc3QgUm91dGluZyBNYW5hZ2VtZW50IFlBTkcgTW9kdWxlJw0KPihpZXRmLWlwdjQt
dW5pY2FzdC1yb3V0aW5nQDIwMTctMTAtMTQueWFuZyk6DQo+JzkuICBJUHY2IFVuaWNhc3QgUm91
dGluZyBNYW5hZ2VtZW50IFlBTkcgTW9kdWxlJw0KPihpZXRmLWlwdjYtdW5pY2FzdC1yb3V0aW5n
QDIwMTctMTAtMTQueWFuZyk6DQo+DQo+DQo+ICAtIFRoZSBpZXRmLWlwdjQtdW5pY2FzdC1yb3V0
aW5nIGFuZCBpZXRmLWlwdjYtdW5pY2FzdC1yb3V0aW5nIG1vZHVsZXMNCj5pbXBvcnQgdGhlIGll
dGYtcm91dGluZyB3aXRob3V0IHJldmlzaW9uIChyZWYuIHJmYzYwODcjc2VjdGlvbi00LjYpOg0K
Pg0KPg0KPiAgICAgbyBUaGUgcmV2aXNpb24tZGF0ZSBzdWJzdGF0ZW1lbnQgd2l0aGluIHRoZSBp
bXBvcnRzIHN0YXRlbWVudCBTSE9VTEQNCj5iZQ0KPiAgICAgcHJlc2VudCBpZiBhbnkgZ3JvdXBp
bmdzIGFyZSB1c2VkIGZyb20gdGhlIGV4dGVybmFsIG1vZHVsZS4iDQoNClNpbmNlIHRoZXNlIG1v
ZHVsZXMgYXJlIGFsbCBpbiB0aGUgc2FtZSBkcmFmdCwgSeKAmWQgcmF0aGVyIGxlYXZlIG91dCB0
aGUNCnJldmlzaW9uIGRhdGUgYXMgaXQgaXMgY2xlYW5lciB3aXRob3V0IGl0LiBMZXQgbWUgZGlz
Y3VzcyB3aXRoIG15DQpjby1hdXRob3JzLiANCj4NCj4NCj4nQXBwZW5kaXggRC4gRGF0YSBUcmVl
IEV4YW1wbGUnOg0KPg0KPiAgLSBUaGUgZXhhbXBsZSBpbiB0aGUgQXBwZW5kaXggRC4gaGFzIG5v
dCBiZWVuIHVwZGF0ZWQgYW5kIGl0IG11c3QgYmUNCj5leHRlbmRlZCBpbiBvcmRlciB0byBkZW1v
bnN0cmF0ZSBhIHVzZWNhc2Ugb2Ygb3BlcmF0aW9uYWwgZGF0YXN0b3JlIG9mDQo+Y29uZmlndXJh
dGlvbiBkYXRhIHdpdGggZGlmZmVyZW50IG9yaWdpbiAoaW50ZW5kZWQsIHN5c3RlbSwgZXRjLikN
Cj5zaW1pbGFyIHRvIHRoZSAnQXBwZW5kaXggQy4gRXhhbXBsZSBEYXRhJyBvZg0KPmRyYWZ0LWll
dGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wNS4NCg0KQWN0dWFsbHksIG5vbmUgb2YgdGhl
IGV4YW1wbGVzIGFjY2Vzc2VkIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGUgaW4gUkZDDQo4MDIyLiBI
b3dldmVyLCBJIGFncmVlIHRoYXQgdGhpcyBzaG91bGQgYmUgYWRkZWQgYW5kIHdl4oCZbGwgd29y
ayBvbiBpdC4NCj4NCj4NCj5OaXRzOg0KPiAgLSBzL0ZpZ3VyZXMgMS9GaWd1cmUgMS8NCj4gIC0g
cy9zeXN0ZW1pbmRlcGVuZGVudGx5L3N5c3RlbSBpbmRlcGVuZGVudGx5Lw0KDQpUaGFua3MgZm9y
IGNhdGNoaW5nIC0gSSBmaXhlZCB0aGVzZSBpbiB0aGUgLTAxIHZlcnNpb24gb2YNCmRyYWZ0LWll
dGYtbmV0bW9kLXJmYzgwMjJiaXMtMDEudHh0Lg0KDQpUaGFua3MsDQpBY2VlIA0KPg0KPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1haWxp
bmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Fri Nov  3 10:03: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 598D513FEFA for ; Fri,  3 Nov 2017 10:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACkjcHlGz4Mf for ; Fri,  3 Nov 2017 10:03:53 -0700 (PDT)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 DA3AD13FAED for ; Fri,  3 Nov 2017 10:03:52 -0700 (PDT)
Received: by mail-ot0-x233.google.com with SMTP id h37so3180873otd.3 for ; Fri, 03 Nov 2017 10:03:52 -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=VAjuImoD1OxKN69TV5PXGmE66jw+dccNg/F9bxnY4+Y=; b=h9mVtXumuThjTGJIjInoYjNwKvb+8W3mFx1cF1pRjFM5YbxqCzNFOyV5wYqy1sm9sj C4gkKZPvCJjL6MVHqREFZel7g8x+NmlWz6w5Z4xCWKsFQktfscOBrJfH0KYx9JBu2vHo LmKpbA1WvjSYEbAp/fcYL1b/vDyXO/fn/F4msHv523YVkEZetPyQ+0PX6xVdIJlRYb59 4iZED2G77VgwWpft+X9r9I6O1ha8X5C8a9CPNrOvvA56CNA9+KP85ruX1PYnFHEkz3nh 2znjdL5/Ax+9Y/F8hPFMM9tbnpt1F+NpHE1dEOZ8rpWxX6Rd4iDtBeM+3oQi0R960xdv iKTQ==
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=VAjuImoD1OxKN69TV5PXGmE66jw+dccNg/F9bxnY4+Y=; b=KVsuYNfZYRtrJZ5g2P6vpGexz3Jfii4zjQCc+wBmeIwmNREDxxE0qyQlItMaSZ1Zt1 9lUrKd3QdOIVLu1TqwoXQuh6jnQS8XcEO0Elg4FCKEFMt2YjZVjfb8IYjviNvHXix/qm fCJyuhrZqN3ppTq/LTtCshUq4ZBOKqp4mAUJAbJ7Tf9Ioh4n9L8BpR8OAPKDVqik/HMe G1FQovmo9ZRM9GCp9XUutXOPtpZNjQtjNU7Jxd1ByMzogLw+BjFpWPHJicp7OY9iqXJF dHsHlLNGQ362OUWQlSeBy99vbvpgoJoS+WKDfI/S5Q28+q7liwHsNtGg6zqd5uMHHap/ mMCw==
X-Gm-Message-State: AJaThX42I494HA1EwWDI7GlcG/FGMJCE72TGBPG/bTdI+sibhDuNd5ri Aa1xcj5udtrdKNAQC4hsVCMJxdnQcwu/HTUa1TU=
X-Google-Smtp-Source: ABhQp+QJVvGKlF1dFllbCNBcf0j6yx6JohhTU/QYAB+S64CrUhw9eYZnp7dIhb7h3HcX2B2Q42Jv4sDbsTJliI1PSmU=
X-Received: by 10.157.33.79 with SMTP id l15mr5697299otd.124.1509728631996; Fri, 03 Nov 2017 10:03:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.7.133 with HTTP; Fri, 3 Nov 2017 10:03:11 -0700 (PDT)
In-Reply-To: 
References:  <6B80D720-C62B-444E-A0D0-E4839F5483D2@gmail.com>    
From: "M. Ranganathan" 
Date: Fri, 3 Nov 2017 13:03:11 -0400
Message-ID: 
To: Mahesh Jethanandani 
Cc: Robert Wilton , netmod@ietf.org
Content-Type: multipart/alternative; boundary="001a11428ea4d14680055d17162b"
Archived-At: 
Subject: Re: [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: Fri, 03 Nov 2017 17:03:55 -0000

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

Hello Mahesh,

On Thu, Nov 2, 2017 at 11:36 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

>
> On Nov 2, 2017, at 11:34 PM, M. Ranganathan  wrote:
>
> Hi Rob, Mahesh,
>
> Thanks for reading.
>
> On Thu, Nov 2, 2017 at 11:00 AM, Robert Wilton  wrote:
>
>> Hi Ranga,
>>
>> Presumably another choice would to keep ACLs defined in one place (i.e.
>> no grouping required), augment with ACL model with your extra MUD + other
>> mgmt data, and then have a reference to that ACL from your model.
>>
>> Thanks,
>> Rob
>>
>
>  In the case of MUD ( which is just a use case driving this need ), there
> are local references from MUD to the ACL. MUD itself augments the ACL
> model.
>
> Augmentation would make (logical and design) sense if you were adding
> nodes that are in some way related to the ACL itself.
>
> If I wanted to Augment ACL with something that is not directly ACL
> relevant then Augmentation makes less sense to me from a design perspective
> (lets say I wanted to define a new YANG model that includes the ACL with
> some other system-relavant meta-data that has nothing to do with ACLs but
> is needed by the system in order to install an ACL).
>
>
> Can you give an example? Would you be for example using the match
> container(s) in the ACL draft, but not use the actions container?
>
>
>

I would need to be able to use all of the containers.

For example, I want to define a YANG model  and auto-generate code in
opendaylight that will accept a JSON structure such as the following

{
 "extension-info" : {
      "auxiliary-information" : "https://some.domain.com/foo";
     "ietf-access-control-list:access-lists": {

          "acl-name": "some-acl-name",
           "acl-type": "ipv4-acl",
           .....

       }

     }
}

Ideally, I don't want to modify the ACL model for this purpose.

Thanks,

Regards,

Ranga.


>
>> _______________________________________________
>> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>>
>>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>


-- 
M. Ranganathan

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


Hello Mahesh,

On Thu, Nov 2, 2017 at 11:36 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

On Nov 2, 2017, at 11:34 PM, M. Ra=
nganathan <mranga@=
gmail.com> wrote:

Hi R=
ob, Mahesh,

Thanks for reading.

On Thu, Nov 2, 2017 at 11:00 AM, R=
obert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  
Hi Ranga,
Presumably another choice wou=
ld to keep ACLs defined in one place
      (i.e. no grouping required), augment with ACL model with your
      extra MUD + other mgmt data, and then have a reference to that ACL
      from your model.
Thanks,

      Rob

=C2=A0In the case o=
f MUD ( which is just a use case driving this need ), there are local refer=
ences from MUD to the ACL. MUD itself augments the ACL model. 

Augmentation would make (logical and design) sense if you were adding=
 nodes that are in some way related to the ACL itself.

If=
 I wanted to Augment ACL with something that is not directly ACL relevant t=
hen Augmentation makes less sense to me from a design perspective (lets say=
 I wanted to define a new YANG model that includes the ACL with some other =
system-relavant meta-data that has nothing to do with ACLs but is needed by=
 the system in order to install an ACL).
<=
/div>

Can you give an example? Woul=
d you be for example using the match container(s) in the ACL draft, but not=
 use the actions container?

=


<=
br>

I would need to be able to use all of the cont=
ainers. 

For example, I want to define a YANG model=C2=A0=
 and auto-generate code in opendaylight that will accept a JSON structure s=
uch as the following

{
=C2=A0"extension-info"=
; : {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "auxiliary-informat=
ion" : "https://some.domain.com/foo";
=C2=A0=C2=A0=C2=A0=C2=A0 "i=
etf-access-control-list:access-lists": {

=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "acl-name": &quo=
t;some-acl-name",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 "acl-type": "ipv4-acl",
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .....

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

Ideally, I don't want to modify the ACL=
 model for this purpose. 

Thanks,

Regar=
ds,

Ranga.
=C2=A0

      

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



    

    







Mahesh Jethanandani








-- 
M. Ranganathan




--001a11428ea4d14680055d17162b--


From nobody Fri Nov  3 10:31: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 45A4313FF03; Fri,  3 Nov 2017 10:31:00 -0700 (PDT)
X-Quarantine-ID: <9q7GYEHfeqAt>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
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 9q7GYEHfeqAt; Fri,  3 Nov 2017 10:30:56 -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 05BBF13FF04; Fri,  3 Nov 2017 10:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37961; q=dns/txt; s=iport; t=1509730255; x=1510939855; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to; bh=ev2d13KHEjnQeempPcdOy+zzFfyYEP/6tej2PAcBFa4=; b=BI3cyRb7P5UIMtHMUz1EMbVg7BHrdhtn4AyQo+dYnxwBbuE8gHtC4B3E d66Er7HdTbn+jGpZ1DisQECm91Ci8EENUGXkuady/+GAisYIQb1PJahKr UJwmt+RJGPT8zJD41i94ELSqL+OJh9InZOL1K9zK5W06D9wkFcAT/9BHU Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQC1pvxZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgkRCgRJuJ4N9ixOQI5ZFEIIBCiWFFgKFFxcBAQEBAQEBAQFrKIU?= =?us-ascii?q?eAQUaCU4IEAkQCiABAgcCAlcGAQwGAgEBF4oIEIkqnWeCJyaKagEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2DLoNagWkph1oFARECAYMzgmIFii6CHYUTkDCHZoMcS4k?= =?us-ascii?q?vghVfiQSHPIotgjSBSIdtgTkhATWBA2k0IQgdFUmCZAmCUxwZgU9ANgGNMQEBA?= =?us-ascii?q?Q?=
X-IronPort-AV: E=Sophos;i="5.44,339,1505779200"; d="scan'208,217";a="52522"
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; 03 Nov 2017 17:30:52 +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 vA3HUp8I020644; Fri, 3 Nov 2017 17:30:51 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: Fri, 3 Nov 2017 18:30:52 +0100
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: 
Content-Type: multipart/alternative; boundary="------------8089E1673C08B81B6A9250AA"
Content-Language: en-US
Archived-At: 
Subject: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [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: Fri, 03 Nov 2017 17:31:00 -0000

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

Dear all,

Let me present this draft 
https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/

                     New YANG Module Update Procedure
                 draft-clacla-netmod-yang-model-update-01

Abstract

    This document specifies a new YANG module update procedure in case of
    non backward-compatible changes, as an alternative proposal to the
    YANG 1.1 specifications.  This document updates RFC 7950.


Problem statement:
Changing a YANG module name each time there is a non backward compatible 
change (as RFC7950 requires) adds a lot of complexity to automation, 
from an import and service composition point of view.

Solution:
We need a different mechanism. The solution in the draft is based on the 
semantic versioning YANG extension: it was proposed openconfig in the 
past and is currently used by the openconfig YANG modules

Note: there might other solutions, such as new YANG keywords, but at 
this point in time, it's important to recognize that we need to change 
the way we produce YANG modules at the IETF. Let's discuss on the list 
and during the NETMOD meeting.

Regards, Benoit.
> 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)
>>>>>
>>>>>
>>>>>
>>>>>
>>
>


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


  
    
  
  
    
Dear all,

      

      Let me present this draft https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/

      
                    New YANG Module Update Procedure
                draft-clacla-netmod-yang-model-update-01

Abstract

   This document specifies a new YANG module update procedure in case of
   non backward-compatible changes, as an alternative proposal to the
   YANG 1.1 specifications.  This document updates RFC 7950.


      

      Problem statement:

      Changing a YANG module name each time there is a non backward
      compatible change (as RFC7950 requires) adds a lot of complexity
      to automation, from an import and service composition point of
      view. 

      

      Solution: 

      We need a different mechanism. The solution in the draft is based
      on the semantic versioning YANG extension: it was proposed
      openconfig in the past and is currently used by the openconfig
      YANG modules 

      

      Note: there might other solutions, such as new YANG keywords, but
      at this point in time, it's important to recognize that we need to
      change the way we produce YANG modules at the IETF. Let's discuss
      on the list and during the NETMOD meeting.

      

      Regards, Benoit. 

    

      
      
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)






                

              

            

          

        

        

      

      

    

    

  


--------------8089E1673C08B81B6A9250AA--


From nobody Fri Nov  3 10:49: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 1716C13FEFD for ; Fri,  3 Nov 2017 10:49:46 -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 dnoz6N_jH3HY for ; Fri,  3 Nov 2017 10:49:42 -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 2666813FF0D for ; Fri,  3 Nov 2017 10:49:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 50F1926; Fri,  3 Nov 2017 18:49:40 +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 O_MzroQ3pqDc; Fri,  3 Nov 2017 18:49: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; Fri,  3 Nov 2017 18:49:40 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C7452011B; Fri,  3 Nov 2017 18:49:40 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u9bndmmZK7RD; Fri,  3 Nov 2017 18:49:38 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A5FF20111; Fri,  3 Nov 2017 18:49:38 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 0229F414A040; Fri,  3 Nov 2017 18:48:11 +0100 (CET)
Date: Fri, 3 Nov 2017 18:48:11 +0100
From: Juergen Schoenwaelder 
To: Benoit Claise 
Cc: NetMod WG 
Message-ID: <20171103174811.vmsgcsdt5u5avxgu@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Benoit Claise , NetMod WG 
References:  <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <708ad6ca-e37b-6236-59b2-80c611b132ae@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] draft-clacla-netmod-yang-model-update-00.txt : Re: [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: Fri, 03 Nov 2017 17:49:46 -0000

My take here is that structured version numbers do only partially
solve the problem. Andy's work years ago on packages offers in my view
a superior foundation for a solution. Once we can bundle modules that
are designed and known to work together into meaningful packages, then
it may be possible to relax some of the strict RFC 7950 update
rules.

Once the NETMOD WG gets the work on NMDA "completed", I believe "YANG
packages" are a worthwhile target to work on. There is a need to get
more structure into the module space, not just additional structured
version numbers.

/js

On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:
> Dear all,
> 
> Let me present this draft
> https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
> 
>                     New YANG Module Update Procedure
>                 draft-clacla-netmod-yang-model-update-01
> 
> Abstract
> 
>    This document specifies a new YANG module update procedure in case of
>    non backward-compatible changes, as an alternative proposal to the
>    YANG 1.1 specifications.  This document updates RFC 7950.
> 
> 
> Problem statement:
> Changing a YANG module name each time there is a non backward compatible
> change (as RFC7950 requires) adds a lot of complexity to automation, from an
> import and service composition point of view.
> 
> Solution:
> We need a different mechanism. The solution in the draft is based on the
> semantic versioning YANG extension: it was proposed openconfig in the past
> and is currently used by the openconfig YANG modules
> 
> Note: there might other solutions, such as new YANG keywords, but at this
> point in time, it's important to recognize that we need to change the way we
> produce YANG modules at the IETF. Let's discuss on the list and during the
> NETMOD meeting.
> 
> Regards, Benoit.
> > 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)
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > 
> > 
> 

> _______________________________________________
> 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 Nov  3 11:05: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 EB45E13FF17 for ; Fri,  3 Nov 2017 11:05:46 -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 G2zXnTg-4wTf for ; Fri,  3 Nov 2017 11:05:43 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FCA13FF1F for ; Fri,  3 Nov 2017 11:05:41 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id 90so4066469lfs.13 for ; Fri, 03 Nov 2017 11:05:41 -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=3jfObJvV6W9svHnpjtLScI1QigbMyPF5s+7Lxp1i0ew=; b=r+GXcRjxc4pCABJazlIUdOVm9WYyuVcZn8gkilyEQ710kLQspTiIKqBJKOZyKxuKH8 OQ1GEL4Jnm2Xm22XyccZ7wIg0m7fTv8DFu7AUJh0dyWo16c1OUo7HZycq3xXWeky0Lwp 34VeEJjufdEXMqLek6ESPMPS81k8OLzwJ8PlYupA3r5kkGUTDoATHyqAnN0vnWk22TDH be4CkAEX5fdvQM1b/sHb2Ur1W7eZG2lwjzPO2B8AefNaz1TirN0qNgG/4rFqr+fq3Nz1 LOtwD/IFyEjWjvH4N6b+Yc5nHCm9r8g05c6rnbTdrHPlmP+eS08Vk13ZOyw+neA4vu2h 1Psw==
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=3jfObJvV6W9svHnpjtLScI1QigbMyPF5s+7Lxp1i0ew=; b=k+wVV4p9MLtuyi4HjNBeYslzpamWW03KEHdqnSIjK5kmhwn5RWxReyzSpuU1FzujW8 QnKAL5m+uYSgcHc/Ti2jIg89rvFl6cALIQFW1tWS9bwyfRgdQMp8yAX+7zNnQ8yZ1ZC8 YaV3rH1zXaUfX7/45Cfaq0IJWm5+7vSUcm8mxrKqN6eRWm/6TPiCbHb7HrAAXWjHDRe2 RJlYedrXq0pL4E/ZMg/vJb80JQLGqpABBtErmFzDTB/g1yq56mhZlIW38rVBG9/HXcUa UWGIVsJP6xKyJZ7xJTdwpotCUOG/tJvABht8VYBtisAIzmalxMR9wpdlvwIov8ypRWxy 56Bg==
X-Gm-Message-State: AMCzsaUQEIJEGmo4VpCQbDjbCA7cqggdRxOWYZ4wUnYoJiaEnGgOm34h wogAO8hDdfU0lCRRYz4wzSTZwYdn4yWLwkg2MxNl2Q==
X-Google-Smtp-Source: ABhQp+QYk9TmuiOolRkYex4+30Z1oYd8E8OTPD4t3rZswNX2QV7RoESEqdw6oMbd85Cblpgsy3qnsbS7O//8YmCegiI=
X-Received: by 10.46.2.197 with SMTP id y66mr3251090lje.151.1509732339694; Fri, 03 Nov 2017 11:05:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Fri, 3 Nov 2017 11:05:38 -0700 (PDT)
In-Reply-To: <20171103174811.vmsgcsdt5u5avxgu@elstar.local>
References:  <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com>   <20171103174811.vmsgcsdt5u5avxgu@elstar.local>
From: Andy Bierman 
Date: Fri, 3 Nov 2017 11:05:38 -0700
Message-ID: 
To: Juergen Schoenwaelder , Benoit Claise , NetMod WG 
Content-Type: multipart/alternative; boundary="94eb2c1cddead0959d055d17f3c9"
Archived-At: 
Subject: Re: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [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: Fri, 03 Nov 2017 18:05:47 -0000

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

On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> My take here is that structured version numbers do only partially
> solve the problem. Andy's work years ago on packages offers in my view
> a superior foundation for a solution. Once we can bundle modules that
> are designed and known to work together into meaningful packages, then
> it may be possible to relax some of the strict RFC 7950 update
> rules.
>
> Once the NETMOD WG gets the work on NMDA "completed", I believe "YANG
> packages" are a worthwhile target to work on. There is a need to get
> more structure into the module space, not just additional structured
> version numbers.
>
>
I agree ;-)

It is nice to have a way to know current implementations will probably
break if they upgrade to the new version. It is even nicer if the APIs
are stable and don't break existing code.

It is not encouraging that the IETF cannot produce stable YANG modules
published in RFCs.  We expect I-Ds to ignore the YANG update rules,
but not RFC versions.

Since the semantic versioning is only per-module, it is not usefull for
determining if module foo will work with module bar.  If it is OK
to break backward-compatibility then it will become increasingly
difficult to just use the latest version of a module. Real interoperability
at the granularity of modules will become more difficult. YANG packages
can dramatically reduce the number of API permutations.


/js
>


Andy


>
> On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:
> > Dear all,
> >
> > Let me present this draft
> > https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
> >
> >                     New YANG Module Update Procedure
> >                 draft-clacla-netmod-yang-model-update-01
> >
> > Abstract
> >
> >    This document specifies a new YANG module update procedure in case of
> >    non backward-compatible changes, as an alternative proposal to the
> >    YANG 1.1 specifications.  This document updates RFC 7950.
> >
> >
> > Problem statement:
> > Changing a YANG module name each time there is a non backward compatible
> > change (as RFC7950 requires) adds a lot of complexity to automation,
> from an
> > import and service composition point of view.
> >
> > Solution:
> > We need a different mechanism. The solution in the draft is based on the
> > semantic versioning YANG extension: it was proposed openconfig in the
> past
> > and is currently used by the openconfig YANG modules
> >
> > Note: there might other solutions, such as new YANG keywords, but at this
> > point in time, it's important to recognize that we need to change the
> way we
> > produce YANG modules at the IETF. Let's discuss on the list and during
> the
> > NETMOD meeting.
> >
> > Regards, Benoit.
> > > 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  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)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > >
> >
>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
My take here is that structured version numbers do o=
nly partially

solve the problem. Andy's work years ago on packages offers in my view<=
br>
a superior foundation for a solution. Once we can bundle modules that

are designed and known to work together into meaningful packages, then

it may be possible to relax some of the strict RFC 7950 update

rules.



Once the NETMOD WG gets the work on NMDA "completed", I believe &=
quot;YANG

packages" are a worthwhile target to work on. There is a need to get
more structure into the module space, not just additional structured

version numbers.



I agree ;-)

I=
t is nice to have a way to know current implementations will probably
=

break if they upgrade to the new version. It is even nicer if the APIs=

are stable and don't break existing code.

It is not encouraging that the IETF cannot produce stable YANG modul=
es
published in RFCs.=C2=A0 We expect I-Ds to ignore the YANG upd=
ate rules,
but not RFC versions.

Since t=
he semantic versioning is only per-module, it is not usefull for
=
determining if module foo will work with module bar.=C2=A0 If it is OK
to break backward-compatibility then it will become increasingly
difficult to just use the latest version of a module. Real interopera=
bility
at the granularity of modules will become more difficult. =
YANG packages
can dramatically reduce the number of API permutati=
ons.



/js
=C2=A0

Andy
=C2=
=A0



On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:

> Dear all,

>

> Let me present this draft

> https://datatracker.ietf=
.org/doc/draft-clacla-netmod-yang-model-update/

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0New YANG Module Update Procedure

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cla=
cla-netmod-yang-model-update-01

>

> Abstract

>

>=C2=A0 =C2=A0 This document specifies a new YANG module update procedur=
e in case of

>=C2=A0 =C2=A0 non backward-compatible changes, as an alternative propos=
al to the

>=C2=A0 =C2=A0 YANG 1.1 specifications.=C2=A0 This document updates RFC =
7950.

>

>

> Problem statement:

> Changing a YANG module name each time there is a non backward compatib=
le

> change (as RFC7950 requires) adds a lot of complexity to automation, f=
rom an

> import and service composition point of view.

>

> Solution:

> We need a different mechanism. The solution in the draft is based on t=
he

> semantic versioning YANG extension: it was proposed openconfig in the =
past

> and is currently used by the openconfig YANG modules

>

> Note: there might other solutions, such as new YANG keywords, but at t=
his

> point in time, it's important to recognize that we need to change =
the way we

> produce YANG modules at the IETF. Let's discuss on the list and du=
ring the

> NETMOD meeting.

>

> Regards, Benoit.

> > On 10/12/2017 3:30 PM, Benoit Claise wrote:

> > > Hi Lou,

> > > >

> > > > So circling back to the original question: what do we d=
o about

> > > > the non backward-compatible module being defined in rfc=
8049bis?

> > > >

> > > > While being sympathetic to many of the comments made be=
low as

> > > > well as the "do over" concept, I find the com=
ments 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 o=
f the

> > > > group before asking the authors make this change.

> > > >

> > > Since this draft is AD sponsored, I'll evaluate the cons=
ensus on

> > > RFC8049bis.

> > > Moving to ietf-l3vpn-svc-2 is the easy path not to break bac=
kward

> > > compatibility. However, since ietf-l3vpn-svc is unimplementa=
ble (it

> > > has broken XPATH expressions, so a compliant implementation =
is

> > > impossible), so technically, ietf-l3vpn-svc does not even ex=
ist.

> > 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 transitio=
n: 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 iss=
ue discussed

> > > > below, but this is not a new issue it's just the fi=
rst time

> > > > we'll actually executing the steps envisioned as pa=
rt of the

> > > > rules laid out in yang. My personal take away is that m=
eans that

> > > > we should immediately start work on an extension defini=
ng along

> > > > the lines of=C2=A0 ' *_obsolete|update_*' menti=
oned below.

> > > >

> > > I believe that option 1 is the more pragmatic and complete s=
olution.

> > > 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 prob=
lem is:

> > > > > RFC8049 is broken. The small problem is: trying to=
 maintain

> > > > > backward compatibility.

> > > > > draft-wu-l3sm-rfc8049bis has rightly focused on th=
e big problem.

> > > > >

> > > > > Let me extend the scope of this email thread from =
"handling

> > > > > module incompatibility" to "handling mod=
ule incompatibility

> > > > > and NMDA transition".

> > > > > As I mentioned in the past (see "semver.org compa=
rison of

> > > > > two YANG modules" email in NETMOD), I believe=
 the IETF will

> > > > > have to change its way of working in terms of back=
ward

> > > > > compatibility. See also the email "ietf-routi=
ng or

> > > > > ietf-routing-2? module naming convention for NMDA<=
br>
> > > > > transition. Re: [netmod] upcoming adoptions" =
in NETMOD.

> > > > >

> > > > > However, we will have to tackle this discussion on=
e day or the other:

> > > > > - we need _an automatic way_ to make the link betw=
een the

> > > > > YANG module in RFC8049 and the YANG module in

> > > > > draft-wu-l3sm-rfc8049bis, or any non backward comp=
atible

> > > > > YANG modules.

> > > > > - we need _an automatic way_ to make the link betw=
een the

> > > > > YANG module in RFC8022 and the YANG module in

> > > > > draft-acee-netmod-rfc8022bis, or any new YANG modu=
le names

> > > > > used for NMDA transition.

> > > > > Note: actually, we face two different problems.
> > > > > draft-wu-l3sm-rfc8049bis might be declared backwar=
d

> > > > > incompatible with RFC8049, while RFC8022bis is bac=
kward

> > > > > compatible with RFC8022. The RFC8022bis went for a=
 new YANG

> > > > > module name ietf-routing-2 to avoid to document th=
e -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 openc=
onfig way.

> > > > > See draft-clacla-netmod-model-catalog (and
> > > > > draft-openconfig-netmod-model-catalog before)=


> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 // extension statements=


> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extension =
openconfig-version {

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg=
ument "semver" {

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0yin-element false;

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0des=
cription

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0"The OpenConfig version number for the module. This is

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0expressed as a semantic version number of the form:

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0x.y.z

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 where:

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0* x corresponds to the major version,

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0* y corresponds to a minor version,

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0* z corresponds to a patch version.

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0This version corresponds to the model file within which it is

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0defined, and does not cover the whole set of OpenConfig models.

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Where several modules are used to build up a single block of

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0functionality, the same module version is specified across each

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0file that makes up the module.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0A major version number of 0 indicates that this model is still

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0in development (whether within OpenConfig or with industry

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0partners), and is potentially subject to change.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Following a release of major version 1, all modules will

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0increment major revision number where backwards incompatible

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0changes to the model are made.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0The minor version is changed when features are added to the

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0model that do not impact current clients use of the model.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0The patch-level version is incremented when non-feature changes

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0(such as bugfixes or clarifications to human-readable

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0descriptions that do not impact model functionality) are made

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0that maintain backwards compatibility.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0The version number is stored in the module meta-data.";

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

> > > > >

> > > > > Similarly, we always keep the same YANG module nam=
e in case

> > > > > of NMDA transition. So ietf-routing-2 should be ch=
anged back

> > > > > to ietf-routing.

> > > > > The email thread "[Rtg-dt-yang-arch] ietf-rou=
ting or

> > > > > ietf-routing-2? module naming convention for NMDA<=
br>
> > > > > 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 d=
o we make

> > > > > the link with the previous module?

> > > > > Then ...=C2=A0 What? We create extension that will=
 link the

> > > > > draft-wu-l3sm-rfc8049bis YANG module to the RFC804=
9 YANG

> > > > > module? Same principle as #1, but just more comple=
x.

> > > > > Or we have a new YANG keyword (this implies YANG 2=
.0)

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0<CODE BEGINS>file"ie=
tf-l3vpn-svc@2017-09-14.yang"

> > > > >=C2=A0 =C2=A0 =C2=A0module ietf-l3vpn-svc-2 {

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0yang-version 1.1;

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace "urn:ietf=
:params:xml:ns:yang:ietf-l3vpn-svc";

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix l3vpn-svc;

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*_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 _mo=
dule _to

> > > > > the draft-wu-l3sm-rfc8049bis _document _to lookup =
the IETF

> > > > > "obsolete" flag in order to understand t=
hat the RFC8049 YANG

> > > > > module is obsolete is not an automatic solution.
> > > > > - Using the yangcatalog.org might be a solution a=
s we track

> > > > > the derived semantic, but this is just an offline =
trick.

> > > > > This is not what I call "automatic way"<=
br>
> > > > > - Using the YANG module description field might be=


> > > > > interesting, but again this is not an "automa=
tic way":

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0description

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This YANG module =
defines a generic service configuration

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0model for Layer 3=
 VPNs. This model is common across all

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vendor implementa=
tions. This obsoletes the RFC8049 YANG

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0module, ietf-l3vp=
n-svc@2017-01-2";

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0revision 2017-09-14 {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 description

> > > > >=C2=A0 =C2=A0 =C2=A0"First revision ofRFC8049 =
<https://tools.ietf.org/html/rfc8049>.";

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 reference

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"RFC xxxx: Y=
ANG Data Model for L3VPN Service Delivery";

> > > > >

> > > > >

> > > > > In conclusion, I believe openconfig got this right=
 and that

> > > > > solution #1 is the solution to go ... while waitin=
g for a

> > > > > new YANG keyword in YANG 2.0

> > > > >

> > > > > (*) If you want to change the module from ietf-rou=
ting to

> > > > > ietf-routing-2, then you should follow with all au=
thors of

> > > > > dependent modules to make sure they transition to<=
br>
> > > > > ietf-routing-2

> > > > > In the yangcatalog.org, because I needed the info=
rmation as

> > > > > OPS AD, we created a small script to get that auth=
ors list

> > > > > for IETF drafts. For the ietf-routing, this produc=
es the

> > > > > following

> > > > > {

> > > > > =C2=A0=C2=A0=C2=A0 "output": {

> > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "a=
uthor-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",<=
br>
> > > > > "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&quo=
t;,

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

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

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

> > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

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

> > > > > }

> > > > >

> > > > > 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-interfa=
ces-2, we

> > > > > would have an cross SDO issue ... Btw, there are n=
o

> > > > > automatic ways to extract the authors of YANG modu=
les 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 kno=
w the

> > > > > authors. Time consuming, believe me.

> > > > >

> > > > > Regards, Benoit

> > > > > > Hi,

> > > > > >

> > > > > >=C2=A0 =C2=A0=C2=A0=C2=A0 As part of the my Ro=
uting Directorate review of

> > > > > > draft-wu-l3sm-rfc8049bis I noted that there w=
ere several incompatible

> > > > > > changes being made to the ietf-l3vpn-svc modu=
le without changing the

> > > > > > name.=C2=A0 I raised this with the YANG docto=
rs and others involved with the

> > > > > > draft and it surfaced some topics which reall=
y should be discussed here

> > > > > > in NetMod.

> > > > > >

> > > > > > The background (as explained off-list by othe=
rs, so I hope I have it

> > > > > > right)=C2=A0 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.=C2=A0 L3SM has concluded so the fix i=
s in the individual draft

> > > > > > draft-wu-l3sm-rfc8049bis.=C2=A0 Since the rfc=
8049 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 wi=
th 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 Dr=
s., the general discussion

> > > > > > was heading down the path of using a new modu=
le name, and thereby not

> > > > > > violating YANG module update rules.=C2=A0 Thi=
s lead us back to the a similar

> > > > > > discussion we've been having in the conte=
xt of 8022bis: how best to

> > > > > > indicate that a whole module is being obsolet=
ed.=C2=A0 RFCs do this by adding

> > > > > > 'metadata' to the headers, e.g., &quo=
t;Obsoletes: 8049", but this doesn't

> > > > > > help YANG tooling.=C2=A0 For 8022, we have on=
e approach - publishing an

> > > > > > updated rev of the original module marking al=
l nodes as deprecated - but

> > > > > > that doesn't really make sense for rfc804=
9bis.

> > > > > >

> > > > > > So the discussion for the WG is:

> > > > > >

> > > > > > How do we handle incompatible module changes,=
 notably when one module

> > > > > > 'obsoletes' another module --=C2=A0 f=
rom 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





--

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

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

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



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1cddead0959d055d17f3c9--


From nobody Fri Nov  3 11: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 CBBB713FF2F for ; Fri,  3 Nov 2017 11:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 vi-qZpGpfWEH for ; Fri,  3 Nov 2017 11:17:04 -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 2386013FF2E for ; Fri,  3 Nov 2017 11:17:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4112B1406159; Fri,  3 Nov 2017 19:17:02 +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 V3ancIgTttsU; Fri,  3 Nov 2017 19:17:02 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 13C98140615A; Fri,  3 Nov 2017 19:17:02 +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 RJACspB7NgaT; Fri,  3 Nov 2017 19:17:02 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id DFA141406155; Fri,  3 Nov 2017 19:17:01 +0100 (CET)
To: "Acee Lindem (acee)" , "netmod@ietf.org" 
References: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.com> 
From: Vladimir Vassilev 
Message-ID: 
Date: Fri, 3 Nov 2017 19:17:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] 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: Fri, 03 Nov 2017 18:17:07 -0000

On 11/03/2017 05:49 PM, Acee Lindem (acee) wrote:
> Hi Vladimir,
>
> Thanks for comments - see inline.
>
> On 10/29/17, 8:43 PM, "netmod on behalf of Vladimir Vassilev"
>  wrote:
>
>> 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 t=
he
>> 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 remo=
ved
> >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 80=
22.
>> NEW:
>>     This version of the Routing Management data model supports the Net=
work
>>     Management Datastore Architecture (NMDA)
>> [I-D.ietf-netmod-revised-datastores].
> The Abstract and Introduction sections are independent and the informat=
ion
> is pertinent to both.
>
>>
>> '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 st=
ate
>>                  entry.";
>>               refine "address-family" {
>>                 mandatory "false";
>>               }
>>             }
>>             ...
> I will discuss this with my co-authors.
>>   - 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
> I added =E2=80=9Crt:=E2=80=9D where it was missing to the identityref s=
tatements. This
> will be in the next revision.
I made this one sound credible but later noticed I quoted irrelevant=20
text from draft-ietf-netmod-rfc6087bis-14 ('default' is not 'base'). And=20
the text in RFC7950 '5.4.=C2=A0 Resolving Grouping, Type, and Identity Na=
mes'=20
states that static scoping applies to identifiers in type statements=20
which overrules 7.13 'The "uses" statement'.

My bad. The change is redundant.
>> '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 module=
s
>> import the ietf-routing without revision (ref. rfc6087#section-4.6):
>>
>>
>>      o The revision-date substatement within the imports statement SHO=
ULD
>> be
>>      present if any groupings are used from the external module."
> Since these modules are all in the same draft, I=E2=80=99d rather leave=
 out the
> revision date as it is cleaner without it. Let me discuss with my
> co-authors.
>>
>> '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.
> Actually, none of the examples accessed operational state date in RFC
> 8022. However, I agree that this should be added and we=E2=80=99ll work=
 on it.
>>
>> Nits:
>>   - s/Figures 1/Figure 1/
>>   - s/systemindependently/system independently/
> Thanks for catching - I fixed these in the -01 version of
> draft-ietf-netmod-rfc8022bis-01.txt.
>
> Thanks,
> Acee
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Sat Nov  4 10:38: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 92B3613FBB8 for ; Sat,  4 Nov 2017 10:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LJ-lHCyB7jph for ; Sat,  4 Nov 2017 10:38:46 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 B9A4413FB0F for ; Sat,  4 Nov 2017 10:38:46 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id w134so6700145qkb.0 for ; Sat, 04 Nov 2017 10:38:46 -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=8vBxNYVCgJT6XR3HYM4b0uE8HIegbyJdltnc5nhBR7k=; b=d2Efi7I7D/6kDj7gk4DT4LlAiUdz9AMrtoKXDPu7eQE900YG7jyC38DrMNEIt5rqk8 Wpcoo9iCI+IWugFhV32hR7/PhPZdTjSQqFnJrpekp13Bw1GOkDcZQPtPRa9FM23e34JM vGj9jVLx+0c4z17eYsudmnNl2HRCz5vLmlUQvhnryQNnRYvOAeSH2tdv0BY2kCRiKzrV R/6c19zepOuBRi/h93hPyCr/g8plnrx8dnqKsu44eYusPj2dSQy/7RdjQks2jQ87unI3 X+PyD7RaV1/v4e6IzmrZD5YgT7txLky2BZWzwgUSR8Y/J/cqFsjE4NTrMcwYe0OWm/fp oJ0A==
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=8vBxNYVCgJT6XR3HYM4b0uE8HIegbyJdltnc5nhBR7k=; b=gSPoTqXXF8BP//2yygk/clx2sHqojaYi9kmo1B6lcEG8YDc0qVJdo+cc+7xXe+zriG yMfDQOb/ChITBVq1z0LkldmUjajaXe2UeB379UY1yRvSAMFVFivK3JHdC6CoeqBPx3CX +RuTxEluPPkS0FocGi+VDE2sL37Vs1nZ58npzqaGJnzRWB1KDUNC4zz0XA5UVuQcTRHk vvilHYb3h5SVczvMg8zmITUBnBRKi9YO/w0kAToPRF459e2YKvZ8nNOk+x0H77AGO/5C lH4frLX3pCXwPE4NW+IPJez/qF6vTTY8jiZqzijH+9W0ye+EyeWue6lppesYC/4jCURF xejg==
X-Gm-Message-State: AMCzsaUrHmEKe81+dQVU6c/4z1qNCpvugUYJ9WTziyHW0eq8ewU5t/rm 1AE8yNg/JYDVu+F6eoyPGRN3ZImQJx1Oy2uGIRM=
X-Google-Smtp-Source: ABhQp+SA7KkNy9Qus35okiRFCWhyJnheWDs4nduHsw/kjlkpxKvxbkacrkM2B1MZ5ODuLkynT2ug3gFEpieSsnkwOfY=
X-Received: by 10.55.42.73 with SMTP id q70mr15024771qkh.337.1509817125662; Sat, 04 Nov 2017 10:38:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.109.136 with HTTP; Sat, 4 Nov 2017 10:38:45 -0700 (PDT)
In-Reply-To: <0587EC2C-6B31-409D-B2A4-649EECEEB45A@gmail.com>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com> <51CEDFCB-88CF-4066-8428-55BF7521D1F0@gmail.com> <20171103085244.GG12688@spritelink.se> <0587EC2C-6B31-409D-B2A4-649EECEEB45A@gmail.com>
From: Sonal Agarwal 
Date: Sat, 4 Nov 2017 10:38:45 -0700
Message-ID: 
To: Mahesh Jethanandani 
Cc: Kristian Larsson , netmod@ietf.org
Content-Type: multipart/alternative; boundary="001a114970a673738e055d2bb151"
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: Sat, 04 Nov 2017 17:38:48 -0000

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

Kristian,

In response to one of your previous comments:

*"I'm really bothered by the compound key consisting of acl-type*










*and the acl-name since attachment points then need to referenceboth.  It's
also weird because I don't think choosing theacl-type is really a choice of
the user but more of a limitationof the platform.One approach would be to
change the key to only be the acl-namebut let the acl-type leaf remain,
perhaps make it mandatory ordefault to some unified acl-type. I think it's
still possible toimplement a constraint on this, right? Like if a platform
onlysupports a specific type at some attachment point it can add
aconstraint on the acl-type by doing deref() on the leafref."*

The key for an ACL needs to remain as the name and type. They both uniquely
define the presence of the ACL in config.

Sonal.



On Fri, Nov 3, 2017 at 5:44 AM, Mahesh Jethanandani  wrote:

> Please do, and we can discuss the changes on the mailing list.
>
> Thanks.
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
> > On Nov 3, 2017, at 2:22 PM, Kristian Larsson 
> wrote:
> >
> >> On Thu, Nov 02, 2017 at 07:10:30PM +0630, Mahesh Jethanandani wrote:
> >> Ok. Will update the model to reflect the discussion on this thread.
> >
> > Mahesh, would it be helpful if I prepared changes in the form of
> > pull requests on the github repo?
> >
> > I can write code, we can discuss it here and merge once agreed?
> >
> >   kll
> >
> > --
> > Kristian Larsson                                        KLL-RIPE
> > +46 704 264511                                kll@spritelink.net
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Kristian,

In response to one of your pr=
evious comments:

"I'm really bothered by the compound key cons=
isting of acl-type
and the acl-name since attachment points then need to reference
both.=C2=A0 It's also weird because I don't t=
hink choosing the
acl-type is really a choice of the=
 user but more of a limitation
of the platform.

One approac=
h 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 possib=
le to
implement a constraint on this, right? Like if=
 a platform only
supports a specific type at some at=
tachment point it can add a
constraint on the acl-ty=
pe by doing deref() on the leafref."

The=
 key for an ACL needs to remain as the name and type. They both uniquely de=
fine the presence of the ACL in config.=C2=A0

Sona=
l.



On Fri, Nov 3, 2017 at 5:44 AM, Mahesh Jethanandani <mjethanan=
dani@gmail.com> wrote:
Plea=
se do, and we can discuss the changes on the mailing list.



Thanks.



Mahesh Jethanandani

mjethanandani@gmail.com




> On Nov 3, 2017, at 2:22 PM, Kristian Larsson <kristian@spritelink.net> wrote:

>

>> On Thu, Nov 02, 2017 at 07:10:30PM +0630, Mahesh Jethanandani wrot=
e:

>> Ok. Will update the model to reflect the discussion on this thread=
.

>

> Mahesh, would it be helpful if I prepared changes in the form of

> pull requests on the github repo?

>

> I can write code, we can discuss it here and merge once agreed?

>

>=C2=A0 =C2=A0kll

>

> --

> Kristian Larsson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 KLL-RIPE

> +46 704 26=
4511=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kll@spritelink.net



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a114970a673738e055d2bb151--


From nobody Sat Nov  4 11:01: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 4C17813FBC7 for ; Sat,  4 Nov 2017 11:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPqQC0rThrFb for ; Sat,  4 Nov 2017 11:01:14 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 28E8613FBB8 for ; Sat,  4 Nov 2017 11:01:14 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id n61so6703757qte.10 for ; Sat, 04 Nov 2017 11:01:14 -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=wtcusBII4kTzaidOuxuXdJGnH2LpGgI42vWvykjMA5w=; b=DokrI7xRZp5ol66Kc9eRGsSft1ZOMVbsb49HoowG9ZRN4PIIfDqeacpbQ40eFTRHKG yRWOEYYwApUhO4Vxj0R6qdcT4Lu942uALaydR5X3JRFPkMXI/DMk8P2KC+NnQH0+0Ne0 G8o2P2m4wqrcCZMkGZ0HkEMwXuwBQ21gRjdPsh9rKCty8Titfztrin9eMECsqsp+MmN1 NsJKcAF8tsiyN5viZ32Fh9Fiwkcd9UDXG8h/9pwhIBfF12JtZ7pvTzg24ycrSpAfP3CH i4VosWjkgisuKJRV9Es357NmYj7tZyzGA4KveLTtw8N9Wwuyuny1oSOEtdeTUMmb4J98 2Egg==
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=wtcusBII4kTzaidOuxuXdJGnH2LpGgI42vWvykjMA5w=; b=mMexcsc8M6Tv5+QBmjchiHAlfYalTnYdv8m6SQCkVASUm0umrHLSYd22/xAecKED0s gLaZgwylXmERf8Uni4EjptN6IaPE7qK/Voq68W+KG23gYrNTuNk9ULAtucfGqGSyV2kY DjegbkOLodm2GuzS28NHJCgElD6kF040vEDqGUKGltwKxEZ7E+UJeVaTyCg6lt74q7iA rhP/7D0BrY1f/of6WHDOmfnJBSCL0ovSCVcH77cb/e4kye/gVixgYIkJJxPVtyrpTz8G 4S7GaJZ2XlC7osFMeP/OYxs0fPcYNhM5YDmucW0/JFThUMkuGALzJZhKBibPwjB/ZCbl W4AA==
X-Gm-Message-State: AMCzsaVvOUYONGeuwn98IY4NZeJEyvjYBK7dND18wPGbzjZaSO4sN5W9 5sD1Tps1bdLrvm9LU+0qfff1CocixNL371Mlo/RQGg==
X-Google-Smtp-Source: ABhQp+Rp4Qy9wHJ/iuGK2eFYFsGmPY40tGNArio2bYSF71GtPddbSufnzCReq3IS29AVCEzc9qqHnablzYKKU7ANPTA=
X-Received: by 10.200.7.74 with SMTP id k10mr14959173qth.279.1509818473331; Sat, 04 Nov 2017 11:01:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.109.136 with HTTP; Sat, 4 Nov 2017 11:01:12 -0700 (PDT)
In-Reply-To: <63d922fe-0f83-f5e7-44a0-7d8abe58aa12@cisco.com>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com>  <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <22bb1ad7-070b-68e1-b35a-bce01204b840@cisco.com> <20171103101225.GJ12688@spritelink.se> <63d922fe-0f83-f5e7-44a0-7d8abe58aa12@cisco.com>
From: Sonal Agarwal 
Date: Sat, 4 Nov 2017 11:01:12 -0700
Message-ID: 
To: Robert Wilton 
Cc: Kristian Larsson , netmod@ietf.org
Content-Type: multipart/alternative; boundary="f403043a82ccc73fa9055d2c01bf"
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: Sat, 04 Nov 2017 18:01:16 -0000

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

On Fri, Nov 3, 2017 at 3:40 AM, Robert Wilton  wrote:

>
>
> On 03/11/2017 10:12, Kristian Larsson wrote:
>
>> On Fri, Nov 03, 2017 at 09:30:01AM +0000, Robert Wilton wrote:
>>
>>>
>>> On 03/11/2017 08:42, Kristian Larsson wrote:
>>>
>>>> On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
>>>>
>>>>> On 02/11/2017 16:41, Kristian Larsson wrote:
>>>>>
>>>>>> Are we seeking to have a single style of attachment points? I
>>>>>> think that's difficult in reality. Linux has one style, where a
>>>>>> single global "ACL" is defined. Most routers use per interface
>>>>>> ACL and as seen, they split it up on ethernet vs IP (and v4 vs
>>>>>> v6). I doubt one can be said to be better than the other so
>>>>>> trying to argue that everyone should converge on one way is
>>>>>> pointless. Similarly supporting every different style is also
>>>>>> futile as it's completely against the point of standardisation.
>>>>>>
>>>>>> The pragmatic compromies is likely to support a few ways and any
>>>>>> vendor that needs something radically different need to build
>>>>>> their own model, do augment, deviate, refine or whatever. Other
>>>>>> thoughts?
>>>>>>
>>>>> For interface attachments I think that the approach in the draft looks
>>>>> OK,
>>>>> and reasonably generic, but will need vendor deviations. This is
>>>>> probably
>>>>> OK.
>>>>>
>>>> I don't agree. Given the length we've gone in trying to convey the
>>>> match capabilities of the platform I think we can afford to give
>>>> implementors some options when it comes to attachment too! :)
>>>>
>>> I  agree that interface vs global are two different styles, and happy if
>>> the
>>> model supports both.
>>>
>> Cool.
>>
>>
>>
>> As for the per-interface style options
>>>>   * current draft; a list of ACLs of varying "type", evaluated in
>>>>     specified order, per-interface and per direction
>>>>   * three separate ACLs for ethernet, ipv4 and ipv6 and
>>>>     per-interface and per direction
>>>>
>>> I think that the current model accommodates both of these.
>>>
>>> For the 3 separate ACLs, the vendor would "deviate" the model with
>>> additional constraints so that there could only be one ACL of each type
>>> in
>>> the list for an interface.
>>>
>> Fair enough. I actually discussed this solution off-list
>> yesterday evening but failed to bring it up as a potential
>> solution now ;)
>>
>>
>> Given that the model allows mixed ACLs, this approach still seems
>>> reasonable
>>> and quite generic to me.
>>>
>> Sure. I guess the XPath on IOS XR, which supports one eth acl,
>> one ipv4 acl and one ipv6 acl per interface becomes a little
>> tricky. Like we have to do count() based on acl-type I guess to
>> prevent two ACLs of the same type being set (or say that the
>> translation mechanism should logically merge multiple ACLs).
>>
> Yes.  I thought XR either allowed a v4 and  a v6 ACLs, or no IP ACL and
> just an Ethernet ACL.
>
>

> IOS-XR allows IPV4 and IPV6 ACL's on L3 interfaces. It allows Ethernet
> ACL's on L2 interfaces


   Sonal.


> If so the constraint should be something very roughly like:
> - deviate add max-elements 2
> - deviate add unique "type"
> - deviate add must (count(set-name) != 2, or acl_type != eth).
>
> Or, if one of each type is allowed, then this would just be:
> - deviate add max-elements 3
> - deviate add unique "type"
>
>
>> JUNOS also has different attachment points that each accept a
>> list of ACLs so it's just a matter of putting a constraint on
>> accepted acl-type and the translation mechanism just sorts based
>> on acl-type.
>>
>> I'm happy with this :)
>>
> Cool.
>
> Rob
>
>
>>     kll
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Fri, Nov 3, 2017 at 3:40 AM, Robert Wilton <rwilton@cisco.com&g=
t; wrote:




On 03/11/2017 10:12, Kristian Larsson wrote:



On Fri, Nov 03, 2017 at 09:30:01AM +0000, Robert Wilton wrote:





On 03/11/2017 08:42, Kristian Larsson wrote:



On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:



On 02/11/2017 16:41, Kristian Larsson wrote:



Are we seeking to have a single style of attachment points? I

think that's difficult in reality. Linux has one style, where a

single global "ACL" is defined. Most routers use per interface
ACL and as seen, they split it up on ethernet vs IP (and v4 vs

v6). I doubt one can be said to be better than the other so

trying to argue that everyone should converge on one way is

pointless. Similarly supporting every different style is also

futile as it's completely against the point of standardisation.



The pragmatic compromies is likely to support a few ways and any

vendor that needs something radically different need to build

their own model, do augment, deviate, refine or whatever. Other

thoughts?



For interface attachments I think that the approach in the draft looks OK,<=
br>
and reasonably generic, but will need vendor deviations. This is probably
OK.



I don't agree. Given the length we've gone in trying to convey the<=
br>
match capabilities of the platform I think we can afford to give

implementors some options when it comes to attachment too! :)



I=C2=A0 agree that interface vs global are two different styles, and happy =
if the

model supports both.



Cool.









As for the per-interface style options

=C2=A0 * current draft; a list of ACLs of varying "type", evaluat=
ed in

=C2=A0 =C2=A0 specified order, per-interface and per direction

=C2=A0 * three separate ACLs for ethernet, ipv4 and ipv6 and

=C2=A0 =C2=A0 per-interface and per direction



I think that the current model accommodates both of these.



For the 3 separate ACLs, the vendor would "deviate" the model wit=
h

additional constraints so that there could only be one ACL of each type in<=
br>
the list for an interface.



Fair enough. I actually discussed this solution off-list

yesterday evening but failed to bring it up as a potential

solution now ;)







Given that the model allows mixed ACLs, this approach still seems reasonabl=
e

and quite generic to me.



Sure. I guess the XPath on IOS XR, which supports one eth acl,

one ipv4 acl and one ipv6 acl per interface becomes a little

tricky. Like we have to do count() based on acl-type I guess to

prevent two ACLs of the same type being set (or say that the

translation mechanism should logically merge multiple ACLs).



Yes.=C2=A0 I thought XR either allowed a v4 and=C2=A0 a v6 ACLs, or no IP A=
CL and just an Ethernet ACL.


=C2=A0
IOS-XR allows IPV4 and=
 IPV6 ACL's on L3 interfaces. It allows Ethernet ACL's on L2 interf=
aces

=C2=A0 =C2=A0Sonal.
=C2=A0

If so the constraint should be something very roughly like:

- deviate add max-elements 2

- deviate add unique "type"

- deviate add must (count(set-name) !=3D 2, or acl_type !=3D eth).



Or, if one of each type is allowed, then this would just be:

- deviate add max-elements 3

- deviate add unique "type"







JUNOS also has different attachment points that each accept a

list of ACLs so it's just a matter of putting a constraint on

accepted acl-type and the translation mechanism just sorts based

on acl-type.



I'm happy with this :)



Cool.



Rob







=C2=A0 =C2=A0 kll







_______________________________________________

netmod mailing list

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




--f403043a82ccc73fa9055d2c01bf--


From nobody Sat Nov  4 12:03: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 D1F6D13FBD6 for ; Sat,  4 Nov 2017 12:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.451
X-Spam-Level: 
X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449] 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 bOEjJpudkBRx for ; Sat,  4 Nov 2017 12:03:40 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D7F8113FBC7 for ; Sat,  4 Nov 2017 12:03:40 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1F1FC61027; Sat,  4 Nov 2017 19:03:40 +0000 (UTC)
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net>
User-agent: mu4e 0.9.18; emacs 25.3.1
From: Christian Hopps 
To: Kent Watsen 
Cc: "netmod\@ietf.org" 
In-reply-to: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net>
Date: Sat, 04 Nov 2017 15:03:39 -0400
Message-ID: <871sldyigk.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain
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, 04 Nov 2017 19:03:43 -0000

I've reviewed this draft (-08), and I think it's ready for publication.

A nit, the text:

Page 4 item 3: "The mounted schema is defined by instance data that is
part of the mounted data model."

Seems pretty complex if all it's trying to say is "It is what it is".

Thanks,
Chris.


Kent Watsen  writes:

> 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 Mon Nov  6 01:38: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 D5DEF13FBBC for ; Mon,  6 Nov 2017 01:37:52 -0800 (PST)
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 jtdlt7rYPxBA for ; Mon,  6 Nov 2017 01:37:42 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898AC13FB86 for ; Mon,  6 Nov 2017 01:37:37 -0800 (PST)
Received: from birdie2 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id B978E62D69; Mon,  6 Nov 2017 10:37:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1509961055; bh=QoAAzLjPiLOJMvSN0Lni/c0jGmARSvB0WVqSHUGsme4=; h=From:To:Date; b=WSObTPXbvBXp7G9HSkvdoKrNI+M+y8kk0Jth9jWTRBSodNsyELzNq1n4dJ953qaup 0K9RH8eILXAHgwwSiKACQfrI7e1nVXtJTFuty4zQqXFNRvdY5oVMgpd/xDkvObXL1K QEuJJD0iwu7MLh9AEFwmzd08AHHrWZuvJjJKZL0c=
Message-ID: <1509961121.1828.17.camel@nic.cz>
From: Ladislav Lhotka 
To: Christian Hopps , Kent Watsen 
Cc: "netmod@ietf.org" 
Date: Mon, 06 Nov 2017 10:38:41 +0100
In-Reply-To: <871sldyigk.fsf@chopps.org>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <871sldyigk.fsf@chopps.org>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] 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: Mon, 06 Nov 2017 09:37:53 -0000

On Sat, 2017-11-04 at 15:03 -0400, Christian Hopps wrote:
> I've reviewed this draft (-08), and I think it's ready for publication.
> 
> A nit, the text:
> 
> Page 4 item 3: "The mounted schema is defined by instance data that is
> part of the mounted data model."

So would it be better to say "... is defined by a new instance of YANG library
that is a part of the mounted data model."?

Thanks, Lada

> 
> Seems pretty complex if all it's trying to say is "It is what it is".
> 
> Thanks,
> Chris.
> 
> 
> Kent Watsen  writes:
> 
> > 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
> 
> _______________________________________________
> 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 Nov  6 05:19: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 6E4F413FC15 for ; Mon,  6 Nov 2017 05:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 knkV9n7KX_6L for ; Mon,  6 Nov 2017 05:19:23 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7294113FC18 for ; Mon,  6 Nov 2017 05:19:23 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id E58321AE030A; Mon,  6 Nov 2017 14:19:20 +0100 (CET)
Date: Mon, 06 Nov 2017 14:19:24 +0100 (CET)
Message-Id: <20171106.141924.996087392255055625.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: phil@juniper.net, rwilton@cisco.com, kwatsen@juniper.net, netmod@ietf.org, randy_presuhn@alumni.stanford.edu
From: Martin Bjorklund 
In-Reply-To: 
References:  <201711022116.vA2LGTB3044617@idle.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] 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: Mon, 06 Nov 2017 13:19:35 -0000

Hi,

Trying to summarize this issue.

The problem is which datastore is used to:

    1a. evaluate action ancestor nodes
    1b. evaluate action input/output parameter leafref,
        instance-identifier, must, when
    2.  evaluate rpc input/output parameter leafref,
        instance-identifier, must, when

(Note that the side effects of an action/rpc is not part of this
issue)

I think it would be very weird if 1a and 1b were treated differently,
so I just label them as 1 below.

Possible solutions:

A.  Always use  for 1 and 2.

    (This is what the current nmda draft says).

B.  Let the client specify the datastore for 1, and use 
    for 2.

    (Note that this is trivial in RESTCONF (since the datastore is
    part of the URL), but would require a new parameter for NETCONF
    (or a new ).
    
C.  Let the client specify the datastore for 1 and 2.

    This would require a new generic parameter for how RPCs are
    invoked in both NETCONF and RESTCONF.

D.  Like B, but let the description of the "rpc" statement optionally
    override this.


I prefer B and then D.


/martin




Andy Bierman  wrote:
> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
> 
> > Sorry, if I wasn't clear.  I meant the  element would
> > be directly under , so the system knows where to start
> > looking for data.  Guessing is bad.
> >
> >
> Totally agree guessing is bad.
> Did you see the  proposal in a previous email?
> That is exactly what I proposed, except I do not want to
> overload  so the new template would be a different name.
> 
> I realize the expanded name of the datastore element prevents it from
> being confused with top-level YANG nodes, but the conformance
> is more clear with a new name.
> 
> 
> 
> 
> > Thanks,
> >  Phil
> >
> 
> Andy
> 
> 
> >
> >
> > Andy Bierman writes:
> > >So a server will be required to guess the correct datastore until it
> > >finds the right one that matches the action instance?
> > >
> > >   
> > >       
> > >          
> > >             10
> > >             
> > >                candidate
> > >             
> > >          
> > >        
> > >    
> > >
> > >The server will guess the datastore in some proprietary order and parse
> > >instances of /top/ and /top/list1.  Then it finds the  action
> > >and parses the input to get to the datastore and find out the real
> > datastore
> > >to use.  If the server guessed wrong, then it reparses the 
> > against
> > >the requested datastore.  Hopefully the schema trees match up.
> > >
> > >Will vendors do all the extra work required to support this sort of thing?
> > >I doubt it.
> > >
> > >
> > >Andy
> > >
> > >
> > >
> > >
> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer  wrote:
> > >
> > >> 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
> > >>
> > >
> > >--001a11411b0ad2d58d055cee96cb
> > >Content-Type: text/html; charset="UTF-8"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >
Hi,

So a server will be required to
> > gue=
> > >ss the correct datastore until it
finds the right one that
> > matche=
> > >s the action instance?

=C2=A0
> > =C2=A0<action>=
> > >
=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>
=C2=A0
> > =C2=A0 =
> > >=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> > >=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 =C2=A0
> > =C2=
> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>
=C2=A0 =C2=A0
> > =C2=
> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate<
> > /datas=
> > >tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > =C2=A0</do-=
> > >test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > </list1>
<=
> > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0
> > </a=
> > >ction>

The server will guess the datastore
> > in s=
> > >ome proprietary order and parse
instances of /top/ and
> > /top/list1=
> > >.=C2=A0 Then it finds the <do-test> action
and parses the
> > i=
> > >nput to get to the datastore and find out the real datastore
to
> > u=
> > >se.=C2=A0 If the server guessed wrong, then it reparses the
> > <action> =
> > >against
the requested datastore.=C2=A0 Hopefully the schema
> > trees=
> > > match up.

Will vendors do all the extra work
> > requ=
> > >ired to support this sort of thing?
I doubt
> > it.

 > >iv>

Andy


 > div>

 > >iv>

On Tue,
> > O=
> > >ct 31, 2017 at 11:36 PM, Phil Shafer < > href=3D"mailt=
> > >o:phil@juniper.net" target=3D"_blank">phil@juniper.net>
> > wrote=
> > >:
 > .8ex;border-le=
> > >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

> > >>ii) However, as far as I can see, it doesn't make sense for an
> > acti=
> > >on to

> > >>directly affect the contents of any configuration datastore, that
> > shoul=
> > >d

> > >>be done via a purpose built rpc (like edit-config).

> > >

> > >An example action would be to retrieve the=C2=A0 fingerprint of an ssh

> > >key.=C2=A0 I might want to get the fingerprint of a key in
> > <candidate>=
> > >;

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

> > >

> > >Seems like <startup> 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?=C2=A0 Any specific RPC can define its

> > >own datastore leaf of hard-code the database in the description

> > >(explicitly or implicitly <operational>), but the <action>
> > RPC =
> > >only

> > >gets this if we make a new parameter for it.

> > >

> > >Thanks,

> > >=C2=A0Phil

> > >


> > >
> > >--001a11411b0ad2d58d055cee96cb--
> >


From nobody Mon Nov  6 05:33: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 4E7F413FC1D for ; Mon,  6 Nov 2017 05:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hAdBW9hYCEDe for ; Mon,  6 Nov 2017 05:33:05 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6071C13FB09 for ; Mon,  6 Nov 2017 05:33:05 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 258281404BA for ; Mon,  6 Nov 2017 06:33:04 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id WdZ01w00B2SSUrH01dZ3XV; Mon, 06 Nov 2017 06:33:04 -0700
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=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=sC3jslCIGhcA:10 a=u07AKapRAAAA:8 a=xskcdSivAAAA:8 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=qjV_LLvqQDixxDVRnr0A:9 a=-MjPFmNV3SJqGFfT:21 a=CjuIK1q_8ugA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=B8SJYIqRPU5_XtF5Z38x:22 a=cAcMbU7R10T-QSRYIcO_: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=h8lYsIEO2egpe6zVGJXJeYQZlCv1Y8cLqwJ2KAKbkcU=; b=ZX7qyHhOYSjxh0gHKqt6nKgE0O K4NuOwWhjRpyWhBNVjTa+m9e51CoJqGpmY5n2qWfsM2ydb68kcbIEBiVMwEGBXoh3yRfEI2qY9tnw AxT9Z1hHlQMIfeVmi3n8XFSpq;
Received: from [172.58.185.143] (port=64616 helo=[IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eBhWN-004O66-Un; Mon, 06 Nov 2017 06:33:00 -0700
From: Lou Berger 
To: Martin Bjorklund , 
CC: 
Date: Mon, 06 Nov 2017 08:32:58 -0500
Message-ID: <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171106.141924.996087392255055625.mbj@tail-f.com>
References:  <201711022116.vA2LGTB3044617@idle.juniper.net>  <20171106.141924.996087392255055625.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.143
X-Exim-ID: 1eBhWN-004O66-Un
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) [172.58.185.143]:64616
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Mon, 06 Nov 2017 13:33:12 -0000

Martin,

If I have an RPC or action that changes state, how would the persistence of 
that state be indicated with an NMBA data stores.  I expected it to be 
related to the data store, but I read your mail below as saying otherwise
Thanks,
Lou


On November 6, 2017 8:20:12 AM Martin Bjorklund  wrote:

> Hi,
>
> Trying to summarize this issue.
>
> The problem is which datastore is used to:
>
>     1a. evaluate action ancestor nodes
>     1b. evaluate action input/output parameter leafref,
>         instance-identifier, must, when
>     2.  evaluate rpc input/output parameter leafref,
>         instance-identifier, must, when
>
> (Note that the side effects of an action/rpc is not part of this
> issue)
>
> I think it would be very weird if 1a and 1b were treated differently,
> so I just label them as 1 below.
>
> Possible solutions:
>
> A.  Always use  for 1 and 2.
>
>     (This is what the current nmda draft says).
>
> B.  Let the client specify the datastore for 1, and use 
>     for 2.
>
>     (Note that this is trivial in RESTCONF (since the datastore is
>     part of the URL), but would require a new parameter for NETCONF
>     (or a new ).
>
> C.  Let the client specify the datastore for 1 and 2.
>
>     This would require a new generic parameter for how RPCs are
>     invoked in both NETCONF and RESTCONF.
>
> D.  Like B, but let the description of the "rpc" statement optionally
>     override this.
>
>
> I prefer B and then D.
>
>
> /martin
>
>
>
>
> Andy Bierman  wrote:
>> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
>>
>> > Sorry, if I wasn't clear.  I meant the  element would
>> > be directly under , so the system knows where to start
>> > looking for data.  Guessing is bad.
>> >
>> >
>> Totally agree guessing is bad.
>> Did you see the  proposal in a previous email?
>> That is exactly what I proposed, except I do not want to
>> overload  so the new template would be a different name.
>>
>> I realize the expanded name of the datastore element prevents it from
>> being confused with top-level YANG nodes, but the conformance
>> is more clear with a new name.
>>
>>
>>
>>
>> > Thanks,
>> >  Phil
>> >
>>
>> Andy
>>
>>
>> >
>> >
>> > Andy Bierman writes:
>> > >So a server will be required to guess the correct datastore until it
>> > >finds the right one that matches the action instance?
>> > >
>> > >   
>> > >       
>> > >          
>> > >             10
>> > >             
>> > >                candidate
>> > >             
>> > >          
>> > >        
>> > >    
>> > >
>> > >The server will guess the datastore in some proprietary order and parse
>> > >instances of /top/ and /top/list1.  Then it finds the  action
>> > >and parses the input to get to the datastore and find out the real
>> > datastore
>> > >to use.  If the server guessed wrong, then it reparses the 
>> > against
>> > >the requested datastore.  Hopefully the schema trees match up.
>> > >
>> > >Will vendors do all the extra work required to support this sort of thing?
>> > >I doubt it.
>> > >
>> > >
>> > >Andy
>> > >
>> > >
>> > >
>> > >
>> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer  wrote:
>> > >
>> > >> 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
>> > >>
>> > >
>> > >--001a11411b0ad2d58d055cee96cb
>> > >Content-Type: text/html; charset="UTF-8"
>> > >Content-Transfer-Encoding: quoted-printable
>> > >
>> > >
Hi,

So a server will be required to
>> > gue=
>> > >ss the correct datastore until it
finds the right one that
>> > matche=
>> > >s the action instance?

=C2=A0
>> > =C2=A0<action>=
>> > >
=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>
=C2=A0
>> > =C2=A0 =
>> > >=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
>> > >=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 =C2=A0
>> > =C2=
>> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>
=C2=A0 =C2=A0
>> > =C2=
>> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate<
>> > /datas=
>> > >tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>> > =C2=A0</do-=
>> > >test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>> > </list1>
<=
>> > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0
>> > </a=
>> > >ction>

The server will guess the datastore
>> > in s=
>> > >ome proprietary order and parse
instances of /top/ and
>> > /top/list1=
>> > >.=C2=A0 Then it finds the <do-test> action
and parses the
>> > i=
>> > >nput to get to the datastore and find out the real datastore
to
>> > u=
>> > >se.=C2=A0 If the server guessed wrong, then it reparses the
>> > <action> =
>> > >against
the requested datastore.=C2=A0 Hopefully the schema
>> > trees=
>> > > match up.

Will vendors do all the extra work
>> > requ=
>> > >ired to support this sort of thing?
I doubt
>> > it.

> > >iv>

Andy


> > div>

> > >iv>

On Tue,
>> > O=
>> > >ct 31, 2017 at 11:36 PM, Phil Shafer <> > href=3D"mailt=
>> > >o:phil@juniper.net" target=3D"_blank">phil@juniper.net>
>> > wrote=
>> > >:
> > .8ex;border-le=
>> > >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

>> > >>ii) However, as far as I can see, it doesn't make sense for an
>> > acti=
>> > >on to

>> > >>directly affect the contents of any configuration datastore, that
>> > shoul=
>> > >d

>> > >>be done via a purpose built rpc (like edit-config).

>> > >

>> > >An example action would be to retrieve the=C2=A0 fingerprint of an ssh

>> > >key.=C2=A0 I might want to get the fingerprint of a key in
>> > <candidate>=
>> > >;

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

>> > >

>> > >Seems like <startup> 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?=C2=A0 Any specific RPC can define its

>> > >own datastore leaf of hard-code the database in the description

>> > >(explicitly or implicitly <operational>), but the <action>
>> > RPC =
>> > >only

>> > >gets this if we make a new parameter for it.

>> > >

>> > >Thanks,

>> > >=C2=A0Phil

>> > >


>> > >
>> > >--001a11411b0ad2d58d055cee96cb--
>> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



From nobody Mon Nov  6 06:03: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 33DF513FC1D for ; Mon,  6 Nov 2017 06:03:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hp-tiJdbeHqW for ; Mon,  6 Nov 2017 06:03:23 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C195413FB40 for ; Mon,  6 Nov 2017 06:03:22 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D9B436D3; Mon,  6 Nov 2017 15:03:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id D20shUMnwpVn; Mon,  6 Nov 2017 15:03:18 +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,  6 Nov 2017 15:03:20 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C33BC20116; Mon,  6 Nov 2017 15:03:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 60a9oW4I0ECs; Mon,  6 Nov 2017 15:03:20 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC9BC20111; Mon,  6 Nov 2017 15:03:19 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 07EE0414CFAD; Mon,  6 Nov 2017 15:01:52 +0100 (CET)
Date: Mon, 6 Nov 2017 15:01:52 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: andy@yumaworks.com, netmod@ietf.org
Message-ID: <20171106140152.5kcgjja6yy6n4h3j@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References:  <201711022116.vA2LGTB3044617@idle.juniper.net>  <20171106.141924.996087392255055625.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171106.141924.996087392255055625.mbj@tail-f.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: Mon, 06 Nov 2017 14:03:25 -0000

On Mon, Nov 06, 2017 at 02:19:24PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Trying to summarize this issue.
> 
> The problem is which datastore is used to:
> 
>     1a. evaluate action ancestor nodes
>     1b. evaluate action input/output parameter leafref,
>         instance-identifier, must, when
>     2.  evaluate rpc input/output parameter leafref,
>         instance-identifier, must, when
> 
> (Note that the side effects of an action/rpc is not part of this
> issue)
> 
> I think it would be very weird if 1a and 1b were treated differently,
> so I just label them as 1 below.
> 
> Possible solutions:
> 
> A.  Always use  for 1 and 2.
> 
>     (This is what the current nmda draft says).
> 
> B.  Let the client specify the datastore for 1, and use 
>     for 2.
> 
>     (Note that this is trivial in RESTCONF (since the datastore is
>     part of the URL), but would require a new parameter for NETCONF
>     (or a new ).
>     
> C.  Let the client specify the datastore for 1 and 2.
> 
>     This would require a new generic parameter for how RPCs are
>     invoked in both NETCONF and RESTCONF.
> 
> D.  Like B, but let the description of the "rpc" statement optionally
>     override this.
> 
> 
> I prefer B and then D.
>

I prefer A for now and I believe any of the other options may be
considered in the future (when we can provide proper support of YANG
and the protocols). I also believe that A covers a large number of
real-world use cases.

/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 Nov  6 06:35: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 313F513FC28 for ; Mon,  6 Nov 2017 06:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.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 Sy740SlNdmx5 for ; Mon,  6 Nov 2017 06:35:31 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A836E13F3D5 for ; Mon,  6 Nov 2017 06:35:31 -0800 (PST)
Received: by mail-oi0-x230.google.com with SMTP id j126so7468284oib.8 for ; Mon, 06 Nov 2017 06:35:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CM0sPlWcxxIkPijl4Dcd0lYHJ5uQ/wvlE+24JSIA9gk=; b=VBP477+zz+NCB78WceFj7SqVKZGV/jJyp2/zBnBG5wIdfCETHmx3M1JArvgk1m6CBr rQ66Zu+S1E39T3Wo/RY/tcgZSaMxtfqinP2dLRLb50oiykAFfqvk4ADCrPQaARzwE3ac 14g4lAMTODAH7UWPZL41JSHaTYIfVwUVkXZcoddANUUdx2LUUFHuhJz8lHqe8uxyg30/ imp12reiHrBOB9l4kpzin/Cb2pz24sOZ1j8t5bUXC8DtGaDNDi5imNhW3X8syFoIXDSW HyVb2jh9kRzLVBFwR1ZtLN5l5xrAoo1lmGPfiJNHAqdGKAQf5SuK3Zejl6MyGBY2XA5z LT9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CM0sPlWcxxIkPijl4Dcd0lYHJ5uQ/wvlE+24JSIA9gk=; b=atkyQ6p5aEIHALDDF9MNiQ8Dnp653Qszi+jgZrsYiYVrw9DFyxTCUKy3R7oRTxvqfn pZShiTYyFdC5b5O1i5MTpw8chuRseVUmr4TaRqitWjq9j74bwefPmt6OkDIl3bpQam9a rU3CE8O3Dc/IeGkeorP2ws7NahWqDEeb9XNE5H2WW+h+4vzvSO2n4nYbBkhyKnsy9qgM ZE7XCm6sDRrwpZcL1gEZtPgpJKx+TKVZY8VXFhYrE5S7DfQaL6dEsyTmSKy0TohPhtmT LmYRqBu8u2ted9sE4mmoR19NHtdkdnYpeIHJ8KL/oP3qsjK0xIIJadt0rlm2lRwrdPrI EAoA==
X-Gm-Message-State: AMCzsaVT2gbCNiLtJJawgkpbaT+ikaMDBEc+CoReSkAcwqfTG7CGjZss /oEaCmLDpc6g5nlhZU+1Z8k0QXvg9WeP7ImVdR5rmA==
X-Google-Smtp-Source: ABhQp+SnfP1EOKDadyuzqvdk3u9D782Wrbf4v8S05ZrhLZ8nUC9tpzxbNzUeTN8NgE8GvPgio3Voeq09QMuw+FuFzbI=
X-Received: by 10.202.81.193 with SMTP id f184mr8156174oib.147.1509978930280;  Mon, 06 Nov 2017 06:35:30 -0800 (PST)
MIME-Version: 1.0
References:  <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com>   <20171103174811.vmsgcsdt5u5avxgu@elstar.local> 
In-Reply-To: 
From: Rob Shakir 
Date: Mon, 06 Nov 2017 14:35:19 +0000
Message-ID: 
To: Andy Bierman 
Cc: Juergen Schoenwaelder , Benoit Claise , NetMod WG 
Content-Type: multipart/alternative; boundary="001a113d7832c21066055d515d98"
Archived-At: 
Subject: Re: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [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: Mon, 06 Nov 2017 14:35:36 -0000

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

I agree that semantic versioning is only part of the solution. In
OpenConfig versioning we have the concept of release bundles that have a
semver, these contain modules that are known to work together - and are the
base for compliance descriptions. The individual modules semver has been
useful to mark where there are backwards incompatible changes in an
individual module.

On top of release bundles, we also have feature bundles which describe a
particular implementation's requirements for the modules. A feature bundle
is a description of paths within a release bundle.

We're continuing to gain experience with how well this works, but certainly
I don't see the need for the bundles alleviating the need for the semantic
versions for modules.

r.

On Fri, 3 Nov 2017 at 11:05 Andy Bierman  wrote:

> On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> My take here is that structured version numbers do only partially
>> solve the problem. Andy's work years ago on packages offers in my view
>> a superior foundation for a solution. Once we can bundle modules that
>> are designed and known to work together into meaningful packages, then
>> it may be possible to relax some of the strict RFC 7950 update
>> rules.
>>
>> Once the NETMOD WG gets the work on NMDA "completed", I believe "YANG
>> packages" are a worthwhile target to work on. There is a need to get
>> more structure into the module space, not just additional structured
>> version numbers.
>>
>>
> I agree ;-)
>
> It is nice to have a way to know current implementations will probably
> break if they upgrade to the new version. It is even nicer if the APIs
> are stable and don't break existing code.
>
> It is not encouraging that the IETF cannot produce stable YANG modules
> published in RFCs.  We expect I-Ds to ignore the YANG update rules,
> but not RFC versions.
>
> Since the semantic versioning is only per-module, it is not usefull for
> determining if module foo will work with module bar.  If it is OK
> to break backward-compatibility then it will become increasingly
> difficult to just use the latest version of a module. Real interoperability
> at the granularity of modules will become more difficult. YANG packages
> can dramatically reduce the number of API permutations.
>
>
> /js
>>
>
>
> Andy
>
>
>>
>> On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:
>> > Dear all,
>> >
>> > Let me present this draft
>> > https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
>> >
>> >                     New YANG Module Update Procedure
>> >                 draft-clacla-netmod-yang-model-update-01
>> >
>> > Abstract
>> >
>> >    This document specifies a new YANG module update procedure in case of
>> >    non backward-compatible changes, as an alternative proposal to the
>> >    YANG 1.1 specifications.  This document updates RFC 7950.
>> >
>> >
>> > Problem statement:
>> > Changing a YANG module name each time there is a non backward compatible
>> > change (as RFC7950 requires) adds a lot of complexity to automation,
>> from an
>> > import and service composition point of view.
>> >
>> > Solution:
>> > We need a different mechanism. The solution in the draft is based on the
>> > semantic versioning YANG extension: it was proposed openconfig in the
>> past
>> > and is currently used by the openconfig YANG modules
>> >
>> > Note: there might other solutions, such as new YANG keywords, but at
>> this
>> > point in time, it's important to recognize that we need to change the
>> way we
>> > produce YANG modules at the IETF. Let's discuss on the list and during
>> the
>> > NETMOD meeting.
>> >
>> > Regards, Benoit.
>> > > 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 <
>> https://tools.ietf.org/html/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)
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > >
>> > >
>> >
>>
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 <+49%20421%202003587>         Campus Ring 1 |
>> 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 <+49%20421%202003103>         <
>> http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> 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
>

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


I agree that semantic versioning is only part of the solut=
ion. In OpenConfig versioning we have the concept of release bundles that h=
ave a semver, these contain modules that are known to work together - and a=
re the base for compliance descriptions. The individual modules semver has =
been useful to mark where there are backwards incompatible changes in an in=
dividual module.

On top of release bundles, we also have=
 feature bundles which describe a particular implementation's requireme=
nts for the modules. A feature bundle is a description of paths within a re=
lease bundle.

We're continuing to gain experie=
nce with how well this works, but certainly I don't see the need for th=
e bundles alleviating the need for the semantic versions for modules.
=


r.

On Fri, 3 Nov 2017 at 11:05 Andy Bierman <andy@yumaworks.com> wrote:
On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
=

My take here is that structured version numb=
ers do only partially

solve the problem. Andy's work years ago on packages offers in my view<=
br>
a superior foundation for a solution. Once we can bundle modules that

are designed and known to work together into meaningful packages, then

it may be possible to relax some of the strict RFC 7950 update

rules.



Once the NETMOD WG gets the work on NMDA "completed", I believe &=
quot;YANG

packages" are a worthwhile target to work on. There is a need to get
more structure into the module space, not just additional structured

version numbers.



I agree ;-)
It is nice to have a way to know current implementations will =
probably
break if they upgrade to the new version. It is even nic=
er if the APIs
are stable and don't break existing code.

It is not encouraging that the IETF cannot produce sta=
ble YANG modules
published in RFCs.=C2=A0 We expect I-Ds to ignor=
e the YANG update rules,
but not RFC versions.

Since the semantic versioning is only per-module, it is not usefull =
for
determining if module foo will work with module bar.=C2=A0 If=
 it is OK
to break backward-compatibility then it will become inc=
reasingly
difficult to just use the latest version of a module. R=
eal interoperability
at the granularity of modules will become mo=
re difficult. YANG packages
can dramatically reduce the number of=
 API permutations.



/js
=C2=A0

Andy=

=C2=A0



On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:

> Dear all,

>

> Let me present this draft

> https://datatracker.ietf=
.org/doc/draft-clacla-netmod-yang-model-update/

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0New YANG Module Update Procedure

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cla=
cla-netmod-yang-model-update-01

>

> Abstract

>

>=C2=A0 =C2=A0 This document specifies a new YANG module update procedur=
e in case of

>=C2=A0 =C2=A0 non backward-compatible changes, as an alternative propos=
al to the

>=C2=A0 =C2=A0 YANG 1.1 specifications.=C2=A0 This document updates RFC =
7950.

>

>

> Problem statement:

> Changing a YANG module name each time there is a non backward compatib=
le

> change (as RFC7950 requires) adds a lot of complexity to automation, f=
rom an

> import and service composition point of view.

>

> Solution:

> We need a different mechanism. The solution in the draft is based on t=
he

> semantic versioning YANG extension: it was proposed openconfig in the =
past

> and is currently used by the openconfig YANG modules

>

> Note: there might other solutions, such as new YANG keywords, but at t=
his

> point in time, it's important to recognize that we need to change =
the way we

> produce YANG modules at the IETF. Let's discuss on the list and du=
ring the

> NETMOD meeting.

>

> Regards, Benoit.

> > On 10/12/2017 3:30 PM, Benoit Claise wrote:

> > > Hi Lou,

> > > >

> > > > So circling back to the original question: what do we d=
o about

> > > > the non backward-compatible module being defined in rfc=
8049bis?

> > > >

> > > > While being sympathetic to many of the comments made be=
low as

> > > > well as the "do over" concept, I find the com=
ments 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 o=
f the

> > > > group before asking the authors make this change.

> > > >

> > > Since this draft is AD sponsored, I'll evaluate the cons=
ensus on

> > > RFC8049bis.

> > > Moving to ietf-l3vpn-svc-2 is the easy path not to break bac=
kward

> > > compatibility. However, since ietf-l3vpn-svc is unimplementa=
ble (it

> > > has broken XPATH expressions, so a compliant implementation =
is

> > > impossible), so technically, ietf-l3vpn-svc does not even ex=
ist.

> > 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 ie=
tf@ietf.org

> >

> > Regards, Benoit

> > >

> > > What NETMOD should focus on is closing on the NMDA transitio=
n: 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 iss=
ue discussed

> > > > below, but this is not a new issue it's just the fi=
rst time

> > > > we'll actually executing the steps envisioned as pa=
rt of the

> > > > rules laid out in yang. My personal take away is that m=
eans that

> > > > we should immediately start work on an extension defini=
ng along

> > > > the lines of=C2=A0 ' *_obsolete|update_*' menti=
oned below.

> > > >

> > > I believe that option 1 is the more pragmatic and complete s=
olution.

> > > 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 prob=
lem is:

> > > > > RFC8049 is broken. The small problem is: trying to=
 maintain

> > > > > backward compatibility.

> > > > > draft-wu-l3sm-rfc8049bis has rightly focused on th=
e big problem.

> > > > >

> > > > > Let me extend the scope of this email thread from =
"handling

> > > > > module incompatibility" to "handling mod=
ule incompatibility

> > > > > and NMDA transition".

> > > > > As I mentioned in the past (see "semver.org compa=
rison of

> > > > > two YANG modules" email in NETMOD), I believe=
 the IETF will

> > > > > have to change its way of working in terms of back=
ward

> > > > > compatibility. See also the email "ietf-routi=
ng or

> > > > > ietf-routing-2? module naming convention for NMDA<=
br>
> > > > > transition. Re: [netmod] upcoming adoptions" =
in NETMOD.

> > > > >

> > > > > However, we will have to tackle this discussion on=
e day or the other:

> > > > > - we need _an automatic way_ to make the link betw=
een the

> > > > > YANG module in RFC8049 and the YANG module in

> > > > > draft-wu-l3sm-rfc8049bis, or any non backward comp=
atible

> > > > > YANG modules.

> > > > > - we need _an automatic way_ to make the link betw=
een the

> > > > > YANG module in RFC8022 and the YANG module in

> > > > > draft-acee-netmod-rfc8022bis, or any new YANG modu=
le names

> > > > > used for NMDA transition.

> > > > > Note: actually, we face two different problems.
> > > > > draft-wu-l3sm-rfc8049bis might be declared backwar=
d

> > > > > incompatible with RFC8049, while RFC8022bis is bac=
kward

> > > > > compatible with RFC8022. The RFC8022bis went for a=
 new YANG

> > > > > module name ietf-routing-2 to avoid to document th=
e -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 openc=
onfig way.

> > > > > See draft-clacla-netmod-model-catalog (and

> > > > > draft-openconfig-netmod-model-catalog before)

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 // extension statements=


> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extension =
openconfig-version {

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg=
ument "semver" {

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0yin-element false;

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0des=
cription

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0"The OpenConfig version number for the module. This is

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0expressed as a semantic version number of the form:

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0x.y.z

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 where:

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0* x corresponds to the major version,

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0* y corresponds to a minor version,

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0* z corresponds to a patch version.

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0This version corresponds to the model file within which it is

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0defined, and does not cover the whole set of OpenConfig models.

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Where several modules are used to build up a single block of

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0functionality, the same module version is specified across each

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0file that makes up the module.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0A major version number of 0 indicates that this model is still

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0in development (whether within OpenConfig or with industry

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0partners), and is potentially subject to change.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Following a release of major version 1, all modules will

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0increment major revision number where backwards incompatible

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0changes to the model are made.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0The minor version is changed when features are added to the

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0model that do not impact current clients use of the model.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0The patch-level version is incremented when non-feature changes

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0(such as bugfixes or clarifications to human-readable

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0descriptions that do not impact model functionality) are made

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0that maintain backwards compatibility.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0The version number is stored in the module meta-data.";

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

> > > > >

> > > > > Similarly, we always keep the same YANG module nam=
e in case

> > > > > of NMDA transition. So ietf-routing-2 should be ch=
anged back

> > > > > to ietf-routing.

> > > > > The email thread "[Rtg-dt-yang-arch] ietf-rou=
ting or

> > > > > ietf-routing-2? module naming convention for NMDA<=
br>
> > > > > 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 d=
o we make

> > > > > the link with the previous module?

> > > > > Then ...=C2=A0 What? We create extension that will=
 link the

> > > > > draft-wu-l3sm-rfc8049bis YANG module to the RFC804=
9 YANG

> > > > > module? Same principle as #1, but just more comple=
x.

> > > > > Or we have a new YANG keyword (this implies YANG 2=
.0)

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0<CODE BEGINS>file"ie=
tf-l3vpn-svc@2017-09-14.yang"

> > > > >=C2=A0 =C2=A0 =C2=A0module ietf-l3vpn-svc-2 {

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0yang-version 1.1;

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace "urn:ietf=
:params:xml:ns:yang:ietf-l3vpn-svc";

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix l3vpn-svc;

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*_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 _mo=
dule _to

> > > > > the draft-wu-l3sm-rfc8049bis _document _to lookup =
the IETF

> > > > > "obsolete" flag in order to understand t=
hat the RFC8049 YANG

> > > > > module is obsolete is not an automatic solution.
> > > > > - Using the yangcatalog.org might be a solution a=
s we track

> > > > > the derived semantic, but this is just an offline =
trick.

> > > > > This is not what I call "automatic way"<=
br>
> > > > > - Using the YANG module description field might be=


> > > > > interesting, but again this is not an "automa=
tic way":

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0description

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This YANG module =
defines a generic service configuration

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0model for Layer 3=
 VPNs. This model is common across all

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vendor implementa=
tions. This obsoletes the RFC8049 YANG

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0module, ietf-l3vp=
n-svc@2017-01-2";

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0revision 2017-09-14 {
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 description

> > > > >=C2=A0 =C2=A0 =C2=A0"First revision ofRFC8049 =
<https://tools.ietf.org/html/rfc8049>.";

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 reference

> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"RFC xxxx: Y=
ANG Data Model for L3VPN Service Delivery";

> > > > >

> > > > >

> > > > > In conclusion, I believe openconfig got this right=
 and that

> > > > > solution #1 is the solution to go ... while waitin=
g for a

> > > > > new YANG keyword in YANG 2.0

> > > > >

> > > > > (*) If you want to change the module from ietf-rou=
ting to

> > > > > ietf-routing-2, then you should follow with all au=
thors of

> > > > > dependent modules to make sure they transition to<=
br>
> > > > > ietf-routing-2

> > > > > In the yangcatalog.org, because I needed the info=
rmation as

> > > > > OPS AD, we created a small script to get that auth=
ors list

> > > > > for IETF drafts. For the ietf-routing, this produc=
es the

> > > > > following

> > > > > {

> > > > > =C2=A0=C2=A0=C2=A0 "output": {

> > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "a=
uthor-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&=
quot;,

> > > > > "draft-ietf-teas-yang-rsvp-te@ietf.org&qu=
ot;,

> > > > > "draft-ietf-mpls-mldp-yang@ietf.org",
> > > > > "draft-zhao-pim-igmp-mld-snooping-ya=
ng@ietf.org",

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

> > > > > "draft-acee-rtgwg-yang-rib-extend@ietf.or=
g",

> > > > > "draft-ietf-pim-igmp-mld-yang@ietf.org&qu=
ot;,

> > > > > "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@iet=
f.org",

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

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

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

> > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

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

> > > > > }

> > > > >

> > > > > 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-interfa=
ces-2, we

> > > > > would have an cross SDO issue ... Btw, there are n=
o

> > > > > automatic ways to extract the authors of YANG modu=
les 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 kno=
w the

> > > > > authors. Time consuming, believe me.

> > > > >

> > > > > Regards, Benoit

> > > > > > Hi,

> > > > > >

> > > > > >=C2=A0 =C2=A0=C2=A0=C2=A0 As part of the my Ro=
uting Directorate review of

> > > > > > draft-wu-l3sm-rfc8049bis I noted that there w=
ere several incompatible

> > > > > > changes being made to the ietf-l3vpn-svc modu=
le without changing the

> > > > > > name.=C2=A0 I raised this with the YANG docto=
rs and others involved with the

> > > > > > draft and it surfaced some topics which reall=
y should be discussed here

> > > > > > in NetMod.

> > > > > >

> > > > > > The background (as explained off-list by othe=
rs, so I hope I have it

> > > > > > right)=C2=A0 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.=C2=A0 L3SM has concluded so the fix i=
s in the individual draft

> > > > > > draft-wu-l3sm-rfc8049bis.=C2=A0 Since the rfc=
8049 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 wi=
th 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 Dr=
s., the general discussion

> > > > > > was heading down the path of using a new modu=
le name, and thereby not

> > > > > > violating YANG module update rules.=C2=A0 Thi=
s lead us back to the a similar

> > > > > > discussion we've been having in the conte=
xt of 8022bis: how best to

> > > > > > indicate that a whole module is being obsolet=
ed.=C2=A0 RFCs do this by adding

> > > > > > 'metadata' to the headers, e.g., &quo=
t;Obsoletes: 8049", but this doesn't

> > > > > > help YANG tooling.=C2=A0 For 8022, we have on=
e approach - publishing an

> > > > > > updated rev of the original module marking al=
l nodes as deprecated - but

> > > > > > that doesn't really make sense for rfc804=
9bis.

> > > > > >

> > > > > > So the discussion for the WG is:

> > > > > >

> > > > > > How do we handle incompatible module changes,=
 notably when one module

> > > > > > 'obsoletes' another module --=C2=A0 f=
rom 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




--

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 Ri=
ng 1 | 28759 Bremen | Germany

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



_______________________________________________

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




--001a113d7832c21066055d515d98--


From nobody Mon Nov  6 06:49: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 8F73E13FC2C for ; Mon,  6 Nov 2017 06:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 br1f7OWFZU-1 for ; Mon,  6 Nov 2017 06:49:12 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2E13F698 for ; Mon,  6 Nov 2017 06:49:12 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 0783A1AE030A; Mon,  6 Nov 2017 15:49:09 +0100 (CET)
Date: Mon, 06 Nov 2017 15:49:13 +0100 (CET)
Message-Id: <20171106.154913.1683303692062360930.mbj@tail-f.com>
To: lberger@labn.net
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=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: Mon, 06 Nov 2017 14:49:14 -0000

Lou Berger  wrote:
> Martin,
> 
> If I have an RPC or action that changes state, how would the
> persistence of that state be indicated with an NMBA data stores.  I
> expected it to be related to the data store, but I read your mail
> below as saying otherwise

The side effects of executing an rpc or action is described in the
rpc/action itself.  This is not a problem.  For example, see the
definition of .  So with NMDA, this continues to work
like before.


/martin




> Thanks,
> Lou
> 
> 
> On November 6, 2017 8:20:12 AM Martin Bjorklund 
> wrote:
> 
> > Hi,
> >
> > Trying to summarize this issue.
> >
> > The problem is which datastore is used to:
> >
> >     1a. evaluate action ancestor nodes
> >     1b. evaluate action input/output parameter leafref,
> >         instance-identifier, must, when
> >     2.  evaluate rpc input/output parameter leafref,
> >         instance-identifier, must, when
> >
> > (Note that the side effects of an action/rpc is not part of this
> > issue)
> >
> > I think it would be very weird if 1a and 1b were treated differently,
> > so I just label them as 1 below.
> >
> > Possible solutions:
> >
> > A.  Always use  for 1 and 2.
> >
> >     (This is what the current nmda draft says).
> >
> > B.  Let the client specify the datastore for 1, and use 
> >     for 2.
> >
> >     (Note that this is trivial in RESTCONF (since the datastore is
> >     part of the URL), but would require a new parameter for NETCONF
> >     (or a new ).
> >
> > C.  Let the client specify the datastore for 1 and 2.
> >
> >     This would require a new generic parameter for how RPCs are
> >     invoked in both NETCONF and RESTCONF.
> >
> > D.  Like B, but let the description of the "rpc" statement optionally
> >     override this.
> >
> >
> > I prefer B and then D.
> >
> >
> > /martin
> >
> >
> >
> >
> > Andy Bierman  wrote:
> >> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
> >>
> >> > Sorry, if I wasn't clear.  I meant the  element would
> >> > be directly under , so the system knows where to start
> >> > looking for data.  Guessing is bad.
> >> >
> >> >
> >> Totally agree guessing is bad.
> >> Did you see the  proposal in a previous email?
> >> That is exactly what I proposed, except I do not want to
> >> overload  so the new template would be a different name.
> >>
> >> I realize the expanded name of the datastore element prevents it from
> >> being confused with top-level YANG nodes, but the conformance
> >> is more clear with a new name.
> >>
> >>
> >>
> >>
> >> > Thanks,
> >> >  Phil
> >> >
> >>
> >> Andy
> >>
> >>
> >> >
> >> >
> >> > Andy Bierman writes:
> >> > >So a server will be required to guess the correct datastore until it
> >> > >finds the right one that matches the action instance?
> >> > >
> >> > >   
> >> > >       
> >> > >          
> >> > >             10
> >> > >             
> >> > >                candidate
> >> > >             
> >> > >          
> >> > >        
> >> > >    
> >> > >
> >> > >The server will guess the datastore in some proprietary order and
> >> > >parse
> >> > >instances of /top/ and /top/list1.  Then it finds the  action
> >> > >and parses the input to get to the datastore and find out the real
> >> > datastore
> >> > >to use.  If the server guessed wrong, then it reparses the 
> >> > against
> >> > >the requested datastore.  Hopefully the schema trees match up.
> >> > >
> >> > >Will vendors do all the extra work required to support this sort of
> >> > >thing?
> >> > >I doubt it.
> >> > >
> >> > >
> >> > >Andy
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
> >> > >wrote:
> >> > >
> >> > >> 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
> >> > >>
> >> > >
> >> > >--001a11411b0ad2d58d055cee96cb
> >> > >Content-Type: text/html; charset="UTF-8"
> >> > >Content-Transfer-Encoding: quoted-printable
> >> > >
> >> > >
Hi,

So a server will be required
> >> > >to
> >> > gue=
> >> > >ss the correct datastore until it
finds the right one that
> >> > matche=
> >> > >s the action instance?

=C2=A0
> >> > =C2=A0<action>=
> >> > >
=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>
=C2=A0
> >> > =C2=A0 =
> >> > >=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0
> >> > >=C2=A0 =
> >> > >=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 =C2=A0
> >> > =C2=
> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>
=C2=A0 =C2=A0
> >> > =C2=
> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate<
> >> > /datas=
> >> > >tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> >> > =C2=A0</do-=
> >> > >test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> >> > </list1>
<=
> >> > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0
> >> > </a=
> >> > >ction>

The server will guess the datastore
> >> > in s=
> >> > >ome proprietary order and parse
instances of /top/ and
> >> > /top/list1=
> >> > >.=C2=A0 Then it finds the <do-test> action
and parses
> >> > >the
> >> > i=
> >> > >nput to get to the datastore and find out the real
> >> > >datastore
to
> >> > u=
> >> > >se.=C2=A0 If the server guessed wrong, then it reparses the
> >> > <action> =
> >> > >against
the requested datastore.=C2=A0 Hopefully the schema
> >> > trees=
> >> > > match up.

Will vendors do all the extra work
> >> > requ=
> >> > >ired to support this sort of thing?
I doubt
> >> > it.

 >> > >iv>

Andy


 >> > div>

 >> > >iv>

On
> >> > >Tue,
> >> > O=
> >> > >ct 31, 2017 at 11:36 PM, Phil Shafer < >> > href=3D"mailt=
> >> > >o:phil@juniper.net" target=3D"_blank">phil@juniper.net>
> >> > wrote=
> >> > >:
 >> > .8ex;border-le=
> >> > >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

> >> > >>ii) However, as far as I can see, it doesn't make sense for an
> >> > acti=
> >> > >on to

> >> > >>directly affect the contents of any configuration datastore, that
> >> > shoul=
> >> > >d

> >> > >>be done via a purpose built rpc (like edit-config).

> >> > >

> >> > >An example action would be to retrieve the=C2=A0 fingerprint of an
> >> > >ssh

> >> > >key.=C2=A0 I might want to get the fingerprint of a key in
> >> > <candidate>=
> >> > >;

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

> >> > >

> >> > >Seems like <startup> 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?=C2=A0 Any specific RPC can define
> >> > >its

> >> > >own datastore leaf of hard-code the database in the description

> >> > >(explicitly or implicitly <operational>), but the <action>
> >> > RPC =
> >> > >only

> >> > >gets this if we make a new parameter for it.

> >> > >

> >> > >Thanks,

> >> > >=C2=A0Phil

> >> > >


> >> > >
> >> > >--001a11411b0ad2d58d055cee96cb--
> >> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> 


From nobody Mon Nov  6 07:03: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 2E67313FC2F for ; Mon,  6 Nov 2017 07:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KOQS3MusQpeZ for ; Mon,  6 Nov 2017 07:03:41 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B35F13FC2C for ; Mon,  6 Nov 2017 07:03:38 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 9E9C11E0B99 for ; Mon,  6 Nov 2017 08:03:37 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id Wf3Z1w00a2SSUrH01f3c5d; Mon, 06 Nov 2017 08:03:37 -0700
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=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=sC3jslCIGhcA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=xskcdSivAAAA:8 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=FIGp5oMs-BBKaa9VkXwA:9 a=-MjPFmNV3SJqGFfT:21 a=CjuIK1q_8ugA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=B8SJYIqRPU5_XtF5Z38x:22 a=cAcMbU7R10T-QSRYIcO_: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=SWS9BNrjKcOMiXg4A4vvIj9EGSoF5/3/PBhDb5wuX2w=; b=o7adLTklu8E1YeaH/UVswaoK7W aryBLQ6iDgx89u22xK7HHbtjMHIcGMQC5W2b7VrljQ5StMXo2BCuk3zYX6WYflBF6g/3YzAgE8GdX 627TWHE1PCDSvmCgIGXp9rKI6;
Received: from [172.58.185.143] (port=19148 helo=[IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eBiw0-000Js5-W2; Mon, 06 Nov 2017 08:03:33 -0700
From: Lou Berger 
To: Martin Bjorklund 
CC: , 
Date: Mon, 06 Nov 2017 10:03:30 -0500
Message-ID: <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171106.154913.1683303692062360930.mbj@tail-f.com>
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.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.143
X-Exim-ID: 1eBiw0-000Js5-W2
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) [172.58.185.143]:19148
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Mon, 06 Nov 2017 15:03:44 -0000

So i guess this comes down to D listed below.  While i was expecting C, i 
think D is probably workable. How would you envision the override would be 
expressed?

Lou


On November 6, 2017 9:49:49 AM Martin Bjorklund  wrote:

> Lou Berger  wrote:
>> Martin,
>>
>> If I have an RPC or action that changes state, how would the
>> persistence of that state be indicated with an NMBA data stores.  I
>> expected it to be related to the data store, but I read your mail
>> below as saying otherwise
>
> The side effects of executing an rpc or action is described in the
> rpc/action itself.  This is not a problem.  For example, see the
> definition of .  So with NMDA, this continues to work
> like before.
>
>
> /martin
>
>
>
>
>> Thanks,
>> Lou
>>
>>
>> On November 6, 2017 8:20:12 AM Martin Bjorklund 
>> wrote:
>>
>> > Hi,
>> >
>> > Trying to summarize this issue.
>> >
>> > The problem is which datastore is used to:
>> >
>> >     1a. evaluate action ancestor nodes
>> >     1b. evaluate action input/output parameter leafref,
>> >         instance-identifier, must, when
>> >     2.  evaluate rpc input/output parameter leafref,
>> >         instance-identifier, must, when
>> >
>> > (Note that the side effects of an action/rpc is not part of this
>> > issue)
>> >
>> > I think it would be very weird if 1a and 1b were treated differently,
>> > so I just label them as 1 below.
>> >
>> > Possible solutions:
>> >
>> > A.  Always use  for 1 and 2.
>> >
>> >     (This is what the current nmda draft says).
>> >
>> > B.  Let the client specify the datastore for 1, and use 
>> >     for 2.
>> >
>> >     (Note that this is trivial in RESTCONF (since the datastore is
>> >     part of the URL), but would require a new parameter for NETCONF
>> >     (or a new ).
>> >
>> > C.  Let the client specify the datastore for 1 and 2.
>> >
>> >     This would require a new generic parameter for how RPCs are
>> >     invoked in both NETCONF and RESTCONF.
>> >
>> > D.  Like B, but let the description of the "rpc" statement optionally
>> >     override this.
>> >
>> >
>> > I prefer B and then D.
>> >
>> >
>> > /martin
>> >
>> >
>> >
>> >
>> > Andy Bierman  wrote:
>> >> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
>> >>
>> >> > Sorry, if I wasn't clear.  I meant the  element would
>> >> > be directly under , so the system knows where to start
>> >> > looking for data.  Guessing is bad.
>> >> >
>> >> >
>> >> Totally agree guessing is bad.
>> >> Did you see the  proposal in a previous email?
>> >> That is exactly what I proposed, except I do not want to
>> >> overload  so the new template would be a different name.
>> >>
>> >> I realize the expanded name of the datastore element prevents it from
>> >> being confused with top-level YANG nodes, but the conformance
>> >> is more clear with a new name.
>> >>
>> >>
>> >>
>> >>
>> >> > Thanks,
>> >> >  Phil
>> >> >
>> >>
>> >> Andy
>> >>
>> >>
>> >> >
>> >> >
>> >> > Andy Bierman writes:
>> >> > >So a server will be required to guess the correct datastore until it
>> >> > >finds the right one that matches the action instance?
>> >> > >
>> >> > >   
>> >> > >       
>> >> > >          
>> >> > >             10
>> >> > >             
>> >> > >                candidate
>> >> > >             
>> >> > >          
>> >> > >        
>> >> > >    
>> >> > >
>> >> > >The server will guess the datastore in some proprietary order and
>> >> > >parse
>> >> > >instances of /top/ and /top/list1.  Then it finds the  action
>> >> > >and parses the input to get to the datastore and find out the real
>> >> > datastore
>> >> > >to use.  If the server guessed wrong, then it reparses the 
>> >> > against
>> >> > >the requested datastore.  Hopefully the schema trees match up.
>> >> > >
>> >> > >Will vendors do all the extra work required to support this sort of
>> >> > >thing?
>> >> > >I doubt it.
>> >> > >
>> >> > >
>> >> > >Andy
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
>> >> > >wrote:
>> >> > >
>> >> > >> 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
>> >> > >>
>> >> > >
>> >> > >--001a11411b0ad2d58d055cee96cb
>> >> > >Content-Type: text/html; charset="UTF-8"
>> >> > >Content-Transfer-Encoding: quoted-printable
>> >> > >
>> >> > >
Hi,

So a server will be required
>> >> > >to
>> >> > gue=
>> >> > >ss the correct datastore until it
finds the right one that
>> >> > matche=
>> >> > >s the action instance?

=C2=A0
>> >> > =C2=A0<action>=
>> >> > >
=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>
=C2=A0
>> >> > =C2=A0 =
>> >> > >=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0
>> >> > >=C2=A0 =
>> >> > >=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 =C2=A0
>> >> > =C2=
>> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>
=C2=A0 =C2=A0
>> >> > =C2=
>> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate<
>> >> > /datas=
>> >> > >tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>> >> > =C2=A0</do-=
>> >> > >test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>> >> > </list1>
<=
>> >> > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0
>> >> > </a=
>> >> > >ction>

The server will guess the datastore
>> >> > in s=
>> >> > >ome proprietary order and parse
instances of /top/ and
>> >> > /top/list1=
>> >> > >.=C2=A0 Then it finds the <do-test> action
and parses
>> >> > >the
>> >> > i=
>> >> > >nput to get to the datastore and find out the real
>> >> > >datastore
to
>> >> > u=
>> >> > >se.=C2=A0 If the server guessed wrong, then it reparses the
>> >> > <action> =
>> >> > >against
the requested datastore.=C2=A0 Hopefully the schema
>> >> > trees=
>> >> > > match up.

Will vendors do all the extra work
>> >> > requ=
>> >> > >ired to support this sort of thing?
I doubt
>> >> > it.

> >> > >iv>

Andy


> >> > div>

> >> > >iv>

On
>> >> > >Tue,
>> >> > O=
>> >> > >ct 31, 2017 at 11:36 PM, Phil Shafer <> >> > href=3D"mailt=
>> >> > >o:phil@juniper.net" target=3D"_blank">phil@juniper.net>
>> >> > wrote=
>> >> > >:
> >> > .8ex;border-le=
>> >> > >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

>> >> > >>ii) However, as far as I can see, it doesn't make sense for an
>> >> > acti=
>> >> > >on to

>> >> > >>directly affect the contents of any configuration datastore, that
>> >> > shoul=
>> >> > >d

>> >> > >>be done via a purpose built rpc (like edit-config).

>> >> > >

>> >> > >An example action would be to retrieve the=C2=A0 fingerprint of an
>> >> > >ssh

>> >> > >key.=C2=A0 I might want to get the fingerprint of a key in
>> >> > <candidate>=
>> >> > >;

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

>> >> > >

>> >> > >Seems like <startup> 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?=C2=A0 Any specific RPC can define
>> >> > >its

>> >> > >own datastore leaf of hard-code the database in the description

>> >> > >(explicitly or implicitly <operational>), but the <action>
>> >> > RPC =
>> >> > >only

>> >> > >gets this if we make a new parameter for it.

>> >> > >

>> >> > >Thanks,

>> >> > >=C2=A0Phil

>> >> > >


>> >> > >
>> >> > >--001a11411b0ad2d58d055cee96cb--
>> >> >
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> >
>>
>>
>



From nobody Mon Nov  6 07:20: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 4CEE713FC37 for ; Mon,  6 Nov 2017 07:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 bxBFRUmrdzp8 for ; Mon,  6 Nov 2017 07:20:46 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6132713F698 for ; Mon,  6 Nov 2017 07:20:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12581; q=dns/txt; s=iport; t=1509981645; x=1511191245; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=l4CohheqGTYh2wJZdNBtB4uDoOhM8EHIEjTsypVGIe0=; b=SqoGvWqlFaUChF1dx0JIXYSIHCwRYGBMMnQyGEay/ZQK7YVvAKaR+XgD vWVhim+e+t3dc1LKX5SRTeHzdeVF8G6HAJ2xJuhGhrj/fr1S6R0L3xaPA 14GFiG7dVP/+g2PtPN0XpHnJOusEk7d/n9WseA/ggR2h6xBrRPlQW1lQ/ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAgARfQBa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhBhuJ4N9ixOPfCZ9lVmCAQoYC4RJTwKFKxQBAQEBAQEBAQFrKIU?= =?us-ascii?q?fAQEEAQEhDwEFNgsQCQIOCgICJgICJzAGAQkDBgIBAReKCBCNUp1ngieLBwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CH4NagWkpC4JBNYReARECAQgWgxWCYgW?= =?us-ascii?q?RXpAwi02JL4IViWMkhxiOKYdtgTk2IVwnaTQhCB0VSYJkglwcgWdBNot2AQEB?=
X-IronPort-AV: E=Sophos;i="5.44,353,1505779200";  d="scan'208";a="46310"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2017 15:20:43 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA6FKg40023741; Mon, 6 Nov 2017 15:20:42 GMT
To: Lou Berger , netmod@ietf.org
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
From: Robert Wilton 
Message-ID: <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com>
Date: Mon, 6 Nov 2017 15:20:42 +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: <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] 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: Mon, 06 Nov 2017 15:20:53 -0000

Hi Lou,

All of proposed solutions (A through D) allow the action or the RPC to 
perform whatever behaviour that it wants.

This issue is only about which datastore is used to evaluate and check 
that the parameters for the action/rpc are valid.  E.g. if the 
parameters use when, must, leaf-ref, or instance-identifier.

So, to take option "A" for example: "A.  Always use  for 1 
and 2."

One can still define a RPC that modifies another datastore ("edit-data" 
in the NETCONF NMDA  draft is one such example).  But to check whether 
the edit-data request can be performed, any input parameter constraints 
would be evaluated against .  However, given that the input 
parameters to edit-data don't contain any when, must, leaf-ref, or 
instance-identifier statements then it makes absolutely no functional 
difference which the datastore the parameters are evaluated in, since 
the result will always be the same regardless.  But perhaps it just 
feels a little odd that they are conceptually evaluated against 
operational, even though the RPC only even affects one of the editable 
configurable datastores.

Thanks,
Rob


On 06/11/2017 15:03, Lou Berger wrote:
> So i guess this comes down to D listed below.  While i was expecting 
> C, i think D is probably workable. How would you envision the override 
> would be expressed?
>
> Lou
>
>
> On November 6, 2017 9:49:49 AM Martin Bjorklund  wrote:
>
>> Lou Berger  wrote:
>>> Martin,
>>>
>>> If I have an RPC or action that changes state, how would the
>>> persistence of that state be indicated with an NMBA data stores.  I
>>> expected it to be related to the data store, but I read your mail
>>> below as saying otherwise
>>
>> The side effects of executing an rpc or action is described in the
>> rpc/action itself.  This is not a problem.  For example, see the
>> definition of .  So with NMDA, this continues to work
>> like before.
>>
>>
>> /martin
>>
>>
>>
>>
>>> Thanks,
>>> Lou
>>>
>>>
>>> On November 6, 2017 8:20:12 AM Martin Bjorklund 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > Trying to summarize this issue.
>>> >
>>> > The problem is which datastore is used to:
>>> >
>>> >     1a. evaluate action ancestor nodes
>>> >     1b. evaluate action input/output parameter leafref,
>>> >         instance-identifier, must, when
>>> >     2.  evaluate rpc input/output parameter leafref,
>>> >         instance-identifier, must, when
>>> >
>>> > (Note that the side effects of an action/rpc is not part of this
>>> > issue)
>>> >
>>> > I think it would be very weird if 1a and 1b were treated differently,
>>> > so I just label them as 1 below.
>>> >
>>> > Possible solutions:
>>> >
>>> > A.  Always use  for 1 and 2.
>>> >
>>> >     (This is what the current nmda draft says).
>>> >
>>> > B.  Let the client specify the datastore for 1, and use 
>>> >     for 2.
>>> >
>>> >     (Note that this is trivial in RESTCONF (since the datastore is
>>> >     part of the URL), but would require a new parameter for NETCONF
>>> >     (or a new ).
>>> >
>>> > C.  Let the client specify the datastore for 1 and 2.
>>> >
>>> >     This would require a new generic parameter for how RPCs are
>>> >     invoked in both NETCONF and RESTCONF.
>>> >
>>> > D.  Like B, but let the description of the "rpc" statement optionally
>>> >     override this.
>>> >
>>> >
>>> > I prefer B and then D.
>>> >
>>> >
>>> > /martin
>>> >
>>> >
>>> >
>>> >
>>> > Andy Bierman  wrote:
>>> >> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  
>>> wrote:
>>> >>
>>> >> > Sorry, if I wasn't clear.  I meant the  element would
>>> >> > be directly under , so the system knows where to start
>>> >> > looking for data.  Guessing is bad.
>>> >> >
>>> >> >
>>> >> Totally agree guessing is bad.
>>> >> Did you see the  proposal in a previous email?
>>> >> That is exactly what I proposed, except I do not want to
>>> >> overload  so the new template would be a different name.
>>> >>
>>> >> I realize the expanded name of the datastore element prevents it 
>>> from
>>> >> being confused with top-level YANG nodes, but the conformance
>>> >> is more clear with a new name.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> > Thanks,
>>> >> >  Phil
>>> >> >
>>> >>
>>> >> Andy
>>> >>
>>> >>
>>> >> >
>>> >> >
>>> >> > Andy Bierman writes:
>>> >> > >So a server will be required to guess the correct datastore 
>>> until it
>>> >> > >finds the right one that matches the action instance?
>>> >> > >
>>> >> > >   
>>> >> > >       
>>> >> > >          
>>> >> > >             10
>>> >> > >             
>>> >> > > candidate
>>> >> > >             
>>> >> > >          
>>> >> > >        
>>> >> > >    
>>> >> > >
>>> >> > >The server will guess the datastore in some proprietary order and
>>> >> > >parse
>>> >> > >instances of /top/ and /top/list1.  Then it finds the 
>>>  action
>>> >> > >and parses the input to get to the datastore and find out the 
>>> real
>>> >> > datastore
>>> >> > >to use.  If the server guessed wrong, then it reparses the 
>>> 
>>> >> > against
>>> >> > >the requested datastore.  Hopefully the schema trees match up.
>>> >> > >
>>> >> > >Will vendors do all the extra work required to support this 
>>> sort of
>>> >> > >thing?
>>> >> > >I doubt it.
>>> >> > >
>>> >> > >
>>> >> > >Andy
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
>>> >> > >wrote:
>>> >> > >
>>> >> > >> 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
>>> >> > >>
>>> >> > >
>>> >> > >--001a11411b0ad2d58d055cee96cb
>>> >> > >Content-Type: text/html; charset="UTF-8"
>>> >> > >Content-Transfer-Encoding: quoted-printable
>>> >> > >
>>> >> > >
Hi,

So a server will be 
>>> required
>>> >> > >to
>>> >> > gue=
>>> >> > >ss the correct datastore until it
finds the right 
>>> one that
>>> >> > matche=
>>> >> > >s the action instance?

=C2=A0
>>> >> > =C2=A0<action>=
>>> >> > >
=C2=A0 =C2=A0 =C2=A0 
>>> =C2=A0<top>
=C2=A0
>>> >> > =C2=A0 =
>>> >> > >=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0
>>> >> > >=C2=A0 =
>>> >> > >=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 
>>> =C2=A0
>>> >> > =C2=
>>> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 
>>> =C2=A0<do-test>
=C2=A0 =C2=A0
>>> >> > =C2=
>>> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
>>> <datastore>candidate<
>>> >> > /datas=
>>> >> > >tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>>> >> > =C2=A0</do-=
>>> >> > >test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>>> >> > </list1>
<=
>>> >> > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 
>>> =C2=A0
>>> >> > </a=
>>> >> > >ction>

The server will guess the 
>>> datastore
>>> >> > in s=
>>> >> > >ome proprietary order and parse
instances of /top/ and
>>> >> > /top/list1=
>>> >> > >.=C2=A0 Then it finds the <do-test> action
and 
>>> parses
>>> >> > >the
>>> >> > i=
>>> >> > >nput to get to the datastore and find out the real
>>> >> > >datastore
to
>>> >> > u=
>>> >> > >se.=C2=A0 If the server guessed wrong, then it reparses the
>>> >> > <action> =
>>> >> > >against
the requested datastore.=C2=A0 Hopefully the 
>>> schema
>>> >> > trees=
>>> >> > > match up.

Will vendors do all the 
>>> extra work
>>> >> > requ=
>>> >> > >ired to support this sort of thing?
I doubt
>>> >> > it.

>> >> > >iv>

Andy


>> >> > div>

>> >> > >iv>

>> class=3D"gmail_quote">On
>>> >> > >Tue,
>>> >> > O=
>>> >> > >ct 31, 2017 at 11:36 PM, Phil Shafer <>> >> > href=3D"mailt=
>>> >> > >o:phil@juniper.net" 
>>> target=3D"_blank">phil@juniper.net>
>>> >> > wrote=
>>> >> > >:
>> >> > .8ex;border-le=
>>> >> > >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

>>> >> > >>ii) However, as far as I can see, it doesn't make 
>>> sense for an
>>> >> > acti=
>>> >> > >on to

>>> >> > >>directly affect the contents of any configuration 
>>> datastore, that
>>> >> > shoul=
>>> >> > >d

>>> >> > >>be done via a purpose built rpc (like edit-config).

>>> >> > >

>>> >> > >An example action would be to retrieve the=C2=A0 fingerprint 
>>> of an
>>> >> > >ssh

>>> >> > >key.=C2=A0 I might want to get the fingerprint of a key in
>>> >> > <candidate>=
>>> >> > >;

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

>>> >> > >

>>> >> > >Seems like <startup> 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?=C2=A0 Any specific RPC can define
>>> >> > >its

>>> >> > >own datastore leaf of hard-code the database in the 
>>> description

>>> >> > >(explicitly or implicitly <operational>), but the 
>>> <action>
>>> >> > RPC =
>>> >> > >only

>>> >> > >gets this if we make a new parameter for it.

>>> >> > >

>>> >> > >Thanks,

>>> >> > >=C2=A0Phil

>>> >> > >


>>> >> > >
>>> >> > >--001a11411b0ad2d58d055cee96cb--
>>> >> >
>>> >
>>> > _______________________________________________
>>> > 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 Nov  6 08:12: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 D5A1F13FC49 for ; Mon,  6 Nov 2017 08:12:02 -0800 (PST)
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 FlqJrfOBLjei for ; Mon,  6 Nov 2017 08:12:00 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 DB85913FB14 for ; Mon,  6 Nov 2017 08:11:59 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 02B7317781B for ; Mon,  6 Nov 2017 08:51:30 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id WfrS1w0192SSUrH01frV1B; Mon, 06 Nov 2017 08:51:29 -0700
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=sC3jslCIGhcA:10 a=AUd_NHdVAAAA:8 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=xskcdSivAAAA:8 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=9L8UMKYyNcGWCJ_SSa8A:9 a=89xDdMM8pRvpIXvn:21 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=B8SJYIqRPU5_XtF5Z38x:22 a=cAcMbU7R10T-QSRYIcO_: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=StX2Itl6YhvhRf4e2VCihP+H2CW+EB+El0nLiKWe1PI=; b=rjieCDlVtCBzJsXwhFKsed4eBs 8IBdQ44Al9vBZjR2OpHAushi+795JQXrwNgLzb/i/OxpK8J3aY+6usqgKUKQVRwL4+MwPKVANRe/q jkaqzXtAOCjEOwjdw5+/hk5pH;
Received: from [172.58.185.143] (port=47542 helo=[IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eBjgM-000Ugn-Gj; Mon, 06 Nov 2017 08:51:26 -0700
From: Lou Berger 
To: Robert Wilton , 
Date: Mon, 06 Nov 2017 10:51:23 -0500
Message-ID: <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com>
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@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: 172.58.185.143
X-Exim-ID: 1eBjgM-000Ugn-Gj
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) [172.58.185.143]:47542
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Mon, 06 Nov 2017 16:12:03 -0000

On November 6, 2017 10:21:19 AM Robert Wilton  wrote:

> Hi Lou,
>
> All of proposed solutions (A through D) allow the action or the RPC to
> perform whatever behaviour that it wants.
>
> This issue is only about which datastore is used to evaluate and check
> that the parameters for the action/rpc are valid.  E.g. if the
> parameters use when, must, leaf-ref, or instance-identifier.
>
> So, to take option "A" for example: "A.  Always use  for 1
> and 2."
>
> One can still define a RPC that modifies another datastore ("edit-data"
> in the NETCONF NMDA  draft is one such example).  But to check whether
> the edit-data request can be performed, any input parameter constraints
> would be evaluated against .  However, given that the input
> parameters to edit-data don't contain any when, must, leaf-ref, or
> instance-identifier statements then it makes absolutely no functional
> difference which the datastore the parameters are evaluated in, since
> the result will always be the same regardless.  But perhaps it just
> feels a little odd that they are conceptually evaluated against
> operational, even though the RPC only even affects one of the editable
> configurable datastores.
>


Yes, which is why I've been assuming we'd end up with c.

Thanks,

Lou
> Thanks,
> Rob
>
>
> On 06/11/2017 15:03, Lou Berger wrote:
>> So i guess this comes down to D listed below.  While i was expecting
>> C, i think D is probably workable. How would you envision the override
>> would be expressed?
>>
>> Lou
>>
>>
>> On November 6, 2017 9:49:49 AM Martin Bjorklund  wrote:
>>
>>> Lou Berger  wrote:
>>>> Martin,
>>>>
>>>> If I have an RPC or action that changes state, how would the
>>>> persistence of that state be indicated with an NMBA data stores.  I
>>>> expected it to be related to the data store, but I read your mail
>>>> below as saying otherwise
>>>
>>> The side effects of executing an rpc or action is described in the
>>> rpc/action itself.  This is not a problem.  For example, see the
>>> definition of .  So with NMDA, this continues to work
>>> like before.
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>>
>>>> On November 6, 2017 8:20:12 AM Martin Bjorklund 
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > Trying to summarize this issue.
>>>> >
>>>> > The problem is which datastore is used to:
>>>> >
>>>> >     1a. evaluate action ancestor nodes
>>>> >     1b. evaluate action input/output parameter leafref,
>>>> >         instance-identifier, must, when
>>>> >     2.  evaluate rpc input/output parameter leafref,
>>>> >         instance-identifier, must, when
>>>> >
>>>> > (Note that the side effects of an action/rpc is not part of this
>>>> > issue)
>>>> >
>>>> > I think it would be very weird if 1a and 1b were treated differently,
>>>> > so I just label them as 1 below.
>>>> >
>>>> > Possible solutions:
>>>> >
>>>> > A.  Always use  for 1 and 2.
>>>> >
>>>> >     (This is what the current nmda draft says).
>>>> >
>>>> > B.  Let the client specify the datastore for 1, and use 
>>>> >     for 2.
>>>> >
>>>> >     (Note that this is trivial in RESTCONF (since the datastore is
>>>> >     part of the URL), but would require a new parameter for NETCONF
>>>> >     (or a new ).
>>>> >
>>>> > C.  Let the client specify the datastore for 1 and 2.
>>>> >
>>>> >     This would require a new generic parameter for how RPCs are
>>>> >     invoked in both NETCONF and RESTCONF.
>>>> >
>>>> > D.  Like B, but let the description of the "rpc" statement optionally
>>>> >     override this.
>>>> >
>>>> >
>>>> > I prefer B and then D.
>>>> >
>>>> >
>>>> > /martin
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > Andy Bierman  wrote:
>>>> >> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer 
>>>> wrote:
>>>> >>
>>>> >> > Sorry, if I wasn't clear.  I meant the  element would
>>>> >> > be directly under , so the system knows where to start
>>>> >> > looking for data.  Guessing is bad.
>>>> >> >
>>>> >> >
>>>> >> Totally agree guessing is bad.
>>>> >> Did you see the  proposal in a previous email?
>>>> >> That is exactly what I proposed, except I do not want to
>>>> >> overload  so the new template would be a different name.
>>>> >>
>>>> >> I realize the expanded name of the datastore element prevents it
>>>> from
>>>> >> being confused with top-level YANG nodes, but the conformance
>>>> >> is more clear with a new name.
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> > Thanks,
>>>> >> >  Phil
>>>> >> >
>>>> >>
>>>> >> Andy
>>>> >>
>>>> >>
>>>> >> >
>>>> >> >
>>>> >> > Andy Bierman writes:
>>>> >> > >So a server will be required to guess the correct datastore
>>>> until it
>>>> >> > >finds the right one that matches the action instance?
>>>> >> > >
>>>> >> > >   
>>>> >> > >       
>>>> >> > >          
>>>> >> > >             10
>>>> >> > >             
>>>> >> > > candidate
>>>> >> > >             
>>>> >> > >          
>>>> >> > >        
>>>> >> > >    
>>>> >> > >
>>>> >> > >The server will guess the datastore in some proprietary order and
>>>> >> > >parse
>>>> >> > >instances of /top/ and /top/list1.  Then it finds the
>>>>  action
>>>> >> > >and parses the input to get to the datastore and find out the
>>>> real
>>>> >> > datastore
>>>> >> > >to use.  If the server guessed wrong, then it reparses the
>>>> 
>>>> >> > against
>>>> >> > >the requested datastore.  Hopefully the schema trees match up.
>>>> >> > >
>>>> >> > >Will vendors do all the extra work required to support this
>>>> sort of
>>>> >> > >thing?
>>>> >> > >I doubt it.
>>>> >> > >
>>>> >> > >
>>>> >> > >Andy
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
>>>> >> > >wrote:
>>>> >> > >
>>>> >> > >> 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
>>>> >> > >>
>>>> >> > >
>>>> >> > >--001a11411b0ad2d58d055cee96cb
>>>> >> > >Content-Type: text/html; charset="UTF-8"
>>>> >> > >Content-Transfer-Encoding: quoted-printable
>>>> >> > >
>>>> >> > >
Hi,

So a server will be
>>>> required
>>>> >> > >to
>>>> >> > gue=
>>>> >> > >ss the correct datastore until it
finds the right
>>>> one that
>>>> >> > matche=
>>>> >> > >s the action instance?

=C2=A0
>>>> >> > =C2=A0<action>=
>>>> >> > >
=C2=A0 =C2=A0 =C2=A0
>>>> =C2=A0<top>
=C2=A0
>>>> >> > =C2=A0 =
>>>> >> > >=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0
>>>> >> > >=C2=A0 =
>>>> >> > >=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0
>>>> =C2=A0
>>>> >> > =C2=
>>>> >> > >=A0 =C2=A0 =C2=A0 =C2=A0
>>>> =C2=A0<do-test>
=C2=A0 =C2=A0
>>>> >> > =C2=
>>>> >> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>>>> <datastore>candidate<
>>>> >> > /datas=
>>>> >> > >tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>>>> >> > =C2=A0</do-=
>>>> >> > >test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>>>> >> > </list1>
<=
>>>> >> > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0
>>>> =C2=A0
>>>> >> > </a=
>>>> >> > >ction>

The server will guess the
>>>> datastore
>>>> >> > in s=
>>>> >> > >ome proprietary order and parse
instances of /top/ and
>>>> >> > /top/list1=
>>>> >> > >.=C2=A0 Then it finds the <do-test> action
and
>>>> parses
>>>> >> > >the
>>>> >> > i=
>>>> >> > >nput to get to the datastore and find out the real
>>>> >> > >datastore
to
>>>> >> > u=
>>>> >> > >se.=C2=A0 If the server guessed wrong, then it reparses the
>>>> >> > <action> =
>>>> >> > >against
the requested datastore.=C2=A0 Hopefully the
>>>> schema
>>>> >> > trees=
>>>> >> > > match up.

Will vendors do all the
>>>> extra work
>>>> >> > requ=
>>>> >> > >ired to support this sort of thing?
I doubt
>>>> >> > it.

>>> >> > >iv>

Andy


>>> >> > div>

>>> >> > >iv>

>>> class=3D"gmail_quote">On
>>>> >> > >Tue,
>>>> >> > O=
>>>> >> > >ct 31, 2017 at 11:36 PM, Phil Shafer <>>> >> > href=3D"mailt=
>>>> >> > >o:phil@juniper.net"
>>>> target=3D"_blank">phil@juniper.net>
>>>> >> > wrote=
>>>> >> > >:
>>> >> > .8ex;border-le=
>>>> >> > >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

>>>> >> > >>ii) However, as far as I can see, it doesn't make
>>>> sense for an
>>>> >> > acti=
>>>> >> > >on to

>>>> >> > >>directly affect the contents of any configuration
>>>> datastore, that
>>>> >> > shoul=
>>>> >> > >d

>>>> >> > >>be done via a purpose built rpc (like edit-config).

>>>> >> > >

>>>> >> > >An example action would be to retrieve the=C2=A0 fingerprint
>>>> of an
>>>> >> > >ssh

>>>> >> > >key.=C2=A0 I might want to get the fingerprint of a key in
>>>> >> > <candidate>=
>>>> >> > >;

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

>>>> >> > >

>>>> >> > >Seems like <startup> 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?=C2=A0 Any specific RPC can define
>>>> >> > >its

>>>> >> > >own datastore leaf of hard-code the database in the
>>>> description

>>>> >> > >(explicitly or implicitly <operational>), but the
>>>> <action>
>>>> >> > RPC =
>>>> >> > >only

>>>> >> > >gets this if we make a new parameter for it.

>>>> >> > >

>>>> >> > >Thanks,

>>>> >> > >=C2=A0Phil

>>>> >> > >


>>>> >> > >
>>>> >> > >--001a11411b0ad2d58d055cee96cb--
>>>> >> >
>>>> >
>>>> > _______________________________________________
>>>> > 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 Nov  6 08:42: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 C5AE913FB36 for ; Mon,  6 Nov 2017 08:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 TLKlBvlMKgUU for ; Mon,  6 Nov 2017 08:42:00 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E2813FB1F for ; Mon,  6 Nov 2017 08:41:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2360; q=dns/txt; s=iport; t=1509986519; x=1511196119; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=rf2fqnxmP0zwhb3WDEfOpKGUUUX1cC8HZO5FZzcmx9g=; b=c7zUxqJjc3kjnDdEAr5MQY+AeQC2BCQcAQaH0oxo+k9fWIP/RXR7JUb6 FkLUJEtWv/BknfCU3thB4GdcXo5mx3O3mMDOEowfjGycABWZG/fGSH/26 Wr8l6RqZGdQtNsnHDIJp2iYWEkWrUWI+uXQL8YwuHyE3UmNOf68x8sQQj I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAACZjwBa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQYng32KH3SQJJZGghEKhTsChScYAQEBAQEBAQEBayiFHwEFIw8?= =?us-ascii?q?BBUEQCw4KAgImAgJXBgEMBgIBAReKCKsegieLCQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?SCBD4Ifg1qCEoMBiCaCYgWiDpR8i3iHPI4ph22BOR84gWw0IQgdFYMthF9BNot?= =?us-ascii?q?2AQEB?=
X-IronPort-AV: E=Sophos;i="5.44,353,1505779200";  d="scan'208";a="56904"
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; 06 Nov 2017 16:41:57 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA6GfvtY018987; Mon, 6 Nov 2017 16:41:57 GMT
To: Lou Berger , netmod@ietf.org
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
From: Robert Wilton 
Message-ID: 
Date: Mon, 6 Nov 2017 16:41: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: <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] 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: Mon, 06 Nov 2017 16:42:02 -0000

On 06/11/2017 15:51, Lou Berger wrote:
>
>
> On November 6, 2017 10:21:19 AM Robert Wilton  wrote:
>
>> Hi Lou,
>>
>> All of proposed solutions (A through D) allow the action or the RPC to
>> perform whatever behaviour that it wants.
>>
>> This issue is only about which datastore is used to evaluate and check
>> that the parameters for the action/rpc are valid.  E.g. if the
>> parameters use when, must, leaf-ref, or instance-identifier.
>>
>> So, to take option "A" for example: "A.  Always use  for 1
>> and 2."
>>
>> One can still define a RPC that modifies another datastore ("edit-data"
>> in the NETCONF NMDA  draft is one such example).  But to check whether
>> the edit-data request can be performed, any input parameter constraints
>> would be evaluated against .  However, given that the input
>> parameters to edit-data don't contain any when, must, leaf-ref, or
>> instance-identifier statements then it makes absolutely no functional
>> difference which the datastore the parameters are evaluated in, since
>> the result will always be the same regardless.  But perhaps it just
>> feels a little odd that they are conceptually evaluated against
>> operational, even though the RPC only even affects one of the editable
>> configurable datastores.
>>
>
>
> Yes, which is why I've been assuming we'd end up with c.

But I think that to do C properly also requires a new optional statement 
in YANG to indicate where the Action/RPC parameters are evaluated (with 
the default being  if the new statement isn't specified).

Most RPCs/Action statements seem to naturally apply to .

For the RPCs/Action statements that don't naturally apply to 
, it seems that it mostly doesn't matter where the 
parameters are evaluated.

At the moment, the set of remaining RPCs/Actions (don't apply to 
 but do care about parameter evaluation) seems quite small:
  (i) RFC7517, if it defined a YANG model for the  RPC
  (ii) A partial datastore diff from a subtree in  to 
 might be another - it would want an instance-identifier 
path to the subtree in .
  (iii) Perhaps I2RS and dynamic datastores may also throw up some new 
examples.

Thanks,
Rob


From nobody Mon Nov  6 08:51:35 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D01413FB6B for ; Mon,  6 Nov 2017 08:51:33 -0800 (PST)
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 ARabru2Qq54g for ; Mon,  6 Nov 2017 08:51:30 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 1A91B13FBB2 for ; Mon,  6 Nov 2017 08:51:23 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 0F33D179B23 for ; Mon,  6 Nov 2017 09:48:28 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id WgoQ1w0092SSUrH01goT6N; Mon, 06 Nov 2017 09:48:28 -0700
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=sC3jslCIGhcA:10 a=AUd_NHdVAAAA:8 a=apQQR3hXPwcTO8itTgcA: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=uoMB99VOumY8ukh6m06p6o8fqiNMIUTYrr/Bu2kAz/E=; b=UfwBrJeunhQgK+tYLonxy6rEVv SQJ1psDtx5AILlRcvJ6VO4P9s94zOfTLS7YACnTd2vHnj5flxfTXT+5CRqqQUI8pBaaEdTO8SwG7x vEUhJ08SOfrP1TwQMgRfIYM9H;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:32982 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 1eBkZU-000hkN-0o; Mon, 06 Nov 2017 09:48:24 -0700
To: Robert Wilton , netmod@ietf.org
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 
From: Lou Berger 
Message-ID: 
Date: Mon, 6 Nov 2017 11:48:23 -0500
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: 1eBkZU-000hkN-0o
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]:32982
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Mon, 06 Nov 2017 16:51:33 -0000

On 11/06/2017 11:41 AM, Robert Wilton wrote:
> 
> 
> On 06/11/2017 15:51, Lou Berger wrote:
>>
>>
>> On November 6, 2017 10:21:19 AM Robert Wilton  wrote:
>>
>>> Hi Lou,
>>>
>>> All of proposed solutions (A through D) allow the action or the RPC to
>>> perform whatever behaviour that it wants.
>>>
>>> This issue is only about which datastore is used to evaluate and check
>>> that the parameters for the action/rpc are valid.  E.g. if the
>>> parameters use when, must, leaf-ref, or instance-identifier.
>>>
>>> So, to take option "A" for example: "A.  Always use  for 1
>>> and 2."
>>>
>>> One can still define a RPC that modifies another datastore ("edit-data"
>>> in the NETCONF NMDA  draft is one such example).  But to check whether
>>> the edit-data request can be performed, any input parameter constraints
>>> would be evaluated against .  However, given that the input
>>> parameters to edit-data don't contain any when, must, leaf-ref, or
>>> instance-identifier statements then it makes absolutely no functional
>>> difference which the datastore the parameters are evaluated in, since
>>> the result will always be the same regardless.  But perhaps it just
>>> feels a little odd that they are conceptually evaluated against
>>> operational, even though the RPC only even affects one of the editable
>>> configurable datastores.
>>>
>>
>>
>> Yes, which is why I've been assuming we'd end up with c.
> 
> But I think that to do C properly also requires a new optional statement
> in YANG to indicate where the Action/RPC parameters are evaluated (with
> the default being  if the new statement isn't specified).
> 
> Most RPCs/Action statements seem to naturally apply to .
> 
> For the RPCs/Action statements that don't naturally apply to
> , it seems that it mostly doesn't matter where the
> parameters are evaluated.
> 
> At the moment, the set of remaining RPCs/Actions (don't apply to
>  but do care about parameter evaluation) seems quite small:
>  (i) RFC7517, if it defined a YANG model for the  RPC
>  (ii) A partial datastore diff from a subtree in  to
>  might be another - it would want an instance-identifier
> path to the subtree in .
>  (iii) Perhaps I2RS and dynamic datastores may also throw up some new
> examples.

The tags draft has an RPC to 'reset to default state'.  I could see
wanting the reset to be persistent or not depending on actual usage...

Lou
> 
> Thanks,
> Rob
> 
> 


From nobody Mon Nov  6 09:04: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 986A213FBB2 for ; Mon,  6 Nov 2017 09:04:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eZvWCMqopE2t for ; Mon,  6 Nov 2017 09:04:17 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6211A13FB36 for ; Mon,  6 Nov 2017 09:04:17 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 208DEF71; Mon,  6 Nov 2017 18:04:16 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ubetESud50Is; Mon,  6 Nov 2017 18:04:13 +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,  6 Nov 2017 18:04:15 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEF8720116; Mon,  6 Nov 2017 18:04:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lNjlGkDLS4PG; Mon,  6 Nov 2017 18:04:15 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65F002010B; Mon,  6 Nov 2017 18:04:15 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D1455414D520; Mon,  6 Nov 2017 18:02:47 +0100 (CET)
Date: Mon, 6 Nov 2017 18:02:47 +0100
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Robert Wilton , netmod@ietf.org
Message-ID: <20171106170247.l4tmjglageyakqgx@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Robert Wilton , netmod@ietf.org
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.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] 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: Mon, 06 Nov 2017 17:04:19 -0000

On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
> 
> The tags draft has an RPC to 'reset to default state'.  I could see
> wanting the reset to be persistent or not depending on actual usage...
>

In general, I think we love the usage of standard operations like
edit-config to manipulate configuration datastores and I think we
dislike custom operations that manipulate configuration datastores.

/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 Nov  6 09:08: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 52C9013FBEF for ; Mon,  6 Nov 2017 09:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 X3nDKuAT8TmF for ; Mon,  6 Nov 2017 09:08:22 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247A913FB6E for ; Mon,  6 Nov 2017 09:08:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3879; q=dns/txt; s=iport; t=1509988102; x=1511197702; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8rkoJH8+44orwRi7Ppt3CkAv4gStxX1A8C4tNHWl6po=; b=Ff7bvfX8QuL5zEjbTWq88OlB8g9iBiS/ZBpx896eHH/desLybxNiWpYI NjabIh5WJTPsOsWHSevLNykhOz/Y3GdJUv3Mcl5RSw8xZt0bFwdKM3B/E M48KJ/J3kwGZR4MEkJfEfVIvZkWCVOJ0kQi17aWQDcS/HeNHuWzhCwR5s s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAABAlgBa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQYng32KH3SQJZZGEIIBCoU7AoUnGAEBAQEBAQEBAWsohR4BAQQ?= =?us-ascii?q?BIw8BBVEZCgICJgICVwYBDAYCAQEXigAIqyOCJ4sMAQEBAQEBAQECAQEBAQEBI?= =?us-ascii?q?oEPgh+DWoISgwGEeoMsgmIFog6Bb5MNi3iHPI4ph22BOR84gWw0IQgdFUmCZIR?= =?us-ascii?q?fQTaLdgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,353,1505779200";  d="scan'208";a="102218"
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; 06 Nov 2017 17:08:19 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA6H8JBY020030; Mon, 6 Nov 2017 17:08:19 GMT
To: Lou Berger , netmod@ietf.org
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  
From: Robert Wilton 
Message-ID: 
Date: Mon, 6 Nov 2017 17:08:19 +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: [netmod] Reset tags RPC [was Re:  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: Mon, 06 Nov 2017 17:08:24 -0000

Renaming this sub thread to avoid confusing the main discussion.


On 06/11/2017 16:48, Lou Berger wrote:
> On 11/06/2017 11:41 AM, Robert Wilton wrote:
>>
>> On 06/11/2017 15:51, Lou Berger wrote:
>>>
>>> On November 6, 2017 10:21:19 AM Robert Wilton  wrote:
>>>
>>>> Hi Lou,
>>>>
>>>> All of proposed solutions (A through D) allow the action or the RPC to
>>>> perform whatever behaviour that it wants.
>>>>
>>>> This issue is only about which datastore is used to evaluate and check
>>>> that the parameters for the action/rpc are valid.  E.g. if the
>>>> parameters use when, must, leaf-ref, or instance-identifier.
>>>>
>>>> So, to take option "A" for example: "A.  Always use  for 1
>>>> and 2."
>>>>
>>>> One can still define a RPC that modifies another datastore ("edit-data"
>>>> in the NETCONF NMDA  draft is one such example).  But to check whether
>>>> the edit-data request can be performed, any input parameter constraints
>>>> would be evaluated against .  However, given that the input
>>>> parameters to edit-data don't contain any when, must, leaf-ref, or
>>>> instance-identifier statements then it makes absolutely no functional
>>>> difference which the datastore the parameters are evaluated in, since
>>>> the result will always be the same regardless.  But perhaps it just
>>>> feels a little odd that they are conceptually evaluated against
>>>> operational, even though the RPC only even affects one of the editable
>>>> configurable datastores.
>>>>
>>>
>>> Yes, which is why I've been assuming we'd end up with c.
>> But I think that to do C properly also requires a new optional statement
>> in YANG to indicate where the Action/RPC parameters are evaluated (with
>> the default being  if the new statement isn't specified).
>>
>> Most RPCs/Action statements seem to naturally apply to .
>>
>> For the RPCs/Action statements that don't naturally apply to
>> , it seems that it mostly doesn't matter where the
>> parameters are evaluated.
>>
>> At the moment, the set of remaining RPCs/Actions (don't apply to
>>  but do care about parameter evaluation) seems quite small:
>>   (i) RFC7517, if it defined a YANG model for the  RPC
>>   (ii) A partial datastore diff from a subtree in  to
>>  might be another - it would want an instance-identifier
>> path to the subtree in .
>>   (iii) Perhaps I2RS and dynamic datastores may also throw up some new
>> examples.
> The tags draft has an RPC to 'reset to default state'.  I could see
> wanting the reset to be persistent or not depending on actual usage...
OK, I don't understand why this RPC is needed at all.

If the tags are managed through config (which I think that they are), 
then calling the "reset to default state" RPC should be equivalent to a 
normal list entry delete for that module anyway.

Why do you need two methods to achieve the same thing?  Or does this RPC 
do something slightly different?

Personally, I think that it would be better if the only way of editing 
configuration is through an  RPC.

A couple of other nits on the tags draft:
  - the tree diagram in 6.1 doesn't cover the config, perhaps it is out 
of date.
  - I would put list module-tags into a container (e.g. to make it 
easier to delete, or replace, all tag information).
  - do the configured tags replace the devices list or merge with them 
(perhaps this could be clarified)?  If merge, then presumably you also 
need a way to delete existing entries.  E.g. perhaps "grouping 
module-tags" also needs a separate leaf-list of tags to delete (really 
hide) from the implementation?

Thanks,
Rob


>
> Lou
>> Thanks,
>> Rob
>>
>>
> .
>


From nobody Mon Nov  6 09:12: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 AD6F613FC58 for ; Mon,  6 Nov 2017 09:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZgR75GRp6TGP for ; Mon,  6 Nov 2017 09:12:37 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF8C13FC56 for ; Mon,  6 Nov 2017 09:12:36 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 60C731E0A06 for ; Mon,  6 Nov 2017 10:12:36 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id WhCZ1w0082SSUrH01hCclD; Mon, 06 Nov 2017 10:12:36 -0700
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=sC3jslCIGhcA:10 a=B6bsVrN823sM5u_vJfoA: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=AQ11vQZAJjlgxAEsnMpv48jSGVFGuF37h81QmT8Y5uk=; b=MoI+5EDxIWZYPxeldevQqsKBvf E7l/4YgMljuO21p93DN5uOndNIaSsjnWoR7oR4yDf7kr0MVDbAxzmCXauCbZtfur0On751nvLZHq1 nl5NeMYPlwvl0EVGOG+G5bNks;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:35748 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eBkwr-000ncv-5f; Mon, 06 Nov 2017 10:12:33 -0700
To: Robert Wilton , netmod@ietf.org
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>   <20171106170247.l4tmjglageyakqgx@elstar.local>
From: Lou Berger 
Message-ID: <4dbcf0d6-a11a-e410-a958-32058914da53@labn.net>
Date: Mon, 6 Nov 2017 12:12:30 -0500
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: <20171106170247.l4tmjglageyakqgx@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: 1eBkwr-000ncv-5f
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]:35748
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Mon, 06 Nov 2017 17:12:41 -0000

What's the standard way to reset a list to a default (based on
implementation)?

On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:
> On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
>> The tags draft has an RPC to 'reset to default state'.  I could see
>> wanting the reset to be persistent or not depending on actual usage...
>>
> In general, I think we love the usage of standard operations like
> edit-config to manipulate configuration datastores and I think we
> dislike custom operations that manipulate configuration datastores.
>
> /js
>


From nobody Mon Nov  6 09:16: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 A359D13FB55 for ; Mon,  6 Nov 2017 09:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOE6yhP0K8tI for ; Mon,  6 Nov 2017 09:15:57 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD3D13FAF7 for ; Mon,  6 Nov 2017 09:15:57 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id g70so11334919lfl.3 for ; Mon, 06 Nov 2017 09:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5dsVRGD2b0d4i4mJJkvklkI14JdbNyFmukzBHQqIY6s=; b=14F14hZhgeLx1znKrA444osZ5zxHhNY+G6eTGthAD1VAw0tDf64zzUZmKAxQx9FMel fiYq8mUISYKQt8SynzU9TjbUiRzyp4c1wVCx0to2cClETYcZJ14V2/xi4uhSCU/LprUm +q4K4qhLvPARYUJYjs3+PVq1oLONackxLTrDwratAbBw/3E8tIxDglnK8FZMCgg6O0OC TfHeZvc+3qbX6ADPzGkc8kFfTkZGA6Z9OxvfLVdwcphuuPSIGj5IUGko+D8EPRsf6I2l Lk9fA6smNay4g204C2qz1i1C2fXCh7xj9SjA3KxriitSo1ZZ9UXox9Lht0D+ULeBlNzL Fgmg==
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=5dsVRGD2b0d4i4mJJkvklkI14JdbNyFmukzBHQqIY6s=; b=CjtEdwQRfh4nlyYxYodYpVGnC5CUR2UqgrLWnkJFFFojeA/h43oXy59MdMi7xEOgMh Ge2KB1EhZepeQlbP9e8mLNkbCKzdLisY+cbJZrBqA8zKXdETz+llKQRFjZ4Drlvj7JmO /aNrQGmwfwj1oLKO4ZbGlK+wHOTDjKj5hw1hE8AD15lnzjw6DEfhtgAAgbkj5OCSBFuv q72g3PxmdP2mL9uQecIO419Pn/dHM6ufoWDhoDTvKWxgViZflKS4tEW8eBEUAuYQU6yB ebEERWmHZpC1BUr1uyYE/0799MKxWXCfXoXS43dypBOq0/NY5oOokyJW4vQNEkTWkI2Q y6fA==
X-Gm-Message-State: AMCzsaVLQL9VI2+V4630s8ZY7ptgdZu90CaEHs0bnG724ugP9Bc3mUl3 POZfSBl8Gybc8bn8mhOAtgdciyjx5sOvbqnyn5Qt4Q==
X-Google-Smtp-Source: ABhQp+S0CAxsbJQdDAmuJ7MWsiB3lAC3ucUFawHjm/aQHw8v7osi4irYw1ZuoK/sFOmYvT44cyRwL+50ARsSmqgQsL8=
X-Received: by 10.25.23.165 with SMTP id 37mr5657809lfx.202.1509988555344; Mon, 06 Nov 2017 09:15:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Mon, 6 Nov 2017 09:15:54 -0800 (PST)
In-Reply-To: <20171106.141924.996087392255055625.mbj@tail-f.com>
References:  <201711022116.vA2LGTB3044617@idle.juniper.net>  <20171106.141924.996087392255055625.mbj@tail-f.com>
From: Andy Bierman 
Date: Mon, 6 Nov 2017 09:15:54 -0800
Message-ID: 
To: Martin Bjorklund 
Cc: Phil Shafer , Robert Wilton ,  Kent Watsen , "netmod@ietf.org" ,  Randy Presuhn 
Content-Type: multipart/alternative; boundary="001a11401a0474e7db055d539bd0"
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: Mon, 06 Nov 2017 17:16:01 -0000

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

On Mon, Nov 6, 2017 at 5:19 AM, Martin Bjorklund  wrote:

> Hi,
>
> Trying to summarize this issue.
>
> The problem is which datastore is used to:
>
>     1a. evaluate action ancestor nodes
>     1b. evaluate action input/output parameter leafref,
>         instance-identifier, must, when
>     2.  evaluate rpc input/output parameter leafref,
>         instance-identifier, must, when
>
> (Note that the side effects of an action/rpc is not part of this
> issue)
>
> I think it would be very weird if 1a and 1b were treated differently,
> so I just label them as 1 below.
>
> Possible solutions:
>
> A.  Always use  for 1 and 2.
>
>     (This is what the current nmda draft says).
>
> B.  Let the client specify the datastore for 1, and use 
>     for 2.
>
>     (Note that this is trivial in RESTCONF (since the datastore is
>     part of the URL), but would require a new parameter for NETCONF
>     (or a new ).
>
> C.  Let the client specify the datastore for 1 and 2.
>
>     This would require a new generic parameter for how RPCs are
>     invoked in both NETCONF and RESTCONF.
>
> D.  Like B, but let the description of the "rpc" statement optionally
>     override this.
>
>
> I prefer B and then D.
>
>
>

I prefer (A).

I do not see how this is transparent to non-NMDA clients that use actions
and/or rpcs.
The evaluation of config=true nodes change from  to .
This is a significant change that can break non-NMDA clients.

A non-NMDA client thinks the server is performing XPath evaluation according
to RFC 7950, sec. 6.4.1.


   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, all state data in the
      server, and the running configuration datastore.  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.

   o  If the XPath expression is defined in a substatement to an
      "output" statement in an "rpc" or "action" statement, the
      accessible tree is the RPC or action operation instance, all state
      data in the server, and the running configuration datastore.  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
      output parameters as children.



> /martin
>
>
>

Andy



>
>
> Andy Bierman  wrote:
> > On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
> >
> > > Sorry, if I wasn't clear.  I meant the  element would
> > > be directly under , so the system knows where to start
> > > looking for data.  Guessing is bad.
> > >
> > >
> > Totally agree guessing is bad.
> > Did you see the  proposal in a previous email?
> > That is exactly what I proposed, except I do not want to
> > overload  so the new template would be a different name.
> >
> > I realize the expanded name of the datastore element prevents it from
> > being confused with top-level YANG nodes, but the conformance
> > is more clear with a new name.
> >
> >
> >
> >
> > > Thanks,
> > >  Phil
> > >
> >
> > Andy
> >
> >
> > >
> > >
> > > Andy Bierman writes:
> > > >So a server will be required to guess the correct datastore until it
> > > >finds the right one that matches the action instance?
> > > >
> > > >   
> > > >       
> > > >          
> > > >             10
> > > >             
> > > >                candidate
> > > >             
> > > >          
> > > >        
> > > >    
> > > >
> > > >The server will guess the datastore in some proprietary order and
> parse
> > > >instances of /top/ and /top/list1.  Then it finds the  action
> > > >and parses the input to get to the datastore and find out the real
> > > datastore
> > > >to use.  If the server guessed wrong, then it reparses the 
> > > against
> > > >the requested datastore.  Hopefully the schema trees match up.
> > > >
> > > >Will vendors do all the extra work required to support this sort of
> thing?
> > > >I doubt it.
> > > >
> > > >
> > > >Andy
> > > >
> > > >
> > > >
> > > >
> > > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
> wrote:
> > > >
> > > >> 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
> > > >>
> > > >
> > > >--001a11411b0ad2d58d055cee96cb
> > > >Content-Type: text/html; charset="UTF-8"
> > > >Content-Transfer-Encoding: quoted-printable
> > > >
> > > >
Hi,

So a server will be required
> to
> > > gue=
> > > >ss the correct datastore until it
finds the right one that
> > > matche=
> > > >s the action instance?

=C2=A0
> > > =C2=A0<action>=
> > > >
=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>
=C2=A0
> > > =C2=A0 =
> > > >=C2=A0 =C2=A0 =C2=A0 <list1>
=C2=A0 =C2=A0 =C2=A0
> =C2=A0 =
> > > >=C2=A0 =C2=A0 =C2=A0<key>10</key>
=C2=A0 =C2=A0
> > > =C2=
> > > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test>
=C2=A0
> =C2=A0
> > > =C2=
> > > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <datastore>candidate<
> > > /datas=
> > > >tore>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > > =C2=A0</do-=
> > > >test>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > > </list1>
<=
> > > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
=C2=A0 =C2=A0
> > > </a=
> > > >ction>

The server will guess the
> datastore
> > > in s=
> > > >ome proprietary order and parse
instances of /top/ and
> > > /top/list1=
> > > >.=C2=A0 Then it finds the <do-test> action
and parses
> the
> > > i=
> > > >nput to get to the datastore and find out the real
> datastore
to
> > > u=
> > > >se.=C2=A0 If the server guessed wrong, then it reparses the
> > > <action> =
> > > >against
the requested datastore.=C2=A0 Hopefully the schema
> > > trees=
> > > > match up.

Will vendors do all the extra
> work
> > > requ=
> > > >ired to support this sort of thing?
I doubt
> > > it.

 > > >iv>

Andy


 > > div>

 > > >iv>

On
> Tue,
> > > O=
> > > >ct 31, 2017 at 11:36 PM, Phil Shafer < > > href=3D"mailt=
> > > >o:phil@juniper.net" target=3D"_blank">phil@juniper.net>
> > > wrote=
> > > >:
 > > .8ex;border-le=
> > > >ft:1px #ccc solid;padding-left:1ex">Robert Wilton writes:

> > > >>ii) However, as far as I can see, it doesn't make sense for an
> > > acti=
> > > >on to

> > > >>directly affect the contents of any configuration datastore, that
> > > shoul=
> > > >d

> > > >>be done via a purpose built rpc (like edit-config).

> > > >

> > > >An example action would be to retrieve the=C2=A0 fingerprint of an
> ssh

> > > >key.=C2=A0 I might want to get the fingerprint of a key in
> > > <candidate>=
> > > >;

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

> > > >

> > > >Seems like <startup> 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?=C2=A0 Any specific RPC can define
> its

> > > >own datastore leaf of hard-code the database in the description

> > > >(explicitly or implicitly <operational>), but the <action>
> > > RPC =
> > > >only

> > > >gets this if we make a new parameter for it.

> > > >

> > > >Thanks,

> > > >=C2=A0Phil

> > > >


> > > >
> > > >--001a11411b0ad2d58d055cee96cb--
> > >
>

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




On Mon, Nov 6, 2017 at 5:19 AM, Martin Bjorklund <=
mbj@tail-f.com><=
/span> wrote:
Hi,



Trying to summarize this issue.



The problem is which datastore is used to:



=C2=A0 =C2=A0 1a. evaluate action ancestor nodes

=C2=A0 =C2=A0 1b. evaluate action input/output parameter leafref,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identifier, must, when

=C2=A0 =C2=A0 2.=C2=A0 evaluate rpc input/output parameter leafref,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 instance-identifier, must, when



(Note that the side effects of an action/rpc is not part of this

issue)



I think it would be very weird if 1a and 1b were treated differently,

so I just label them as 1 below.



Possible solutions:



A.=C2=A0 Always use <operational> for 1 and 2.



=C2=A0 =C2=A0 (This is what the current nmda draft says).



B.=C2=A0 Let the client specify the datastore for 1, and use <operationa=
l>

=C2=A0 =C2=A0 for 2.



=C2=A0 =C2=A0 (Note that this is trivial in RESTCONF (since the datastore i=
s

=C2=A0 =C2=A0 part of the URL), but would require a new parameter for NETCO=
NF

=C2=A0 =C2=A0 (or a new <action2>).



C.=C2=A0 Let the client specify the datastore for 1 and 2.



=C2=A0 =C2=A0 This would require a new generic parameter for how RPCs are
=C2=A0 =C2=A0 invoked in both NETCONF and RESTCONF.



D.=C2=A0 Like B, but let the description of the "rpc" statement o=
ptionally

=C2=A0 =C2=A0 override this.





I prefer B and then D.






I prefer (A).

I do not see how this is transparent to non-NMDA clients th=
at use actions and/or rpcs.
The evaluation of config=3Dtrue nodes=
 change from <running> to <operational>.
This is a si=
gnificant change that can break non-NMDA clients.

=
A non-NMDA client thinks the server is performing XPath evaluation accordin=
g
to RFC 7950, sec. 6.4.1.


   o  If the XPath expression is defined in a substatement to an "inp=
ut"
      statement in an "rpc" or "action" statement, the =
accessible tree
      is the RPC or action operation instance, all state data in the
      server, and the running configuration datastore.  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 inpu=
t
      parameters as children.

   o  If the XPath expression is defined in a substatement to an
      "output" statement in an "rpc" or "action&qu=
ot; statement, the
      accessible tree is the RPC or action operation instance, all state
      data in the server, and the running configuration datastore.  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
      output parameters as children.
=C2=A0

/martin






Andy

=C2=A0





Andy Bierman <andy@yumaworks.com> wrote:

> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer <phil@juniper.net> wrote:

>

> > Sorry, if I wasn't clear.=C2=A0 I meant the <datastore>=
 element would

> > be directly under <action>, so the system knows where to st=
art

> > looking for data.=C2=A0 Guessing is bad.

> >

> >

> Totally agree guessing is bad.

> Did you see the <action2> proposal in a previous email?

> That is exactly what I proposed, except I do not want to

> overload <action> so the new template would be a different name.=


>

> I realize the expanded name of the datastore element prevents it from<=
br>
> being confused with top-level YANG nodes, but the conformance

> is more clear with a new name.

>

>

>

>

> > Thanks,

> >=C2=A0 Phil

> >

>

> Andy

>

>

> >

> >

> > Andy Bierman writes:

> > >So a server will be required to guess the correct datastore u=
ntil it

> > >finds the right one that matches the action instance?

> > >

> > >=C2=A0 =C2=A0<action>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<top>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <list1>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<key>10=
</key>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<do-test&g=
t;

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <d=
atastore>candidate</datastore>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</do-test&=
gt;

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </list1>

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>

> > >=C2=A0 =C2=A0 </action>

> > >

> > >The server will guess the datastore in some proprietary order=
 and parse

> > >instances of /top/ and /top/list1.=C2=A0 Then it finds the &l=
t;do-test> action

> > >and parses the input to get to the datastore and find out the=
 real

> > datastore

> > >to use.=C2=A0 If the server guessed wrong, then it reparses t=
he <action>

> > against

> > >the requested datastore.=C2=A0 Hopefully the schema trees mat=
ch up.

> > >

> > >Will vendors do all the extra work required to support this s=
ort of thing?

> > >I doubt it.

> > >

> > >

> > >Andy

> > >

> > >

> > >

> > >

> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer <phil@juniper.net> wrote:

> > >

> > >> Robert Wilton writes:

> > >> >ii) However, as far as I can see, it doesn't mak=
e sense for an action

> > to

> > >> >directly affect the contents of any configuration da=
tastore, that

> > should

> > >> >be done via a purpose built rpc (like edit-config).<=
br>
> > >>

> > >> An example action would be to retrieve the=C2=A0 fingerp=
rint of an ssh

> > >> key.=C2=A0 I might want to get the fingerprint of a key =
in <candidate>

> > >> 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 <cand=
idate>.

> > >>

> > >> Seems like <startup> 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, an=
d the problem

> > >> with ruling it out is that it becomes needed at some lat=
er 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/a=
ction and

> > >> have it default to operational?=C2=A0 Any specific RPC c=
an define its

> > >> own datastore leaf of hard-code the database in the desc=
ription

> > >> (explicitly or implicitly <operational>), but the =
<action> RPC only

> > >> gets this if we make a new parameter for it.

> > >>

> > >> Thanks,

> > >>=C2=A0 Phil

> > >>

> > >

> > >--001a11411b0ad2d58d055cee96cb

> > >Content-Type: text/html; charset=3D"UTF-8"

> > >Content-Transfer-Encoding: quoted-printable

> > >

> > ><div dir=3D3D"ltr">Hi,<div><br>&l=
t;/div><div>So a server will be required to

> > gue=3D

> > >ss the correct datastore until it</div><div>finds=
 the right one that

> > matche=3D

> > >s the action instance?</div><div><br></d=
iv><div>=3DC2=3DA0

> > =3DC2=3DA0&lt;action&gt;=3D

> > ></div><div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=
=3DA0&lt;top&gt;</div><div>=3DC2=3DA0

> > =3DC2=3DA0 =3D

> > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 &lt;list1&gt;</di=
v><div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D

> > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0&lt;key&gt;10&lt;=
/key&gt;</div><div>=3DC2=3DA0 =3DC2=3DA0

> > =3DC2=3D

> > >=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0&lt;do-t=
est&gt;</div><div>=3DC2=3DA0 =3DC2=3DA0

> > =3DC2=3D

> > >=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =
&lt;datastore&gt;candidate&lt;

> > /datas=3D

> > >tore&gt;</div><div>=3DC2=3DA0 =3DC2=3DA0 =3DC=
2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0

> > =3DC2=3DA0&lt;/do-=3D

> > >test&gt;</div><div>=3DC2=3DA0 =3DC2=3DA0 =3DC=
2=3DA0 =3DC2=3DA0 =3DC2=3DA0

> > &lt;/list1&gt;</div><=3D

> > >div>=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 &lt;/t=
op&gt;</div><div>=3DC2=3DA0 =3DC2=3DA0

> > &lt;/a=3D

> > >ction&gt;</div><div><br></div&g=
t;<div>The server will guess the datastore

> > in s=3D

> > >ome proprietary order and parse</div><div>instanc=
es of /top/ and

> > /top/list1=3D

> > >.=3DC2=3DA0 Then it finds the &lt;do-test&gt; action&=
lt;/div><div>and parses the

> > i=3D

> > >nput to get to the datastore and find out the real datastore&=
lt;/div><div>to

> > u=3D

> > >se.=3DC2=3DA0 If the server guessed wrong, then it reparses t=
he

> > &lt;action&gt; =3D

> > >against</div><div>the requested datastore.=3DC2=
=3DA0 Hopefully the schema

> > trees=3D

> > > match up.</div><div><br></div><di=
v>Will vendors do all the extra work

> > requ=3D

> > >ired to support this sort of thing?</div><div>I d=
oubt

> > it.</div><div><br></d=3D

> > >iv><div><br></div><div>Andy</div><div><br></div><div><br></

> > div><div><br></d=3D

> > >iv><div><div class=3D3D"gmail_extra">=
;<br><div class=3D3D"gmail_quote">On Tue,

> > O=3D

> > >ct 31, 2017 at 11:36 PM, Phil Shafer <span dir=3D3D"l=
tr">&lt;<a

> > href=3D3D"mailt=3D

> > >o:phil@juniper.net" target=3D3D"_blank">phil@juniper.net</a>&gt;</span>

> > wrote=3D

> > >:<br><blockquote class=3D3D"gmail_quote" s=
tyle=3D3D"margin:0 0 0

> > .8ex;border-le=3D

> > >ft:1px #ccc solid;padding-left:1ex">Robert Wilton wri=
tes:<br>

> > >&gt;ii) However, as far as I can see, it doesn&#39;t =
make sense for an

> > acti=3D

> > >on to<br>

> > >&gt;directly affect the contents of any configuration dat=
astore, that

> > shoul=3D

> > >d<br>

> > >&gt;be done via a purpose built rpc (like edit-config).&l=
t;br>

> > ><br>

> > >An example action would be to retrieve the=3DC2=3DA0 fingerpr=
int of an ssh<br>

> > >key.=3DC2=3DA0 I might want to get the fingerprint of a key i=
n

> > &lt;candidate&gt=3D

> > >;<br>

> > >before I commit it.<br>

> > ><br>

> > >Or I could have an action that sets the SNMPv3 auth key to a =
random<br>

> > >value, and I want to invoke that action against &lt;candi=
date&gt;.<br>

> > ><br>

> > >Seems like &lt;startup&gt; might also be an interesti=
ng place to

> > target<br>

> > >actions, but I can&#39;t think of a good example.<br&g=
t;

> > ><br>

> > >There are always scenarios where something is useful, and the=
 problem<br>

> > >with ruling it out is that it becomes needed at some later po=
int.<br>

> > >We&#39;ve a habit of ruling out things and later wishing =
we had them.<br>

> > ><br>

> > >Is the easy fix to just put a datastore leaf under rpc/action=
 and<br>

> > >have it default to operational?=3DC2=3DA0 Any specific RPC ca=
n define its<br>

> > >own datastore leaf of hard-code the database in the descripti=
on<br>

> > >(explicitly or implicitly &lt;operational&gt;), but t=
he &lt;action&gt;

> > RPC =3D

> > >only<br>

> > >gets this if we make a new parameter for it.<br>

> > ><br>

> > >Thanks,<br>

> > >=3DC2=3DA0Phil<br>

> > ></blockquote></div><br></div><=
;/div></div>

> > >

> > >--001a11411b0ad2d58d055cee96cb--

> >





--001a11401a0474e7db055d539bd0--


From nobody Mon Nov  6 09:18: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 7274413FB55 for ; Mon,  6 Nov 2017 09:18:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oQr1hraSINuv for ; Mon,  6 Nov 2017 09:18:37 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B22D13FAF7 for ; Mon,  6 Nov 2017 09:18:37 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CD6D46A0; Mon,  6 Nov 2017 18:18:35 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id jsPfHB4YSvY1; Mon,  6 Nov 2017 18:18:33 +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,  6 Nov 2017 18:18:35 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B782920110; Mon,  6 Nov 2017 18:18:35 +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 W6xMKNFNeNl3; Mon,  6 Nov 2017 18:18:35 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 656462010B; Mon,  6 Nov 2017 18:18:35 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 130ED414D62A; Mon,  6 Nov 2017 18:17:08 +0100 (CET)
Date: Mon, 6 Nov 2017 18:17:07 +0100
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Robert Wilton , netmod@ietf.org
Message-ID: <20171106171707.hd535oyhpysnxtec@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Robert Wilton , netmod@ietf.org
References: <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>   <20171106170247.l4tmjglageyakqgx@elstar.local> <4dbcf0d6-a11a-e410-a958-32058914da53@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4dbcf0d6-a11a-e410-a958-32058914da53@labn.net>
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: Mon, 06 Nov 2017 17:18:38 -0000

What is default content of a list? Where is this coming from?

/js

On Mon, Nov 06, 2017 at 12:12:30PM -0500, Lou Berger wrote:
> 
> What's the standard way to reset a list to a default (based on
> implementation)?
> 
> On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:
> > On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
> >> The tags draft has an RPC to 'reset to default state'.  I could see
> >> wanting the reset to be persistent or not depending on actual usage...
> >>
> > In general, I think we love the usage of standard operations like
> > edit-config to manipulate configuration datastores and I think we
> > dislike custom operations that manipulate configuration datastores.
> >
> > /js
> >
> 
> _______________________________________________
> 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 Nov  6 09:20: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 6E0A413FB1D for ; Mon,  6 Nov 2017 09:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Yck00t9uC3zS for ; Mon,  6 Nov 2017 09:20:25 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D179D13FAF7 for ; Mon,  6 Nov 2017 09:20:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1112; q=dns/txt; s=iport; t=1509988825; x=1511198425; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=k1hCuIEJS+NU8otuk6PurEfNpWmVOv/1wE3Xeegx2QM=; b=UWwAB3wSNtITVQyes6L6VUbeJkMKtlO4IbRFS+091OHlb+SAcJjpKM1m nnfIsSVrhOtwkWBN0hSGUjTCd31ot574vTmLXwj1gXdUkLkWys3VK5mIP HNvdSxcPLRxA73IH6DzSZjHBQN5oKjjwlX7EWVf4X6watH1TNYDjehEIS c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAgB3mQBa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIsTj38mllaCAQqFOwKFKhUBAQEBAQEBAQFrKIUfAQUjDwE?= =?us-ascii?q?FUQsOCgICJgICVwYBDAgBAReKCKsTgieLDAEBAQEBAQEDAQEBAQEBIoEPgh+DW?= =?us-ascii?q?oISC4J2hHqDLIJiBaIOlHyLeIc8jimHbYE5NSKBbDQhCB0Vgy6EXkGMLAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,353,1505779200";  d="scan'208";a="50015"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2017 17:20:22 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA6HKM20027042; Mon, 6 Nov 2017 17:20:22 GMT
To: Lou Berger , netmod@ietf.org
References:  <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>   <20171106170247.l4tmjglageyakqgx@elstar.local>
From: Robert Wilton 
Message-ID: <1331a06a-4feb-6278-aad3-f43932f649d6@cisco.com>
Date: Mon, 6 Nov 2017 17:20:22 +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: <20171106170247.l4tmjglageyakqgx@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: Mon, 06 Nov 2017 17:20:27 -0000

On 06/11/2017 17:02, Juergen Schoenwaelder wrote:
> On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
>> The tags draft has an RPC to 'reset to default state'.  I could see
>> wanting the reset to be persistent or not depending on actual usage...
>>
> In general, I think we love the usage of standard operations like
> edit-config to manipulate configuration datastores and I think we
> dislike custom operations that manipulate configuration datastores.
Yes.

I also dislike the idea of client managed persistent data that is not 
configuration.

E.g. I think that the subscriptions draft has this right:  It has 
configurable subscriptions, that are persistent; and rpc based dynamic 
subscriptions, that are not persistent.

If the tags draft defined RPCs to modify the module tags in a non 
persistent way then that would be OK with me (if this is actually 
useful), it is just that those actions/rpcs would end up only acting 
against the data in , and hence I think solution A would 
actually be sufficient for this case.

Thanks,
Rob


>
> /js
>


From nobody Mon Nov  6 09:24: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 520AF13FB68 for ; Mon,  6 Nov 2017 09:24:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TaP8CkFrKXj8 for ; Mon,  6 Nov 2017 09:24:34 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C1613FAF7 for ; Mon,  6 Nov 2017 09:24:34 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 77BBF1E0B0E for ; Mon,  6 Nov 2017 10:24:34 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id WhQX1w00V2SSUrH01hQa8r; Mon, 06 Nov 2017 10:24:34 -0700
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=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=lr2ujRqUopnOCGUPdbUA: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=FQ9ZVBZg5ktabi9+wGNLckBujSTgqJXEWYtWy5HnVPQ=; b=RWbyOVuC/KP4vQe/oLGaew6cT6 5YDjKUb7hAhM3hytKHaM+4oaWBEWnu/3N8BZgRLqbCxhOtl0tja8sltL9Iars0U7azRKoG4y731km m+xDJHLc7vFyAfXVQfZD4yTc5;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:37262 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eBl8R-000q6R-8i; Mon, 06 Nov 2017 10:24:31 -0700
To: Robert Wilton , netmod@ietf.org
References: <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>   <20171106170247.l4tmjglageyakqgx@elstar.local> <4dbcf0d6-a11a-e410-a958-32058914da53@labn.net> <20171106171707.hd535oyhpysnxtec@elstar.local>
From: Lou Berger 
Message-ID: 
Date: Mon, 6 Nov 2017 12:24:28 -0500
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: <20171106171707.hd535oyhpysnxtec@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: 1eBl8R-000q6R-8i
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]:37262
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Mon, 06 Nov 2017 17:24:36 -0000

On 11/6/2017 12:17 PM, Juergen Schoenwaelder wrote:
> What is default content of a list? Where is this coming from?
Whatever the vendor chooses in their code, and perhaps what gets defined
in future model definitions...
Lou

> /js
>
> On Mon, Nov 06, 2017 at 12:12:30PM -0500, Lou Berger wrote:
>> What's the standard way to reset a list to a default (based on
>> implementation)?
>>
>> On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:
>>> On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
>>>> The tags draft has an RPC to 'reset to default state'.  I could see
>>>> wanting the reset to be persistent or not depending on actual usage...
>>>>
>>> In general, I think we love the usage of standard operations like
>>> edit-config to manipulate configuration datastores and I think we
>>> dislike custom operations that manipulate configuration datastores.
>>>
>>> /js
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Nov  6 09:30: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 5FFEB13FBAB for ; Mon,  6 Nov 2017 09:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 TFxID1sgguxc for ; Mon,  6 Nov 2017 09:30:20 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EEEF13FBA8 for ; Mon,  6 Nov 2017 09:30:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1616; q=dns/txt; s=iport; t=1509989419; x=1511199019; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=6jJOV0C08dmJq7Wgdi47yXWSZKPnibS7Ur0y4dOMX60=; b=V5Fi/pXoh5oIZelF53sthT56vvUAoiH8YR+5XypmnQ1ROvnnFPTevF9C LCO2tKjpCupntBw0J5u74ShC7ST2wd7OXoF41+JP147iYerVDZGwccxA2 UqK2zG0Oe6RmXN0f+M5Xv5NDqguYyXHxedFyfRlsg1Xaa3KdjrWfmZAAE E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAgAYmwBa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhBhuJ4N9ixOPfyaWVoIBChgLhElPAoUqFQEBAQEBAQEBAWsohR4?= =?us-ascii?q?BAQEDAQEBIQ8BBTYQCwsOCgICJgICJzAGAQwGAgEBihcIEKsIgieLDAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEaBYEPgh+DWoISC4J2hHqDLIJiBaIOlHyLeIc8jimHbYE?= =?us-ascii?q?5NSKBbDQhCB0VSYJkhF9BNot2AQEB?=
X-IronPort-AV: E=Sophos;i="5.44,353,1505779200";  d="scan'208";a="57526"
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; 06 Nov 2017 17:30:17 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA6HUHh4018901; Mon, 6 Nov 2017 17:30:17 GMT
To: Lou Berger , netmod@ietf.org
References: <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>   <20171106170247.l4tmjglageyakqgx@elstar.local> <4dbcf0d6-a11a-e410-a958-32058914da53@labn.net> <20171106171707.hd535oyhpysnxtec@elstar.local> 
From: Robert Wilton 
Message-ID: 
Date: Mon, 6 Nov 2017 17:30:17 +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: Mon, 06 Nov 2017 17:30:21 -0000

On 06/11/2017 17:24, Lou Berger wrote:
>
> On 11/6/2017 12:17 PM, Juergen Schoenwaelder wrote:
>> What is default content of a list? Where is this coming from?
> Whatever the vendor chooses in their code, and perhaps what gets defined
> in future model definitions...
This is mixing up config and state:

The device's default module tags wouldn't be in , only in 
, [ and perhaps .]

Only the clients configured modification to the module tags ends up in 
.  This is merged with the system module tags, and then the 
resultant set end up in .

Resetting the list to default is achieved by just deleting the list 
entry in .  No special RPC is needed.

Thanks,
Rob

> Lou
>
>> /js
>>
>> On Mon, Nov 06, 2017 at 12:12:30PM -0500, Lou Berger wrote:
>>> What's the standard way to reset a list to a default (based on
>>> implementation)?
>>>
>>> On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:
>>>> On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
>>>>> The tags draft has an RPC to 'reset to default state'.  I could see
>>>>> wanting the reset to be persistent or not depending on actual usage...
>>>>>
>>>> In general, I think we love the usage of standard operations like
>>>> edit-config to manipulate configuration datastores and I think we
>>>> dislike custom operations that manipulate configuration datastores.
>>>>
>>>> /js
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Mon Nov  6 10:46: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 9BDD613FC17 for ; Mon,  6 Nov 2017 10:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5UlWwJtrDNiy for ; Mon,  6 Nov 2017 10:46:03 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 E248413FBB4 for ; Mon,  6 Nov 2017 10:46:02 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 6E64C140722 for ; Mon,  6 Nov 2017 11:46:00 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id Wilw1w00V2SSUrH01ilzCZ; Mon, 06 Nov 2017 11:46:00 -0700
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=sC3jslCIGhcA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=DKfOpxZBoGsPWl3n6O0A: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: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=AXmoWS2zJ1mELhGo1GXhAnUw3QbgVvV3us65ZW8sBJ4=; b=SvK8MhbShU9nZPrdvpP5rRhRjD 3tGDUwysQdn01KbKl1+ewsangfArsyaGs81pa+qB7j9kDqkuMHqQJsemBRR0EBwqx5iEGqJmvKzks zS/pvHeluNiLo45MoqKof7UK9;
Received: from [172.58.185.143] (port=45762 helo=[IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eBmPB-0018ft-6f; Mon, 06 Nov 2017 11:45:56 -0700
From: Lou Berger 
To: Robert Wilton , 
Date: Mon, 06 Nov 2017 13:45:49 -0500
Message-ID: <15f92a517f0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: 
References: <20171106.141924.996087392255055625.mbj@tail-f.com> <15f9188b728.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20171106.154913.1683303692062360930.mbj@tail-f.com> <15f91db9dd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5c1d29df-4cdf-4972-5a11-0a111177bf93@cisco.com> <15f92077478.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>   <20171106170247.l4tmjglageyakqgx@elstar.local> <4dbcf0d6-a11a-e410-a958-32058914da53@labn.net> <20171106171707.hd535oyhpysnxtec@elstar.local>  
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.185.143
X-Exim-ID: 1eBmPB-0018ft-6f
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:651f:7cb3:0:45:9f72:9f01]) [172.58.185.143]:45762
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Mon, 06 Nov 2017 18:46:04 -0000

Humm. I don't think this is how Chris is envisioning it. We can talk more 
next week when he presents.

Lou


On November 6, 2017 12:31:18 PM Robert Wilton  wrote:

>
>
> On 06/11/2017 17:24, Lou Berger wrote:
>>
>> On 11/6/2017 12:17 PM, Juergen Schoenwaelder wrote:
>>> What is default content of a list? Where is this coming from?
>> Whatever the vendor chooses in their code, and perhaps what gets defined
>> in future model definitions...
> This is mixing up config and state:
>
> The device's default module tags wouldn't be in , only in
> , [ and perhaps .]
>
> Only the clients configured modification to the module tags ends up in
> .  This is merged with the system module tags, and then the
> resultant set end up in .
>
> Resetting the list to default is achieved by just deleting the list
> entry in .  No special RPC is needed.
>
> Thanks,
> Rob
>
>> Lou
>>
>>> /js
>>>
>>> On Mon, Nov 06, 2017 at 12:12:30PM -0500, Lou Berger wrote:
>>>> What's the standard way to reset a list to a default (based on
>>>> implementation)?
>>>>
>>>> On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:
>>>>> On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
>>>>>> The tags draft has an RPC to 'reset to default state'.  I could see
>>>>>> wanting the reset to be persistent or not depending on actual usage...
>>>>>>
>>>>> In general, I think we love the usage of standard operations like
>>>>> edit-config to manipulate configuration datastores and I think we
>>>>> dislike custom operations that manipulate configuration datastores.
>>>>>
>>>>> /js
>>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>
>



From nobody Mon Nov  6 11:07: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 56CB513FBBA for ; Mon,  6 Nov 2017 11:07:18 -0800 (PST)
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 yJBfQ5-PSRky for ; Mon,  6 Nov 2017 11:07:16 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0133.outbound.protection.outlook.com [104.47.37.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 6AB9C13FBB9 for ; Mon,  6 Nov 2017 11:07:15 -0800 (PST)
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=EPyzrKtIz6hSMhPiwOLq+r5G/m0IrOjiRbyL4XN8FIA=; b=JDapNu/Ks2GqUmtGZ2Vvu2V3nyItt/60RW9dxlSLo9e4A6SrCQgvkFhc4P359UXWm5LXjDTdbZcBTM7Ha8gTxgnMKc1yYLZoNnJWcRnH1X6DA24VjFOStDKmJZIkLEi8Is9qIV81DAm8P+yc/a6R/+dF5fb1S/WidgFyhktnbCE=
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.218.6; Mon, 6 Nov 2017 19:07: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.0218.005; Mon, 6 Nov 2017 19:07:13 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-08
Thread-Index: AQHTSnZblpFyoLN8ekG6ibtU7APGZ6MHfCmA
Date: Mon, 6 Nov 2017 19:07:13 +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: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:H9c4WbLB/p6cqgPlrruG//0NMNlTYO2sRvNNlw4ZJQgTOfB2KtAyHitZCcVUUZQPG/ED1qs5Lozblo/J4w2Wrs6CFm6RANZBAfLWA7WuK1N30AGabi04ERLycO1F9sBK/PktXrqRs7wte8P4VY8mjmsRCO0sMDPQPG0Z0FVmuGxW6ONA7b6v/qNtDLaYdSfKvGv5WQxFcUmLXoRls1LApubU+5ytFyGZev4YDzsqC2czx8nJawONg0G2URAjESE663nDsW1kupinnhcHfIsVmj+l6mZcMUV1C1W02D+8yg05gO0Gq/cmfAakRhVy464alfZmYQ1V3XHc8lq2Axi5v4ua2uDC0fXEYivrSTcQcis=; 5:VtJNziIhgdQS8uvUc3AyUM3ERefVCGunXgGc3wC+C4Rk8REe6ANPg6w8JbjBKkaQTCu/nWDLK6CF2LDYFhYtniTUh/Bm+psd+XesFMO6bXvkXCYy1/K443vbkCajJgXN0Be1Fc4efpp/rjoIeySBSupSZkjXNMhCwz9tnrbsjhA=; 24:koaBiGiMlw/HRAPNJN999S9hspgZAIIgu0XUXjrIBvA3XHkAZ3Iv2EE5oAzo9e1cK3rU/c1WJhU0oSNwqGmO6IrcdUL3q6fVkTTO7JsrEBQ=; 7:8rJr2Lx42jwsANFi/lNue4b2dKkPUPEGQdRdcn8+l7VPxI9y5zRYXOp/JVLeRHbVkKWIrQ+lZapM4CfunMZNy/OM0po+cpqNSNjzuZOw+3oW89iYqjAH1VrKjMK3IwQE5yGgzKNYAmXHb4CT6N7H+Lt9pwcTIusw7DaBftWUcdZpOEj3L2dibxB6Isgw20FSUKB/B13qGP2FsgV/aQSCfP75E+UUOhD5Mzz7aIbmlflL6uZDXI0oYiJNKzn0DZJY
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 115529f1-ed79-468f-20ff-08d5254996f6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603249); SRVR:BLUPR05MB276; 
x-ms-traffictypediagnostic: BLUPR05MB276:
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)(3002001)(3231021)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(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: 048396AFA0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(189002)(199003)(305945005)(230783001)(105586002)(2351001)(478600001)(102836003)(14454004)(3846002)(6116002)(101416001)(68736007)(189998001)(3280700002)(3660700001)(2906002)(81166006)(2900100001)(33656002)(8936002)(8676002)(25786009)(81156014)(83506002)(50986999)(54356999)(76176999)(7736002)(1730700003)(229853002)(106356001)(2501003)(6246003)(36756003)(58126008)(316002)(6436002)(77096006)(6916009)(6486002)(5640700003)(2950100002)(83716003)(82746002)(53936002)(6506006)(97736004)(99286004)(6512007)(66066001)(5660300001)(86362001); 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)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3F1DAB2A29D66343985D3D3A82945980@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 115529f1-ed79-468f-20ff-08d5254996f6
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 19:07:13.7564 (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-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: Mon, 06 Nov 2017 19:07:18 -0000

DQpUaGlzIGNsb3NlcyB0aGUgc2NoZW1hLW1vdW50IExhc3QgQ2FsbC4gIExvb2tpbmcgYXQgdGhl
IA0KcmVzcG9uc2VzLCB0aGVyZSBpcyBzdHJvbmcgc3VwcG9ydCBmb3IgcHVibGljYXRpb24gYWZ0
ZXINCmEgdmFyaWV0eSBvZiBMYXN0IENhbGwgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCwg
c29tZQ0KdGhyZWFkcyBvZiB3aGljaCBtYXkgc3RpbGwgYmUgb25nb2luZy4gIFRoZSBhdXRob3Jz
IHNob3VsZA0KcG9zdCBhbiB1cGRhdGUgYWRkcmVzc2VzIHRoZSBMYXN0IENhbGwgY29tbWVudHMg
Zm9sbG93ZWQNCmJ5IGEgcmVxdWVzdCBmb3IgY29tbWVudHMgdG8gcmV2aWV3IHRoZSB1cGRhdGUg
dG8gZW5zdXJlDQp0aGVpciBjb21tZW50cyB3ZXJlIGFkZHJlc3NlZC4gIE9uY2UgY29tcGxldGUs
IHRoZSBkb2N1bWVudA0Kd2lsbCB0aGVuIHByb2dyZXNzIHRvIHRoZSBzaGVwaGVyZCB3cml0ZS11
cCBwaGFzZS4NCg0KVGhhbmtzLA0KS2VudCAvLyBzaGVwaGVyZA0KDQotLQ0KDQpbY2hhbmdpbmcg
c3ViamVjdCBsaW5lXQ0KDQpBbGwsDQoNClBsZWFzZSB1c2UgdGhlIGp1c3QtcG9zdGVkIC0wOCB2
ZXJzaW9uIGluc3RlYWQuDQoNCkluIGFkZGl0aW9uIHRvIGNoYW5naW5nIHRoZSBzdWJqZWN0IGxp
bmUsIEkgYWxzbyBjaGFuZ2VkDQp0aGUgdGV4dCBiZWxvdy4gIFRoZSBlbmQgZGF0ZSByZW1haW5z
IHVuY2hhbmdlZC4NCg0KUmVnYXJkcywNCktlbnQgLy8gY28tY2hhaXINCg0KLS0NCg0KQWxsLA0K
DQpUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFm
dC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQtMDguDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3Qg
Y2FsbCBlbmRzIG9uIE5vdmVtYmVyIDMuDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRo
ZSBuZXRtb2QgbWFpbGluZyBsaXN0Lg0KDQpQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUg
cmV2aWV3ZWQgdGhpcyBkb2N1bWVudCANCmFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJs
aWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KVGhpcyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZl
biBmcm9tIGF1dGhvcnMuDQoNCkNvdWxkIHRoZSBhdXRob3JzLCBleHBsaWNpdGx5IENDLWVkIG9u
IHRoaXMgZW1haWwsIA0KcGxlYXNlIGFsc28gY29uZmlybSBvbmUgbW9yZSB0aW1lIHRoYXQgdGhl
eSBhcmUgDQp1bmF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0KDQpUaGFu
ayB5b3UsDQpOZXRtb2QgQ2hhaXJzDQoNCg0KDQoNCg0K


From nobody Mon Nov  6 11:16: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 5B1A313FAD9 for ; Mon,  6 Nov 2017 11:16:15 -0800 (PST)
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 pPsHuQpUseJM for ; Mon,  6 Nov 2017 11:16:13 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0135.outbound.protection.outlook.com [104.47.41.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C07813F698 for ; Mon,  6 Nov 2017 11:16:13 -0800 (PST)
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=k0ItlNYhL0x0wwHuV5Z/bg5A4zB4bnfaZvqwk2+QbTM=; b=YsWJZ6HmncocNPNnUTPtC8sc4qg3/6fFEKHcBKWQkhUezhPdnLpPlL3ro1KQvxFFP7880qXH8xl+kUBwsSU49jLkhnI68reI4FvTIOEF8Y215r0oX7hdFNdKOepzzwsdup6P1peu+Zrr5BZlP2ByNT9cKwoXIzmfBjIIQ7PIVFU=
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_P384) id 15.20.218.6; Mon, 6 Nov 2017 19:16:11 +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.0218.005; Mon, 6 Nov 2017 19:16:11 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
Thread-Index: AQHTVzO04R9mVwyDOkCxkCX5K2HeVg==
Date: Mon, 6 Nov 2017 19:16:11 +0000
Message-ID: <66FA526D-19AE-41C1-99FE-670F879796CA@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.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:7RYzO2jlcEBwPbwVNbkdFUlcNQZFvjSn1kADPH+1wLjNh5uywyJiLDJusTOnKCcmkxH7TScEBVNuRFi+GGXPllSkM4dKpRk84U7BW1hmlwfqw96m/ogvYt/b1RfrhxyPxmXHzE8FlYzBff93g8jJVhd/AJLttpqxlYkYyjPmtCjD4h6x2TW6jJTCZgZIBsPhlxMCyOdDFRJrstlQO2qNDOmka0E3fJMIBWMSV0ysxUI2srqsNWGoPz7f31HzpKlKYnpLkGXiekUlhYgWkhiz9j4sHadX+/mQrkpywDyz01RJFBnvVPcdvwu38vBa5w7GsGgBuql+S366zoI60mIVG66HMuYmDkt7gMf5OZi7Sxk=; 5:hhsbjzv3T+JvJrfd95zdgOFn5qP6J87rEGmBLXVmRwtHhH/9HeqvyTo9hiF9jQNnilfZ30XzVh4m2oOPDLSVjyj3i055owR8C8DCzXuZWM6AycSK1IGLiDc+hD0ajtIGVJWZadNo13jBnwAVBLjB/WNeoHQaXF0xJHbaKTurcwU=; 24:QfmtBgrFKxEOUl3WLPRn6rn2WLrKNCQ7T3llryDodbTMzo43GzNthyjjw5k0XFUmWzr+m0V3vDsSdOlEGVTJEik/+s81uek/5Mlz/j9xdDY=; 7:Vt+WbL0UoNlO0yh5WspixQYbxOf+4fElaWzfdaS7ZmTdnb+U0t+6o/WkXGoC/tQ5UPKo50dAPRgWBTlZVYm2tVkgMKYGYTDbVK04X6xCcV+TJuHTbBzGXfadL/VF0mgdbM8knS40qPMmIotOKj+4OmpsYdlyzm1rajtFxCMkU6AP7LNC3VTwUwcrZBBhba6+ZHmyGZISvVA3AapG7SAohdamRWFpipgRDMxu8owKejB1qiBy4SUhO4Hq64NjETPH
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 6daf475d-158f-4748-ebc1-08d5254ad74e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:BLUPR05MB274; 
x-ms-traffictypediagnostic: BLUPR05MB274:
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)(93006095)(93001095)(10201501046)(3231021)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(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: 048396AFA0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(189002)(199003)(2900100001)(6246003)(6916009)(2906002)(8676002)(58126008)(6116002)(2351001)(102836003)(305945005)(3846002)(316002)(33656002)(5660300001)(230783001)(83506002)(86362001)(575784001)(3280700002)(82746002)(66066001)(99286004)(8936002)(81166006)(81156014)(1730700003)(25786009)(53936002)(7736002)(106356001)(105586002)(50986999)(54356999)(3660700001)(68736007)(6512007)(6306002)(101416001)(478600001)(83716003)(5640700003)(966005)(229853002)(189998001)(14454004)(97736004)(36756003)(6506006)(6436002)(2501003)(6486002)(77096006); 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: 6daf475d-158f-4748-ebc1-08d5254ad74e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 19:16:11.2405 (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-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, 06 Nov 2017 19:16:15 -0000

DQpUaGlzIGNsb3NlcyB0aGUgTGFzdCBDYWxsIG9uIHRoaXMgZG9jdW1lbnQuICBUaGVyZSBpcw0K
Y2xlYXJseSBhIGxvdCBvZiBpbnRlcmVzdCBpbiB0aGUgcHVibGljYXRpb24gb2YgYW4gQUNMDQpt
b2RlbCwgYnV0IHRoZXJlIGFsc28gc2VlbXMgdG8gYmUgc2lnbmlmaWNhbnQgY29uY2Vybg0KZm9y
IGhvdyB0aGlzIG1vZGVsIGlzIHN0cnVjdHVyZWQuICBJdCBzZWVtcyB0aGF0IHdlIG5lZWQNCnRv
IHNwZW5kIHNvbWUgbW9yZSB0aW1lIHRvIGVuc3VyZSB0aGUgY3VycmVudCBzdHJ1Y3R1cmUNCmlz
IG9rYXkuICBCYXNlZCBvbiB0aGUgcmVzdWx0IG9mIHRoaXMgZGlzY3Vzc2lvbiwgd2UNCndpbGwg
dGhlbiBqdWRnZSBpZiB0aGlzIExhc3QgQ2FsbCB3YXMgc3VjY2Vzc2Z1bCBvZiBub3QuDQoNClRo
YW5rcywNCktlbnQgLy8gc2hlcGhlcmQNCg0KDQotLQ0KDQpBbGwsDQoNClRoaXMgc3RhcnRzIGEg
dHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCmRyYWZ0LWlldGYtbmV0bW9kLWFj
bC1tb2RlbC0xNC4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gTm92ZW1i
ZXIgMy4NClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxp
c3QuDQoNClBvc2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3Vt
ZW50DQphbmQgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29t
ZSENClRoaXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KDQpD
b3VsZCB0aGUgYXV0aG9ycywgZXhwbGljaXRseSBDQy1lZCBvbiB0aGlzIGVtYWlsLCBwbGVhc2UN
CmFsc28gY29uZmlybSBhdCB0aGlzIHRpbWUgdGhhdCB0aGV5IGFyZSB1bmF3YXJlIG9mIGFueSAN
CklQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQoNClRoYW5rIHlvdSwNCk5ldG1vZCBDaGFpcnMN
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0
bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJv
b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp
bmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E
VFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09
SENwOXBOTzFlQVNDN2ZCeHJzRDRoT1VqVFhIYktNdVdDNUMyaDcteW02OCZzPWs3dVJkaXVQMFo4
dnZEYTFoT0x4ZFFKUXQzTUJwSHY4Z2N1SGc5aHktTHcmZT0NCg0KDQo=


From nobody Mon Nov  6 23:53: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 B54DB13FB8A; Mon,  6 Nov 2017 23:53:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level: 
X-Spam-Status: No, score=-3.647 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, URG_BIZ=0.573, 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 BGkkojPS0v0N; Mon,  6 Nov 2017 23:53:42 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E036513FC10; Mon,  6 Nov 2017 23:53:40 -0800 (PST)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZI28920; Tue, 07 Nov 2017 07:53:39 +0000 (GMT)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 7 Nov 2017 07:53:38 +0000
Received: from DGGEML507-MBS.china.huawei.com ([169.254.1.221]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0361.001; Tue, 7 Nov 2017 15:53:26 +0800
From: Jiangyuanlong 
To: Alex Campbell , "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/8WWaL7pCg3gAzlH4A=
Date: Tue, 7 Nov 2017 07:53:26 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8@dggeml507-mbs.china.huawei.com>
References: <150906887826.22201.5033565145094897903.idtracker@ietfa.amsl.com>,  <3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97@dggeml507-mbx.china.huawei.com> <1509329710965.52658@Aviatnet.com>
In-Reply-To: <1509329710965.52658@Aviatnet.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-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5A016683.00A8, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4f5776818ae5929f90e8bb5a96927dab
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: Tue, 07 Nov 2017 07:53:46 -0000

Hi Alex,

Sorry for a late reply as I spent the last week for an urgent business trip=
.
Please see my comments in line with +AFs-YJ+AF0-

Thanks,
Yuanlong

-----Original Message-----
From: Alex Campbell +AFs-mailto:Alex.Campbell+AEA-Aviatnet.com+AF0-=20
Sent: Monday, October 30, 2017 10:15 AM
To: Jiangyuanlong+ADs- tictoc+AEA-ietf.org
Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
Subject: Re: WG Last Call resolutions incorporated in draft-ietf-tictoc-158=
8v2-yang-06

Hi,
I've reviewed this latest draft and have some more comments.

1. I find the introduction to be unnecessarily wordy+ADs- it feels like it =
was written with a view of not missing any information out, rather than try=
ing to keep it concise.
   For example, there is no need to elaborate on YANG data types here. It i=
s also not here to sell YANG.

+AFs-YJ+AF0- Yes, we are trying to give some introductory information for a=
n outsider who may not be familiar with PTP or YANG, and explain why a YANG=
 for PTP is needed. The juicy part of this document is its YANG module, and=
 people can skip all the other texts if they are familiar with PTP and YANG=
.
Besides, these texts have been contributed by multiple sources and undergon=
e several rounds of reviews, thus I will wait for a clear message from the =
TICTOC chairs to introduce any big changes at this last call stage.


OLD:

   As a synchronization protocol, IEEE 1588-2008 +AFs-IEEE1588+AF0- is wide=
ly
   supported in the carrier networks, industrial networks, automotive
   networks, and many other applications. It can provide high
   precision time synchronization as fine as nano-seconds. The
   protocol depends on a Precision Time Protocol (PTP) engine to
   decide its own state automatically, and a PTP transportation layer
   to carry the PTP timing and various quality messages. The
   configuration parameters and state data sets of IEEE 1588-2008 are
   numerous.

   According to the concepts described in +AFs-RFC3444+AF0-, IEEE 1588-2008
   itself provides an information model in its normative
   specifications for the data sets (in IEEE 1588-2008 clause 8). Some
   standardization organizations including the IETF have specified
   data models in MIBs (Management Information Bases) for IEEE 1588-
   2008 data sets (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0-). These MIB=
s are
   typically focused on retrieval of state data using the Simple
   Network Management Protocol (SNMP), furthermore, configuration of
   PTP data sets is not considered in +AFs-RFC8173+AF0-.

   Some service providers and applications require that the management
   of the IEEE 1588-2008 synchronization network be flexible and more
   Internet-based (typically overlaid on their transport networks).
   Software Defined Network (SDN) is another driving factor, which
   demands an improved configuration capability of synchronization
   networks.

   YANG +AFs-RFC6020+AF0- is a data modeling language used to model
   configuration and state data manipulated by network management
   protocols like the Network Configuration Protocol (NETCONF)
   +AFs-RFC6241+AF0-. A small set of built-in data types are defined in
   +AFs-RFC6020+AF0-, and a collection of common data types are further
   defined in +AFs-RFC6991+AF0-. Advantages of YANG include Internet based
   configuration capability, validation, rollback and so on. All of
   these characteristics make it attractive to become another
   candidate modeling language for IEEE 1588-2008.

NEW:

   IEEE 1588-2008 is a time protocol that provides high precision time
   synchronization as fine as nano-seconds.

   IEEE 1588-2008 itself provides an information model in its normative
   specifications for the data sets (IEEE 1588-2008 clause 8).
   Standard information models (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0=
-) have been
   previously defined as MIBs focused on the retrieval of state data using
   SNMP +AFs-RFC1157+AF0-.

   YANG +AFs-RFC6020+AF0- is a data modeling language used to model configu=
ration
   and state data manipulated by network management protocols like NETCONF
   +AFs-RFC6241+AF0-.

2. Can we refer to the system as simply PTP rather than IEEE 1588(-2008)?
+AFs-YJ+AF0- Advice from IEEE 1588 is, we need to use +ACI-1588-2008+ACI- a=
s much as possible to help clarify that the scope of this YANG is limited t=
o the published 1588 standard.


3. There is insufficient spacing here to separate the terms from their defi=
nitions:
OLD

   PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
   for PTP protocol decisions and for providing values for PTP message
   fields, see Section 8 of +AFs-IEEE1588+AF0-.

   PTP instance A PTP implementation in the device (i.e., an OC or BC)
   represented by a specific PTP dataset.

NEW

   PTP dataset
     Structured attributes of clocks (an OC, BC or TC) used
     for PTP protocol decisions and for providing values for PTP message
     fields, see Section 8 of +AFs-IEEE1588+AF0-.

   PTP instance
     A PTP implementation in the device (i.e., an OC or BC)
     represented by a specific PTP dataset.
+AFs-YJ+AF0- OK.

4. There's a singular/plural mismatch here:

   module. Query and configuration of device wide or port specific
   configuration information and clock data set is described for this
   version.
+AFs-YJ+AF0- Good, we will change 'is' to 'are'.

and here:

   Query and configuration of clock information include:


5. The choice of uint16 as instance-number limits implementations to 65536 =
distinct instances.
   While I have a hard time imagining a system with more than 65536 PTP ins=
tances, I would prefer to avoid imposing arbitrary limits.
   I would recommend changing instance-number to a string (and renaming it =
to instance-name or just name).
+AFs-YJ+AF0- The 1588-2008 supports multiple instances of PTP, but it is am=
biguous in its organization of those PTP instances, especially with regard =
to management.
 In the 1588 new revision, there is an explicit list of PTP instances, and =
that list is indexed using a number (not name). Thus to align with the new =
revision, we need to keep it instance-number.
 If 65536 limit is a concern, how about change it to uint32, any concerns?


6. I still recommend removing -ds from the YANG element names that still in=
clude it. It doesn't appear to add any value.
+AFs-YJ+AF0- Rodney's opinion: the value of using 'ds' is that the 1588 doc=
ument on which this YANG model is based uses +ACI-DefaultDS+ACI- as a term.=
 PTP experts even say +ACI-default dee ess+ACI- verbally when referring to =
this data. If we changed this to just +ACI-default+ACI-, PTP experts might =
assume that we are referring to something entirely new to YANG. Thus, to al=
ign with 1588-2008, the same set of terminologies are used.

7. What+ADs-s the relevance of injection attacks relevant to this YANG modu=
le?
+AFs-YJ+AF0- This is a general statement which is applicable to this YANG m=
odule and other YANG modules as well.
Thanks again,
Yuanlong

Alex


+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF=
8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-
From: netmod +ADw-netmod-bounces+AEA-ietf.org+AD4- on behalf of Jiangyuanlo=
ng +ADw-jiangyuanlong+AEA-huawei.com+AD4-
Sent: Friday, 27 October 2017 3:21 p.m.
To: tictoc+AEA-ietf.org
Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
Subject: +AFs-netmod+AF0- WG Last Call resolutions incorporated in draft-ie=
tf-tictoc-1588v2-yang-06

Dear all,

Based on all the comments we received during the WG Last Call process, we'v=
e updated the document to version 6.
We believe all the LC comments are resolved and the consensus is reflected =
in this new revision.
Many thanks to Martin, Tal, Opher, Alex, John and many others who had revie=
wed and commented on this draft.

Cheers,
Yuanlong on behalf of all coauthors

-----Original Message-----
From: internet-drafts+AEA-ietf.org +AFs-mailto:internet-drafts+AEA-ietf.org=
+AF0-
Sent: Friday, October 27, 2017 9:48 AM
To: Xian Liu+ADs- Rodney Cummings+ADs- rodney.cummings+AEA-ni.com+ADs- Jian=
gyuanlong+ADs- Xujinchun
Subject: New Version Notification for draft-ietf-tictoc-1588v2-yang-06.txt


A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
has been successfully submitted by Yuanlong Jiang and posted to the IETF re=
pository.

Name:           draft-ietf-tictoc-1588v2-yang
Revision:       06
Title:          YANG Data Model for IEEE 1588-2008
Document date:  2017-10-26
Group:          tictoc
Pages:          30
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588=
v2-yang-06.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-y=
ang/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-0=
6
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-158=
8v2-yang-06
Diff:           https://www.ietf.org/rfcdiff?url2+AD0-draft-ietf-tictoc-158=
8v2-yang-06

Abstract:
   This document defines a YANG data model for the configuration of
   IEEE 1588-2008 devices and clocks, and also retrieval of the
   configuration information, data set and running states of IEEE
   1588-2008 clocks.




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.

The IETF Secretariat

+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF=
8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
netmod mailing list
netmod+AEA-ietf.org
https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Nov  7 03:59: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 B70E013FE31 for ; Tue,  7 Nov 2017 03:59:19 -0800 (PST)
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 3UoFxkjlukn4 for ; Tue,  7 Nov 2017 03:59:18 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3582613FE36 for ; Tue,  7 Nov 2017 03:59:17 -0800 (PST)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZI68995; Tue, 07 Nov 2017 11:59:15 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 7 Nov 2017 11:59:14 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.198]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Tue, 7 Nov 2017 19:59:05 +0800
From: Zhuzhiguo 
To: "netmod@ietf.org" 
CC: "Liubin (Nickylba)" , "Zhengguangying (Walker)" , "Guopeipei (Peipei Guo)" , lianji , "Liquan (Liquan, NOS CSD)" 
Thread-Topic: [netmod]
Thread-Index: AdNXv7mQK9BH9+gqTUuoBnBBNmJ74A==
Date: Tue, 7 Nov 2017 11:59:05 +0000
Message-ID: <90D4AD4FAC4AD946A3593922318387CC9C2272D9@nkgeml513-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.175.187]
Content-Type: multipart/alternative; boundary="_000_90D4AD4FAC4AD946A3593922318387CC9C2272D9nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5A01A013.01D9, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.198, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e9878f225c8535b92cd5551542c1463f
Archived-At: 
Subject: [netmod] (no subject)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 07 Nov 2017 11:59:20 -0000

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

Hi,

I have one question about how to implement YANG module that import other-mo=
dule which is NOT be implemented?

For example, module-A import module-B, but any nodes that depend on B are n=
ot-supported

Module A {
   import module-B;
}

There are two way to mark module-B is not really in use:

Option-1: refer conformance-type in RFC 7895 (ietf-yang-library), mark modu=
le-A as "implement", module-B is "import"
This way seems work, but some teammates think it may not comply with RFC. A=
nd we also argue about what module-B should be presented in 


   module-A
   module-B            =3D=3D=3D>should any "impor=
t" module MUST be sent by server to client also?


Option-2: mark module-B as "implement" also, but mark all-nodes as deviated
This way seems work also, but it will cause NETCONF-client and NETCONF-serv=
er load module that have NO node that can be accessed

Thanks.


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











Hi,


 


I have one question about how t=
o implement YANG module that import other-module which is NOT be implemente=
d?


 


For example, module-A import mo=
dule-B, but any nodes that depend on B are not-supported<=
/p>

 


Module A {

   import module-B;


}


 


There are two way to mark modul=
e-B is not really in use:


 


Option-1: refer conformance-typ=
e in RFC 7895 (ietf-yang-library), mark module-A as “implement”=
, module-B is “import”


This way seems work, but some t=
eammates think it may not comply with RFC. And we also argue about what mod=
ule-B should be presented in <hello>


 


<capabilities>=



   <capability>=
module-A</capability>


   <capability>=
module-B</capability>        =
    =3D=3D=3D>should any “import” module MUST=
 be sent by server to client also?



<capabilities>=



 


Option-2: mark module-B as R=
20;implement” also, but mark all-nodes as deviated<=
/p>

This way seems work also, but i=
t will cause NETCONF-client and NETCONF-server load module that have NO nod=
e that can be accessed


 


Thanks.


 






--_000_90D4AD4FAC4AD946A3593922318387CC9C2272D9nkgeml513mbschi_--


From nobody Tue Nov  7 04:09: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 30A0913FE36 for ; Tue,  7 Nov 2017 04:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztPyf3AYi8jo for ; Tue,  7 Nov 2017 04:09:29 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3045313FC44 for ; Tue,  7 Nov 2017 04:09:27 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 6378B1AE02BB; Tue,  7 Nov 2017 13:09:25 +0100 (CET)
Date: Tue, 07 Nov 2017 13:08:01 +0100 (CET)
Message-Id: <20171107.130801.1219859225033022699.mbj@tail-f.com>
To: zhuzhiguo@huawei.com
Cc: netmod@ietf.org, liquan92@huawei.com
From: Martin Bjorklund 
In-Reply-To: <90D4AD4FAC4AD946A3593922318387CC9C2272D9@nkgeml513-mbs.china.huawei.com>
References: <90D4AD4FAC4AD946A3593922318387CC9C2272D9@nkgeml513-mbs.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] (no subject)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 07 Nov 2017 12:09:30 -0000

Zhuzhiguo  wrote:
> Hi,
> 
> I have one question about how to implement YANG module that import
> other-module which is NOT be implemented?
> 
> For example, module-A import module-B, but any nodes that depend on B
> are not-supported
> 
> Module A {
>    import module-B;
> }
> 
> There are two way to mark module-B is not really in use:
> 
> Option-1: refer conformance-type in RFC 7895 (ietf-yang-library), mark
> module-A as "implement", module-B is "import"

This is correct.  But if A augments some node in B, you have to
implement B as well.

> This way seems work, but some teammates think it may not comply with
> RFC.

Why wouldn't it?

> And we also argue about what module-B should be presented in
> 
> 
> 
>    module-A
>    module-B ===>should any "import" module MUST
>    be sent by server to client also?
> 

Assuming A and B are YANG 1.1 modules, they should NOT be listed in
 - yang-library is used instead.

> Option-2: mark module-B as "implement" also, but mark all-nodes as
> deviated
> This way seems work also, but it will cause NETCONF-client and
> NETCONF-server load module that have NO node that can be accessed

There's no reason to do this.



/martin


From nobody Tue Nov  7 04:54:35 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A5E13FB98 for ; Tue,  7 Nov 2017 04:54:33 -0800 (PST)
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 KeEP7zcoPesW for ; Tue,  7 Nov 2017 04:54:31 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDBD13FDCB for ; Tue,  7 Nov 2017 04:54:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3322; q=dns/txt; s=iport; t=1510059271; x=1511268871; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=/jkzNKOb2/PJpNwNtsBkBoPCwEnQG9xqtpORLQid02g=; b=AnZFmuMFNUM6GZz82yM92UG52P+JxJYwX+i/lUKtBFTazp2JsZkqeFai upL21ToOTDd+QWQ32HUOgG+EtQ4H8g+3/zp0ophs8smONay3RoUa/MgCG qOqsyUFOPISZCisDPBh0oXzulJmjIozuxjDR5xDTnkz02gvD20+vfOrJm k=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQC+rAFa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQYbieDfYsTkCqWSBCCAQcDGAuESU8ChTUWAQEBAQEBAQEBayi?= =?us-ascii?q?FHwEBAQMBASFLGwsOCioCAicwBgEKAgYCAQGKHxCpL4InixQBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBEA+DMIVtgwGEYgESAYM0gmIFknCPHoRCgiOBAY0WghVfhSSDYIc?= =?us-ascii?q?8lhyBOSYMJYEDbTQhCB0VSYJkCYReOTaJfII1AQEB?=
X-IronPort-AV: E=Sophos;i="5.44,358,1505779200"; d="asc'?scan'208";a="120137"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2017 12:54:11 +0000
Received: from [10.61.98.123] (dhcp-10-61-98-123.cisco.com [10.61.98.123]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA7CsASa015833; Tue, 7 Nov 2017 12:54:11 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <66FA526D-19AE-41C1-99FE-670F879796CA@juniper.net>
From: Eliot Lear 
Message-ID: <1cf2e28a-99e9-bbac-3cdb-2256d9040a69@cisco.com>
Date: Tue, 7 Nov 2017 18:24:10 +0530
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: <66FA526D-19AE-41C1-99FE-670F879796CA@juniper.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6ITBRa3ELka1IohAvcJh352GAA4DnMtEB"
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, 07 Nov 2017 12:54:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6ITBRa3ELka1IohAvcJh352GAA4DnMtEB
Content-Type: multipart/mixed; boundary="bXlfmJbTonv4pMrW0cK26aftE9EjS7Bnf";
 protected-headers="v1"
From: Eliot Lear 
To: Kent Watsen , "netmod@ietf.org" 
Message-ID: <1cf2e28a-99e9-bbac-3cdb-2256d9040a69@cisco.com>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
References: <66FA526D-19AE-41C1-99FE-670F879796CA@juniper.net>
In-Reply-To: <66FA526D-19AE-41C1-99FE-670F879796CA@juniper.net>

--bXlfmJbTonv4pMrW0cK26aftE9EjS7Bnf
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Kent,

Can you or the chairs please summarize what issues need to be
addressed?=C2=A0 We are in a place where we end up in endless last calls,=
 and
that is bad.

Eliot


On 11/7/17 12:46 AM, Kent Watsen wrote:
> This closes the Last Call on this document.  There is
> clearly a lot of interest in the publication of an ACL
> model, but there also seems to be significant concern
> for how this model is structured.  It seems that we need
> to spend some more time to ensure the current structure
> is okay.  Based on the result of this discussion, we
> will then judge if this Last Call was successful of not.
>
> Thanks,
> Kent // shepherd
>
>
> --
>
> 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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai=
lman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTX=
cWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DHCp9pNO1eASC7f=
BxrsD4hOUjTXHbKMuWC5C2h7-ym68&s=3Dk7uRdiuP0Z8vvDa1hOLxdQJQt3MBpHv8gcuHg9h=
y-Lw&e=3D
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



--bXlfmJbTonv4pMrW0cK26aftE9EjS7Bnf--

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

iQEcBAEBCAAGBQJaAazyAAoJEIe2a0bZ0noz9h0IAMJR+hL8R5CeUjlr1Rz5qGCh
atvjanpumNWtujNF1Vkf4XFLxYkF3mDCYDn4bWstzZAADUMEEi1kVLJrt9/pm4qU
YfazVZJ8Ws4tbQVgrGCsyroNHKzfVIB+Su9CmYvQUSGeF54i91E2A8vo/kqPYwyU
qn7aSdTKDUQWZ72550FkADIJNLwW/twO4XP/UsPdUwWKY6gYteKrzrYHbZqm0zrJ
1rEg9u1d/Kty9OoX88qTNhZsIzzDQRKBNAihJY+8U/+0ql5F6XDPrxwjlLT5k/d/
XSIN92p4+TdZXqMs5f/3pdyV36WxD605BNXEAfz+XEordlWM5YkJn4l7RJYyeRs=
=pUZF
-----END PGP SIGNATURE-----

--6ITBRa3ELka1IohAvcJh352GAA4DnMtEB--


From nobody Tue Nov  7 05:12: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 94EAE13FD6F for ; Tue,  7 Nov 2017 05:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCiILPu9fkZh for ; Tue,  7 Nov 2017 05:11:58 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50107.outbound.protection.outlook.com [40.107.5.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C96C13FE6B for ; Tue,  7 Nov 2017 05:11:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gsHQjgmq4Qbm2S39xyeMEWyLvFeNX79FPRPyNHvhH+A=; b=eY4GlALsl/oMF6lJTMnH5rkbI3UEexGYGnU/Cozsk3wRXH3IUm8392d/lYV/HAWA4Zckl2TA4WQznfteMhcE7VTtHE5lIypidGRr5He9JXNIU9rrkQDea5LcYdfPRNvZ/QdeW8lTxbM44oRl0AuFSgtwwdej9paGApA23QafkT8=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.169.153.236) by DB6PR0701MB2998.eurprd07.prod.outlook.com (2603:10a6:4:73::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Tue, 7 Nov 2017 13:11:54 +0000
Message-ID: <013a01d357c9$95af1a00$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Juergen Schoenwaelder" , "Martin Bjorklund" 
Cc: 
References:  <201711022116.vA2LGTB3044617@idle.juniper.net>  <20171106.141924.996087392255055625.mbj@tail-f.com> <20171106140152.5kcgjja6yy6n4h3j@elstar.local>
Date: Tue, 7 Nov 2017 13:06:35 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: HE1PR05CA0137.eurprd05.prod.outlook.com (2603:10a6:7:28::24) To DB6PR0701MB2998.eurprd07.prod.outlook.com (2603:10a6:4:73::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 61dd7c7d-81a0-4ded-477a-08d525e11e84
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603199); SRVR:DB6PR0701MB2998; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 3:IUWRdhG3rtzKyTN7s1t7bUuwPXJAaVQJ489a8OKXoug965mC7V6POHvYkTD5y2tlqX1q1xemUVx7/8JM8erN9F9olOcuFKDB9c/PcKRa/62VEVXQv8n3A+DXe1igNcnGM7l1V0m43+0a2Q82//lrByyiZ7vzDQ+yp+4KwtInkex8ARRl1tHJHy/Z8PtwgtBhKwQUfD5O7AgaHzHo3gJO0r29qVN7vyFH+zKrq0JQR6jYUjkA2r9wz6rnAGvHqQlL; 25:AxcYzAlEDZQAiYYfpnxn3c1x6dxIa36z71+BAiWGQFtSFACPybMsJSZNz+SzZwxIRkJXhYBZdi5icv0shYS+vujSv/zdBEwcmhJw7OH4SNkZNlHR16Wo8VRZutqVv0SW+/Djg1y+Y3ZNWOpaFD2VGga5B9iAPcmEOmssYYKKiLd8mLh1grz0iDo/eg6mLHDZHZm8MjD4BTiKPM/LtUcYcDSkhPptA/uUAbj6SH0rba3rZHTCvZmZJSDxareNchZp0LMsWETAezb91Aiz/pARHU/+eSKXm/r7/VCAqiiuRLf0XsgANQRknlNF2LtoK/YiMTn8DzTU5DMCmsbpOH7mkA==; 31:uEto8TsfPkmjXgNyTeypNi5mEmYgNh/xZosxWpoHleTQZJrNaMtVkDeAEGRq1NANf7nDH1o+uzZGvbhaPwdME1maIdMF8Ls9uEwm1R2SrLNW453r5rXxkiQ68g8cF7hch+n5eZLfJB2y9cTuZPtNhOa1bAh5jbFtSsKg+SkiMWkJyRKjo0D/cwWhGeTTAWiCh8TlzcrvBzCTGMRINz+FUlPGY+N6syaSTvS9eWC5G8s=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2998:
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)(3231021)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(61426038)(61427038)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2998; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2998; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 4:dPAnr21MMxeFMQnv6w8XoQ7BRQykemtmc8Naa2jWkqz4nJ4Ab0UKcxSKvJfxjH7utm5YUaT2C6S+gsiJSOLeEu78PtAbnwCVn+t5qD/9w5qLVqF0GGENfE0pgiawh07oKJh0WdtTK9Sj+ZvQ1n2LOYOMhSvgKo4Icr33oIxpwkf7V19Is9pIYMtIzRO8HkeskxS9/DBfvFn+Oza7AZFfYMT/4R2C5VvZTtIUsP0VfPK+Rq6T9iIJiGezULXHwUDasHholgMpIAVotSLen3Xyng==
X-Forefront-PRVS: 0484063412
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(13464003)(199003)(24454002)(189002)(6306002)(2906002)(110136005)(6246003)(9686003)(44716002)(101416001)(47776003)(229853002)(66066001)(4720700003)(7736002)(62236002)(6496005)(6486002)(93886005)(25786009)(4326008)(106356001)(316002)(305945005)(105586002)(53936002)(61296003)(1556002)(33646002)(8676002)(230700001)(966005)(86362001)(44736005)(81156014)(6666003)(189998001)(81166006)(50986999)(8936002)(68736007)(14496001)(16526018)(478600001)(84392002)(50466002)(81816999)(97736004)(116806002)(5660300001)(76176999)(81686999)(1456003)(50226002)(6116002)(23756003)(3846002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2998; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2998; 23:ejSNb9FTmu5Ljtr6A5YtAn8ocnJWLhpyqqlUK?= =?iso-8859-1?Q?DjIEIq0zcnpeMbpnMllHYdqAV+r70WLu1g4MqpAVLo5edIj4flDhyUx3Cd?= =?iso-8859-1?Q?0OKlNn+92Xd4yAn0Xr5kaNqG/Msp9Yr95tp9OzKa8hd9hA23A5Tlofodgk?= =?iso-8859-1?Q?dO+5v0ofu+soO1y58aPLNb9blKE54IIRpseoxuOoGkrg9pHLOquaQL8RfU?= =?iso-8859-1?Q?zMopw7jeVuJGFIkf2lDuiiKk2bHBxvxfs1LgkcnTIWifTOnR54/dMW8JMm?= =?iso-8859-1?Q?RjMc6/MpXDodRUfza3vQG/cjro+OOQTe6l50ZCmzxgBHnqvzusZheZ9+Q0?= =?iso-8859-1?Q?oDTmap539FMikuhDdWL3Ji9RwKmhQWfkcMrIpHDF8MpfWdFpnpZqKtxcmO?= =?iso-8859-1?Q?fG4PftI/QXpp24jpJSFYBhQI2x48VmyJQVQfpHvrzztrIqMKOJVWeCjpPg?= =?iso-8859-1?Q?eDeCNxjSVLsZxxNhithqGezszy8hnjj02ZdPxbpVgIJVLb7tjHzZ/Uim8y?= =?iso-8859-1?Q?83toSV8HzamyMObSl7ifYpWKIA/u15hPE5KWWd+uBhFEeBRWEtaF/B3eVi?= =?iso-8859-1?Q?tzy4P3ppFdomI3H+qgGJfUvdImEzUOLnhwh0/n0apEwPX99NnD1t++NyDy?= =?iso-8859-1?Q?ugJ1UwMj7wLHpZwSX0AT8FbDQbE1GsfPAA1Xkprr+a1h9LwFxxjW+iS67H?= =?iso-8859-1?Q?9UMgIXafEuy57EhN0m4ENsUjroQkx0DQZOHqVs1UwO/dwA2zxOFtBTSBJl?= =?iso-8859-1?Q?jKlH1gXLAzCvJTSWR0gi1woZhWyCx8NpTFQ7zKBtR3YxCzwj4VxGM2BdrC?= =?iso-8859-1?Q?80BckqmQDbD6+8yTIrWzZfLPZF3aeupmszjEPyh/ZR1a5Wpr+20anraG+6?= =?iso-8859-1?Q?1easeFIIYeiwMODm5yUauY/v8klsILV49zsBnHLvQR0ek2rrbaarijk5PH?= =?iso-8859-1?Q?2i7WIwpYIqNmu0uGuzARAXUuoY9L9m3Rmd1mz0LDHNie7S87SrcM7Ph6xk?= =?iso-8859-1?Q?5E2pWI5AApvnr4tbr57vVGV0R3MvQWMDszUYeRh3RUimjiCetG2jNNMWpR?= =?iso-8859-1?Q?X0uEn1LRpzzL1BvCrOoRvkmuCP0Xlpdg8L0HGxEHtvlZ+mHeywMCaXccYB?= =?iso-8859-1?Q?XJORByvmEmTWQ/pmFnIDVlqR/zivlClCO+i4GS3/Ih+0swUue5r/T3hIDH?= =?iso-8859-1?Q?a6chMrhSDoH87dIlx4fqgy9Sjv7dNqXbVrVThyq+MQdWjm0vga13H4jy+v?= =?iso-8859-1?Q?LDNfMGtE0wjJLm6JKC1BIUi8FhpMe0n68KDmB5hBXUzEFGud5s/vIH+L3I?= =?iso-8859-1?Q?p1Nly00mcBSYLOKRsx1WFdnqC+qw5oi2kFiaIItXHWvzXNysxRd57ekR23?= =?iso-8859-1?Q?S4cTR7mJTH9W9JtFq9zL7QkMWXzH+eMaSI0UOTC6GBpfpQRNsId0BsLV6L?= =?iso-8859-1?Q?wqzpU5jPbL+2RzYAtAgUh0K42oHX4qNcnTkY5O0HSbeieW9ViKZm5BxIFg?= =?iso-8859-1?Q?Vko2TqzIHCx9KL0ELPLTcI=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 6:MxMyNJtMEtuoBpjYoRxW0X1e91HN6nIVjieZs//2m249wK+4SQ1uE3UiwQ2qyh9wq3NcIPJkNwsLJ1rMKkANYw5+wRBMV6PzURsGJtMDyF4yIp1y/jlYWkcSECrQRuhMKYdhHuFl8KDd7Y77DQNZiNeeVvXEXg66doqx06bwr2s94ZXOqYPUrXZfUDwrmdW+lyPk5f1hPn0dcx3tW6xE61K+mytrZ6I8StQNdXc657zPNImYeLaiLh25PmV8sBugLYOj03iHXs9L9CfcDeKndI9xFAMgHD8Lco7uMo4kPd/Jt7+QAoZuCVEmS1tk3nQp0hYr25TaDE77MLchs51PPJ+j4A4k2gl18Qt8WQCjAro=; 5:RBzQhVjapckxlrR3UFN/lGHGnauOJCRsZZfzMaBrb3cgRrwmGsD9ybwTq7HNqP6dnvh7A7aIBeB7P/xKAVIFXEitwcM61kDu2lkV+JlenVsrVdg1R3Jt1ComWzkwuNfxkz8f9Iy8vChtZvmGWEo7iXjDv1Cv/b3sY1CTX5l0cl4=; 24:UgRIA0oEt/OcFgM3/zEVVDumbDY2sGoIxZuSxAiORqvnW/RgmvRl0Ld9SHXvl131O7DHf4YmOf4PP4f3/1NIXMyRtmfSEnVDeq/yTbZlSxg=; 7:N+8xELowUwE2M0kT5G0RAp50NtMkY9/aN6oySMYz+7j+Q9/P1ihFRiQy9Ub051vOdXpnzOYESjS+tV6YToWdreDZNmsc2w9LrCUsP4Fm8XkS4ecHqO4MpyHZSGrWwkCFK3zC9U5Ley5/sRK8MEb1SEmXMxnw4Wnj0a75VIYdz8HpbxWuaYUg6L/Rqbw/cIhBzEDH7ET7Xn5ZNBnlePZgoJQkfgS4tv8GFgL1R/WaB29sqBea/3LOIdv86Sbl95VU
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2017 13:11:54.6241 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 61dd7c7d-81a0-4ded-477a-08d525e11e84
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2998
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, 07 Nov 2017 13:12:01 -0000

---- Original Message -----
From: "Juergen Schoenwaelder" 
To: "Martin Bjorklund" 
Cc: 
Sent: Monday, November 06, 2017 2:01 PM
> On Mon, Nov 06, 2017 at 02:19:24PM +0100, Martin Bjorklund wrote:
> >
> > Trying to summarize this issue.
> >
> > The problem is which datastore is used to:
> >
> >     1a. evaluate action ancestor nodes
> >     1b. evaluate action input/output parameter leafref,
> >         instance-identifier, must, when
> >     2.  evaluate rpc input/output parameter leafref,
> >         instance-identifier, must, when
> >
> > (Note that the side effects of an action/rpc is not part of this
> > issue)
> >
> > I think it would be very weird if 1a and 1b were treated
differently,
> > so I just label them as 1 below.
> >
> > Possible solutions:
> >
> > A.  Always use  for 1 and 2.
> >
> >     (This is what the current nmda draft says).
> >
> > B.  Let the client specify the datastore for 1, and use

> >     for 2.
> >
> >     (Note that this is trivial in RESTCONF (since the datastore is
> >     part of the URL), but would require a new parameter for NETCONF
> >     (or a new ).
> >
> > C.  Let the client specify the datastore for 1 and 2.
> >
> >     This would require a new generic parameter for how RPCs are
> >     invoked in both NETCONF and RESTCONF.
> >
> > D.  Like B, but let the description of the "rpc" statement
optionally
> >     override this.
> >
> >
> > I prefer B and then D.
>
> I prefer A for now and I believe any of the other options may be
> considered in the future (when we can provide proper support of YANG
> and the protocols). I also believe that A covers a large number of
> real-world use cases.

I prefer A.  I think it is the simplest and the one least likely to have
consequences that were not anticipated.  You could see this discussion
as being one of unanticipated consequences so I want the least change to
solve the problem, while thinking about what B (or C or D, roughly the
order of increasing uncertainty) really involves.

Tom Petch

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


From nobody Tue Nov  7 05: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 719DA13FE69 for ; Tue,  7 Nov 2017 05:21:49 -0800 (PST)
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 VJFnGXPk78Ef for ; Tue,  7 Nov 2017 05:21:48 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0EB13FDA4 for ; Tue,  7 Nov 2017 05:21:47 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSD89611; Tue, 07 Nov 2017 13:21:45 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 7 Nov 2017 13:21:22 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.198]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Tue, 7 Nov 2017 21:21:12 +0800
From: Zhuzhiguo 
To: Martin Bjorklund 
CC: "netmod@ietf.org" , "Liquan (Liquan, NOS CSD)" 
Thread-Topic: [netmod] (no subject)
Thread-Index: AQHTV8FIOYLj0hXU2EOAvZHtRNyUf6MI5BgQ
Date: Tue, 7 Nov 2017 13:21:12 +0000
Message-ID: <90D4AD4FAC4AD946A3593922318387CC9C227381@nkgeml513-mbs.china.huawei.com>
References: <90D4AD4FAC4AD946A3593922318387CC9C2272D9@nkgeml513-mbs.china.huawei.com> <20171107.130801.1219859225033022699.mbj@tail-f.com>
In-Reply-To: <20171107.130801.1219859225033022699.mbj@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.175.187]
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.0A090203.5A01B369.0140, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.198, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c0130ebefbc7afb0959d0eb07ff1bc30
Archived-At: 
Subject: [netmod] =?gb2312?b?tPC4tDogIChubyBzdWJqZWN0KQ==?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 07 Nov 2017 13:21:49 -0000

SGkgTWFydGluLA0KVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KDQpJZiBtb2R1bGUtQSBhbmQg
bW9kdWwtQiBhcmUgMS4wIG1vZHVsZXMsIGFyZSB0aGV5IHNob3VsZCBiZSBwcmVzZW50ZWQgaW4g
PGhlbGxvPj8NCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTWFydGluIEJqb3JrbHVu
ZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tXSANCreiy83KsbzkOiAyMDE3xOoxMdTCN8jVIDIwOjA4
DQrK1bz+yMs6IFpodXpoaWd1byA8emh1emhpZ3VvQGh1YXdlaS5jb20+DQqzrcvNOiBuZXRtb2RA
aWV0Zi5vcmc7IExpcXVhbiAoTGlxdWFuLCBOT1MgQ1NEKSA8bGlxdWFuOTJAaHVhd2VpLmNvbT4N
Ctb3zOI6IFJlOiBbbmV0bW9kXSAobm8gc3ViamVjdCkNCg0KWmh1emhpZ3VvIDx6aHV6aGlndW9A
aHVhd2VpLmNvbT4gd3JvdGU6DQo+IEhpLA0KPiANCj4gSSBoYXZlIG9uZSBxdWVzdGlvbiBhYm91
dCBob3cgdG8gaW1wbGVtZW50IFlBTkcgbW9kdWxlIHRoYXQgaW1wb3J0IA0KPiBvdGhlci1tb2R1
bGUgd2hpY2ggaXMgTk9UIGJlIGltcGxlbWVudGVkPw0KPiANCj4gRm9yIGV4YW1wbGUsIG1vZHVs
ZS1BIGltcG9ydCBtb2R1bGUtQiwgYnV0IGFueSBub2RlcyB0aGF0IGRlcGVuZCBvbiBCIA0KPiBh
cmUgbm90LXN1cHBvcnRlZA0KPiANCj4gTW9kdWxlIEEgew0KPiAgICBpbXBvcnQgbW9kdWxlLUI7
DQo+IH0NCj4gDQo+IFRoZXJlIGFyZSB0d28gd2F5IHRvIG1hcmsgbW9kdWxlLUIgaXMgbm90IHJl
YWxseSBpbiB1c2U6DQo+IA0KPiBPcHRpb24tMTogcmVmZXIgY29uZm9ybWFuY2UtdHlwZSBpbiBS
RkMgNzg5NSAoaWV0Zi15YW5nLWxpYnJhcnkpLCBtYXJrIA0KPiBtb2R1bGUtQSBhcyAiaW1wbGVt
ZW50IiwgbW9kdWxlLUIgaXMgImltcG9ydCINCg0KVGhpcyBpcyBjb3JyZWN0LiAgQnV0IGlmIEEg
YXVnbWVudHMgc29tZSBub2RlIGluIEIsIHlvdSBoYXZlIHRvIGltcGxlbWVudCBCIGFzIHdlbGwu
DQotLS0tLS8vLy9hbGwgdGhlc2UgYXVnbWVudHMgYXJlIGRldmlhdGVkDQoNCj4gVGhpcyB3YXkg
c2VlbXMgd29yaywgYnV0IHNvbWUgdGVhbW1hdGVzIHRoaW5rIGl0IG1heSBub3QgY29tcGx5IHdp
dGggDQo+IFJGQy4NCg0KV2h5IHdvdWxkbid0IGl0Pw0KLS0tLS0tLy8vL2NsaWVudCBjYW4gZ2V0
IG1vZHVsZS1CLCBidXQgY2FuJ3QgZG8gYW55IG9wZXJhdGlvbiBvbiBtb2R1bGUtQg0KDQo+IEFu
ZCB3ZSBhbHNvIGFyZ3VlIGFib3V0IHdoYXQgbW9kdWxlLUIgc2hvdWxkIGJlIHByZXNlbnRlZCBp
biA8aGVsbG8+DQo+IA0KPiA8Y2FwYWJpbGl0aWVzPg0KPiAgICA8Y2FwYWJpbGl0eT5tb2R1bGUt
QTwvY2FwYWJpbGl0eT4NCj4gICAgPGNhcGFiaWxpdHk+bW9kdWxlLUI8L2NhcGFiaWxpdHk+ID09
PT5zaG91bGQgYW55ICJpbXBvcnQiIG1vZHVsZSBNVVNUDQo+ICAgIGJlIHNlbnQgYnkgc2VydmVy
IHRvIGNsaWVudCBhbHNvPw0KPiA8Y2FwYWJpbGl0aWVzPg0KDQpBc3N1bWluZyBBIGFuZCBCIGFy
ZSBZQU5HIDEuMSBtb2R1bGVzLCB0aGV5IHNob3VsZCBOT1QgYmUgbGlzdGVkIGluIDxoZWxsbz4g
LSB5YW5nLWxpYnJhcnkgaXMgdXNlZCBpbnN0ZWFkLg0KPiBPcHRpb24tMjogbWFyayBtb2R1bGUt
QiBhcyAiaW1wbGVtZW50IiBhbHNvLCBidXQgbWFyayBhbGwtbm9kZXMgYXMgDQo+IGRldmlhdGVk
IFRoaXMgd2F5IHNlZW1zIHdvcmsgYWxzbywgYnV0IGl0IHdpbGwgY2F1c2UgTkVUQ09ORi1jbGll
bnQgDQo+IGFuZCBORVRDT05GLXNlcnZlciBsb2FkIG1vZHVsZSB0aGF0IGhhdmUgTk8gbm9kZSB0
aGF0IGNhbiBiZSBhY2Nlc3NlZA0KDQpUaGVyZSdzIG5vIHJlYXNvbiB0byBkbyB0aGlzLg0KDQoN
Cg0KL21hcnRpbg0K


From nobody Tue Nov  7 05:25: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 D968E13FB74 for ; Tue,  7 Nov 2017 05:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imX17REYe1UC for ; Tue,  7 Nov 2017 05:25:00 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB5713FAF3 for ; Tue,  7 Nov 2017 05:25:00 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 3ABCA1AE02BB; Tue,  7 Nov 2017 14:24:59 +0100 (CET)
Date: Tue, 07 Nov 2017 14:23:35 +0100 (CET)
Message-Id: <20171107.142335.998654658313885657.mbj@tail-f.com>
To: zhuzhiguo@huawei.com
Cc: netmod@ietf.org, liquan92@huawei.com
From: Martin Bjorklund 
In-Reply-To: <90D4AD4FAC4AD946A3593922318387CC9C227381@nkgeml513-mbs.china.huawei.com>
References: <90D4AD4FAC4AD946A3593922318387CC9C2272D9@nkgeml513-mbs.china.huawei.com> <20171107.130801.1219859225033022699.mbj@tail-f.com> <90D4AD4FAC4AD946A3593922318387CC9C227381@nkgeml513-mbs.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=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] =?utf-8?b?562U5aSNOiAgKG5vIHN1YmplY3Qp?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 07 Nov 2017 13:25:02 -0000

Wmh1emhpZ3VvIDx6aHV6aGlndW9AaHVhd2VpLmNvbT4gd3JvdGU6DQo+IEhpIE1hcnRpbiwNCj4g
VGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KPiANCj4gSWYgbW9kdWxlLUEgYW5kIG1vZHVsLUIg
YXJlIDEuMCBtb2R1bGVzLCBhcmUgdGhleSBzaG91bGQgYmUgcHJlc2VudGVkDQo+IGluIDxoZWxs
bz4/DQoNClllcywgYnV0IG5vdGUgdGhhdCBpZiBCIGlzIHByZXNlbnQgaW4gPGhlbGxvPiwgYSBj
bGllbnQgd2lsbCB0aGluaw0KdGhhdCBhbGwgbm9kZXMgaW4gQiBhcmUgaW1wbGVtZW50ZWQuICBU
aGlzIGlzIHdoeSB5YW5nLWxpYnJhcnkgaGFzIHRoZQ0KJ2NvbmZvcm1hbmNlJyBsZWFmLg0KDQoN
Ci9tYXJ0aW4NCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogTWFydGlu
IEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tXSANCj4g5Y+R6YCB5pe26Ze0OiAyMDE3
5bm0MTHmnIg35pelIDIwOjA4DQo+IOaUtuS7tuS6ujogWmh1emhpZ3VvIDx6aHV6aGlndW9AaHVh
d2VpLmNvbT4NCj4g5oqE6YCBOiBuZXRtb2RAaWV0Zi5vcmc7IExpcXVhbiAoTGlxdWFuLCBOT1Mg
Q1NEKSA8bGlxdWFuOTJAaHVhd2VpLmNvbT4NCj4g5Li76aKYOiBSZTogW25ldG1vZF0gKG5vIHN1
YmplY3QpDQo+IA0KPiBaaHV6aGlndW8gPHpodXpoaWd1b0BodWF3ZWkuY29tPiB3cm90ZToNCj4g
PiBIaSwNCj4gPiANCj4gPiBJIGhhdmUgb25lIHF1ZXN0aW9uIGFib3V0IGhvdyB0byBpbXBsZW1l
bnQgWUFORyBtb2R1bGUgdGhhdCBpbXBvcnQgDQo+ID4gb3RoZXItbW9kdWxlIHdoaWNoIGlzIE5P
VCBiZSBpbXBsZW1lbnRlZD8NCj4gPiANCj4gPiBGb3IgZXhhbXBsZSwgbW9kdWxlLUEgaW1wb3J0
IG1vZHVsZS1CLCBidXQgYW55IG5vZGVzIHRoYXQgZGVwZW5kIG9uIEIgDQo+ID4gYXJlIG5vdC1z
dXBwb3J0ZWQNCj4gPiANCj4gPiBNb2R1bGUgQSB7DQo+ID4gICAgaW1wb3J0IG1vZHVsZS1COw0K
PiA+IH0NCj4gPiANCj4gPiBUaGVyZSBhcmUgdHdvIHdheSB0byBtYXJrIG1vZHVsZS1CIGlzIG5v
dCByZWFsbHkgaW4gdXNlOg0KPiA+IA0KPiA+IE9wdGlvbi0xOiByZWZlciBjb25mb3JtYW5jZS10
eXBlIGluIFJGQyA3ODk1IChpZXRmLXlhbmctbGlicmFyeSksIG1hcmsNCj4gPiBtb2R1bGUtQSBh
cyAiaW1wbGVtZW50IiwgbW9kdWxlLUIgaXMgImltcG9ydCINCj4gDQo+IFRoaXMgaXMgY29ycmVj
dC4gIEJ1dCBpZiBBIGF1Z21lbnRzIHNvbWUgbm9kZSBpbiBCLCB5b3UgaGF2ZSB0bw0KPiBpbXBs
ZW1lbnQgQiBhcyB3ZWxsLg0KPiAtLS0tLS8vLy9hbGwgdGhlc2UgYXVnbWVudHMgYXJlIGRldmlh
dGVkDQo+IA0KPiA+IFRoaXMgd2F5IHNlZW1zIHdvcmssIGJ1dCBzb21lIHRlYW1tYXRlcyB0aGlu
ayBpdCBtYXkgbm90IGNvbXBseSB3aXRoIA0KPiA+IFJGQy4NCj4gDQo+IFdoeSB3b3VsZG4ndCBp
dD8NCj4gLS0tLS0tLy8vL2NsaWVudCBjYW4gZ2V0IG1vZHVsZS1CLCBidXQgY2FuJ3QgZG8gYW55
IG9wZXJhdGlvbiBvbiBtb2R1bGUtQg0KPiANCj4gPiBBbmQgd2UgYWxzbyBhcmd1ZSBhYm91dCB3
aGF0IG1vZHVsZS1CIHNob3VsZCBiZSBwcmVzZW50ZWQgaW4gPGhlbGxvPg0KPiA+IA0KPiA+IDxj
YXBhYmlsaXRpZXM+DQo+ID4gICAgPGNhcGFiaWxpdHk+bW9kdWxlLUE8L2NhcGFiaWxpdHk+DQo+
ID4gICAgPGNhcGFiaWxpdHk+bW9kdWxlLUI8L2NhcGFiaWxpdHk+ID09PT5zaG91bGQgYW55ICJp
bXBvcnQiIG1vZHVsZSBNVVNUDQo+ID4gICAgYmUgc2VudCBieSBzZXJ2ZXIgdG8gY2xpZW50IGFs
c28/DQo+ID4gPGNhcGFiaWxpdGllcz4NCj4gDQo+IEFzc3VtaW5nIEEgYW5kIEIgYXJlIFlBTkcg
MS4xIG1vZHVsZXMsIHRoZXkgc2hvdWxkIE5PVCBiZSBsaXN0ZWQgaW4NCj4gPGhlbGxvPiAtIHlh
bmctbGlicmFyeSBpcyB1c2VkIGluc3RlYWQuDQo+ID4gT3B0aW9uLTI6IG1hcmsgbW9kdWxlLUIg
YXMgImltcGxlbWVudCIgYWxzbywgYnV0IG1hcmsgYWxsLW5vZGVzIGFzIA0KPiA+IGRldmlhdGVk
IFRoaXMgd2F5IHNlZW1zIHdvcmsgYWxzbywgYnV0IGl0IHdpbGwgY2F1c2UgTkVUQ09ORi1jbGll
bnQgDQo+ID4gYW5kIE5FVENPTkYtc2VydmVyIGxvYWQgbW9kdWxlIHRoYXQgaGF2ZSBOTyBub2Rl
IHRoYXQgY2FuIGJlIGFjY2Vzc2VkDQo+IA0KPiBUaGVyZSdzIG5vIHJlYXNvbiB0byBkbyB0aGlz
Lg0KPiANCj4gDQo+IA0KPiAvbWFydGluDQo=


From nobody Tue Nov  7 11: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 6003C132031 for ; Tue,  7 Nov 2017 11:13:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqMS-ZVfuiOF for ; Tue,  7 Nov 2017 11:13:53 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 55E1F13213D for ; Tue,  7 Nov 2017 11:13:52 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id F03AB1820F7A; Tue,  7 Nov 2017 20:13:18 +0100 (CET)
Received: from localhost (unknown [172.29.2.111]) by trail.lhotka.name (Postfix) with ESMTPSA id 8E4021820F78; Tue,  7 Nov 2017 20:13:17 +0100 (CET)
From: Ladislav Lhotka 
To: Vladimir Vassilev , "netmod\@ietf.org" 
In-Reply-To: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.com>
References: <4b313b03-73e2-1633-5936-4526ca67f820@transpacket.com>
Mail-Followup-To: Vladimir Vassilev , "netmod\@ietf.org" 
Date: Tue, 07 Nov 2017 20:14:55 +0100
Message-ID: <87y3nhaok0.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [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: Tue, 07 Nov 2017 19:13:56 -0000

Vladimir Vassilev  writes:

> 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";
>               }
>             }
>             ...
>

Following the logic of RFC 8022, address-family has to be a mandatory
parameter for all RIB entries in , so there seems to be no
other choice than make it "mandatory true" in the schema, as NMDA only
has one schema for all datastores.

Lada

>   - 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/
>
> _______________________________________________
> 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 Nov  7 13:52: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 DA993126C19 for ; Tue,  7 Nov 2017 13:51:57 -0800 (PST)
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 j0rwGnndAkkB for ; Tue,  7 Nov 2017 13:51:55 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0138.outbound.protection.outlook.com [104.47.40.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 EDABB128D0F for ; Tue,  7 Nov 2017 13:51:54 -0800 (PST)
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=xeef40Wy8Valmifyne0a4fYtwRRCNnFwgKRAuswYelI=; b=PGPUBQikzDbQscdVLtzhhv1ExCs4IvgIUX5KtFbCbgYap9/QWiu0GkD6E3F4UBR8xTBjrRpqI2EPhPHy+31V+FK4UuLpYnf6E1UghA+VJcIViw/ntqu34GrqPxk3NBTmAA1M56EiSx+WEXFMbUL/Mj7lmzyeHUfEi894e2VucJU=
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_P384) id 15.20.218.6; Tue, 7 Nov 2017 21:51:53 +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.0218.005; Tue, 7 Nov 2017 21:51:53 +0000
From: Kent Watsen 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] review of draft-ietf-netmod-schema-mount-08
Thread-Index: AQHTVB4smPzO0RNFj02ycL7IpPSiYqMCz3AAgAZZvwA=
Date: Tue, 7 Nov 2017 21:51:53 +0000
Message-ID: 
References:  <87po8z9x5p.fsf@nic.cz>
In-Reply-To: <87po8z9x5p.fsf@nic.cz>
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.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:NbZ0XOZ1+CfQNXlIGask0p1oAvOi3cFl7ppMyyZImUiq/cXI52bZXpi+hUcz2dN/rzGPpoqTtXeHQKDVcP18QvEvW4Y+5gNijj5ZcF9Qa9edOwZCT7K2ZCTIJY/wO5VGFmIQlmbDWtSUna0jQS82sPSrRHbb6z3HcIkdT8acyl9Q4vUamxr6aAy3v6mjOqAnGNGp8D6n3RZEPNdmrR00+OnopA0QGJySXyRzc3xdE0X8VYnHslfE6ISFWCeBJZQ1uqdABR/pO8Fwd717c6ORkllFfxFFRTA7FATIFoI6w8QORbSzpJZieSM2K6KHlttIEADxbaEiydPK85icePjnqsrv7dcewxiMQr5quOKRQpM=; 5:nc7Qw20BMR1DPf3MyQCHyaHK7LAM8UxtZSaYLeetwr/SbeC/vNBmhog9vBQscCperBeEIlCi767Ym+1ISa+WPm8BgePnLwem0z6ZV11b2n4pnAij8byXiI8zcP8DWX4dSeEQtTXtAHI6xz9F2ps0zE/ZFZhxcJHALKZ4VVkMwHY=; 24:nkHpV9o7yGxTlLcSdQhGkBz0OvJarCIjltV3jk3JhMqf2t04NEXZFtRv6pQ7y0Zxu/2Rz3aT5g/qWrbHZ9f4IwUc3v1/WII/kAOLPimgd+0=; 7:IrcJpCSvijL26KtPwWUFEn7Hx6/Bbg9CAsQJNxIrs+U+AY8w0zz4eXd3bXgiQzooWT+aYpTNtH9J8e4IKfEuOX8jFv4GGNUgyfzJCCJhkwEMHGobRzlCBZaY63AVZ9ZCJ1omFwHkxtZpShdT+jy5Bpp8zF4Ofvdy5vtIuKuEc3WSTkVrUJ/x8rgiUC1jQVxD80UllQmN16AX9KqAPMWVw2TyNg4jXQpyX/9bZXdYrn1VwyYh24eCrOfOHiyj6VXd
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ae94b9ce-8909-4524-583b-08d52629c217
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603249); SRVR:BLUPR05MB273; 
x-ms-traffictypediagnostic: BLUPR05MB273:
x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(17755550239193); 
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)(3231021)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(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: 0484063412
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(189002)(199003)(51914003)(52644002)(5660300001)(14454004)(8936002)(83716003)(77096006)(7736002)(316002)(478600001)(8676002)(3280700002)(66066001)(25786009)(6506006)(81166006)(2950100002)(33656002)(2906002)(305945005)(106356001)(81156014)(68736007)(6436002)(83506002)(3660700001)(6486002)(230783001)(36756003)(50986999)(76176999)(6246003)(54356999)(105586002)(97736004)(229853002)(2900100001)(189998001)(110136005)(82746002)(58126008)(2501003)(102836003)(86362001)(3846002)(101416001)(53936002)(6512007)(99286004)(6116002); 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)
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: <45EF9E494EC6DB4EA1F6DD710757D536@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: ae94b9ce-8909-4524-583b-08d52629c217
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 21:51:53.3836 (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] review of 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: Tue, 07 Nov 2017 21:51:58 -0000

DQoNCj4gSGkgS2VudCwNCj4NCj4gdGhhbmtzIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LCBzZWUg
bXkgcmVzcG9uc2VzIGlubGluZS4NCg0KSGkgTGFkYSwgcGxlYXNlIHNlZSBiZWxvdy4NCg0KDQo+
PiAxLiBGcm9tIFNlY3Rpb24gNDoNCj4+DQo+PiAgICBSb3V0aW5nIGNvbmZpZ3VyYXRpb24gaW5z
aWRlIGFuIE5JIG9mdGVuIG5lZWRzIHRvIHJlZmVyIHRvIGludGVyZmFjZXMgKGF0DQo+PiAgICBs
ZWFzdCB0aG9zZSB0aGF0IGFyZSBhc3NpZ25lZCB0byB0aGUgTkkpLCB3aGljaCBpcyBpbXBvc3Np
YmxlIHVubGVzcyBzdWNoDQo+PiAgICBhIHJlZmVyZW5jZSBjYW4gcG9pbnQgdG8gYSBub2RlIGlu
IHRoZSBwYXJlbnQgc2NoZW1hIChpbnRlcmZhY2UgbmFtZSkuDQo+Pg0KPj4gVGhpcyBzZWVtcyBv
dmVyc3RhdGVkLiAgUmF0aGVyIGl0IGlzIGEgcmVzdWx0IG9mIGFuIGVhcmxpZXIgZGVzaWduIGRl
Y2lzaW9uLg0KPj4gQW4gYWx0ZXJuYXRlIHNvbHV0aW9uIG1pZ2h0IGhhdmUgZXhwb3J0ZWQgdGhl
IGdsb2JhbCBpbnRlcmZhY2VzIGludG8gYSANCj4+IGNvbmZpZyBmYWxzZSBsaXN0IGluc2lkZSB0
aGUgbW91bnQgamFpbC4gICBXYXMgc3VjaCBhIHNvbHV0aW9uDQo+PiBkaXNjdXNzZWQ/DQo+DQo+
IERvIHlvdSBtZWFuIHNvbWV0aGluZyBsaWtlIGhhdmluZyAic3ltbGlua3MiIHRvIGludGVyZmFj
ZXMgaW5zaWRlIHRoZQ0KPiBtb3VudCBqYWlsPyBZZXMsIHRoaXMgd2FzIGRpc2N1c3NlZCBhbmQg
cmVqZWN0ZWQuIEFjY29yZGluZyB0byBNYXJ0aW4sDQo+IHRhaWwtZiBoYWQgbWFkZSBhIHZlcnkg
YmFkIGV4cGVyaWVuY2Ugd2l0aCB0aGlzIGFwcHJvYWNoLg0KDQpZZXMsIGEgbGl0dGxlIGJpdCBs
aWtlIGEgc3ltbGluayBpbnNpZGUgdGhlIG1vdW50IGphaWwuICBHb29kIHRvIGhlYXINCnRoYXQg
aXQgd2FzIGRpc2N1c3NlZC4gIEkgc3RpbGwgdGhpbmsgdGhlIGFib3ZlICJpbXBvc3NpYmxlIiB3
b3JkIGlzDQpvdmVyc3RhdGluZyB0aGluZ3MuICBQZXJoYXBzIHMvaW1wb3NzaWJsZSBzdWNoL3Bv
c3NpYmxlIHdoZW4vPw0KDQoNCj4+IDIuIEFsc28gZnJvbSBTZWN0aW9uIDQ6DQo+Pg0KPj4gICAg
Rm9yIGV2ZXJ5IHNjaGVtYSBtb3VudGVkIHVzaW5nIHRoZSAidXNlLXNjaGVtYSIgbWV0aG9kLCBp
dCBpcyBwb3NzaWJsZSANCj4+ICAgIHRvIHNwZWNpZnkgYSBsZWFmLWxpc3QgbmFtZWQgInBhcmVu
dC1yZWZlcmVuY2UiIHRoYXQgY29udGFpbnMgemVybyBvciBtb3JlDQo+PiAgICBYUGF0aCAxLjAg
ZXhwcmVzc2lvbnMuICBFYWNoIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVkIHdpdGggdGhlIG5vZGUg
aW4gdGhlDQo+PiAgICBwYXJlbnQgZGF0YSB0cmVlIHdoZXJlIHRoZSBtb3VudCBwb2ludCBpcyBk
ZWZpbmVkIGFzIHRoZSBjb250ZXh0IG5vZGUuICANCj4+DQo+PiBJZiB5b3UgY2FuIG5lc3RlZC1t
b3VudHMsIGNhbiB5b3UgYWxzbyBoYXZlIG5lc3RlZCBwYXJlbnQtcmVmZXJlbmNlcz8NCj4NCj4g
WWVzLCBidXQgeW91IGNhbiBvbmx5IHJlZmVyIHRvIHRoZSBsZXZlbCBkaXJlY3RseSBhYm92ZS4N
Cg0KT2theS4NCg0KDQoNCj4+IDMuIEFsc28gZnJvbSBTZWN0aW9uIDQgKHNhbWUgcGFyYWdyYXBo
KToNCj4+DQo+PiAgICBGb3IgdGhlIHB1cnBvc2VzIG9mDQo+PiAgICBldmFsdWF0aW5nIFhQYXRo
IGV4cHJlc3Npb25zIHdpdGhpbiB0aGUgbW91bnRlZCBkYXRhIHRyZWUsIHRoZSB1bmlvbg0KPj4g
ICAgb2YgYWxsIHN1Y2ggbm9kZXNldHMgaXMgYWRkZWQgdG8gdGhlIGFjY2Vzc2libGUgZGF0YSB0
cmVlLg0KPj4NCj4+IENvdWxkIHRoaXMgZXZlciByZXN1bHQgaW4gbmFtZSBjb2xsaXNpb24/DQo+
DQo+IFBvdGVudGlhbGx5IHllcywgYnV0IHNpYmxpbmcgbm9kZXMgd2l0aCB0aGUgc2FtZSBuYW1l
IGFyZSBub3QgYW4gaXNzdWUNCj4gZm9yIFhQYXRoIGV2YWx1YXRpb24uIA0KDQpJIGRvbid0IGtu
b3cgaWYgSSBhZ3JlZSB0aGF0IGl0IGNhbid0IGJlIGFuIGlzc3VlLiAgV2hhdCBpZiB0aGUgbW9k
dWxlDQpoYXMgYSB0b3AtbGV2ZWwgL3dpZGdldHMgY29udGFpbmVyLCBhbmQgdGhlcmUgaXMgYSBw
YXJlbnQtcmVmZXJlbmNlIHRvDQphIC93aWRnZXRzIGNvbnRhaW5lciwgYW5kIHRoZXJlIGlzIGFu
IFhwYXRoIHRvIC93aWRnZXRzIC0gc2VlbXMgbGlrZQ0KeW91IGNvdWxkIGhhdmUgYm90aCBmYWxz
ZS1wb3NpdGl2ZXMgYW5kIGZhbHNlLW5lZ2F0aXZlcy4uLg0KDQoNCg0KDQo+PiA0LiBSZWdhcmRp
bmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMsIHdoYXQgYWJvdXQNCj4+IC95YW5nbW50OnNjaGVt
YS1tb3VudHM/DQo+DQo+IFlvdSBhcmUgcmlnaHQsIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u
cyBzaG91bGQgYmUgc2ltaWxhcg0KPiB0byB0aG9zZSBpbiBSRkMgNzg5NS4gSXQgaXMgdGhlIHNh
bWUgdHlwZSBvZiByaXNrLg0KDQpvaw0KDQoNCj4+IEFsc28sIHNob3VsZCBob3cgTkFDTSBpbnRl
cmFjdHMgd2l0aCBtb3VudGVkIGluc3RhbmNlIGRhdGEgYmUNCj4+IHNwZWNpZmllZD8NCj4NCj4g
VGhpcyBpcyBhIGdvb2QgcXVlc3Rpb24gYmVjYXVzZSwgaW4gcHJpbmNpcGxlLCB0b3AtbGV2ZWwg
TkFDTSBydWxlcw0KPiBjYW4gYWRkcmVzcyBpbnN0YW5jZXMgb2YgbW91bnRlZCBzY2hlbWFzLiBP
biB0aGUgb3RoZXIgaGFuZCwNCj4gaWV0Zi1uZXRjb25mLWFjbSBjYW4gYWxzbyBiZSBhIHBhcnQg
b2YgdGhlIG1vdW50ZWQgc2NoZW1hIC0gYW5kIGlmDQo+IHNvLCBjYW4gaXRzIHJ1bGVzIGFsc28g
YWRkcmVzcyBpbnN0YW5jZXMgaW4gdGhlIHBhcmVudCBzY2hlbWEgdmlhDQo+IHRoZSBwYXJlbnQt
cmVmZXJlbmNlIG1lY2hhbmlzbT8NCj4NCj4gQnV0IEkgd291bGQgc2F5IGl0IGlzIHVwIHRvIHJm
YzY1MzZiaXMgdG8gZGVhbCB3aXRoIHRoZXNlIHF1ZXN0aW9ucy4NCg0KSSBkb24ndCBrbm93LCBi
dXQgaXQgc2VlbXMgdGhhdCB0aGlzIGRyYWZ0IGlzIGludHJvZHVjaW5nIHRoZSBjb25jZXB0Lg0K
Tm90IHRvIG1lbnRpb24sIHJmYzY1MzZiaXMgaXMgYWxyZWFkeSB3aXRoIHRoZSBJRVNHLiAgSW4g
ZWl0aGVyIGNhc2UsDQpsZXQncyB3b3JrIG91dCB3aGF0IGl0IG1lYW5zIGFuZCB0aGVuIGRlY2lk
ZSB3aGljaCBkcmFmdCBpdCBuZWVkcyB0bw0KZ28gaW50by4NCg0KDQoNCj4+IDUuIFRoaXMgZG9j
dW1lbnQgZG9lcyBub3Qgc2F5IGFueXRoaW5nIGFib3V0IGhvdyBpdCByZWxhdGVzIHRvIE5NREEu
DQo+PiBDbGVhcmx5IGFsbCB0aGlzIGlzIHRhcmdldGVkIHRvIHRoZSBjb252ZW50aW9uYWwgZGF0
YXN0b3JlcywgYnV0IGhvdw0KPj4gaXMgaXQgcmVmbGVjdGVkIGluIGUuZy4sIDxvcGVyYXRpb25h
bD4/ICBEb2VzIGFueXRoaW5nIG5lZWQgdG8gYmUgc2FpZA0KPj4gaGVyZT8NCj4NCj4gVGhlICJ1
c2Utc2NoZW1hIiBjYXNlIHNob3VsZG4ndCBwb3NlIGJpZyBwcm9ibGVtcyBiZWNhdXNlIGl0IGlz
DQo+IGVzc2VudGlhbGx5IGFuIGV4dGVybmFsbHkgc3BlY2lmaWVkIGF1Z21lbnQuIFRoZSAiaW5s
aW5lIiBjYXNlIGlzDQo+IHNvbWV3aGF0IGRpc3R1cmJpbmcgdGhvdWdoOiBjb3VsZCB0aGUgZW1i
ZWRkZWQgWUFORyBsaWJyYXJ5IGluc3RhbmNlcw0KPiBiZSBkaWZmZXJlbnQgaW4gZGlmZmVyZW50
IGRhdGFzdG9yZXM/DQoNCllBTkcgTGlicmFyeSBpcyBvbmx5IGF2YWlsYWJsZSBpbiA8b3BlcmF0
aW9uYWw+IChpdCdzIGFsbCBjb25maWcgZmFsc2UpLg0KSSB0aGluayB5b3UgbWVhbiB0aGUgZW1i
ZWRkZWQgWUFORyBMaWJyYXJ5IGluc3RhbmNlcyB1bmRlciB0aGUgbW91bnQgDQpwb2ludHMuICBZ
ZXMsIHlvdSBtYXkgaGF2ZSBhIHByb2JsZW0gaGVyZS4gIFN0aWxsLCB0aGlzIGlzbid0IG15IHF1
ZXN0aW9uLA0KaXMgbW9yZSBhYm91dCBzY2hlbWEtbW91bnRpbmcgcmVxdWlyZW1lbnRzIGFjcm9z
cyBkYXRhc3RvcmVzLiAgRS5nLiwgaWYNCmEgc2NoZW1hLW1vdW50IGV4aXN0cyBpbiA8cnVubmlu
Zz4sIG11c3QgaXQgZXhpc3RpbmcgaW4gPGludGVuZGVkPiBhbmQNCjxvcGVyYXRpb25hbD4gYXMg
d2VsbD8gIENvbnZlcnNlbHksIGlmIGEgc2NoZW1hLW1vdW50IGV4aXN0cyBpbg0KPG9wZXJhdGlv
bmFsPiwgbXVzdCBpdCBleGlzdCBpbiA8cnVubmluZz4/ICBJIHRoaW5rIHRoaXMgZHJhZnQgc2hv
dWxkDQpjbGFyaWZ5IHN1Y2ggdGhpbmdzLg0KDQoNCg0KPj4gV2hhdCBpZiB0aGUgbW91bnRlZCBz
Y2hlbWEgaGFzIGRldmlhdGlvbnMgaW4gPG9wZXJhdGlvbmFsPi4NCj4NCj4gSSBkb24ndCB1bmRl
cnN0YW5kIHdoeSB0aGlzIGNvdWxkIGJlIGFuIGlzc3VlLg0KDQpJJ20gbm90IHNheWluZyBpdCdz
IGEgcHJvYmxlbSB5ZXQuICBJJ20ganVzdCBzdGF0aW5nIHRoYXQgc3VjaCB0aGluZ3MNCmNhbiBv
Y2N1ciBhbmQgaXQncyB1bmNsZWFyIHRoYXQsIGlmIHRoZXkgZG8sIGNvdWxkIGl0IGNhdXNlIHBy
b2JsZW1zLg0KRm9yIGluc3RhbmNlLCBhIG1vdW50ZWQgc2NoZW1hIG1heSBiZSBsb29raW5nIGZv
ciBhIHBhcmVudCByZWZlcmVuY2UNCnRoYXQgZG9lc24ndCBleGlzdCBiZWNhdXNlIG9mIGEgZGV2
aWF0aW9uLg0KDQoNCg0KDQo+PiBOaXRzIChsaW5lLWJyZWFrIHNlcGFyYXRlZCk6DQo+Pg0KPj4g
SXMgIm90aGVyIG9wdGlvbmFsIGNob2ljZXMiIGJlaW5nIHZhZ3VlIG9uIHB1cnBvc2U/ICBTaG91
bGQgaXQganVzdA0KPj4gY2FsbCBvdXQgZmVhdHVyZXMgYW5kIGRldmlhdGlvbnM/DQo+DQo+WWVz
LCBpdCBzaG91bGQuDQo+DQo+Pg0KPj4gInRoZSBZQU5HIGxpYnJhcnkgZGF0YSIgc2VlbXMgb2Rk
LiAgTWF5YmUgInRoZSBpbnN0YW5jZSBvZiB0aGUgWUFORw0KPj4gTGlicmFyeSBtb2R1bGUiPw0K
Pg0KPiBJdCBpcyB0aGUgc2FtZSBidXQgSSBwcmVmZXIgdGhlIGZvcm1lci4gTm90ZSB0aGF0IHRo
ZSB0ZXJtICJpbnN0YW5jZSINCj4gaXMgbm90IGRlZmluZWQgaW4gUkZDIDc5NTAuDQoNCm9rYXkN
Cg0KDQo+PiAtIGRvY3VtZW50LCBhbmQgY291bGQgYmUgcG9zc2libHkgZGVhbHQgd2l0aCBpbiBh
IGZ1dHVyZSByZXZpc2lvbiBvZiB0aGUgWUFORyBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlDQo+PiAr
IGRvY3VtZW50LCBhcyBpdCBuZWVkcyB0byBiZSBkZWFsdCB3aXRoIGFzIGFuIHVwZGF0ZSB0byB0
aGUgWUFORyBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlDQo+DQo+IEkgYW0gbm90IHN1cmUgdGhhdCBp
dCAqbmVlZHMqIHRvIGJlIGRvbmUsIGJlY2F1c2UgaXQgY291bGQgaGF2ZQ0KPiBmYXItcmVhY2hp
bmcgY29uc2VxdWVuY2VzLg0KDQpIZXJlIEknbSB1c2luZyAibmVlZHMiIG5vdCB0byBtZWFuIHRo
YXQgaXQgImhhcyB0byBiZSBkb25lIiBidXQgbW9yZSB0aGF0LA0KaWYgaXQgaXMgZG9uZSwgaXQg
d291bGQgaGF2ZSB0byBiZSBkb25lIGluIGFuIHVwZGF0ZSB0byB0aGUgWUFORyBkYXRhIA0KbW9k
ZWxpbmcgbGFuZ3VhZ2UuICBUaGUgY3VycmVudCBzZW50ZW5jZSBzZWVtcyB0b28gb3Blbi1lbmRl
ZC4uLg0KDQoNCj4+IC0gU2NoZW1hIG1vdW50IGFwcGxpZXMgdG8gdGhlIGRhdGEgbW9kZWwNCj4+
ICsgU2NoZW1hIG1vdW50IHJlZ2FyZHMgdGhlIGRhdGEgbW9kZWwNCj4NCj4gT0sNCj4NCj4+DQo+
PiAtIFRoaXMgZG9jdW1lbnQgYWxsb3dzIG1vdW50aW5nIG9mIGNvbXBsZXRlIGRhdGEgbW9kZWxz
IG9ubHkuDQo+PiArIFRoaXMgZG9jdW1lbnQgYWxsb3dzIG1vdW50aW5nIG9mIGNvbXBsZXRlIG1v
ZHVsZXMgb25seS4NCj4NCj4gQ29ycmVjdA0KPg0KPg0KPj4gLSBtYXkgZXh0ZW5kIHRoaXMgbW9k
ZWwgYnkgZGVmaW5pbmcNCj4+ICsgbWF5IGV4dGVuZCB0aGlzIHNvbHV0aW9uIGJ5IGRlZmluaW5n
DQo+DQo+IE9yIHBlcmhhcHMgImFwcHJvYWNoIj8gSSB3b3VsZCBsZWF2ZSAic29sdXRpb24iIHRv
IG1hcmtldGluZyBmb2xrcy4NCg0KImFwcHJvYWNoIiBpcyBmaW5lLg0KDQoNCj4+IEluIFMzLCBy
ZXBsYWNlICJZQU5HIDEuMSIgd2l0aCAiWUFORyAxLjEgYW5kIGl0cyBjb250aW51YW5jZXMiPw0K
Pg0KPiBOb3Qgc3VyZS4gRm9yIGV4YW1wbGUsIG5leHQgdmVyc2lvbiBvZiBZQU5HIGNhbi9zaG91
bGQgdHVybiAibW91bnQtcG9pbnQiDQo+IGludG8gYSBidWlsdC1pbiBzdGF0ZW1lbnQuDQoNClNv
IHRoZW4sIHdoZW4gd2UgZGVmaW5lIHlhbmctbmV4dCwgd2UnZCBiZSBmb3JjZWQgdG8gZWl0aGVy
IGluY29ycG9yYXRlDQpzY2hlbWEtbW91bnQgb3Igc2ltdWx0YW5lb3VzbHkgcHVibGlzaCBhbiB1
cGRhdGUgdG8gdGhpcyBSRkMgdG8gYWxsb3cNCml0IHRvIHdvcmsgd2l0aCB0aGUgbmV3IHZlcnNp
b24gb2YgWUFORz8gIEV2ZW4gaWYgWUFORy1uZXh0IGRlZmluZWQgYQ0KYnVpbHQtaW4gZXF1aWx2
YWxlbnQsIHdvdWxkIHdlIG5vdCB3YW50IHRoaXMgbWVjaGFuaXNtIHRvIGNvbnRpbnVlIHRvDQpi
ZSBzdXBwb3J0ZWQsIGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eT8NCg0KDQo+PiAtIEEgImNv
bnRhaW5lciIgb3IgImxpc3QiIG5vZGUNCj4+ICsgQSAnY29udGFpbmVyJyBvciAnbGlzdCcgbm9k
ZQ0KPg0KPiBBY3R1YWxseSwgZm9sbG93aW5nIFJGQyA3OTUwIGNvbnZlbnRpb25zLCBubyBxdW90
ZXMgc2hvdWxkIGJlIHVzZWQgaGVyZS4NCj4NCg0KSSdtIGNvbmZ1c2VkIGFib3V0IHRoZXNlIGNv
bnZlbnRpb25zIC0gYXJlIHRoZXkgd3JpdHRlbiBkb3duIHNvbWV3aGVyZS4NCkluIE1hcnRpbidz
IHJldmlldyBvZiB6ZXJvdG91Y2ggZHJhZnQsIGhlIGRpbmdlZCBtZSBvbiBteSBtaXMtdXNlIG9m
DQpzaW5nbGUtcXVvdGVzLCBmb3IgdGhlIHNlY29uZCB0aW1lLiAgTG9va2luZyBhdCBSRkMgNzk1
MCwgSSBkb24ndCBzZWUNCnRoZSBjb252ZW50aW9uIGxpc3RlZCBhbnl3aGVyZSwgb3IgYXJlIHlv
dSBzYXlpbmcgdGhhdCB0aGUgY29udmVudGlvbg0KaXMgdGhyb3VnaG91dCB0aGUgUkZDIGFuZCBm
b2xrcyBhcmUgZXhwZWN0ZWQgdG8gaW1wbGljaXRseSB1bmRlcnN0YW5kDQp3aGF0IGl0IGlzPw0K
DQoNCg0KPj4gLSBvZiAiY29udGFpbmVyIiBhbmQgImxpc3QiIHN0YXRlbWVudHMuDQo+PiArIG9m
IHRoZSAiY29udGFpbmVyIiBhbmQgImxpc3QiIHN0YXRlbWVudHMuDQo+DQo+IE9LDQo+DQo+Pg0K
Pj4gLSBNb3VudGVkIHNjaGVtYXMgZm9yIGFsbCBtb3VudCBwb2ludHMNCj4+ICsgVGhlIHNjaGVt
YSBmb3IgYWxsIG1vdW50IHBvaW50cw0KPg0KPiBPSw0KPg0KPg0KPj4gLSBpbiB0aGUgInlhbmdt
bnQ6c2NoZW1hLW1vdW50cyIgY29udGFpbmVyLg0KPj4gKyBpbiB0aGUgdG9wLWxldmVsICJ5YW5n
bW50OnNjaGVtYS1tb3VudHMiIGNvbnRhaW5lciBkZWZpbmVkIGluIHRoZQ0KPj4gImlldGYteWFu
Zy1zY2hlbWEtbW91bnQiIG1vZHVsZSBkZWZpbmVkIGluIFtTZWN0aW9uIDhdLg0KPg0KPiBTZWN0
aW9uIDIuMiBkZWZpbmVzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgInlhbmdtbnQiIHBy
ZWZpeCBhbmQNCj4gdGhhdCBtb2R1bGUuDQoNClllcywgYnV0IHRoaXMgaXMgdGhlIGZpcnN0IHRp
bWUgaW4gdGhlIFJGQyB0aGF0IC9zY2hlbWEtbW91bnRzIGlzDQptZW50aW9uZWQuICBUaGUgcHJl
Zml4IGlzIHRoZXJlLCBidXQgd2h5IG5vdCBndWlkZSB0aGUgdXNlciBhIGxpdHRsZQ0KbW9yZT8N
Cg0KDQo+PiAgVGhlICJyZWZlcnMgdGhyb3VnaCBpdHMga2V5IiBwYXJ0IGlzIG5vdCBjbGVhciAt
IGFyZSB5b3UgdGFsa2luZw0KPj4gIGFib3V0IHRoZSBtb3VudC1wb2ludCdzIGFyZ3VtZW50L2xh
YmVsPw0KPg0KPiBZZXMuIFdvdWxkIGl0IGJlIG1vcmUgY2xlYXIgdG8gc2F5IHRoaXM/DQo+DQo+
ICAgRXZlcnkgZW50cnkgb2YgdGhpcyBsaXN0IHJlZmVycyB0aHJvdWdoIGl0cyBrZXkgdG8gYSBt
b3VudCBwb2ludA0KPiAgIGxhYmVsIGFuZCBzcGVjaWZpZXMgdGhlIHNjaGVtYSBmb3IgYWxsIG1v
dW50IHBvaW50cyB3aXRoIHRoYXQgbGFiZWwuDQoNClllcyENCg0KDQo+PiBJIGRvbid0IHVuZGVy
c3RhbmQgImFib3ZlIHRob3NlIHRoYXQgYXJlIGRlZmluZWQgaW4gdGhlIHBhcmVudA0KPj4gc2No
ZW1hLiIgIC0gbW9zdGx5IHRoZSB3b3JkICJhYm92ZSIgaXMgdGhyb3dpbmcgbWXigKYNCj4NCj4g
WWVzLCAiYXBhcnQgZnJvbSIgaXMgYmV0dGVyLg0KDQphZ3JlZWQuDQoNCg0KPj4gLSBJZiBtdWx0
aXBsZSBtb3VudCBwb2ludHMgd2l0aCB0aGUgc2FtZSBuYW1lDQo+PiArIElmIG11bHRpcGxlIG1v
dW50IHBvaW50cyB3aXRoIHRoZSBzYW1lIGxhYmVsICAgICh3YXNuJ3QgaXQgY2FsbGVkIGENCj4+
ICJsYWJlbCIgYmVmb3JlPykNCj4NCj5SaWdodA0KPg0KPg0KPj4gUmVnYXJkaW5nICJOb3RlLCB0
aGF0IGluIHRoaXMgY2FzZSBhIG1vdW50IHBvaW50IiwgYmV5b25kIHRoZSBtaXNzaW5nDQo+PiBj
b21tYSwgYW4gZXhhbXBsZSB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuICBJIGRvbid0IGtub3cgaWYg
SSB1bmRlcnN0YW5kDQo+PiBpdCByaWdodC4NCj4NCj4gWW91IGRvbid0LCBiZWNhdXNlIHRoYXQg
c2VudGVuY2UgaXMgY29tcGxldGVseSB3cm9uZyAtIGl0IGlzIHlldCBhbm90aGVyDQo+IGV4YW1w
bGUgb2YgbWl4aW5nIHVwIHRoZSBzY2hlbWEgYW5kIGluc3RhbmNlLiBUaGUgaWRlYSBpcyB0aGF0
IGlmIChmb3INCj4gc29tZSBzdHJhbmdlIHJlYXNvbikgdGhlIG1vdW50ZWQgc2NoZW1hIGluY2x1
ZGVzIHRoZSBpZXRmLXlhbmctbGlicmFyeQ0KPiBtb2R1bGUsIHRoZW4gYWxsICppbnN0YW5jZXMq
IG9mIHRoaXMgKG1vdW50ZWQpIFlBTkcgbGlicmFyeSBtdXN0IGJlDQo+IGlkZW50aWNhbCBhbmQg
aGF2ZSB0aGUgc2FtZSBjb250ZW50IGFzIHRoZSAidXNlLXNjaGVtYSIgZGF0YS4NCg0Kb2theQ0K
DQoNCj4gVGhpcyBpcyBhbm90aGVyIHJlYXNvbiB3aHkgSSB3b3VsZCBwcmVmZXIgdG8gaGF2ZSBv
bmx5IG9uZSBZQU5HIGxpYnJhcnkNCj4gYXQgdGhlIHRvcCAtIGl0IGlzIG5vdCByZWd1bGFyIHN0
YXRlIGRhdGEuDQoNCkRvZXMgdGhpcyBuZWVkIHRvIGJlIGRpc2N1c3NlZCBzb21lIG1vcmU/DQoN
Cg0KPiBJbiB0aGUgWUFORyBpdHNlbGYsICJTdGF0ZSBkYXRhIG5vZGVzIiBkaWRuJ3QgcGFyc2Ug
d2VsbCwgIlByb3RvY29sDQo+IGFjY2Vzc2libGUgbm9kZXMiIGluc3RlYWQ/DQo+DQo+IERvIHlv
dSBtZWFuIHRoZSBjb21tZW50PyBUaGUgc2FtZSBvciBzaW1pbGFyIGNvbW1lbnQgaXMgaW4gbWFu
eSBleGlzdGluZw0KPiBtb2R1bGVzIC0gZm9yIGV4YW1wbGUsIGlldGYteWFuZy1saWJyYXJ5IGhh
cyAiT3BlcmF0aW9uYWwgc3RhdGUgZGF0YQ0KPiBub2RlcyIuIEl0IGlzIHRydWUgdGhvdWdoIHRo
YXQgaXQgZG9lc24ndCBtYWtlIG11Y2ggc2Vuc2UgaGVyZSBhcyBsb25nDQo+IGFzIHRoZXJlIGFy
ZSBubyBjb25maWd1cmF0aW9uIGRhdGEuDQoNCg0KWWVzLCB0aGUgY29tbWVudC4gIFdlbGwsIHRo
aXMgaXMgYSBuaXQsIHNvIHRha2UgaXQgZm9yIHdoYXQgaXQncyB3b3J0aCwNCmJ1dCBpdCBkaWQg
c2VlbSBhIGJpdCB1bnVzdWFsIHdoZW4gSSByZWFkIGl0Lg0KDQoNCj4+IFJlZ2FyZGluZyB0aGUg
Zmlyc3QgcGFyYWdyYXBoIGluIEFwcGVuZGl4IEEsIEkgdG9vayBtZSBzb21lIHRpbWUgDQo+PiB0
byByZWFsaXplIHRoYXQgdGhlIHJ0Z3dnLWRldmljZS1tb2RlbCBpbmNsdWRlZCANCj4+IGlldGYt
bmV0d29yay1pbnN0YW5jZSBhbmQgdGhhdCB0aG9zZSBtb2R1bGVzIGRlZmluZSBtb3VudC1wb2lu
dHMgDQo+PiBhbmQgd2hlcmUuICAgUGxlYXNlIG1ha2UgdGhpcyBlYXNpZXIgZm9yIGZpcnN0LXRp
bWUgcmVhZGVycy4NCj4NCj4gT0ssIHdlIHNob3VsZCB0cnkuDQoNCnRoYW5rcy4NCg0KDQoNCj4+
IEluIEExLCBpcyBpZXRmLW5ldHdvcmstaW5zdGFuY2UgbWlzc2luZz8gIC0gbWlnaHQgd2FudCB0
byBkb3VibGUtY2hlY2sNCj4+IGFsbA0KPg0KPiBObywgYmVjYXVzZSBBMSBkZXNjcmliZXMgb25s
eSB0aGUgdG9wIChkZXZpY2UpIGxldmVsLA0KPiBpZXRmLW5ldHdvcmstaW5zdGFuY2UgaXMgYSBw
YXJ0IG9mIHRoZSBMTkUgc2NoZW1hIGluIEEuMi4NCg0Kb2theQ0KDQoNCj4+IEluIGFsbCB0aGUg
ZXhhbXBsZXMsIGJ1dCBiZWdpbm5pbmcgd2l0aCBBMiwgaXQgbWlnaHQgaGVscCB0byBzaG93IHRo
ZQ0KPj4gUkVTVFNDT05GIHByb3RvY29sIG9wZXJhdGlvbiB0aGF0IGlsbHVzdHJhdGVzIHRoZSBy
ZXN1bHQsIHNvIHRoYXQgaXQncw0KPj4gY2xlYXIgd2hlcmUgaW4gdGhlIGRhdGEgbW9kZWwgdGhl
IHBhcnRpY3VsYXIgaW5zdGFuY2UgaXMgbG9jYXRlZC4NCj4+IEFueXRoaW5nIHRoYXQgY2FuIGJl
IGRvbmUgdG8gcHJvdmlkZSBtb3JlIGNvbnRleHQgd291bGQgYmUgaGVscGZ1bC4NCj4NCj4gSXQg
c2VlbXMgdG8gbWFrZSBzZW5zZSBpbiBBLjMgLSB0byBkZW1vbnN0cmF0ZSBhbiBVUkkgb2YgYSBy
ZXNvdXJjZQ0KPiBpbnNpZGUgYW4gTkkuDQoNCmdyZWF0LCBhbnl0aGluZyB0aGF0IGhlbHBzLg0K
DQoNCj4+IEZvciB0aGUgMm5kIGhhbGYgb2YgQTIsIHdoYXQgaGFwcGVucyBpZiB0aGVyZSBpcyBh
biAibG5lLTIiLCB3aWxsIGl0DQo+PiBhbHNvIGdldCAiZXRoMCI/DQo+DQo+IEkgdGhpbmsgImll
dGYtbG9naWNhbC1uZXR3b3JrLWVsZW1lbnQ6YmluZC1sbmUtbmFtZSIgbGVhZiBzaG91bGQgY29u
dGFpbg0KPiB0aGUgbmFtZSBvZiBhIExORSB0byB0byB3aGljaCB0aGUgaW50ZXJmYWNlICJldGgw
IiBpcyBhc3NpZ25lZCwgc28gaXQNCj4gbG9va3MgbGlrZSBhIG1pc3Rha2UuDQoNCmdsYWQgdG8g
aGVhciB0aGVyZSBtaWdodCBiZSBhIG1pc3Rha2UNCg0KDQo+PiAtIHdoaWNoIHNob3VsZCBpbmNs
dWRlIGF0IGxlYXN0DQo+PiArIHdoaWNoIHNob3VsZCBpbmNsdWRlIGF0IGxlYXN0IGFuIGluc3Rh
bmNlIG9mDQo+PiBpZXRmLXlhbmctbGlicmFyeTptb2R1bGVzLXN0YXRlIGFuZCBpZXRmLWludGVy
ZmFjZXM6aW50ZXJmYWNlcy1zdGF0ZSwNCj4+IGFzIGZvbGxvd3M6DQo+DQo+IEJ1dCB0aGUgaW1w
b3J0YW50IHBvaW50IGlzIHRoYXQgb25seSBpbnRlcmZhY2VzIGFzc2lnbmVkIHRvIHRoZSBMTkUN
Cj4gbmVlZCB0byBiZSBpbmNsdWRlZCwgc28gaXQgaXMgbm90IGp1c3QgImFuIGluc3RhbmNlIG9m
DQo+IGlldGYtaW50ZXJmYWNlczppbnRlcmZhY2VzLXN0YXRlIi4gV2h5IGRvIHlvdSB0aGluayB0
aGUgZXhpc3RpbmcgdGV4dA0KPiBpc24ndCBPSz8NCg0KV2hhdCB5b3UgaGF2ZSBpc24ndCB3cm9u
ZywgcGVyIHNlLCBJJ20ganVzdCB0cnlpbmcgdG8gbWFrZSB0aGUgdGV4dA0KbW9yZSByZWFkYWJs
ZS4gIEhvdyBhYm91dDoNCg0KICB3aGljaCBzaG91bGQgaW5jbHVkZSBhdCBsZWFzdCBhbiBpbnN0
YW5jZSBvZg0KICBpZXRmLXlhbmctbGlicmFyeTptb2R1bGVzLXN0YXRlIGFuZCBpZXRmLWludGVy
ZmFjZXM6aW50ZXJmYWNlcy1zdGF0ZSwNCiAgY29udGFpbmluZyBvbmx5IHRoZSBlbnRyaWVzIHJl
bGV2YW50IHRvIHRoZSBtb3VudC1wb2ludCwgYXMgZm9sbG93czoNCg0KLSBvciB1c2UgeW91ciBv
d24gd29yZHM/DQoNCg0KDQo+IExhZGENCg0KS2VudA0KDQoNCg0KDQo=


From nobody Tue Nov  7 23:47: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 D2AC1131519 for ; Tue,  7 Nov 2017 23:47:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 D_4E26aSWUdE for ; Tue,  7 Nov 2017 23:47:25 -0800 (PST)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id D427D129C26 for ; Tue,  7 Nov 2017 23:47:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id DBBC926184B; Wed,  8 Nov 2017 08:47:25 +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 JpGqbW5JUkmW; Wed,  8 Nov 2017 08:47:23 +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 6B17B261846; Wed,  8 Nov 2017 08:47:23 +0100 (CET)
Date: Wed, 8 Nov 2017 08:47:21 +0100
From: Kristian Larsson 
To: Sonal Agarwal 
Cc: Mahesh Jethanandani , netmod@ietf.org
Message-ID: <20171108074721.GK12688@spritelink.se>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>  <20171102.132634.1363976895007772742.mbj@tail-f.com> <51CEDFCB-88CF-4066-8428-55BF7521D1F0@gmail.com> <20171103085244.GG12688@spritelink.se> <0587EC2C-6B31-409D-B2A4-649EECEEB45A@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
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: Wed, 08 Nov 2017 07:47:27 -0000

On Sat, Nov 04, 2017 at 10:38:45AM -0700, Sonal Agarwal wrote:
> Kristian,
> 
> In response to one of your previous comments:
> 
> "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."
> 
> The key for an ACL needs to remain as the name and type. They
> both uniquely define the presence of the ACL in config.

You can't argue for a design choice by saying "this is how it
is". If we change the key to be acl-name only then it is the name
that "uniquely define the presence of the ACL in config".

What do you perceive as the benefit of having acl-type in the
key? Why can't it be an attribute? We can still check, from the
attachment point, what the acl-type is.

   kll

-- 
Kristian Larsson                                        KLL-RIPE
+46 72 5479985                                kll@spritelink.net


From nobody Wed Nov  8 00:32: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 384F8129B1E; Wed,  8 Nov 2017 00:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N68X3tfBVIst; Wed,  8 Nov 2017 00:32:14 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A260A13177E; Wed,  8 Nov 2017 00:32:13 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZJ80185; Wed, 08 Nov 2017 08:32:10 +0000 (GMT)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 08:32:08 +0000
Received: from DGGEML504-MBS.china.huawei.com ([169.254.11.20]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 16:32:02 +0800
From: wangzitao 
To: Kent Watsen , "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" 
Thread-Topic: draft agenda posted
Thread-Index: AdNYa/3iPyFHj1coT76VduMv5FXb3A==
Date: Wed, 8 Nov 2017 08:32:03 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.78.152]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5A02C10B.018A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.11.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 0d3f1ca97c94e118d6fef7a5292a8d18
Archived-At: 
Subject: Re: [netmod] draft agenda posted
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 08 Nov 2017 08:32:16 -0000

UHJlc2VudGVycywgDQoNClBsZWFzZSBwcmVwYXJlIHRvIHNlbmQgeW91ciBzbGlkZXMgdG8gbWUg
YW5kIENDIHRoZSBjaGFpcnMuIFRoZSBkZWFkbGluZSBmb3Igc2xpZGVzIGlzIDI0IGhvdXJzIHBy
aW9yIHRvIHRoZSBzZXNzaW9uIChub3RlIHdlIGFyZSBvbiBXRURORVNEQVksIE5vdmVtYmVyIDE1
LCAyMDE3KSAsIHRob3VnaCBlYXJsaWVyIGlzIGJldHRlci4gDQoNCkFuZCBwbGVhc2UgdGFrZSBh
IGxvb2sgYXQgdGhlIGxpc3QgZm9yIHByZXNlbnRpbmcgYXQgTmV0bW9kOiANCmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDAvbWF0ZXJpYWxzL2FnZW5kYS0xMDAtbmV0bW9k
Lw0KDQpCZXN0IHJlZ2FyZHMhDQotTWljaGFlbA0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7I
yzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gS2VudCBXYXRz
ZW4NCreiy83KsbzkOiAyMDE3xOoxMdTCMsjVIDY6MTkNCsrVvP7IyzogbmV0bW9kQGlldGYub3Jn
DQrW98ziOiBbbmV0bW9kXSBkcmFmdCBhZ2VuZGEgcG9zdGVkDQoNCg0KVGhlIGRyYWZ0IGFnZW5k
YSBmb3IgdGhlIE5FVE1PRCBzZXNzaW9ucyBoYXMgYmVlbiBwb3N0ZWQ6DQoNCiAgaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMC9tYXRlcmlhbHMvYWdlbmRhLTEwMC1uZXRt
b2QvDQoNClRoZXJlIGFyZSBubyBzZXNzaW9ucyBsaXN0ZWQgZm9yIHRoZSB0aHJlZSBOTURBLXVw
ZGF0ZSBtb2RlbCBkcmFmdHMgKHJmYzcyMjNiaXMsIHJmYzcyNzdiaXMsIHJmYzgwMjJiaXMpLiAg
VGhleSB3aWxsIGJlIGNvdmVyZWQgdG9nZXRoZXIgYnkgdGhlIGNoYWlycyBpbiB0aGUgYmVnaW5u
aW5nIG9mIFNlc3Npb24gMS4NCg0KQ2hlZXJzLA0KS2VudCAoYW5kIExvdSkNCg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGlu
ZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0bW9kDQo=


From nobody Wed Nov  8 00:51: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 9B85713180F for ; Wed,  8 Nov 2017 00:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4DsRsbLn-wo3 for ; Wed,  8 Nov 2017 00:51:44 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 581231317FA for ; Wed,  8 Nov 2017 00:51:44 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id B2F491AE0144; Wed,  8 Nov 2017 09:51:42 +0100 (CET)
Date: Wed, 08 Nov 2017 09:50:19 +0100 (CET)
Message-Id: <20171108.095019.1523851923210652414.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <87po8z9x5p.fsf@nic.cz> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] review of 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: Wed, 08 Nov 2017 08:51:47 -0000

Kent Watsen  wrote:
> 
> 
> > Hi Kent,
> >
> > thanks for the thorough review, see my responses inline.
> 
> Hi Lada, please see below.
> 
> 
> >> 1. From Section 4:
> >>
> >>    Routing configuration inside an NI often needs to refer to interfaces (at
> >>    least those that are assigned to the NI), which is impossible unless such
> >>    a reference can point to a node in the parent schema (interface name).
> >>
> >> This seems overstated.  Rather it is a result of an earlier design decision.
> >> An alternate solution might have exported the global interfaces into a 
> >> config false list inside the mount jail.   Was such a solution
> >> discussed?

Actually, this wouldn't work, since config true leafrefs/xpaths can't
refer to this "config false" list inside the mount jail.

Besides, even a symlink approach would in fact allow for "such a
reference to point to a node in the parent schema tree".

> > Do you mean something like having "symlinks" to interfaces inside the
> > mount jail? Yes, this was discussed and rejected. According to Martin,
> > tail-f had made a very bad experience with this approach.
> 
> Yes, a little bit like a symlink inside the mount jail.  Good to hear
> that it was discussed.  I still think the above "impossible" word is
> overstating things.  Perhaps s/impossible such/possible when/?

See above; I think the current text is correct.

The point is that *somehow* the solution needs to allow for these
kinds of references; symlinks could be one solution, the
"parent-reference" that we use is another solution.

> >> 3. Also from Section 4 (same paragraph):
> >>
> >>    For the purposes of
> >>    evaluating XPath expressions within the mounted data tree, the union
> >>    of all such nodesets is added to the accessible data tree.
> >>
> >> Could this ever result in name collision?
> >
> > Potentially yes, but sibling nodes with the same name are not an issue
> > for XPath evaluation. 
> 
> I don't know if I agree that it can't be an issue.  What if the module
> has a top-level /widgets container, and there is a parent-reference to
> a /widgets container

The nodes exist in a namespace.  So if you have /widgets in two
different modules there is no issue.  However, if you mount a module A
and at the same time provide A's toplevel nodes as parent references
then you might have a problem - or not!  The document defines what
happens in this case (the result is the union).   Also note that
constructing the set of mounted modules and corresponding
parent-references is up to the implementation.

> >> Also, should how NACM interacts with mounted instance data be
> >> specified?
> >
> > This is a good question because, in principle, top-level NACM rules
> > can address instances of mounted schemas. On the other hand,
> > ietf-netconf-acm can also be a part of the mounted schema - and if
> > so, can its rules also address instances in the parent schema via
> > the parent-reference mechanism?
> >
> > But I would say it is up to rfc6536bis to deal with these questions.
> 
> I don't know, but it seems that this draft is introducing the concept.
> Not to mention, rfc6536bis is already with the IESG.  In either case,
> let's work out what it means and then decide which draft it needs to
> go into.

I think NACM in the parent node should cover access to the mounted
data.  For example, it should be possible to have a rule for:

 /network-instances/network-instance[name='foo']/vrf-root/rt:routing


> >> 5. This document does not say anything about how it relates to NMDA.
> >> Clearly all this is targeted to the conventional datastores

No, or maybe I don't understand what you mean.  Schema mount allows
for mounting config false nodes, or even doing a "read-only" mount.
Such a mount is clearly not available in the conventional datastores.

>, but how
> >> is it reflected in e.g., ?  Does anything need to be said
> >> here?
> >
> > The "use-schema" case shouldn't pose big problems because it is
> > essentially an externally specified augment. The "inline" case is
> > somewhat disturbing though: could the embedded YANG library instances
> > be different in different datastores?
> 
> YANG Library is only available in  (it's all config false).
> I think you mean the embedded YANG Library instances under the mount 
> points.  Yes, you may have a problem here.  Still, this isn't my question,
> is more about schema-mounting requirements across datastores.  E.g., if
> a schema-mount exists in , must it existing in  and
>  as well?  Conversely, if a schema-mount exists in
> , must it exist in ?  I think this draft should
> clarify such things.

I agree that this needs to be clarified.  This issue partly comes from
the fact that schema mount uses the groupings in the old yang
library.  I think we need to use the new groupings from rfc7895bis.


> >> What if the mounted schema has deviations in .
> >
> > I don't understand why this could be an issue.
> 
> I'm not saying it's a problem yet.  I'm just stating that such things
> can occur and it's unclear that, if they do, could it cause problems.
> For instance, a mounted schema may be looking for a parent reference
> that doesn't exist because of a deviation.
> 
> 
> 
> 
> >> Nits (line-break separated):
> >>
> >> Is "other optional choices" being vague on purpose?  Should it just
> >> call out features and deviations?
> >
> >Yes, it should.
> >
> >>
> >> "the YANG library data" seems odd.  Maybe "the instance of the YANG
> >> Library module"?
> >
> > It is the same but I prefer the former. Note that the term "instance"
> > is not defined in RFC 7950.
> 
> okay
> 
> 
> >> - document, and could be possibly dealt with in a future revision of the YANG data modeling language
> >> + document, as it needs to be dealt with as an update to the YANG data modeling language
> >
> > I am not sure that it *needs* to be done, because it could have
> > far-reaching consequences.
> 
> Here I'm using "needs" not to mean that it "has to be done" but more that,
> if it is done, it would have to be done in an update to the YANG data 
> modeling language.  The current sentence seems too open-ended...
> 
> 
> >> - Schema mount applies to the data model
> >> + Schema mount regards the data model
> >
> > OK
> >
> >>
> >> - This document allows mounting of complete data models only.
> >> + This document allows mounting of complete modules only.
> >
> > Correct
> >
> >
> >> - may extend this model by defining
> >> + may extend this solution by defining
> >
> > Or perhaps "approach"? I would leave "solution" to marketing folks.
> 
> "approach" is fine.
> 
> 
> >> In S3, replace "YANG 1.1" with "YANG 1.1 and its continuances"?
> >
> > Not sure. For example, next version of YANG can/should turn "mount-point"
> > into a built-in statement.
> 
> So then, when we define yang-next, we'd be forced to either incorporate
> schema-mount or simultaneously publish an update to this RFC to allow
> it to work with the new version of YANG?  Even if YANG-next defined a
> built-in equilvalent, would we not want this mechanism to continue to
> be supported, for backwards compatibility?
> 
> 
> >> - A "container" or "list" node
> >> + A 'container' or 'list' node
> >
> > Actually, following RFC 7950 conventions, no quotes should be used here.
> >
> 
> I'm confused about these conventions - are they written down somewhere.
> In Martin's review of zerotouch draft, he dinged me on my mis-use of
> single-quotes, for the second time.  Looking at RFC 7950, I don't see
> the convention listed anywhere, or are you saying that the convention
> is throughout the RFC and folks are expected to implicitly understand
> what it is?

I think you just should be consistent; if you attach some semantic
meaning to single quotes vs double quotes the document needs to
explain that meaning.  If it is just for quotation, be consistent.  I
think the RFC editor prefers double quotes (but I can't find a
reference to this).

As for the term container; this is a term for an interior node,
defined in 7950, so it is used w/o quotes.   Compare with references
to the "container" statement.




/martin


From nobody Wed Nov  8 02:16: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 0F458131987 for ; Wed,  8 Nov 2017 02:16:27 -0800 (PST)
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 3Yc9y6U6vIE3 for ; Wed,  8 Nov 2017 02:16:24 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB49131884 for ; Wed,  8 Nov 2017 02:16:23 -0800 (PST)
Received: from birdie7 (unknown [IPv6:2001:1488:fffe:6:6cd8:55ff:fec2:ecec]) by mail.nic.cz (Postfix) with ESMTPSA id 3A48763BE5; Wed,  8 Nov 2017 11:16:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510136181; bh=rvF+6PB8tv/Rhon08NpSMRHswjTAB9/RWHBKknpB+po=; h=From:To:Date; b=oc0RJER6mcxeXU7g83c3hkODaH/fhJiHCj5/bnQjkAJdpztB8yGJf9fdH3ZxRFWjW PHmblNUqm11YWI2ETrPBAcxl7bOtx64b+t803ayeWhWzi4HPcSnZxm7tJqa7fsanhk q539B65EzWOm1lCj46O3N63kDawNvzR53tfLXPLg=
Message-ID: <1510136247.17913.33.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund , kwatsen@juniper.net
Cc: netmod@ietf.org
Date: Wed, 08 Nov 2017 11:17:27 +0100
In-Reply-To: <20171108.095019.1523851923210652414.mbj@tail-f.com>
References:  <87po8z9x5p.fsf@nic.cz>  <20171108.095019.1523851923210652414.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] review of 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: Wed, 08 Nov 2017 10:16:27 -0000

On Wed, 2017-11-08 at 09:50 +0100, Martin Bjorklund wrote:
> Kent Watsen  wrote:
> > 
> > 
> > > Hi Kent,
> > >
> > > thanks for the thorough review, see my responses inline.
> > 
> > Hi Lada, please see below.
> > 
> > 
> > >> 1. From Section 4:
> > >>
> > >>    Routing configuration inside an NI often needs to refer to interfaces (at
> > >>    least those that are assigned to the NI), which is impossible unless such
> > >>    a reference can point to a node in the parent schema (interface name).
> > >>
> > >> This seems overstated.  Rather it is a result of an earlier design decision.
> > >> An alternate solution might have exported the global interfaces into a 
> > >> config false list inside the mount jail.   Was such a solution
> > >> discussed?
> 
> Actually, this wouldn't work, since config true leafrefs/xpaths can't
> refer to this "config false" list inside the mount jail.
> 
> Besides, even a symlink approach would in fact allow for "such a
> reference to point to a node in the parent schema tree".
> 
> > > Do you mean something like having "symlinks" to interfaces inside the
> > > mount jail? Yes, this was discussed and rejected. According to Martin,
> > > tail-f had made a very bad experience with this approach.
> > 
> > Yes, a little bit like a symlink inside the mount jail.  Good to hear
> > that it was discussed.  I still think the above "impossible" word is
> > overstating things.  Perhaps s/impossible such/possible when/?
> 
> See above; I think the current text is correct.
> 
> The point is that *somehow* the solution needs to allow for these
> kinds of references; symlinks could be one solution, the
> "parent-reference" that we use is another solution.

I agree, and also we don't want to make such nodes protocol-accessible in the
mounted tree.

> 
> > >> 3. Also from Section 4 (same paragraph):
> > >>
> > >>    For the purposes of
> > >>    evaluating XPath expressions within the mounted data tree, the union
> > >>    of all such nodesets is added to the accessible data tree.
> > >>
> > >> Could this ever result in name collision?
> > >
> > > Potentially yes, but sibling nodes with the same name are not an issue
> > > for XPath evaluation. 
> > 
> > I don't know if I agree that it can't be an issue.  What if the module
> > has a top-level /widgets container, and there is a parent-reference to
> > a /widgets container
> 
> The nodes exist in a namespace.  So if you have /widgets in two
> different modules there is no issue.  However, if you mount a module A
> and at the same time provide A's toplevel nodes as parent references
> then you might have a problem - or not!  The document defines what
> happens in this case (the result is the union).   Also note that
> constructing the set of mounted modules and corresponding
> parent-references is up to the implementation.

This is fine with must expressions but actually leafrefs are defined so that the
leaf instance being referred to has to be unique. This needn't be the case here
- I don't know if it matters.

> 
> > >> Also, should how NACM interacts with mounted instance data be
> > >> specified?
> > >
> > > This is a good question because, in principle, top-level NACM rules
> > > can address instances of mounted schemas. On the other hand,
> > > ietf-netconf-acm can also be a part of the mounted schema - and if
> > > so, can its rules also address instances in the parent schema via
> > > the parent-reference mechanism?
> > >
> > > But I would say it is up to rfc6536bis to deal with these questions.
> > 
> > I don't know, but it seems that this draft is introducing the concept.
> > Not to mention, rfc6536bis is already with the IESG.  In either case,
> > let's work out what it means and then decide which draft it needs to
> > go into.
> 
> I think NACM in the parent node should cover access to the mounted
> data.  For example, it should be possible to have a rule for:
> 
>  /network-instances/network-instance[name='foo']/vrf-root/rt:routing

Do you mean that NACM can only be used at the top level? What if it is also part
of the mounted schema?

> 
> 
> > >> 5. This document does not say anything about how it relates to NMDA.
> > >> Clearly all this is targeted to the conventional datastores
> 
> No, or maybe I don't understand what you mean.  Schema mount allows
> for mounting config false nodes, or even doing a "read-only" mount.
> Such a mount is clearly not available in the conventional datastores.
> 
> >, but how
> > >> is it reflected in e.g., ?  Does anything need to be said
> > >> here?
> > >
> > > The "use-schema" case shouldn't pose big problems because it is
> > > essentially an externally specified augment. The "inline" case is
> > > somewhat disturbing though: could the embedded YANG library instances
> > > be different in different datastores?
> > 
> > YANG Library is only available in  (it's all config false).

OK, so if I have a mount point of the "inline" type in  or ,
I have to go to , find the corresponding instance of the mount
point (if it's there), and read the YANG library data below it to learn the
schema in ? What if the mount point is inactive configuration? Then
the mounted schema probably cannot be determined at all.

> > I think you mean the embedded YANG Library instances under the mount 
> > points.  Yes, you may have a problem here.  Still, this isn't my question,
> > is more about schema-mounting requirements across datastores.  E.g., if
> > a schema-mount exists in , must it existing in  and
> >  as well?  Conversely, if a schema-mount exists in
> > , must it exist in ?  I think this draft should
> > clarify such things.

I am really confused: what do you mean by saying that "schema-mount exists"? Do
you mean "mount point exists"? If so, as long as the mount point is config=true,
it has to exist in all datastores (I assume). 

> 
> I agree that this needs to be clarified.  This issue partly comes from
> the fact that schema mount uses the groupings in the old yang
> library.  I think we need to use the new groupings from rfc7895bis.

YANG started basically as a document-oriented schema language (and schema mount
adheres to this view). NMDA tries to extrapolate its use to multiple documents
with differents schemas. My gut feeling is that this is not going to work - the
complexity will be overwhelming.

Lada

> 
> 
> > >> What if the mounted schema has deviations in .
> > >
> > > I don't understand why this could be an issue.
> > 
> > I'm not saying it's a problem yet.  I'm just stating that such things
> > can occur and it's unclear that, if they do, could it cause problems.
> > For instance, a mounted schema may be looking for a parent reference
> > that doesn't exist because of a deviation.
> > 
> > 
> > 
> > 
> > >> Nits (line-break separated):
> > >>
> > >> Is "other optional choices" being vague on purpose?  Should it just
> > >> call out features and deviations?
> > >
> > >Yes, it should.
> > >
> > >>
> > >> "the YANG library data" seems odd.  Maybe "the instance of the YANG
> > >> Library module"?
> > >
> > > It is the same but I prefer the former. Note that the term "instance"
> > > is not defined in RFC 7950.
> > 
> > okay
> > 
> > 
> > >> - document, and could be possibly dealt with in a future revision of the YANG data modeling language
> > >> + document, as it needs to be dealt with as an update to the YANG data modeling language
> > >
> > > I am not sure that it *needs* to be done, because it could have
> > > far-reaching consequences.
> > 
> > Here I'm using "needs" not to mean that it "has to be done" but more that,
> > if it is done, it would have to be done in an update to the YANG data 
> > modeling language.  The current sentence seems too open-ended...
> > 
> > 
> > >> - Schema mount applies to the data model
> > >> + Schema mount regards the data model
> > >
> > > OK
> > >
> > >>
> > >> - This document allows mounting of complete data models only.
> > >> + This document allows mounting of complete modules only.
> > >
> > > Correct
> > >
> > >
> > >> - may extend this model by defining
> > >> + may extend this solution by defining
> > >
> > > Or perhaps "approach"? I would leave "solution" to marketing folks.
> > 
> > "approach" is fine.
> > 
> > 
> > >> In S3, replace "YANG 1.1" with "YANG 1.1 and its continuances"?
> > >
> > > Not sure. For example, next version of YANG can/should turn "mount-point"
> > > into a built-in statement.
> > 
> > So then, when we define yang-next, we'd be forced to either incorporate
> > schema-mount or simultaneously publish an update to this RFC to allow
> > it to work with the new version of YANG?  Even if YANG-next defined a
> > built-in equilvalent, would we not want this mechanism to continue to
> > be supported, for backwards compatibility?
> > 
> > 
> > >> - A "container" or "list" node
> > >> + A 'container' or 'list' node
> > >
> > > Actually, following RFC 7950 conventions, no quotes should be used here.
> > >
> > 
> > I'm confused about these conventions - are they written down somewhere.
> > In Martin's review of zerotouch draft, he dinged me on my mis-use of
> > single-quotes, for the second time.  Looking at RFC 7950, I don't see
> > the convention listed anywhere, or are you saying that the convention
> > is throughout the RFC and folks are expected to implicitly understand
> > what it is?
> 
> I think you just should be consistent; if you attach some semantic
> meaning to single quotes vs double quotes the document needs to
> explain that meaning.  If it is just for quotation, be consistent.  I
> think the RFC editor prefers double quotes (but I can't find a
> reference to this).
> 
> As for the term container; this is a term for an interior node,
> defined in 7950, so it is used w/o quotes.   Compare with references
> to the "container" statement.
> 
> 
> 
> 
> /martin
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Nov  8 04:59: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 5C91E124319 for ; Wed,  8 Nov 2017 04:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xPpPp3IQL3VD for ; Wed,  8 Nov 2017 04:59:35 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EBDAB1201FA for ; Wed,  8 Nov 2017 04:59:34 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id DFF491AE0144; Wed,  8 Nov 2017 13:59:31 +0100 (CET)
Date: Wed, 08 Nov 2017 13:58:08 +0100 (CET)
Message-Id: <20171108.135808.522457298716867760.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: kwatsen@juniper.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1510136247.17913.33.camel@nic.cz>
References:  <20171108.095019.1523851923210652414.mbj@tail-f.com> <1510136247.17913.33.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] review of 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: Wed, 08 Nov 2017 12:59:37 -0000

Ladislav Lhotka  wrote:
> On Wed, 2017-11-08 at 09:50 +0100, Martin Bjorklund wrote:
> > Kent Watsen  wrote:
> > > 
> > > 
> > > > Hi Kent,
> > > >
> > > > thanks for the thorough review, see my responses inline.
> > > 
> > > Hi Lada, please see below.
> > > 
> > > 
> > > >> 1. From Section 4:
> > > >>
> > > >>    Routing configuration inside an NI often needs to refer to interfaces (at
> > > >>    least those that are assigned to the NI), which is impossible unless such
> > > >>    a reference can point to a node in the parent schema (interface name).
> > > >>
> > > >> This seems overstated.  Rather it is a result of an earlier design decision.
> > > >> An alternate solution might have exported the global interfaces into a 
> > > >> config false list inside the mount jail.   Was such a solution
> > > >> discussed?
> > 
> > Actually, this wouldn't work, since config true leafrefs/xpaths can't
> > refer to this "config false" list inside the mount jail.
> > 
> > Besides, even a symlink approach would in fact allow for "such a
> > reference to point to a node in the parent schema tree".
> > 
> > > > Do you mean something like having "symlinks" to interfaces inside the
> > > > mount jail? Yes, this was discussed and rejected. According to Martin,
> > > > tail-f had made a very bad experience with this approach.
> > > 
> > > Yes, a little bit like a symlink inside the mount jail.  Good to hear
> > > that it was discussed.  I still think the above "impossible" word is
> > > overstating things.  Perhaps s/impossible such/possible when/?
> > 
> > See above; I think the current text is correct.
> > 
> > The point is that *somehow* the solution needs to allow for these
> > kinds of references; symlinks could be one solution, the
> > "parent-reference" that we use is another solution.
> 
> I agree, and also we don't want to make such nodes protocol-accessible in the
> mounted tree.
> 
> > 
> > > >> 3. Also from Section 4 (same paragraph):
> > > >>
> > > >>    For the purposes of
> > > >>    evaluating XPath expressions within the mounted data tree, the union
> > > >>    of all such nodesets is added to the accessible data tree.
> > > >>
> > > >> Could this ever result in name collision?
> > > >
> > > > Potentially yes, but sibling nodes with the same name are not an issue
> > > > for XPath evaluation. 
> > > 
> > > I don't know if I agree that it can't be an issue.  What if the module
> > > has a top-level /widgets container, and there is a parent-reference to
> > > a /widgets container
> > 
> > The nodes exist in a namespace.  So if you have /widgets in two
> > different modules there is no issue.  However, if you mount a module A
> > and at the same time provide A's toplevel nodes as parent references
> > then you might have a problem - or not!  The document defines what
> > happens in this case (the result is the union).   Also note that
> > constructing the set of mounted modules and corresponding
> > parent-references is up to the implementation.
> 
> This is fine with must expressions but actually leafrefs are defined so that the
> leaf instance being referred to has to be unique.

I'm not sure what you refer to, but in general a leafref can refer to
more than one node:

   The "path" expression evaluates to a node set consisting of zero,
   one, or more nodes.  If the "require-instance" property is "true",
   this node set MUST be non-empty.


> This needn't be the case here
> - I don't know if it matters.
> 
> > 
> > > >> Also, should how NACM interacts with mounted instance data be
> > > >> specified?
> > > >
> > > > This is a good question because, in principle, top-level NACM rules
> > > > can address instances of mounted schemas. On the other hand,
> > > > ietf-netconf-acm can also be a part of the mounted schema - and if
> > > > so, can its rules also address instances in the parent schema via
> > > > the parent-reference mechanism?
> > > >
> > > > But I would say it is up to rfc6536bis to deal with these questions.
> > > 
> > > I don't know, but it seems that this draft is introducing the concept.
> > > Not to mention, rfc6536bis is already with the IESG.  In either case,
> > > let's work out what it means and then decide which draft it needs to
> > > go into.
> > 
> > I think NACM in the parent node should cover access to the mounted
> > data.  For example, it should be possible to have a rule for:
> > 
> >  /network-instances/network-instance[name='foo']/vrf-root/rt:routing
> 
> Do you mean that NACM can only be used at the top level? What if it is also part
> of the mounted schema?

I don't think that we can/should require that a server that mounts
nacm has to enforce the nacm rules in the mount jail.

One reason for mounting nacm would be "peer mount" where you mount all
models some other device supports.  In this case that other device
will of course enfore the nacm rules, but in the parent node these
nacm rules don't mean anything.


> > > >> 5. This document does not say anything about how it relates to NMDA.
> > > >> Clearly all this is targeted to the conventional datastores
> > 
> > No, or maybe I don't understand what you mean.  Schema mount allows
> > for mounting config false nodes, or even doing a "read-only" mount.
> > Such a mount is clearly not available in the conventional datastores.
> > 
> > >, but how
> > > >> is it reflected in e.g., ?  Does anything need to be said
> > > >> here?
> > > >
> > > > The "use-schema" case shouldn't pose big problems because it is
> > > > essentially an externally specified augment. The "inline" case is
> > > > somewhat disturbing though: could the embedded YANG library instances
> > > > be different in different datastores?
> > > 
> > > YANG Library is only available in  (it's all config false).
> 
> OK, so if I have a mount point of the "inline" type in  or ,
> I have to go to , find the corresponding instance of the mount
> point (if it's there)

It is, per the latest discussions, where we say that the schema for
operational is a superset of the schema for the config.

>, and read the YANG library data below it to learn the
> schema in ?

Sure, and this is how it would work in pre-NMDA as well, to learn the
schema for  for example.



/martin



> What if the mount point is inactive configuration? Then
> the mounted schema probably cannot be determined at all.
> 
> > > I think you mean the embedded YANG Library instances under the mount 
> > > points.  Yes, you may have a problem here.  Still, this isn't my question,
> > > is more about schema-mounting requirements across datastores.  E.g., if
> > > a schema-mount exists in , must it existing in  and
> > >  as well?  Conversely, if a schema-mount exists in
> > > , must it exist in ?  I think this draft should
> > > clarify such things.
> 
> I am really confused: what do you mean by saying that "schema-mount exists"? Do
> you mean "mount point exists"? If so, as long as the mount point is config=true,
> it has to exist in all datastores (I assume). 
> 
> > 
> > I agree that this needs to be clarified.  This issue partly comes from
> > the fact that schema mount uses the groupings in the old yang
> > library.  I think we need to use the new groupings from rfc7895bis.
> 
> YANG started basically as a document-oriented schema language (and schema mount
> adheres to this view). NMDA tries to extrapolate its use to multiple documents
> with differents schemas. My gut feeling is that this is not going to work - the
> complexity will be overwhelming.
> 
> Lada
> 
> > 
> > 
> > > >> What if the mounted schema has deviations in .
> > > >
> > > > I don't understand why this could be an issue.
> > > 
> > > I'm not saying it's a problem yet.  I'm just stating that such things
> > > can occur and it's unclear that, if they do, could it cause problems.
> > > For instance, a mounted schema may be looking for a parent reference
> > > that doesn't exist because of a deviation.
> > > 
> > > 
> > > 
> > > 
> > > >> Nits (line-break separated):
> > > >>
> > > >> Is "other optional choices" being vague on purpose?  Should it just
> > > >> call out features and deviations?
> > > >
> > > >Yes, it should.
> > > >
> > > >>
> > > >> "the YANG library data" seems odd.  Maybe "the instance of the YANG
> > > >> Library module"?
> > > >
> > > > It is the same but I prefer the former. Note that the term "instance"
> > > > is not defined in RFC 7950.
> > > 
> > > okay
> > > 
> > > 
> > > >> - document, and could be possibly dealt with in a future revision of the YANG data modeling language
> > > >> + document, as it needs to be dealt with as an update to the YANG data modeling language
> > > >
> > > > I am not sure that it *needs* to be done, because it could have
> > > > far-reaching consequences.
> > > 
> > > Here I'm using "needs" not to mean that it "has to be done" but more that,
> > > if it is done, it would have to be done in an update to the YANG data 
> > > modeling language.  The current sentence seems too open-ended...
> > > 
> > > 
> > > >> - Schema mount applies to the data model
> > > >> + Schema mount regards the data model
> > > >
> > > > OK
> > > >
> > > >>
> > > >> - This document allows mounting of complete data models only.
> > > >> + This document allows mounting of complete modules only.
> > > >
> > > > Correct
> > > >
> > > >
> > > >> - may extend this model by defining
> > > >> + may extend this solution by defining
> > > >
> > > > Or perhaps "approach"? I would leave "solution" to marketing folks.
> > > 
> > > "approach" is fine.
> > > 
> > > 
> > > >> In S3, replace "YANG 1.1" with "YANG 1.1 and its continuances"?
> > > >
> > > > Not sure. For example, next version of YANG can/should turn "mount-point"
> > > > into a built-in statement.
> > > 
> > > So then, when we define yang-next, we'd be forced to either incorporate
> > > schema-mount or simultaneously publish an update to this RFC to allow
> > > it to work with the new version of YANG?  Even if YANG-next defined a
> > > built-in equilvalent, would we not want this mechanism to continue to
> > > be supported, for backwards compatibility?
> > > 
> > > 
> > > >> - A "container" or "list" node
> > > >> + A 'container' or 'list' node
> > > >
> > > > Actually, following RFC 7950 conventions, no quotes should be used here.
> > > >
> > > 
> > > I'm confused about these conventions - are they written down somewhere.
> > > In Martin's review of zerotouch draft, he dinged me on my mis-use of
> > > single-quotes, for the second time.  Looking at RFC 7950, I don't see
> > > the convention listed anywhere, or are you saying that the convention
> > > is throughout the RFC and folks are expected to implicitly understand
> > > what it is?
> > 
> > I think you just should be consistent; if you attach some semantic
> > meaning to single quotes vs double quotes the document needs to
> > explain that meaning.  If it is just for quotation, be consistent.  I
> > think the RFC editor prefers double quotes (but I can't find a
> > reference to this).
> > 
> > As for the term container; this is a term for an interior node,
> > defined in 7950, so it is used w/o quotes.   Compare with references
> > to the "container" statement.
> > 
> > 
> > 
> > 
> > /martin
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 


From nobody Wed Nov  8 05:14: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 0A5BA1250B8; Wed,  8 Nov 2017 05:14:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.348
X-Spam-Level: 
X-Spam-Status: No, score=-1.348 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, URG_BIZ=0.573] 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 tcDXxVToUyy7; Wed,  8 Nov 2017 05:14:41 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0138.outbound.protection.outlook.com [104.47.2.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 8F6961201F2; Wed,  8 Nov 2017 05:14:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aRUWTes1zFCJOA3+Os2XNcGxm1GfewSXbN3j0ZS+pg4=; b=Br12IsnBWTU0+awwnkKVY4oyYXnhEpyg7upkE3qHuLjwFBsbLlLIw1oZ7BMypZzQq+G/0MJrTbOb8pbhEKkrxXzr6UxS4gCZVHOJLU1JqNlDM3H6bzyF38T9NOSjHJC0c1g73vuu0u8FxXqRQLnvmNP7QszJ2JspisGM8W1HRFo=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.169.153.236) 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.218.6; Wed, 8 Nov 2017 13:14:37 +0000
Message-ID: <02fb01d35893$2081f160$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Jiangyuanlong" , "Alex Campbell" , 
Cc: "Xian Liu" , "Xujinchun" ,  
References: <150906887826.22201.5033565145094897903.idtracker@ietfa.amsl.com>,  <3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97@dggeml507-mbx.china.huawei.com> <1509329710965.52658@Aviatnet.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8@dggeml507-mbs.china.huawei.com>
Date: Wed, 8 Nov 2017 13:11:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.169.153.236]
X-ClientProxiedBy: VI1PR09CA0066.eurprd09.prod.outlook.com (2603:10a6:802:28::34) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5504bda7-e9c5-4afb-b96e-08d526aaa9f5
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603199); SRVR:HE1PR0701MB3003; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:ZvOqyxM8zPCrLMVNB5RQ9Nc0BOiUJkngG37NkDdrb+UafsmqkRaC4H1s070ZHyFasw3Fp+uNfd58eCTfq7wlGAahqFHUjfFmQNP0QAAl7aQwDzsaayoGuLfnU0iuwohRgtsG9SiNK4LzEae9mqjis9x2WD1AX3dbXx2D7BUaRoqiEGcUTRozOfibwwN7aFMcqmAXRrgZfC9HvF6r+Yl85kMteASdwBjhBL3E9QdJUjclIt/XizuBsqglvgi+Q54C; 25:XUAdaSkyf4gLsVXOVOQpfEu82LDvZNuT6h+VlxGlld4Gk8LXcRm37YVozpkJMyGHQrId4ebWw4DhdC+aOJRlOjXxy+6KlzjiNhMpTNPleAp0IZY56PB0wW+t937fy5pCIE8Q9WV0BUbhIKqOZKq0S7v6FY89t4LflkyOJXjAOnLkYJ8pl0302ZBNp2iYCfYOCbe+w8IT9bGQLuP161ffXNpLgFHVKfoKPU63jBOHs8X8tXi5pyXVFyoVlALoujr/Oe2fUCYvyhf0Fk/pSVBVfm8sb0viZ+XW6LB3oEG+nB07z1v+2zCXE1PTbk44x+zlVyTNtqQTYLjFFlpKEKyOMA==; 31:Gs/Cvf9d2v1v2uWQM4ZydFVWis7zy6FUDwp53CA8oJOuuSnOQtILN/n7a7MBlrRopkEQO6MHIikg0ThrwrlQHggK7qfgGmoqgaFHdI9l2HAeXi62oeOOy5JuuZM8vYAFnocZ6tslcpXyMTcid9vEaJiUpshocLiHqPUVVxdtxrGKVcWhPr/ABLLLQgxZg2zwUr8Yyy90c4ohT7H5OuaiyI5xTr8zZwZIxMFrvAvVBKM=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003:
X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(120809045254105)(50582790962513)(100405760836317)(265557217796441)(145744241990776);
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)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3231021)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(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:8fnQoHqO5khKihiIk7BTOLc6k3Xtedz0hwjQPJZbZ2hPqWBQgl3kslArudeFmMBWg21KPFlWpnGXQ+kf3KwnmjtvZ+biVyN7BtP1hI0LOSZjGr0S2+ECwdt7Zfwa6Gs5n1KDbGgM6VwGOrn+v9iO3k5WuZ66LK2kyLTQ3NHdq0PeKXD3loJevAXg6mCQk3eEoGuJoQgItMxcs1fpfQwRxFS+fmbyoWqEJjlXPW8f9QpdCpL8n2CCMKCnB6avrdVvcrz9Ig6Efy920nFhdxtC73S2ZSnWsME4i2TGHVdwfwbgTCLgh4WWn9YqhLVY2ngJvi0O2Lw7/aSMyd7o0U7T6mW0VTllc63ABoTnuitYyJk9pF2jAOQV9Li+6PySCLfpgSXkgXADKXPn2ERLCaeoUYTkoJqEjImwCbqhbWDMLOspCwqJUUWPlLeBQUT2F97kHAihUtywYiTnZpR4wxnJGaIqSTapHVaSKp+5DGN4rYw=
X-Forefront-PRVS: 0485417665
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(346002)(376002)(39860400002)(189002)(199003)(377424004)(13464003)(43784003)(51444003)(47776003)(84392002)(44716002)(229853002)(44736005)(110136005)(54906003)(4720700003)(230783001)(14496001)(33646002)(116806002)(6666003)(25786009)(4001150100001)(6486002)(106356001)(105586002)(68736007)(50226002)(478600001)(93886005)(316002)(7736002)(305945005)(6116002)(53546010)(966005)(3846002)(50466002)(61296003)(8936002)(6306002)(9686003)(81166006)(8676002)(23756003)(81156014)(97736004)(5660300001)(62236002)(66066001)(2906002)(189998001)(6496005)(53936002)(50986999)(230700001)(86362001)(1556002)(81686999)(16526018)(1456003)(81816999)(101416001)(4326008)(6246003)(76176999)(48020200001)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); 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:txIVO8HlY8/6S20zbQG9W6JvqPqOvzP7bob+p?= =?iso-8859-1?Q?fv8T1wSCFmQsy8w9lcDp3T2OXYSh/aAGQQuzOsZ6djEpXL2k28bNLf0pb+?= =?iso-8859-1?Q?QVFBY8e4YytyREhZ3IGab4g1N/nLczppS+aHAcRnkm3GcDX6Y8nezAY6z2?= =?iso-8859-1?Q?rC3J8Iz0yhoZEpxJilCKe7EBsjZ87wuj6Q3Njc/b1x/xNP0t43eo5Ij28Z?= =?iso-8859-1?Q?T6t2WbqRfj/NVCV1sFsmnx3/+PcntOf/4sXXR7mGd7D4wkU6YdKpNaxZvq?= =?iso-8859-1?Q?69nwhn8hncvpErh8es9qK4gN9E4O0LSzTZAc8QoWBTA/BNY6U37mX4ouCV?= =?iso-8859-1?Q?UYNZFI9SjwfH2MbCfU1kgn4x3Ut3tUM5ZSRoAm7ApDhJPAcBgpEmJjKJnA?= =?iso-8859-1?Q?IXKp9qvWoqfjbvZczJgmR4iqp30iD5N4rJyhPOVNGAwRpsE1XSFh47EDzN?= =?iso-8859-1?Q?vzMsq8mqsS0G5WBh7H5uSKAm+bFdI2pDzSRjzVOx3hr0oRBGvRkLd1KN/L?= =?iso-8859-1?Q?2aPOIMzCC2s/7y71gMONqHV7EbHGrSyQZ2vYpScA3CL9hMP9FlqckbwH2Y?= =?iso-8859-1?Q?JQhlXog7lQcSSFSxnWZl3A4+5k9imfH3M4JJEGzv27Ayt7vClPC+Xdfej5?= =?iso-8859-1?Q?ta3ZkLfnBqHlo7Uu376ISHZg/aTITgkHdpis2vvxMkr/dsWbz7KPD0tM6v?= =?iso-8859-1?Q?Gj2w1OndOfIUeqLzo85boTz0kQDrRQzVX4HT5zzMAlvVQ4I3ldQ02qQcpT?= =?iso-8859-1?Q?9G5IgnA2/yJ9re1tmuChlGcJcstDZkrKltNpCB5tyL8j/JKyd8TVgdysgw?= =?iso-8859-1?Q?MBX17LiQYvNAYuVmaRt9socWyJs2PWkTblvVRnHxYKCi7tW27fITRSwSBy?= =?iso-8859-1?Q?Y3mIZLFRhJbhM51es0ivkPb1ipVwpvHfUIGGSxiElLv/UfY+gjsi+TBq/R?= =?iso-8859-1?Q?Tf1hgSvU/vmBH5QGF01N/YDx2udz2s8zYhW5EMaJuwYqjdZKhfJScfXvTN?= =?iso-8859-1?Q?YNIxy2dkHAxfsRMzFT4T61HucSZhe5TlIimlzmdVUe5F5rwg/xO1VsnHgb?= =?iso-8859-1?Q?OYX+ZMjNLYnCYAy15oMqc+MG46k7KPr4o5dtjDYHhR0giMdDEkpqhfCfrv?= =?iso-8859-1?Q?n/780NCiMdioxl/Hf/vCC49a6Qrv1a2h9uhgiASpuPfQdmRp1YR1O3tXCi?= =?iso-8859-1?Q?+BrOXs/yxAC7FXYTZRbbZhGWfyi0Pany9FD3mqjVmNHhVs3QADvT4vMqRS?= =?iso-8859-1?Q?R31xtHF0RhkXo0DBxmvaL72qz4xyLwHpVv1lh6FF3LDD+e1cwAHdrRcOai?= =?iso-8859-1?Q?UYb+a6HRXO+mH9LCgiVMADlGV6ecmrhQ+6wBg7uCLEAlpEHLVLhAf/9ORI?= =?iso-8859-1?Q?OCGHbIlx/0kNvgb6nxNs1n7Jcxarr4e3l+6acDwtsxecC6bQbn4R3AEHrQ?= =?iso-8859-1?Q?Lc0oOYsSmvDaFpwQi6x8Z8XZ1W2mw3d1BOh3SbFG50V61f4PWA1/+a7EoA?= =?iso-8859-1?Q?ulQBewCY+dYRu7H1Q2TyUR3PwSfIwnlBL7GQ+azqqPL3E05UXTAcEFz4nQ?= =?iso-8859-1?Q?7P4DiHGO7hiqNJUDeiWLFpbK3vQnQqSAuAzr/AMGdU/2WJTDt0qjQCvNFZ?= =?iso-8859-1?Q?6gzKVmrvLOMAFv7tqENCRg7n33GsyFliRLzygyHgd3OCd/lzK2dud6srFv?= =?iso-8859-1?Q?0qltZ3gvln7xtvGShY+kZMjZnUo+6K4Nwll1Cky5n5LHhTmASCTZNIhof9?= =?iso-8859-1?Q?qcVyZhT7Mhy16QTrlzCxInefTHvZw96LQRBMpZsCWoJDAlC62hyEQicPgP?= =?iso-8859-1?Q?Cfr/QjD1s?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:r1UquYC5nXHFfELOXMhO4Rkdi/LLl9FxWji9IY8mhu6Xw1UhAi8WS4O0PlTc1LVxD7cx1yUfZXF1n7HihmOJlgB6qyxqe2JFhNQgiSIdn997RZ6pp3ViKs+/wjITDcKm4WmQLdbljcihF9ox+hYqcdJqk/gz6D4KvvUvIHqDYzyJx8ELpXjTYKQ7uAJshJJvlIgMlaL/9bmo+Hb/2XsNxkPGFrJrRj/f5p6EwM7VM7VhZT+XfC6e8ShrNUw0YXOl5ZOLvcSOYGK6aSaHDjbVy08CDYUwaugtN+bae9pBWqYE5jN7bopZUS76Zn2/oQ9xZqAbnaKvAH6GwzzoW/jMjBm6btCeMI2opMR74dGKkhw=; 5:5R70X5swE2KcBUnSMAOPy8INP24URd07X5GW/GVN+edcUyXzB7dQvh11vP6YU+1kFziDZFwqAhl8CwcT8o+nHdy3rhSOLEb+gBPaajqv8Jp5fHN/t4pHqOqdWXTVV1/Q0EhaqYzkCqs0N9vQT+ylQPIS/1dE8WxXhuZ3zi1ej+A=; 24:XD2mXonbD8xa9XwKdzizHzLewR5Ncz3MldCLH8lvvxtlzIUmQKxvqkYfV+g7Bib+2gf3hXpi/xu9alEyrCkMbD6VUEYDdBxfWC1tJqNRmPU=; 7:idZ9Rw0v/9ydKTxrEah/h9QRoA9KbADstlZNfYn9bC7qfbErqJezoxu2o6MD/VKvPoo6mg3K4JTj/QBaeElJvP32N52indGFWlDU27ipYmEG9WONrq4u0fErRyR4g6tSTnkz/kFq9aF6C4WcGEI3Dg2AT6la9683GWwRcRLxgJW+zVo23FmQhPPbtKn0Mo6S8k8Is/mZcBMp6UVdjRYVxMAlugtcAympmOy9ZAwxfHoJu09Ottb8oUwsYxtlwKiz
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2017 13:14:37.0854 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5504bda7-e9c5-4afb-b96e-08d526aaa9f5
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 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: Wed, 08 Nov 2017 13:14:44 -0000

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules
is woefully weak).

I think too that you are spot on with your terminology; where IEEE
1588-2008 has an accepted way of working, then that is the right way for
this I-D.

One fresh comment arising from that.  You commented earlier that you had
departed from IEEE 1588-2008 in changing camel case to the YANG style
names, with hyphens, and I think that that is a logical choice.  But I
would go further and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put
that; probably Section 2, perhaps immediately before the tree diagram,
since that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would
be worth having a concordance of IEEE 1588-2008 names and YANG names;
this was common practice with MIB Modules.

Tom Petch

----- Original Message -----
From: "Jiangyuanlong" 
To: "Alex Campbell" ; 
Cc: "Xian Liu" ; "Xujinchun"
; 
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


> Hi Alex,
>
> Sorry for a late reply as I spent the last week for an urgent business
trip.
> Please see my comments in line with [YJ]
>
> Thanks,
> Yuanlong
>
> -----Original Message-----
> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
> Sent: Monday, October 30, 2017 10:15 AM
> To: Jiangyuanlong; tictoc@ietf.org
> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
>
> Hi,
> I've reviewed this latest draft and have some more comments.
>
> 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.
>    For example, there is no need to elaborate on YANG data types here.
It is also not here to sell YANG.
>
> [YJ] Yes, we are trying to give some introductory information for an
outsider who may not be familiar with PTP or YANG, and explain why a
YANG for PTP is needed. The juicy part of this document is its YANG
module, and people can skip all the other texts if they are familiar
with PTP and YANG.
> Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear
message from the TICTOC chairs to introduce any big changes at this last
call stage.
>
>
> OLD:
>
>    As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
>    supported in the carrier networks, industrial networks, automotive
>    networks, and many other applications. It can provide high
>    precision time synchronization as fine as nano-seconds. The
>    protocol depends on a Precision Time Protocol (PTP) engine to
>    decide its own state automatically, and a PTP transportation layer
>    to carry the PTP timing and various quality messages. The
>    configuration parameters and state data sets of IEEE 1588-2008 are
>    numerous.
>
>    According to the concepts described in [RFC3444], IEEE 1588-2008
>    itself provides an information model in its normative
>    specifications for the data sets (in IEEE 1588-2008 clause 8). Some
>    standardization organizations including the IETF have specified
>    data models in MIBs (Management Information Bases) for IEEE 1588-
>    2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
>    typically focused on retrieval of state data using the Simple
>    Network Management Protocol (SNMP), furthermore, configuration of
>    PTP data sets is not considered in [RFC8173].
>
>    Some service providers and applications require that the management
>    of the IEEE 1588-2008 synchronization network be flexible and more
>    Internet-based (typically overlaid on their transport networks).
>    Software Defined Network (SDN) is another driving factor, which
>    demands an improved configuration capability of synchronization
>    networks.
>
>    YANG [RFC6020] is a data modeling language used to model
>    configuration and state data manipulated by network management
>    protocols like the Network Configuration Protocol (NETCONF)
>    [RFC6241]. A small set of built-in data types are defined in
>    [RFC6020], and a collection of common data types are further
>    defined in [RFC6991]. Advantages of YANG include Internet based
>    configuration capability, validation, rollback and so on. All of
>    these characteristics make it attractive to become another
>    candidate modeling language for IEEE 1588-2008.
>
> NEW:
>
>    IEEE 1588-2008 is a time protocol that provides high precision time
>    synchronization as fine as nano-seconds.
>
>    IEEE 1588-2008 itself provides an information model in its
normative
>    specifications for the data sets (IEEE 1588-2008 clause 8).
>    Standard information models (e.g. [RFC8173], [IEEE8021AS]) have
been
>    previously defined as MIBs focused on the retrieval of state data
using
>    SNMP [RFC1157].
>
>    YANG [RFC6020] is a data modeling language used to model
configuration
>    and state data manipulated by network management protocols like
NETCONF
>    [RFC6241].
>
> 2. Can we refer to the system as simply PTP rather than IEEE
1588(-2008)?
> [YJ] Advice from IEEE 1588 is, we need to use "1588-2008" as much as
possible to help clarify that the scope of this YANG is limited to the
published 1588 standard.
>
>
> 3. There is insufficient spacing here to separate the terms from their
definitions:
> OLD
>
>    PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
>    for PTP protocol decisions and for providing values for PTP message
>    fields, see Section 8 of [IEEE1588].
>
>    PTP instance A PTP implementation in the device (i.e., an OC or BC)
>    represented by a specific PTP dataset.
>
> NEW
>
>    PTP dataset
>      Structured attributes of clocks (an OC, BC or TC) used
>      for PTP protocol decisions and for providing values for PTP
message
>      fields, see Section 8 of [IEEE1588].
>
>    PTP instance
>      A PTP implementation in the device (i.e., an OC or BC)
>      represented by a specific PTP dataset.
> [YJ] OK.
>
> 4. There's a singular/plural mismatch here:
>
>    module. Query and configuration of device wide or port specific
>    configuration information and clock data set is described for this
>    version.
> [YJ] Good, we will change 'is' to 'are'.
>
> and here:
>
>    Query and configuration of clock information include:
>
>
> 5. The choice of uint16 as instance-number limits implementations to
65536 distinct instances.
>    While I have a hard time imagining a system with more than 65536
PTP instances, I would prefer to avoid imposing arbitrary limits.
>    I would recommend changing instance-number to a string (and
renaming it to instance-name or just name).
> [YJ] The 1588-2008 supports multiple instances of PTP, but it is
ambiguous in its organization of those PTP instances, especially with
regard to management.
>  In the 1588 new revision, there is an explicit list of PTP instances,
and that list is indexed using a number (not name). Thus to align with
the new revision, we need to keep it instance-number.
>  If 65536 limit is a concern, how about change it to uint32, any
concerns?
>
>
> 6. I still recommend removing -ds from the YANG element names that
still include it. It doesn't appear to add any value.
> [YJ] Rodney's opinion: the value of using 'ds' is that the 1588
document on which this YANG model is based uses "DefaultDS" as a term.
PTP experts even say "default dee ess" verbally when referring to this
data. If we changed this to just "default", PTP experts might assume
that we are referring to something entirely new to YANG. Thus, to align
with 1588-2008, the same set of terminologies are used.
>
> 7. What;s the relevance of injection attacks relevant to this YANG
module?
> [YJ] This is a general statement which is applicable to this YANG
module and other YANG modules as well.
> Thanks again,
> Yuanlong
>
> Alex
>
>
> ________________________________________
> From: netmod  on behalf of Jiangyuanlong

> Sent: Friday, 27 October 2017 3:21 p.m.
> To: tictoc@ietf.org
> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> Subject: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
>
> Dear all,
>
> Based on all the comments we received during the WG Last Call process,
we've updated the document to version 6.
> We believe all the LC comments are resolved and the consensus is
reflected in this new revision.
> Many thanks to Martin, Tal, Opher, Alex, John and many others who had
reviewed and commented on this draft.
>
> Cheers,
> Yuanlong on behalf of all coauthors
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Friday, October 27, 2017 9:48 AM
> To: Xian Liu; Rodney Cummings; rodney.cummings@ni.com; Jiangyuanlong;
Xujinchun
> Subject: New Version Notification for
draft-ietf-tictoc-1588v2-yang-06.txt
>
>
> A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
> has been successfully submitted by Yuanlong Jiang and posted to the
IETF repository.
>
> Name:           draft-ietf-tictoc-1588v2-yang
> Revision:       06
> Title:          YANG Data Model for IEEE 1588-2008
> Document date:  2017-10-26
> Group:          tictoc
> Pages:          30
> URL:
https://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588v2-yang-06.tx
t
> Status:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
> Htmlized:
https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-06
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-06
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588v2-yang-06
>
> Abstract:
>    This document defines a YANG data model for the configuration of
>    IEEE 1588-2008 devices and clocks, and also retrieval of the
>    configuration information, data set and running states of IEEE
>    1588-2008 clocks.
>
>
>
>
> 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
>
> _______________________________________________
> 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 Nov  8 05:25: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 36C20126C22 for ; Wed,  8 Nov 2017 05:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QysQgHZlNIF for ; Wed,  8 Nov 2017 05:25:48 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9821250B8 for ; Wed,  8 Nov 2017 05:25:45 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 6576E18215DD; Wed,  8 Nov 2017 14:25:07 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 403AB1820F78; Wed,  8 Nov 2017 14:25:05 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , "netmod\@ietf.org" , Martin Bjorklund 
In-Reply-To: <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com>
Mail-Followup-To: Robert Wilton , "netmod\@ietf.org" , Martin Bjorklund , Kent Watsen 
Date: Wed, 08 Nov 2017 14:26:47 +0100
Message-ID: <874lq4oq94.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Wed, 08 Nov 2017 13:25:52 -0000

Hi Rob,

thank you for the review, my replies are inline.

Robert Wilton  writes:

> Hi,
>
> I have read this document and think that is almost ready for publication.
>
> I have one general comment regarding the YANG module library (at the=20
> end), and a few nits, but otherwise the draft looks good.
>
> 1. Sec 1. Introduction paragraph 2, "internal node".=C2=A0 It wasn't=20
> absolutely clear to me what an internal node is, so I wonder whether=20
> this would be more clear as=C2=A0 "internal (i.e. non root) node".

Agreed, but probably with a hyphen: "non-root"?

>
> 2. Sec 1. Introduction, page 4, paragraph starting "2.=20
> Implementation-time ...".=C2=A0 This section states that it is a stable a=
s=20
> YANG library, and hence cannot change due to a server reboot. However,=20
> YANG library doesn't appear to have that restriction, and hence this=20
> doesn't seem to align with RFC 7895, introduction paragraph 2.

I don't know exactly under what circumstances YANG library can change
after a reboot, but in such a case schema-mounts data might be subject
to a change as well. I definitely think that the "run-time" case is
something else.

>
> 3. Sec 2.1 Glossary of New Terms:=C2=A0 "Schema" isn't actually defined=20
> anywhere (RFC 7950 doesn't define this).=C2=A0 Should it be defined here?=
=C2=A0=20
> The NMDA datastores draft had a similar issue and we choose to define=20
> "datastore schema" instead.

I think the right place for defining the term "schema" (and "data model"
as well) is the specification of YANG because it is desirable that all
documents related to YANG use the same meaning.

>
> 4. Sec 3.2. paragraph 1.=C2=A0 Same comment as 2 above also applies here.=
=C2=A0=20
> The text "same management session" might be more clear as "same client=20
> management protocol session".

Hmm, I wouldn't say this is more clear - it seems to indicate that we
are managing the client.

But it could also be that such rules are inappropriate in this document and
rather belong to a protocol spec.

>
> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" =3D=
>=20
> "are possible, and as such, needs"

I actually don't understand neither this sentence nor what the point of
such exceptions could possibly be.

>
> 6. Sec 3.2 paragraph 5.=C2=A0 Would it useful to state that even though t=
he=20
> schema is the same, the data is different and not necessarily related.

I think this goes without saying, as it is also the case for a single mount
point that is a list node - data in each entry is different.

>
> 7. Sec 3.3 last paragraph.=C2=A0 "On the other hand, " =3D> "In addition,=
 "

Yes.

>
> 8.=C2=A0 Sec 6 Implementation Notes.=C2=A0 Would this section be better n=
amed=20
> "Implementation Considerations"?

Agreed.

>
> 9. Structure of ietf-yang-schema-mount module:
>  =C2=A0 - Should "uri" under namespace be marked as "mandatory" so that i=
t=20
> doesn't appear to be optional in the tree diagram.

Yes, this is an omission.

>  =C2=A0 - Should the "module" name be included under the namespace.=C2=A0=
 It seems=20
> that lots of other "module bindings" are done via the module name rather=
=20
> than the namespace?

We need it exclusively for XPath, so it seems natural to stay close to XML
namespaces.

>
> 10. Example A.3.=C2=A0 This contains some features that are enabled. Poss=
ibly=20
> it would be useful in the description to point this out, and state that=20
> unless the features are listed they wouldn't be enabled.

Yes, we reuse the groupings from ietf-yang-library, and the idea is to
apply the same semantics. And as you are saying below, it would be more
straightforward to integrate it directly with YANG library.=20

>
> My last general comment relates generally to the structure of the=20
> Iietf-yang-schema-mount.=C2=A0 As Lada has pointed out previously, this=20
> module and YANG library bis could be more closely aligned (e.g. along=20
> the lines of reusing module-sets for the "schema" list).=C2=A0 It would h=
ave=20
> been nice if this module could augment YANG library (so that you can=20
> easily get the modules and schema mount information in a single simple=20
> request), however that would put an undesired dependency delaying=20
> publishing this draft until YANG library bis is completed.

Of course I agree, but I think the priority should be to make things as
simple and easy to understand as possible. They are complex enough
anyway.

Thanks, Lada

>
> Thanks,
> Rob
>
>
> On 20/10/2017 22: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
>> .
>>
>

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


From nobody Wed Nov  8 06:51: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 304D81270A7 for ; Wed,  8 Nov 2017 06:51:35 -0800 (PST)
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 xIIVJU-6AO5E for ; Wed,  8 Nov 2017 06:51:32 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E704F12706D for ; Wed,  8 Nov 2017 06:51:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18121; q=dns/txt; s=iport; t=1510152692; x=1511362292; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=EJIddbcsMqeevtMjr6hkECilps4FRZ6OClu3DttmCxc=; b=V+oQTul0KBOLMP2emQEFoSGFtPeCX9ne4Faww2FV50CgbQcONqWHcs8n P6NFuu0Vfb/M0Poz3sni/+u79AHMiPVpgS7kqLF1TGDil5sr+SaN2355Y 7m9+rPFjy7xTNGxW1zkMiC3UwZm4ON4Tuh3+Bgga0U+rkpQAZRi37HIBJ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADAGANa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEgVRuJ4N9ih90kC2RBIVIEIIBChgBCoFegmtPAoU7GAEBAQE?= =?us-ascii?q?BAQEBAWsohR4BAQEBAgEBASFLGwsYKgICJzAGAQwGAgEBihcIEKlEgicminYBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYMwg1uBaSmDAYRiARIBCYMrgmMFkWGHKYk?= =?us-ascii?q?QlH6CFYYEg2AkhxuOModvgTkfOIEDbjQhCB0VSYJkhF9BNologjUBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,364,1505779200"; d="scan'208,217";a="97173"
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; 08 Nov 2017 14:51:29 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA8EpTvo013089; Wed, 8 Nov 2017 14:51:29 GMT
To: "netmod@ietf.org" , Martin Bjorklund , Kent Watsen 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz>
From: Robert Wilton 
Message-ID: <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com>
Date: Wed, 8 Nov 2017 14:51:29 +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: <874lq4oq94.fsf@nic.cz>
Content-Type: multipart/alternative; boundary="------------15ADA7E6E82E8D005A208937"
Content-Language: en-US
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: Wed, 08 Nov 2017 14:51:35 -0000

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



On 08/11/2017 13:26, Ladislav Lhotka wrote:
> Hi Rob,
>
> thank you for the review, my replies are inline.
>
> Robert Wilton  writes:
>
>> Hi,
>>
>> I have read this document and think that is almost ready for publication.
>>
>> I have one general comment regarding the YANG module library (at the
>> end), and a few nits, but otherwise the draft looks good.
>>
>> 1. Sec 1. Introduction paragraph 2, "internal node".  It wasn't
>> absolutely clear to me what an internal node is, so I wonder whether
>> this would be more clear as  "internal (i.e. non root) node".
> Agreed, but probably with a hyphen: "non-root"?
OK.

>
>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
>> Implementation-time ...".  This section states that it is a stable as
>> YANG library, and hence cannot change due to a server reboot. However,
>> YANG library doesn't appear to have that restriction, and hence this
>> doesn't seem to align with RFC 7895, introduction paragraph 2.
> I don't know exactly under what circumstances YANG library can change
> after a reboot, but in such a case schema-mounts data might be subject
> to a change as well. I definitely think that the "run-time" case is
> something else.
A software upgrade could quite reasonably change YANG library without a 
device reboot.  Perhaps saying less is more precise:

E.g.

    2.  Implementation-time: the mounted schema is defined by a server
        implementor and is as stable as YANG library information. Also,
        a client can learn the entire schema together with YANG library data.


Or alternatively, you say that it is at least as stable as the YANG 
library information, and then list when it could change.


>
>> 3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined
>> anywhere (RFC 7950 doesn't define this).  Should it be defined here?
>> The NMDA datastores draft had a similar issue and we choose to define
>> "datastore schema" instead.
> I think the right place for defining the term "schema" (and "data model"
> as well) is the specification of YANG because it is desirable that all
> documents related to YANG use the same meaning.
OK, 7950 doesn't define it today.  Is that a problem?

>
>> 4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.
>> The text "same management session" might be more clear as "same client
>> management protocol session".
> Hmm, I wouldn't say this is more clear - it seems to indicate that we
> are managing the client.
My issue is that "same management session" isn't really that clear to 
what it is referring to.  Perhaps drop the "client" and have "same 
management protocol session"?


>
> But it could also be that such rules are inappropriate in this document and
> rather belong to a protocol spec.
I think that they are OK here if this draft defines the lifetime of the 
schema.  If it is just the same as YANG library, then perhaps this could 
be left to the YANG library spec to specify?

>
>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" =>
>> "are possible, and as such, needs"
> I actually don't understand neither this sentence nor what the point of
> such exceptions could possibly be.
An example would presumably be where effectively the same data is being 
mounted in a separate place.  E.g. the list of physical interfaces in an 
LNE may represent a subset of all physical interfaces in the device, 
that would also be present in the host model.
>
>> 6. Sec 3.2 paragraph 5.  Would it useful to state that even though the
>> schema is the same, the data is different and not necessarily related.
> I think this goes without saying, as it is also the case for a single mount
> point that is a list node - data in each entry is different.
In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally 
separate from the parent data.  For paragraph 5, I still that it is 
useful to state the equivalent that if a schema is mounted twice it 
doesn't mean the same data is mounted in both places.


>
>> 7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "
> Yes.
>
>> 8.  Sec 6 Implementation Notes.  Would this section be better named
>> "Implementation Considerations"?
> Agreed.
>
>> 9. Structure of ietf-yang-schema-mount module:
>>     - Should "uri" under namespace be marked as "mandatory" so that it
>> doesn't appear to be optional in the tree diagram.
> Yes, this is an omission.
>
>>     - Should the "module" name be included under the namespace.  It seems
>> that lots of other "module bindings" are done via the module name rather
>> than the namespace?
> We need it exclusively for XPath, so it seems natural to stay close to XML
> namespaces.
I was suggesting that it might be useful to add "module" in addition to 
namespace.

>
>> 10. Example A.3.  This contains some features that are enabled. Possibly
>> it would be useful in the description to point this out, and state that
>> unless the features are listed they wouldn't be enabled.
> Yes, we reuse the groupings from ietf-yang-library, and the idea is to
> apply the same semantics. And as you are saying below, it would be more
> straightforward to integrate it directly with YANG library.
>
>> My last general comment relates generally to the structure of the
>> Iietf-yang-schema-mount.  As Lada has pointed out previously, this
>> module and YANG library bis could be more closely aligned (e.g. along
>> the lines of reusing module-sets for the "schema" list).  It would have
>> been nice if this module could augment YANG library (so that you can
>> easily get the modules and schema mount information in a single simple
>> request), however that would put an undesired dependency delaying
>> publishing this draft until YANG library bis is completed.
> Of course I agree, but I think the priority should be to make things as
> simple and easy to understand as possible. They are complex enough
> anyway.
Thanks,
Rob


>
> Thanks, Lada
>
>> Thanks,
>> Rob
>>
>>
>> On 20/10/2017 22: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
>>> .
>>>


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


  
    
  
  
    


    

    

    
On 08/11/2017 13:26, Ladislav Lhotka
      wrote:

    

    

      
Hi Rob,

thank you for the review, my replies are inline.

Robert Wilton <rwilton@cisco.com> writes:



      

        
Hi,

I have read this document and think that is almost ready for publication.

I have one general comment regarding the YANG module library (at the 
end), and a few nits, but otherwise the draft looks good.

1. Sec 1. Introduction paragraph 2, "internal node".  It wasn't 
absolutely clear to me what an internal node is, so I wonder whether 
this would be more clear as  "internal (i.e. non root) node".


      

      
Agreed, but probably with a hyphen: "non-root"?

    

    OK.

    

    

      



      

        
2. Sec 1. Introduction, page 4, paragraph starting "2. 
Implementation-time ...".  This section states that it is a stable as 
YANG library, and hence cannot change due to a server reboot. However, 
YANG library doesn't appear to have that restriction, and hence this 
doesn't seem to align with RFC 7895, introduction paragraph 2.


      

      
I don't know exactly under what circumstances YANG library can change
after a reboot, but in such a case schema-mounts data might be subject
to a change as well. I definitely think that the "run-time" case is
something else.

    

    A software upgrade could quite reasonably change YANG library
    without a device reboot.  Perhaps saying less is more precise:

    

    E.g.

    
   2.  Implementation-time: the mounted schema is defined by a server
       implementor and is as stable as YANG library information. Also,
       a client can learn the entire schema together with YANG library data.


    

    Or alternatively, you say that it is at least as stable as the YANG
    library information, and then list when it could change.

    

    

    

      



      

        
3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined 
anywhere (RFC 7950 doesn't define this).  Should it be defined here?  
The NMDA datastores draft had a similar issue and we choose to define 
"datastore schema" instead.


      

      
I think the right place for defining the term "schema" (and "data model"
as well) is the specification of YANG because it is desirable that all
documents related to YANG use the same meaning.

    

    OK, 7950 doesn't define it today.  Is that a problem?

    

    

      



      

        
4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.  
The text "same management session" might be more clear as "same client 
management protocol session".


      

      
Hmm, I wouldn't say this is more clear - it seems to indicate that we
are managing the client.

    

    My issue is that "same management session" isn't really that clear
    to what it is referring to.  Perhaps drop the "client" and have
    "same management protocol session"?

    

    

    

      

But it could also be that such rules are inappropriate in this document and
rather belong to a protocol spec.

    

    I think that they are OK here if this draft defines the lifetime of
    the schema.  If it is just the same as YANG library, then perhaps
    this could be left to the YANG library spec to specify?

    

    

      



      

        
5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" => 
"are possible, and as such, needs"


      

      
I actually don't understand neither this sentence nor what the point of
such exceptions could possibly be.

    

    An example would presumably be where effectively the same data is
    being mounted in a separate place.  E.g. the list of physical
    interfaces in an LNE may represent a subset of all physical
    interfaces in the device, that would also be present in the host
    model.

    

      



      

        
6. Sec 3.2 paragraph 5.  Would it useful to state that even though the 
schema is the same, the data is different and not necessarily related.


      

      
I think this goes without saying, as it is also the case for a single mount
point that is a list node - data in each entry is different.

    

    In Sec 3.2 paragraph 2, it clarifies that the mounted data is
    generally separate from the parent data.  For paragraph 5, I still
    that it is useful to state the equivalent that if a schema is
    mounted twice it doesn't mean the same data is mounted in both
    places.

    

    

    

      



      

        
7. Sec 3.3 last paragraph.  "On the other hand, " => "In addition, "


      

      
Yes.



      

        
8.  Sec 6 Implementation Notes.  Would this section be better named 
"Implementation Considerations"?


      

      
Agreed.



      

        
9. Structure of ietf-yang-schema-mount module:
   - Should "uri" under namespace be marked as "mandatory" so that it 
doesn't appear to be optional in the tree diagram.


      

      
Yes, this is an omission.



      

        
   - Should the "module" name be included under the namespace.  It seems 
that lots of other "module bindings" are done via the module name rather 
than the namespace?


      

      
We need it exclusively for XPath, so it seems natural to stay close to XML
namespaces.

    

    I was suggesting that it might be useful to add "module" in addition
    to namespace.

    

    

      



      

        
10. Example A.3.  This contains some features that are enabled. Possibly 
it would be useful in the description to point this out, and state that 
unless the features are listed they wouldn't be enabled.


      

      
Yes, we reuse the groupings from ietf-yang-library, and the idea is to
apply the same semantics. And as you are saying below, it would be more
straightforward to integrate it directly with YANG library. 



      

        
My last general comment relates generally to the structure of the 
Iietf-yang-schema-mount.  As Lada has pointed out previously, this 
module and YANG library bis could be more closely aligned (e.g. along 
the lines of reusing module-sets for the "schema" list).  It would have 
been nice if this module could augment YANG library (so that you can 
easily get the modules and schema mount information in a single simple 
request), however that would put an undesired dependency delaying 
publishing this draft until YANG library bis is completed.


      

      
Of course I agree, but I think the priority should be to make things as
simple and easy to understand as possible. They are complex enough
anyway.

    

    Thanks,

    Rob

    

    

    

      

Thanks, Lada



      

        
Thanks,
Rob


On 20/10/2017 22: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
.



        

        

      

      

    

    

  


--------------15ADA7E6E82E8D005A208937--


From nobody Wed Nov  8 08:43:35 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA997128B37 for ; Wed,  8 Nov 2017 08:43:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KQc3E6AazIl3 for ; Wed,  8 Nov 2017 08:43:31 -0800 (PST)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 753A6128A32 for ; Wed,  8 Nov 2017 08:43:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 6447726184B; Wed,  8 Nov 2017 17:43:18 +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 zLdWk-TByqgj; Wed,  8 Nov 2017 17:43:16 +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 41665261846; Wed,  8 Nov 2017 17:43:16 +0100 (CET)
Date: Wed, 8 Nov 2017 17:43:14 +0100
From: Kristian Larsson 
To: Kent Watsen 
Cc: "netmod@ietf.org" 
Message-ID: <20171108164314.GA2389@spritelink.se>
References: <66FA526D-19AE-41C1-99FE-670F879796CA@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <66FA526D-19AE-41C1-99FE-670F879796CA@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: Wed, 08 Nov 2017 16:43:34 -0000

On Mon, Nov 06, 2017 at 07:16:11PM +0000, Kent Watsen wrote:
> 
> This closes the Last Call on this document.  There is
> clearly a lot of interest in the publication of an ACL
> model, but there also seems to be significant concern
> for how this model is structured.  It seems that we need
> to spend some more time to ensure the current structure
> is okay.  Based on the result of this discussion, we
> will then judge if this Last Call was successful of not.

I've probably ignited the most recent debate on this model. I'm
sorry for prolonging the process and preventing moving into RFC
but I really am not comfortable with the current structure.

Besides the structure, which is perhaps more subjective, I think
the model contains actual errors. For example, it appears that
there should be stats entries at the interface attachment points
but that data is config true and not config false and the leafref
doesn't match on the acl-type&acl-name so it could point to any
acl-rule!? It's possible to match on conflicting data, like IPv4
and IPv6 or TCP and UDP in the same ACE, which just doesn't make
any sense at all. There is a match on interface but it is not
clear if this is ingress or egress interface. any-acl is empty!?

I am working on a couple of concrete suggestions for making a
more elegant model.

   kll

-- 
Kristian Larsson                                        KLL-RIPE
+46 72 5479985                                kll@spritelink.net


From nobody Wed Nov  8 15:28: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 AC40D127444 for ; Wed,  8 Nov 2017 15:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BJruwW4U-Kzf for ; Wed,  8 Nov 2017 15:28:42 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54421127419 for ; Wed,  8 Nov 2017 15:28:42 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 1C0E61E0AF7 for ; Wed,  8 Nov 2017 16:28:41 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id XbUd1w00J2SSUrH01bUgiG; Wed, 08 Nov 2017 16:28:41 -0700
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=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=OyA3P-psrVQ5wCfCBMUA: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:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc: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=kRQRY4OKl+uUCIywLdnK0TUks8A9wlOFHw4IdhIQJ7o=; b=C/B6l8pYSJIdqpf4gwOGVWeYFn dJeCT/b0Wi/C+jBUqE9Cp4Q4Dsn6fMJFECLUTUp+JPRd3DVrWL+IISvnLvx188px4Sw2x76e+lZjI uyAT211uCgyeofAlKR6meNS2v;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47966 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eCZlt-002oqG-7x for netmod@ietf.org; Wed, 08 Nov 2017 16:28:37 -0700
To: NETMOD Group 
From: Lou Berger 
Message-ID: <532f9a90-d737-05bf-a020-fad454561752@labn.net>
Date: Wed, 8 Nov 2017 18:28:32 -0500
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
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: 1eCZlt-002oqG-7x
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]:47966
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Agenda updated
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 08 Nov 2017 23:28:43 -0000

Please note that the agenda has been reordered to accommodate some
scheduling conflicts.  Please take note:
https://datatracker.ietf.org/meeting/100/materials/agenda-100-netmod/

Lou (and Kent)




From nobody Wed Nov  8 17:58: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 3CF7C124B18; Wed,  8 Nov 2017 17:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level: 
X-Spam-Status: No, score=-3.647 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, URG_BIZ=0.573, 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 L5v0inV1AhuY; Wed,  8 Nov 2017 17:58:22 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28114126FB3; Wed,  8 Nov 2017 17:58:21 -0800 (PST)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSG00847; Thu, 09 Nov 2017 01:58:18 +0000 (GMT)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 9 Nov 2017 01:58:17 +0000
Received: from DGGEML507-MBS.china.huawei.com ([169.254.1.221]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0361.001; Thu, 9 Nov 2017 09:58:07 +0800
From: Jiangyuanlong 
To: "t.petch" , Alex Campbell , "tictoc@ietf.org" 
CC: Xian Liu , Xujinchun , "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTTso91J0wdpBQm0ySMhnhc/8WWaL7pCg3gAzlH4CAAgBFvYAAydiw
Date: Thu, 9 Nov 2017 01:58:06 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB62E74B@dggeml507-mbs.china.huawei.com>
References: <150906887826.22201.5033565145094897903.idtracker@ietfa.amsl.com>,  <3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97@dggeml507-mbx.china.huawei.com> <1509329710965.52658@Aviatnet.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8@dggeml507-mbs.china.huawei.com> <02fb01d35893$2081f160$4001a8c0@gateway.2wire.net>
In-Reply-To: <02fb01d35893$2081f160$4001a8c0@gateway.2wire.net>
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-7"
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.5A03B63B.006F, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 5319eaa9f94f467187d4ff533b086654
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: Thu, 09 Nov 2017 01:58:25 -0000

Tom,

Good to know all your viewpoints. We will add a sentence in Section 2 expla=
ining the logic of YANG style names in this document, maybe put it as a not=
e in the 2nd paragraph (as these names are used in the 3rd paragraph) .=20

Thanks,
Yuanlong

-----Original Message-----
From: t.petch +AFs-mailto:ietfc+AEA-btconnect.com+AF0-=20
Sent: Wednesday, November 08, 2017 9:12 PM
To: Jiangyuanlong+ADs- Alex Campbell+ADs- tictoc+AEA-ietf.org
Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in draf=
t-ietf-tictoc-1588v2-yang-06

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules is w=
oefully weak).

I think too that you are spot on with your terminology+ADs- where IEEE
1588-2008 has an accepted way of working, then that is the right way for th=
is I-D.

One fresh comment arising from that.  You commented earlier that you had de=
parted from IEEE 1588-2008 in changing camel case to the YANG style names, =
with hyphens, and I think that that is a logical choice.  But I would go fu=
rther and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put that=
+ADs- probably Section 2, perhaps immediately before the tree diagram, sinc=
e that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would be =
worth having a concordance of IEEE 1588-2008 names and YANG names+ADs- this=
 was common practice with MIB Modules.

Tom Petch

----- Original Message -----
From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4-
To: +ACI-Alex Campbell+ACI- +ADw-Alex.Campbell+AEA-Aviatnet.com+AD4AOw- +AD=
w-tictoc+AEA-ietf.org+AD4-
Cc: +ACI-Xian Liu+ACI- +ADw-lene.liuxian+AEA-foxmail.com+AD4AOw- +ACI-Xujin=
chun+ACI-
+ADw-xujinchun+AEA-huawei.com+AD4AOw- +ADw-netmod+AEA-ietf.org+AD4-
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


+AD4- Hi Alex,
+AD4-
+AD4- Sorry for a late reply as I spent the last week for an urgent busines=
s
trip.
+AD4- Please see my comments in line with +AFs-YJ+AF0-
+AD4-
+AD4- Thanks,
+AD4- Yuanlong
+AD4-
+AD4- -----Original Message-----
+AD4- From: Alex Campbell +AFs-mailto:Alex.Campbell+AEA-Aviatnet.com+AF0-
+AD4- Sent: Monday, October 30, 2017 10:15 AM
+AD4- To: Jiangyuanlong+ADs- tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Hi,
+AD4- I've reviewed this latest draft and have some more comments.
+AD4-
+AD4- 1. I find the introduction to be unnecessarily wordy+ADs- it feels li=
ke it
was written with a view of not missing any information out, rather than try=
ing to keep it concise.
+AD4-    For example, there is no need to elaborate on YANG data types here=
.
It is also not here to sell YANG.
+AD4-
+AD4- +AFs-YJ+AF0- Yes, we are trying to give some introductory information=
 for an
outsider who may not be familiar with PTP or YANG, and explain why a YANG f=
or PTP is needed. The juicy part of this document is its YANG module, and p=
eople can skip all the other texts if they are familiar with PTP and YANG.
+AD4- Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear message f=
rom the TICTOC chairs to introduce any big changes at this last call stage.
+AD4-
+AD4-
+AD4- OLD:
+AD4-
+AD4-    As a synchronization protocol, IEEE 1588-2008 +AFs-IEEE1588+AF0- i=
s widely
+AD4-    supported in the carrier networks, industrial networks, automotive
+AD4-    networks, and many other applications. It can provide high
+AD4-    precision time synchronization as fine as nano-seconds. The
+AD4-    protocol depends on a Precision Time Protocol (PTP) engine to
+AD4-    decide its own state automatically, and a PTP transportation layer
+AD4-    to carry the PTP timing and various quality messages. The
+AD4-    configuration parameters and state data sets of IEEE 1588-2008 are
+AD4-    numerous.
+AD4-
+AD4-    According to the concepts described in +AFs-RFC3444+AF0-, IEEE 158=
8-2008
+AD4-    itself provides an information model in its normative
+AD4-    specifications for the data sets (in IEEE 1588-2008 clause 8). Som=
e
+AD4-    standardization organizations including the IETF have specified
+AD4-    data models in MIBs (Management Information Bases) for IEEE 1588-
+AD4-    2008 data sets (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0-). The=
se MIBs are
+AD4-    typically focused on retrieval of state data using the Simple
+AD4-    Network Management Protocol (SNMP), furthermore, configuration of
+AD4-    PTP data sets is not considered in +AFs-RFC8173+AF0-.
+AD4-
+AD4-    Some service providers and applications require that the managemen=
t
+AD4-    of the IEEE 1588-2008 synchronization network be flexible and more
+AD4-    Internet-based (typically overlaid on their transport networks).
+AD4-    Software Defined Network (SDN) is another driving factor, which
+AD4-    demands an improved configuration capability of synchronization
+AD4-    networks.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
+AD4-    configuration and state data manipulated by network management
+AD4-    protocols like the Network Configuration Protocol (NETCONF)
+AD4-    +AFs-RFC6241+AF0-. A small set of built-in data types are defined =
in
+AD4-    +AFs-RFC6020+AF0-, and a collection of common data types are furth=
er
+AD4-    defined in +AFs-RFC6991+AF0-. Advantages of YANG include Internet =
based
+AD4-    configuration capability, validation, rollback and so on. All of
+AD4-    these characteristics make it attractive to become another
+AD4-    candidate modeling language for IEEE 1588-2008.
+AD4-
+AD4- NEW:
+AD4-
+AD4-    IEEE 1588-2008 is a time protocol that provides high precision tim=
e
+AD4-    synchronization as fine as nano-seconds.
+AD4-
+AD4-    IEEE 1588-2008 itself provides an information model in its
normative
+AD4-    specifications for the data sets (IEEE 1588-2008 clause 8).
+AD4-    Standard information models (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021=
AS+AF0-) have
been
+AD4-    previously defined as MIBs focused on the retrieval of state data
using
+AD4-    SNMP +AFs-RFC1157+AF0-.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
configuration
+AD4-    and state data manipulated by network management protocols like
NETCONF
+AD4-    +AFs-RFC6241+AF0-.
+AD4-
+AD4- 2. Can we refer to the system as simply PTP rather than IEEE
1588(-2008)?
+AD4- +AFs-YJ+AF0- Advice from IEEE 1588 is, we need to use +ACI-1588-2008+=
ACI- as much as
possible to help clarify that the scope of this YANG is limited to the publ=
ished 1588 standard.
+AD4-
+AD4-
+AD4- 3. There is insufficient spacing here to separate the terms from thei=
r
definitions:
+AD4- OLD
+AD4-
+AD4-    PTP dataset  Structured attributes of clocks (an OC, BC or TC) use=
d
+AD4-    for PTP protocol decisions and for providing values for PTP messag=
e
+AD4-    fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance A PTP implementation in the device (i.e., an OC or BC=
)
+AD4-    represented by a specific PTP dataset.
+AD4-
+AD4- NEW
+AD4-
+AD4-    PTP dataset
+AD4-      Structured attributes of clocks (an OC, BC or TC) used
+AD4-      for PTP protocol decisions and for providing values for PTP
message
+AD4-      fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance
+AD4-      A PTP implementation in the device (i.e., an OC or BC)
+AD4-      represented by a specific PTP dataset.
+AD4- +AFs-YJ+AF0- OK.
+AD4-
+AD4- 4. There's a singular/plural mismatch here:
+AD4-
+AD4-    module. Query and configuration of device wide or port specific
+AD4-    configuration information and clock data set is described for this
+AD4-    version.
+AD4- +AFs-YJ+AF0- Good, we will change 'is' to 'are'.
+AD4-
+AD4- and here:
+AD4-
+AD4-    Query and configuration of clock information include:
+AD4-
+AD4-
+AD4- 5. The choice of uint16 as instance-number limits implementations to
65536 distinct instances.
+AD4-    While I have a hard time imagining a system with more than 65536
PTP instances, I would prefer to avoid imposing arbitrary limits.
+AD4-    I would recommend changing instance-number to a string (and
renaming it to instance-name or just name).
+AD4- +AFs-YJ+AF0- The 1588-2008 supports multiple instances of PTP, but it=
 is
ambiguous in its organization of those PTP instances, especially with regar=
d to management.
+AD4-  In the 1588 new revision, there is an explicit list of PTP instances=
,
and that list is indexed using a number (not name). Thus to align with the =
new revision, we need to keep it instance-number.
+AD4-  If 65536 limit is a concern, how about change it to uint32, any
concerns?
+AD4-
+AD4-
+AD4- 6. I still recommend removing -ds from the YANG element names that
still include it. It doesn't appear to add any value.
+AD4- +AFs-YJ+AF0- Rodney's opinion: the value of using 'ds' is that the 15=
88
document on which this YANG model is based uses +ACI-DefaultDS+ACI- as a te=
rm.
PTP experts even say +ACI-default dee ess+ACI- verbally when referring to t=
his data. If we changed this to just +ACI-default+ACI-, PTP experts might a=
ssume that we are referring to something entirely new to YANG. Thus, to ali=
gn with 1588-2008, the same set of terminologies are used.
+AD4-
+AD4- 7. What+ADs-s the relevance of injection attacks relevant to this YAN=
G
module?
+AD4- +AFs-YJ+AF0- This is a general statement which is applicable to this =
YANG
module and other YANG modules as well.
+AD4- Thanks again,
+AD4- Yuanlong
+AD4-
+AD4- Alex
+AD4-
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-
+AD4- From: netmod +ADw-netmod-bounces+AEA-ietf.org+AD4- on behalf of Jiang=
yuanlong
+ADw-jiangyuanlong+AEA-huawei.com+AD4-
+AD4- Sent: Friday, 27 October 2017 3:21 p.m.
+AD4- To: tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Dear all,
+AD4-
+AD4- Based on all the comments we received during the WG Last Call process=
,
we've updated the document to version 6.
+AD4- We believe all the LC comments are resolved and the consensus is
reflected in this new revision.
+AD4- Many thanks to Martin, Tal, Opher, Alex, John and many others who had
reviewed and commented on this draft.
+AD4-
+AD4- Cheers,
+AD4- Yuanlong on behalf of all coauthors
+AD4-
+AD4- -----Original Message-----
+AD4- From: internet-drafts+AEA-ietf.org +AFs-mailto:internet-drafts+AEA-ie=
tf.org+AF0-
+AD4- Sent: Friday, October 27, 2017 9:48 AM
+AD4- To: Xian Liu+ADs- Rodney Cummings+ADs- rodney.cummings+AEA-ni.com+ADs=
- Jiangyuanlong+ADs-
Xujinchun
+AD4- Subject: New Version Notification for
draft-ietf-tictoc-1588v2-yang-06.txt
+AD4-
+AD4-
+AD4- A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
+AD4- has been successfully submitted by Yuanlong Jiang and posted to the
IETF repository.
+AD4-
+AD4- Name:           draft-ietf-tictoc-1588v2-yang
+AD4- Revision:       06
+AD4- Title:          YANG Data Model for IEEE 1588-2008
+AD4- Document date:  2017-10-26
+AD4- Group:          tictoc
+AD4- Pages:          30
+AD4- URL:
https://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588v2-yang-06.tx
t
+AD4- Status:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
+AD4- Htmlized:
https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-06
+AD4- Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-06
+AD4- Diff:
https://www.ietf.org/rfcdiff?url2+AD0-draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Abstract:
+AD4-    This document defines a YANG data model for the configuration of
+AD4-    IEEE 1588-2008 devices and clocks, and also retrieval of the
+AD4-    configuration information, data set and running states of IEEE
+AD4-    1588-2008 clocks.
+AD4-
+AD4-
+AD4-
+AD4-
+AD4- 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.
+AD4-
+AD4- The IETF Secretariat
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://www.ietf.org/mailman/listinfo/netmod
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Nov  9 07: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 032DE126D74 for ; Thu,  9 Nov 2017 07:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCG_Sq5A20sd for ; Thu,  9 Nov 2017 07:36:54 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B7710126CD6 for ; Thu,  9 Nov 2017 07:36:53 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 620D918215DE; Thu,  9 Nov 2017 16:36:08 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id BB81F1820F78; Thu,  9 Nov 2017 16:36:04 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , "netmod\@ietf.org" , Martin Bjorklund , Kent Watsen 
In-Reply-To: <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com>
Mail-Followup-To: Robert Wilton , "netmod\@ietf.org" , Martin Bjorklund , Kent Watsen 
Date: Thu, 09 Nov 2017 16:37:53 +0100
Message-ID: <87d14rjwdq.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Thu, 09 Nov 2017 15:36:57 -0000

Robert Wilton  writes:

>>
>>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
>>> Implementation-time ...".=C2=A0 This section states that it is a stable=
 as
>>> YANG library, and hence cannot change due to a server reboot. However,
>>> YANG library doesn't appear to have that restriction, and hence this
>>> doesn't seem to align with RFC 7895, introduction paragraph 2.
>> I don't know exactly under what circumstances YANG library can change
>> after a reboot, but in such a case schema-mounts data might be subject
>> to a change as well. I definitely think that the "run-time" case is
>> something else.
> A software upgrade could quite reasonably change YANG library without a=20
> device reboot.=C2=A0 Perhaps saying less is more precise:
>
> E.g.
>
>     2.  Implementation-time: the mounted schema is defined by a server
>         implementor and is as stable as YANG library information. Also,
>         a client can learn the entire schema together with YANG library d=
ata.
>

It seems that neither 7950 nor 7895 defines how stable YANG library data
is. The conclusion might be that it can change any time, which is IMO
hardly acceptable.=20=20

>
> Or alternatively, you say that it is at least as stable as the YANG=20
> library information, and then list when it could change.
>
>
>>
>>> 3. Sec 2.1 Glossary of New Terms:=C2=A0 "Schema" isn't actually defined
>>> anywhere (RFC 7950 doesn't define this).=C2=A0 Should it be defined her=
e?
>>> The NMDA datastores draft had a similar issue and we choose to define
>>> "datastore schema" instead.
>> I think the right place for defining the term "schema" (and "data model"
>> as well) is the specification of YANG because it is desirable that all
>> documents related to YANG use the same meaning.
> OK, 7950 doesn't define it today.=C2=A0 Is that a problem?

"Schema tree" and "schema node" are defined and used a lot in 7950, so
it might be good to define "schema" as well - meaning the schema tree
with all associated semantics.=20

>
>>
>>> 4. Sec 3.2. paragraph 1.=C2=A0 Same comment as 2 above also applies her=
e.
>>> The text "same management session" might be more clear as "same client
>>> management protocol session".
>> Hmm, I wouldn't say this is more clear - it seems to indicate that we
>> are managing the client.
> My issue is that "same management session" isn't really that clear to=20
> what it is referring to.=C2=A0 Perhaps drop the "client" and have "same=20
> management protocol session"?

This probably needs to be coupled somehow with YANG library stability -
if YANG library can change during a session, then schema mounts should
be permitted to change as well.

>
>
>>
>> But it could also be that such rules are inappropriate in this document =
and
>> rather belong to a protocol spec.
> I think that they are OK here if this draft defines the lifetime of the=20
> schema.=C2=A0 If it is just the same as YANG library, then perhaps this c=
ould=20
> be left to the YANG library spec to specify?
>
>>
>>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" =
=3D>
>>> "are possible, and as such, needs"
>> I actually don't understand neither this sentence nor what the point of
>> such exceptions could possibly be.
> An example would presumably be where effectively the same data is being=20
> mounted in a separate place.=C2=A0 E.g. the list of physical interfaces i=
n an=20
> LNE may represent a subset of all physical interfaces in the device,=20
> that would also be present in the host model.

Then I would say simply "..., its data will generally have no
relationship to the data of the parent, unless the data model explicitly
states otherwise."

OK, "data model" is another term that isn't defined, but to me it is the
collection of YANG modules that define the schema. I think it's not
possible to say where the exception has to be stated, it can be
either in the parent or in the mounted module, or even elsewhere.

>>
>>> 6. Sec 3.2 paragraph 5.=C2=A0 Would it useful to state that even though=
 the
>>> schema is the same, the data is different and not necessarily related.
>> I think this goes without saying, as it is also the case for a single mo=
unt
>> point that is a list node - data in each entry is different.
> In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally=20
> separate from the parent data.=C2=A0 For paragraph 5, I still that it is=
=20
> useful to state the equivalent that if a schema is mounted twice it=20
> doesn't mean the same data is mounted in both places.

This should be absolutely clear to anybody who understands that we are
only constructing a schema because, e.g., multiple uses of the same
grouping in YANG also don't mean the same instance data. Unfortunately,
with schema mount this confusion arises again and again, maybe the term
"mount" is really misleading.

...

>>
>>> 9. Structure of ietf-yang-schema-mount module:
>>>   =C2=A0 - Should "uri" under namespace be marked as "mandatory" so tha=
t it
>>> doesn't appear to be optional in the tree diagram.
>> Yes, this is an omission.
>>
>>>   =C2=A0 - Should the "module" name be included under the namespace.=C2=
=A0 It seems
>>> that lots of other "module bindings" are done via the module name rather
>>> than the namespace?
>> We need it exclusively for XPath, so it seems natural to stay close to X=
ML
>> namespaces.
> I was suggesting that it might be useful to add "module" in addition to=20
> namespace.

This is possible but redundant, I was thinking about replacing the URIs
with module names. It probably doesn't really matter unless the URIs are
written by hand.

Lada

>
>>
>>> 10. Example A.3.=C2=A0 This contains some features that are enabled. Po=
ssibly
>>> it would be useful in the description to point this out, and state that
>>> unless the features are listed they wouldn't be enabled.
>> Yes, we reuse the groupings from ietf-yang-library, and the idea is to
>> apply the same semantics. And as you are saying below, it would be more
>> straightforward to integrate it directly with YANG library.
>>
>>> My last general comment relates generally to the structure of the
>>> Iietf-yang-schema-mount.=C2=A0 As Lada has pointed out previously, this
>>> module and YANG library bis could be more closely aligned (e.g. along
>>> the lines of reusing module-sets for the "schema" list).=C2=A0 It would=
 have
>>> been nice if this module could augment YANG library (so that you can
>>> easily get the modules and schema mount information in a single simple
>>> request), however that would put an undesired dependency delaying
>>> publishing this draft until YANG library bis is completed.
>> Of course I agree, but I think the priority should be to make things as
>> simple and easy to understand as possible. They are complex enough
>> anyway.
> Thanks,
> Rob
>
>
>>
>> Thanks, Lada
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 20/10/2017 22: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
>>>> .
>>>>
>
> _______________________________________________
> 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 Thu Nov  9 07:58: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 E8ED712706D for ; Thu,  9 Nov 2017 07:58:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZcP30k49RsN for ; Thu,  9 Nov 2017 07:58:41 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BECFB126557 for ; Thu,  9 Nov 2017 07:58:40 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 9699618215DD; Thu,  9 Nov 2017 16:57:56 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id C20571820F78; Thu,  9 Nov 2017 16:57:53 +0100 (CET)
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: kwatsen@juniper.net, netmod@ietf.org
In-Reply-To: <20171108.135808.522457298716867760.mbj@tail-f.com>
References:  <20171108.095019.1523851923210652414.mbj@tail-f.com> <1510136247.17913.33.camel@nic.cz> <20171108.135808.522457298716867760.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , kwatsen@juniper.net, netmod@ietf.org
Date: Thu, 09 Nov 2017 16:59:43 +0100
Message-ID: <87a7zvjvdc.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] review of 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: Thu, 09 Nov 2017 15:58:43 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> On Wed, 2017-11-08 at 09:50 +0100, Martin Bjorklund wrote:
>> > Kent Watsen  wrote:
>> > > 
>> > > 
>> > > > Hi Kent,
>> > > >
>> > > > thanks for the thorough review, see my responses inline.
>> > > 
>> > > Hi Lada, please see below.
>> > > 
>> > > 
>> > > >> 1. From Section 4:
>> > > >>
>> > > >>    Routing configuration inside an NI often needs to refer to interfaces (at
>> > > >>    least those that are assigned to the NI), which is impossible unless such
>> > > >>    a reference can point to a node in the parent schema (interface name).
>> > > >>
>> > > >> This seems overstated.  Rather it is a result of an earlier design decision.
>> > > >> An alternate solution might have exported the global interfaces into a 
>> > > >> config false list inside the mount jail.   Was such a solution
>> > > >> discussed?
>> > 
>> > Actually, this wouldn't work, since config true leafrefs/xpaths can't
>> > refer to this "config false" list inside the mount jail.
>> > 
>> > Besides, even a symlink approach would in fact allow for "such a
>> > reference to point to a node in the parent schema tree".
>> > 
>> > > > Do you mean something like having "symlinks" to interfaces inside the
>> > > > mount jail? Yes, this was discussed and rejected. According to Martin,
>> > > > tail-f had made a very bad experience with this approach.
>> > > 
>> > > Yes, a little bit like a symlink inside the mount jail.  Good to hear
>> > > that it was discussed.  I still think the above "impossible" word is
>> > > overstating things.  Perhaps s/impossible such/possible when/?
>> > 
>> > See above; I think the current text is correct.
>> > 
>> > The point is that *somehow* the solution needs to allow for these
>> > kinds of references; symlinks could be one solution, the
>> > "parent-reference" that we use is another solution.
>> 
>> I agree, and also we don't want to make such nodes protocol-accessible in the
>> mounted tree.
>> 
>> > 
>> > > >> 3. Also from Section 4 (same paragraph):
>> > > >>
>> > > >>    For the purposes of
>> > > >>    evaluating XPath expressions within the mounted data tree, the union
>> > > >>    of all such nodesets is added to the accessible data tree.
>> > > >>
>> > > >> Could this ever result in name collision?
>> > > >
>> > > > Potentially yes, but sibling nodes with the same name are not an issue
>> > > > for XPath evaluation. 
>> > > 
>> > > I don't know if I agree that it can't be an issue.  What if the module
>> > > has a top-level /widgets container, and there is a parent-reference to
>> > > a /widgets container
>> > 
>> > The nodes exist in a namespace.  So if you have /widgets in two
>> > different modules there is no issue.  However, if you mount a module A
>> > and at the same time provide A's toplevel nodes as parent references
>> > then you might have a problem - or not!  The document defines what
>> > happens in this case (the result is the union).   Also note that
>> > constructing the set of mounted modules and corresponding
>> > parent-references is up to the implementation.
>> 
>> This is fine with must expressions but actually leafrefs are defined so that the
>> leaf instance being referred to has to be unique.
>
> I'm not sure what you refer to, but in general a leafref can refer to
> more than one node:
>
>    The "path" expression evaluates to a node set consisting of zero,
>    one, or more nodes.  If the "require-instance" property is "true",
>    this node set MUST be non-empty.
>

OK, I wasn't aware of this. The text in other places indicates
uniqueness, e.g.

- The "path" substatement (Section 9.9.2) is used to identify the
  referred leaf or leaf-list node ... (sec. 9.9)

- The predicates are only used when more than one key reference is
  needed to uniquely identify a leaf instance. (sec. 9.9.2)

>
>> This needn't be the case here
>> - I don't know if it matters.
>> 
>> > 
>> > > >> Also, should how NACM interacts with mounted instance data be
>> > > >> specified?
>> > > >
>> > > > This is a good question because, in principle, top-level NACM rules
>> > > > can address instances of mounted schemas. On the other hand,
>> > > > ietf-netconf-acm can also be a part of the mounted schema - and if
>> > > > so, can its rules also address instances in the parent schema via
>> > > > the parent-reference mechanism?
>> > > >
>> > > > But I would say it is up to rfc6536bis to deal with these questions.
>> > > 
>> > > I don't know, but it seems that this draft is introducing the concept.
>> > > Not to mention, rfc6536bis is already with the IESG.  In either case,
>> > > let's work out what it means and then decide which draft it needs to
>> > > go into.
>> > 
>> > I think NACM in the parent node should cover access to the mounted
>> > data.  For example, it should be possible to have a rule for:
>> > 
>> >  /network-instances/network-instance[name='foo']/vrf-root/rt:routing
>> 
>> Do you mean that NACM can only be used at the top level? What if it is also part
>> of the mounted schema?
>
> I don't think that we can/should require that a server that mounts
> nacm has to enforce the nacm rules in the mount jail.
>
> One reason for mounting nacm would be "peer mount" where you mount all
> models some other device supports.  In this case that other device
> will of course enfore the nacm rules, but in the parent node these
> nacm rules don't mean anything.

OK.

>
>
>> > > >> 5. This document does not say anything about how it relates to NMDA.
>> > > >> Clearly all this is targeted to the conventional datastores
>> > 
>> > No, or maybe I don't understand what you mean.  Schema mount allows
>> > for mounting config false nodes, or even doing a "read-only" mount.
>> > Such a mount is clearly not available in the conventional datastores.
>> > 
>> > >, but how
>> > > >> is it reflected in e.g., ?  Does anything need to be said
>> > > >> here?
>> > > >
>> > > > The "use-schema" case shouldn't pose big problems because it is
>> > > > essentially an externally specified augment. The "inline" case is
>> > > > somewhat disturbing though: could the embedded YANG library instances
>> > > > be different in different datastores?
>> > > 
>> > > YANG Library is only available in  (it's all config false).
>> 
>> OK, so if I have a mount point of the "inline" type in  or ,
>> I have to go to , find the corresponding instance of the mount
>> point (if it's there)
>
> It is, per the latest discussions, where we say that the schema for
> operational is a superset of the schema for the config.

But this is not about the schema - you have to find the *instance* of the
mount point and grab YANG library data from there. But if that instance
isn't in  (which is IMO possible), you are out of luck.

Again, this mixing of instance data and YANG library (representing the
schema) is problematic.

Lada

>
>>, and read the YANG library data below it to learn the
>> schema in ?
>
> Sure, and this is how it would work in pre-NMDA as well, to learn the
> schema for  for example.
>
>
>
> /martin
>
>
>
>> What if the mount point is inactive configuration? Then
>> the mounted schema probably cannot be determined at all.
>> 
>> > > I think you mean the embedded YANG Library instances under the mount 
>> > > points.  Yes, you may have a problem here.  Still, this isn't my question,
>> > > is more about schema-mounting requirements across datastores.  E.g., if
>> > > a schema-mount exists in , must it existing in  and
>> > >  as well?  Conversely, if a schema-mount exists in
>> > > , must it exist in ?  I think this draft should
>> > > clarify such things.
>> 
>> I am really confused: what do you mean by saying that "schema-mount exists"? Do
>> you mean "mount point exists"? If so, as long as the mount point is config=true,
>> it has to exist in all datastores (I assume). 
>> 
>> > 
>> > I agree that this needs to be clarified.  This issue partly comes from
>> > the fact that schema mount uses the groupings in the old yang
>> > library.  I think we need to use the new groupings from rfc7895bis.
>> 
>> YANG started basically as a document-oriented schema language (and schema mount
>> adheres to this view). NMDA tries to extrapolate its use to multiple documents
>> with differents schemas. My gut feeling is that this is not going to work - the
>> complexity will be overwhelming.
>> 
>> Lada
>> 
>> > 
>> > 
>> > > >> What if the mounted schema has deviations in .
>> > > >
>> > > > I don't understand why this could be an issue.
>> > > 
>> > > I'm not saying it's a problem yet.  I'm just stating that such things
>> > > can occur and it's unclear that, if they do, could it cause problems.
>> > > For instance, a mounted schema may be looking for a parent reference
>> > > that doesn't exist because of a deviation.
>> > > 
>> > > 
>> > > 
>> > > 
>> > > >> Nits (line-break separated):
>> > > >>
>> > > >> Is "other optional choices" being vague on purpose?  Should it just
>> > > >> call out features and deviations?
>> > > >
>> > > >Yes, it should.
>> > > >
>> > > >>
>> > > >> "the YANG library data" seems odd.  Maybe "the instance of the YANG
>> > > >> Library module"?
>> > > >
>> > > > It is the same but I prefer the former. Note that the term "instance"
>> > > > is not defined in RFC 7950.
>> > > 
>> > > okay
>> > > 
>> > > 
>> > > >> - document, and could be possibly dealt with in a future revision of the YANG data modeling language
>> > > >> + document, as it needs to be dealt with as an update to the YANG data modeling language
>> > > >
>> > > > I am not sure that it *needs* to be done, because it could have
>> > > > far-reaching consequences.
>> > > 
>> > > Here I'm using "needs" not to mean that it "has to be done" but more that,
>> > > if it is done, it would have to be done in an update to the YANG data 
>> > > modeling language.  The current sentence seems too open-ended...
>> > > 
>> > > 
>> > > >> - Schema mount applies to the data model
>> > > >> + Schema mount regards the data model
>> > > >
>> > > > OK
>> > > >
>> > > >>
>> > > >> - This document allows mounting of complete data models only.
>> > > >> + This document allows mounting of complete modules only.
>> > > >
>> > > > Correct
>> > > >
>> > > >
>> > > >> - may extend this model by defining
>> > > >> + may extend this solution by defining
>> > > >
>> > > > Or perhaps "approach"? I would leave "solution" to marketing folks.
>> > > 
>> > > "approach" is fine.
>> > > 
>> > > 
>> > > >> In S3, replace "YANG 1.1" with "YANG 1.1 and its continuances"?
>> > > >
>> > > > Not sure. For example, next version of YANG can/should turn "mount-point"
>> > > > into a built-in statement.
>> > > 
>> > > So then, when we define yang-next, we'd be forced to either incorporate
>> > > schema-mount or simultaneously publish an update to this RFC to allow
>> > > it to work with the new version of YANG?  Even if YANG-next defined a
>> > > built-in equilvalent, would we not want this mechanism to continue to
>> > > be supported, for backwards compatibility?
>> > > 
>> > > 
>> > > >> - A "container" or "list" node
>> > > >> + A 'container' or 'list' node
>> > > >
>> > > > Actually, following RFC 7950 conventions, no quotes should be used here.
>> > > >
>> > > 
>> > > I'm confused about these conventions - are they written down somewhere.
>> > > In Martin's review of zerotouch draft, he dinged me on my mis-use of
>> > > single-quotes, for the second time.  Looking at RFC 7950, I don't see
>> > > the convention listed anywhere, or are you saying that the convention
>> > > is throughout the RFC and folks are expected to implicitly understand
>> > > what it is?
>> > 
>> > I think you just should be consistent; if you attach some semantic
>> > meaning to single quotes vs double quotes the document needs to
>> > explain that meaning.  If it is just for quotation, be consistent.  I
>> > think the RFC editor prefers double quotes (but I can't find a
>> > reference to this).
>> > 
>> > As for the term container; this is a term for an interior node,
>> > defined in 7950, so it is used w/o quotes.   Compare with references
>> > to the "container" statement.
>> > 
>> > 
>> > 
>> > 
>> > /martin
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 

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


From nobody Thu Nov  9 08:35: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 1E488127601 for ; Thu,  9 Nov 2017 08:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRAm7FrPMwkz for ; Thu,  9 Nov 2017 08:34:56 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0721274A5 for ; Thu,  9 Nov 2017 08:34:56 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id n69so7919830lfn.2 for ; Thu, 09 Nov 2017 08:34:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=GmatFxGvZVbMdptg7pNxBnZ/07THF+Hl8RG2wXMM0c0=; b=b4Jf7rNXEOGFHT8s/j+wejQoPd70BMXO1gPJRl/QTIre6MtNle3NmkmK1d30oN4K0M fTCutwlNRIks69HQtnPXQuUGNGZCIQUDzXmWoFtBN9wwgAyZbnWdp1LcFAtRJ1DwRfTS JtKJB06JajX02iA79qs7mpjNztLAS8Qz6zv9EUdTqvd2990mMTxywJbX0z4VhKh+zoY0 QXIchiVOOaHGqFNXV8sug3s3/AxlqkQ7L5e+ivD1wHaN98SgSpCflfPnmHEYH3SZnLO7 PiYphIfCFW9wcNwJ7A/MXimODm62YgohTmqMwDKLgS2jRrEO4Gz3gqhtNYpEBfy6zQyY FuPw==
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=GmatFxGvZVbMdptg7pNxBnZ/07THF+Hl8RG2wXMM0c0=; b=ZJNtMSMUHg2lNDhZeRoErVlNaYXIJfWXYd/AcGhQarE/gBFVqJAVWdlmipGEM57dsN 8X2UfgmUHb1b1rqyJ6p/zjAqego7BrUZcp99feqt44qDW49JyvnXiDTA44QlH1U407MH xGmUfPthJz3CSg/r0F2oKIcQDQXS+Rqfq3Yhu464oaWRG1IibJK2OIZjEljP8Z9dorGZ CZbJrvOqbEgAaL+avMLRzOszNj47PQo33xH3t6dtw7wHx7t/WIu8MPN//awOzgTHnElW ds15D5Oam1FL8F1ITMYyZKc5zRH/16qFWEI4SlAR/aMU4FAY/s2/gwvBYyfyEGL4K9gh QVFg==
X-Gm-Message-State: AJaThX6p7UKG719n//7PgcSEAXHJ2UK6ybheyCk9JwlVF4apPua43JI/ /SnJCWej1lToQgdByuk3Bwak3aFGk73pbG56PEx5cQ==
X-Google-Smtp-Source: ABhQp+RQ2O68Nc2xFncTwxvqAUe1/UXB2IJd0vRS2oMEvREQP/ReOYVuru/32Wnq71+0oLJpC1dOqrhJ4UCTuvpnI/Y=
X-Received: by 10.46.101.4 with SMTP id z4mr447710ljb.42.1510245294217; Thu, 09 Nov 2017 08:34:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 9 Nov 2017 08:34:52 -0800 (PST)
In-Reply-To: <87d14rjwdq.fsf@nic.cz>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz>
From: Andy Bierman 
Date: Thu, 9 Nov 2017 08:34:52 -0800
Message-ID: 
To: Robert Wilton , "netmod@ietf.org" ,  Martin Bjorklund , Kent Watsen 
Content-Type: multipart/alternative; boundary="001a114d31ea495b55055d8f626e"
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: Thu, 09 Nov 2017 16:35:00 -0000

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

On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka  wrote:

> Robert Wilton  writes:
>
> >>
> >>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
> >>> Implementation-time ...".  This section states that it is a stable as
> >>> YANG library, and hence cannot change due to a server reboot. However,
> >>> YANG library doesn't appear to have that restriction, and hence this
> >>> doesn't seem to align with RFC 7895, introduction paragraph 2.
> >> I don't know exactly under what circumstances YANG library can change
> >> after a reboot, but in such a case schema-mounts data might be subject
> >> to a change as well. I definitely think that the "run-time" case is
> >> something else.
> > A software upgrade could quite reasonably change YANG library without a
> > device reboot.  Perhaps saying less is more precise:
> >
> > E.g.
> >
> >     2.  Implementation-time: the mounted schema is defined by a server
> >         implementor and is as stable as YANG library information. Also,
> >         a client can learn the entire schema together with YANG library
> data.
> >
>
> It seems that neither 7950 nor 7895 defines how stable YANG library data
> is. The conclusion might be that it can change any time, which is IMO
> hardly acceptable.
>


Actually, the YANG library is allowed to change at any time.
Clients use the module-set-id and the yang-library-change notification
to keep their cached copy of the server's library up to date.



Andy



> >
> > Or alternatively, you say that it is at least as stable as the YANG
> > library information, and then list when it could change.
> >
> >
> >>
> >>> 3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined
> >>> anywhere (RFC 7950 doesn't define this).  Should it be defined here?
> >>> The NMDA datastores draft had a similar issue and we choose to define
> >>> "datastore schema" instead.
> >> I think the right place for defining the term "schema" (and "data model"
> >> as well) is the specification of YANG because it is desirable that all
> >> documents related to YANG use the same meaning.
> > OK, 7950 doesn't define it today.  Is that a problem?
>
> "Schema tree" and "schema node" are defined and used a lot in 7950, so
> it might be good to define "schema" as well - meaning the schema tree
> with all associated semantics.
>
> >
> >>
> >>> 4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.
> >>> The text "same management session" might be more clear as "same client
> >>> management protocol session".
> >> Hmm, I wouldn't say this is more clear - it seems to indicate that we
> >> are managing the client.
> > My issue is that "same management session" isn't really that clear to
> > what it is referring to.  Perhaps drop the "client" and have "same
> > management protocol session"?
>
> This probably needs to be coupled somehow with YANG library stability -
> if YANG library can change during a session, then schema mounts should
> be permitted to change as well.
>
> >
> >
> >>
> >> But it could also be that such rules are inappropriate in this document
> and
> >> rather belong to a protocol spec.
> > I think that they are OK here if this draft defines the lifetime of the
> > schema.  If it is just the same as YANG library, then perhaps this could
> > be left to the YANG library spec to specify?
> >
> >>
> >>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs"
> =>
> >>> "are possible, and as such, needs"
> >> I actually don't understand neither this sentence nor what the point of
> >> such exceptions could possibly be.
> > An example would presumably be where effectively the same data is being
> > mounted in a separate place.  E.g. the list of physical interfaces in an
> > LNE may represent a subset of all physical interfaces in the device,
> > that would also be present in the host model.
>
> Then I would say simply "..., its data will generally have no
> relationship to the data of the parent, unless the data model explicitly
> states otherwise."
>
> OK, "data model" is another term that isn't defined, but to me it is the
> collection of YANG modules that define the schema. I think it's not
> possible to say where the exception has to be stated, it can be
> either in the parent or in the mounted module, or even elsewhere.
>
> >>
> >>> 6. Sec 3.2 paragraph 5.  Would it useful to state that even though the
> >>> schema is the same, the data is different and not necessarily related.
> >> I think this goes without saying, as it is also the case for a single
> mount
> >> point that is a list node - data in each entry is different.
> > In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally
> > separate from the parent data.  For paragraph 5, I still that it is
> > useful to state the equivalent that if a schema is mounted twice it
> > doesn't mean the same data is mounted in both places.
>
> This should be absolutely clear to anybody who understands that we are
> only constructing a schema because, e.g., multiple uses of the same
> grouping in YANG also don't mean the same instance data. Unfortunately,
> with schema mount this confusion arises again and again, maybe the term
> "mount" is really misleading.
>
> ...
>
> >>
> >>> 9. Structure of ietf-yang-schema-mount module:
> >>>     - Should "uri" under namespace be marked as "mandatory" so that it
> >>> doesn't appear to be optional in the tree diagram.
> >> Yes, this is an omission.
> >>
> >>>     - Should the "module" name be included under the namespace.  It
> seems
> >>> that lots of other "module bindings" are done via the module name
> rather
> >>> than the namespace?
> >> We need it exclusively for XPath, so it seems natural to stay close to
> XML
> >> namespaces.
> > I was suggesting that it might be useful to add "module" in addition to
> > namespace.
>
> This is possible but redundant, I was thinking about replacing the URIs
> with module names. It probably doesn't really matter unless the URIs are
> written by hand.
>
> Lada
>
> >
> >>
> >>> 10. Example A.3.  This contains some features that are enabled.
> Possibly
> >>> it would be useful in the description to point this out, and state that
> >>> unless the features are listed they wouldn't be enabled.
> >> Yes, we reuse the groupings from ietf-yang-library, and the idea is to
> >> apply the same semantics. And as you are saying below, it would be more
> >> straightforward to integrate it directly with YANG library.
> >>
> >>> My last general comment relates generally to the structure of the
> >>> Iietf-yang-schema-mount.  As Lada has pointed out previously, this
> >>> module and YANG library bis could be more closely aligned (e.g. along
> >>> the lines of reusing module-sets for the "schema" list).  It would have
> >>> been nice if this module could augment YANG library (so that you can
> >>> easily get the modules and schema mount information in a single simple
> >>> request), however that would put an undesired dependency delaying
> >>> publishing this draft until YANG library bis is completed.
> >> Of course I agree, but I think the priority should be to make things as
> >> simple and easy to understand as possible. They are complex enough
> >> anyway.
> > Thanks,
> > Rob
> >
> >
> >>
> >> Thanks, Lada
> >>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>> On 20/10/2017 22: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
> >>>> .
> >>>>
> >
> > _______________________________________________
> > 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
>

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




On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka <<=
a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:
Robert Wilton <rwilton@cisco.com> writes:



>>

>>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
>>> Implementation-time ...".=C2=A0 This section states that =
it is a stable as

>>> YANG library, and hence cannot change due to a server reboot. =
However,

>>> YANG library doesn't appear to have that restriction, and =
hence this

>>> doesn't seem to align with RFC 7895, introduction paragrap=
h 2.

>> I don't know exactly under what circumstances YANG library can=
 change

>> after a reboot, but in such a case schema-mounts data might be sub=
ject

>> to a change as well. I definitely think that the "run-time&qu=
ot; case is

>> something else.

> A software upgrade could quite reasonably change YANG library without =
a

> device reboot.=C2=A0 Perhaps saying less is more precise:

>

> E.g.

>

>=C2=A0 =C2=A0 =C2=A02.=C2=A0 Implementation-time: the mounted schema is=
 defined by a server

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementor and is as stable as YANG =
library information. Also,

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a client can learn the entire schema =
together with YANG library data.

>



It seems that neither 7950 nor 7895 defines how stable YANG library data
is. The conclusion might be that it can change any time, which is IMO

hardly acceptable.


Actua=
lly, the YANG library is allowed to change at any time.
Clients u=
se the module-set-id and the yang-library-change notification
to =
keep their cached copy of the server's library up to date.


Andy




>

> Or alternatively, you say that it is at least as stable as the YANG
> library information, and then list when it could change.

>

>

>>

>>> 3. Sec 2.1 Glossary of New Terms:=C2=A0 "Schema" isn=
't actually defined

>>> anywhere (RFC 7950 doesn't define this).=C2=A0 Should it b=
e defined here?

>>> The NMDA datastores draft had a similar issue and we choose to=
 define

>>> "datastore schema" instead.

>> I think the right place for defining the term "schema" (=
and "data model"

>> as well) is the specification of YANG because it is desirable that=
 all

>> documents related to YANG use the same meaning.

> OK, 7950 doesn't define it today.=C2=A0 Is that a problem?



"Schema tree" and "schema node" are defined and used a =
lot in 7950, so

it might be good to define "schema" as well - meaning the schema =
tree

with all associated semantics.



>

>>

>>> 4. Sec 3.2. paragraph 1.=C2=A0 Same comment as 2 above also ap=
plies here.

>>> The text "same management session" might be more cle=
ar as "same client

>>> management protocol session".

>> Hmm, I wouldn't say this is more clear - it seems to indicate =
that we

>> are managing the client.

> My issue is that "same management session" isn't really =
that clear to

> what it is referring to.=C2=A0 Perhaps drop the "client" and=
 have "same

> management protocol session"?



This probably needs to be coupled somehow with YANG library stability -

if YANG library can change during a session, then schema mounts should

be permitted to change as well.



>

>

>>

>> But it could also be that such rules are inappropriate in this doc=
ument and

>> rather belong to a protocol spec.

> I think that they are OK here if this draft defines the lifetime of th=
e

> schema.=C2=A0 If it is just the same as YANG library, then perhaps thi=
s could

> be left to the YANG library spec to specify?

>

>>

>>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and=
 such needs" =3D>

>>> "are possible, and as such, needs"

>> I actually don't understand neither this sentence nor what the=
 point of

>> such exceptions could possibly be.

> An example would presumably be where effectively the same data is bein=
g

> mounted in a separate place.=C2=A0 E.g. the list of physical interface=
s in an

> LNE may represent a subset of all physical interfaces in the device,
> that would also be present in the host model.



Then I would say simply "..., its data will generally have no

relationship to the data of the parent, unless the data model explicitly
states otherwise."



OK, "data model" is another term that isn't defined, but to m=
e it is the

collection of YANG modules that define the schema. I think it's not

possible to say where the exception has to be stated, it can be

either in the parent or in the mounted module, or even elsewhere.



>>

>>> 6. Sec 3.2 paragraph 5.=C2=A0 Would it useful to state that ev=
en though the

>>> schema is the same, the data is different and not necessarily =
related.

>> I think this goes without saying, as it is also the case for a sin=
gle mount

>> point that is a list node - data in each entry is different.

> In Sec 3.2 paragraph 2, it clarifies that the mounted data is generall=
y

> separate from the parent data.=C2=A0 For paragraph 5, I still that it =
is

> useful to state the equivalent that if a schema is mounted twice it
> doesn't mean the same data is mounted in both places.



This should be absolutely clear to anybody who understands that we are

only constructing a schema because, e.g., multiple uses of the same

grouping in YANG also don't mean the same instance data. Unfortunately,=


with schema mount this confusion arises again and again, maybe the term

"mount" is really misleading.



...



>>

>>> 9. Structure of ietf-yang-schema-mount module:

>>>=C2=A0 =C2=A0=C2=A0 - Should "uri" under namespace be=
 marked as "mandatory" so that it

>>> doesn't appear to be optional in the tree diagram.

>> Yes, this is an omission.

>>

>>>=C2=A0 =C2=A0=C2=A0 - Should the "module" name be inc=
luded under the namespace.=C2=A0 It seems

>>> that lots of other "module bindings" are done via th=
e module name rather

>>> than the namespace?

>> We need it exclusively for XPath, so it seems natural to stay clos=
e to XML

>> namespaces.

> I was suggesting that it might be useful to add "module" in =
addition to

> namespace.



This is possible but redundant, I was thinking about replacing the URIs

with module names. It probably doesn't really matter unless the URIs ar=
e

written by hand.



Lada



>

>>

>>> 10. Example A.3.=C2=A0 This contains some features that are en=
abled. Possibly

>>> it would be useful in the description to point this out, and s=
tate that

>>> unless the features are listed they wouldn't be enabled.
>> Yes, we reuse the groupings from ietf-yang-library, and the idea i=
s to

>> apply the same semantics. And as you are saying below, it would be=
 more

>> straightforward to integrate it directly with YANG library.

>>

>>> My last general comment relates generally to the structure of =
the

>>> Iietf-yang-schema-mount.=C2=A0 As Lada has pointed out previou=
sly, this

>>> module and YANG library bis could be more closely aligned (e.g=
. along

>>> the lines of reusing module-sets for the "schema" li=
st).=C2=A0 It would have

>>> been nice if this module could augment YANG library (so that y=
ou can

>>> easily get the modules and schema mount information in a singl=
e simple

>>> request), however that would put an undesired dependency delay=
ing

>>> publishing this draft until YANG library bis is completed.

>> Of course I agree, but I think the priority should be to make thin=
gs as

>> simple and easy to understand as possible. They are complex enough=


>> anyway.

> Thanks,

> Rob

>

>

>>

>> Thanks, Lada

>>

>>> Thanks,

>>> Rob

>>>

>>>

>>> On 20/10/2017 22: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 docu=
ment

>>>> 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/listi=
nfo/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




--001a114d31ea495b55055d8f626e--


From nobody Thu Nov  9 09:00: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 DDC3E127868 for ; Thu,  9 Nov 2017 09:00:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.11
X-Spam-Level: 
X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 0yXiG0l_aep8 for ; Thu,  9 Nov 2017 09:00:02 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB69612785F for ; Thu,  9 Nov 2017 09:00:01 -0800 (PST)
X-AuditID: c1b4fb2d-d4f0b9c0000002b9-fc-5a04898f5e92
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CD.92.00697.F89840A5; Thu,  9 Nov 2017 17:59:59 +0100 (CET)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 9 Nov 2017 17:59:59 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T0bSX8cm0AtlPZwGPaevNe+pGOngZh63lgCiR0cPkzM=; b=Ir7BGRZBLi6A74fYcndhmNr8qAu4ORMLxb1OneQUnaet6+s/Z5GzwqT2YBlp5KThOYxvRevQoFViTzrjqawJG/Tgy7fcAGStaDRTaXmznv5esGvdVT9/Bmeve9ZBeMG312hbICq/zqqGLOcTO6DB1TSIesxiqnDnwqWw3otV/dE=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [159.107.197.147] (91.82.100.59) by VI1PR07MB3438.eurprd07.prod.outlook.com (2603:10a6:802:24::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Thu, 9 Nov 2017 16:59:57 +0000
To: "netmod@ietf.org" 
From: Balazs Lengyel 
Message-ID: <01a4beef-4a86-fa10-dc81-7dd57e12a9a8@ericsson.com>
Date: Thu, 9 Nov 2017 17:59:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; 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
X-Originating-IP: [91.82.100.59]
X-ClientProxiedBy: HE1PR0902CA0003.eurprd09.prod.outlook.com (2603:10a6:3:e5::13) To VI1PR07MB3438.eurprd07.prod.outlook.com (2603:10a6:802:24::12)
X-MS-Office365-Filtering-Correlation-Id: c566f035-b501-4306-55e1-08d527934f03
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:VI1PR07MB3438; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 3:tcMmnPzXa0KZAUvVob7U5ZDABSLSS5NuP7G4FLFtsKUeuhjLwr04wMMI2fDgDvRpGgrFW6YJGn/Xd2+OJ8ueslnOQnR9mnr3GJ/pNA7/FzhF5dtpeSarS+y6+xsm4SjkjYfdsIDKQG5bUdp0cStWOuq/QitgNThYgFw2/im8EsFFvTjw7iC/p2zVEpsPNYyQH3Up7zZvCigkThDMFIECCIm5r1jnscBAb+viX1QPIyrjXRVKX7iliICSRoXsyVp8; 25:jWq6cF/9+dUZt7Y5ifJsJjir796nuupK/ItZcEr2MoJ8vaW9FPqM8bFh41BU6/6tdN3D0BV5tXZVrEW3hNwXrFtfXqoFphyQLRnUQav3BSyFqgyOP8wG82l26IP7AnN9h7Svff3nWTlNrSf72ixg8nuECwvZKEct1rcDITcYJ2swcrGwih8Onc9qzc0s1vX4/81pWacaj7P4IX2HE68UKLxrHgYzYdXhrbeJc36y1RU6sHP3uDfO6OOMmfry2mWub3RmxUU0DZf1f+Zb91zDEhwuXMR492fCCXMs2Qyr4iqXR/Q2xvDf+FCRHNkfITzITmXbMAV9wNmyqF9PrImFbw==; 31:FHO3bnarp+BzD42d9QiSDn2hekUp8FtPKsRF+Y4auEUTahDtrQY0hS87GoOj/ZAieHxIOV0dJ8b2Tym7suXS0ZX3523uoCd9BRggbc4g5ZSFE9ekNp6CHBLC/Z18Xh9EFybav/lShRI4xKuKZVKQhl0nFiQdvANCOhU1aIbvY7R5LaM+oSI/9Kf6JQS1y07/poYVDuU9rV8r81zQcZmu08ksKOgvenmQdaO0OgxZTP4=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VI1PR07MB3438:
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 20:2BzzWtKxXj5vRy9a+sYtgz7draXzyRilrypHkctKY0zrnMYn0bcQ7y2KKvl74FPnyt6iMx4DXGw8FRSFbYUxjowQllGuMREJLvppaMQrcf4vXHYway253608IeC2KENKzJK8pfeuhycCpif4IkUhZ5f7aHT5c9Im/0TtkYd8+G1w98dcFzcGUILXaiDYsYqe9OLopAMVPhwEG7xBlCC1+Ybjk/lZxitkb3rRdUYNhqIw0Fn7v2BwF1AnTuyLqxp4UqrLTaeqAyR2EP/ida5KiofphNGw0JxcKagEIrbnujk+4MbINjvddlAN62lAfOscu0aY4bKKkgGC0mbUXANZ6QkU+vbkNmurhCmsdWmnMyeXDpWFtGHcE2sw8jTEQSPp0yWEOhlua3eCBfifo7mOvA+/glnvDTKsF4ZLL9HEDfUVpp4/BW2qcnNpMp9pZVRNXXpcs/pi0QyaDsJAewNeNVAo3SF2iAKNuIzURoMFYSTInwoG4Xkzhl22mA+HZlZU; 4:vRgwBochQ81IPSUX4M0tekmImSnGgj/SF26T10eT8olXKyb5IqPbZL1w4SDQQJctRL78FjI3wwwaZu3dU6vC3F9VyKQMme6oN7QpUpPEhKaKIk988dZbCP5+/YNTPR5xmjaJlrmM5GYW16Ahy5wLqNG9jjrCiW4bPSVM88ZRsK6Ah3noBXCQkZVdAnXR6KJmiWmk2lN1sJKBOZMagUfyifIGcyLipMLVOx4SIT3fvT4Qxzy5W4lGmfw9otOdaBL4S6hCP34DRhOjQ8jkv6lJQyROQD6y9ClszM8Mo0rPAUCXMuFXj8yJHdgcTpii0D01oREqoVl7aXmDzxOWtSAmamQVKOUFcvfdR+fPG6bApv0=
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(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)(3231021)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3438; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3438; 
X-Forefront-PRVS: 0486A0CB86
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(6009001)(346002)(376002)(39860400002)(189002)(252514010)(199003)(65956001)(16576012)(101416001)(25786009)(31686004)(5640700003)(6666003)(6916009)(50986999)(33646002)(49976008)(6486002)(105586002)(68736007)(6306002)(2351001)(478600001)(50466002)(966005)(106356001)(65826007)(5660300001)(54356999)(64126003)(8676002)(23676003)(83506002)(1730700003)(81166006)(2501003)(3846002)(6116002)(97736004)(66066001)(316002)(8936002)(65806001)(53936002)(16526018)(67846002)(58126008)(81156014)(189998001)(36756003)(86362001)(7736002)(2906002)(2870700001)(305945005)(31696002)(47776003)(78286006)(225543005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3438; H:[159.107.197.147]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIzNDM4OzIzOnBSa1pJRnNoZGMyMWpEcGpFYWtBc1dUQ2No?= =?utf-8?B?ck4va0VXbGlQanlMVEtRZWg5aUc1MDlwMTNDcDVaY0tadVJxUUVvdUM4UTZt?= =?utf-8?B?QWR5bHVJa2NTOE4yTi92Q0o1U1dNdklacWJwRjF0MzV3a05rNUVadGEvaW1J?= =?utf-8?B?LzhERy8rU2d4ZG5vM0tmalpSSkdxN0psdjZTYURlODFHampCelk0clYyLzI5?= =?utf-8?B?TXVNaVdVK29zckVidnAyT3M2M3E0TGtqa2R6ZTFMS000OUxnbUpPakNDdWhL?= =?utf-8?B?a3dnSCt0RDV0TUt3dlZ6MkY5UVZ5M1liTDYySWRPeXd3SlhvK3BNZFhWbkRR?= =?utf-8?B?ajNOQ2JXakptaWZjZHNmQi83Y0FJSG1IUXJ1ZGpXTDdrWGhWU21TNFdVdm1z?= =?utf-8?B?SjhONlJMMVY2UVZhNjlubG9hbit6ajdBUmcxWW0yUlJqNnh4NXcwZHBZbkxp?= =?utf-8?B?d1Mxc2Y5VWVDYUlzbllmUXhUN1FrV2V1cDVpSDZYaVhHYWlDYjZOUEJTNDFy?= =?utf-8?B?Z05XYVNId3JuSEl5QVlQYk1Tb0pWRTdPbjdkbGVQcFEwV2FwQUZqZGRzMUx2?= =?utf-8?B?bHJXTkhtd3BQNkNnYzc3a2ZaK3YxVFhYZjVJclJGUUtHTTFEZWgyVnlKWGMv?= =?utf-8?B?ZTYyMmtkalFGendTWEJFTXE4TDdPY0F2NTVpNHVjSzRUeDJ0Slk0d2JSS1la?= =?utf-8?B?Ym14TnpGdnNJQk9yM2tsLytXSGVkUE1aNXJvZkNUdW9WaVkzQ0JUVzhORERw?= =?utf-8?B?TlJMVkF6VnExWno5dTB3dFc4WE4xb2p0TGR3QWV6NmREQkhtYUlIeUc4eExN?= =?utf-8?B?ZHpRQ1YvZkV4b2lnbE8xZ2NzODFBQ3ExMkd6UmR4SUsxcjUwenNXR0todGIx?= =?utf-8?B?STZtTE15YnBEWWpvTUQrU2pnNnJVNGlkd2pZSTdGL29FaXBveGF4OWR1Vy9n?= =?utf-8?B?UmRyMHZuSGJJUENIeGJRaXVldnBWV1JrV0pBN1hDejU0ZS8vbDVJYjVsL0ht?= =?utf-8?B?ZksrMlZyNFBiQWpzTVBDd29ldE0zdU5UVmhzS0VUS3hrYitUNHNLZ3FaR1g4?= =?utf-8?B?SHp5dEw0bzVqZlJoRW11SVlnY012ODdsRGNFV012S2RaVWhTbTIwUTBNVEhk?= =?utf-8?B?ci9QNGVCbzE3d1ZUbzBIaFVDcnJJT3YrOHhtOHJNdE8vV3FGSGlhcGJ6LzFO?= =?utf-8?B?UG96N3BQd2NwNEdPdnhNdUxRSXlQd0FZRGd0VUZmeVRFMlFaZkhBR3p6T2pV?= =?utf-8?B?SFNRVzJUejJQNXJ0bmg5aHAycTN4VWlCRExqV1A2Sjdqa2MyZnFpNVpmb1pm?= =?utf-8?B?eW04djh0bFFndFR6d3RqZmpUNkU5amFERWdUcHZTUkw1UEVJM1Q4bUVleXZu?= =?utf-8?B?VnFHSjI2UlZtbjZPN1lLclNQU0xDRjZCTXZPRVBkZlV2M3hCVm1IYnhyM0JM?= =?utf-8?B?UWIvV1pvUnkxckhyRkpCM3FuZGZ5T205bWlqWGJBTkhHcjJUR0JvZlRYcEJw?= =?utf-8?B?TmdVNXg5R1ZkUlV3blZXUHptMnlKcFZmZlZQUll6RXdnN3l0WHZTWU1NMGhN?= =?utf-8?B?b0FkUzROSW9KVVlpbG5MeW9icnpQTnFmRnU2Z2ZCcWE5WkJrYVJ5WEoyOGxv?= =?utf-8?B?MFVyY3RmUDFXT3dhR2Vwa2kzcCtXbitkT3RNbjJEVWFjdVNmZ1puN2tUcnR1?= =?utf-8?B?R1Jtd1E2aFR4Qk1ldmRJOXQyRk1pR0p6eldmcG02Q3cxNG5WZDYxQmZKSlk5?= =?utf-8?B?LzdqQXlXSjdONW5UUG5nOHRtWGh2OUxtcFJ4TWlnTDNqVGJTN0lrRSsrdGVo?= =?utf-8?B?R2RRWGQrNXo0QUZJdXdFTkxWRXpGbys2Qkt6SnZIeDR5SCs2aHU5UE5hdXN2?= =?utf-8?Q?yobFCnspVFSv2ASxgA2iRaGzLvlHNqf8?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 6:foqkC5VaoNwbpl0ftLq77cMcM0pIC8uZ4qSYO+8wEuec6Ux9Dk+BnVD6H1zSHe4sEyoocnngWhA3a3muo9NAgDYaPI/n5ktUijNUTGaNkjLmcO+f69ak2x835wunnLfWArMng4Xou55A61NJ1dIP88mK+mKQ4Eyh8Mf3TXVmgZN7DRv8DeF8BfUdrLRyBju659TSyjDHmMVPVsEDB6gfEc+I9EqkQwGb4RVNbHsZS/DeKdLQErTe7FsMz2iczvIV1h2JO8ujyJjdCJAI4SsP/TJ1pbFfc07gdFr2ddE30x7Z01El12sjYlyb4y+YZHlHI1w2kAjO2qa7m16Is47+yPXw3W4wqx2RSqp5P4qVEMg=; 5:4PyfD9NOLUK3/0+8cL9q3DgQ/FWlN7ToyhY2iWA10MYW9OvolBeT1HaaKfzqnbpRpQSkyrvuChSjyAXhaICqNgGZTu7HeJGy47bQcS+/flFM2Oq7EtPWJaoRZzaADYSJmqpogsJT1FB8L269r/bhq+ERdzYoRFemmLEjChtEJvo=; 24:cMJVUZeE+sZdQV/1101Li7OMzDIRZNEW8DaM5hjfhwQM8fLFOsXc4+iqhIrLdKJ6BeK1PenF4UwN9ot9lUkRFuMaJfyJKwNtOYBwYGxJfHQ=; 7:R0PXlmEHeBlI1p1BDmlrJFKCE/JhE7Wp92IdeYd2ExBXP6kRuhxOaHUevQvCf8Tv7xRNCuUqBDw8nM7V23ydrnfQPrgAZaSyqAUJ7RWLdR6u+WRFFrAhFtmR86dpR162lkHpy9Nco5se5yfPCOrHUsBo/kbO0xW9Yz9Bh2d7zTqOb1TASBYQ691v9clchIoYqc2wzJfj1Xhl7LTxo5Z8SyOvhW3IjS39HO7Ca5Oq7frtAstdnR/o0vkDOfs5x6qT
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2017 16:59:57.9431 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c566f035-b501-4306-55e1-08d527934f03
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3438
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUyM2K7n25/J0uUwa7dlhbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/jpTpaCJt6K7te2DYyruboYOTkkBEwkLh87yNLFyMUhJHCY UeLalV2sEM5xRontq3eAZVgEepklNj3ZygrSwigQJ7FzzUIwW0ignUnic78iiC0ioC4xc+d6 NhCbTcBIYmr/eaBmDg5hARuJLb2cIGFeAXuJNS/3sYDYLAIqEhe/7GEGsUUFYiQmPrjICFEj KHFy5hOwGmYBC4mZ888zQtjyEs1bZzND2OISt57MZ4L4QEHi+ubrYHdKCEwHOnrNCkaI2zQk Hl74ywpR5Cux9MFrqKKZjBJLzi5ih3Aa2CX2/l3PCFElK3H07BwWCFtL4vzca4wQRUvYJdoX /oRKeEu0P7vMDvKahEC2xIMl9hDhK6wSn385QdgyEl92nYPa9p9V4uy62UwQJ6VKbLnRwgaR eCwkMePUE/YJjJqzkPw9C8nfs5D8PQvJ3wsYWVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxi BCaJg1t+6+5gXP3a8RCjAAejEg/vtyaWKCHWxLLiytxDjBIczEoivJz1QCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8DvsuRAgJpCeWpGanphakFsFkmTg4pRoYLfJfLwhJzD/9KmvzzIMJunlL q3Y7zDtuJDs5fUWRWW2osqIF48PgtSEqx77vMOjVLDefrrrszvdDtj+svYtrXCx/eDKsZ5py cIvFYekPk7I6guKOZQgVi5x/lLKz6PnBt8lNLUov9jOtXH9lctKG/TkyDMtCrM5nHlTNWWf+ egcfy28JMYOVSizFGYmGWsxFxYkAkht8LA4DAAA=
Archived-At: 
Subject: [netmod] rfc7223bis Backward compatibility in YANG - BAD !!!
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Nov 2017 17:00:07 -0000

Hello,
In draft-ietf-netmod-rfc7223bis-00 I read

The "/interfaces-state" subtree with "config false" data nodes is
    deprecated.  ...

    Servers that do not implement NMDA, or that wish to support clients
    that do not implement NMDA, MAY implement the deprecated
    "/interfaces-state" tree.

This means that a server MAY simply remove a big branch 
(interfaces-state). If I have a network management system (NMS) and the 
YANG server upgrades to a new revision of the module suddenly my NMS SW 
breaks.

I find it really strange that, on a one hand YANG has very strict rules 
about updating a module, on the other hand just by deprecating something 
you can remove anything. Are we taking backward compatibility seriously 
or not? It seems not.

Earlier we had discussions about the definition of deprecated and 
obsolete in https://tools.ietf.org/html/rfc7950#section-7.21.2.
 From an NMS point of view the current definition just states: Anything 
can be deprecated/obsoleted anytime. If something has a status different 
from current there is no guarantee its usable or even that it exists.

IMHO these definitions are unusable for an NMS. Ericsson needed to 
introduce its own rules. IETF should do something about this! I have 
proposals if there are people interested.

As a minimum I would propose, that a server that does not implements a 
fully functional /interfaces-state" subtree MUST obsolete it, not just 
deprecate it.

regards Balazs

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


From nobody Thu Nov  9 09:11: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 8753F1276AF for ; Thu,  9 Nov 2017 09:11:24 -0800 (PST)
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 Nbw1Q9lw96T9 for ; Thu,  9 Nov 2017 09:11:21 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5294A127863 for ; Thu,  9 Nov 2017 09:11:21 -0800 (PST)
Received: from birdie17 (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 90B436425B; Thu,  9 Nov 2017 18:11:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510247476; bh=4rsRNpunVdu8mW0VsDVxJnaV4dX0I1prILCFFoFDPJc=; h=From:To:Date; b=pAF7GFEJ/Era3zRT8ZpMRX6VYTbZaVdmQ2GtmG1iliy6I7Sq27DO7XYOfZze7ReNh V5W769p8Lg4qO8onIM/dI+7JRqQrgt209JEW/RYRLWYXDzKAK/QfOZ9+NGqdIbV4r7 BhzIsrKqP8S5y7eRX8lR2EAqkCbVMlz1I/DEG9k0=
Message-ID: <1510247543.4067.4.camel@nic.cz>
From: Ladislav Lhotka 
To: Andy Bierman , Robert Wilton ,  "netmod@ietf.org" , Martin Bjorklund , Kent Watsen 
Date: Thu, 09 Nov 2017 18:12:23 +0100
In-Reply-To: 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] 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: Thu, 09 Nov 2017 17:11:24 -0000

On Thu, 2017-11-09 at 08:34 -0800, Andy Bierman wrote:
> 
> 
> On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka  wrote:
> > Robert Wilton  writes:
> > 
> > >>
> > >>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
> > >>> Implementation-time ...".  This section states that it is a stable as
> > >>> YANG library, and hence cannot change due to a server reboot. However,
> > >>> YANG library doesn't appear to have that restriction, and hence this
> > >>> doesn't seem to align with RFC 7895, introduction paragraph 2.
> > >> I don't know exactly under what circumstances YANG library can change
> > >> after a reboot, but in such a case schema-mounts data might be subject
> > >> to a change as well. I definitely think that the "run-time" case is
> > >> something else.
> > > A software upgrade could quite reasonably change YANG library without a
> > > device reboot.  Perhaps saying less is more precise:
> > >
> > > E.g.
> > >
> > >     2.  Implementation-time: the mounted schema is defined by a server
> > >         implementor and is as stable as YANG library information. Also,
> > >         a client can learn the entire schema together with YANG library data.
> > >
> > 
> > It seems that neither 7950 nor 7895 defines how stable YANG library data
> > is. The conclusion might be that it can change any time, which is IMO
> > hardly acceptable.
> 
> 
> Actually, the YANG library is allowed to change at any time.
> Clients use the module-set-id and the yang-library-change notification
> to keep their cached copy of the server's library up to date.

Notifications are optional, so basically the client needs to check module-set-id 
before every operation, and even this may not be sufficient for avoiding errors.

The YANG data model was touted as a contract between the server and client - and
 it is a strange contract if the server can change it arbitrarily.

Lada

> 
> 
> 
> Andy
> 
> 
> > >
> > > Or alternatively, you say that it is at least as stable as the YANG
> > > library information, and then list when it could change.
> > >
> > >
> > >>
> > >>> 3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined
> > >>> anywhere (RFC 7950 doesn't define this).  Should it be defined here?
> > >>> The NMDA datastores draft had a similar issue and we choose to define
> > >>> "datastore schema" instead.
> > >> I think the right place for defining the term "schema" (and "data model"
> > >> as well) is the specification of YANG because it is desirable that all
> > >> documents related to YANG use the same meaning.
> > > OK, 7950 doesn't define it today.  Is that a problem?
> > 
> > "Schema tree" and "schema node" are defined and used a lot in 7950, so
> > it might be good to define "schema" as well - meaning the schema tree
> > with all associated semantics.
> > 
> > >
> > >>
> > >>> 4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.
> > >>> The text "same management session" might be more clear as "same client
> > >>> management protocol session".
> > >> Hmm, I wouldn't say this is more clear - it seems to indicate that we
> > >> are managing the client.
> > > My issue is that "same management session" isn't really that clear to
> > > what it is referring to.  Perhaps drop the "client" and have "same
> > > management protocol session"?
> > 
> > This probably needs to be coupled somehow with YANG library stability -
> > if YANG library can change during a session, then schema mounts should
> > be permitted to change as well.
> > 
> > >
> > >
> > >>
> > >> But it could also be that such rules are inappropriate in this document and
> > >> rather belong to a protocol spec.
> > > I think that they are OK here if this draft defines the lifetime of the
> > > schema.  If it is just the same as YANG library, then perhaps this could
> > > be left to the YANG library spec to specify?
> > >
> > >>
> > >>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" =>
> > >>> "are possible, and as such, needs"
> > >> I actually don't understand neither this sentence nor what the point of
> > >> such exceptions could possibly be.
> > > An example would presumably be where effectively the same data is being
> > > mounted in a separate place.  E.g. the list of physical interfaces in an
> > > LNE may represent a subset of all physical interfaces in the device,
> > > that would also be present in the host model.
> > 
> > Then I would say simply "..., its data will generally have no
> > relationship to the data of the parent, unless the data model explicitly
> > states otherwise."
> > 
> > OK, "data model" is another term that isn't defined, but to me it is the
> > collection of YANG modules that define the schema. I think it's not
> > possible to say where the exception has to be stated, it can be
> > either in the parent or in the mounted module, or even elsewhere.
> > 
> > >>
> > >>> 6. Sec 3.2 paragraph 5.  Would it useful to state that even though the
> > >>> schema is the same, the data is different and not necessarily related.
> > >> I think this goes without saying, as it is also the case for a single mount
> > >> point that is a list node - data in each entry is different.
> > > In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally
> > > separate from the parent data.  For paragraph 5, I still that it is
> > > useful to state the equivalent that if a schema is mounted twice it
> > > doesn't mean the same data is mounted in both places.
> > 
> > This should be absolutely clear to anybody who understands that we are
> > only constructing a schema because, e.g., multiple uses of the same
> > grouping in YANG also don't mean the same instance data. Unfortunately,
> > with schema mount this confusion arises again and again, maybe the term
> > "mount" is really misleading.
> > 
> > ...
> > 
> > >>
> > >>> 9. Structure of ietf-yang-schema-mount module:
> > >>>     - Should "uri" under namespace be marked as "mandatory" so that it
> > >>> doesn't appear to be optional in the tree diagram.
> > >> Yes, this is an omission.
> > >>
> > >>>     - Should the "module" name be included under the namespace.  It seems
> > >>> that lots of other "module bindings" are done via the module name rather
> > >>> than the namespace?
> > >> We need it exclusively for XPath, so it seems natural to stay close to XML
> > >> namespaces.
> > > I was suggesting that it might be useful to add "module" in addition to
> > > namespace.
> > 
> > This is possible but redundant, I was thinking about replacing the URIs
> > with module names. It probably doesn't really matter unless the URIs are
> > written by hand.
> > 
> > Lada
> > 
> > >
> > >>
> > >>> 10. Example A.3.  This contains some features that are enabled. Possibly
> > >>> it would be useful in the description to point this out, and state that
> > >>> unless the features are listed they wouldn't be enabled.
> > >> Yes, we reuse the groupings from ietf-yang-library, and the idea is to
> > >> apply the same semantics. And as you are saying below, it would be more
> > >> straightforward to integrate it directly with YANG library.
> > >>
> > >>> My last general comment relates generally to the structure of the
> > >>> Iietf-yang-schema-mount.  As Lada has pointed out previously, this
> > >>> module and YANG library bis could be more closely aligned (e.g. along
> > >>> the lines of reusing module-sets for the "schema" list).  It would have
> > >>> been nice if this module could augment YANG library (so that you can
> > >>> easily get the modules and schema mount information in a single simple
> > >>> request), however that would put an undesired dependency delaying
> > >>> publishing this draft until YANG library bis is completed.
> > >> Of course I agree, but I think the priority should be to make things as
> > >> simple and easy to understand as possible. They are complex enough
> > >> anyway.
> > > Thanks,
> > > Rob
> > >
> > >
> > >>
> > >> Thanks, Lada
> > >>
> > >>> Thanks,
> > >>> Rob
> > >>>
> > >>>
> > >>> On 20/10/2017 22: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
> > >>>> .
> > >>>>
> > >
> > > _______________________________________________
> > > 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Nov  9 09:36: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 02A911243F6 for ; Thu,  9 Nov 2017 09:36:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGCcPbm2QKHj for ; Thu,  9 Nov 2017 09:36:16 -0800 (PST)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7673C12726E for ; Thu,  9 Nov 2017 09:36:16 -0800 (PST)
Received: by mail-lf0-x235.google.com with SMTP id r129so8124306lff.8 for ; Thu, 09 Nov 2017 09:36:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zoauOc7LEktXzqStUA0rrOADj6Qr41KpBe9suGyExrY=; b=dijysABpTuewKY79uopNlSCu4YkG2ijI6fxjuU95v9tCKnvCIHfm4xm4umR0G2fwLD T8bpllgJaBJaQTgb4Bt7cdoD3aEGr2ecI7pkBlQ/T8FVJKx9Q1wau/IXrskPnZmgLcel l2I/PARlR6ts9IIvMmcR0dh3hOXgnT9S9qiKfHCdbfwFMu+C4V2Jun4TdZaizFq5Fo6s ybqRo2c8cmqV5lqMByJF1vHiCaGX8EOv8lUGDEZMXTVLJ0F90n95JIbR3pEkoZsbgQtu P7PAiiyXz7RGFQWC1AmqWGPQChPIIAK2d7Kb0DnIwVNNFttDHQiA68ruC8A4N3GiOC9a e3hA==
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=zoauOc7LEktXzqStUA0rrOADj6Qr41KpBe9suGyExrY=; b=djpm8h8V0F8vRi1NSlokCjzkuV44y3rON2Hzvf91XlYyopP251MUrsDdw/s54vEHrW YNpsRtKOaq5iHocv/AaoWSUFDBwk+wNvN6tdmwSN6q/npOFb8JECirPNNk+mJCsJUOAc XKckENJuoqCsb8DPbXPRaEh0XcJkRk022ORu7EE3/lgRi2pMA4mf2ZDYedrCgtQ4Hk23 EybX2IkJddXB8UMursduuk0j7FpU20SgAPt55PXdRwUzAzV4lM1LDQlIsuR2Gep7OnPn E1QB15o5jDjPDHzhUg2NNfencQhLdYZLLS3dhpQESqPpRgyB2H01n6tKrF2nzUgZmYaw Svjg==
X-Gm-Message-State: AJaThX5pCnvI9KEAC7++nbR2IFPxqQOVkSojNsT8jStbigZBdumquM77 cD4ZcZG0S9mKmKbBo7dW4iTNcvhwB8kUqiFurTOEog==
X-Google-Smtp-Source: AGs4zMbgW1fo7qD4GjIeE8RWNihbe8bgl6MP+rYuAB+SxjusUaAbbSea30O+lBu9o7LLQCo/ydgZKTsMSec4cBilZQU=
X-Received: by 10.25.221.217 with SMTP id w86mr38259lfi.89.1510248974708; Thu, 09 Nov 2017 09:36:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 9 Nov 2017 09:36:13 -0800 (PST)
In-Reply-To: <01a4beef-4a86-fa10-dc81-7dd57e12a9a8@ericsson.com>
References: <01a4beef-4a86-fa10-dc81-7dd57e12a9a8@ericsson.com>
From: Andy Bierman 
Date: Thu, 9 Nov 2017 09:36:13 -0800
Message-ID: 
To: Balazs Lengyel 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0ec71ea91eed055d903dde"
Archived-At: 
Subject: Re: [netmod] rfc7223bis Backward compatibility in YANG - BAD !!!
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Nov 2017 17:36:19 -0000

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

On Thu, Nov 9, 2017 at 8:59 AM, Balazs Lengyel 
wrote:

> Hello,
> In draft-ietf-netmod-rfc7223bis-00 I read
>
> The "/interfaces-state" subtree with "config false" data nodes is
>    deprecated.  ...
>
>    Servers that do not implement NMDA, or that wish to support clients
>    that do not implement NMDA, MAY implement the deprecated
>    "/interfaces-state" tree.
>
> This means that a server MAY simply remove a big branch
> (interfaces-state). If I have a network management system (NMS) and the
> YANG server upgrades to a new revision of the module suddenly my NMS SW
> breaks.
>
> I find it really strange that, on a one hand YANG has very strict rules
> about updating a module, on the other hand just by deprecating something
> you can remove anything. Are we taking backward compatibility seriously or
> not? It seems not.
>
>

Ironically, the NMDA approach was sold as the solution path without any
disruption to the data models.

Customers will pressure vendors to fix "stuff that used to work" and
generally
vendors avoid breaking it in the first place.  3rd party NMS has never been
a priority
anywhere, including the IETF.


Earlier we had discussions about the definition of deprecated and obsolete
> in https://tools.ietf.org/html/rfc7950#section-7.21.2.
> From an NMS point of view the current definition just states: Anything can
> be deprecated/obsoleted anytime. If something has a status different from
> current there is no guarantee its usable or even that it exists.
>
> IMHO these definitions are unusable for an NMS. Ericsson needed to
> introduce its own rules. IETF should do something about this! I have
> proposals if there are people interested.
>
> As a minimum I would propose, that a server that does not implements a
> fully functional /interfaces-state" subtree MUST obsolete it, not just
> deprecate it.
>


how does this help?
Duplicate read-only data does not break anything.
An old client can keep reading /interfaces-state and a new client
can use .

There are some problems with NMDA that break old clients (e.g., rpc and
action)
but this isn't one of them.



> regards Balazs



Andy


>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Thu, Nov 9, 2017 at 8:59 AM, Balazs Lengyel <balazs.lengy=
el@ericsson.com> wrote:
Hel=
lo,

In draft-ietf-netmod-rfc7223bis-00 I read



The "/interfaces-state" subtree with "config false" dat=
a nodes is

=C2=A0=C2=A0 deprecated.=C2=A0 ...



=C2=A0=C2=A0 Servers that do not implement NMDA, or that wish to support cl=
ients

=C2=A0=C2=A0 that do not implement NMDA, MAY implement the deprecated

=C2=A0=C2=A0 "/interfaces-state" tree.



This means that a server MAY simply remove a big branch (interfaces-state).=
 If I have a network management system (NMS) and the YANG server upgrades t=
o a new revision of the module suddenly my NMS SW breaks.



I find it really strange that, on a one hand YANG has very strict rules abo=
ut updating a module, on the other hand just by deprecating something you c=
an remove anything. Are we taking backward compatibility seriously or not? =
It seems not.




Ironically, the NMDA ap=
proach was sold as the solution path without any
disruption to th=
e data models.=C2=A0

Customers will pressure vendo=
rs to fix "stuff that used to work" and generally
vendo=
rs avoid breaking it in the first place. =C2=A03rd party NMS has never been=
 a priority
anywhere, including the IETF.



Earlier we had discussions about the definition of deprecated and obsolete =
in https://tools.ietf.org/html/rfc7950#sectio=
n-7.21.2.

>From an NMS point of view the current definition just states: Anything can =
be deprecated/obsoleted anytime. If something has a status different from c=
urrent there is no guarantee its usable or even that it exists.



IMHO these definitions are unusable for an NMS. Ericsson needed to introduc=
e its own rules. IETF should do something about this! I have proposals if t=
here are people interested.



As a minimum I would propose, that a server that does not implements a full=
y functional /interfaces-state" subtree MUST obsolete it, not just dep=
recate it.


how does this=
 help?
Duplicate read-only data does not break anything.
An old client can keep reading /interfaces-state and a new client
can use <get-data>.

There are some proble=
ms with NMDA that break old clients (e.g., rpc and action)
but th=
is isn't one of them.





regards Balazs


Andy
=C2=A0




-- 

Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ema=
il: Balazs=
.Lengyel@ericsson.com



_______________________________________________

netmod mailing list

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




--94eb2c0ec71ea91eed055d903dde--


From nobody Thu Nov  9 09:38: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 8E12312726E for ; Thu,  9 Nov 2017 09:38:45 -0800 (PST)
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 pULnT5R2mZ-i for ; Thu,  9 Nov 2017 09:38:43 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F70D1243F6 for ; Thu,  9 Nov 2017 09:38:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8864; q=dns/txt; s=iport; t=1510249123; x=1511458723; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=PjlZbZP16Jt32QIWFAUC9XxyCqA7uKyaDwvqAATqiek=; b=kG6gqzCyol54w0YNpMBHFwHJAQowzdgk22FA4t1XWqHBYCGlhWahdm1l haGBhbUrooVvXcvYZnZcET3qL8u5F3S3ccaxLKkFLVpBSQgpII2L2mAGK WZTWcE3EWLmH+j1xWVRC/rAsrptQmj7+KGfBpY1NAZxS1nNFyqYOzVo5s Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAAB0kQRa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQYbieDfYofdJAJJpZOEIIBChgLgV6Ca08ChHYYAQEBAQEBAQE?= =?us-ascii?q?BayiFHgEBAQMBAQEhDwEFNgQXCxgCAiYCAicwBgEMBgIBAReKAAgQqV6CJ4sXA?= =?us-ascii?q?QEBAQEBAQECAQEBAQEBAQEBGgWBD4Ihg1uBaSkLgnaEZAESAQmDK4JjBZFhkDq?= =?us-ascii?q?UfoIVhgWDYIdBjjKHcIE5HziBA240IQgdFUmCZIRfQTaJVYI1AQEB?=
X-IronPort-AV: E=Sophos;i="5.44,370,1505779200";  d="scan'208";a="165531"
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; 09 Nov 2017 17:38:41 +0000
Received: from [10.63.23.122] (dhcp-ensft1-uk-vla370-10-63-23-122.cisco.com [10.63.23.122]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA9HcemM024939; Thu, 9 Nov 2017 17:38:40 GMT
To: "netmod@ietf.org" , Martin Bjorklund , Kent Watsen 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz>
From: Robert Wilton 
Message-ID: <56ea1907-c2ed-1940-089c-527b33f0723e@cisco.com>
Date: Thu, 9 Nov 2017 17:38:40 +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: <87d14rjwdq.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] 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: Thu, 09 Nov 2017 17:38:45 -0000

On 09/11/2017 15:37, Ladislav Lhotka wrote:
> Robert Wilton  writes:
>
>>>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
>>>> Implementation-time ...".  This section states that it is a stable as
>>>> YANG library, and hence cannot change due to a server reboot. However,
>>>> YANG library doesn't appear to have that restriction, and hence this
>>>> doesn't seem to align with RFC 7895, introduction paragraph 2.
>>> I don't know exactly under what circumstances YANG library can change
>>> after a reboot, but in such a case schema-mounts data might be subject
>>> to a change as well. I definitely think that the "run-time" case is
>>> something else.
>> A software upgrade could quite reasonably change YANG library without a
>> device reboot.  Perhaps saying less is more precise:
>>
>> E.g.
>>
>>      2.  Implementation-time: the mounted schema is defined by a server
>>          implementor and is as stable as YANG library information. Also,
>>          a client can learn the entire schema together with YANG library data.
>>
> It seems that neither 7950 nor 7895 defines how stable YANG library data
> is. The conclusion might be that it can change any time, which is IMO
> hardly acceptable.
>
>> Or alternatively, you say that it is at least as stable as the YANG
>> library information, and then list when it could change.
>>
>>
>>>> 3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined
>>>> anywhere (RFC 7950 doesn't define this).  Should it be defined here?
>>>> The NMDA datastores draft had a similar issue and we choose to define
>>>> "datastore schema" instead.
>>> I think the right place for defining the term "schema" (and "data model"
>>> as well) is the specification of YANG because it is desirable that all
>>> documents related to YANG use the same meaning.
>> OK, 7950 doesn't define it today.  Is that a problem?
> "Schema tree" and "schema node" are defined and used a lot in 7950, so
> it might be good to define "schema" as well - meaning the schema tree
> with all associated semantics.
OK, but we can't add definitions to 7950 now.  Would it make sense to 
add the definition to the NMDA draft and reference that?

>
>>>> 4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies here.
>>>> The text "same management session" might be more clear as "same client
>>>> management protocol session".
>>> Hmm, I wouldn't say this is more clear - it seems to indicate that we
>>> are managing the client.
>> My issue is that "same management session" isn't really that clear to
>> what it is referring to.  Perhaps drop the "client" and have "same
>> management protocol session"?
> This probably needs to be coupled somehow with YANG library stability -
> if YANG library can change during a session, then schema mounts should
> be permitted to change as well.
Agreed.

>
>>
>>> But it could also be that such rules are inappropriate in this document and
>>> rather belong to a protocol spec.
>> I think that they are OK here if this draft defines the lifetime of the
>> schema.  If it is just the same as YANG library, then perhaps this could
>> be left to the YANG library spec to specify?
>>
>>>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" =>
>>>> "are possible, and as such, needs"
>>> I actually don't understand neither this sentence nor what the point of
>>> such exceptions could possibly be.
>> An example would presumably be where effectively the same data is being
>> mounted in a separate place.  E.g. the list of physical interfaces in an
>> LNE may represent a subset of all physical interfaces in the device,
>> that would also be present in the host model.
> Then I would say simply "..., its data will generally have no
> relationship to the data of the parent, unless the data model explicitly
> states otherwise."
>
> OK, "data model" is another term that isn't defined, but to me it is the
> collection of YANG modules that define the schema. I think it's not
> possible to say where the exception has to be stated, it can be
> either in the parent or in the mounted module, or even elsewhere.
OK, but I would avoid introducing the term "data model".

>
>>>> 6. Sec 3.2 paragraph 5.  Would it useful to state that even though the
>>>> schema is the same, the data is different and not necessarily related.
>>> I think this goes without saying, as it is also the case for a single mount
>>> point that is a list node - data in each entry is different.
>> In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally
>> separate from the parent data.  For paragraph 5, I still that it is
>> useful to state the equivalent that if a schema is mounted twice it
>> doesn't mean the same data is mounted in both places.
> This should be absolutely clear to anybody who understands that we are
> only constructing a schema because, e.g., multiple uses of the same
> grouping in YANG also don't mean the same instance data. Unfortunately,
> with schema mount this confusion arises again and again, maybe the term
> "mount" is really misleading.
So, I'm not confused by this (but I am quite familiar with the 
solution), but think that this is an area where a less familiar reader 
could make the wrong assumption, hence the suggestion to clarify it.


>
> ...
>
>>>> 9. Structure of ietf-yang-schema-mount module:
>>>>      - Should "uri" under namespace be marked as "mandatory" so that it
>>>> doesn't appear to be optional in the tree diagram.
>>> Yes, this is an omission.
>>>
>>>>      - Should the "module" name be included under the namespace.  It seems
>>>> that lots of other "module bindings" are done via the module name rather
>>>> than the namespace?
>>> We need it exclusively for XPath, so it seems natural to stay close to XML
>>> namespaces.
>> I was suggesting that it might be useful to add "module" in addition to
>> namespace.
> This is possible but redundant, I was thinking about replacing the URIs
> with module names. It probably doesn't really matter unless the URIs are
> written by hand.
I'm wondering whether this list is really required at all.  E.g. if you 
see my other email about YANG library structure, then if the structure 
for schema mount and YANG library was converged then would this list 
still be necessary?  Or could there just be a reference to the parent 
schema that xpath references are resolved against?

Thanks,
Rob

>
> Lada
>
>>>> 10. Example A.3.  This contains some features that are enabled. Possibly
>>>> it would be useful in the description to point this out, and state that
>>>> unless the features are listed they wouldn't be enabled.
>>> Yes, we reuse the groupings from ietf-yang-library, and the idea is to
>>> apply the same semantics. And as you are saying below, it would be more
>>> straightforward to integrate it directly with YANG library.
>>>
>>>> My last general comment relates generally to the structure of the
>>>> Iietf-yang-schema-mount.  As Lada has pointed out previously, this
>>>> module and YANG library bis could be more closely aligned (e.g. along
>>>> the lines of reusing module-sets for the "schema" list).  It would have
>>>> been nice if this module could augment YANG library (so that you can
>>>> easily get the modules and schema mount information in a single simple
>>>> request), however that would put an undesired dependency delaying
>>>> publishing this draft until YANG library bis is completed.
>>> Of course I agree, but I think the priority should be to make things as
>>> simple and easy to understand as possible. They are complex enough
>>> anyway.
>> Thanks,
>> Rob
>>
>>
>>> Thanks, Lada
>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 20/10/2017 22: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
>>>>> .
>>>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Nov  9 09:44: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 BAC3D1287A3 for ; Thu,  9 Nov 2017 09:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKJp626zAj8B for ; Thu,  9 Nov 2017 09:44:34 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B669127B60 for ; Thu,  9 Nov 2017 09:44:27 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id r129so8150555lff.8 for ; Thu, 09 Nov 2017 09:44:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=trXjje9zTG6mp+VV0eZlk2IbmwrjE/tdXD+hRAVah3I=; b=L+/bLHEIEUglO6o7VhBSF7F9ckUbXjoQI9eUTWwKUn39NOe4ZjZHBJye6D6oLV+LXG v0fJHrmxvZFNhuqMr+yhi8MG3VJvoytMNgvSLHju2jRRnamGUKogJNmnCMGosc/HKvny PZ4bGkSVkfLgW8rl1S9fISB9YaeDAFBlR/CyTlmkSAHCnzGVt3qPnjSJYz6S2hNMiX4s uxL/gNXIOEQV4h/FftItwj32/Zyp6FeFksnbeT7iVyIFBu++zf/gny++hZV0eUpUcwLE n65zqXLCJ4bhV9i/OpURfwQ616181BJaWRvM6E/vk3r1m7B6cg/25OVGrLx6MZdd9mWf AWmQ==
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=trXjje9zTG6mp+VV0eZlk2IbmwrjE/tdXD+hRAVah3I=; b=Sk0lyFAPMNONjZwi089PgG3eAVkiTNae487KzNiLW7ckfiZY1K1HFBLspnQNvxTaj3 bXq54AiRnjEbw57jMIWoMvU/ZelggWLe+nlc8aJGeK3F9U6TEiGgiu/i6B+tIViS5bXB 3HnHXjgnqe4kXQgFtEhYKIdKklS++djGuJG5QWn/byetRhZ7N8A+n1XSsV4jWgCyBiBv SVNGPxVTOraYWeGmApEUcrou+c+EFJbGb0S696lpAK7+k8cnB6ZTrEUbf4cWGVUO57xV Zt7j+h5p8sfOWubq5W0Ouiz0vdfprQNc5BOMeWI5n4dbkkqsX1TtY/OiPyAcz70WZAEk zP4Q==
X-Gm-Message-State: AJaThX6IVez1NuCjOr8SunW86Zgydu+ulg5ilyo7Z/2/9jUanEiDAs8G AMLMr0KUi6O62hmUSkSHVWbNHm22a41Uah55ux2Hgg==
X-Google-Smtp-Source: AGs4zMYkTC4vhUgF7L6/rBON6SwzGh/i6fKI3aZo5k+gjn6HLWm9nnWpIxE/TbSRT4aYiJCmg/55sUVFkxgBUMFQUL0=
X-Received: by 10.25.23.165 with SMTP id 37mr522618lfx.202.1510249465360; Thu, 09 Nov 2017 09:44:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.214.9 with HTTP; Thu, 9 Nov 2017 09:44:24 -0800 (PST)
In-Reply-To: <1510247543.4067.4.camel@nic.cz>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz>  <1510247543.4067.4.camel@nic.cz>
From: Andy Bierman 
Date: Thu, 9 Nov 2017 09:44:24 -0800
Message-ID: 
To: Ladislav Lhotka 
Cc: Robert Wilton , "netmod@ietf.org" ,  Martin Bjorklund , Kent Watsen 
Content-Type: multipart/alternative; boundary="001a11401a04e800b5055d905a26"
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: Thu, 09 Nov 2017 17:44:38 -0000

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

On Thu, Nov 9, 2017 at 9:12 AM, Ladislav Lhotka  wrote:

> On Thu, 2017-11-09 at 08:34 -0800, Andy Bierman wrote:
> >
> >
> > On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka  wrote:
> > > Robert Wilton  writes:
> > >
> > > >>
> > > >>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
> > > >>> Implementation-time ...".  This section states that it is a stable
> as
> > > >>> YANG library, and hence cannot change due to a server reboot.
> However,
> > > >>> YANG library doesn't appear to have that restriction, and hence
> this
> > > >>> doesn't seem to align with RFC 7895, introduction paragraph 2.
> > > >> I don't know exactly under what circumstances YANG library can
> change
> > > >> after a reboot, but in such a case schema-mounts data might be
> subject
> > > >> to a change as well. I definitely think that the "run-time" case is
> > > >> something else.
> > > > A software upgrade could quite reasonably change YANG library
> without a
> > > > device reboot.  Perhaps saying less is more precise:
> > > >
> > > > E.g.
> > > >
> > > >     2.  Implementation-time: the mounted schema is defined by a
> server
> > > >         implementor and is as stable as YANG library information.
> Also,
> > > >         a client can learn the entire schema together with YANG
> library data.
> > > >
> > >
> > > It seems that neither 7950 nor 7895 defines how stable YANG library
> data
> > > is. The conclusion might be that it can change any time, which is IMO
> > > hardly acceptable.
> >
> >
> > Actually, the YANG library is allowed to change at any time.
> > Clients use the module-set-id and the yang-library-change notification
> > to keep their cached copy of the server's library up to date.
>
> Notifications are optional, so basically the client needs to check
> module-set-id
> before every operation, and even this may not be sufficient for avoiding
> errors.
>
> The YANG data model was touted as a contract between the server and client
> - and
>  it is a strange contract if the server can change it arbitrarily.
>
>

The server can change the library according to the contract.
It updates the module-set-id.

In reality, there are no routers that change the module set at run-time.
They are all mostly-monolithic firmware that need to reboot to change the
YANG modules.
Modular software is more complex to test, so it is not as common in
embedded systems.

Lada
>

Andy


>
> >
> >
> >
> > Andy
> >
> >
> > > >
> > > > Or alternatively, you say that it is at least as stable as the YANG
> > > > library information, and then list when it could change.
> > > >
> > > >
> > > >>
> > > >>> 3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined
> > > >>> anywhere (RFC 7950 doesn't define this).  Should it be defined
> here?
> > > >>> The NMDA datastores draft had a similar issue and we choose to
> define
> > > >>> "datastore schema" instead.
> > > >> I think the right place for defining the term "schema" (and "data
> model"
> > > >> as well) is the specification of YANG because it is desirable that
> all
> > > >> documents related to YANG use the same meaning.
> > > > OK, 7950 doesn't define it today.  Is that a problem?
> > >
> > > "Schema tree" and "schema node" are defined and used a lot in 7950, so
> > > it might be good to define "schema" as well - meaning the schema tree
> > > with all associated semantics.
> > >
> > > >
> > > >>
> > > >>> 4. Sec 3.2. paragraph 1.  Same comment as 2 above also applies
> here.
> > > >>> The text "same management session" might be more clear as "same
> client
> > > >>> management protocol session".
> > > >> Hmm, I wouldn't say this is more clear - it seems to indicate that
> we
> > > >> are managing the client.
> > > > My issue is that "same management session" isn't really that clear to
> > > > what it is referring to.  Perhaps drop the "client" and have "same
> > > > management protocol session"?
> > >
> > > This probably needs to be coupled somehow with YANG library stability -
> > > if YANG library can change during a session, then schema mounts should
> > > be permitted to change as well.
> > >
> > > >
> > > >
> > > >>
> > > >> But it could also be that such rules are inappropriate in this
> document and
> > > >> rather belong to a protocol spec.
> > > > I think that they are OK here if this draft defines the lifetime of
> the
> > > > schema.  If it is just the same as YANG library, then perhaps this
> could
> > > > be left to the YANG library spec to specify?
> > > >
> > > >>
> > > >>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such
> needs" =>
> > > >>> "are possible, and as such, needs"
> > > >> I actually don't understand neither this sentence nor what the
> point of
> > > >> such exceptions could possibly be.
> > > > An example would presumably be where effectively the same data is
> being
> > > > mounted in a separate place.  E.g. the list of physical interfaces
> in an
> > > > LNE may represent a subset of all physical interfaces in the device,
> > > > that would also be present in the host model.
> > >
> > > Then I would say simply "..., its data will generally have no
> > > relationship to the data of the parent, unless the data model
> explicitly
> > > states otherwise."
> > >
> > > OK, "data model" is another term that isn't defined, but to me it is
> the
> > > collection of YANG modules that define the schema. I think it's not
> > > possible to say where the exception has to be stated, it can be
> > > either in the parent or in the mounted module, or even elsewhere.
> > >
> > > >>
> > > >>> 6. Sec 3.2 paragraph 5.  Would it useful to state that even though
> the
> > > >>> schema is the same, the data is different and not necessarily
> related.
> > > >> I think this goes without saying, as it is also the case for a
> single mount
> > > >> point that is a list node - data in each entry is different.
> > > > In Sec 3.2 paragraph 2, it clarifies that the mounted data is
> generally
> > > > separate from the parent data.  For paragraph 5, I still that it is
> > > > useful to state the equivalent that if a schema is mounted twice it
> > > > doesn't mean the same data is mounted in both places.
> > >
> > > This should be absolutely clear to anybody who understands that we are
> > > only constructing a schema because, e.g., multiple uses of the same
> > > grouping in YANG also don't mean the same instance data. Unfortunately,
> > > with schema mount this confusion arises again and again, maybe the term
> > > "mount" is really misleading.
> > >
> > > ...
> > >
> > > >>
> > > >>> 9. Structure of ietf-yang-schema-mount module:
> > > >>>     - Should "uri" under namespace be marked as "mandatory" so
> that it
> > > >>> doesn't appear to be optional in the tree diagram.
> > > >> Yes, this is an omission.
> > > >>
> > > >>>     - Should the "module" name be included under the namespace.
> It seems
> > > >>> that lots of other "module bindings" are done via the module name
> rather
> > > >>> than the namespace?
> > > >> We need it exclusively for XPath, so it seems natural to stay close
> to XML
> > > >> namespaces.
> > > > I was suggesting that it might be useful to add "module" in addition
> to
> > > > namespace.
> > >
> > > This is possible but redundant, I was thinking about replacing the URIs
> > > with module names. It probably doesn't really matter unless the URIs
> are
> > > written by hand.
> > >
> > > Lada
> > >
> > > >
> > > >>
> > > >>> 10. Example A.3.  This contains some features that are enabled.
> Possibly
> > > >>> it would be useful in the description to point this out, and state
> that
> > > >>> unless the features are listed they wouldn't be enabled.
> > > >> Yes, we reuse the groupings from ietf-yang-library, and the idea is
> to
> > > >> apply the same semantics. And as you are saying below, it would be
> more
> > > >> straightforward to integrate it directly with YANG library.
> > > >>
> > > >>> My last general comment relates generally to the structure of the
> > > >>> Iietf-yang-schema-mount.  As Lada has pointed out previously, this
> > > >>> module and YANG library bis could be more closely aligned (e.g.
> along
> > > >>> the lines of reusing module-sets for the "schema" list).  It would
> have
> > > >>> been nice if this module could augment YANG library (so that you
> can
> > > >>> easily get the modules and schema mount information in a single
> simple
> > > >>> request), however that would put an undesired dependency delaying
> > > >>> publishing this draft until YANG library bis is completed.
> > > >> Of course I agree, but I think the priority should be to make
> things as
> > > >> simple and easy to understand as possible. They are complex enough
> > > >> anyway.
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > >>
> > > >> Thanks, Lada
> > > >>
> > > >>> Thanks,
> > > >>> Rob
> > > >>>
> > > >>>
> > > >>> On 20/10/2017 22: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
> > > >>>> .
> > > >>>>
> > > >
> > > > _______________________________________________
> > > > 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
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>

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




On Thu, Nov 9, 2017 at 9:12 AM, Ladislav Lhotka <<=
a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:
On Thu, 2017-11-09 at 08:34 -0=
800, Andy Bierman wrote:

>

>

> On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> > Robert Wilton <rwilton@cisco.com> writes:

> >

> > >>

> > >>> 2. Sec 1. Introduction, page 4, paragraph starting &=
quot;2.

> > >>> Implementation-time ...".=C2=A0 This section st=
ates that it is a stable as

> > >>> YANG library, and hence cannot change due to a serve=
r reboot. However,

> > >>> YANG library doesn't appear to have that restric=
tion, and hence this

> > >>> doesn't seem to align with RFC 7895, introductio=
n paragraph 2.

> > >> I don't know exactly under what circumstances YANG l=
ibrary can change

> > >> after a reboot, but in such a case schema-mounts data mi=
ght be subject

> > >> to a change as well. I definitely think that the "r=
un-time" case is

> > >> something else.

> > > A software upgrade could quite reasonably change YANG librar=
y without a

> > > device reboot.=C2=A0 Perhaps saying less is more precise:
> > >

> > > E.g.

> > >

> > >=C2=A0 =C2=A0 =C2=A02.=C2=A0 Implementation-time: the mounted=
 schema is defined by a server

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementor and is as stabl=
e as YANG library information. Also,

> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a client can learn the enti=
re schema together with YANG library data.

> > >

> >

> > It seems that neither 7950 nor 7895 defines how stable YANG libra=
ry data

> > is. The conclusion might be that it can change any time, which is=
 IMO

> > hardly acceptable.

>

>

> Actually, the YANG library is allowed to change at any time.

> Clients use the module-set-id and the yang-library-change notification=


> to keep their cached copy of the server's library up to date.



Notifications are optional, so basically the client needs to check module-s=
et-id

before every operation, and even this may not be sufficient for avoiding er=
rors.



The YANG data model was touted as a contract between the server and client =
- and

=C2=A0it is a strange contract if the server can change it arbitrarily.




The server can change t=
he library according to the contract.
It updates the module-set-i=
d.

In reality, there are no routers that change th=
e module set at run-time.
They are all mostly-monolithic firmware=
 that need to reboot to change the YANG modules.
Modular software=
 is more complex to test, so it is not as common in embedded systems.
=



Lada

Andy
=C2=A0



>

>

>

> Andy

>

>

> > >

> > > Or alternatively, you say that it is at least as stable as t=
he YANG

> > > library information, and then list when it could change.

> > >

> > >

> > >>

> > >>> 3. Sec 2.1 Glossary of New Terms:=C2=A0 "Schema=
" isn't actually defined

> > >>> anywhere (RFC 7950 doesn't define this).=C2=A0 S=
hould it be defined here?

> > >>> The NMDA datastores draft had a similar issue and we=
 choose to define

> > >>> "datastore schema" instead.

> > >> I think the right place for defining the term "sche=
ma" (and "data model"

> > >> as well) is the specification of YANG because it is desi=
rable that all

> > >> documents related to YANG use the same meaning.

> > > OK, 7950 doesn't define it today.=C2=A0 Is that a proble=
m?

> >

> > "Schema tree" and "schema node" are defined a=
nd used a lot in 7950, so

> > it might be good to define "schema" as well - meaning t=
he schema tree

> > with all associated semantics.

> >

> > >

> > >>

> > >>> 4. Sec 3.2. paragraph 1.=C2=A0 Same comment as 2 abo=
ve also applies here.

> > >>> The text "same management session" might b=
e more clear as "same client

> > >>> management protocol session".

> > >> Hmm, I wouldn't say this is more clear - it seems to=
 indicate that we

> > >> are managing the client.

> > > My issue is that "same management session" isn'=
;t really that clear to

> > > what it is referring to.=C2=A0 Perhaps drop the "client=
" and have "same

> > > management protocol session"?

> >

> > This probably needs to be coupled somehow with YANG library stabi=
lity -

> > if YANG library can change during a session, then schema mounts s=
hould

> > be permitted to change as well.

> >

> > >

> > >

> > >>

> > >> But it could also be that such rules are inappropriate i=
n this document and

> > >> rather belong to a protocol spec.

> > > I think that they are OK here if this draft defines the life=
time of the

> > > schema.=C2=A0 If it is just the same as YANG library, then p=
erhaps this could

> > > be left to the YANG library spec to specify?

> > >

> > >>

> > >>> 5. Sec 3.2. paragraph 2, last sentence: "are po=
ssible and such needs" =3D>

> > >>> "are possible, and as such, needs"

> > >> I actually don't understand neither this sentence no=
r what the point of

> > >> such exceptions could possibly be.

> > > An example would presumably be where effectively the same da=
ta is being

> > > mounted in a separate place.=C2=A0 E.g. the list of physical=
 interfaces in an

> > > LNE may represent a subset of all physical interfaces in the=
 device,

> > > that would also be present in the host model.

> >

> > Then I would say simply "..., its data will generally have n=
o

> > relationship to the data of the parent, unless the data model exp=
licitly

> > states otherwise."

> >

> > OK, "data model" is another term that isn't defined=
, but to me it is the

> > collection of YANG modules that define the schema. I think it'=
;s not

> > possible to say where the exception has to be stated, it can be
> > either in the parent or in the mounted module, or even elsewhere.=


> >

> > >>

> > >>> 6. Sec 3.2 paragraph 5.=C2=A0 Would it useful to sta=
te that even though the

> > >>> schema is the same, the data is different and not ne=
cessarily related.

> > >> I think this goes without saying, as it is also the case=
 for a single mount

> > >> point that is a list node - data in each entry is differ=
ent.

> > > In Sec 3.2 paragraph 2, it clarifies that the mounted data i=
s generally

> > > separate from the parent data.=C2=A0 For paragraph 5, I stil=
l that it is

> > > useful to state the equivalent that if a schema is mounted t=
wice it

> > > doesn't mean the same data is mounted in both places.
> >

> > This should be absolutely clear to anybody who understands that w=
e are

> > only constructing a schema because, e.g., multiple uses of the sa=
me

> > grouping in YANG also don't mean the same instance data. Unfo=
rtunately,

> > with schema mount this confusion arises again and again, maybe th=
e term

> > "mount" is really misleading.

> >

> > ...

> >

> > >>

> > >>> 9. Structure of ietf-yang-schema-mount module:

> > >>>=C2=A0 =C2=A0 =C2=A0- Should "uri" under na=
mespace be marked as "mandatory" so that it

> > >>> doesn't appear to be optional in the tree diagra=
m.

> > >> Yes, this is an omission.

> > >>

> > >>>=C2=A0 =C2=A0 =C2=A0- Should the "module" n=
ame be included under the namespace.=C2=A0 It seems

> > >>> that lots of other "module bindings" are d=
one via the module name rather

> > >>> than the namespace?

> > >> We need it exclusively for XPath, so it seems natural to=
 stay close to XML

> > >> namespaces.

> > > I was suggesting that it might be useful to add "module=
" in addition to

> > > namespace.

> >

> > This is possible but redundant, I was thinking about replacing th=
e URIs

> > with module names. It probably doesn't really matter unless t=
he URIs are

> > written by hand.

> >

> > Lada

> >

> > >

> > >>

> > >>> 10. Example A.3.=C2=A0 This contains some features t=
hat are enabled. Possibly

> > >>> it would be useful in the description to point this =
out, and state that

> > >>> unless the features are listed they wouldn't be =
enabled.

> > >> Yes, we reuse the groupings from ietf-yang-library, and =
the idea is to

> > >> apply the same semantics. And as you are saying below, i=
t would be more

> > >> straightforward to integrate it directly with YANG libra=
ry.

> > >>

> > >>> My last general comment relates generally to the str=
ucture of the

> > >>> Iietf-yang-schema-mount.=C2=A0 As Lada has pointed o=
ut previously, this

> > >>> module and YANG library bis could be more closely al=
igned (e.g. along

> > >>> the lines of reusing module-sets for the "schem=
a" list).=C2=A0 It would have

> > >>> been nice if this module could augment YANG library =
(so that you can

> > >>> easily get the modules and schema mount information =
in a single simple

> > >>> request), however that would put an undesired depend=
ency delaying

> > >>> publishing this draft until YANG library bis is comp=
leted.

> > >> Of course I agree, but I think the priority should be to=
 make things as

> > >> simple and easy to understand as possible. They are comp=
lex enough

> > >> anyway.

> > > Thanks,

> > > Rob

> > >

> > >

> > >>

> > >> Thanks, Lada

> > >>

> > >>> Thanks,

> > >>> Rob

> > >>>

> > >>>

> > >>> On 20/10/2017 22:37, Kent Watsen wrote:

> > >>>> All,

> > >>>>

> > >>>> This starts a two-week working group last call o=
n

> > >>>> draft-ietf-netmod-schema-mount-07.

> > >>>>

> > >>>> The working group last call ends on November 3.<=
br>
> > >>>> 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", a=
re welcome!

> > >>>> This is useful and important, even from authors.=


> > >>>>

> > >>>> Could the authors, explicitly CC-ed on this emai=
l,

> > >>>> please also confirm one more time that they are<=
br>
> > >>>> 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/listinf=
o/netmod

> >

> > --

> > Ladislav Lhotka

> > Head, CZ.NIC Labs

> > PGP Key ID: 0xB8F92B08A9F76C67

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.=
org

> > https://www.ietf.org/mailman/listinfo/net=
mod

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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

--

Ladislav Lhotka

Head, CZ.NIC Labs

PGP Key ID: 0xB8F92B08A9F76C67





--001a11401a04e800b5055d905a26--


From nobody Thu Nov  9 10:18: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 420FB12940B for ; Thu,  9 Nov 2017 10:18:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 I7QRkAteBvBx for ; Thu,  9 Nov 2017 10:18:15 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1156612940A for ; Thu,  9 Nov 2017 10:18:09 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 356E3F6F; Thu,  9 Nov 2017 19:18:07 +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 DGzD7XkJoDaM; Thu,  9 Nov 2017 19:18:06 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu,  9 Nov 2017 19:18:07 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8B2C20116; Thu,  9 Nov 2017 19:18:06 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gwkOBdkKWcfe; Thu,  9 Nov 2017 19:18:06 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44E1620114; Thu,  9 Nov 2017 19:18:06 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 5ACAB41515D8; Thu,  9 Nov 2017 19:16:39 +0100 (CET)
Date: Thu, 9 Nov 2017 19:16:38 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: "netmod@ietf.org" , Martin Bjorklund , Kent Watsen 
Message-ID: <20171109181638.zel2otpzrptggvwz@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , "netmod@ietf.org" , Martin Bjorklund , Kent Watsen 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz> <56ea1907-c2ed-1940-089c-527b33f0723e@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: <56ea1907-c2ed-1940-089c-527b33f0723e@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
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: Thu, 09 Nov 2017 18:18:22 -0000

On Thu, Nov 09, 2017 at 05:38:40PM +0000, Robert Wilton wrote:
> 
> > > > > 3. Sec 2.1 Glossary of New Terms: "Schema" isn't actually defined
> > > > > anywhere (RFC 7950 doesn't define this). Should it be defined here?
> > > > > The NMDA datastores draft had a similar issue and we choose to define
> > > > > "datastore schema" instead.
> > > > I think the right place for defining the term "schema" (and "data model"
> > > > as well) is the specification of YANG because it is desirable that all
> > > > documents related to YANG use the same meaning.
> > > OK, 7950 doesn't define it today. Is that a problem?
> > "Schema tree" and "schema node" are defined and used a lot in 7950, so
> > it might be good to define "schema" as well - meaning the schema tree
> > with all associated semantics.
> OK, but we can't add definitions to 7950 now. Would it make sense to add
> the definition to the NMDA draft and reference that?

So what is the difference between "schema tree" and "schema"? Or to
put it differently, what is "all associated semantics" that you are
adding to a "schema tree" to obtain a "schema"? RFC 7950 says:

   o  schema tree: The definition hierarchy specified within a module.

If I understand 'definition hierarchy' correctly, than it seems
"schema" is just an abbreviation of "schema tree", i.e., there is no
semantic difference between these two terms. If there is a difference,
we need to be able to spell it out.

/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 Nov  9 10:21: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 CEDCB1293E0; Thu,  9 Nov 2017 10:21:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 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, URG_BIZ=0.573, 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 Fp3_Mlve6LFN; Thu,  9 Nov 2017 10:21:37 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0118.outbound.protection.outlook.com [104.47.2.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F1C129353; Thu,  9 Nov 2017 10:21:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N3DYII86xtYmoJU3yo3KlGbUV04UXVo5LyyiTjL8Ky4=; b=hWJ4cRiGBN6bMGhelg/k+s08noLxGYfj1keSmJNxGqUi1dP5XKPjHNcGg3cbSaXIq00MiKqQfOPzNQG8gnRtBMl0ZvyQlbvTScy1OUp4GEdZYWJoFpn+qyBIsEwr5BoCf/VjMULrVe7WF6/fw8vy/fChd4nfgNaKJCCO5cP1yG0=
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.218.6; Thu, 9 Nov 2017 18:21:33 +0000
Message-ID: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Jiangyuanlong" , "Alex Campbell" , 
Cc: "Xian Liu" , "Xujinchun" ,  
References: +ADw-150906887826.22201.5033565145094897903.idtracker+AEA-ietfa.amsl.com+AD4-, +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97+AEA-dggeml507-mbx.china.huawei.com+AD4- +ADw-1509329710965.52658+AEA-Aviatnet.com+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8+AEA-dggeml507-mbs.china.huawei.com+AD4- +ADw-02fb01d35893+ACQ-2081f160+ACQ-4001a8c0+AEA-gateway.2wire.net+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62E74B+AEA-dggeml507-mbs.china.huawei.com+AD4-
Date: Thu, 9 Nov 2017 17:47:55 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-7"
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: DB6PR0501CA0006.eurprd05.prod.outlook.com (2603:10a6:4:8f::16) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 7c0bb2d7-2e59-46dd-4bde-08d5279eb552
X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603249); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:pqWp84Y712X91Uc++XFu7Py2rg0wFtdq6TIQj4A6dlg+04cGUEXdrbHKvekWpXo6CYUSCssLEZ7poioTS+PZficBBpz+m5hbF1+FdlLHx4kPmbqCcXK79lo255UEkCT1DPjCsXZjWJEdx5h9yYY8hYzbOGeVoGKdJ7afVJrr78KzxhpYxjRAN9/7QxIZbt8oGFvbLJl/PPAMuOO/LqtY1X6fS3hytH+RqF/sxkS0QtmxS3rGgxItmZ2lxiAdXXtL3ztw44dcOo/ZjVLqoo+ap4y+EAwh1mswLDvxMZ8uG6o=; 25:em6BJaA/oWJVtNi+KtBRMkdNobxzcu0NvdbtyL0BCwk39xEndWHYjM6KWaOnnf0oUdDwBOOd2KyYAx/DZI3LpOvtzfApP39iIUjuP52M+zfbJYAwjO+cdZDs7Q0AQVo+SqjnI84PSb/tuLpxKBTW4v7C2BAcRJ9oKNui98W4yOhAU8IU2LTKbEzdp2zhWavIUFHpbwr2VPpEn6Vv/8MWHIEjGlw5+3eq7FFTP0KAoBZBBKslw84D4Ic/J8fkn1tyqj8qh3CiFxvkFiOGM+flry1jrGJbkcCFh5VMsWltUsJsLMaQMC0htEl9A1DieYPf+TyBh5kMA6khCZa0jPyugg==; 31:mt2R8zVfHmEk92qDTeueRgizAbmMJFtdK/jkbgTr3c1JFQsq+2DT2BTE/XWQDbgyS7HdyBC+7e7unJkgwBln+FJCcEjWgsgydVAAkLccCp+yOqHrQVAkhW4Pu/mZUlEc+yXK2BNjL6hATiyRKbZIl7fNRhMYXZiN38CExWDI2hBda/Ep89bRYgVKhHpqgQXrkeV6Q2zaw7pXWE4F9qGstnKX/LMR+DbR0QLKbidOhc8=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(278428928389397)(120809045254105)(50582790962513)(100405760836317)(265557217796441)(145744241990776);
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)(3231021)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(61426038)(61427038)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(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:jdP+QzPBc5xX/7DzOJ6Rf0WgpjoiVCCLyYMYtEDPxh5SccYCTmjIyPZM89QIjQ1+t6r3qFTZIBC70BXJB+sZ5i7bDkRQRC45yZhPhx1Fe9yDjgLxX/s5LxSCnIe9OfDaW3p7164cCl6uglBt0lD4xVMELuwKo/5D6kv32dfrItAESDDrxvoOMb++bdVnNchK9pd/L2XhxCqY764BlXkxrlsuZuUNWRoHHE1nmqm4JjBtmEPv91a/gLa9lFFM0RUH8FjNAgwjuUOaA2lhPsdAjH328BGA/fC4BO0GRZXOiN+YAxDWyAog0NiFYcUw+xkT78MQvTAdIeZBPX5Fru+zBTUxzYO+xc9CmcLHLThk7a7gBWQTSjUrTaZc2ZC2y4sCqHXZ6EjW2VEqGrd9A4MHhDq7m6R6Bp8ZFvKMAyEpeYs4ZAGqzBe15UFug+50guHxp162LHlwWjpZQyU+1IjQrn7hUgKMT9YZzu7nHfcvpRBDJf/wtHvS7tJGASphp8i/5AGak0lUgoi7JUrk3DqyIA==
X-Forefront-PRVS: 0486A0CB86
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(51444003)(189002)(43784003)(199003)(377424004)(13464003)(33646002)(68736007)(1556002)(105586002)(97736004)(7736002)(4001150100001)(50466002)(305945005)(110136005)(316002)(106356001)(54906003)(8676002)(9686003)(5660300001)(8936002)(6306002)(86362001)(61296003)(6246003)(6496005)(2906002)(4326008)(6116002)(230700001)(53936002)(81166006)(81156014)(3846002)(478600001)(47776003)(966005)(1456003)(84392002)(53546010)(6666003)(229853002)(62236002)(66066001)(4720700003)(44716002)(50226002)(25786009)(16526018)(116806002)(6486002)(189998001)(76176999)(44736005)(50986999)(81816999)(81686999)(14496001)(101416001)(230783001)(48020200001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDI7MjM6OFhYbWJpeG9ROEsySUtMMHgyREVEdHhQ?= =?utf-8?B?MXdzNEUrcmgvY25RYzNCN2pWRk9oQndxSmNXeEkvcVg5Znk5VUtKSkw3UStz?= =?utf-8?B?ZFc3REVFMW0vd3BJN3ZtK1ZZd0REUHBiRGdVTlpoV3BMd0JEaEUyWlgzWGhY?= =?utf-8?B?eEJhb0ZXd2RXRWtPL3RKdm1GdFBlSlFGQUdDTWJXMzlHSjJXeUxDYVNVNjhJ?= =?utf-8?B?YTVHTXlTSnpsbE1zbjYxUllVUHRTc1BNMGxZNjY5WXhML1h6aHBsR1V5bkxw?= =?utf-8?B?Tnp1TzgxUlU1YkhjZEs5WXR3QitVT2lFLzk5TWZOc1pmZXJmazdPZnRiU1I4?= =?utf-8?B?MjR4c29WTStqdUlhZDYrWDNyUGYvaFdIQmFtRGVVaWRRMXBvSVRLakhKb0lx?= =?utf-8?B?S1BIU1ZTR1dUQ2JIT2Zoak9wUkFuU3ZyWEVkTnM1OWVzZ2tRRGk0aThrdThR?= =?utf-8?B?REd5UEFPQldlYUlQK0V3cE96dG1ubEt4SGxsL2E2MHdJKzdoNm5TMXdOMmI3?= =?utf-8?B?aHBqOVhOL1J1RHZkeGpQWFNSdGxCTDVsWGMyWjNzWFQ0RGFJenZoNENMVml3?= =?utf-8?B?cnc1VVZzS241VmJXMElTdlVrZ1ByZ1JmNWpRVUFJT0FvNmRUSzlCWW9Eb3dv?= =?utf-8?B?MzhPK3VYTGpXRFZGUitaYndpWXh4emQrdGxZSkl3Y0lNbkZJaEVORFUxdVlO?= =?utf-8?B?RkNFM1NsWDdzWklwZDFnYmw2NzZ5Mm9uN2lFVVJpWjZSKzc5RVJSVFpXU24z?= =?utf-8?B?Q1BFMWxWUGx2QWVmWHQybENReGNkZ081Q08rUG9tS2FGbEM4dk40d21kT3Jo?= =?utf-8?B?N2lkYzZtSUFnQ1JjRjBXaXdvQmtwTnZOcmFrY0VqS2wreitJN3hLWUdJMjdt?= =?utf-8?B?QzhxRFVTUmZ2V05YS1hiM2E4WXo2NlQyZ0UzNUtVQ0hST01XUzFaUkE4M2VW?= =?utf-8?B?VFNSVGYzS0YvbWdmbUlUL3JYWW55bU5hVFVLekNYSlN0L1FJTEpPUnd6V1BF?= =?utf-8?B?Z0g1U3BGTXhIVU5QdjdsL1NVR0tqSktOelo5R3JVK3dBWmE5RlJVbkhGSHZu?= =?utf-8?B?OVVnY1h5MmhVTytjR2J0NEdoM1l5cXZPZkUrTGNBc2lvby84YnhGMitHM3pU?= =?utf-8?B?ZFlaakdtb0FyUDZDK2EvNXhwdTBsTEY2VjBVNGd5T2xHVFNyaDRXUEJ3bWdn?= =?utf-8?B?RGJwcFpWZWRpMlVEU1NFa0F6T05jSDZBdTg5a3plODhUT3lLUGhGcjh4ZnRx?= =?utf-8?B?dTZ2QmhOZHFwdW1PbUVvb0t2Y2VJQ2oxVjYxTjFRSzFCN0tpa0RPWmdYWHI5?= =?utf-8?B?ZW8xejFncWFXQ1RHeUc1Vk45SHNlaWwxT2JCcDZoeUY0ckRzV0RCVCtkRzNn?= =?utf-8?B?MkZKQ3RXRTUxMFExRUdUY1BUVkxWMjF0TXU4QVBsQVFGc0ZBSnhtSlVNVmtP?= =?utf-8?B?ZDJhOUNlb01LaVJmUHBleDg4dUViRGhJVzdYYmlHYkVMODliVlk2RHl2RlJV?= =?utf-8?B?d1RpcG05T1UxMmlWK21qUWhMVHNtZC9BSlpCcHJTUWh3ZERrYThFdkxnMVFy?= =?utf-8?B?N1hhTmpLY0dPcW9qOTN1YlNYVHVweERsT09VM3hXbHhFNGlYdnBOWVY0S1F0?= =?utf-8?B?RWo0VndXSElVT0VXbGkxVVJLaG1vUmk0Zk51OG5zb3dsNTFPV1hUZHNHSUQw?= =?utf-8?B?YjlzcCszRkRlRUZZdXdUeDlENmREbnh3WUpRUDlpbkZhaU5CaWdsT213aUIw?= =?utf-8?B?Z3oyL1VPQVdQTmdJanZrS2t0UjNCbW96YUF4Y1M3VG5rdTduUG9TNzgwWnhy?= =?utf-8?B?dTR5bHNwK1BKc1pURUJNaTc0ZG1zZFErenl2aUlqVWtXWkhmMzQ5Qy9GK0xr?= =?utf-8?B?OVk2cENsLzhFbkNTNWthSldrb1VId3FyUUJ5KzRjSVI2c1Z2YVNpVnAwSm9o?= =?utf-8?B?OTZkYXUwMkE0TDRxTFFlZ3dMTE90NGs4cWRwWlRIaHRxRzg4aHcvL2tEQ1Fw?= =?utf-8?B?MUNlZVhvT0ZTYjcxdnNZdkJQS05YcHRpZ255b0lHMWRvaTY0d0pLSE84S1Bh?= =?utf-8?B?UDhuR1RWRXlUZ3lJaUV6a0tlb2VVODhPM2k0NDlrVHRDMStjS25Cb3pGY2lD?= =?utf-8?Q?lF4KzlUoO/u2PwtJo9oJajNzs=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:LO0eA7wgCq2w2lRyHHLbpiGOYAbwmYikSlBJ+KUn50Bz3eY6pP+vL9AEdoNP1P/OXHTxI63NXS65Y2nbWcixbT5kSdluGxVKIvgACoFsVJfKAFe/L7VFM5Ww+vN59NOIJt7LKM6sFnZ7f1ZXfa7LDyE5HSWS4ymTaR5EBbBkXORVYzkmhRqGxibu+550s6GeGaHkpTUMUDtfbJ8sfcaZDU+UZ/U6P3h71bK343FnBaNc3Dbiay0sfclhDhXZil8NJ6WJVobZzU+eIWwf8bx81u3r41MmUbMEU2Bypzd/i2CDKEO2Nbwo8xBkZ6Ixm/cF/DkX4ucqCmif2t30QEEETvK1O6HTn8dVEFXKvVOWC0A=; 5:aK2gsEceai5PX4v2jFByr//PBHD1+ylLTUvdHUZpA+LUL6rp5a9Ewv07FUvtcbZz5jfqwuJ87PgeSzeGI8DomVrgrKpEUJDClfENeuY1I5biz3JwdfOn301RFRQ81k1Yai3Bhe4/s3lo0ex0t5pTCWSjsWPWrNrqDKC67ojKkDc=; 24:Np1LiuOKJxAebi6b0bb2wqoeXv1fElroHI6RMpbUeDSnLs3MelOg7jpYNP/xanP4l74+fmmqNBj3XK8+Z+YYxWzEAwlhBFd4YploUIv7nto=; 7:GX9AILRI/SjmU52eZipmtnqSSsdXzVJzgFv9VBEP65CkSU9+rNNjzG4re6RO5eI9iI/lQZHFqBxTObJUGJBKQkBLPPN/qIxCSnWgp+6vquZc/S8Nqj2l1JPqb5E7k6JfM2mISDjjy6vRNRex16gqpYz7SgcW4TUdsvzAI0w0qMVjsANF9pt/mS2ZuLo+iGNajGveGIDD231rJoiaaDkf/hC8sLSR+/Zd5OnuUBYEyj8HlSqJg00J6CUdDZFyULin
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2017 18:21:33.4428 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c0bb2d7-2e59-46dd-4bde-08d5279eb552
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] +AFs-netmod+AF0- 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: Thu, 09 Nov 2017 18:21:41 -0000

----- Original Message -----
From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4-
Sent: Thursday, November 09, 2017 1:58 AM

Tom,

Good to know all your viewpoints. We will add a sentence in Section 2
explaining the logic of YANG style names in this document, maybe put it
as a note in the 2nd paragraph (as these names are used in the 3rd
paragraph) .

+ADw-tp+AD4-

Yuanlong,

Another belated thought.

It is common practice, and I think a good one, to include a sentence
just before the YANG module giving Normative references to other RFC
andsuch like that are referenced, implicitly or explicitly, in the
module itself (which, of course, cannot contain the references in the
same way that the rest of the RFC can).  The sentence does not become
part of the YANG module but anyone harking back to the RFC will quickly
find where to go for more information.

draft-ietf-netmod-rfc7277bis-00 gives a good example of this.  For this
I-D, I would suggest references to IEEE Std 1588-2008 and the RFC from
which ietf-interfaces is imported.

Tom Petch


Thanks,
Yuanlong

-----Original Message-----
From: t.petch +AFs-mailto:ietfc+AEA-btconnect.com+AF0-
Sent: Wednesday, November 08, 2017 9:12 PM
To: Jiangyuanlong+ADs- Alex Campbell+ADs- tictoc+AEA-ietf.org
Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules
is woefully weak).

I think too that you are spot on with your terminology+ADs- where IEEE
1588-2008 has an accepted way of working, then that is the right way for
this I-D.

One fresh comment arising from that.  You commented earlier that you had
departed from IEEE 1588-2008 in changing camel case to the YANG style
names, with hyphens, and I think that that is a logical choice.  But I
would go further and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put
that+ADs- probably Section 2, perhaps immediately before the tree diagram,
since that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would
be worth having a concordance of IEEE 1588-2008 names and YANG names+ADs-
this was common practice with MIB Modules.

Tom Petch

----- Original Message -----
From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4-
To: +ACI-Alex Campbell+ACI- +ADw-Alex.Campbell+AEA-Aviatnet.com+AD4AOw- +ADw-tictoc+AEA-ietf.org+AD4-
Cc: +ACI-Xian Liu+ACI- +ADw-lene.liuxian+AEA-foxmail.com+AD4AOw- +ACI-Xujinchun+ACI-
+ADw-xujinchun+AEA-huawei.com+AD4AOw- +ADw-netmod+AEA-ietf.org+AD4-
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


+AD4- Hi Alex,
+AD4-
+AD4- Sorry for a late reply as I spent the last week for an urgent business
trip.
+AD4- Please see my comments in line with +AFs-YJ+AF0-
+AD4-
+AD4- Thanks,
+AD4- Yuanlong
+AD4-
+AD4- -----Original Message-----
+AD4- From: Alex Campbell +AFs-mailto:Alex.Campbell+AEA-Aviatnet.com+AF0-
+AD4- Sent: Monday, October 30, 2017 10:15 AM
+AD4- To: Jiangyuanlong+ADs- tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Hi,
+AD4- I've reviewed this latest draft and have some more comments.
+AD4-
+AD4- 1. I find the introduction to be unnecessarily wordy+ADs- it feels like it
was written with a view of not missing any information out, rather than
trying to keep it concise.
+AD4-    For example, there is no need to elaborate on YANG data types here.
It is also not here to sell YANG.
+AD4-
+AD4- +AFs-YJ+AF0- Yes, we are trying to give some introductory information for an
outsider who may not be familiar with PTP or YANG, and explain why a
YANG for PTP is needed. The juicy part of this document is its YANG
module, and people can skip all the other texts if they are familiar
with PTP and YANG.
+AD4- Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear
message from the TICTOC chairs to introduce any big changes at this last
call stage.
+AD4-
+AD4-
+AD4- OLD:
+AD4-
+AD4-    As a synchronization protocol, IEEE 1588-2008 +AFs-IEEE1588+AF0- is widely
+AD4-    supported in the carrier networks, industrial networks, automotive
+AD4-    networks, and many other applications. It can provide high
+AD4-    precision time synchronization as fine as nano-seconds. The
+AD4-    protocol depends on a Precision Time Protocol (PTP) engine to
+AD4-    decide its own state automatically, and a PTP transportation layer
+AD4-    to carry the PTP timing and various quality messages. The
+AD4-    configuration parameters and state data sets of IEEE 1588-2008 are
+AD4-    numerous.
+AD4-
+AD4-    According to the concepts described in +AFs-RFC3444+AF0-, IEEE 1588-2008
+AD4-    itself provides an information model in its normative
+AD4-    specifications for the data sets (in IEEE 1588-2008 clause 8). Some
+AD4-    standardization organizations including the IETF have specified
+AD4-    data models in MIBs (Management Information Bases) for IEEE 1588-
+AD4-    2008 data sets (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0-). These MIBs are
+AD4-    typically focused on retrieval of state data using the Simple
+AD4-    Network Management Protocol (SNMP), furthermore, configuration of
+AD4-    PTP data sets is not considered in +AFs-RFC8173+AF0-.
+AD4-
+AD4-    Some service providers and applications require that the management
+AD4-    of the IEEE 1588-2008 synchronization network be flexible and more
+AD4-    Internet-based (typically overlaid on their transport networks).
+AD4-    Software Defined Network (SDN) is another driving factor, which
+AD4-    demands an improved configuration capability of synchronization
+AD4-    networks.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
+AD4-    configuration and state data manipulated by network management
+AD4-    protocols like the Network Configuration Protocol (NETCONF)
+AD4-    +AFs-RFC6241+AF0-. A small set of built-in data types are defined in
+AD4-    +AFs-RFC6020+AF0-, and a collection of common data types are further
+AD4-    defined in +AFs-RFC6991+AF0-. Advantages of YANG include Internet based
+AD4-    configuration capability, validation, rollback and so on. All of
+AD4-    these characteristics make it attractive to become another
+AD4-    candidate modeling language for IEEE 1588-2008.
+AD4-
+AD4- NEW:
+AD4-
+AD4-    IEEE 1588-2008 is a time protocol that provides high precision time
+AD4-    synchronization as fine as nano-seconds.
+AD4-
+AD4-    IEEE 1588-2008 itself provides an information model in its
normative
+AD4-    specifications for the data sets (IEEE 1588-2008 clause 8).
+AD4-    Standard information models (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0-) have
been
+AD4-    previously defined as MIBs focused on the retrieval of state data
using
+AD4-    SNMP +AFs-RFC1157+AF0-.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
configuration
+AD4-    and state data manipulated by network management protocols like
NETCONF
+AD4-    +AFs-RFC6241+AF0-.
+AD4-
+AD4- 2. Can we refer to the system as simply PTP rather than IEEE
1588(-2008)?
+AD4- +AFs-YJ+AF0- Advice from IEEE 1588 is, we need to use +ACI-1588-2008+ACI- as much as
possible to help clarify that the scope of this YANG is limited to the
published 1588 standard.
+AD4-
+AD4-
+AD4- 3. There is insufficient spacing here to separate the terms from their
definitions:
+AD4- OLD
+AD4-
+AD4-    PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
+AD4-    for PTP protocol decisions and for providing values for PTP message
+AD4-    fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance A PTP implementation in the device (i.e., an OC or BC)
+AD4-    represented by a specific PTP dataset.
+AD4-
+AD4- NEW
+AD4-
+AD4-    PTP dataset
+AD4-      Structured attributes of clocks (an OC, BC or TC) used
+AD4-      for PTP protocol decisions and for providing values for PTP
message
+AD4-      fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance
+AD4-      A PTP implementation in the device (i.e., an OC or BC)
+AD4-      represented by a specific PTP dataset.
+AD4- +AFs-YJ+AF0- OK.
+AD4-
+AD4- 4. There's a singular/plural mismatch here:
+AD4-
+AD4-    module. Query and configuration of device wide or port specific
+AD4-    configuration information and clock data set is described for this
+AD4-    version.
+AD4- +AFs-YJ+AF0- Good, we will change 'is' to 'are'.
+AD4-
+AD4- and here:
+AD4-
+AD4-    Query and configuration of clock information include:
+AD4-
+AD4-
+AD4- 5. The choice of uint16 as instance-number limits implementations to
65536 distinct instances.
+AD4-    While I have a hard time imagining a system with more than 65536
PTP instances, I would prefer to avoid imposing arbitrary limits.
+AD4-    I would recommend changing instance-number to a string (and
renaming it to instance-name or just name).
+AD4- +AFs-YJ+AF0- The 1588-2008 supports multiple instances of PTP, but it is
ambiguous in its organization of those PTP instances, especially with
regard to management.
+AD4-  In the 1588 new revision, there is an explicit list of PTP instances,
and that list is indexed using a number (not name). Thus to align with
the new revision, we need to keep it instance-number.
+AD4-  If 65536 limit is a concern, how about change it to uint32, any
concerns?
+AD4-
+AD4-
+AD4- 6. I still recommend removing -ds from the YANG element names that
still include it. It doesn't appear to add any value.
+AD4- +AFs-YJ+AF0- Rodney's opinion: the value of using 'ds' is that the 1588
document on which this YANG model is based uses +ACI-DefaultDS+ACI- as a term.
PTP experts even say +ACI-default dee ess+ACI- verbally when referring to this
data. If we changed this to just +ACI-default+ACI-, PTP experts might assume
that we are referring to something entirely new to YANG. Thus, to align
with 1588-2008, the same set of terminologies are used.
+AD4-
+AD4- 7. What+ADs-s the relevance of injection attacks relevant to this YANG
module?
+AD4- +AFs-YJ+AF0- This is a general statement which is applicable to this YANG
module and other YANG modules as well.
+AD4- Thanks again,
+AD4- Yuanlong
+AD4-
+AD4- Alex
+AD4-
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-
+AD4- From: netmod +ADw-netmod-bounces+AEA-ietf.org+AD4- on behalf of Jiangyuanlong
+ADw-jiangyuanlong+AEA-huawei.com+AD4-
+AD4- Sent: Friday, 27 October 2017 3:21 p.m.
+AD4- To: tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Dear all,
+AD4-
+AD4- Based on all the comments we received during the WG Last Call process,
we've updated the document to version 6.
+AD4- We believe all the LC comments are resolved and the consensus is
reflected in this new revision.
+AD4- Many thanks to Martin, Tal, Opher, Alex, John and many others who had
reviewed and commented on this draft.
+AD4-
+AD4- Cheers,
+AD4- Yuanlong on behalf of all coauthors
+AD4-
+AD4- -----Original Message-----
+AD4- From: internet-drafts+AEA-ietf.org +AFs-mailto:internet-drafts+AEA-ietf.org+AF0-
+AD4- Sent: Friday, October 27, 2017 9:48 AM
+AD4- To: Xian Liu+ADs- Rodney Cummings+ADs- rodney.cummings+AEA-ni.com+ADs- Jiangyuanlong+ADs-
Xujinchun
+AD4- Subject: New Version Notification for
draft-ietf-tictoc-1588v2-yang-06.txt
+AD4-
+AD4-
+AD4- A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
+AD4- has been successfully submitted by Yuanlong Jiang and posted to the
IETF repository.
+AD4-
+AD4- Name:           draft-ietf-tictoc-1588v2-yang
+AD4- Revision:       06
+AD4- Title:          YANG Data Model for IEEE 1588-2008
+AD4- Document date:  2017-10-26
+AD4- Group:          tictoc
+AD4- Pages:          30
+AD4- URL:
https://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588v2-yang-06.tx
t
+AD4- Status:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
+AD4- Htmlized:
https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-06
+AD4- Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-06
+AD4- Diff:
https://www.ietf.org/rfcdiff?url2+AD0-draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Abstract:
+AD4-    This document defines a YANG data model for the configuration of
+AD4-    IEEE 1588-2008 devices and clocks, and also retrieval of the
+AD4-    configuration information, data set and running states of IEEE
+AD4-    1588-2008 clocks.
+AD4-
+AD4-
+AD4-
+AD4-
+AD4- 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.
+AD4-
+AD4- The IETF Secretariat
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://www.ietf.org/mailman/listinfo/netmod
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Nov  9 13:19: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 4E477129B95 for ; Thu,  9 Nov 2017 13:19:40 -0800 (PST)
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, 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 EpLKGf0N7b6j for ; Thu,  9 Nov 2017 13:19:39 -0800 (PST)
Received: from mail-pf0-f196.google.com (mail-pf0-f196.google.com [209.85.192.196]) (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 3983E129B8B for ; Thu,  9 Nov 2017 13:19:39 -0800 (PST)
Received: by mail-pf0-f196.google.com with SMTP id 17so5151674pfn.12 for ; Thu, 09 Nov 2017 13:19:39 -0800 (PST)
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=4DffK9b3JAl4vwx9D4haYkriVVNtZYCgdaY7qhjOV5I=; b=FY35PqylZXvc4z2bSmhEzZu9shTXm3A+nS5eSrzf+s07me6p9mbjN4YFqdXFhUQG3G wBK+GRN+pwJzl4mMJgrgagr0bOgAl359dWdiaAO0J8tMSgWbs9kvhvp9OZT0lTz9TFdC PJZPVGufl3W7SI/29752nLF+ylBgtTuIWkVs4fUQxJHMqLiWwcqgMHgYrWX/EJjDAcDb Gd3F1gL2M4wCJI0LQdqQZfXRezpusp3HYTbxYo6jm1MNO6JW+6sEPSDWAGG5Iw1EK8fk H7+HL2OhPJTK1ZzCAMNiJ/BqKeE1y7ViRq55uUfzyWhOAhQV+0vp3Y4ZVYIvlhaPWOH+ +UAQ==
X-Gm-Message-State: AJaThX4HVc4xgjLgf3W0XCry9rOmHef++AmmSeEqkVk+4LEt6SoFBWtP 8sSkoAFt4iE72KHvlUUB7imTjGEQMM4=
X-Google-Smtp-Source: ABhQp+SqO/kS/8gtcFi5qDPk2Iw8lfBkoNSeiIuH1pXsCGsxWRTK7XQXf8VxP1NSj44e/MWYNmltbw==
X-Received: by 10.101.99.199 with SMTP id n7mr1773885pgv.247.1510262378471; Thu, 09 Nov 2017 13:19:38 -0800 (PST)
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 d89sm14958270pfb.121.2017.11.09.13.19.37 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 13:19:37 -0800 (PST)
To: netmod@ietf.org
References: <01a4beef-4a86-fa10-dc81-7dd57e12a9a8@ericsson.com>
From: Randy Presuhn 
Message-ID: <238531b7-03dc-32be-b9f0-0cdef8cc17bb@alumni.stanford.edu>
Date: Thu, 9 Nov 2017 13:19:37 -0800
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: <01a4beef-4a86-fa10-dc81-7dd57e12a9a8@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] rfc7223bis Backward compatibility in YANG - BAD !!!
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 09 Nov 2017 21:19:40 -0000

Hi -

On 11/9/2017 8:59 AM, Balazs Lengyel wrote:
...
>  From an NMS point of view the current definition just states: Anything 
> can be deprecated/obsoleted anytime. If something has a status different 
> from current there is no guarantee its usable or even that it exists.

Robust NMS software needs to take this stance anyway.  Deprecation and
obsolescence are not the only reasons something may become unusable or
disappear.  Consider, for example, changing access control policies,
hot swap / insertion, and outright failures or bugs.  A management
application that cannot deal with these possibilities isn't ready
for the real world, IMO.

Randy


From nobody Thu Nov  9 17:27: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 0656D127201; Thu,  9 Nov 2017 17:27:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.648
X-Spam-Level: 
X-Spam-Status: No, score=-3.648 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, URG_BIZ=0.573] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LFtF07JE0-a; Thu,  9 Nov 2017 17:27:18 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD9512426E; Thu,  9 Nov 2017 17:27:16 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSH37861; Fri, 10 Nov 2017 01:27:14 +0000 (GMT)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 10 Nov 2017 01:27:13 +0000
Received: from DGGEML507-MBS.china.huawei.com ([169.254.1.221]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0361.001; Fri, 10 Nov 2017 09:27:04 +0800
From: Jiangyuanlong 
To: "t.petch" , Alex Campbell , "tictoc@ietf.org" 
CC: Xian Liu , Xujinchun , "netmod@ietf.org" 
Thread-Topic: +AFs-netmod+AF0- WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTWYecwxNLJMnL1U+IWAzhBxBreaMMzxUg
Date: Fri, 10 Nov 2017 01:27:03 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB62EDD5@dggeml507-mbs.china.huawei.com>
References: +ADw-150906887826.22201.5033565145094897903.idtracker+AEA-ietfa.amsl.com+AD4-, +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97+AEA-dggeml507-mbx.china.huawei.com+AD4- +ADw-1509329710965.52658+AEA-Aviatnet.com+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8+AEA-dggeml507-mbs.china.huawei.com+AD4- +ADw-02fb01d35893+ACQ-2081f160+ACQ-4001a8c0+AEA-gateway.2wire.net+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62E74B+AEA-dggeml507-mbs.china.huawei.com+AD4- <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net>
In-Reply-To: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net>
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-7"
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.5A050073.00CE, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.221, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c95ee8e44771bee32d2d4d4d3fdc5d53
Archived-At: 
Subject: Re: [netmod] +AFs-netmod+AF0- 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, 10 Nov 2017 01:27:21 -0000

Dear Tom,

Good suggestion, we will adding this note of references at the beginning of=
 Section 3.

Cheers,
Yuanlong

-----Original Message-----
From: t.petch +AFs-mailto:ietfc+AEA-btconnect.com+AF0-=20
Sent: Friday, November 10, 2017 1:48 AM
To: Jiangyuanlong+ADs- Alex Campbell+ADs- tictoc+AEA-ietf.org
Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
Subject: Re: +-AFs-netmod+-AF0- WG Last Call resolutions incorporated in dr=
aft-ietf-tictoc-1588v2-yang-06

----- Original Message -----
From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4-
Sent: Thursday, November 09, 2017 1:58 AM

Tom,

Good to know all your viewpoints. We will add a sentence in Section 2 expla=
ining the logic of YANG style names in this document, maybe put it as a not=
e in the 2nd paragraph (as these names are used in the 3rd
paragraph) .

+ADw-tp+AD4-

Yuanlong,

Another belated thought.

It is common practice, and I think a good one, to include a sentence just b=
efore the YANG module giving Normative references to other RFC andsuch like=
 that are referenced, implicitly or explicitly, in the module itself (which=
, of course, cannot contain the references in the same way that the rest of=
 the RFC can).  The sentence does not become part of the YANG module but an=
yone harking back to the RFC will quickly find where to go for more informa=
tion.

draft-ietf-netmod-rfc7277bis-00 gives a good example of this.  For this I-D=
, I would suggest references to IEEE Std 1588-2008 and the RFC from which i=
etf-interfaces is imported.

Tom Petch


Thanks,
Yuanlong

-----Original Message-----
From: t.petch +AFs-mailto:ietfc+AEA-btconnect.com+AF0-
Sent: Wednesday, November 08, 2017 9:12 PM
To: Jiangyuanlong+ADs- Alex Campbell+ADs- tictoc+AEA-ietf.org
Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules is w=
oefully weak).

I think too that you are spot on with your terminology+ADs- where IEEE
1588-2008 has an accepted way of working, then that is the right way for th=
is I-D.

One fresh comment arising from that.  You commented earlier that you had de=
parted from IEEE 1588-2008 in changing camel case to the YANG style names, =
with hyphens, and I think that that is a logical choice.  But I would go fu=
rther and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put that=
+ADs- probably Section 2, perhaps immediately before the tree diagram, sinc=
e that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would be =
worth having a concordance of IEEE 1588-2008 names and YANG names+ADs- this=
 was common practice with MIB Modules.

Tom Petch

----- Original Message -----
From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4-
To: +ACI-Alex Campbell+ACI- +ADw-Alex.Campbell+AEA-Aviatnet.com+AD4AOw- +AD=
w-tictoc+AEA-ietf.org+AD4-
Cc: +ACI-Xian Liu+ACI- +ADw-lene.liuxian+AEA-foxmail.com+AD4AOw- +ACI-Xujin=
chun+ACI-
+ADw-xujinchun+AEA-huawei.com+AD4AOw- +ADw-netmod+AEA-ietf.org+AD4-
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


+AD4- Hi Alex,
+AD4-
+AD4- Sorry for a late reply as I spent the last week for an urgent busines=
s
trip.
+AD4- Please see my comments in line with +AFs-YJ+AF0-
+AD4-
+AD4- Thanks,
+AD4- Yuanlong
+AD4-
+AD4- -----Original Message-----
+AD4- From: Alex Campbell +AFs-mailto:Alex.Campbell+AEA-Aviatnet.com+AF0-
+AD4- Sent: Monday, October 30, 2017 10:15 AM
+AD4- To: Jiangyuanlong+ADs- tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Hi,
+AD4- I've reviewed this latest draft and have some more comments.
+AD4-
+AD4- 1. I find the introduction to be unnecessarily wordy+ADs- it feels li=
ke it
was written with a view of not missing any information out, rather than try=
ing to keep it concise.
+AD4-    For example, there is no need to elaborate on YANG data types here=
.
It is also not here to sell YANG.
+AD4-
+AD4- +AFs-YJ+AF0- Yes, we are trying to give some introductory information=
 for an
outsider who may not be familiar with PTP or YANG, and explain why a YANG f=
or PTP is needed. The juicy part of this document is its YANG module, and p=
eople can skip all the other texts if they are familiar with PTP and YANG.
+AD4- Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear message f=
rom the TICTOC chairs to introduce any big changes at this last call stage.
+AD4-
+AD4-
+AD4- OLD:
+AD4-
+AD4-    As a synchronization protocol, IEEE 1588-2008 +AFs-IEEE1588+AF0- i=
s widely
+AD4-    supported in the carrier networks, industrial networks, automotive
+AD4-    networks, and many other applications. It can provide high
+AD4-    precision time synchronization as fine as nano-seconds. The
+AD4-    protocol depends on a Precision Time Protocol (PTP) engine to
+AD4-    decide its own state automatically, and a PTP transportation layer
+AD4-    to carry the PTP timing and various quality messages. The
+AD4-    configuration parameters and state data sets of IEEE 1588-2008 are
+AD4-    numerous.
+AD4-
+AD4-    According to the concepts described in +AFs-RFC3444+AF0-, IEEE 158=
8-2008
+AD4-    itself provides an information model in its normative
+AD4-    specifications for the data sets (in IEEE 1588-2008 clause 8). Som=
e
+AD4-    standardization organizations including the IETF have specified
+AD4-    data models in MIBs (Management Information Bases) for IEEE 1588-
+AD4-    2008 data sets (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0-). The=
se MIBs are
+AD4-    typically focused on retrieval of state data using the Simple
+AD4-    Network Management Protocol (SNMP), furthermore, configuration of
+AD4-    PTP data sets is not considered in +AFs-RFC8173+AF0-.
+AD4-
+AD4-    Some service providers and applications require that the managemen=
t
+AD4-    of the IEEE 1588-2008 synchronization network be flexible and more
+AD4-    Internet-based (typically overlaid on their transport networks).
+AD4-    Software Defined Network (SDN) is another driving factor, which
+AD4-    demands an improved configuration capability of synchronization
+AD4-    networks.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
+AD4-    configuration and state data manipulated by network management
+AD4-    protocols like the Network Configuration Protocol (NETCONF)
+AD4-    +AFs-RFC6241+AF0-. A small set of built-in data types are defined =
in
+AD4-    +AFs-RFC6020+AF0-, and a collection of common data types are furth=
er
+AD4-    defined in +AFs-RFC6991+AF0-. Advantages of YANG include Internet =
based
+AD4-    configuration capability, validation, rollback and so on. All of
+AD4-    these characteristics make it attractive to become another
+AD4-    candidate modeling language for IEEE 1588-2008.
+AD4-
+AD4- NEW:
+AD4-
+AD4-    IEEE 1588-2008 is a time protocol that provides high precision tim=
e
+AD4-    synchronization as fine as nano-seconds.
+AD4-
+AD4-    IEEE 1588-2008 itself provides an information model in its
normative
+AD4-    specifications for the data sets (IEEE 1588-2008 clause 8).
+AD4-    Standard information models (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021=
AS+AF0-) have
been
+AD4-    previously defined as MIBs focused on the retrieval of state data
using
+AD4-    SNMP +AFs-RFC1157+AF0-.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
configuration
+AD4-    and state data manipulated by network management protocols like
NETCONF
+AD4-    +AFs-RFC6241+AF0-.
+AD4-
+AD4- 2. Can we refer to the system as simply PTP rather than IEEE
1588(-2008)?
+AD4- +AFs-YJ+AF0- Advice from IEEE 1588 is, we need to use +ACI-1588-2008+=
ACI- as much as
possible to help clarify that the scope of this YANG is limited to the publ=
ished 1588 standard.
+AD4-
+AD4-
+AD4- 3. There is insufficient spacing here to separate the terms from thei=
r
definitions:
+AD4- OLD
+AD4-
+AD4-    PTP dataset  Structured attributes of clocks (an OC, BC or TC) use=
d
+AD4-    for PTP protocol decisions and for providing values for PTP messag=
e
+AD4-    fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance A PTP implementation in the device (i.e., an OC or BC=
)
+AD4-    represented by a specific PTP dataset.
+AD4-
+AD4- NEW
+AD4-
+AD4-    PTP dataset
+AD4-      Structured attributes of clocks (an OC, BC or TC) used
+AD4-      for PTP protocol decisions and for providing values for PTP
message
+AD4-      fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance
+AD4-      A PTP implementation in the device (i.e., an OC or BC)
+AD4-      represented by a specific PTP dataset.
+AD4- +AFs-YJ+AF0- OK.
+AD4-
+AD4- 4. There's a singular/plural mismatch here:
+AD4-
+AD4-    module. Query and configuration of device wide or port specific
+AD4-    configuration information and clock data set is described for this
+AD4-    version.
+AD4- +AFs-YJ+AF0- Good, we will change 'is' to 'are'.
+AD4-
+AD4- and here:
+AD4-
+AD4-    Query and configuration of clock information include:
+AD4-
+AD4-
+AD4- 5. The choice of uint16 as instance-number limits implementations to
65536 distinct instances.
+AD4-    While I have a hard time imagining a system with more than 65536
PTP instances, I would prefer to avoid imposing arbitrary limits.
+AD4-    I would recommend changing instance-number to a string (and
renaming it to instance-name or just name).
+AD4- +AFs-YJ+AF0- The 1588-2008 supports multiple instances of PTP, but it=
 is
ambiguous in its organization of those PTP instances, especially with regar=
d to management.
+AD4-  In the 1588 new revision, there is an explicit list of PTP instances=
,
and that list is indexed using a number (not name). Thus to align with the =
new revision, we need to keep it instance-number.
+AD4-  If 65536 limit is a concern, how about change it to uint32, any
concerns?
+AD4-
+AD4-
+AD4- 6. I still recommend removing -ds from the YANG element names that
still include it. It doesn't appear to add any value.
+AD4- +AFs-YJ+AF0- Rodney's opinion: the value of using 'ds' is that the 15=
88
document on which this YANG model is based uses +ACI-DefaultDS+ACI- as a te=
rm.
PTP experts even say +ACI-default dee ess+ACI- verbally when referring to t=
his data. If we changed this to just +ACI-default+ACI-, PTP experts might a=
ssume that we are referring to something entirely new to YANG. Thus, to ali=
gn with 1588-2008, the same set of terminologies are used.
+AD4-
+AD4- 7. What+ADs-s the relevance of injection attacks relevant to this YAN=
G
module?
+AD4- +AFs-YJ+AF0- This is a general statement which is applicable to this =
YANG
module and other YANG modules as well.
+AD4- Thanks again,
+AD4- Yuanlong
+AD4-
+AD4- Alex
+AD4-
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-
+AD4- From: netmod +ADw-netmod-bounces+AEA-ietf.org+AD4- on behalf of Jiang=
yuanlong
+ADw-jiangyuanlong+AEA-huawei.com+AD4-
+AD4- Sent: Friday, 27 October 2017 3:21 p.m.
+AD4- To: tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Dear all,
+AD4-
+AD4- Based on all the comments we received during the WG Last Call process=
,
we've updated the document to version 6.
+AD4- We believe all the LC comments are resolved and the consensus is
reflected in this new revision.
+AD4- Many thanks to Martin, Tal, Opher, Alex, John and many others who had
reviewed and commented on this draft.
+AD4-
+AD4- Cheers,
+AD4- Yuanlong on behalf of all coauthors
+AD4-
+AD4- -----Original Message-----
+AD4- From: internet-drafts+AEA-ietf.org +AFs-mailto:internet-drafts+AEA-ie=
tf.org+AF0-
+AD4- Sent: Friday, October 27, 2017 9:48 AM
+AD4- To: Xian Liu+ADs- Rodney Cummings+ADs- rodney.cummings+AEA-ni.com+ADs=
- Jiangyuanlong+ADs-
Xujinchun
+AD4- Subject: New Version Notification for
draft-ietf-tictoc-1588v2-yang-06.txt
+AD4-
+AD4-
+AD4- A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
+AD4- has been successfully submitted by Yuanlong Jiang and posted to the
IETF repository.
+AD4-
+AD4- Name:           draft-ietf-tictoc-1588v2-yang
+AD4- Revision:       06
+AD4- Title:          YANG Data Model for IEEE 1588-2008
+AD4- Document date:  2017-10-26
+AD4- Group:          tictoc
+AD4- Pages:          30
+AD4- URL:
https://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588v2-yang-06.tx
t
+AD4- Status:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
+AD4- Htmlized:
https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-06
+AD4- Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-06
+AD4- Diff:
https://www.ietf.org/rfcdiff?url2+AD0-draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Abstract:
+AD4-    This document defines a YANG data model for the configuration of
+AD4-    IEEE 1588-2008 devices and clocks, and also retrieval of the
+AD4-    configuration information, data set and running states of IEEE
+AD4-    1588-2008 clocks.
+AD4-
+AD4-
+AD4-
+AD4-
+AD4- 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.
+AD4-
+AD4- The IETF Secretariat
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://www.ietf.org/mailman/listinfo/netmod
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Nov 10 01:39: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 7A5DE12EC09 for ; Fri, 10 Nov 2017 01:39:18 -0800 (PST)
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 Fk_qQZ3Y1l9I for ; Fri, 10 Nov 2017 01:39:15 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C28C129432 for ; Fri, 10 Nov 2017 01:39:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10445; q=dns/txt; s=iport; t=1510306755; x=1511516355; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ePEbd9E38ysTRso6u46cCRn6dBcGKSMnwVosluhUOVU=; b=L/yJS6VVgJgbjtToMLRDdbVlGuyc7sQ1MmNKboePTBjnDbZenYjT91oJ ZumYU9MNhMr0jDR0IxK3BkHMnvaBb75AFWwZBIA1HgOqS0sUewIBUtqo3 bj2kFM5HIP+ETJ84CICdLSEAqjN4we6koFUrgzpK/b4Cw3qrVivT9RYNX M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAADDcgVa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUHJ4N+ih90kDORCIVIghEKggGDOgKEehgBAQEBAQEBAQFrKIU?= =?us-ascii?q?fAQUjVhAJAhgnAwICRhEGAQwGAgEBih6LYp1ogicmimsBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgzCDW4ISgwGFAQmDIoJjBaIglQCLfIdCjjKHcIE5HziBcjQhCB0?= =?us-ascii?q?Vgy2EX0E2iWOCQgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,373,1505779200"; d="scan'208,217";a="132589"
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; 10 Nov 2017 09:39:12 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAA9dCh7013688; Fri, 10 Nov 2017 09:39:12 GMT
To: Andy Bierman , Ladislav Lhotka 
Cc: "netmod@ietf.org" , Martin Bjorklund , Kent Watsen 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz>  <1510247543.4067.4.camel@nic.cz> 
From: Robert Wilton 
Message-ID: <3b497bdc-dbf6-c3ce-1b1f-2460f55fbb43@cisco.com>
Date: Fri, 10 Nov 2017 09:39:12 +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: multipart/alternative; boundary="------------A83B94EE9C154811D4AB21C6"
Content-Language: en-US
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: Fri, 10 Nov 2017 09:39:18 -0000

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



On 09/11/2017 17:44, Andy Bierman wrote:
>
>
> On Thu, Nov 9, 2017 at 9:12 AM, Ladislav Lhotka  > wrote:
>
>     On Thu, 2017-11-09 at 08:34 -0800, Andy Bierman wrote:
>     >
>     >
>     > On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka      > wrote:
>     > > Robert Wilton >
>     writes:
>     > >
>     > > >>
>     > > >>> 2. Sec 1. Introduction, page 4, paragraph starting "2.
>     > > >>> Implementation-time ...".  This section states that it is
>     a stable as
>     > > >>> YANG library, and hence cannot change due to a server
>     reboot. However,
>     > > >>> YANG library doesn't appear to have that restriction, and
>     hence this
>     > > >>> doesn't seem to align with RFC 7895, introduction paragraph 2.
>     > > >> I don't know exactly under what circumstances YANG library
>     can change
>     > > >> after a reboot, but in such a case schema-mounts data might
>     be subject
>     > > >> to a change as well. I definitely think that the "run-time"
>     case is
>     > > >> something else.
>     > > > A software upgrade could quite reasonably change YANG
>     library without a
>     > > > device reboot.  Perhaps saying less is more precise:
>     > > >
>     > > > E.g.
>     > > >
>     > > >     2.  Implementation-time: the mounted schema is defined
>     by a server
>     > > >         implementor and is as stable as YANG library
>     information. Also,
>     > > >         a client can learn the entire schema together with
>     YANG library data.
>     > > >
>     > >
>     > > It seems that neither 7950 nor 7895 defines how stable YANG
>     library data
>     > > is. The conclusion might be that it can change any time, which
>     is IMO
>     > > hardly acceptable.
>     >
>     >
>     > Actually, the YANG library is allowed to change at any time.
>     > Clients use the module-set-id and the yang-library-change
>     notification
>     > to keep their cached copy of the server's library up to date.
>
>     Notifications are optional, so basically the client needs to check
>     module-set-id
>     before every operation, and even this may not be sufficient for
>     avoiding errors.
>
>     The YANG data model was touted as a contract between the server
>     and client - and
>      it is a strange contract if the server can change it arbitrarily.
>
>
>
> The server can change the library according to the contract.
> It updates the module-set-id.
>
> In reality, there are no routers that change the module set at run-time.
> They are all mostly-monolithic firmware that need to reboot to change 
> the YANG modules.
> Modular software is more complex to test, so it is not as common in 
> embedded systems.
I think that it is becoming a lot more common.

Various network OSes allow fixes to be installed on the fly (which could 
include fixes or additions to the manageability interfaces), or the 
software to be upgraded without a formal reboot of the system.  Normally 
this would be achieved via some controlled failover of the route 
processor node to a hot standby route processor.

Linux allows packages to be installed on the fly.   This could include 
new protocols and services with associated YANG modules.  In fact, there 
are even variants of Linux that allow the running kernel to be hot 
patched without a reboot!

If a "hot" upgrade was being controlled by YANG then ideally you don't 
want to even break the management protocol session if possible.

Certainly, I would think that you need to allow LNE's to be 
provisioned/unprovisioned without restarting anything.

Thanks,
Rob


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


  
    
  
  
    


    

    

    
On 09/11/2017 17:44, Andy Bierman
      wrote:

    

    

      
      


        


          
On Thu, Nov 9, 2017 at 9:12 AM,
            Ladislav Lhotka <lhotka@nic.cz>
            wrote:

            
On Thu,
              2017-11-09 at 08:34 -0800, Andy Bierman wrote:

              >

              >

              > On Thu, Nov 9, 2017 at 7:37 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

              > > Robert Wilton <rwilton@cisco.com> writes:

              > >

              > > >>

              > > >>> 2. Sec 1. Introduction, page 4,
              paragraph starting "2.

              > > >>> Implementation-time ...".  This
              section states that it is a stable as

              > > >>> YANG library, and hence cannot
              change due to a server reboot. However,

              > > >>> YANG library doesn't appear to have
              that restriction, and hence this

              > > >>> doesn't seem to align with RFC
              7895, introduction paragraph 2.

              > > >> I don't know exactly under what
              circumstances YANG library can change

              > > >> after a reboot, but in such a case
              schema-mounts data might be subject

              > > >> to a change as well. I definitely think
              that the "run-time" case is

              > > >> something else.

              > > > A software upgrade could quite reasonably
              change YANG library without a

              > > > device reboot.  Perhaps saying less is more
              precise:

              > > >

              > > > E.g.

              > > >

              > > >     2.  Implementation-time: the mounted
              schema is defined by a server

              > > >         implementor and is as stable as
              YANG library information. Also,

              > > >         a client can learn the entire
              schema together with YANG library data.

              > > >

              > >

              > > It seems that neither 7950 nor 7895 defines how
              stable YANG library data

              > > is. The conclusion might be that it can change
              any time, which is IMO

              > > hardly acceptable.

              >

              >

              > Actually, the YANG library is allowed to change at
              any time.

              > Clients use the module-set-id and the
              yang-library-change notification

              > to keep their cached copy of the server's library up
              to date.

              

              Notifications are optional, so basically the client needs
              to check module-set-id

              before every operation, and even this may not be
              sufficient for avoiding errors.

              

              The YANG data model was touted as a contract between the
              server and client - and

               it is a strange contract if the server can change it
              arbitrarily.

              

            

            


            

            


            

            
The server can change the library according to the
              contract.

            
It updates the module-set-id.

            


            

            
In reality, there are no routers that change the module
              set at run-time.

            
They are all mostly-monolithic firmware that need to
              reboot to change the YANG modules.

            
Modular software is more complex to test, so it is not
              as common in embedded systems.

          

        

      

    

    I think that it is becoming a lot more common.

    

    Various network OSes allow fixes to be installed on the fly (which
    could include fixes or additions to the manageability interfaces),
    or the software to be upgraded without a formal reboot of the
    system.  Normally this would be achieved via some controlled
    failover of the route processor node to a hot standby route
    processor.

    

    Linux allows packages to be installed on the fly.   This could
    include new protocols and services with associated YANG modules.  In
    fact, there are even variants of Linux that allow the running kernel
    to be hot patched without a reboot!

    

    If a "hot" upgrade was being controlled by YANG then ideally you
    don't want to even break the management protocol session if
    possible.

    

    Certainly, I would think that you need to allow LNE's to be
    provisioned/unprovisioned without restarting anything.

    

    Thanks,

    Rob

    

  


--------------A83B94EE9C154811D4AB21C6--


From nobody Fri Nov 10 05:35: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 6333212702E for ; Fri, 10 Nov 2017 05:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 JZ-Ha4JCNySr for ; Fri, 10 Nov 2017 05:35:41 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA2B612009C for ; Fri, 10 Nov 2017 05:35:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1510320941; x=1511530541; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ljrFQe7NGdg/GRPj80Dj+a0Ad8VbHMqMoMcjiVPnFIE=; b=CdpbRWkz8iUnpKJpLVK6N1y2ChxYMq2ktsB/4EmF4fbV2NnilT4NImK8 1iP//040YQ2npkguGZwHzrhSEKr+EwhiK0aEYMZDmC2gn+XmQJowzt+Bu vgED5xW2prboKi6acV+0qE3kYM0/AZ+AJ7OwsyJIk/pQjEBeVMQv/zOT/ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQBXqgVa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUHhCWLE5AOJpZQghEKhTsChHwWAQEBAQEBAQEBayiFHgEBAQE?= =?us-ascii?q?CASMPAQVRCxgCAiYCAlcGAQwIAQGKFgipaYInixABAQEBAQEBAwEBAQEBASKBD?= =?us-ascii?q?4Ilg1uBaSkLgnaILIJjBaIhlQCCFYlnJIcgjjKHcIE5JQExgXI0IQgdFYMuhF5?= =?us-ascii?q?BjHcBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,374,1505779200";  d="scan'208";a="182850"
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 Nov 2017 13:35:39 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAADZc5G020978; Fri, 10 Nov 2017 13:35:38 GMT
To: "netmod@ietf.org" , Martin Bjorklund , Kent Watsen 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz> <56ea1907-c2ed-1940-089c-527b33f0723e@cisco.com> <20171109181638.zel2otpzrptggvwz@elstar.local>
From: Robert Wilton 
Message-ID: <4b1cec2b-3ad5-5650-08af-e297473b4c63@cisco.com>
Date: Fri, 10 Nov 2017 13:35:38 +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: <20171109181638.zel2otpzrptggvwz@elstar.local>
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-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, 10 Nov 2017 13:35:47 -0000

On 09/11/2017 18:16, Juergen Schoenwaelder wrote:
> On Thu, Nov 09, 2017 at 05:38:40PM +0000, Robert Wilton wrote:
>>>>>> 3. Sec 2.1 Glossary of New Terms:  "Schema" isn't actually defined
>>>>>> anywhere (RFC 7950 doesn't define this).  Should it be defined here?
>>>>>> The NMDA datastores draft had a similar issue and we choose to define
>>>>>> "datastore schema" instead.
>>>>> I think the right place for defining the term "schema" (and "data model"
>>>>> as well) is the specification of YANG because it is desirable that all
>>>>> documents related to YANG use the same meaning.
>>>> OK, 7950 doesn't define it today.  Is that a problem?
>>> "Schema tree" and "schema node" are defined and used a lot in 7950, so
>>> it might be good to define "schema" as well - meaning the schema tree
>>> with all associated semantics.
>> OK, but we can't add definitions to 7950 now.  Would it make sense to add
>> the definition to the NMDA draft and reference that?
> So what is the difference between "schema tree" and "schema"? Or to
> put it differently, what is "all associated semantics" that you are
> adding to a "schema tree" to obtain a "schema"? RFC 7950 says:
>
>     o  schema tree: The definition hierarchy specified within a module.

When I read this definition of schema tree, it makes me think that it 
applies to only a single module.  E.g. you could have the ietf-ip schema 
tree, or the ietf-interfaces schema tree, etc.

But I think of a"schema" as being the tree structure of all schema nodes 
for a defined set of modules.


>
> If I understand 'definition hierarchy' correctly, than it seems
> "schema" is just an abbreviation of "schema tree", i.e., there is no
> semantic difference between these two terms. If there is a difference,
> we need to be able to spell it out.

So, if "schema tree" refers to the schema nodes in one module, I think 
"schema" is different from "schema tree".  But perhaps I'm 
misinterpreting the "schema tree" definition.

Thanks,
Rob


>
> /js
>


From nobody Fri Nov 10 07:38: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 0C5E9126CC4 for ; Fri, 10 Nov 2017 07:38:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ5EtoiBPYbf for ; Fri, 10 Nov 2017 07:38:34 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A3459126C3D for ; Fri, 10 Nov 2017 07:38:34 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 9BC3318215DE; Fri, 10 Nov 2017 16:37:43 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id D670E1820F78; Fri, 10 Nov 2017 16:37:40 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Robert Wilton 
Cc: "netmod\@ietf.org" 
In-Reply-To: <20171109181638.zel2otpzrptggvwz@elstar.local>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz> <56ea1907-c2ed-1940-089c-527b33f0723e@cisco.com> <20171109181638.zel2otpzrptggvwz@elstar.local>
Mail-Followup-To: Juergen Schoenwaelder , Robert Wilton , "netmod\@ietf.org" 
Date: Fri, 10 Nov 2017 16:39:36 +0100
Message-ID: <87lgje9m87.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Fri, 10 Nov 2017 15:38:37 -0000

Juergen Schoenwaelder  writes:

> On Thu, Nov 09, 2017 at 05:38:40PM +0000, Robert Wilton wrote:
>>=20
>> > > > > 3. Sec 2.1 Glossary of New Terms:=C2=A0 "Schema" isn't actually =
defined
>> > > > > anywhere (RFC 7950 doesn't define this).=C2=A0 Should it be defi=
ned here?
>> > > > > The NMDA datastores draft had a similar issue and we choose to d=
efine
>> > > > > "datastore schema" instead.
>> > > > I think the right place for defining the term "schema" (and "data =
model"
>> > > > as well) is the specification of YANG because it is desirable that=
 all
>> > > > documents related to YANG use the same meaning.
>> > > OK, 7950 doesn't define it today.=C2=A0 Is that a problem?
>> > "Schema tree" and "schema node" are defined and used a lot in 7950, so
>> > it might be good to define "schema" as well - meaning the schema tree
>> > with all associated semantics.
>> OK, but we can't add definitions to 7950 now.=C2=A0 Would it make sense =
to add
>> the definition to the NMDA draft and reference that?
>
> So what is the difference between "schema tree" and "schema"? Or to
> put it differently, what is "all associated semantics" that you are
> adding to a "schema tree" to obtain a "schema"? RFC 7950 says:
>
>    o  schema tree: The definition hierarchy specified within a module.

As Rob points out, this is probably incorrect, as schema tree should
involve multiple modules. It makes no sense to talk about a schema tree
of an augmenting module unless we also take into account the augmented
module.

Anyway, schema tree is really just the hierarchy, i.e. a tree of schema
nodes, whereas schema is the hierarchy with datatypes, semantic rules
and all that. We can validate instance data against the schema, not
against the schema tree. This is at least how I understand it.

Lada

>
> If I understand 'definition hierarchy' correctly, than it seems
> "schema" is just an abbreviation of "schema tree", i.e., there is no
> semantic difference between these two terms. If there is a difference,
> we need to be able to spell it out.
>
> /js
>
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Fri Nov 10 08:10: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 02A4D126DC2 for ; Fri, 10 Nov 2017 08:10:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 znmPLsEzancW for ; Fri, 10 Nov 2017 08:10:06 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A51126BF6 for ; Fri, 10 Nov 2017 08:10:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 392426F; Fri, 10 Nov 2017 17:10:04 +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 rc8JN5yQeG6u; Fri, 10 Nov 2017 17:10:03 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Nov 2017 17:10:04 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25DDA2011F; Fri, 10 Nov 2017 17:10:04 +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 AD6lavU7PzOO; Fri, 10 Nov 2017 17:10:03 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB4DF2011E; Fri, 10 Nov 2017 17:10:03 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 3BFDF415297C; Fri, 10 Nov 2017 17:08:36 +0100 (CET)
Date: Fri, 10 Nov 2017 17:08:36 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton , "netmod@ietf.org" 
Message-ID: <20171110160836.2hy5nr4zuklwnjjj@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , "netmod@ietf.org" 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz> <56ea1907-c2ed-1940-089c-527b33f0723e@cisco.com> <20171109181638.zel2otpzrptggvwz@elstar.local> <87lgje9m87.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87lgje9m87.fsf@nic.cz>
User-Agent: NeoMutt/20170714 (1.8.3)
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: Fri, 10 Nov 2017 16:10:13 -0000

On Fri, Nov 10, 2017 at 04:39:36PM +0100, Ladislav Lhotka wrote:
> >
> > So what is the difference between "schema tree" and "schema"? Or to
> > put it differently, what is "all associated semantics" that you are
> > adding to a "schema tree" to obtain a "schema"? RFC 7950 says:
> >
> >    o  schema tree: The definition hierarchy specified within a module.
> 
> As Rob points out, this is probably incorrect, as schema tree should
> involve multiple modules. It makes no sense to talk about a schema tree
> of an augmenting module unless we also take into account the augmented
> module.
> 
> Anyway, schema tree is really just the hierarchy, i.e. a tree of schema
> nodes, whereas schema is the hierarchy with datatypes, semantic rules
> and all that. We can validate instance data against the schema, not
> against the schema tree. This is at least how I understand it.

The current definition says "definition hierarchy specified within a
module", perhaps this was intended to mean 'tree of schema nodes', but
perhaps it means "the hierarchy with datatypes, semantic rules and all
that". ;-) Looking at the definition of schema node, I see:

  o schema node: A node in the schema tree.  One of action, container,
  leaf, leaf-list, list, choice, case, rpc, input, output,
  notification, anydata, and anyxml.

With this, your interpretation makes sense and a better way to define
scheme tree would then be:

  o schema tree: The tree formed out of schema nodes of a module.

The schema could be defined as

  o schema: All definitions of a module including the schema tree.

I think it is OK to scope these definitions to the notion of a module.
If people talk about the schema (schema tree, schema nodes) of a
collection of modules, it seems natural to assume that this means the
union of the schemas (schema trees, schema nodes).

/js

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


From nobody Fri Nov 10 19:31: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 376091270AE for ; Fri, 10 Nov 2017 19:31:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.158
X-Spam-Level: 
X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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=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 52fCdIDcE5JH for ; Fri, 10 Nov 2017 19:31:06 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7214D1200C1 for ; Fri, 10 Nov 2017 19:31:06 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 182911E081A for ; Fri, 10 Nov 2017 20:06:55 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id YT6s1w0012SSUrH01T6vAq; Fri, 10 Nov 2017 20:06:55 -0700
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=sC3jslCIGhcA:10 a=3ROPyQwvLTZxNUSrdNkA: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=hbA77YHuGLks+C5X7T5S7jGOJWM9QhcfjOUIjSuklcQ=; b=qaoBB9SPNIz7qS3EVcnPvNF4c3 /70awyRFUyz7IrzeY/XwOsdihx/zwW13/fgZLQw4u0yLXzhEP1qkbsBdVjU5fYQLLcd+Xl2v3jWSY 718c/ESTiRXBzPxO4xq7AZWoT;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:42694 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eDM8B-000ArL-Lv; Fri, 10 Nov 2017 20:06:51 -0700
To: netmod@ietf.org
Cc: netmod-chairs@ietf.org
From: Lou Berger 
Message-ID: 
Date: Sat, 11 Nov 2017 00:59:19 +0800
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-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: 1eDM8B-000ArL-Lv
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]:42694
X-Source-Auth: lberger@labn.net
X-Email-Count: 16
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Please send status of WG drafts not on the agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Nov 2017 03:31:07 -0000

Hi,
	If your *WG* draft is not on the agenda for this meeting, please send 
the list a status update  -- covering recent changes, open issues, plan 
for completing the document.

Thank you,
Lou (and Kent)


From nobody Fri Nov 10 19:31: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 1674C1292D3 for ; Fri, 10 Nov 2017 19:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.158
X-Spam-Level: 
X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 Icb4_Ig1w2qt for ; Fri, 10 Nov 2017 19:31:30 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 500F21270AE for ; Fri, 10 Nov 2017 19:31:28 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id F3F40176579 for ; Fri, 10 Nov 2017 20:06:43 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id YT6g1w00S2SSUrH01T6j8s; Fri, 10 Nov 2017 20:06:43 -0700
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=sC3jslCIGhcA:10 a=y1sg0DtI7uQ6J5gZwZYA: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=+wK0aw0fF00HrZHdAlCqo9ZahsEojvPFitteqiWQHkY=; b=KzX0MAetvHEPigQuppLY8rYOv2 IBt2ocH8U+y5qAN2GB3Imlix4OsoOASERCxWwJb3YSiSSntfq/REoRsCseHn7l65/K8Z/IX7qQpO4 icosx4jEUn26h90j5ph0Gndvg;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:42654 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eDM80-000AqQ-II; Fri, 10 Nov 2017 20:06:40 -0700
To: Martin Bjorklund , kwatsen@juniper.net
Cc: netmod@ietf.org
References:  <87po8z9x5p.fsf@nic.cz>  <20171108.095019.1523851923210652414.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <608159e0-f6f4-7918-d0f5-9c0464213ca7@labn.net>
Date: Sat, 11 Nov 2017 00:50:04 +0800
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: <20171108.095019.1523851923210652414.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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: 1eDM80-000AqQ-II
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]:42654
X-Source-Auth: lberger@labn.net
X-Email-Count: 11
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] review of 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, 11 Nov 2017 03:31:32 -0000

On 11/8/2017 4:50 PM, Martin Bjorklund wrote:
>>> The "use-schema" case shouldn't pose big problems because it is
>>> essentially an externally specified augment. The "inline" case is
>>> somewhat disturbing though: could the embedded YANG library instances
>>> be different in different datastores?
>> YANG Library is only available in  (it's all config false).
>> I think you mean the embedded YANG Library instances under the mount
>> points.  Yes, you may have a problem here.  Still, this isn't my question,
>> is more about schema-mounting requirements across datastores.  E.g., if
>> a schema-mount exists in , must it existing in  and
>>  as well?  Conversely, if a schema-mount exists in
>> , must it exist in ?  I think this draft should
>> clarify such things.
> I agree that this needs to be clarified.  This issue partly comes from
> the fact that schema mount uses the groupings in the old yang
> library.  I think we need to use the new groupings from rfc7895bis.
> 

We previously discussed this point an chose not to use rfc7895bis as we 
wanted to allow current implementations to add support NIs/LNEs with 
minimal additional work, and specifically not require support for 
rfc7895bis and NMDA to support LNEs/NIs (and consequently schema mount).

I do think it would be good to have rfc7895bis supersede 
ietf-yang-schema-mount by incorporating its functionality, but that 
wouldn't be a change to this document.

Lou


From nobody Fri Nov 10 19:31: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 34EB81270AE for ; Fri, 10 Nov 2017 19:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.158
X-Spam-Level: 
X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 7PJlxfkYkK43 for ; Fri, 10 Nov 2017 19:31:36 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C441200C1 for ; Fri, 10 Nov 2017 19:31:36 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id CD9C52160BD for ; Fri, 10 Nov 2017 20:06:50 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id YT6m1w00m2SSUrH01T6p6t; Fri, 10 Nov 2017 20:06:50 -0700
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=sC3jslCIGhcA:10 a=n0GyCHDuJ4aEKEL0ZBYA: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=AR96UmkuCJrtlk4uMWKjR4znsgkdGqJOwd9QkaEUV80=; b=cM/E8UPv+kyb7ljJGZFw7xTrPB AonTkJy5hPEbTYnDGr8g51suV06pZTopN4B5XNyvpekKjHxkjZRBOLxfc9igfc/0u63qknJvYpSDj tJA06Q/v8oN0lB/qrgZEpCWck;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:42656 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eDM86-000Aqt-FY; Fri, 10 Nov 2017 20:06:46 -0700
To: Robert Wilton , "netmod@ietf.org" , Martin Bjorklund , Kent Watsen 
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz>
From: Lou Berger 
Message-ID: <2299aed7-8e99-ccfd-cc86-3e8d590b37f6@labn.net>
Date: Sat, 11 Nov 2017 00:50:09 +0800
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: <874lq4oq94.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
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: 1eDM86-000Aqt-FY
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]:42656
X-Source-Auth: lberger@labn.net
X-Email-Count: 13
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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, 11 Nov 2017 03:31:37 -0000

On 11/8/2017 9:26 PM, Ladislav Lhotka wrote:
>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs" =>
>> "are possible, and as such, needs"
> I actually don't understand neither this sentence nor what the point of
> such exceptions could possibly be.
> 

In the case of the example, LNEs, there is a relationship between 
interfaces in the parent and interfaces in the LNE that is known at the 
parent, but the LNE.  (Think host interface assigned to VM.)

Lou


From nobody Sat Nov 11 07:09: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 09A2712956D for ; Sat, 11 Nov 2017 07:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 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, 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 UI2zl01MuSy9 for ; Sat, 11 Nov 2017 07:09:52 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02E91296D2 for ; Sat, 11 Nov 2017 07:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76442; q=dns/txt; s=iport; t=1510412992; x=1511622592; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=6BI86XSxrDrLVlRdKzKpC6w7T9BKD1zE4UpPiyuARAg=; b=QKFTr40C0nCNpc/lGsZHIauez9Vf/Tt5gXjSCnCULl++4pxwHBAo9teQ 9CudL8mxKRWJKPGwXa02TB1Fp+ymIGEJWQlrDK8swV/ADD9qAiONshrVD Iq1tufwGuPA+IR9HZ/SJBt9u0cPShBsFybBCcUhGICNxayS6ywNmbMdzG 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAADQEQda/51dJa1CFwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgzVkbieDfoofjyuBfX6VUhCBfgMKGAEMhEdPAoRGPxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUeAQEBAQIBAQEYAQhJAgMFAwUJAgkCDgICBiABAgQDAgIbDB8DD?= =?us-ascii?q?gYBDAYCAQEXiX8IEDOMJ51ogicmimYBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYM?= =?us-ascii?q?vggeBVYFpKYJMNYRfBQERAgEkCxAmgk6CYwWKNoIdhRWBEoYaiENTh2uDHkuJM?= =?us-ascii?q?IIVX4kJh0WKMYI3gUqHcoE5HziBA280IQgdFUmCZAkKgkkcGYFbNDYBihABAQE?=
X-IronPort-AV: E=Sophos; i="5.44,378,1505779200"; d="scan'208,217"; a="30209888"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Nov 2017 15:09:50 +0000
Received: from [10.24.18.179] ([10.24.18.179]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vABF9lcm015350; Sat, 11 Nov 2017 15:09:48 GMT
To: Rob Shakir , Andy Bierman 
Cc: Juergen Schoenwaelder , NetMod WG 
References:  <751fa015-a917-a104-f6c6-25cc9a5accba@cisco.com> <15f105bf980.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <708ad6ca-e37b-6236-59b2-80c611b132ae@cisco.com>   <20171103174811.vmsgcsdt5u5avxgu@elstar.local>  
From: Benoit Claise 
Message-ID: <13f8a09b-89ee-4f2e-be11-ffc07cee2024@cisco.com>
Date: Sat, 11 Nov 2017 23:09:47 +0800
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="------------E0B45DA8A88745695465F245"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [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: Sat, 11 Nov 2017 15:09:57 -0000

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

Replying to Jürgen, Andy, and Rob in this email.

Yes. Semantic versioning is a step in the right direction. Specifically 
for native/generated models (yes, those exist into the wild). And for 
"standard" models too. See 
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-01#section-2.1

We'll have to come to the notion of release bundle, for sure.
The "leaf tree-type" (*) is a release bundle type of metadata anyway
I was hoping that the IETF would be releasing YANG modules in bundle, 
but looking at the rate, it seems more drop by drop. Anyway, all those 
routing modules should be working together. The YANG impact analysis 
should help in checking this. See 
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=both
Btw, the "dependent" and "dependencies" are also metadata in the 
yangcatalog.org

Just saying that YANG modules "are designed and known to work together 
into meaningful packages" is interesting.
However, in the end, operators combine/test YANG modules to deploy 
services. This is Rob"s feature bundle described below. Since this 
notion of feature bundle is service specific, for service composition, 
in the end, the feature bundle is a service-specific release bundle, so 
operator specific, so orchestrator/controller specific.

> I agree that semantic versioning is only part of the solution.
> In OpenConfig versioning we have the concept of release bundles that 
> have a semver, these contain modules that are known to work together - 
> and are the base for compliance descriptions.
> The individual modules semver has been useful to mark where there are 
> backwards incompatible changes in an individual module.
>
> On top of release bundles, we also have feature bundles which describe 
> a particular implementation's requirements for the modules. A feature 
> bundle is a description of paths within a release bundle.
>
> We're continuing to gain experience with how well this works, but 
> certainly I don't see the need for the bundles alleviating the need 
> for the semantic versions for modules.
+1.

It's a matter of determining which problem we want to tackle now.

(*) https://datatracker.ietf.org/doc/draft-clacla-netmod-model-catalog/

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)";
       }


Regards, Benoit
>
> On Fri, 3 Nov 2017 at 11:05 Andy Bierman  > wrote:
>
>     On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder
>          > wrote:
>
>         My take here is that structured version numbers do only partially
>         solve the problem. Andy's work years ago on packages offers in
>         my view
>         a superior foundation for a solution. Once we can bundle
>         modules that
>         are designed and known to work together into meaningful
>         packages, then
>         it may be possible to relax some of the strict RFC 7950 update
>         rules.
>
>         Once the NETMOD WG gets the work on NMDA "completed", I
>         believe "YANG
>         packages" are a worthwhile target to work on. There is a need
>         to get
>         more structure into the module space, not just additional
>         structured
>         version numbers.
>
>
>     I agree ;-)
>
>     It is nice to have a way to know current implementations will probably
>     break if they upgrade to the new version. It is even nicer if the APIs
>     are stable and don't break existing code.
>
>     It is not encouraging that the IETF cannot produce stable YANG modules
>     published in RFCs.  We expect I-Ds to ignore the YANG update rules,
>     but not RFC versions.
>
>     Since the semantic versioning is only per-module, it is not
>     usefull for
>     determining if module foo will work with module bar.  If it is OK
>     to break backward-compatibility then it will become increasingly
>     difficult to just use the latest version of a module. Real
>     interoperability
>     at the granularity of modules will become more difficult. YANG
>     packages
>     can dramatically reduce the number of API permutations.
>
>
>         /js
>
>
>     Andy
>
>
>         On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:
>         > Dear all,
>         >
>         > Let me present this draft
>         >
>         https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
>         >
>         >                     New YANG Module Update Procedure
>         >  draft-clacla-netmod-yang-model-update-01
>         >
>         > Abstract
>         >
>         >    This document specifies a new YANG module update
>         procedure in case of
>         >    non backward-compatible changes, as an alternative
>         proposal to the
>         >    YANG 1.1 specifications.  This document updates RFC 7950.
>         >
>         >
>         > Problem statement:
>         > Changing a YANG module name each time there is a non
>         backward compatible
>         > change (as RFC7950 requires) adds a lot of complexity to
>         automation, from an
>         > import and service composition point of view.
>         >
>         > Solution:
>         > We need a different mechanism. The solution in the draft is
>         based on the
>         > semantic versioning YANG extension: it was proposed
>         openconfig in the past
>         > and is currently used by the openconfig YANG modules
>         >
>         > Note: there might other solutions, such as new YANG
>         keywords, but at this
>         > point in time, it's important to recognize that we need to
>         change the way we
>         > produce YANG modules at the IETF. Let's discuss on the list
>         and during the
>         > NETMOD meeting.
>         >
>         > Regards, Benoit.
>         > > 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)
>         > > > > > >
>         > > > > > >
>         > > > > > >
>         > > > > > >
>         > > >
>         > >
>         >
>
>         > _______________________________________________
>         > netmod mailing list
>         > netmod@ietf.org 
>         > https://www.ietf.org/mailman/listinfo/netmod
>
>
>         --
>         Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>         Phone: +49 421 200 3587     Campus
>         Ring 1 | 28759 Bremen | Germany
>         Fax: +49 421 200 3103   
>          
>
>         _______________________________________________
>         netmod mailing list
>         netmod@ietf.org 
>         https://www.ietf.org/mailman/listinfo/netmod
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>


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


  
    
  
  
    
Replying to Jürgen, Andy, and Rob in
      this email.

      

      Yes. Semantic versioning is a step in the right direction.
      Specifically for native/generated models (yes, those exist into
      the wild). And for "standard" models too. See
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-01#section-2.1

      

      We'll have to come to the notion of release bundle, for sure.

      The "leaf tree-type" (*) is a release bundle type of metadata
      anyway

      I was hoping that the IETF would be releasing YANG modules in
      bundle, but looking at the rate, it seems more drop by drop.
      Anyway, all those routing modules should be working together. The
      YANG impact analysis should help in checking this. See
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-routing&recurse=0&rfcs=1&show_subm=1&show_dir=both

      Btw, the "dependent" and "dependencies" are also metadata in the
      yangcatalog.org

      

      Just saying that YANG modules "are designed and known to work
      together into meaningful packages" is interesting. 

      However, in the end, operators combine/test YANG modules to deploy
      services. This is Rob"s feature bundle described below. Since this
      notion of feature bundle is service specific, for service
      composition, in the end, the feature bundle is a service-specific
      release bundle,
      so operator specific, so orchestrator/controller specific.

      

    

    

      
      
I agree that semantic versioning is only part of
        the solution. 

    

    

      
In OpenConfig versioning we have the concept of
        release bundles that have a semver, these contain modules that
        are known to work together - and are the base for compliance
        descriptions. 

    

    

      
The individual modules semver has been useful to
        mark where there are backwards incompatible changes in an
        individual module.

    

    

      

        


        

        
On top of release bundles, we also have feature bundles
          which describe a particular implementation's requirements for
          the modules. A feature bundle is a description of paths within
          a release bundle.

        


        

        
We're continuing to gain experience with how well this
          works, but certainly I don't see the need for the bundles
          alleviating the need for the semantic versions for modules.

      

    

    +1. 

    

    It's a matter of determining which problem we want to tackle now.

    

    (*)
    https://datatracker.ietf.org/doc/draft-clacla-netmod-model-catalog/

    
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)";
      }

    

    Regards, Benoit

    


      

        
On Fri, 3 Nov 2017 at 11:05 Andy Bierman <andy@yumaworks.com>
          wrote:

        

        

          

            

              
On Fri, Nov 3, 2017 at 10:48 AM,
                Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
                wrote:

                
My
                  take here is that structured version numbers do only
                  partially

                  solve the problem. Andy's work years ago on packages
                  offers in my view

                  a superior foundation for a solution. Once we can
                  bundle modules that

                  are designed and known to work together into
                  meaningful packages, then

                  it may be possible to relax some of the strict RFC
                  7950 update

                  rules.

                  

                  Once the NETMOD WG gets the work on NMDA "completed",
                  I believe "YANG

                  packages" are a worthwhile target to work on. There is
                  a need to get

                  more structure into the module space, not just
                  additional structured

                  version numbers.

                  

                

                


                

              

            

          

          

            

              

                
I agree ;-)

                


                

                
It is nice to have a way to know current
                  implementations will probably

                
break if they upgrade to the new version. It is
                  even nicer if the APIs

                
are stable and don't break existing code.

                


                

                
It is not encouraging that the IETF cannot produce
                  stable YANG modules

                
published in RFCs.  We expect I-Ds to ignore the
                  YANG update rules,

                
but not RFC versions.

                


                

                
Since the semantic versioning is only per-module,
                  it is not usefull for

                
determining if module foo will work with module
                  bar.  If it is OK

                
to break backward-compatibility then it will become
                  increasingly

                
difficult to just use the latest version of a
                  module. Real interoperability

                
at the granularity of modules will become more
                  difficult. YANG packages

                
can dramatically reduce the number of API
                  permutations.

                


                

                


                

                

                  /js

                

              

            

          

          

            

              

                
 

                


                

                
Andy

              

            

          

          

            

              

                
 

                

                  

                  On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit
                  Claise wrote:

                  > Dear all,

                  >

                  > Let me present this draft

                  > https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/

                  >

                  >                     New YANG Module Update
                  Procedure

                  >               
                   draft-clacla-netmod-yang-model-update-01

                  >

                  > Abstract

                  >

                  >    This document specifies a new YANG module
                  update procedure in case of

                  >    non backward-compatible changes, as an
                  alternative proposal to the

                  >    YANG 1.1 specifications.  This document
                  updates RFC 7950.

                  >

                  >

                  > Problem statement:

                  > Changing a YANG module name each time there is a
                  non backward compatible

                  > change (as RFC7950 requires) adds a lot of
                  complexity to automation, from an

                  > import and service composition point of view.

                  >

                  > Solution:

                  > We need a different mechanism. The solution in
                  the draft is based on the

                  > semantic versioning YANG extension: it was
                  proposed openconfig in the past

                  > and is currently used by the openconfig YANG
                  modules

                  >

                  > Note: there might other solutions, such as new
                  YANG keywords, but at this

                  > point in time, it's important to recognize that
                  we need to change the way we

                  > produce YANG modules at the IETF. Let's discuss
                  on the list and during the

                  > NETMOD meeting.

                  >

                  > Regards, Benoit.

                  > > 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 ofRFC8049
                  <https://tools.ietf.org/html/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)

                  > > > > > >

                  > > > > > >

                  > > > > > >

                  > > > > > >

                  > > >

                  > >

                  >

                  

                  > _______________________________________________

                  > 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     
                         <http://www.jacobs-university.de/>

                      

                      _______________________________________________

                      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

        

      

    

    

  


--------------E0B45DA8A88745695465F245--


From nobody Sat Nov 11 08:11: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 86E6D124319 for ; Sat, 11 Nov 2017 08:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 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, 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 a-guEJkktfMQ for ; Sat, 11 Nov 2017 08:11:32 -0800 (PST)
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 811A5129B02 for ; Sat, 11 Nov 2017 08:11:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23602; q=dns/txt; s=iport; t=1510416688; x=1511626288; h=subject:references:from:to:cc:message-id:date: mime-version:in-reply-to; bh=i2Kex6AT9BdCYuZEa0LIuweeK5gM+KT89eY4t537wFs=; b=FM4cBzr+/vuno5ze8rMLZH8JHvE3KMEKQtCyfG1bDLvrX8Joiy7qXI96 yN7XRU91qfLw0ENW9LPA6ylWbQF4/l160w6tMu5QPj5p2RTgvn0HkNXEo 6fT8hLPB0Pvn1W04SqGvmFjdFR4wtb3qJvhs6v0ywgyFSwj7sHx+jr/Qf Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAQDZIAda/4QNJK1CEAocAQEBBAEBC?= =?us-ascii?q?gEBgzVkbieOHY8rgX2RCIVIEIIBCh6BY4M6AoRGPxgBAQEBAQEBAQFrKIUeAQM?= =?us-ascii?q?DJ0cCCRAcAwECL08IBg0GAgEBih4QM6wCOiaKZgEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAR2DNIIHgVWCEoJMg3mBGwUBBwsBKxSFWAWMU4UVgRKGGokWh2uDaYkwgnS?= =?us-ascii?q?JCYdFjGiBSodygTkfOBkpQW80IQgdFUmCZAmCUB8ZgVs0NgEBAQGHSw0YB4IWA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.44,378,1505779200";  d="scan'208,217";a="322436458"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Nov 2017 16:11:26 +0000
Received: from [10.24.18.179] ([10.24.18.179]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vABGBOXd026347; Sat, 11 Nov 2017 16:11:25 GMT
References: 
From: Benoit Claise 
To: NETMOD Working Group 
Cc: Henrik Levkowetz 
X-Forwarded-Message-Id: 
Message-ID: <386c91c0-6d87-0b64-30e8-4a29edb220cc@cisco.com>
Date: Sun, 12 Nov 2017 00:11:23 +0800
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="------------2EB99F48DCAB62DA6C02067E"
Content-Language: en-US
Archived-At: 
Subject: [netmod] YANG module metada and impact analysis links in the datatracker (New datatracker release: v6.64.0)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Nov 2017 16:11:35 -0000

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

Dear all,

Here are two useful URLs in the datatracker if you care about YANG modules.
This was announced in Henrik's email "New datatracker release: v6.64.0", 
but let me stress this again.

If you take for example this draft: draft-ietf-netmod-rfc7223bis
The tracker, at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/, provides 
two "additional URLs":
  - Yang catalog entry for ietf-interfaces@2017-08-17.yang 
 

  - Yang impact analysis for draft-ietf-netmod-rfc7223bis 
 


The first entry provides a list of all metadata in the YANG module for 
the yangcatalog.org 


            |  +--rw module* [name revision organization]
            |     +--rw name                        yang:yang-identifier
            |     +--rw revision                    union
            |     +--rw organization                string
            |     +--rw ietf
            |     |  +--rw ietf-wg?   string
            |     +--rw namespace                   inet:uri
            |     +--rw schema?                     inet:uri
            |     +--rw generated-from?             enumeration
            |     +--rw maturity-level?             enumeration
            |     +--rw document-name?              string
            |     +--rw author-email?               yc:email-address
            |     +--rw reference?                  inet:uri
            |     +--rw module-classification       enumeration
            |     +--rw compilation-status?         enumeration
            |     +--rw compilation-result?         inet:uri
            |     +--rw prefix?                     string
            |     +--rw yang-version?               enumeration
            |     +--rw description?                string
            |     +--rw contact?                    string
            |     +--rw module-type?                enumeration
            |     +--rw belongs-to?                 yang:yang-identifier
            |     +--rw tree-type?                  enumeration
            |     +--rw submodule* [name revision]
            |     |  +--rw name        yang:yang-identifier
            |     |  +--rw revision    union
            |     |  +--rw schema?     inet:uri
            |     +--rw dependencies* [name]
            |     |  +--rw name        yang:yang-identifier
            |     |  +--rw revision?   union
            |     |  +--rw schema?     inet:uri
            |     +--rw dependents* [name]
            |     |  +--rw name        yang:yang-identifier
            |     |  +--rw revision?   union
            |     |  +--rw schema?     inet:uri
            |     +--rw semantic-version?           yc:semver
            |     +--rw derived-semantic-version?   yc:semver
            |     +--rw implementations
            |        +--rw implementation* [vendor platform software-version software-flavor]
            |           +--rw vendor              string
            |           +--rw platform            string
            |           +--rw software-version    string
            |           +--rw software-flavor     string
            |           +--rw os-version?         string
            |           +--rw feature-set?        string
            |           +--rw os-type?            string
            |           +--rw feature*            yang:yang-identifier
            |           +--rw deviation* [name revision]
            |           |  +--rw name        yang:yang-identifier
            |           |  +--rw revision    union
            |           +--rw conformance-type?   enumeration
            +--rw vendors
               +--rw vendor* [name]
                  +--rw name         string
                  +--rw platforms
                     +--rw platform* [name]
                        +--rw name                 string
                        +--rw software-versions
                           +--rw software-version* [name]
                              +--rw name                string
                              +--rw software-flavors
                                 +--rw software-flavor* [name]
                                    +--rw name         string
                                    +--rw protocols
                                    |  +--rw protocol* [name]
                                    |     +--rw name                identityref
                                    |     +--rw protocol-version*   string
                                    |     +--rw capabilities*       string
                                    +--rw modules
                                       +--rw module* [name revision organization]
                                          +--rw name                -> /catalog/modules/module/name
                                          +--rw revision            -> /catalog/modules/module/revision
                                          +--rw organization        -> /catalog/modules/module/organization
                                          +--rw os-version?         string
                                          +--rw feature-set?        string
                                          +--rw os-type?            string
                                          +--rw feature*            yang:yang-identifier
                                          +--rw deviation* [name revision]
                                          |  +--rw name        yang:yang-identifier
                                          |  +--rw revision    union
                                          +--rw conformance-type?   enumeration

I advice you to review the leave definitions at YANG module for the 
yangcatalog.org 
, 
to understand the use cases.
The most useful leaves to start with are the validation-status and 
validation-report.

The second entry provides the impact analysis. There are thee options:

    1. dependents only: only show those modules that depend on the
    target module(s).
      use case: you want to see the impacted modules
    2. dependencies only: only show those modules that are imported by
    the target module(s).
      use case: you want to see the bottleneck for standardization
    3. both

Enjoy.

Regards, Benoit

-------- Forwarded Message --------
Subject: 	New datatracker release: v6.64.0
Date: 	Wed, 01 Nov 2017 06:36:58 -0700
From: 	Henrik Levkowetz 
To: 	codesprints@ietf.org, iesg@ietf.org, wgchairs@ietf.org



Hi,

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

Release notes:

ietfdb (6.64.0) ietf; urgency=medium

   **Yang resource links on yang draft pages**

   Drafts containing yang modules now get links pointing to the yang impact
   analysis, and to module metadata for each module.  Support has been added
   for ad-hoc trac instances, permitting automatic maintenance of role-based
   admin rights also for other trac instances than the WG, RG, and directorate
   wikis.  The draft submission automation API description is now referenced
   from the draft submission upload page.  'Additional URLs' for drafts are now
   sorted, rather than presented in random order.  Links pointing from draft
   review pages to mailing lists, for the full review text, are now validated
   in order to avoid presenting links to unavailable resources.  An issue with
   parameter expansion in a nomcom template has been fixed, as have various
   other issues.

   Details from the commit log:

   * Tweaked a page cache time to make newly uploaded session agendas visible
     with less delay.

   * Added a guard against iterating over None in stats.views.document_stats()

   * Added draft URLs pointing to Yang resources (impact analysis and model
     metadata) for submissions containing Yang modules.

   * Changed the submission checkers to return more information in the
     checker details json blob; in particular added information about individual
     extracted code modules associated with a draft.  This is used by the yang
     valididty checker to return a list of extracted yang modules.

   * Changed the SubmissionCheck.time field to use a default now value,
     instead of auto_now, to permit migrations without changing the timestamps.

   * Added some more debugging output for occasional author extraction
     failures during test.  See also [14226].

   * Added support for ad-hoc trac instances, with arbitrary names and
     filesystem paths, but still bound to a particular group's roles for
     management of trac admin rights.

   * Display document urls in alphabetical order

   * Permit document urls to be up to 512 bytes, rather than the default 200

   * New settings for adhoc wikis and yang document urls

   * Added a mention of the submission automation API on the submission
     upload page.

   * Added cleaning of review_url from the review completion form, to make
     sure it's retrievable.

   * Added some debugging code to help identify random test failures

   * Added a new field Meeting.days to capture the length of a meeting.
     This is necessary now that we have previous meetings officially starting
     Sunday, lasting to Friday, and future meetings starting Saturday, Lasting
     to Friday.  We use Meeting.days to calculate Meeting.end_date().
     Meeting.get_ietf_monday() and two cut_off() methods have also been updated
     to be instance methods instead of class methods, and to not assume that a
     meeting starts on Sunday.

   * Updated coverage data

   * Expanded one of the nomcom tests a bit, and updated a fixture to match
     the current /nomcom/default/email/feedback_receipt.txt template.

   * Don't blow up when checking if the logged-in user is a document author,
     if the user don't have a person record.

  -- Henrik Levkowetz   30 Oct 2017 04:30:27 -0700

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

For development, copy the new development version instead:
   'svn copy https://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.64.1.dev0' 

Regards,

	Henrik
	(via the mkrelease script)

.


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


  

    
  
  
    Dear all,

    

    Here are two useful URLs in the datatracker if you care about YANG
    modules.

    This was announced in Henrik's email "New datatracker release:
    v6.64.0", but let me stress this again.

    

    If you take for example this draft: draft-ietf-netmod-rfc7223bis

    The tracker, at
    https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/,
    provides two "additional URLs":

     - Yang
      catalog entry for ietf-interfaces@2017-08-17.yang
    

     - Yang
      impact analysis for draft-ietf-netmod-rfc7223bis
    


      The first entry provides a list of all metadata in the YANG
        module for the yangcatalog.org

      

        
       |  +--rw module* [name revision organization]
       |     +--rw name                        yang:yang-identifier
       |     +--rw revision                    union
       |     +--rw organization                string
       |     +--rw ietf
       |     |  +--rw ietf-wg?   string
       |     +--rw namespace                   inet:uri
       |     +--rw schema?                     inet:uri
       |     +--rw generated-from?             enumeration
       |     +--rw maturity-level?             enumeration
       |     +--rw document-name?              string
       |     +--rw author-email?               yc:email-address
       |     +--rw reference?                  inet:uri
       |     +--rw module-classification       enumeration
       |     +--rw compilation-status?         enumeration
       |     +--rw compilation-result?         inet:uri
       |     +--rw prefix?                     string
       |     +--rw yang-version?               enumeration
       |     +--rw description?                string
       |     +--rw contact?                    string
       |     +--rw module-type?                enumeration
       |     +--rw belongs-to?                 yang:yang-identifier
       |     +--rw tree-type?                  enumeration
       |     +--rw submodule* [name revision]
       |     |  +--rw name        yang:yang-identifier
       |     |  +--rw revision    union
       |     |  +--rw schema?     inet:uri
       |     +--rw dependencies* [name]
       |     |  +--rw name        yang:yang-identifier
       |     |  +--rw revision?   union
       |     |  +--rw schema?     inet:uri
       |     +--rw dependents* [name]
       |     |  +--rw name        yang:yang-identifier
       |     |  +--rw revision?   union
       |     |  +--rw schema?     inet:uri
       |     +--rw semantic-version?           yc:semver
       |     +--rw derived-semantic-version?   yc:semver
       |     +--rw implementations
       |        +--rw implementation* [vendor platform software-version software-flavor]
       |           +--rw vendor              string
       |           +--rw platform            string
       |           +--rw software-version    string
       |           +--rw software-flavor     string
       |           +--rw os-version?         string
       |           +--rw feature-set?        string
       |           +--rw os-type?            string
       |           +--rw feature*            yang:yang-identifier
       |           +--rw deviation* [name revision]
       |           |  +--rw name        yang:yang-identifier
       |           |  +--rw revision    union
       |           +--rw conformance-type?   enumeration
       +--rw vendors
          +--rw vendor* [name]
             +--rw name         string
             +--rw platforms
                +--rw platform* [name]
                   +--rw name                 string
                   +--rw software-versions
                      +--rw software-version* [name]
                         +--rw name                string
                         +--rw software-flavors
                            +--rw software-flavor* [name]
                               +--rw name         string
                               +--rw protocols
                               |  +--rw protocol* [name]
                               |     +--rw name                identityref
                               |     +--rw protocol-version*   string
                               |     +--rw capabilities*       string
                               +--rw modules
                                  +--rw module* [name revision organization]
                                     +--rw name                -> /catalog/modules/module/name
                                     +--rw revision            -> /catalog/modules/module/revision
                                     +--rw organization        -> /catalog/modules/module/organization
                                     +--rw os-version?         string
                                     +--rw feature-set?        string
                                     +--rw os-type?            string
                                     +--rw feature*            yang:yang-identifier
                                     +--rw deviation* [name revision]
                                     |  +--rw name        yang:yang-identifier
                                     |  +--rw revision    union
                                     +--rw conformance-type?   enumeration

      

      I advice you to review the leave definitions at YANG
        module for the yangcatalog.org, to understand the use cases.

      The most useful leaves to start with are the validation-status and
      validation-report.

      

      The second entry provides the impact analysis. There are thee
      options:

      
1. dependents only: only show those modules that
        depend on the target module(s).

         use case: you want to see the impacted modules

        2. dependencies only: only show those modules that are imported
        by the target module(s).

         use case: you want to see the bottleneck for standardization

        3. both

      

      Enjoy.

      

      Regards, Benoit  

      

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

        
          

            Subject:
            
            New datatracker release: v6.64.0
          

          

            Date: 
            Wed, 01 Nov 2017 06:36:58 -0700
          

          

            From: 
            Henrik Levkowetz <henrik@levkowetz.com>
          

          

            To: 
            codesprints@ietf.org, iesg@ietf.org, wgchairs@ietf.org
          

        
      

      

      

      
Hi,

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

Release notes:

ietfdb (6.64.0) ietf; urgency=medium

  **Yang resource links on yang draft pages**

  Drafts containing yang modules now get links pointing to the yang impact
  analysis, and to module metadata for each module.  Support has been added
  for ad-hoc trac instances, permitting automatic maintenance of role-based
  admin rights also for other trac instances than the WG, RG, and directorate
  wikis.  The draft submission automation API description is now referenced
  from the draft submission upload page.  'Additional URLs' for drafts are now
  sorted, rather than presented in random order.  Links pointing from draft
  review pages to mailing lists, for the full review text, are now validated
  in order to avoid presenting links to unavailable resources.  An issue with
  parameter expansion in a nomcom template has been fixed, as have various
  other issues.

  Details from the commit log:

  * Tweaked a page cache time to make newly uploaded session agendas visible
    with less delay.

  * Added a guard against iterating over None in stats.views.document_stats()

  * Added draft URLs pointing to Yang resources (impact analysis and model 
    metadata) for submissions containing Yang modules.

  * Changed the submission checkers to return more information in the 
    checker details json blob; in particular added information about individual 
    extracted code modules associated with a draft.  This is used by the yang 
    valididty checker to return a list of extracted yang modules.

  * Changed the SubmissionCheck.time field to use a default now value, 
    instead of auto_now, to permit migrations without changing the timestamps.

  * Added some more debugging output for occasional author extraction 
    failures during test.  See also [14226].

  * Added support for ad-hoc trac instances, with arbitrary names and 
    filesystem paths, but still bound to a particular group's roles for 
    management of trac admin rights.

  * Display document urls in alphabetical order

  * Permit document urls to be up to 512 bytes, rather than the default 200

  * New settings for adhoc wikis and yang document urls

  * Added a mention of the submission automation API on the submission 
    upload page.

  * Added cleaning of review_url from the review completion form, to make 
    sure it's retrievable.

  * Added some debugging code to help identify random test failures

  * Added a new field Meeting.days to capture the length of a meeting.  
    This is necessary now that we have previous meetings officially starting 
    Sunday, lasting to Friday, and future meetings starting Saturday, Lasting 
    to Friday.  We use Meeting.days to calculate Meeting.end_date().  
    Meeting.get_ietf_monday() and two cut_off() methods have also been updated 
    to be instance methods instead of class methods, and to not assume that a 
    meeting starts on Sunday.

  * Updated coverage data

  * Expanded one of the nomcom tests a bit, and updated a fixture to match 
    the current /nomcom/default/email/feedback_receipt.txt template.

  * Don't blow up when checking if the logged-in user is a document author, 
    if the user don't have a person record.

 -- Henrik Levkowetz <henrik@levkowetz.com>  30 Oct 2017 04:30:27 -0700

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

For development, copy the new development version instead:
  'svn copy https://svn.tools.ietf.org/svn/tools/ietfdb/tags/dev/6.64.1.dev0' <YOURBRANCH>

Regards,

	Henrik
	(via the mkrelease script)

.



    

  


--------------2EB99F48DCAB62DA6C02067E--


From nobody Sat Nov 11 19:19: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 2929A126D46 for ; Sat, 11 Nov 2017 19:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8njsnwqZ5l1o for ; Sat, 11 Nov 2017 19:19:33 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893C9124BFA for ; Sat, 11 Nov 2017 19:19:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1773; q=dns/txt; s=iport; t=1510456773; x=1511666373; h=subject:references:to:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DUr4IeQhu4YSxesxJ0CGeiLAs/sfi+xaCrv4wI3UorY=; b=GKMrv0H24RwwofYDvy+NoC52mvMV+olLu7NzwAGA9pHrPwXn2k3R87fY 5QHgqDg97gyChKcECE8GXBZybG6L4S2Sshiyu8HFVhMFgswjF2ekhh7qp fsJG5+cjVJkCZ4NBXLClqFK8K9Ddc1OCSvh3mFUF2S890hi7Yfjz4o0XV Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAAADvQda/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1ZG4ng36KH5EmllCCEQolhRYChEY/GAEBAQEBAQEBAWsdC4U?= =?us-ascii?q?eAQMDI1QSHAMBAgMCJgICTQIIBg0GAgEBih4QqlqCJ4sGAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR+BD4IlggeBVYISgwGDRIRogmMFkWiBE48vh2uNGYIVX4Upg2CHRYo?= =?us-ascii?q?xgjeJPIE5HziBclUlFR8qgmQJhHQjNgGKFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,382,1505779200"; d="scan'208";a="29710660"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Nov 2017 03:19:32 +0000
Received: from [10.24.112.116] ([10.24.112.116]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAC3JVtE025517 for ; Sun, 12 Nov 2017 03:19:32 GMT
References: <151045152562.30840.9044943952830084519.idtracker@ietfa.amsl.com>
To: "netmod@ietf.org" 
From: Joe Clarke 
Organization: Cisco
X-Forwarded-Message-Id: <151045152562.30840.9044943952830084519.idtracker@ietfa.amsl.com>
Message-ID: <757d08a4-e645-127d-c1c4-f2b980bc63ad@cisco.com>
Date: Sat, 11 Nov 2017 22:19:31 -0500
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: <151045152562.30840.9044943952830084519.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-clacla-netmod-yang-model-update-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: Sun, 12 Nov 2017 03:19:35 -0000

Hello, all.

This new version of our semantic version draft adds a proposed YANG
extension for module-version, discusses how we derive a semantic version
for existing modules, discusses a list of open items in terms of module
versioning (to be mentioned in the meeting), and fixes some typos and
wording.

Joe


-------- Forwarded Message --------
Subject: New Version Notification for
draft-clacla-netmod-yang-model-update-02.txt
Date: Sat, 11 Nov 2017 17:52:05 -0800
From: internet-drafts@ietf.org
To: Benoit Claise , Kevin D'Souza ,
Joe Clarke 


A new version of I-D, draft-clacla-netmod-yang-model-update-02.txt
has been successfully submitted by Joe Clarke and posted to the
IETF repository.

Name:		draft-clacla-netmod-yang-model-update
Revision:	02
Title:		New YANG Module Update Procedure
Document date:	2017-11-11
Group:		Individual Submission
Pages:		14
URL:
https://www.ietf.org/internet-drafts/draft-clacla-netmod-yang-model-update-02.txt
Status:
https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
Htmlized:
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-clacla-netmod-yang-model-update-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-clacla-netmod-yang-model-update-02

Abstract:
   This document specifies a new YANG module update procedure in case of
   backward-incompatible changes, as an alternative proposal to the YANG
   1.1 specifications.  This document updates RFC 7950.




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


From nobody Sun Nov 12 18:02: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 B6A5D127005; Sun, 12 Nov 2017 18:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 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, 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 VJ8XGbkpKTSw; Sun, 12 Nov 2017 18:02:34 -0800 (PST)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CD8126CB6; Sun, 12 Nov 2017 18:02:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3422; q=dns/txt; s=iport; t=1510538553; x=1511748153; h=from:to:cc:subject:message-id:date:mime-version; bh=BYP78yZO8ugJRJtO37LHhYnv8DGrPNi8WrVI1YuuUww=; b=FhU3lodwrKaEfTRgXbM955asf7gAWwYAyh8jtpTzfYsmNaR94RHXKcFp W00qNXpREsjGDoo0BhnorjFfpVK+rLFIjnGyoDwkUXae1PlFDHzIMvvFg nc+1DWAxgzsh0CA1QKafDdc87n4OkwjQBebZb6EqHvSKgCmr5StlVV/JE Y=;
X-IronPort-AV: E=Sophos; i="5.44,386,1505779200"; d="scan'208,217"; a="78661609"
Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2017 02:02:29 +0000
Received: from [10.75.234.179] (hkidc-vpn-client-234-179.cisco.com [10.75.234.179]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAD22Shc030222; Mon, 13 Nov 2017 02:02:28 GMT
From: Benoit Claise 
To: NETMOD Working Group , "ospf-chairs@ietf.org" , "isis-chairs@ietf.org" 
Cc: Routing WG , Alia Atlas , Benoit Claise 
Message-ID: <1332bb78-36a8-2888-2642-f08a30593a10@cisco.com>
Date: Mon, 13 Nov 2017 10:02:27 +0800
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: multipart/alternative; boundary="------------D4FC6AE8D9CEC46530C3275F"
Content-Language: en-US
Archived-At: 
Subject: [netmod] NETMOD bottlenecks for draft-ietf-rtgwg-yang-vrrp and draft-ietf-rtwg-yang-rip publications
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Nov 2017 02:02:36 -0000

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

Dear all,

Currently sitting in the rtgwg WG.
draft-ietf-rtgwg-yang-vrrp and draft-ietf-rtwg-yang-rip are currently in 
AD review.
Let's look at the datatracker new YANG-related URLs to understand the 
impact analysis (the dependent YANG modules) for these two drafts:

  * https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-vrrp@2017-10-25.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both
  * https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-rip@2017-10-25.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both

So the bottlenecks for standardization are:

  * draft-ietf-rtgwg-yang-vrrp:
      o RFC7223bis: ietf-interfaces
      o RFC7277bis: ietf-ip

  * draft-ietf-rtwg-yang-rip:
      o RFC7223bis: ietf-interfaces
      o RFC7277bis: ietf-ip
      o RFC8022bis: ietf-routing
      o draft-ietf-ospf-yang: ietf-ospf (draft status: still ID-exists)
      o draft-ietf-isis-yang-isis-cfg: ietf-isis (draft status: still
        ID-exists)

So the ask to close on RFC7223bis, RFC7277bis, and RFC8022bis asap.
I understand the LC will start soon for these drafts.

Regards, Benoit

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


  

    
  
  
    Dear all,

    

    Currently sitting in the rtgwg WG.

    draft-ietf-rtgwg-yang-vrrp and draft-ietf-rtwg-yang-rip are
    currently in AD review.

    Let's look at the datatracker new YANG-related URLs to understand
    the impact analysis (the dependent YANG modules) for these two
    drafts: 

    
    So the bottlenecks for standardization are:

    
    
      
  • draft-ietf-rtgwg-yang-vrrp:
    • 
      
      
        
    • RFC7223bis: ietf-interfaces
      • 
        
    • RFC7277bis: ietf-ip
      
          
      
        
      • 
      
    
      
  • draft-ietf-rtwg-yang-rip:
    • 
      
      
        
    • RFC7223bis: ietf-interfaces
      • 
        
    • RFC7277bis: ietf-ip
      • 
        
    • RFC8022bis: ietf-routing
      • 
        
    • draft-ietf-ospf-yang: ietf-ospf (draft status: still
          ID-exists)
      
        
      • 
        
    • draft-ietf-isis-yang-isis-cfg: ietf-isis (draft status:
          still ID-exists)
      • 
      
    
    

    So the ask to close on RFC7223bis, RFC7277bis, and RFC8022bis asap.

    I understand the LC will start soon for these drafts.        

    

    Regards, Benoit

  


--------------D4FC6AE8D9CEC46530C3275F--


From nobody Sun Nov 12 19:19: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 160C51293F2 for ; Sun, 12 Nov 2017 19:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEQvSfgzMQTy for ; Sun, 12 Nov 2017 19:19:43 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4C41293F5 for ; Sun, 12 Nov 2017 19:19:43 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 74D8C18215DD; Mon, 13 Nov 2017 04:18:37 +0100 (CET)
Received: from localhost (dhcp-8a3e.meeting.ietf.org [31.133.138.62]) by trail.lhotka.name (Postfix) with ESMTPSA id 73E171820F76; Mon, 13 Nov 2017 04:18:33 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Robert Wilton , "netmod\@ietf.org" 
In-Reply-To: <20171110160836.2hy5nr4zuklwnjjj@elstar.local>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz> <56ea1907-c2ed-1940-089c-527b33f0723e@cisco.com> <20171109181638.zel2otpzrptggvwz@elstar.local> <87lgje9m87.fsf@nic.cz> <20171110160836.2hy5nr4zuklwnjjj@elstar.local>
Mail-Followup-To: Juergen Schoenwaelder , Robert Wilton , "netmod\@ietf.org" 
Date: Mon, 13 Nov 2017 11:20:44 +0800
Message-ID: <87vaieoodv.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
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: Mon, 13 Nov 2017 03:19:46 -0000

Juergen Schoenwaelder  writes:

> On Fri, Nov 10, 2017 at 04:39:36PM +0100, Ladislav Lhotka wrote:
>> >
>> > So what is the difference between "schema tree" and "schema"? Or to
>> > put it differently, what is "all associated semantics" that you are
>> > adding to a "schema tree" to obtain a "schema"? RFC 7950 says:
>> >
>> >    o  schema tree: The definition hierarchy specified within a module.
>> 
>> As Rob points out, this is probably incorrect, as schema tree should
>> involve multiple modules. It makes no sense to talk about a schema tree
>> of an augmenting module unless we also take into account the augmented
>> module.
>> 
>> Anyway, schema tree is really just the hierarchy, i.e. a tree of schema
>> nodes, whereas schema is the hierarchy with datatypes, semantic rules
>> and all that. We can validate instance data against the schema, not
>> against the schema tree. This is at least how I understand it.
>
> The current definition says "definition hierarchy specified within a
> module", perhaps this was intended to mean 'tree of schema nodes', but
> perhaps it means "the hierarchy with datatypes, semantic rules and all
> that". ;-) Looking at the definition of schema node, I see:
>
>   o schema node: A node in the schema tree.  One of action, container,
>   leaf, leaf-list, list, choice, case, rpc, input, output,
>   notification, anydata, and anyxml.
>
> With this, your interpretation makes sense and a better way to define
> scheme tree would then be:
>
>   o schema tree: The tree formed out of schema nodes of a module.
>
> The schema could be defined as
>
>   o schema: All definitions of a module including the schema tree.
>
> I think it is OK to scope these definitions to the notion of a module.
> If people talk about the schema (schema tree, schema nodes) of a
> collection of modules, it seems natural to assume that this means the
> union of the schemas (schema trees, schema nodes).

In many cases it is more useful to talk about the multi-module schema as
defined by YANG library and, potentially, schema mount. The
tree-diagrams draft assumes that tree diagrams will capture both the
parent and mounted hierarchy in the same diagram. The thing is that a
collection of modules often defines hierarchies that aren't mere
side-by-side unions of the individual module hierarches. And
specifically, it is somewhat difficult to talk about a hierarchy for a
module that consists only of augments, without having the context of the
module(s) augmented by it.

So I would suggest to define both "module schema/tree" and
"schema/tree", the latter meaning a multi-module schema as defined by
YANG library and schema mount specification.

Actually, we have another candidate for a more precise definition, namely
"data model". So one option could also be to use "schema/tree" for the
single-module, and "data model/tree" for the multi-module stuff.

Lada


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

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


From nobody Sun Nov 12 19:47: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 E4B4F12932A for ; Sun, 12 Nov 2017 19:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOr-Lwp3eiei for ; Sun, 12 Nov 2017 19:47:01 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA771293F2 for ; Sun, 12 Nov 2017 19:47:01 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 144C218215DD; Mon, 13 Nov 2017 04:45:56 +0100 (CET)
Received: from localhost (dhcp-8a3e.meeting.ietf.org [31.133.138.62]) by trail.lhotka.name (Postfix) with ESMTPSA id 6EC021820F76; Mon, 13 Nov 2017 04:45:52 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , "netmod\@ietf.org" , Martin Bjorklund , Kent Watsen 
In-Reply-To: <56ea1907-c2ed-1940-089c-527b33f0723e@cisco.com>
References: <47B1141C-8979-4910-B7CA-2114B9C0D352@juniper.net> <68c6a4d5-fd3e-efdb-9c34-f69f241d6a31@cisco.com> <874lq4oq94.fsf@nic.cz> <7d8a8b01-6d3b-ac29-dd58-f2771ecdad56@cisco.com> <87d14rjwdq.fsf@nic.cz> <56ea1907-c2ed-1940-089c-527b33f0723e@cisco.com>
Mail-Followup-To: Robert Wilton , "netmod\@ietf.org" , Martin Bjorklund , Kent Watsen 
Date: Mon, 13 Nov 2017 11:48:01 +0800
Message-ID: <87shdion4e.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Mon, 13 Nov 2017 03:47:04 -0000

Robert Wilton  writes:

> On 09/11/2017 15:37, Ladislav Lhotka wrote:
>> Robert Wilton  writes:
...

>>>>> 3. Sec 2.1 Glossary of New Terms:=C2=A0 "Schema" isn't actually defin=
ed
>>>>> anywhere (RFC 7950 doesn't define this).=C2=A0 Should it be defined h=
ere?
>>>>> The NMDA datastores draft had a similar issue and we choose to define
>>>>> "datastore schema" instead.
>>>> I think the right place for defining the term "schema" (and "data mode=
l"
>>>> as well) is the specification of YANG because it is desirable that all
>>>> documents related to YANG use the same meaning.
>>> OK, 7950 doesn't define it today.=C2=A0 Is that a problem?
>> "Schema tree" and "schema node" are defined and used a lot in 7950, so
>> it might be good to define "schema" as well - meaning the schema tree
>> with all associated semantics.
> OK, but we can't add definitions to 7950 now.=C2=A0 Would it make sense t=
o=20
> add the definition to the NMDA draft and reference that?

Ultimately, these terms belong to the YANG spec, but some termporary
solution might be useful, and the NMDA draft looks like a good
candidate.

...

>>>> But it could also be that such rules are inappropriate in this documen=
t and
>>>> rather belong to a protocol spec.
>>> I think that they are OK here if this draft defines the lifetime of the
>>> schema.=C2=A0 If it is just the same as YANG library, then perhaps this=
 could
>>> be left to the YANG library spec to specify?
>>>
>>>>> 5. Sec 3.2. paragraph 2, last sentence: "are possible and such needs"=
 =3D>
>>>>> "are possible, and as such, needs"
>>>> I actually don't understand neither this sentence nor what the point of
>>>> such exceptions could possibly be.
>>> An example would presumably be where effectively the same data is being
>>> mounted in a separate place.=C2=A0 E.g. the list of physical interfaces=
 in an
>>> LNE may represent a subset of all physical interfaces in the device,
>>> that would also be present in the host model.
>> Then I would say simply "..., its data will generally have no
>> relationship to the data of the parent, unless the data model explicitly
>> states otherwise."
>>
>> OK, "data model" is another term that isn't defined, but to me it is the
>> collection of YANG modules that define the schema. I think it's not
>> possible to say where the exception has to be stated, it can be
>> either in the parent or in the mounted module, or even elsewhere.
> OK, but I would avoid introducing the term "data model".

Any reason for avoiding it? This term is used quite a lot.

>
>>
>>>>> 6. Sec 3.2 paragraph 5.=C2=A0 Would it useful to state that even thou=
gh the
>>>>> schema is the same, the data is different and not necessarily related.
>>>> I think this goes without saying, as it is also the case for a single =
mount
>>>> point that is a list node - data in each entry is different.
>>> In Sec 3.2 paragraph 2, it clarifies that the mounted data is generally
>>> separate from the parent data.=C2=A0 For paragraph 5, I still that it is
>>> useful to state the equivalent that if a schema is mounted twice it
>>> doesn't mean the same data is mounted in both places.
>> This should be absolutely clear to anybody who understands that we are
>> only constructing a schema because, e.g., multiple uses of the same
>> grouping in YANG also don't mean the same instance data. Unfortunately,
>> with schema mount this confusion arises again and again, maybe the term
>> "mount" is really misleading.
> So, I'm not confused by this (but I am quite familiar with the=20
> solution), but think that this is an area where a less familiar reader=20
> could make the wrong assumption, hence the suggestion to clarify it.
>

Ideally, everybody should understand that schema mount is just another
means for making modular schemas, as augment is. Unfortunately, it seems
that especially the "inline" method attracts instance-related
considerations.

>
>>
>> ...
>>
>>>>> 9. Structure of ietf-yang-schema-mount module:
>>>>>    =C2=A0 - Should "uri" under namespace be marked as "mandatory" so =
that it
>>>>> doesn't appear to be optional in the tree diagram.
>>>> Yes, this is an omission.
>>>>
>>>>>    =C2=A0 - Should the "module" name be included under the namespace.=
=C2=A0 It seems
>>>>> that lots of other "module bindings" are done via the module name rat=
her
>>>>> than the namespace?
>>>> We need it exclusively for XPath, so it seems natural to stay close to=
 XML
>>>> namespaces.
>>> I was suggesting that it might be useful to add "module" in addition to
>>> namespace.
>> This is possible but redundant, I was thinking about replacing the URIs
>> with module names. It probably doesn't really matter unless the URIs are
>> written by hand.
> I'm wondering whether this list is really required at all.=C2=A0 E.g. if =
you=20
> see my other email about YANG library structure, then if the structure=20
> for schema mount and YANG library was converged then would this list=20
> still be necessary?=C2=A0 Or could there just be a reference to the paren=
t=20
> schema that xpath references are resolved against?

Some kind of prefix definition (be it URI- or module-based, or both), is
still necessary because potentially we can have modules with conflicting
prefixes.

Lada

>
> Thanks,
> Rob
>
>>
>> Lada
>>
>>>>> 10. Example A.3.=C2=A0 This contains some features that are enabled. =
Possibly
>>>>> it would be useful in the description to point this out, and state th=
at
>>>>> unless the features are listed they wouldn't be enabled.
>>>> Yes, we reuse the groupings from ietf-yang-library, and the idea is to
>>>> apply the same semantics. And as you are saying below, it would be more
>>>> straightforward to integrate it directly with YANG library.
>>>>
>>>>> My last general comment relates generally to the structure of the
>>>>> Iietf-yang-schema-mount.=C2=A0 As Lada has pointed out previously, th=
is
>>>>> module and YANG library bis could be more closely aligned (e.g. along
>>>>> the lines of reusing module-sets for the "schema" list).=C2=A0 It wou=
ld have
>>>>> been nice if this module could augment YANG library (so that you can
>>>>> easily get the modules and schema mount information in a single simple
>>>>> request), however that would put an undesired dependency delaying
>>>>> publishing this draft until YANG library bis is completed.
>>>> Of course I agree, but I think the priority should be to make things as
>>>> simple and easy to understand as possible. They are complex enough
>>>> anyway.
>>> Thanks,
>>> Rob
>>>
>>>
>>>> Thanks, Lada
>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 20/10/2017 22: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
>>>>>> .
>>>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Mon Nov 13 01:07: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 E09DB129483; Mon, 13 Nov 2017 01:07:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrPwsH9xOzGT; Mon, 13 Nov 2017 01:07:34 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDFD126B6E; Mon, 13 Nov 2017 01:07:34 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 3450A1AE0311; Mon, 13 Nov 2017 10:07:32 +0100 (CET)
Date: Mon, 13 Nov 2017 10:06:09 +0100 (CET)
Message-Id: <20171113.100609.2174827066431142057.mbj@tail-f.com>
To: netmod@ietf.org, netmod-chairs@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] Please send status of WG drafts not on the agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Nov 2017 09:07:36 -0000

Lou Berger  wrote:
> Hi,
> 	If your *WG* draft is not on the agenda for this meeting, please send
> 	the list a status update -- covering recent changes, open issues, plan
> 	for completing the document.

draft-ietf-netmod-entity-05
---------------------------

As reported in:
https://www.ietf.org/mail-archive/web/netmod/current/msg19162.html

this draft is ready for WGLC.



draft-ietf-netmod-rfc7223bis-00
-------------------------------

This draft is ready for WGLC.

It has one minor unpublished clarification, see the thread
https://www.ietf.org/mail-archive/web/netmod/current/msg19271.html
but this can be handled as a LC comment.



draft-ietf-netmod-rfc7277bis-00
-------------------------------

This draft is ready for WGLC.



/martin


From nobody Mon Nov 13 10:48: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 8C09B129B47 for ; Mon, 13 Nov 2017 10:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5scR1qwmbwq for ; Mon, 13 Nov 2017 10:48:55 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5AA129A99 for ; Mon, 13 Nov 2017 10:48:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 19CF014066DF for ; Mon, 13 Nov 2017 19:48:51 +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 DHz6oO5tCHZ8 for ; Mon, 13 Nov 2017 19:48:51 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id E9B5314066E0 for ; Mon, 13 Nov 2017 19:48:50 +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 RTB_is1Ocdqa for ; Mon, 13 Nov 2017 19:48:50 +0100 (CET)
Received: from [192.168.43.32] (77.16.65.20.tmi.telenormobil.no [77.16.65.20]) by mail.transpacket.com (Postfix) with ESMTPSA id 9C94514066DE for ; Mon, 13 Nov 2017 19:48:50 +0100 (CET)
To: "netmod@ietf.org" 
From: Vladimir Vassilev 
Message-ID: 
Date: Mon, 13 Nov 2017 19:48:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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: 7bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] validation of draft-ietf-netconf-nmda-netconf-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 18:48:57 -0000

Hello,

There is a validation error reported for 
ietf-netconf-datastores@2017-08-24.yang:

Error: XPath expression 'derived-from-or-self(../datastore, 
"or:operational")' with invalid identity param 'or:operational'
ietf-netconf-datastores@2017-08-24.yang:140.63: error(348): invalid 
XPath expression syntax

Vladimir



From nobody Mon Nov 13 22:57: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 70EE7129477 for ; Mon, 13 Nov 2017 22:57:31 -0800 (PST)
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 hRpUt-Wp_wYT for ; Mon, 13 Nov 2017 22:57:30 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.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 CFDF1129476 for ; Mon, 13 Nov 2017 22:57:29 -0800 (PST)
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=c9jmiddq7gKOa6F+eKcihIEe9dJ1PZlH3wSwwYRcBxo=; b=Xobf/FLOve6aP319tcO+lNh3f/3/4UG4NfWYjR+A8FfvuAsMSqSCz+1Hu4Zt+KgoXDGVWEE/udLplhrqh6kgRkUa5Y4j8M+QxTCc8TAp8fcW75AGP7ILNESZEjqp5nlP6xbp+5oGKVtqDJcOVuL1AL4wzK0pkseBZhce0b0mchQ=
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.239.4; Tue, 14 Nov 2017 06:57:28 +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.0239.005; Tue, 14 Nov 2017 06:57:28 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [100all] IETF 100 Final Agenda Changes
Thread-Index: AQHTW6UdeN8fT658NkqDiDOYEABG9aMT+n8A
Date: Tue, 14 Nov 2017 06:57:28 +0000
Message-ID: <3EB499A8-D1A1-4CFC-A5B4-3AB62491DF9F@juniper.net>
References: <151048427509.30856.4928588510399402531.idtracker@ietfa.amsl.com>
In-Reply-To: <151048427509.30856.4928588510399402531.idtracker@ietfa.amsl.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: [116.197.188.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:CZvpRokDsK+QUa+cbucAqgBuVzS+Mgh1myEjTZgmOJe+Uxhd0wZC9bh2KHCghn+EpndmWDLigjHkkzN5o5CtFCJofMWPcwSg4YdJAY5++2Mog4mVRey5eoTJiWZWNuvH+a+zqjqBr2E6GYZVgcbH6ah8FUAyxpNPNf/7NYx5N9gOBlnfrRH74qzbAvdrKLZyTSgEBaCYShBGb5/7IDfcEiG/nryDWouEOvF4j2ibSgjQ5HKUMUd0mu3HzjpEeujs3qONvBSUP2UmucbMKz8u26kQZF3U7cVe6AQtzJm/GktLCADorGSN6dlgLOk6LpoS8bhYbPw9dvP1XH+qjNvQztZhJTThSnLIXFc5ZVQz+2k=; 5:8Muk6BWXuyGszMn7TW4m4VlxzmTOKKuId6iuL+x+EyunhgSo9ofQzACajLrnGQuV6MIN64q+ga4AfserZd0rI9SMO1h/GUulp9Ae7dtV0DNHCk3QMkKaf0eMOnZjxm62S0rLhkweQJMJaOF7TND+infjeN1Dp6N7ci0l+wXZdDY=; 24:y7eKBHL5wlC+04yYGyzK1K1c5ojbtdyZZCq5el8ZYgL8vXabhx5WdxyBwoottfebnncA07kvnOFhYGN42OkffgDvzIXR7xcGK9WWaayhe3Y=; 7:U9kThWOaZ8w3StW66ZkcVHF1tQDsXWxRQ7KnW3LkMo5uXLyXr0hUAT3ceJzVLg6Ub9HcJB9c4kS3ljXV9ghya9904lGiZbSdG2Ua66XZdHjFvetAiM9i5okQJO+/mXfuI7Ep04JiLPWQlxK/Z6DHEl29P71XfAPO8K2mRl7BcRVFNNIgCCon6jgGH9+Gd+6fUU7M0Ua5PMC9umFyYBkCzfQgYSWgEUq3xWU3H9nadiYbosBTStVV6eoQSyc/7lpf
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 00e0a632-0b9c-4f14-32c7-08d52b2cf84c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:BLUPR05MB276; 
x-ms-traffictypediagnostic: BLUPR05MB276:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
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)(3231022)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(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: 04916EA04C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(38314003)(53754006)(199003)(189002)(101416001)(6512007)(2473003)(53936002)(83506002)(2351001)(82746002)(3846002)(76176999)(54356999)(50986999)(6116002)(2900100001)(102836003)(99286004)(36756003)(25786009)(3660700001)(3280700002)(106356001)(478600001)(33656002)(14454004)(189998001)(2906002)(5640700003)(105586002)(2501003)(86362001)(66066001)(77096006)(8936002)(316002)(1730700003)(8676002)(81156014)(81166006)(6486002)(6436002)(6506006)(83716003)(58126008)(229853002)(2950100002)(7736002)(6916009)(305945005)(5660300001)(68736007)(97736004); 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: <48A26A79D79ED440865402CE2FB2B6CF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 00e0a632-0b9c-4f14-32c7-08d52b2cf84c
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 06:57:28.6310 (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: [netmod] FW: [100all] IETF 100 Final Agenda Changes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 14 Nov 2017 06:57:31 -0000

QWxsLA0KDQpQZXIgdGhlIG1lc3NhZ2UgYmVsb3csIHBsZWFzZSBub3RlIHRoYXQgYm90aCBORVRN
T0Qgc2Vzc2lvbnMgdG9tb3Jyb3cgYXJlIG5vdyBpbiBTb3BoaWEuICBJbiBwYXJ0aWN1bGFyLCB0
aGUgZmlyc3Qgc2Vzc2lvbiBpcyBubyBsb25nZXIgaW4gUGFkYW5nLg0KDQpUaGFua3MsDQpLZW50
IChhbmQgTG91KQ0KDQoNCi0tDQoNCkhpIEV2ZXJ5b25lISANCg0KQmVsb3cgYXJlIGNoYW5nZXMg
dG8gdGhlIGZpbmFsIGFnZW5kYS4gQXMgYWx3YXlzLCB0aGUgbW9zdCB1cCB0byBkYXRlIHZlcnNp
b24gb2YgdGhlIGFnZW5kYSBpcyBvbmxpbmUuDQoNCkNBTkNFTEVEOg0KRElOUkcgKHdhcyBNb24g
MDk6MzApDQpNVEdWRU5VRSAod2FzIE1vbiAxNzo0MCkNClRMUyAod2FzIE1vbiAxNzo0MCkNCkky
UlMgKHdhcyBNb24gMTc6NDApDQpETUFSQyAod2FzIFRodXJzIDA5OjMwKQ0KRE5TT1AgKHdhcyBU
aHVycyAxNTo1MCkNCklDRSAod2FzIFRodXJzIDE1OjUwKQ0KQ1VSRExFICh3YXMgVGh1cnMgMTg6
MTApDQoNClJPT00gQ0hBTkdFOiANCk5FVE1PRCAoV2VkcyAxMzMwKSByb29tIGNoYW5nZSBmcm9t
IFBhZGFuZyB0byBTb3BoaWENClNJRFJPUFMgKFdlZHMgMTMzMCkgcm9vbSBjaGFuZ2UgZnJvbSBT
b3BoaWEgdG8gUGFkYW5nDQoNCkRBWSBDSEFOR0U6IA0KVFJJTEwgbW92ZWQgZnJvbSBUaHVyc2Rh
eSAxODEwIHRvIE1vbmRheSAxNzo0MCBpbiBWSVAgQQ0KDQpUSU1FIENIQU5HRToNCkFWVENPUkUg
d2FzIFRodXJzZGF5IDA5OjMwLTEwOjMwIG5vdyAwOTozMC0xMTowMA0KTFdJRyBXZWRuZXNkYXkg
MTEwMC0xMjAwDQoNCk5FVzoNCklOVCBBRCBPZmZpY2UgSG91cnMgLSBUaHVyc2RheSAxMDowMC0x
MTozMCBpbiBDbGFyaw0KDQoNClRoYW5rcyENCg0KSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KMTAwYWxsIG1haWxpbmcg
bGlzdA0KMTAwYWxsQGlldGYub3JnDQoNCg0K


From nobody Mon Nov 13 23:19:09 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 2AA7F129445 for ; Mon, 13 Nov 2017 23:19:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.65.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151064394717.6009.11756979178514340356.idtracker@ietfa.amsl.com>
Date: Mon, 13 Nov 2017 23:19:07 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [netmod] Milestones changed for netmod WG
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, 14 Nov 2017 07:19:07 -0000

Changed milestone "Submit draft-ietf-netmod-revised-datastores to IESG for 
publication (as Standards Track)", set due date to November 2017 from July
2017.

Changed milestone "Submit draft-ietf-netmod-schema-mount to IESG for
publication (as Standards Track)", set due date to December 2017 from October
2017.

Changed milestone "Submit draft-ietf-netmod-entity to IESG for publication
(as Standards Track)", set due date to January 2018 from May 2017.

Changed milestone "Submit draft-ietf-netmod-acl-model to IESG for publication
(as Standards Track)", set due date to January 2018 from June 2017.

URL: https://datatracker.ietf.org/wg/netmod/about/


From nobody Tue Nov 14 08: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 59F6E128DE5 for ; Tue, 14 Nov 2017 08:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.387
X-Spam-Level: 
X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 GWSmWsp7P2Z2 for ; Tue, 14 Nov 2017 08:51:50 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F4C127843 for ; Tue, 14 Nov 2017 08:51:49 -0800 (PST)
X-AuditID: c1b4fb3a-c73ff70000004c48-08-5a0b1f241fb7
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1B.19.19528.42F1B0A5; Tue, 14 Nov 2017 17:51:48 +0100 (CET)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 14 Nov 2017 17:51:47 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GJiX0KQeiD6OYq0hsx+PVUSh2c3mYyKfjlbCzrHerpo=; b=I18fKgJeg2TLJJAAd0QC+ZlULrmc1UxAY/BIjr/5DHJbv203DELz2wo+fCOeky6gRKq8nVIvN+9tSUSr/hyYauQwJldNg3iKSCTtpqVN0g/0sz/GVEsyhh5tyxqn4aaUVvQ0S1f7U9lIs8cASku+UuM2G/6OUeQ7WYtCYlhg0pg=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [10.10.12.142] (103.26.221.241) by HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:2c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Tue, 14 Nov 2017 16:51:44 +0000
To: "netmod@ietf.org" 
From: Balazs Lengyel 
Message-ID: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com>
Date: Wed, 15 Nov 2017 00:51:22 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [103.26.221.241]
X-ClientProxiedBy: HK2PR04CA0083.apcprd04.prod.outlook.com (2603:1096:202:15::27) To HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:2c::15)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: a5e044c7-0025-43b6-284f-08d52b7ffdc5
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR07MB3436; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3436; 3:pMO94dYp+0zkRYIfyidHrc/iBglS3ewiA+1VWMa4ymwySj2AsTQXuClOqK/0RV4T6w+FnYKyy8iS4KAMJQOTgIZg330IFIsXPDrbqPQL45qMOUJjcg92xVYtFN81QV1xogPBLvFHrx3E+i0cAmFymSmv2E9d3fOTH572CKPrn8LL0hzdiZPSLBd6/EIPKf+uVuZKOC2iJS/Osq9TNqO6KZ2QWRzvpVqbK7GbyfUxOHMyLuzTD8+LOeZXpIhXQ1JL; 25:RTDr+Ci3M2oCCswne4iS+mGYoRy+3IWb82PIerRd8B8rFKCBGQBsXNwrRh+Rg6HzAW2dhqqkOjXpVxPRt7qhTpDYLyxF0fON/yDbmUUPTqKRuQJHTO38nVxsqwk8AY/m1RYFdQ2gTbj4aewP0Ptpicutq9CkMt2QlQjuJ4efp2yUBf0eaqS33XBVAsLzjoVD1KkTZzWrc5BUgpRzUuVczgBW9XWBopDX+W47nLhkyicWDFvppOp0qfy7f0fFB9Yw/WiRa0ssJr4u29VAKbEiJOUaKqwmpPk/BxqYiixr/TzriOU9NJAlzZbCP1BD2dmTwGK+gb6KxWif6A7cCfKssQ==; 31:voJjP4Szmv+RXyUdX/NiEWFJrupn652KyGAc2ql5THv5xRC1f5VtOaC/BRcTvT1N+dX+n+OWMc97bI+mj+TpKiBxwR9+M+DlUXjo0JaKjpmCStqdaWLTuDqLkgk2J3PKjPuCbEk/+R5lFgIQn3u/45xBUsH5QCqlgIVRDicGVLwH9ZFPYio9PkhmBGSsRfpT0yQvorDEz+aW9ntUJoEYQRMDAVPG9vAYRQqj8JamNCk=
X-MS-TrafficTypeDiagnostic: HE1PR07MB3436:
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3436; 20:PFXJW9g4xvR4PzXm2N9901ANSqh38rKrLWwPzKOLI01HS/lj7P4KxoDmv8yqlzbtwoHhdpy/FGcwZ/d1zRFqSFe9eQ5FHnakVkPVPhEDhiocIsrM1vOoZ8mN4SY3iuQM+N/VCW4ScssDWXd7T8msCZoQxLRgRCrdd3Jo6QdBptXnA8NB35nYO7EiDcZ+zE/qw2dtI7cBdux3MJTGxWURqOt8kEJ9ZFucdLpGkcnOap8nTDShbyo+bBb/y1lo2h18dV7WlyoEORXt+J/I4h5HnktWIGEGb3qCeIrYDhmQ/Jo2Sq6xbpazUmISLF6i8ETFeXZOSixPYDGkEQkoynP+vqqIbOtRpsodD+T3PjFB5WsaJ/KQBc/DwdR4eDfsHWA7Ze4qCfAO4DSJLgxYgcQN7GvZ7hrBE2dby5kyj2GKmjl0dBQ9jcKiNMSTgP0XLk/yRuIWR2p7QToUQtyyziZYDUNIutO9c5dBG6z3A2mTd8XKFqsNZUqBHCCvrv5JC6fj; 4:7AxsjN6m/p6KqQ5LDRNDreH0FF/jfFHTZi+4Ln6JjYmDM/xuTaxhJAiqkzET0vi1k1IBsaa68Vi9vBrHDgIdSEFifBFuLpLZa+8tb52pVkOOCuwy7d81opy8jBVz1IhduAK6IhPipI2FLpgMx6OsviFUZdPKnI0/HW7kLsg2coFgd53owigVO7FoScUmMiWTLZz1MTNN24OdC+P4Nl7BzVlGACRjmBxji6Oe0j+hU9Ab0C3tG1SI0UBHAcev2i8zG8J4AON1KVrX+ncLCG10dnyMnAD1YAkm1+pS2Pctqb6aT/mLbTePJJHqaxALfBVr
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231022)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3436; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3436; 
X-Forefront-PRVS: 04916EA04C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(376002)(346002)(39860400002)(189002)(199003)(252514010)(33646002)(2351001)(2870700001)(23676003)(16526018)(58126008)(6116002)(230783001)(1730700003)(5660300001)(81156014)(2501003)(81166006)(2906002)(189998001)(65806001)(65956001)(66066001)(64126003)(3846002)(77096006)(23846002)(5640700003)(6486002)(97736004)(83506002)(50466002)(106356001)(15650500001)(86362001)(31696002)(16576012)(65826007)(105586002)(478600001)(68736007)(6666003)(7736002)(54356999)(50986999)(53936002)(6916009)(31686004)(8936002)(236005)(54896002)(25786009)(36756003)(8676002)(101416001)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3436; H:[10.10.12.142]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDM2OzIzOnZaQlBrVjkwdzNnSFZab3FrLzNnU2g1eit3?= =?utf-8?B?Yjk3ZXR3RGhEaURJdUJIdVVLSjQrZDdOTkNPK1ZwQ2tXWmQwZTFqSEh0SFlB?= =?utf-8?B?NWNzU0Y5MEtvNS9PZ2tod283dnRaRDRrSnZUZ1VuZWp4cFljVCtCeithTWt3?= =?utf-8?B?TGJpMUZTMXVFSjFYWjZuVTJ3a3haRkFoTXVycFlGcm1JQktlQU53enU3ZDVK?= =?utf-8?B?bjJVc0I1cDVENUlOUFg4SXRtMEI1bU40eU84cHNaL3gvRitONjJLK08wNVFw?= =?utf-8?B?cE5obVpwNVVhdmdTc0JSNHd2M3kzR3J0dDZySUg4eVFjcG5vdllrcUVGUWRN?= =?utf-8?B?MVVlSkEveVNHR3BMcTBac05rb1Z6RlEwRGszN2NTaEZGNWZPamRDM1pEemN6?= =?utf-8?B?am5DREdtV2FxMmNsbDZISjBoMmJtMUZVTlZWZTBzNU9zVUxqUDFVRC80U0xa?= =?utf-8?B?Tk5sNjFBamJRME52Tk1lVzlvTnRpbXhOZ1Vmc0RLdUtmRUxJMWJsZlkyRjM0?= =?utf-8?B?VVFoUUpIdkxlSlZ3SG1GRXF0SjJvRWNTSUVsT2ZyeU9xQ3A3YTBwNHVTYXVQ?= =?utf-8?B?YlVXWFJWeEtXMVpHcXR2WDdrTHJRM2xTL25GTzFEdWU5N3RhL3VrNXozSHlE?= =?utf-8?B?L3hGWENXSCtxZi9mRWJwTExHWUdGemJPSFk3bTgvNWZZUDJLcDYwYmtmakNu?= =?utf-8?B?a0FzNElsVGprVjUxTG9qa0xWN2srL1dsNkQ5cjdvcDREZ1NHNzVZS1k5d1Fw?= =?utf-8?B?OWNRYlVNbU41eTcrcVEwQkFDQ2VCd1c5RHpTWWE1SkRjcVhqdVpEZUhYL0k0?= =?utf-8?B?L1hZNUZTQ3dFY2xCclFTSHU2U3pYa0lMZU5XV1FHTzJhc3Z1RHVxRk16bnV2?= =?utf-8?B?YmNBVWtuRHFrY2tiNUZXeWsrem51YjkzSUorQTU3TGNHMExRdU5YNDkxR1o4?= =?utf-8?B?di95RXUwQklnaTlzTDVwTnZWT2M0bXFzc2VxdVh5YTBOMTZpNFpMM0s0aTAx?= =?utf-8?B?Yjg4TU5KTWlGMnlKV3BUM1Z4ZE5kTkdxWHduVEU4aFVSc0g5aVNPNHg0cVJL?= =?utf-8?B?ckNNQjlkQU1IZEs2OGxlcFNjVG5uSDBMM1U5TDNoTlprUjY4MW42M25BL0JM?= =?utf-8?B?c0xmOXF2YnhPQkpyWENRS0hlc051ZG40K0wrUHNOampZdG9rL1NGeitzei9U?= =?utf-8?B?NFJjYmhMcC9YWGRCU2xmNHNSK0thbmZ2eURPTlVHMXNRejBBL24yelFKdWtP?= =?utf-8?B?ZWdCYmUySHNrZWNFbDlsS2tVaU1vR1JiMDB5MWlLSUxyN2NLbVZDbTFJYUJi?= =?utf-8?B?ZnZFZ3hKaDRCMUg0R1FnRUYrR3hLWUVIUXZaaTRJRVQ0a0E0L2hPd3RBMGxm?= =?utf-8?B?VFl5KzNORnJqTWF0UlVlTktSSnMyNmh5SWxrcnV4eWRiYzdzSE16bXVPcUhu?= =?utf-8?B?MVNVOTJaYXFCNGxoMWlQWVFKOXo5L281T1Nta3JaTTZRZUtxYnI2WEFqM0xm?= =?utf-8?B?OU5ZTzRNT0VyY08vMTZQYkdIaXlVclBaaDQ5TmJleXpVWkd4anIrN3RtTjFC?= =?utf-8?B?bFcvTHU3K25hL3BUV01LTG4xSC8rS0FPWERXRjg1dFRvcFgvemRodVdFdHdn?= =?utf-8?B?U0FCazVIanpFNlVDbmhHcVlvNEZ3NlBnUFBsb1ZjMmY5MkhMUTF5eEZpK2c0?= =?utf-8?B?T1pIdHZTeFgxUjRlYVBjRlNsUGx3bmJQeG9qd1pVYU9PUEhtWXArRzNjdEpE?= =?utf-8?B?WXBobzA3anlEUGR3U1JzbmpzSXRGWU5manVQUE9OUk8rUTdPT2pnNW9rNWtN?= =?utf-8?B?RFVuMzVkakh3VmdmTUJHSWFybGp4TG5pZEoyZUQ2aVZJVEE9PQ==?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3436; 6:9wsmaNbGQIjV9h/UeSkz3DDOpmLkKXWuqvawQrudHVE2V6XwgMZzpSwLgI5tTeiMU9ubYkoxaxTW+kNpK4yvvOWeo3EBqFSHPgSgCPNR/mclIQ2ACEHZynrTTlAs6kj4GcaXnsqMR6tSGiFAkWMi8yWOgEdfPuK3gP2/Q9HCtXyHXlMmXJ2ddhdKo6JKrDii2kDgPpalw3WXT3+6brtt7XWV5vxr+zRejyQRQ/yVgNLVEroV51JJzr+25uDhON3JZ42uVEL3u3M52XCgyMBFlUrHebTFmTxrv1xfOlqBMR47qlDt0wLm993LkzdL+ZQqbFXRf3ypopxujsRivyT0XjTd1lIEvzWlMTxaMiDVoFw=; 5:LJNUXQ++3zTLk0N/6AC+eZzYVl2VvSid+CQV7xUz/I6PilRrmwbQ3onFSb9So/j/U5VgCiacQyVXHhHMl/vFnNFTBMh4YAc0M4R5uzzr2sFHhuqnSEW2a+PLvlk1IEDPnY+FLxe6TyC21xxc2cxU51E24eWttJbS5Bd9gCmY1dQ=; 24:8UgUjgwHny2WouySzg8thz/NxK5aBEMMisNREXmjvgqoEzKapKkJdHaCnKmNqDhvIH5EV0v3X5WJZsTTGj5yi1Z20HM+NOwRoPqS77DrsA0=; 7:BHWMiDCfwqYA7FIs7JNFwzbH6YmV7rYIPLECrkR/nIjSRlEkkCookZC4dyehVENvOZ2fV7vmSrQV1MAsmWQfg3v3KypAtBNGoyGcuLtxt/WDU3Z7RNIXsx7jGMbNhFdH9H22GBXcLRyxsbxJpeOq1yIQtViTEHvqgpa2ql76FwFxTGu3oXx2d4ql0aUO/ZL4HcAbrSEQGTcpLsd5efoskg0QAn2RZ2cS3DZjhOiwqyba7b+b+FSODCR62rLcqy8R
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2017 16:51:44.9159 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a5e044c7-0025-43b6-284f-08d52b7ffdc5
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3436
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUyM2K7oq6KPHeUwa8lIhbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEr49iBc0wFG3Qq1mzbw9LA+FGhi5GTQ0LAROLaqcvsXYxcHEIC hxkl/m3cywbhnGCUaPm/BMxhEehllpjUdZ0RpIVRIE5i55qFrBBVrUwSs5oOs4EkRATUJWbu XA9mswkYSUztP8/SxcjBISxgI/F+kzZImFfAXmLP18fMIDaLgKrEhB1bwWxRgRiJiQ8uMkLU CEqcnPmEBcRmFtCQaJ0zlx3CFpe49WQ+E4QtL9G8dTYzxAtKEg/aH4C9ICEwlVFiYet8VpCE EFDzwwt/WSGKZCWOnp0Ddo+EgK/E5Z1xEPUzGSX+3+2Aam5gl/i/YxrUVC2J22tPskEkfrBJ XJ5wgx0ikS1xb+EPRgjbSuL1r++MEEVXWCXOX1kG1S0jcejQQyaIxCNWiUMbHrNA3JQqseVG C9TYNUISDSv+sU9g1JyF5PFZSB6fheTxWUgeX8DIsopRtDi1uDg33chIL7UoM7m4OD9PLy+1 ZBMjMFUc3PLbagfjweeOhxgFOBiVeHh5ZLijhFgTy4orcw8xSnAwK4nw7pzFFSXEm5JYWZVa lB9fVJqTWnyIUZqDRUmc10MEqFogPbEkNTs1tSC1CCbLxMEp1cBY2V5bvTzRuWdzQNrnuK2R v989L9itqjXr8P1758+3GvI96522TfndiYdMOj89mCKbOm0fO8qKvdzGNmXJq6bpfIcLHBYf fsI99Zt/dfpcYeWlhjmK97/3u6WGHpS4zRAz8bu4bJi9bWLLrNiasE759CiRrjdiRQseSc4w W9x5c/1aq36WOf5KLMUZiYZazEXFiQDRenFIEQMAAA==
Archived-At: 
Subject: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 16:51:52 -0000


  

    
  
  
    
Hello,

    
First of all Ericsson very strongly supports this draft. This is
      a problem we definitely have, and for which we had to create our
      own internal solution. So we would love to see an IETF solution!

    
General)

    
The document does not mention some other problems with the
      current versioning. These stem from

    
    
      
  • we should allow non-backward compatible (NBC) changes in some
        limited cases
    • 
      
  • it should be possible to determine two module versions'
        compatibility without a line-by-line comparison
    
      
    • 
    

    
Whenever a client OSS implements some higher level logic for a
      network function, something that can not be implemented in a
      purely model driven way, it is always dependent on a specific
      version of the Yang Module (YAM). If the client finds that the
      module has been updated on the network node, it has to decide if
      it tries to handle it as it did the previous version of the model
      or if it just stops to avoid problems. To make this decision the
      client needs to know if the module was updated in a backward
      compatible way or not. This is not addressed with the current
      versioning.

    
While having PYANG based checks for backward compatibility is a
      very good idea, a  comparison based check will never be a complete
      check. It is quite possible to change just the behavior of an
      rpc/action/etc.  without changing the YANG definition.  This will
      only show up as a change of the description statement that can not
      be analyzed by PYANG.

    
When upgrading a network node we might introduce non-backward
      compatible (NBC) changes. Today we need to introduce a new module
      for this. That means during the upgrade process the node must
      convert stored configuration instance data from ietf-routing to
      ietf-routing-2 format. Instead of solving this data
      transformation/transfer problem just for a few NBC data nodes, we
      will have to do it for the full model. This is complicated. In
      many cases the transformation of a few NBC leafs can be handled by
      good defaults or with a small script. Transferring the full data
      set is more complicated. If we allow NBC updates in some cases
      this problem is avoided.

    

    
If we update the module from ietf-routing to ietf-routing-2 ? Do
      we keep the prefix?  In one sense it should be kept as it is the
      same module "logically"; we also might have stored data including
      the prefix (identityrefs, instance-identifiers). On the other hand
      having multiple modules with the same prefix is a problem. The
      only good solution is to allow incompatible updates in some cases.

    
CH 1) 

    

    
You write

      "The YANG data modeling language [RFC7950] specifies strict rules
      for updating..." 

      and again

      "When the same YANG module name is kept, the new YANG module 
      revision must always be updated in a backward-compatible way."

    

    
I strongly disagree. While we have strict rules about even small
      modifications to existing schema, but you are allowed to
      deprecate/obsolete big parts of the model, thereby possibly
      deleting complete subtrees from the schema. That is anything but
      strict backward compatibility.

      I find this aspect of YANG inconsistent to the level that it would
      need an errata. 

    

    
So practically the current rules allow backward incompatible
      changes that can only be detected by a line by line comparison of
      the yang modules. In a system with semantic versioning, you could
      determine backward compatibility just by reading the version
      numbers.

    
CH 2.3) 

      As we need to create a new Yang Module (YAM) even for the smallest
      incompatible modification, this increases the number of modules.

    

    
CH 2.5)  We already have vendor modules depending on ietf-routing

    
CH3.1) 

    

    
I propose that the semantic version should be a mandatory
      substatement of the YANG revision statement. It should be updated
      every time, and it would be good to see the older semantic
      versions as well. 

    

    
I would propose to have 3 separate statements for x,y,z. I don't
      like structured strings. It would be much easier to compare simple
      integers.

    
I can if needed provide some more detailed rules for x,y,z e.g.
      if x is stepped y and z MUST be set to 0.

    
IMHO YANG package definition should be a separate issue, left out
      of this document. Andy has already provided some very good ideas
      about this topic.

    
I also think the current definition of deprecated and obsolete in
      YANG 1.1 is near useless, as all it says that both deprecated and
      obsolete items may or may not be there. We need something better. 
      

    

    
regards Balazs

    

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


  



From nobody Tue Nov 14 13:23: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 C9C761293DF for ; Tue, 14 Nov 2017 13:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8msKXrotH2FL for ; Tue, 14 Nov 2017 13:23:42 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7B4128799 for ; Tue, 14 Nov 2017 13:23:41 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6329421; Tue, 14 Nov 2017 22:23:39 +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 2b33CLT_bNlP; Tue, 14 Nov 2017 22:23: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, 14 Nov 2017 22:23:39 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D2302011F; Tue, 14 Nov 2017 22:23:39 +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 F2uHnpvdLqOF; Tue, 14 Nov 2017 22:23:38 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31EC92011E; Tue, 14 Nov 2017 22:23:38 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 2969C4157CB4; Tue, 14 Nov 2017 22:22:10 +0100 (CET)
Date: Tue, 14 Nov 2017 22:22:10 +0100
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Cc: "netmod@ietf.org" 
Message-ID: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" 
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 21:23:45 -0000

On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
>    Whenever a client OSS implements some higher level logic for a network
>    function, something that can not be implemented in a purely model driven
>    way, it is always dependent on a specific version of the Yang Module
>    (YAM). If the client finds that the module has been updated on the network
>    node, it has to decide if it tries to handle it as it did the previous
>    version of the model or if it just stops to avoid problems. To make this
>    decision the client needs to know if the module was updated in a backward
>    compatible way or not. This is not addressed with the current versioning.

The current rules aim at guaranteeing that definitions (with status
current) remain backwards compatible. Do you have an example what the
current rules fail to achieve this? Definitions with status deprecated
or obsolete may not be present. But if they are present, they have the
same semantics. This is the promise made to a client. (Note also that
objects may be absent for reasons document in deviations or simply not
accessible due to access control.)

>    While having PYANG based checks for backward compatibility is a very good
>    idea, a  comparison based check will never be a complete check. It is
>    quite possible to change just the behavior of an rpc/action/etc.  without
>    changing the YANG definition.  This will only show up as a change of the
>    description statement that can not be analyzed by PYANG.

The problem is to decide whether a change can break client
expectations or not. Even 'bug fixes' can cause a client written to
expect the old 'buggy' behaviour to fail. Also tricky are situations
where behaviour was not clearly enough described and this is 'fixed'
in a module update.

Semantic versioning assumes that one always can clearly distinguish
between incompatible updates and compatible updates. This may not be
so clearly cut in practice, see above. (But then, we have the same
judgement call at the end with today's update rules.)

>    When upgrading a network node we might introduce non-backward compatible
>    (NBC) changes. Today we need to introduce a new module for this. That
>    means during the upgrade process the node must convert stored
>    configuration instance data from ietf-routing to ietf-routing-2 format.
>    Instead of solving this data transformation/transfer problem just for a
>    few NBC data nodes, we will have to do it for the full model. This is
>    complicated. In many cases the transformation of a few NBC leafs can be
>    handled by good defaults or with a small script. Transferring the full
>    data set is more complicated. If we allow NBC updates in some cases this
>    problem is avoided.

In XML land, this is mostly a change of the namespace (not of the
prefix) if one keeps the same structure, no? In JSON land, the change
of the module name more directly becomes visible in instance data; but
this is all encoding details.

>    If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
>    the prefix?

I guess you mean the namespace, not the prefix. You can use any prefix
you like.

>    In one sense it should be kept as it is the same module
>    "logically"; we also might have stored data including the prefix
>    (identityrefs, instance-identifiers). On the other hand having multiple
>    modules with the same prefix is a problem. The only good solution is to
>    allow incompatible updates in some cases.

If we move towards allowing incompabile updates, then we need to have
a mechanism to tell which versions of modules can work together and
which combinations are affected by an incompatible update. We probably
need to require strict import by revision or at least 'import by
compatible revision' (whatever this means at the end).

>    CH 1)
> 
>    You write
>    "The YANG data modeling language [RFC7950] specifies strict rules for
>    updating..."
>    and again
>    "When the same YANG module name is kept, the new YANG module  revision
>    must always be updated in a backward-compatible way."
> 
>    I strongly disagree. While we have strict rules about even small
>    modifications to existing schema, but you are allowed to
>    deprecate/obsolete big parts of the model, thereby possibly deleting
>    complete subtrees from the schema. That is anything but strict backward
>    compatibility.
>    I find this aspect of YANG inconsistent to the level that it would need an
>    errata.

Marking something deprecated / obsolete means you can not be sure this
is implemented. But then, even definitions with status current may not
be implemented (see deviations) or they may not be accessible to a
client due to access control. However, if implemented and accessible,
the guarantee today is that the semantics stay the same and don't
change unexpectedly.

>    So practically the current rules allow backward incompatible changes that
>    can only be detected by a line by line comparison of the yang modules. In
>    a system with semantic versioning, you could determine backward
>    compatibility just by reading the version numbers.

I do not see why you need a line by line comparison. With semantic
versioning, you _hope_ the semantic version number is a good enough
indicator. It might also be that your client is only using a subset
that did not really change even though the semantic version number
changed. Or the semantic version number indicates only minor changes
that sill break your client.

>    CH 2.3)
>    As we need to create a new Yang Module (YAM) even for the smallest
>    incompatible modification, this increases the number of modules.

So it seems to boil down to the question whether foo and foo2 is
significantly more expensive than foo { semver 1.x.y } and foo {
semver 2.x.y }. The main argument seems to be that the later keeps
references that involve module names or namespaces unchanged (but
they may or may not mean different things).

>    IMHO YANG package definition should be a separate issue, left out of this
>    document. Andy has already provided some very good ideas about this topic.

I think it is necessary to think about how the semantic version
numbers are used. See my remark above about imports. If we allow
incompatible changes, than this has side effects and I think we are
not done by just adding a semantic version number without going
working throught the implications.

/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 Nov 14 14:04: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 D78E3127599 for ; Tue, 14 Nov 2017 14:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 JmTQ-nUjizFN for ; Tue, 14 Nov 2017 14:04:43 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BE71274D0 for ; Tue, 14 Nov 2017 14:04:42 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id x68so12982lff.0 for ; Tue, 14 Nov 2017 14:04:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=eiI8MG/W5CItSVvh0Su8r/L7WuHKrHoZ7ZwXs4sb20M=; b=Enegr2AD5Bt1ORAH8eWrZSgD4bCn8WyfALIXE4ZroGQolYHSvq34ugV6/kMnfEEriU h2N1a0gl6lGecGBA2NyuK5dSm5SVac/6hnFUrDyh5ODUh3JfJbwtWkIIg8Eip7sMhlLB XSuln/bJT6reCBL/lPnVUBc/gWGuL8vLapOgPhosiUBYMwn4zREjPl1afob9V14KGPtn HSbzeUcfhbRRbCrVv2+Zk1jkL1gFXvzOL+SF/89K92Ujamf19aOzPGW1hitzQWwyTcvm kcNitCkX1p4+bVfslBCqMKKCivO6YdhiHHtU7tKIW3ESTJMP+XFlisDDt2c9UoJWRHlE gKDg==
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=eiI8MG/W5CItSVvh0Su8r/L7WuHKrHoZ7ZwXs4sb20M=; b=ZN7sgWEWfdwCo+T1jWAa7MH7mI6++eWY/s3uUVhB7w4zJ04Hrb9VpwMhk4EadS3Cn5 LoC/8qs4tcxkzQN8Qk2qdshfRYNUDfpjT2TLoCGpwvLqZHjdeuyFDaNrcsEuERMbiDtl VQjjssETD03EVyfw0JOlmch6AXJnp6WJ39nCgPzWzb5Xv+Z6GV9PyIn3mNapevCfUT/p KHViif/ezdpiczkEI6yRyoFdAE+4otoARtjgFwCxlm/9M6tjAVw17n0VREqFXhLoNlXL KhbXMJuLi9b9xHtAJWdsq4Dp4fa+4CWv8sBE+ouDklevhXTnvUI07X8HaKXMFhuqTFOH Mk6w==
X-Gm-Message-State: AJaThX5DOUEMuzjFrfJyFO5ybbLC9vWmSEF8k5jh5vB2VZcyB4uMvGqL 8lmd/PbYb2tg+3GehidsjgmzTNgoKQpI4T5LcXjcHg==
X-Google-Smtp-Source: AGs4zMbJrYVjVAb+fIWIqOsZ3FMvjaF444TGSRj7KHSCXIQ8SRU8MON/li4tN3zF32LQLQh4q2cEnECoPmN2tiZuB3w=
X-Received: by 10.25.142.5 with SMTP id q5mr4226026lfd.19.1510697080617; Tue, 14 Nov 2017 14:04:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Tue, 14 Nov 2017 14:04:39 -0800 (PST)
In-Reply-To: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
From: Andy Bierman 
Date: Tue, 14 Nov 2017 14:04:39 -0800
Message-ID: 
To: Juergen Schoenwaelder ,  Balazs Lengyel , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045f5098da8e1f055df89200"
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 22:04:46 -0000

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

On Tue, Nov 14, 2017 at 1:22 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
> >    Whenever a client OSS implements some higher level logic for a network
> >    function, something that can not be implemented in a purely model
> driven
> >    way, it is always dependent on a specific version of the Yang Module
> >    (YAM). If the client finds that the module has been updated on the
> network
> >    node, it has to decide if it tries to handle it as it did the previous
> >    version of the model or if it just stops to avoid problems. To make
> this
> >    decision the client needs to know if the module was updated in a
> backward
> >    compatible way or not. This is not addressed with the current
> versioning.
>
> The current rules aim at guaranteeing that definitions (with status
> current) remain backwards compatible. Do you have an example what the
> current rules fail to achieve this? Definitions with status deprecated
> or obsolete may not be present. But if they are present, they have the
> same semantics. This is the promise made to a client. (Note also that
> objects may be absent for reasons document in deviations or simply not
> accessible due to access control.)
>

There are lots of independent variables here.
The use of augment vs. new-module-version has a big impact on this problem.
But the IETF prefers to work on a module for several years, rather
than produce a base model that is extended by many other modules.
This approach has not produced a stable base of modules.
I think the idea is to worry less about stability and just iterate faster,
which might produce better results in the end.




>
> >    While having PYANG based checks for backward compatibility is a very
> good
> >    idea, a  comparison based check will never be a complete check. It is
> >    quite possible to change just the behavior of an rpc/action/etc.
> without
> >    changing the YANG definition.  This will only show up as a change of
> the
> >    description statement that can not be analyzed by PYANG.
>
> The problem is to decide whether a change can break client
> expectations or not. Even 'bug fixes' can cause a client written to
> expect the old 'buggy' behaviour to fail. Also tricky are situations
> where behaviour was not clearly enough described and this is 'fixed'
> in a module update.
>
> Semantic versioning assumes that one always can clearly distinguish
> between incompatible updates and compatible updates. This may not be
> so clearly cut in practice, see above. (But then, we have the same
> judgement call at the end with today's update rules.)
>


In "real" code, we never remove or change an API. Never.
This is what Balazs is talking about.  You make new APIs,
perhaps using wrapper functions, but you do not break code
that depends on the existing APIs.

I would rather have code break immediately and very visibly,
rather than having it appear compatible but in fact changed
behavior silently breaks functionality.  These bugs are harder to find.

I guess if the compiler keep track of the major version for every import
somehow,
then it could issue a warning that "major version changed in import"
if a module diff is done.




>
> >    When upgrading a network node we might introduce non-backward
> compatible
> >    (NBC) changes. Today we need to introduce a new module for this. That
> >    means during the upgrade process the node must convert stored
> >    configuration instance data from ietf-routing to ietf-routing-2
> format.
> >    Instead of solving this data transformation/transfer problem just for
> a
> >    few NBC data nodes, we will have to do it for the full model. This is
> >    complicated. In many cases the transformation of a few NBC leafs can
> be
> >    handled by good defaults or with a small script. Transferring the full
> >    data set is more complicated. If we allow NBC updates in some cases
> this
> >    problem is avoided.
>
> In XML land, this is mostly a change of the namespace (not of the
> prefix) if one keeps the same structure, no? In JSON land, the change
> of the module name more directly becomes visible in instance data; but
> this is all encoding details.
>
> >    If we update the module from ietf-routing to ietf-routing-2 ? Do we
> keep
> >    the prefix?
>
> I guess you mean the namespace, not the prefix. You can use any prefix
> you like.
>
> >    In one sense it should be kept as it is the same module
> >    "logically"; we also might have stored data including the prefix
> >    (identityrefs, instance-identifiers). On the other hand having
> multiple
> >    modules with the same prefix is a problem. The only good solution is
> to
> >    allow incompatible updates in some cases.
>
> If we move towards allowing incompabile updates, then we need to have
> a mechanism to tell which versions of modules can work together and
> which combinations are affected by an incompatible update. We probably
> need to require strict import by revision or at least 'import by
> compatible revision' (whatever this means at the end).
>
> >    CH 1)
> >
> >    You write
> >    "The YANG data modeling language [RFC7950] specifies strict rules for
> >    updating..."
> >    and again
> >    "When the same YANG module name is kept, the new YANG module  revision
> >    must always be updated in a backward-compatible way."
> >
> >    I strongly disagree. While we have strict rules about even small
> >    modifications to existing schema, but you are allowed to
> >    deprecate/obsolete big parts of the model, thereby possibly deleting
> >    complete subtrees from the schema. That is anything but strict
> backward
> >    compatibility.
> >    I find this aspect of YANG inconsistent to the level that it would
> need an
> >    errata.
>
> Marking something deprecated / obsolete means you can not be sure this
> is implemented. But then, even definitions with status current may not
> be implemented (see deviations) or they may not be accessible to a
> client due to access control. However, if implemented and accessible,
> the guarantee today is that the semantics stay the same and don't
> change unexpectedly.
>
> >    So practically the current rules allow backward incompatible changes
> that
> >    can only be detected by a line by line comparison of the yang
> modules. In
> >    a system with semantic versioning, you could determine backward
> >    compatibility just by reading the version numbers.
>
> I do not see why you need a line by line comparison. With semantic
> versioning, you _hope_ the semantic version number is a good enough
> indicator. It might also be that your client is only using a subset
> that did not really change even though the semantic version number
> changed. Or the semantic version number indicates only minor changes
> that sill break your client.
>
> >    CH 2.3)
> >    As we need to create a new Yang Module (YAM) even for the smallest
> >    incompatible modification, this increases the number of modules.
>
> So it seems to boil down to the question whether foo and foo2 is
> significantly more expensive than foo { semver 1.x.y } and foo {
> semver 2.x.y }. The main argument seems to be that the later keeps
> references that involve module names or namespaces unchanged (but
> they may or may not mean different things).
>
> >    IMHO YANG package definition should be a separate issue, left out of
> this
> >    document. Andy has already provided some very good ideas about this
> topic.
>
> I think it is necessary to think about how the semantic version
> numbers are used. See my remark above about imports. If we allow
> incompatible changes, than this has side effects and I think we are
> not done by just adding a semantic version number without going
> working throught the implications.
>


I realized years ago that deprecated and obsolete definitions would create
the need for a compatible revision range (minver .. maxver) for every
import,
and the compatibility matrix would get increasing harder as the module
count grew

People called "package maintainers" do this work now in Linux-land.
The YANG Packages draft was an attempt to standardize a file format
that package maintainers would write and keep up-to-date.
Real testing and verification (with pyang and other tools) would be done
before a package can be released.  The common import mode would
be "greater-or-equal minver"  If a package maintainer decides the version
of "bar"
breaks module "foo", then an inclusive range is needed instead (minver ..
broken-1).

The current import-by-revision is too fragile and needs to be enhanced.



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

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




On Tue, Nov 14, 2017 at 1:22 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Len=
gyel wrote:

>=C2=A0 =C2=A0 Whenever a client OSS implements some higher level logic =
for a network

>=C2=A0 =C2=A0 function, something that can not be implemented in a pure=
ly model driven

>=C2=A0 =C2=A0 way, it is always dependent on a specific version of the =
Yang Module

>=C2=A0 =C2=A0 (YAM). If the client finds that the module has been updat=
ed on the network

>=C2=A0 =C2=A0 node, it has to decide if it tries to handle it as it did=
 the previous

>=C2=A0 =C2=A0 version of the model or if it just stops to avoid problem=
s. To make this

>=C2=A0 =C2=A0 decision the client needs to know if the module was updat=
ed in a backward

>=C2=A0 =C2=A0 compatible way or not. This is not addressed with the cur=
rent versioning.



The current rules aim at guaranteeing that definitions (with status

current) remain backwards compatible. Do you have an example what the

current rules fail to achieve this? Definitions with status deprecated

or obsolete may not be present. But if they are present, they have the

same semantics. This is the promise made to a client. (Note also that

objects may be absent for reasons document in deviations or simply not

accessible due to access control.)

Ther=
e are lots of independent variables here.
The use of augment vs. =
new-module-version has a big impact on this problem.
But the IETF=
 prefers to work on a module for several years, rather
than produ=
ce a base model that is extended by many other modules.
This appr=
oach has not produced a stable base of modules.
I think the idea =
is to worry less about stability and just iterate faster,
which m=
ight produce better results in the end.


=

=C2=A0



>=C2=A0 =C2=A0 While having PYANG based checks for backward compatibilit=
y is a very good

>=C2=A0 =C2=A0 idea, a=C2=A0 comparison based check will never be a comp=
lete check. It is

>=C2=A0 =C2=A0 quite possible to change just the behavior of an rpc/acti=
on/etc.=C2=A0 without

>=C2=A0 =C2=A0 changing the YANG definition.=C2=A0 This will only show u=
p as a change of the

>=C2=A0 =C2=A0 description statement that can not be analyzed by PYANG.<=
br>


The problem is to decide whether a change can break client

expectations or not. Even 'bug fixes' can cause a client written to=


expect the old 'buggy' behaviour to fail. Also tricky are situation=
s

where behaviour was not clearly enough described and this is 'fixed'=
;

in a module update.



Semantic versioning assumes that one always can clearly distinguish

between incompatible updates and compatible updates. This may not be

so clearly cut in practice, see above. (But then, we have the same

judgement call at the end with today's update rules.)
<=
div>

In "real" code, we never remove=
 or change an API. Never.
This is what Balazs is talking about.=
=C2=A0 You make new APIs,
perhaps using wrapper functions, but yo=
u do not break code
that depends on the existing APIs.
=

I would rather have code break immediately and very visibly,=

rather than having it appear compatible but in fact changed
behavior silently breaks functionality.=C2=A0 These bugs are harder t=
o find.

I guess if the compiler keep track of the =
major version for every import somehow,
then it could issue a war=
ning that "major version changed in import"
if a module=
 diff is done.=C2=A0


=C2=A0



>=C2=A0 =C2=A0 When upgrading a network node we might introduce non-back=
ward compatible

>=C2=A0 =C2=A0 (NBC) changes. Today we need to introduce a new module fo=
r this. That

>=C2=A0 =C2=A0 means during the upgrade process the node must convert st=
ored

>=C2=A0 =C2=A0 configuration instance data from ietf-routing to ietf-rou=
ting-2 format.

>=C2=A0 =C2=A0 Instead of solving this data transformation/transfer prob=
lem just for a

>=C2=A0 =C2=A0 few NBC data nodes, we will have to do it for the full mo=
del. This is

>=C2=A0 =C2=A0 complicated. In many cases the transformation of a few NB=
C leafs can be

>=C2=A0 =C2=A0 handled by good defaults or with a small script. Transfer=
ring the full

>=C2=A0 =C2=A0 data set is more complicated. If we allow NBC updates in =
some cases this

>=C2=A0 =C2=A0 problem is avoided.



In XML land, this is mostly a change of the namespace (not of the

prefix) if one keeps the same structure, no? In JSON land, the change

of the module name more directly becomes visible in instance data; but

this is all encoding details.



>=C2=A0 =C2=A0 If we update the module from ietf-routing to ietf-routing=
-2 ? Do we keep

>=C2=A0 =C2=A0 the prefix?



I guess you mean the namespace, not the prefix. You can use any prefix

you like.



>=C2=A0 =C2=A0 In one sense it should be kept as it is the same module
>=C2=A0 =C2=A0 "logically"; we also might have stored data inc=
luding the prefix

>=C2=A0 =C2=A0 (identityrefs, instance-identifiers). On the other hand h=
aving multiple

>=C2=A0 =C2=A0 modules with the same prefix is a problem. The only good =
solution is to

>=C2=A0 =C2=A0 allow incompatible updates in some cases.



If we move towards allowing incompabile updates, then we need to have

a mechanism to tell which versions of modules can work together and

which combinations are affected by an incompatible update. We probably

need to require strict import by revision or at least 'import by

compatible revision' (whatever this means at the end).



>=C2=A0 =C2=A0 CH 1)

>

>=C2=A0 =C2=A0 You write

>=C2=A0 =C2=A0 "The YANG data modeling language [RFC7950] specifies=
 strict rules for

>=C2=A0 =C2=A0 updating..."

>=C2=A0 =C2=A0 and again

>=C2=A0 =C2=A0 "When the same YANG module name is kept, the new YAN=
G module=C2=A0 revision

>=C2=A0 =C2=A0 must always be updated in a backward-compatible way."=
;

>

>=C2=A0 =C2=A0 I strongly disagree. While we have strict rules about eve=
n small

>=C2=A0 =C2=A0 modifications to existing schema, but you are allowed to<=
br>
>=C2=A0 =C2=A0 deprecate/obsolete big parts of the model, thereby possib=
ly deleting

>=C2=A0 =C2=A0 complete subtrees from the schema. That is anything but s=
trict backward

>=C2=A0 =C2=A0 compatibility.

>=C2=A0 =C2=A0 I find this aspect of YANG inconsistent to the level that=
 it would need an

>=C2=A0 =C2=A0 errata.



Marking something deprecated / obsolete means you can not be sure this

is implemented. But then, even definitions with status current may not

be implemented (see deviations) or they may not be accessible to a

client due to access control. However, if implemented and accessible,

the guarantee today is that the semantics stay the same and don't

change unexpectedly.



>=C2=A0 =C2=A0 So practically the current rules allow backward incompati=
ble changes that

>=C2=A0 =C2=A0 can only be detected by a line by line comparison of the =
yang modules. In

>=C2=A0 =C2=A0 a system with semantic versioning, you could determine ba=
ckward

>=C2=A0 =C2=A0 compatibility just by reading the version numbers.



I do not see why you need a line by line comparison. With semantic

versioning, you _hope_ the semantic version number is a good enough

indicator. It might also be that your client is only using a subset

that did not really change even though the semantic version number

changed. Or the semantic version number indicates only minor changes

that sill break your client.



>=C2=A0 =C2=A0 CH 2.3)

>=C2=A0 =C2=A0 As we need to create a new Yang Module (YAM) even for the=
 smallest

>=C2=A0 =C2=A0 incompatible modification, this increases the number of m=
odules.



So it seems to boil down to the question whether foo and foo2 is

significantly more expensive than foo { semver 1.x.y } and foo {

semver 2.x.y }. The main argument seems to be that the later keeps

references that involve module names or namespaces unchanged (but

they may or may not mean different things).



>=C2=A0 =C2=A0 IMHO YANG package definition should be a separate issue, =
left out of this

>=C2=A0 =C2=A0 document. Andy has already provided some very good ideas =
about this topic.



I think it is necessary to think about how the semantic version

numbers are used. See my remark above about imports. If we allow

incompatible changes, than this has side effects and I think we are

not done by just adding a semantic version number without going

working throught the implications.


=

I realized years ago that deprecated and obsolete definitions wo=
uld create
the need for a compatible revision range (minver .. ma=
xver) for every import,
and the compatibility matrix would get in=
creasing harder as the module count grew=C2=A0

Peo=
ple called "package maintainers" do this work now in Linux-land.<=
/div>
The YANG Packages draft was an attempt to standardize a file form=
at
that package maintainers would write and keep up-to-date.
Real testing and verification (with pyang and other tools) would be d=
one
before a package can be released.=C2=A0 The common import mod=
e would
be "greater-or-equal minver" =C2=A0If a package=
 maintainer decides the version of "bar"
breaks module =
"foo", then an inclusive range is needed instead (minver .. broke=
n-1).

The current import-by-revision is too fragil=
e and needs to be enhanced.





/js



Andy

=C2=A0

--

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

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

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



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--f403045f5098da8e1f055df89200--


From nobody Tue Nov 14 18:33: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 66C0E120724 for ; Tue, 14 Nov 2017 18:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COM2sWDRGm7m for ; Tue, 14 Nov 2017 18:33:41 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B58129477 for ; Tue, 14 Nov 2017 18:33:40 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id m1so8550285lfj.9 for ; Tue, 14 Nov 2017 18:33:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=h+TtYd4zV3n4+j1cCNaLfhjukJ99qjwdInZXjiMMdso=; b=kfd0lWB2qncxarwPfZLDCTWeNf4YqLh04PSmN5EwsWV2shKDleXvjZO3rN8PMz6YPo 7ddL1Opc7G6gDoU2Zsao4/kmpA/yx2dNfG9yHPWfkuqwygujvsJAU/JT2Gc+1mnT77MW M6hYIvpYDiMNVN6HwAHmkIEC0pUT590z0oso+JI1+1V4WNrdbABEt2B98Rnbp2qU1R73 ADK52y6GWxkUawSpwTWn4ZG7AFLhnId/X6LxU55YB+Et9330rSFkaI0BXGUISlQ77tJa 56ksG7rv/tIsVUE4V3YvCBQP9w03nqUZwluGtqLt9vkXN4glNv7Mye1CWsYKDAWNV/BQ d6HQ==
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=h+TtYd4zV3n4+j1cCNaLfhjukJ99qjwdInZXjiMMdso=; b=fk2J7/h71QUHgttfjBggx/Zjg1RO4ks+uxl7tNNi0oQqy1rUAVnwW21w3+0etRxI6O CJVoNgKj34WBg1s261ONkuZVJKdfbKGklT9WVeV1UMAit1L5f8jwTOe8/xcIekMMcY+t KWoveirLediRQX51cgEZEwrbiOTM2JJ7F07EDwMtjiNgWmNJaphaahfO5bXabFbWEzg7 +EYAhHDBRUE4IkyYBu/cqd+URRTiIAJofErybm8C+ap3MMnrcKi0SsrbeJVfzDyWYaKS Ye1/TT1DjS0EXFCWwkHjVfkir1mHHgaIxaN/SDJ6VvkbfeTbQX/FOQQcNyCUity8DP0y 0Vbw==
X-Gm-Message-State: AJaThX6ydhKOoSV3HBSPojPhwRyfDouJ0KQawMHPpFD4Q0dKennFOiDG OtATr76S2MxxUDjy2X9UUVYOf8CYc3ALkzxn9lA8EGHk
X-Google-Smtp-Source: AGs4zMZRu4mcMJhtXuVUDzkHEMyrv8bSg/qo8GG7fShhmYo0TeZSj7eI65p87QcgWbuCYd/0DGDkVnczzu+YoQsVF4k=
X-Received: by 10.46.57.10 with SMTP id g10mr10877lja.77.1510713218749; Tue, 14 Nov 2017 18:33:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Tue, 14 Nov 2017 18:33:38 -0800 (PST)
From: Andy Bierman 
Date: Tue, 14 Nov 2017 18:33:38 -0800
Message-ID: 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="089e082f5ce4c2f2ec055dfc54ed"
Archived-At: 
Subject: [netmod] ietf-yang-library edit
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 02:33:42 -0000

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

Hi,

The ietf-yang-library module relies on "yang-identifier", which was added
to the 2nd
version of the ietf-yang-types. It does not compile unless that version is
used.


OLD:

    import ietf-yang-types {
        prefix yang;
    }


NEW:

    import ietf-yang-types {
        prefix yang;
        revision-date "2013-07-15";
        reference "RFC 6991: Common YANG Data Types";
    }


There are other modules such as ietf-ip that rely on RFC 6991 additions
and the import-stmt (in every case) should be changed to specify the
required revision-date.


Andy

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


Hi,

The ietf-yang-library module relies=
 on "yang-identifier", which was added to the 2nd
versi=
on of the ietf-yang-types. It does not compile unless that version is used.=



OLD:

=C2=A0 =C2=A0 import ietf-yang-types {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 prefix yang;
=C2=A0 =C2=A0 }

<=
br>
NEW:

=C2=A0 =C2=A0 import ietf-=
yang-types {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix yang;
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 revision-date "2013-07-15";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reference "RFC 6991: Common YANG Data Typ=
es";
=C2=A0 =C2=A0 }


There are other modules such as ietf-ip that rely on RFC 6991 additi=
ons
and the import-stmt (in every case) should be changed to spec=
ify the
required revision-date.


Andy




--089e082f5ce4c2f2ec055dfc54ed--


From nobody Tue Nov 14 19:33: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 765DF1275AB for ; Tue, 14 Nov 2017 19:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.11
X-Spam-Level: 
X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 TO60ChTl34ev for ; Tue, 14 Nov 2017 19:33:47 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B299E126CE8 for ; Tue, 14 Nov 2017 19:33:46 -0800 (PST)
X-AuditID: c1b4fb2d-f23ff70000001e3d-5f-5a0bb5964990
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7B.5B.07741.695BB0A5; Wed, 15 Nov 2017 04:33:43 +0100 (CET)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 04:33:41 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aV0Xakxvqi/bnL6f/kmlFrCxdqO9DF4IkP9mRmQcDmM=; b=KUibqoPgd2eaP4ND/lJrqXwYCnjQ9PsB2XiPPrLGb2pL1+99sk+JpTujNxU0+Nbg0FFhr1i7mqRpeRMRV+tu6oQY1O1PNwQKpzCRZ88b+MUDUGiDImRA4jrp0MI8YGrQaivurHWBxCGA6YT5DG7GVAUhQg0x/7MAvsnopAfyfN0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [IPv6:2001:67c:370:128:c03b:3d1c:2e9e:f59c] (2001:67c:370:128:c03b:3d1c:2e9e:f59c) by VI1PR07MB3438.eurprd07.prod.outlook.com (2603:10a6:802:24::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Wed, 15 Nov 2017 03:33:40 +0000
To: "netmod@ietf.org" 
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
From: Balazs Lengyel 
Message-ID: <66e88c5b-41fc-7607-e1a9-ebe76eded836@ericsson.com>
Date: Wed, 15 Nov 2017 11:33:18 +0800
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: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [2001:67c:370:128:c03b:3d1c:2e9e:f59c]
X-ClientProxiedBy: SG2PR01CA0107.apcprd01.prod.exchangelabs.com (2603:1096:3:15::33) To VI1PR07MB3438.eurprd07.prod.outlook.com (2603:10a6:802:24::12)
X-MS-Office365-Filtering-Correlation-Id: 48ff4466-92d8-487c-e7f4-08d52bd9aa83
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:VI1PR07MB3438; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 3:YoKDidJhWFNJI15NWi276GIeyDRj94vUs1/pw3RJTrWaS/lobLL6Pv4HPMfA2eUMbXPQ6qNRD5SdeYoC6HUPqoNB6YSkz+p9kgmn90d1V6HXoEIgUjIvQuo1NDmrRHgzsu0Oab7k40dwelT5o3ijwpPxkR3OsQpiIvoN/hoNhbHxxN3ZVtNi4thAUHE4RgqTRqN4YGIgbTgZY+0bP57euo3bqu0pWlkj1isW3tdoxk4+TOcAwWowvTpUbpi25L8v; 25:T3jSv83HMVZSDMujXBzo+dxCmTSLc2Z/lfOfs3CZyB3k83ESY2RjRQJzNPj1NraVzKqsp3CoBmO1oL0hAJ+3bs531K6rQAmPTU2Z8u9LE/ENISCremkIfWXBDyLUKVvXyfRjXsRIpo+M23eg6wxmB35+/ZcV2mfKLDPtisMu38wD9ztJYzdh7Z085gZrnxohX1jhv/0OPdKTBTTfW3py4DvzWCj3kEzPATtvKymETsws5vqO4zkXjvlBF+R0cGqx8n7MdfIGuTZAYVeq8wiKqUTVfoXItWk+0FNMWVS45wHFvsh+btcbK4xyOM9OoHSos0vu0eL7Ozpr5E3y0PCCyQ==; 31:TLLbkIahyi3LPYT7OyGp7JG7yN+hRtMqWI15bE3vIjj9DECzSrjTzSQvWDuucaPr+9ifL5ylVeB9JXElvAZm+NnOX6PqNEUhMKuechktIIk+rpQyBnRFUmNdueShiRhqwFHeiuKgTfnMMN4JRQtQvbTaAcs3DXGcQmovn2p1QCyOyz0OfKc/wupBzPvKU3VNB1kqF6dNWriDX0/UolIYClz/dByM3zVqwb+1cuu9aZQ=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VI1PR07MB3438:
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 20:werKf9XtA2uSbDtvPz2HnJpRZLd7dZ7FfKIKTAIyoo+NlrKrynSXykUJ9bq0bI9tvAWAeGuMRNpNzu1BYFRPFra+EiYmfzNqfoztUHOqeXYcYzIu7WRJOaUnBQeFpIvhkxbVyd4uebAkJMB2abN6WkbQdgDzhqrYno7x0BA7vMQi87rqVEkYHulROQqSs1R5NrotrD2sHlWN/dq+/6/ivDxlo7gCHy+FfLznrgXcKatNPjqjtG/zAcNn3bOelpV7TAPZUC0VWcSVHahgmxOG2BSX3UI+Is1dS3c3C0zuj2AWDmWU/wmNh8Cs6UAEBadSA7zu8jCTcRwaQHItSo31f/mjGiF5e4VuhWQUdvjLQ0tKrIe7obKYwp1aa0N7sh8DdcAfXvfpqvd77AfXV7oK/KiXlkpfiuT51j19zmbtnK56RU+Ds2FJJlWui4cv5y7huRkEPeLxijdMImYsbNB517W4XcRi0WcEpJ0Std2Onh57kBeC1mg3/h2ZqOl0TUq9; 4:Yw+bgJ59XbFhGXa4zdbriBB7c3XtAn5gAJtk7xKagZu/n3PJ5umfPJhsDE4t6obXT8hTEs4pUpBQV4zu3KwHPailY1V3uERLkwsCanpfaJ1vYOOQvLvkF2pG6H0pkAzKeyLGFez4zhClBc/VmElJq7hgAUiEtfv8OH6VUQvqFy2Pc8bTa/ipBWNgfkQ3Dyzsx5OSg11Lviv73v67YiSzuX+86/aZJKrsdSJ2834xlurPwpzTou+nTf8PO5uqQy9rR3b0lrBce+V+cV1tIti56HJsnRiVMS7xmn9Klq5YWg8h4uGgo/OhK02j11rDXArm
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(3231022)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3438; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3438; 
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(45074003)(24454002)(189002)(377424004)(252514010)(199003)(2501003)(23676003)(2906002)(101416001)(67846002)(86362001)(1730700003)(83506002)(105586002)(316002)(81166006)(305945005)(81156014)(58126008)(6116002)(76176999)(53936002)(230783001)(50986999)(6246003)(36756003)(54356999)(50466002)(5640700003)(1706002)(4001150100001)(15650500001)(189998001)(7736002)(31696002)(97736004)(8676002)(2870700001)(25786009)(478600001)(33646002)(65956001)(31686004)(53546010)(47776003)(65806001)(68736007)(2351001)(64126003)(5660300001)(8936002)(65826007)(6486002)(2950100002)(6916009)(6666003)(229853002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3438; H:[IPv6:2001:67c:370:128:c03b:3d1c:2e9e:f59c]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIzNDM4OzIzOmdPYjZkLzBQcWo4bDBNcXhVamg1V2RUck8z?= =?utf-8?B?YjlmZEtOWHRwS1ZMUG1WZXM0Ny9rVzRxc2IyS3pwZXRna1ZrYzRSeFNySXAz?= =?utf-8?B?ZTdEa2g2OVNIR2YyR1c3akZVOFB0NUhMVFpXamoyeEcrbFpsU0c2ZktxYVJE?= =?utf-8?B?VGtZdW51bUMrNDFjVk1tSHZDNnJsdGRmZkphYnpobWVkZEdjL3pka3Vwb2Ra?= =?utf-8?B?aE5TaWhtZ0tHZW5YRnpLTUZFZTJLYzhZdlBJd0FoTjNVdnJ6dS9oL2U4QUg1?= =?utf-8?B?SWFnU2xhREhiSDFxeC94WFkzUUVWYVV2U1RTOUowT3FnQzNqNkhJYjhhWkcv?= =?utf-8?B?VDlmNVV0L2RUVU0vTWkzSy9valEyQi91SSt2NGlhV1hHUlRGeWJISkcvY0Zr?= =?utf-8?B?ZnRmM1lPM1p5UDFZT2lzVk9tV3k0OHd4YlUveHlyUjNFdEFPeVhmamtTTjIz?= =?utf-8?B?Um9FbC9NSi9aN0EveCsycVJ0bm9DYW05bk42UG5YS3I2RVlFeXYyWmk2V3Nw?= =?utf-8?B?WHpFL0M5c2tmeiswcDJLdkx2YlJ5V3lkZXU1WVRVQUpySExJbm5iSTdDRUt3?= =?utf-8?B?WnVZbnlyck1uZjlRV21JallYUndibndsOVBoeFVCRGNjaWJxMDN5eHRyZWUz?= =?utf-8?B?c2kzamQrMWVnYTloY1prRWc1MTlMTG0zdE9obTAyYWlkRHBSTnlISGlldjFq?= =?utf-8?B?QTRPbDlUOGNwblIzcXpFTXlMU2t2K0xjeGZ6TkkxQWYxUzhaLzZ0VDFvcDJK?= =?utf-8?B?Z3B2MkpLTUdDT2x5RTFEc0dNcVFqNWlENkEwUDFwWHhLU3hBRzJaVzFkQjdC?= =?utf-8?B?bHZoRTB4cDVHRjRZSG1YNlV4MFZQU0J0cFdvVzhtQVFsa0plLzFZaTZQMHRN?= =?utf-8?B?ektSbVd5bGM1d0QrYU03OVIrYWJQYVN6cVk0a1ZDMUhzTEV5emx6VUdRZXFZ?= =?utf-8?B?cU5DNWNJRm9zN1JPQlg3U1JuRlZ2djcyM09pN00wYjQ4MHJPK1pWWUczeXR2?= =?utf-8?B?anFNcTJ3VzF3SG9mL2RJZy81UXlkN0tTRHlGa2VKSzhjNE1hdFVUMmN3VFcw?= =?utf-8?B?aVBTRFFhSm9aa3ZnNnJzSzZoazl1c1VYb05KRS8xeE92QzlmZVZmSkJJNlZt?= =?utf-8?B?TERqRWsrNE03U0ZHekc2YWdqRHZTc1NHYVdyd016VnZUQVh6ZFRWeHNpSFJD?= =?utf-8?B?bTFNakRZcytRZGt5Mi9VbXRYUm04T29QaWFMYXBJb1MxbDFDZUJYdmVHR0hP?= =?utf-8?B?U1hKNm04dVpqMytSMzlrUTY3b0t2N1FFcWx6S3p2MXJSWVJxamQ3Vk02cFg5?= =?utf-8?B?YzNaTE5vd2pVTmNEdWR4MVJNRkJSTXVsc3UxNFF5c2xEN3ZnRndzanZsa1Vp?= =?utf-8?B?a3pKVFNUV0lGSUpLcTEvUGtBZmtkWmtxSTkyMHpFUk1McWZtVS9KZVlTcDYz?= =?utf-8?B?SjQyMDU5dmdpMjRxSjQ5dCthZXBTY3h1NUMxcnA5bnFiT05pTHJwRDBoT2Ez?= =?utf-8?B?MXdNL2VDZmYvVEhzT3IvTkFnWGJLM3pwckQybGNYNjFZUzVYMFBlSndLcEtl?= =?utf-8?B?Tk1aSkVsUUhmZkdsWlY2c3hHMk5WSW9PZ1RWNmFtYkxLZnoxcHhmRmZXT1R4?= =?utf-8?B?dlpKbEF5ZVpMWVZKVnlFdlFkMDJwUUI3QjZzNndqckJSSXVmeHhDNG5uWGtR?= =?utf-8?B?MmVTL0lUdWgwTDVmOXVQUmgrWHpnaVUrQTQwcGFmYVUzZUs1WVZJUk81OVhO?= =?utf-8?B?OGJETkxnMzlXNFZ5VEg0UFNlSDdWYUM0d3czKytoL0Q2NGtBcXljOEp4S0kw?= =?utf-8?B?U3VMOGVsYy9tdktjM3Y5UVVsZHZvMkNkd240cEpFZDhpR2c5MHZLYVV4QVlz?= =?utf-8?B?QitBMTJyV21TTXhobzZFS1o4NXhqY0xKYzFIYUxuNlYrUEl3OE02N2tPaUFN?= =?utf-8?B?QStDbUQyMjNQQ09YeHJIUUx0bnk3NERINVh3TUV2dmwzN01lSURtbUUrK0Z6?= =?utf-8?B?YW9WL1F1aGRBSDJkTVdZZjJsVXd4a3dndERLdz09?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 6:rcpu//nPOjuiZbJbcBrMQZ+TLXf+jGHaA77hIbxyiGNCcTt//AsDMaqMCsPWycSixuelWXDB8ZVP/cxMBlKSnQU+IW2p/qRVwnpno5X2k1p6p6gK+0wG3BJQ5QeRCVkCnRJj2Ni0puKHp+2xcHMt6nzydEN5awdsmreSwq44pwTyaVJgmQfaspp152HLhnA4M9fNltsynbg0I29WAY1RsdY3KFbFg48am6xFLTz7znLec2oiL1YRLGO57q0R0o6fyvnYmO4i7gpz5q/svJU4zBxuhWvT50+W5yUGyWdWCHjjjuHFFqPllxpSS8w6gKjCiuWGQFh8X21DsbWVOIX/71EGeZDtUNuU0kq7KV1m9/U=; 5:XS5dgGuAvnQtFN2TvuQDEKg1C1RA0jetyPvgzc83xwcP0bzGN1SgruGv2xt3UiHiYv5gPphhNyXwD4NDrPUq9hu0vFC3aIZBu9bUrYf2X5QBtXuce04bGRnvmVVh3DZLmTM7o3fLlqTcKAaKbsXc/qw/GfE9XHE/iatO5OA2reU=; 24:6tZ6/OEO2NGx6AnKvE6+OCwYJZiOwIMeOpnu1yUjwtiqnDNqCDxgx6p5jER5iyQ6OAwFAce7nv+9LtUKIDNjQWbWq4MsFXmuDpko0LuLKV8=; 7:ijkQXZ9CzOmd624KHawF911HJIU3p2eviD3iU7DPTgxU8rhsp46cL8jfOxcuCpKTQlzscxzpDPPV3VxD68xRkhs7WHpNku8ke6vYkcLUdoSLyqrDEHCVJ2kZg9Vq68Dxrq5uKdGdtquPQXBdfXr7czZ/Yb3RdGWwYaZy1XFOmDM7s1vVlwL+uBauVlCD2aAludT1+ORHnbGxf9pnpRHImFMv3Zb5qYnfjSD5Uu3GC3wt26OnQ37yIVV5FWtRWZpZ
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 03:33:40.5680 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 48ff4466-92d8-487c-e7f4-08d52bd9aa83
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3438
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUyM2K7ge70rdxRBh8PM1nMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI4rm9gLJvhVrJzRztTAeNq2i5GTQ0LAROJb7y3mLkYuDiGB w4wSPW/Xs0M4Jxglbj9bxgZSxSLQyyxx9bUMiM0oECexc81CVoiiPUwS/5quMYEkhAU8JfZ1 /mEFsUUE1CVm7lwP1iwkUCCx5tBhRhCbTcBIYmr/eRYQm1fAXmLTx39AvRxAC1QlTjxXAQmL CsRITHxwkRGiRFDi5MwnYOWcAtYSDbv+s4PYzAIWEjPnn2eEsOUlmrfOZoawxSVuPZkPNlIC qOZAow/ImRICsxglNty7wA5xjobEwwt/WSG+95X4/nQbE0TRTEaJJWcXsUM4DewS79vfsUFU yUocPTuHBcLWkjg/9xojhP2DTeLYK04IO1vi+ZLzUFOtJF7/+s4IMegKq8TH44+YIBIyEidv 7IVq3sMmMWdW3QRG7VlIPp2F5LtZSL6bheS7BYwsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJL NjECU8TBLb91dzCufu14iFGAg1GJh9drAneUEGtiWXFl7iFGCQ5mJRHe5H6gEG9KYmVValF+ fFFpTmrxIUZpDhYlcV4PEaCUQHpiSWp2ampBahFMlomDU6qBcdI+M54N7qULGZ9/PxKvKTLb 2Edg8dzH7+IttHbyaO9jnfLgRgfLt7sX19n5mbk7WswKuvXlycewhA7N5FPuPnZLnY0TdkyI c+gttla/zau7dtmkwmmeZjsX2ebz7Q9I/B6zJP90rM7xegYezVyORfZ1xqeaPnE0fm8/Kf7i uXlE+cxwm5RLSizFGYmGWsxFxYkAOFkTeA0DAAA=
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:33:51 -0000

See bellow!


On 2017-11-15 05:22, Juergen Schoenwaelder wrote:
> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
>>     Whenever a client OSS implements some higher level logic for a network
>>     function, something that can not be implemented in a purely model driven
>>     way, it is always dependent on a specific version of the Yang Module
>>     (YAM). If the client finds that the module has been updated on the network
>>     node, it has to decide if it tries to handle it as it did the previous
>>     version of the model or if it just stops to avoid problems. To make this
>>     decision the client needs to know if the module was updated in a backward
>>     compatible way or not. This is not addressed with the current versioning.
> The current rules aim at guaranteeing that definitions (with status
> current) remain backwards compatible. Do you have an example what the
> current rules fail to achieve this? Definitions with status deprecated
> or obsolete may not be present. But if they are present, they have the
> same semantics. This is the promise made to a client. (Note also that
> objects may be absent for reasons document in deviations or simply not
> accessible due to access control.)
BALAZS: My point is that I do not want to check the full YAM (Yang 
Module) for status commands to understand compatibility. That is not 
better then doing a full analysis of the module. The goal that the 
module name is still the same but it can become incompatible due to 
deprecation is not good enough.
>
>>     While having PYANG based checks for backward compatibility is a very good
>>     idea, a  comparison based check will never be a complete check. It is
>>     quite possible to change just the behavior of an rpc/action/etc.  without
>>     changing the YANG definition.  This will only show up as a change of the
>>     description statement that can not be analyzed by PYANG.
> The problem is to decide whether a change can break client
> expectations or not. Even 'bug fixes' can cause a client written to
> expect the old 'buggy' behaviour to fail. Also tricky are situations
> where behaviour was not clearly enough described and this is 'fixed'
> in a module update.
>
> Semantic versioning assumes that one always can clearly distinguish
> between incompatible updates and compatible updates. This may not be
> so clearly cut in practice, see above. (But then, we have the same
> judgement call at the end with today's update rules.)
BALAZS: Semantic versioning gives the editor the possibility to indicate 
that a change is non backward compatible(NBC). Even if the Yang Model 
type/restrictions/valuespace/etc. does not change, but I, the human 
model designer, know that the expected behavior of the SW implementing 
the model changes, I can still indicate that the model is changing in an 
NBC way. That's one reason I like, I need semantic versioning.
>
>>     When upgrading a network node we might introduce non-backward compatible
>>     (NBC) changes. Today we need to introduce a new module for this. That
>>     means during the upgrade process the node must convert stored
>>     configuration instance data from ietf-routing to ietf-routing-2 format.
>>     Instead of solving this data transformation/transfer problem just for a
>>     few NBC data nodes, we will have to do it for the full model. This is
>>     complicated. In many cases the transformation of a few NBC leafs can be
>>     handled by good defaults or with a small script. Transferring the full
>>     data set is more complicated. If we allow NBC updates in some cases this
>>     problem is avoided.
> In XML land, this is mostly a change of the namespace (not of the
> prefix) if one keeps the same structure, no? In JSON land, the change
> of the module name more directly becomes visible in instance data; but
> this is all encoding details.
BALAZS: Even in XMLland we store the prefix as part of any leaf with 
type instance-identifier or identityref and potentially CLI scripts.
>
>>     If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
>>     the prefix?
> I guess you mean the namespace, not the prefix. You can use any prefix
> you like.
BALAZS: No, I mean the prefix. Prefix is part of the instance data (see 
above), potentially part of CLI scripts etc. It is also part of human 
communication. In email we never refer to
urn:ietf:params:xml:ns:yang:ietf-yang-library:/modules-state instead we 
just write yanglib:/modules/state.
>
>>     In one sense it should be kept as it is the same module
>>     "logically"; we also might have stored data including the prefix
>>     (identityrefs, instance-identifiers). On the other hand having multiple
>>     modules with the same prefix is a problem. The only good solution is to
>>     allow incompatible updates in some cases.
> If we move towards allowing incompabile updates, then we need to have
> a mechanism to tell which versions of modules can work together and
> which combinations are affected by an incompatible update. We probably
> need to require strict import by revision or at least 'import by
> compatible revision' (whatever this means at the end).
BALAZS: We already  have this problem today. We allow incompatible 
updates for deprecated/obsolete. When you import a module, the importing 
module will not check for status statements. For "augment" or "must" 
referencing a deprecated and thus removed part will already today cause 
problems.
>
>>     CH 1)
>>
>>     You write
>>     "The YANG data modeling language [RFC7950] specifies strict rules for
>>     updating..."
>>     and again
>>     "When the same YANG module name is kept, the new YANG module  revision
>>     must always be updated in a backward-compatible way."
>>
>>     I strongly disagree. While we have strict rules about even small
>>     modifications to existing schema, but you are allowed to
>>     deprecate/obsolete big parts of the model, thereby possibly deleting
>>     complete subtrees from the schema. That is anything but strict backward
>>     compatibility.
>>     I find this aspect of YANG inconsistent to the level that it would need an
>>     errata.
> Marking something deprecated / obsolete means you can not be sure this
> is implemented. But then, even definitions with status current may not
> be implemented (see deviations) or they may not be accessible to a
> client due to access control. However, if implemented and accessible,
> the guarantee today is that the semantics stay the same and don't
> change unexpectedly.
BALAZS: Access control can be set by the operator, deviations are at 
least viewable, checkable in design time. However something (possibly) 
removed due to status just disappears. In my view the current status 
deprecated  is similar to deviation not-supported .
>
>>     So practically the current rules allow backward incompatible changes that
>>     can only be detected by a line by line comparison of the yang modules. In
>>     a system with semantic versioning, you could determine backward
>>     compatibility just by reading the version numbers.
> I do not see why you need a line by line comparison. With semantic
> versioning, you _hope_ the semantic version number is a good enough
> indicator. It might also be that your client is only using a subset
> that did not really change even though the semantic version number
> changed. Or the semantic version number indicates only minor changes
> that sill break your client.
BALAZS: Line by line comparison is needed, because today anywhere in the 
model you might find a new status deprecated statement. You are forced 
to do the line by line comparison and even that is no guarantee of 
compatibility due to behavior changes.
Yes you might set the semantic version incorrectly, but that's a bug. 
You might use other parts of YANG incorrectly too.
>
>>     CH 2.3)
>>     As we need to create a new Yang Module (YAM) even for the smallest
>>     incompatible modification, this increases the number of modules.
> So it seems to boil down to the question whether foo and foo2 is
> significantly more expensive than foo { semver 1.x.y } and foo {
> semver 2.x.y }. The main argument seems to be that the later keeps
> references that involve module names or namespaces unchanged (but
> they may or may not mean different things).
BALAZS: For SMALL NBC changes, I propose to keep the original module 
name. Now while agree it is possible to misuse this, and that SMALL is 
subjective, however we already have this situation. Removing stuff by 
deprecation is not much  better then just deleting the same.
In ericsson our internal definition of deprecation follows what e.g. 
JAVA does:
"Deprecated schema nodes MUST still work as defined by the YAM. The 
deprecated status serves only as a a warning that the schema node will 
be removed or obsoleted in the future."
This allows continued compatible usage while still warning the client, 
that the marked parts will go away soon.
>
>>     IMHO YANG package definition should be a separate issue, left out of this
>>     document. Andy has already provided some very good ideas about this topic.
> I think it is necessary to think about how the semantic version
> numbers are used. See my remark above about imports. If we allow
> incompatible changes, than this has side effects and I think we are
> not done by just adding a semantic version number without going
> working throught the implications.
BALAZS: I don't object, although I would prefer to handle them separately.
I do object to the word "if". Due to YANG's current rules for status we 
already allow incompatible changes.
>
> /js
>

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


From nobody Tue Nov 14 20:49: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 48C5812421A for ; Tue, 14 Nov 2017 20:49:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level: 
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 5KSL_vwnTrpn for ; Tue, 14 Nov 2017 20:49:25 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7531612922E for ; Tue, 14 Nov 2017 20:49:23 -0800 (PST)
X-AuditID: c1b4fb30-a25ff70000002554-c6-5a0bc7511bd3
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.D6.09556.157CB0A5; Wed, 15 Nov 2017 05:49:21 +0100 (CET)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 05:49:20 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EqF+BiLVrKgtn5h95QoIe/Amqc6rV9LshqzisU1GcBM=; b=TW/M6SkrRMXtR0iX5cMUS5UwQGegHABdSyntYlFM9Rm4VUI+BzLRyUUW5wfsrfvTSY9kbXbDAIbmU61wBtQMdwKn30P1VplulJT45zILqVrwItd5LtYQSHZ4OJoKOAo5VhyeOJPs5Semfxyekjmp7h+VRnmfXr8dyFL0UD4M83U=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [IPv6:2001:67c:370:128:d151:2478:63f2:5fe7] (2001:67c:370:128:d151:2478:63f2:5fe7) by HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:2c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Wed, 15 Nov 2017 04:49:18 +0000
To: Andy Bierman , "netmod@ietf.org" 
References: 
From: Balazs Lengyel 
Message-ID: 
Date: Wed, 15 Nov 2017 12:48:58 +0800
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: 
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [2001:67c:370:128:d151:2478:63f2:5fe7]
X-ClientProxiedBy: SG2PR06CA0156.apcprd06.prod.outlook.com (2603:1096:1:1f::34) To HE1PR07MB3436.eurprd07.prod.outlook.com (2603:10a6:7:2c::15)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e9f1dee6-bd18-420f-9fa6-08d52be43b7f
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR07MB3436; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3436; 3:rcsPf7o7xw0dQuwp2t7rw/deLOpMRyLDfhmTkxdVtOvQlLw2Ikgm+zHf2CWaMYiR4C9nnr19oGluh0prj+HjpUxpNXRy23ltAh3iP39pVv8IkzafCQnY8F9Nxj+VdLY1WuZyHG7y3YHl6VtakOaICdFUyKOkosiRHDtoD52B/Z9RHT8tXBJb2mcVMOyZgiV6rk+6iP8s/mSrmr6c4kXZltzdzu+2HxRTrQJM20y7EeFGq7pf0/9ScFm+835YMjOu; 25:xs8M1RJSg3fz+frqCcGTYYmbfwlXhF6mWuL9MjjTOPWqRhteKVURepGfZlTLrWMpgeDt7TU0W6Uk7HLAwMO40cUwzUTuyC234t7xuoxnbYX/BfkQgbk2AOq0PhLnVwOmlDWxW+WWUo/Cx3Lm5PWRR9yOUssQwro4rufk8+l3FbqXLyYjAqBkUgD8nyeS9DTnzLX2gi8HVSsnsOnE7wJDTH5x0hHcnkq01LpLM49R3UVAP/g7rzx0BOg8A8KpT795TMLZaNvTftPOB72TfrlKYb6QwDs5BR2cY1XsZJh0eAHBB1YSdmuckSCQbUCkgqbJVJXEaIdGPT85PLSjziDQqQ==; 31:lKzFCAua3hUBygzmxhtFw3a6Cmp2XgyjTtQ6XCfxR62JxW2jF+xVu3iBvY/EgaARkWpzxj7Yqu8muHhWBLI+Z4kzKjoeksLWvPWncv72oVRezQX4meYXchJ/pUqpP1l/wO+bxHKErcnT/oBT6razfnF3+Hh9Zg37KCoNRmQuUfwV9lscOSe/wE4iudXX4BlDH8bxzCSnd+h+AFmXMkL7NpRqAl2J2+s2gR/HgLIIeic=
X-MS-TrafficTypeDiagnostic: HE1PR07MB3436:
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3436; 20:BNCpTMkDznAAmbK7WARny2P2RTAsn/TCQIQ8JebC77t/051gXuIpSjvECr089BAi7yTq5FhLdef6E53lx6Ov16fMu80X4AzChqLkdZ3KlwSLCJWAuVPRDf6aqlo4dmI12DQVsSj9v2qQekUKOhuQao11MTMR48AjT3TGWx8MMemhpEJTehfh01/F5EJwuhNHUSLT85+0ybvEgQ6Z3EM/zYDWdXkK8Fd/RijFsKIic1deZleXord/6jSmcSs4H2pjdwqbUGHk17GORQa8WUIblGmy1Urc8xFFFx9+vNjZNs0xYuhJ44Fafe9+xmihW8tjGCOaSpH+hczuK1NNIJvXZSLNSmnJs7TL4f1oB7yv08Y+iAOR7yZA5xcW6nukBgnKSCl9fb/P6KGwd5gBtl5CU2rudPYxlnPBSnwVmhpkX82iBZMFUaMrgficcus0LJyQfoCQl87iVb0blTICnPy7SMMKJMqWUjSXt8COSzTWqEPJmIkMfdVuR4qJKBDVIXGF; 4:3Rvp+f3Gu59TYirtYrouxnzAkig8OMgQ9z3JdX2vmxZDJz1+wZLXFXA38sc89Q5+/snCsxEaJP//QDmYUm2U1MlvVQvADooeWrBRfDVycIGDyYYlXtjaurui8SbtedLdfTp2lgV6/GkDYRpUJe+W01cIoqfqt70lIGl+bO4WAPkrN5w6ydpro/0WipQUDXVHA3JN1gB/ZmAlLny1pPQ7DZRS9t3iHPlyZWh5F4fZ6pzRrx3VJeAEJFcjARvFL4apyHsZ3vVho0wzmMSi0lESKZxx/DnKp1LkWF0XeB+BhaTe5IisuZXXCsr3OMhCw4IY
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3436; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3436; 
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(24454002)(252514010)(377424004)(189002)(199003)(2950100002)(53936002)(50986999)(76176999)(54356999)(31686004)(6246003)(478600001)(105586002)(7736002)(606006)(6666003)(68736007)(36756003)(101416001)(8676002)(65826007)(966005)(316002)(53546010)(236005)(8936002)(6306002)(54896002)(25786009)(33646002)(2501003)(5660300001)(81166006)(81156014)(229853002)(64126003)(110136005)(2906002)(65956001)(65806001)(189998001)(23676003)(2870700001)(83506002)(50466002)(23846002)(58126008)(6116002)(230783001)(106356001)(97736004)(31696002)(86362001)(4001150100001)(1706002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3436; H:[IPv6:2001:67c:370:128:d151:2478:63f2:5fe7]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDM2OzIzOmZ3UmpMSmVLaW9vNXZTc3lkU2RvbGpTQ2ha?= =?utf-8?B?NmFOZnJ3QnRHVTVlNEVsek5YQ3lKWUZtem0zY2FvTXd3Z3dwaFIxU2hGYkJQ?= =?utf-8?B?NTd4WFVXMTNqTXdTVVlhbFFXUWo3eDNKazJ2TTVidnhDdXpweEQ3S0RBSHhp?= =?utf-8?B?STMrZzMvZmFTbEp5NExvbXV5TVNQMmJiTFFoMGJia1NWUVNzaGZKTHNyaVk2?= =?utf-8?B?RFJpL25WZXM3Rm5HQmsyZDN2Y2J4bmRqUlhNVXAyQjN0VXgzRlNsMWhGQTdL?= =?utf-8?B?YW84bWtnNFBBdDFMQUI1VWNWbHdaaUNzVmxreWVHazJyNi9yb1FNTFNDSkFX?= =?utf-8?B?b0I3dUsxcUJvQ3hLc1gzQkNKTk9qQUR5RXVwOUduYWdMOG9GeDJORU8waml4?= =?utf-8?B?ZjRHOFZCMDFvTzJlMGNQWUxyMnlwQ1d6Yzh3eEFiUHp3a1hZTEc0TDYxWnlX?= =?utf-8?B?RHgwbUtTVFI5QmxtcnowNUdMQmp4cTEwSDNZNTRmTitZcm9PU3luemxnVGZO?= =?utf-8?B?YnM2NTkrSEl5NUxJYTJnM2t3S0tmZkYvVlVJcTBNUnpjN0lrYmN3QzVqUWFa?= =?utf-8?B?UlZwcTNxUXNCY0syWHlwOEltUXdqVWNHczJvVW4rS2pNZXB0WFZId1dOUFlM?= =?utf-8?B?UXZmZWRQc0UxQXFya0VsLzB5U09FRFNWdjUvOVl4U2IyZlhOU1J0Yy9CZ0JE?= =?utf-8?B?MHJSMStobzlFNEl6RHROMjZmb0hZdlU2V3JOWERsTWY1eG13ZE1XeXpVMEYr?= =?utf-8?B?UVRiY1B5ZnB0TnRTaWgrTW9CSUt6L1Z0UVA2S3JoQXNUL1NxYVhTWHBwNEk4?= =?utf-8?B?U0tKQkowLytGVGpkUlpNaGV2Wi93SFZqS01sa0dxdTd5ZitON0plK3VjS28v?= =?utf-8?B?eVkyZEtuZ3ovUDIzRUlmd2xQbmcwdUpTMmoyVkhBNktWQmlLKzVnMnF1NlZl?= =?utf-8?B?SXlXMkxmMXJLV0lHcXFNVVErK3UzTWx4bkFHRDA3SHBISHBPZTJWamZENW50?= =?utf-8?B?Wk9FNHVnMnladTJhb1lqSmdzVnlDTjNlTjFSdUZMY2xqejYybVV4MGtHZ1V2?= =?utf-8?B?Si94a1NOZmJNMFdXYjZsOGdNaU5zc2x6TUlpR09kNDJaMHZSU1lDOUYxb3RE?= =?utf-8?B?c3VjVU5VeUpqays4c2RVMnl6NTJ5dk9RTzk3SE1aV2RmLzRNaTU2ZUZhR25m?= =?utf-8?B?SjlyNE5peWMvMWhkNDZseXl3YkFPQVorZ0VCbWw3ekV1dHpRUmtVYmdKeExn?= =?utf-8?B?bUVwTjAxeHFUNmhDME94S3owR0ErbzdTMmJvSEVvK3NPbUM0b05zRFVaMUtP?= =?utf-8?B?SWd5ZHdIK1NaRk11NXhEN1lna012N21RK0JiUy8zYTU2aEpGeVViNVJPSURC?= =?utf-8?B?QlVkb3R6N1oyS2tTamhndXZzeGZKSXgwT0w4eDhCMDJKN25yY2ltckk4RFlr?= =?utf-8?B?WEUwcVdSbnJsWEthZjRESDNiUTZndDRueHBGck5oNU1uVzlxLzdKNXR3VDJC?= =?utf-8?B?Y1I3YzB3empUVGVUZEJVYmI4NlMwTXVPTThJUlA0R2g4aXNOb1VDWGFBM0VR?= =?utf-8?B?THZHYllBQW5aanNRc2FNMTBpcXRGRlJ0MkFyVHVuNUxNRUNJTldCdk5ydmwz?= =?utf-8?B?TS9kNWtYVDgzK1hmNDBxUEozYnVMdVpCdVVIbEhRRlNSN2M4ZGFNZHB6RWtz?= =?utf-8?B?cHYwaHVEaXlIMEtLMU81K1ZsRlVlNTk1WDhSVlBWZDVhdnIzblc4SzdCdWdS?= =?utf-8?B?NEtGWWNCMVROc25FbFU2UUdabkFCNEF1QWxxVy9hWk4raFNncVlKU28zL09F?= =?utf-8?B?WjlIR0pYMHFzZzU4NXloUk1CZXVLdUw1c3VaZ29ZMkQ5NGpiMG9BT0hlcWhj?= =?utf-8?Q?5Nsate+zpjfl1YbuNUEsYSSnsgJJDXqq?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3436; 6:YC9kF1VR0e3PyAO275EBfRrDxMzuaxNG5sSs3Ckq5DhOeQkwqJWGQhKn0KLCFJkeXlz/KwuVS+yCgoGS2AymS8yrahKPgFdLcEjKNMouprL+cQFVYVGFuGGts2tZjLCCjkK7aEiJ30sf2UgzsZSHCvZxKxSVCC28wLDGf02qCM7i1Pu1zIu0xT7FnZVY/5BC2McY29bRXNjAcGKaEcmP9cK9ru4egmkA4j5Ou5V+X5ApywsGcuLJRtWSMI5dDbIVKeTH1aSrS5ppt/LiVWV4S187CX9xZiKDnPxKsdaseTbPmz88ZgwhhpZAPs5aAidpoKwF0rLlVQPZu/gGq8Hp9DlkcLaU3PrhmzrwoncslVc=; 5:4NzwGRmq3mYWNuo2RaXqc/3swICb9XZTYkk3xQS0vNDxr10R4RtGzGzsuUnMaMKYxrqH3O4yjaP/wQJhNGqTTTTk8Yo9lIr1pk0hDDCcuJGcWG1QzE11lUgYPZlXzEsY1y3Abw79+7K2C8bRfLv6kQ95hOaKZi5cXyeJ8CR3I/8=; 24:x2+vwIliu83sxCSs3JDS2ACh38hWQt7tQDgDl7QBUmbFc6XUpuMS6ak9Re4cUPpD9Ri8/WEs9H1dx7eLnPcoqKMKE+sTKc5K7ZrOV60eGXM=; 7:i8smWxoidVEExVxzX2LLPaKXfWkAMX6xKGHjeOpiS3BoZqL9uNgPQM2VcCwklgxf+l9yphWPvRMiFhyF/Eia7zkJ9mATitCmc94u8ShIFYwiE8Bew7CrWCt9QwoJkFQNEg0WYlQStwQjTxAR5wZYu/1b2ALFycVXS1humiE8O5DFPW6doWaJu6r6CqLuC1EGJhw7KqNz0nfvzaw1VZOOcH741dHQ8Tm9z8i/LbWKQhmGFOjp5qbAN6CuFh6NYJh6
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 04:49:18.5581 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e9f1dee6-bd18-420f-9fa6-08d52be43b7f
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3436
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjm2zk752xr9TlnvkxLGFpz5jQJWRFdfillkP/CLJt60qFO27xk UKlZiCBaZripWCFFLTFl85qiS9NpUmJBJcYKu6ioaaCliG07C/bvucL7wMsQklt8GaPV5bJ6 nSZTTglJ45mOgPD4YVFCZMuCn9oxaKLVjRPF/GO82Kamv7zY0soJ8jQvQXg4lc3U5rP6iCMX hOnG5UUip2/n5dWRZqIIje0oRwIG8AH42mKmypGQkeCXCGrL5/kcGUHQbV6hXYTEFQQ8f7xF uyoIn4euZw88qW4eWFt/OwnD+OJ9YDZRrowUn4Cq4SbkwhJ8Gr7d6yBdmMJRUFP5hnTFxfgo PHmlcskkDoHe1kV31Q8nwm3HhLsqxj5gN8644wIcD52PBC6ZwAq4Wd9Ac9gfPs008jgcBDes dQQ3TA1zm7XuKwFXI2iraeBx5yjgy9tNPhfaBUPj9SSHT8FybzHJFYwItqbLaI4U0VA8avE0 lDDVbKc44w8FfaUViDMyYNi+5MGHYH59DXGhd3ywjs3SnBEI9g+9HqOagp5fXUQVCjN5bTV5 DTR5DTR5DbyPyKfIz8AakrPSoqJUrF6bYjBk61Q6NrcNOb9jwLIR2Ylmfxy3Icwg+TbxulWU IOFr8g2FWTYEDCGXilMqnZI4VVN4hdVnJ+nzMlmDDQUwpNxfHCt1WjhNk8tmsGwOq//v8hiB rAgFJqWPB8eb19IODn23J1umAipwdFAi7CkQaYP7w14MzJaW+cfRDiXvetxknShM9X4jtPu1 zDdizqdmSXFN1vkTNT9sXzlJ3x29WOI4+1lp6tkqCYn5GDQartnbf3VA1JK3fe1Ou0UZcyl0 QTEYfm6aUttUm7up2tVJ6Xp0wbKcNKRr9isJvUHzD4FMC0kZAwAA
Archived-At: 
Subject: Re: [netmod] ietf-yang-library edit
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 04:49:27 -0000


  
    
  
  
    
Hello,

    
I though our strategy was to always use the latest revision
      available. At least till now that works for me.

    

    
regards Balazs

    

    

    
On 2017-11-15 10:33, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
The ietf-yang-library module relies on "yang-identifier",
          which was added to the 2nd

        
version of the ietf-yang-types. It does not compile unless
          that version is used.

        


        

        


        

        
OLD:

        


        

        

          
    import ietf-yang-types {

          
        prefix yang;

          
    }

        

        


        

        


        

        
NEW:

        


        

        

          
    import ietf-yang-types {

          
        prefix yang;

          
        revision-date "2013-07-15";

          
        reference "RFC 6991: Common YANG Data Types";

          
    }

        

        


        

        


        

        
There are other modules such as ietf-ip that rely on RFC
          6991 additions

        
and the import-stmt (in every case) should be changed to
          specify the

        
required revision-date.

        


        

        


        

        
Andy

        


        

        


        

      

      

      

      

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


    

    

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


  



From nobody Tue Nov 14 21:05: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 62FF5127873 for ; Tue, 14 Nov 2017 21:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 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, 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 gE8XdVIEGQYj for ; Tue, 14 Nov 2017 21:04:57 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA001242EA for ; Tue, 14 Nov 2017 21:04:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6631; q=dns/txt; s=iport; t=1510722297; x=1511931897; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=3xNDVEgpgZIPUNW+0IaWW6cAtPusvVwclHC9oILyXz0=; b=HpfFsKYW5u0wFZD8+//yTT1Rb+sCSDM9aYAOa00f37AOKM/e3cGTKWjN bptowypAt1Hgxi9px5TBIwWjjYAsAL6TuDSjHlrwc/CKRv02Fv5P4pQSB 1aGdwE54m6K5AsdxdHxKhu1V05PeQynAmdJZCgwgh4T0NEig9askXcFNW g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAACAyQta/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4ng36KH48xgX2RDoVJEIIBChgBCoRJTwKFAT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHgEBAQECAQEBIUsQCwkCGCoCAicwBgEMBgIBAYoXCBCMY51ogicmi?= =?us-ascii?q?nQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYM0ggeBVYISgwGEZQESAQmDK4JjBYo?= =?us-ascii?q?5iEmPMpUGhA6Hb4dFjjiHc4E5HzhCQXA0IQgdFUmCZIRsNDaGMoI1AQEB?=
X-IronPort-AV: E=Sophos; i="5.44,398,1505779200"; d="scan'208,217"; a="31586408"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 05:04:56 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vAF54tAd030043; Wed, 15 Nov 2017 05:04:55 GMT
To: Balazs Lengyel , Andy Bierman , "netmod@ietf.org" 
References:  
From: Robert Wilton 
Message-ID: <14b6c48a-3d59-6d71-fff3-c034db085227@cisco.com>
Date: Wed, 15 Nov 2017 13:04:54 +0800
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="------------A3CC25D737901450048561D8"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] ietf-yang-library edit
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 05:04:59 -0000

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



On 15/11/2017 12:48, Balazs Lengyel wrote:
>
> Hello,
>
> I though our strategy was to always use the latest revision available. 
> At least till now that works for me.
>
Yes, I'm not convinced that the import by revision is really that 
helpful since it states that it must pull in exactly that version, but 
really the dependency is "at least version X, assuming newer revisions 
are backwards compatible".

E.g. if/when ietf-yang-types is updated again, it would be 
cleaner/simpler if the server could just use the latest version rather 
than having to potentially import multiple revisions.

Thanks,
Rob


> regards Balazs
>
>
> On 2017-11-15 10:33, Andy Bierman wrote:
>> Hi,
>>
>> The ietf-yang-library module relies on "yang-identifier", which was 
>> added to the 2nd
>> version of the ietf-yang-types. It does not compile unless that 
>> version is used.
>>
>>
>> OLD:
>>
>>     import ietf-yang-types {
>>         prefix yang;
>>     }
>>
>>
>> NEW:
>>
>>     import ietf-yang-types {
>>         prefix yang;
>>         revision-date "2013-07-15";
>>         reference "RFC 6991: Common YANG Data Types";
>>     }
>>
>>
>> There are other modules such as ietf-ip that rely on RFC 6991 additions
>> and the import-stmt (in every case) should be changed to specify the
>> required revision-date.
>>
>>
>> Andy
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email:Balazs.Lengyel@ericsson.com  
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    


    

    

    
On 15/11/2017 12:48, Balazs Lengyel
      wrote:

    

    

      
      
Hello,

      
I though our strategy was to always use the latest revision
        available. At least till now that works for me.

      

    

    Yes, I'm not convinced that the import by revision is really that
    helpful since it states that it must pull in exactly that version,
    but really the dependency is "at least version X, assuming newer
    revisions are backwards compatible".

    

    E.g. if/when ietf-yang-types is updated again, it would be
    cleaner/simpler if the server could just use the latest version
    rather than having to potentially import multiple revisions.

    

    Thanks,

    Rob

    

    

    

      
 

      
regards Balazs

      

      

      
On 2017-11-15 10:33, Andy Bierman
        wrote:

      

      

        
Hi,
          


          

          
The ietf-yang-library module relies on "yang-identifier",
            which was added to the 2nd

          
version of the ietf-yang-types. It does not compile
            unless that version is used.

          


          

          


          

          
OLD:

          


          

          

            
    import ietf-yang-types {

            
        prefix yang;

            
    }

          

          


          

          


          

          
NEW:

          


          

          

            
    import ietf-yang-types {

            
        prefix yang;

            
        revision-date "2013-07-15";

            
        reference "RFC 6991: Common YANG Data Types";

            
    }

          

          


          

          


          

          
There are other modules such as ietf-ip that rely on RFC
            6991 additions

          
and the import-stmt (in every case) should be changed to
            specify the

          
required revision-date.

          


          

          


          

          
Andy

          


          

          


          

        

        

        

        

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


      

      

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


      

      

      

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


    

    

  


--------------A3CC25D737901450048561D8--


From nobody Tue Nov 14 21:20: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 3F97C127201 for ; Tue, 14 Nov 2017 21:20:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSLuwluiTu6r for ; Tue, 14 Nov 2017 21:20:05 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA284127058 for ; Tue, 14 Nov 2017 21:20:04 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id g35so10536721lfi.13 for ; Tue, 14 Nov 2017 21:20:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yq4EiedyJgdsIQYWdBEhJI2FrHQCZgW5TfEjRknod2s=; b=eeHGvtyhqO8S6Kz7EnmY/k4Im4VQroBMmcB8IDWpFGhYAMvkY2+LYpJvQy+AFDe/de 82g8INu0nSWZOR4cq6+8SxH6kdfV+icAXRVO2u8NlJLpgYiN2PfujbLTWu/+d+Ve0t9o BOJxe3DWV4fEfyVx09mI2+BFR1q+f0M0pSB5E7htvbgGEG9AmWL7EKldFS3q16mGm0RX QunRyTS/ya2B5dtDjw1613bap0IqLQfh1p6S1q+k73PR7MEMsNlBRBFcLzo3IyMz1Vq5 SHWf3/OrOTnouX9bd7d/0LsFmyQoM/siAkzK/wqJmqYK1OEsz+0AcAsYcS9doG/Be7Bs ehMw==
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=Yq4EiedyJgdsIQYWdBEhJI2FrHQCZgW5TfEjRknod2s=; b=krbjWQAyQIfghJOOb+r82/JSkJgtMvzOhb/yr89jlXpITqzM4SXhIuZozgwgfC0wMc wYvlkl0usgvAiTt4VnZjg+8Pv6BBk/TlNVusPC0TKLFAGG8rdnGoqZC/ZcLnVQPHsMok nDDHqog8LbJUprV9RpX/MKtVDqaS4cCaMNstHS8Q+KiaDzfnIalK6vxelzlsLD62uOYk /HioX23ujZaeqqWPzGmNhveJ8eh84tkDtu3n0dxOHjoJC/RWt3Bz4zFYeMpHwKfr1DGE c1KvuBq8GZcbuHpzlP3KGA/weRhKkvtbwBViJ0d2lvqgTwHO0unGIpGX8cAe4G/RVacO 9a3Q==
X-Gm-Message-State: AJaThX5lSQ80scgiqInwT0GhSh0TtGDa5U2M7pMGiIVgiTcj+MNAgNd7 jzxOHs5v+uYrPk4RfS4GSjmJk4qivVJLShkNsMSdeA==
X-Google-Smtp-Source: AGs4zMb0NMJY8RUfx2pEU2Ge9gqh27sXp/jxlWWw6Gl8mAI0xbRBJ82O/jAMDnJDvVKEOrsu7610m1K1ZWU9iqxzENA=
X-Received: by 10.46.86.195 with SMTP id k64mr6250140lje.81.1510723202900; Tue, 14 Nov 2017 21:20:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Tue, 14 Nov 2017 21:20:02 -0800 (PST)
In-Reply-To: <14b6c48a-3d59-6d71-fff3-c034db085227@cisco.com>
References:   <14b6c48a-3d59-6d71-fff3-c034db085227@cisco.com>
From: Andy Bierman 
Date: Tue, 14 Nov 2017 21:20:02 -0800
Message-ID: 
To: Robert Wilton 
Cc: Balazs Lengyel , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c14aa74dcf790055dfea7af"
Archived-At: 
Subject: Re: [netmod] ietf-yang-library edit
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 05:20:07 -0000

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

Hi,

The entire reason for import-by-revision is to make sure that
the importing module can safely use definitions that have been added after
the first revision of the imported module.


Andy



On Tue, Nov 14, 2017 at 9:04 PM, Robert Wilton  wrote:

>
>
> On 15/11/2017 12:48, Balazs Lengyel wrote:
>
> Hello,
>
> I though our strategy was to always use the latest revision available. At
> least till now that works for me.
>
> Yes, I'm not convinced that the import by revision is really that helpful
> since it states that it must pull in exactly that version, but really the
> dependency is "at least version X, assuming newer revisions are backwards
> compatible".
>
> E.g. if/when ietf-yang-types is updated again, it would be cleaner/simpler
> if the server could just use the latest version rather than having to
> potentially import multiple revisions.
>
> Thanks,
> Rob
>
>
> regards Balazs
>
> On 2017-11-15 10:33, Andy Bierman wrote:
>
> Hi,
>
> The ietf-yang-library module relies on "yang-identifier", which was added
> to the 2nd
> version of the ietf-yang-types. It does not compile unless that version is
> used.
>
>
> OLD:
>
>     import ietf-yang-types {
>         prefix yang;
>     }
>
>
> NEW:
>
>     import ietf-yang-types {
>         prefix yang;
>         revision-date "2013-07-15";
>         reference "RFC 6991: Common YANG Data Types";
>     }
>
>
> There are other modules such as ietf-ip that rely on RFC 6991 additions
> and the import-stmt (in every case) should be changed to specify the
> required revision-date.
>
>
> Andy
>
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>

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


Hi,

The entire reason for import-by-rev=
ision is to make sure that
the importing module can safely use de=
finitions that have been added after
the first revision of the im=
ported module.


Andy

<=
/div>


On Tue, Nov 14, 2017 at 9:04 PM, Robert Wilton &=
lt;rwilton@cisco.com=
> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 15/11/2017 12:48=
, Balazs Lengyel
      wrote:

    

    

     =20
      
Hello,

      
I though our strategy was to always use the latest revision
        available. At least till now that works for me.

      

    

    Yes, I'm not convinced that the import by revision is really that
    helpful since it states that it must pull in exactly that version,
    but really the dependency is "at least version X, assuming newer
    revisions are backwards compatible".

    

    E.g. if/when ietf-yang-types is updated again, it would be
    cleaner/simpler if the server could just use the latest version
    rather than having to potentially import multiple revisions.

    

    Thanks,

    Rob

    

    

    

      
 

      
regards Balazs

      

      

      
On 2017-11-15 10:=
33, Andy Bierman
        wrote:

      

      

        
Hi,
          


          

          
The ietf-yang-library module relies on "yang-identifier=
",
            which was added to the 2nd

          
version of the ietf-yang-types. It does not compile
            unless that version is used.

          


          

          


          

          
OLD:

          


          

          

            
=C2=A0 =C2=A0 import ietf-yang-types {

            
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix yang;

            
=C2=A0 =C2=A0 }

          

          


          

          


          

          
NEW:

          


          

          

            
=C2=A0 =C2=A0 import ietf-yang-types {

            
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix yang;

            
=C2=A0 =C2=A0 =C2=A0 =C2=A0 revision-date "2013-07-15=
";

            
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reference "RFC 6991: Comm=
on YANG Data Types";

            
=C2=A0 =C2=A0 }

          

          


          

          


          

          
There are other modules such as ietf-ip that rely on RFC
            6991 additions

          
and the import-stmt (in every case) should be changed to
            specify the

          
required revision-date.

          


          

          


          

          
Andy

          


          

          


          

        

        

        

        

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


      

      

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


      

      

      

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


    

    

  






--94eb2c14aa74dcf790055dfea7af--


From nobody Tue Nov 14 21:27: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 3659A126C19 for ; Tue, 14 Nov 2017 21:27:03 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 RX_9Q3vkKlb1 for ; Tue, 14 Nov 2017 21:27:01 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 B57641243F6 for ; Tue, 14 Nov 2017 21:27:01 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 6CBA5140448 for ; Tue, 14 Nov 2017 22:27:01 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id a5Sx1w00D2SSUrH015T02r; Tue, 14 Nov 2017 22:27:01 -0700
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=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=fqaglU3sVlq6uR32EvcA:9 a=QEXdDO2ut3YA:10 a=gUXmQ8eWAGYA: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:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc: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=O5cB4bKacQuH6BAx9l1KIUwabIF020Q+Own7o2DzHvw=; b=aW6c+6XNLzfEIFZnO3vc+41c7I KlpVHoqQFeYqADRMiW2Qf0mIf/PCkx0ivqg6qoqzqqo5wLTOS1rC8AhshXnwNX46j//RaSfdcuDAp cadW40tUmKbFwFib8+IT97a3t;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:34656 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eEqDw-002Uxt-Tl for netmod@ietf.org; Tue, 14 Nov 2017 22:26:57 -0700
To: "netmod@ietf.org" 
From: Lou Berger 
Message-ID: <6a3db853-8c03-5ab3-4c94-6a4230b8677a@labn.net>
Date: Wed, 15 Nov 2017 13:26:52 +0800
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-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: 1eEqDw-002Uxt-Tl
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]:34656
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] todays meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 05:27:03 -0000

Just a reminder: our meeting has been moved to Sophia for both session
Also, etherpad can be found at 
http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-netmod?useMonospaceFont=true

Please join and help with note taking and corrections!
Lou and Kent


From nobody Tue Nov 14 21:32: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 231CE1286B1 for ; Tue, 14 Nov 2017 21:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 28X1HpO3t8Kj for ; Tue, 14 Nov 2017 21:32:17 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5451243F6 for ; Tue, 14 Nov 2017 21:32:17 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id F04BD6A0; Wed, 15 Nov 2017 06:32:15 +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 EKGqL-oxDp9k; Wed, 15 Nov 2017 06:32:15 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Nov 2017 06:32:15 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE05B2011F; Wed, 15 Nov 2017 06:32:15 +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 prR9mQHU2U9J; Wed, 15 Nov 2017 06:32:14 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A45E72011E; Wed, 15 Nov 2017 06:32:14 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 545C24158547; Wed, 15 Nov 2017 06:30:46 +0100 (CET)
Date: Wed, 15 Nov 2017 06:30:46 +0100
From: Juergen Schoenwaelder 
To: Balazs Lengyel , "netmod@ietf.org" 
Message-ID: <20171115053046.nr33ypoibdn4jufv@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" 
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 05:32:20 -0000

Another thing to consider is that foo and foo2 allows an
implementation to support both during transition, with foo {semver
1.x.y} and foo {semver 2.x.y} this may be harder.

/js

On Tue, Nov 14, 2017 at 10:22:10PM +0100, Juergen Schoenwaelder wrote:
> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
> >    Whenever a client OSS implements some higher level logic for a network
> >    function, something that can not be implemented in a purely model driven
> >    way, it is always dependent on a specific version of the Yang Module
> >    (YAM). If the client finds that the module has been updated on the network
> >    node, it has to decide if it tries to handle it as it did the previous
> >    version of the model or if it just stops to avoid problems. To make this
> >    decision the client needs to know if the module was updated in a backward
> >    compatible way or not. This is not addressed with the current versioning.
> 
> The current rules aim at guaranteeing that definitions (with status
> current) remain backwards compatible. Do you have an example what the
> current rules fail to achieve this? Definitions with status deprecated
> or obsolete may not be present. But if they are present, they have the
> same semantics. This is the promise made to a client. (Note also that
> objects may be absent for reasons document in deviations or simply not
> accessible due to access control.)
> 
> >    While having PYANG based checks for backward compatibility is a very good
> >    idea, a  comparison based check will never be a complete check. It is
> >    quite possible to change just the behavior of an rpc/action/etc.  without
> >    changing the YANG definition.  This will only show up as a change of the
> >    description statement that can not be analyzed by PYANG.
> 
> The problem is to decide whether a change can break client
> expectations or not. Even 'bug fixes' can cause a client written to
> expect the old 'buggy' behaviour to fail. Also tricky are situations
> where behaviour was not clearly enough described and this is 'fixed'
> in a module update.
> 
> Semantic versioning assumes that one always can clearly distinguish
> between incompatible updates and compatible updates. This may not be
> so clearly cut in practice, see above. (But then, we have the same
> judgement call at the end with today's update rules.)
> 
> >    When upgrading a network node we might introduce non-backward compatible
> >    (NBC) changes. Today we need to introduce a new module for this. That
> >    means during the upgrade process the node must convert stored
> >    configuration instance data from ietf-routing to ietf-routing-2 format.
> >    Instead of solving this data transformation/transfer problem just for a
> >    few NBC data nodes, we will have to do it for the full model. This is
> >    complicated. In many cases the transformation of a few NBC leafs can be
> >    handled by good defaults or with a small script. Transferring the full
> >    data set is more complicated. If we allow NBC updates in some cases this
> >    problem is avoided.
> 
> In XML land, this is mostly a change of the namespace (not of the
> prefix) if one keeps the same structure, no? In JSON land, the change
> of the module name more directly becomes visible in instance data; but
> this is all encoding details.
> 
> >    If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
> >    the prefix?
> 
> I guess you mean the namespace, not the prefix. You can use any prefix
> you like.
> 
> >    In one sense it should be kept as it is the same module
> >    "logically"; we also might have stored data including the prefix
> >    (identityrefs, instance-identifiers). On the other hand having multiple
> >    modules with the same prefix is a problem. The only good solution is to
> >    allow incompatible updates in some cases.
> 
> If we move towards allowing incompabile updates, then we need to have
> a mechanism to tell which versions of modules can work together and
> which combinations are affected by an incompatible update. We probably
> need to require strict import by revision or at least 'import by
> compatible revision' (whatever this means at the end).
> 
> >    CH 1)
> > 
> >    You write
> >    "The YANG data modeling language [RFC7950] specifies strict rules for
> >    updating..."
> >    and again
> >    "When the same YANG module name is kept, the new YANG module  revision
> >    must always be updated in a backward-compatible way."
> > 
> >    I strongly disagree. While we have strict rules about even small
> >    modifications to existing schema, but you are allowed to
> >    deprecate/obsolete big parts of the model, thereby possibly deleting
> >    complete subtrees from the schema. That is anything but strict backward
> >    compatibility.
> >    I find this aspect of YANG inconsistent to the level that it would need an
> >    errata.
> 
> Marking something deprecated / obsolete means you can not be sure this
> is implemented. But then, even definitions with status current may not
> be implemented (see deviations) or they may not be accessible to a
> client due to access control. However, if implemented and accessible,
> the guarantee today is that the semantics stay the same and don't
> change unexpectedly.
> 
> >    So practically the current rules allow backward incompatible changes that
> >    can only be detected by a line by line comparison of the yang modules. In
> >    a system with semantic versioning, you could determine backward
> >    compatibility just by reading the version numbers.
> 
> I do not see why you need a line by line comparison. With semantic
> versioning, you _hope_ the semantic version number is a good enough
> indicator. It might also be that your client is only using a subset
> that did not really change even though the semantic version number
> changed. Or the semantic version number indicates only minor changes
> that sill break your client.
> 
> >    CH 2.3)
> >    As we need to create a new Yang Module (YAM) even for the smallest
> >    incompatible modification, this increases the number of modules.
> 
> So it seems to boil down to the question whether foo and foo2 is
> significantly more expensive than foo { semver 1.x.y } and foo {
> semver 2.x.y }. The main argument seems to be that the later keeps
> references that involve module names or namespaces unchanged (but
> they may or may not mean different things).
> 
> >    IMHO YANG package definition should be a separate issue, left out of this
> >    document. Andy has already provided some very good ideas about this topic.
> 
> I think it is necessary to think about how the semantic version
> numbers are used. See my remark above about imports. If we allow
> incompatible changes, than this has side effects and I think we are
> not done by just adding a semantic version number without going
> working throught the implications.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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


From nobody Tue Nov 14 21:52: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 E359B1276AF for ; Tue, 14 Nov 2017 21:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jIdmS2MCQJZb for ; Tue, 14 Nov 2017 21:51:59 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701391294F0 for ; Tue, 14 Nov 2017 21:51:39 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 375DEF6F; Wed, 15 Nov 2017 06:51:38 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id DJ-Yd99xq4UP; Wed, 15 Nov 2017 06:51:37 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Nov 2017 06:51:38 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0308C2011F; Wed, 15 Nov 2017 06:51:38 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08Wxouhl1kzt; Wed, 15 Nov 2017 06:51:36 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B276A2011E; Wed, 15 Nov 2017 06:51:36 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id BD7134158586; Wed, 15 Nov 2017 06:50:09 +0100 (CET)
Date: Wed, 15 Nov 2017 06:50:09 +0100
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Cc: "netmod@ietf.org" 
Message-ID: <20171115055009.4cxh4flprac4rpg7@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" 
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <66e88c5b-41fc-7607-e1a9-ebe76eded836@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <66e88c5b-41fc-7607-e1a9-ebe76eded836@ericsson.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 05:52:01 -0000

On Wed, Nov 15, 2017 at 11:33:18AM +0800, Balazs Lengyel wrote:
> BALAZS: Semantic versioning gives the editor the possibility to indicate
> that a change is non backward compatible(NBC). Even if the Yang Model
> type/restrictions/valuespace/etc. does not change, but I, the human model
> designer, know that the expected behavior of the SW implementing the model
> changes, I can still indicate that the model is changing in an NBC way.
> That's one reason I like, I need semantic versioning.

You have several possible cases:

a) The semver indicates an non-compatible change and the change does
   affect your client.

b) The semver indicates an non-compatible change but the change does not
   affect your client.

c) The semver indicates no non-compatible change and your client happily
   continues to work.

d) The semver indicates no non-compatible change but there is a change
   that does affect your client.

It seems semantic versioning focuses on a) and c) but b) and d) may
still happen in practice.

> > >     When upgrading a network node we might introduce non-backward compatible
> > >     (NBC) changes. Today we need to introduce a new module for this. That
> > >     means during the upgrade process the node must convert stored
> > >     configuration instance data from ietf-routing to ietf-routing-2 format.
> > >     Instead of solving this data transformation/transfer problem just for a
> > >     few NBC data nodes, we will have to do it for the full model. This is
> > >     complicated. In many cases the transformation of a few NBC leafs can be
> > >     handled by good defaults or with a small script. Transferring the full
> > >     data set is more complicated. If we allow NBC updates in some cases this
> > >     problem is avoided.
> > In XML land, this is mostly a change of the namespace (not of the
> > prefix) if one keeps the same structure, no? In JSON land, the change
> > of the module name more directly becomes visible in instance data; but
> > this is all encoding details.
> BALAZS: Even in XMLland we store the prefix as part of any leaf with type
> instance-identifier or identityref and potentially CLI scripts.

Which is risky since in principle there is no guarantee that the prefix
always remains the same.
 
> > >     If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
> > >     the prefix?
> > I guess you mean the namespace, not the prefix. You can use any prefix
> > you like.
> BALAZS: No, I mean the prefix. Prefix is part of the instance data (see
> above), potentially part of CLI scripts etc. It is also part of human
> communication. In email we never refer to
> urn:ietf:params:xml:ns:yang:ietf-yang-library:/modules-state instead we just
> write yanglib:/modules/state.

See above.

> > >     In one sense it should be kept as it is the same module
> > >     "logically"; we also might have stored data including the prefix
> > >     (identityrefs, instance-identifiers). On the other hand having multiple
> > >     modules with the same prefix is a problem. The only good solution is to
> > >     allow incompatible updates in some cases.
> > If we move towards allowing incompabile updates, then we need to have
> > a mechanism to tell which versions of modules can work together and
> > which combinations are affected by an incompatible update. We probably
> > need to require strict import by revision or at least 'import by
> > compatible revision' (whatever this means at the end).
> BALAZS: We already have this problem today. We allow incompatible updates
> for deprecated/obsolete. When you import a module, the importing module will
> not check for status statements. For "augment" or "must" referencing a
> deprecated and thus removed part will already today cause problems.

There is in general a difference between the status of a definition
and which objects are implemented and which objects are accessible.

> > >     CH 1)
> > > 
> > >     You write
> > >     "The YANG data modeling language [RFC7950] specifies strict rules for
> > >     updating..."
> > >     and again
> > >     "When the same YANG module name is kept, the new YANG module  revision
> > >     must always be updated in a backward-compatible way."
> > > 
> > >     I strongly disagree. While we have strict rules about even small
> > >     modifications to existing schema, but you are allowed to
> > >     deprecate/obsolete big parts of the model, thereby possibly deleting
> > >     complete subtrees from the schema. That is anything but strict backward
> > >     compatibility.
> > >     I find this aspect of YANG inconsistent to the level that it would need an
> > >     errata.
> > Marking something deprecated / obsolete means you can not be sure this
> > is implemented. But then, even definitions with status current may not
> > be implemented (see deviations) or they may not be accessible to a
> > client due to access control. However, if implemented and accessible,
> > the guarantee today is that the semantics stay the same and don't
> > change unexpectedly.
> BALAZS: Access control can be set by the operator, deviations are at least
> viewable, checkable in design time. However something (possibly) removed due
> to status just disappears. In my view the current status deprecated is
> similar to deviation not-supported .

The status is known at compile time. Deviations are known at run-time,
not at design-time.

> > >     So practically the current rules allow backward incompatible changes that
> > >     can only be detected by a line by line comparison of the yang modules. In
> > >     a system with semantic versioning, you could determine backward
> > >     compatibility just by reading the version numbers.
> > I do not see why you need a line by line comparison. With semantic
> > versioning, you _hope_ the semantic version number is a good enough
> > indicator. It might also be that your client is only using a subset
> > that did not really change even though the semantic version number
> > changed. Or the semantic version number indicates only minor changes
> > that sill break your client.
> BALAZS: Line by line comparison is needed, because today anywhere in the
> model you might find a new status deprecated statement. You are forced to do
> the line by line comparison and even that is no guarantee of compatibility
> due to behavior changes.
> Yes you might set the semantic version incorrectly, but that's a bug. You
> might use other parts of YANG incorrectly too.

Semantic versioning gives you a hint, it does not tell for sure your
client fails not does it tell for sure your client will continue to
work.

> > >     CH 2.3)
> > >     As we need to create a new Yang Module (YAM) even for the smallest
> > >     incompatible modification, this increases the number of modules.
> > So it seems to boil down to the question whether foo and foo2 is
> > significantly more expensive than foo { semver 1.x.y } and foo {
> > semver 2.x.y }. The main argument seems to be that the later keeps
> > references that involve module names or namespaces unchanged (but
> > they may or may not mean different things).
> BALAZS: For SMALL NBC changes, I propose to keep the original module name.
> Now while agree it is possible to misuse this, and that SMALL is subjective,
> however we already have this situation. Removing stuff by deprecation is not
> much better then just deleting the same.
> In ericsson our internal definition of deprecation follows what e.g. JAVA
> does:
> "Deprecated schema nodes MUST still work as defined by the YAM. The
> deprecated status serves only as a a warning that the schema node will be
> removed or obsoleted in the future."
> This allows continued compatible usage while still warning the client, that
> the marked parts will go away soon.

The difference is that Java releases are published regularly but IETF
published modules likely won't be republished to go from deprecated to
obsolete. The deprecated status leaves it to implementors to decide
whether they remove something. And implementors usually have little
interest to break clients.

> > >     IMHO YANG package definition should be a separate issue, left out of this
> > >     document. Andy has already provided some very good ideas about this topic.
> > I think it is necessary to think about how the semantic version
> > numbers are used. See my remark above about imports. If we allow
> > incompatible changes, than this has side effects and I think we are
> > not done by just adding a semantic version number without going
> > working throught the implications.
> BALAZS: I don't object, although I would prefer to handle them separately.
> I do object to the word "if". Due to YANG's current rules for status we
> already allow incompatible changes.

/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 Nov 14 22:19: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 782A71294FF for ; Tue, 14 Nov 2017 22:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ys1KsqxRukOY for ; Tue, 14 Nov 2017 22:19:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 733B31294AB for ; Tue, 14 Nov 2017 22:19:47 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C09E1AE0311; Wed, 15 Nov 2017 07:19:45 +0100 (CET)
Date: Wed, 15 Nov 2017 07:19:44 +0100 (CET)
Message-Id: <20171115.071944.118686339998444147.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <14b6c48a-3d59-6d71-fff3-c034db085227@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] ietf-yang-library edit
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 06:19:49 -0000

Hi,

I agree w/ Balazs and Robert.

> The entire reason for import-by-revision is to make sure that
> the importing module can safely use definitions that have been added after
> the first revision of the imported module.

I don't think this is correct; the reason for import-by-revision is to
protect against a newver revision being used.


/martin


> 
> 
> Andy
> 
> 
> 
> On Tue, Nov 14, 2017 at 9:04 PM, Robert Wilton  wrote:
> 
> >
> >
> > On 15/11/2017 12:48, Balazs Lengyel wrote:
> >
> > Hello,
> >
> > I though our strategy was to always use the latest revision available. At
> > least till now that works for me.
> >
> > Yes, I'm not convinced that the import by revision is really that helpful
> > since it states that it must pull in exactly that version, but really the
> > dependency is "at least version X, assuming newer revisions are backwards
> > compatible".
> >
> > E.g. if/when ietf-yang-types is updated again, it would be cleaner/simpler
> > if the server could just use the latest version rather than having to
> > potentially import multiple revisions.
> >
> > Thanks,
> > Rob
> >
> >
> > regards Balazs
> >
> > On 2017-11-15 10:33, Andy Bierman wrote:
> >
> > Hi,
> >
> > The ietf-yang-library module relies on "yang-identifier", which was added
> > to the 2nd
> > version of the ietf-yang-types. It does not compile unless that version is
> > used.
> >
> >
> > OLD:
> >
> >     import ietf-yang-types {
> >         prefix yang;
> >     }
> >
> >
> > NEW:
> >
> >     import ietf-yang-types {
> >         prefix yang;
> >         revision-date "2013-07-15";
> >         reference "RFC 6991: Common YANG Data Types";
> >     }
> >
> >
> > There are other modules such as ietf-ip that rely on RFC 6991 additions
> > and the import-stmt (in every case) should be changed to specify the
> > required revision-date.
> >
> >
> > Andy
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> >
> >
> >
> > _______________________________________________
> > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >


From nobody Tue Nov 14 22:22: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 D045B12702E for ; Tue, 14 Nov 2017 22:22:09 -0800 (PST)
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 nBI4JOJYkypx for ; Tue, 14 Nov 2017 22:22:08 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124081201FA for ; Tue, 14 Nov 2017 22:22:08 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id A859C63FFC for ; Wed, 15 Nov 2017 07:22:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510726926; bh=HwnAdukD8wJNl+OxovN8biD0yEcsIuisisjlCY+NOa0=; h=From:To:Date; b=QX/FFLOgur35PFjkS5RhGd4eIYvbsy2/00DVJEfJyYLwFq0BFtYfKYhAcb6u1HWcE GcfdmyJRquLvnN6ecTP9WqnIGSFOUwaL1LqyKJ02V2v4lZR/KUYP53OLgH8K8g6+6/ yLUIMxL84tt+/5bPQUBpJKpMzpNjLPuxWvlsbc9c=
Message-ID: <1510726990.12151.10.camel@nic.cz>
From: Ladislav Lhotka 
To: NETMOD WG 
Date: Wed, 15 Nov 2017 14:23:10 +0800
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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: [netmod] document organization
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 06:22:10 -0000

Hi,

regarding my proposed reorganization of documents: I strongly disagree with
Martin's comment on jabber that it would be a mere split of the contents into
two documents. It is certainly not true because

- we could get rid of the use-schema/inline choice in schema-mounts data: the
inline case needs to state data in the parent tree at all

- there are many CLRs that are relevant only to one of the methods, so have to
distinguish the cases in the text; for example, parent-references don't apply to
"inline"

- (most important for me) the two methods are really two different mechanisms,
and the "inline" method invites various instance-related considerations whereas
"use-schema" doesn't; it's been my experience that people keep confusing schema
construction and instance data mounting.

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


From nobody Tue Nov 14 22:24: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 B33DC1293EB for ; Tue, 14 Nov 2017 22:24:38 -0800 (PST)
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 vHmqYmCnFPxJ for ; Tue, 14 Nov 2017 22:24:37 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9390F1243F6 for ; Tue, 14 Nov 2017 22:24:37 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id A999A64008 for ; Wed, 15 Nov 2017 07:24:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510727076; bh=dYu5Ax+ub9V9xEUz6GrD6MalPtx1ZDIGhEvOb8fAKGY=; h=From:To:Date; b=fL3HMZft4r8C7QDjFmJtdgwNw3uacomToaFxeDlkA8++n/0DD+X5yuYSnM7NaSQ2D UMHJXiNdklXPfT0JVoj7CRnpv3Rvz0/ANND7ucJc0TPybRSmyQW3sV74S+d5r/r/oC tymw/kRCBPQ8xWiBebwiOkOx8R2ufr6q+QHajAtE=
Message-ID: <1510727142.12151.11.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 15 Nov 2017 14:25:42 +0800
In-Reply-To: <1510726990.12151.10.camel@nic.cz>
References: <1510726990.12151.10.camel@nic.cz>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] document organization
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 06:24:39 -0000

On Wed, 2017-11-15 at 14:23 +0800, Ladislav Lhotka wrote:
> Hi,
> 
> regarding my proposed reorganization of documents: I strongly disagree with
> Martin's comment on jabber that it would be a mere split of the contents into
> two documents. It is certainly not true because
> 
> - we could get rid of the use-schema/inline choice in schema-mounts data: the
> inline case needs to state data in the parent tree at all

Sorry, I meant "no state data" here.

Lada

> 
> - there are many CLRs that are relevant only to one of the methods, so have to
> distinguish the cases in the text; for example, parent-references don't apply to
> "inline"
> 
> - (most important for me) the two methods are really two different mechanisms,
> and the "inline" method invites various instance-related considerations whereas
> "use-schema" doesn't; it's been my experience that people keep confusing schema
> construction and instance data mounting.
> 
> Lada
>    
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Nov 14 23:00: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 D6F5412951F for ; Tue, 14 Nov 2017 23:00:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q06NWNQWlyh for ; Tue, 14 Nov 2017 23:00:31 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8B1270A0 for ; Tue, 14 Nov 2017 23:00:31 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 945691AE0311; Wed, 15 Nov 2017 08:00:29 +0100 (CET)
Date: Wed, 15 Nov 2017 08:00:29 +0100 (CET)
Message-Id: <20171115.080029.1828084423046734849.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <66e88c5b-41fc-7607-e1a9-ebe76eded836@ericsson.com>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <66e88c5b-41fc-7607-e1a9-ebe76eded836@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] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 07:00:34 -0000

Balazs Lengyel  wrote:
> See bellow!
> 
> 
> On 2017-11-15 05:22, Juergen Schoenwaelder wrote:
> > In XML land, this is mostly a change of the namespace (not of the
> > prefix) if one keeps the same structure, no? In JSON land, the change
> > of the module name more directly becomes visible in instance data; but
> > this is all encoding details.
> BALAZS: Even in XMLland we store the prefix as part of any leaf with
> type instance-identifier or identityref and potentially CLI scripts.

This would be a broken implementation.  Since the prefix might change
you cannot store them as is.  You have to translate the prefix to
namespace/module name, and store that.

That said, this encoding rule is really unfortunate.  We fixed it in
the JSON encoding, and I wish we had the same in XML...


/martin


From nobody Tue Nov 14 23: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 DC60E12947C for ; Tue, 14 Nov 2017 23:12:00 -0800 (PST)
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 O4hjpIUc40i7 for ; Tue, 14 Nov 2017 23:11:57 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BAC127B60 for ; Tue, 14 Nov 2017 23:11:56 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id 8A26663FC6 for ; Wed, 15 Nov 2017 08:11:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510729914; bh=5gMd5Yw//mZBMEB/LK1v5oQBjVLkkcEyAuXtUjsY5h4=; h=From:To:Date; b=iTrazygyPcgvg5pU1evokQ3nUQQRzLWwZx039di8XayWZeWvF3ByeS+R5QLSBZt5S nX1iyy022GibFWQUHvxIrM49VY7taYyP4n/JIh2UQgrwOzdLXzwY835dxglx8Feok2 Vv4PKpr6jsP5dT/sO12QtqP+XPr0QjTbAkIxQxFU=
Message-ID: <1510729980.12151.17.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 15 Nov 2017 15:13:00 +0800
In-Reply-To: <20171115.080029.1828084423046734849.mbj@tail-f.com>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <66e88c5b-41fc-7607-e1a9-ebe76eded836@ericsson.com> <20171115.080029.1828084423046734849.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 07:12:01 -0000

On Wed, 2017-11-15 at 08:00 +0100, Martin Bjorklund wrote:
> Balazs Lengyel  wrote:
> > See bellow!
> > 
> > 
> > On 2017-11-15 05:22, Juergen Schoenwaelder wrote:
> > > In XML land, this is mostly a change of the namespace (not of the
> > > prefix) if one keeps the same structure, no? In JSON land, the change
> > > of the module name more directly becomes visible in instance data; but
> > > this is all encoding details.
> > 
> > BALAZS: Even in XMLland we store the prefix as part of any leaf with
> > type instance-identifier or identityref and potentially CLI scripts.
> 
> This would be a broken implementation.  Since the prefix might change
> you cannot store them as is.  You have to translate the prefix to
> namespace/module name, and store that.

I agree. In XML land, there was a lot of software that relied on specific
prefixes, and it turned out to be a big problem.

> 
> That said, this encoding rule is really unfortunate.  We fixed it in
> the JSON encoding, and I wish we had the same in XML...

Prefixes still give you some flexibility, for example the ability to import two
different revisions of the same module.

Lada

> 
> 
> /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 Tue Nov 14 23:24: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 0E70F129426 for ; Tue, 14 Nov 2017 23:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvsCPg_UTjZq for ; Tue, 14 Nov 2017 23:24:26 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB1171270A0 for ; Tue, 14 Nov 2017 23:24:25 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 200781AE0311; Wed, 15 Nov 2017 08:24:25 +0100 (CET)
Date: Wed, 15 Nov 2017 08:24:24 +0100 (CET)
Message-Id: <20171115.082424.47357575757430906.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1510729980.12151.17.camel@nic.cz>
References: <66e88c5b-41fc-7607-e1a9-ebe76eded836@ericsson.com> <20171115.080029.1828084423046734849.mbj@tail-f.com> <1510729980.12151.17.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 07:24:27 -0000

Ladislav Lhotka  wrote:
> On Wed, 2017-11-15 at 08:00 +0100, Martin Bjorklund wrote:
> > Balazs Lengyel  wrote:
> > > See bellow!
> > > 
> > > 
> > > On 2017-11-15 05:22, Juergen Schoenwaelder wrote:
> > > > In XML land, this is mostly a change of the namespace (not of the
> > > > prefix) if one keeps the same structure, no? In JSON land, the change
> > > > of the module name more directly becomes visible in instance data; but
> > > > this is all encoding details.
> > > 
> > > BALAZS: Even in XMLland we store the prefix as part of any leaf with
> > > type instance-identifier or identityref and potentially CLI scripts.
> > 
> > This would be a broken implementation.  Since the prefix might change
> > you cannot store them as is.  You have to translate the prefix to
> > namespace/module name, and store that.
> 
> I agree. In XML land, there was a lot of software that relied on specific
> prefixes, and it turned out to be a big problem.
> 
> > 
> > That said, this encoding rule is really unfortunate.  We fixed it in
> > the JSON encoding, and I wish we had the same in XML...
> 
> Prefixes still give you some flexibility, for example the ability to import two
> different revisions of the same module.

Sure, but that's not reflected in the encoding on-the-wire.


/martin


From nobody Tue Nov 14 23:45: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 980B0129553 for ; Tue, 14 Nov 2017 23:45:55 -0800 (PST)
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 2RpdfG-ahWcY for ; Tue, 14 Nov 2017 23:45:52 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99905127444 for ; Tue, 14 Nov 2017 23:45:52 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:370:128:e0e6:7446:b50f:deb9]) by mail.nic.cz (Postfix) with ESMTPSA id 1B33B64007 for ; Wed, 15 Nov 2017 08:45:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510731950; bh=yZpVBHVtH8mqds++fry87kf7v7ibwdGOUyfakUTenOQ=; h=From:To:Date; b=NZI36H/BLTkjSQ2ZRk51gZWnSsgRVj7w1Yl3G72d1Uf3DSAp5c16Ud+egBceQ1rU0 2phyzgH4i0kvjo+obATjN0NDpPRtdgjbrVULEwDmuHaB3uRi1zbE+2Y4XnMWZ7DxIZ a0CPvneM6SRs2dz8OGw25MtkyeaHDPl27xQ8c8ag=
Message-ID: <1510732017.12151.27.camel@nic.cz>
From: Ladislav Lhotka 
To: NETMOD WG 
Date: Wed, 15 Nov 2017 15:46:57 +0800
In-Reply-To: <20171115.082424.47357575757430906.mbj@tail-f.com>
References: <66e88c5b-41fc-7607-e1a9-ebe76eded836@ericsson.com> <20171115.080029.1828084423046734849.mbj@tail-f.com> <1510729980.12151.17.camel@nic.cz> <20171115.082424.47357575757430906.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 07:45:56 -0000

On Wed, 2017-11-15 at 08:24 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Wed, 2017-11-15 at 08:00 +0100, Martin Bjorklund wrote:
> > > Balazs Lengyel  wrote:
> > > > See bellow!
> > > > 
> > > > 
> > > > On 2017-11-15 05:22, Juergen Schoenwaelder wrote:
> > > > > In XML land, this is mostly a change of the namespace (not of the
> > > > > prefix) if one keeps the same structure, no? In JSON land, the change
> > > > > of the module name more directly becomes visible in instance data; but
> > > > > this is all encoding details.
> > > > 
> > > > BALAZS: Even in XMLland we store the prefix as part of any leaf with
> > > > type instance-identifier or identityref and potentially CLI scripts.
> > > 
> > > This would be a broken implementation.  Since the prefix might change
> > > you cannot store them as is.  You have to translate the prefix to
> > > namespace/module name, and store that.
> > 
> > I agree. In XML land, there was a lot of software that relied on specific
> > prefixes, and it turned out to be a big problem.
> > 
> > > 
> > > That said, this encoding rule is really unfortunate.  We fixed it in
> > > the JSON encoding, and I wish we had the same in XML...
> > 
> > Prefixes still give you some flexibility, for example the ability to import two
> > different revisions of the same module.
> 
> Sure, but that's not reflected in the encoding on-the-wire.

XML has its own rules, so unless tools take a specific prefix for granted,
everything should be OK. One can also declare full module names as NS prefixes
in XML encoding to make it closer to JSON encoding.

The only minor problem is the paragraph in sec. 7.1.4 of RFC 7950 stating that
XML and XPath SHOULD use the prefix defined in YANG. IMO, this should be removed
(but, after all, it is only a SHOULD).

Lada

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


From nobody Wed Nov 15 00:44: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 A27401279EB for ; Wed, 15 Nov 2017 00:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0kWxWev5bNRK for ; Wed, 15 Nov 2017 00:44:44 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4451200C1 for ; Wed, 15 Nov 2017 00:44:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7940; q=dns/txt; s=iport; t=1510735484; x=1511945084; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=W+Y39ru0UtR5iy/T0FHDuVoZAyM2HkLgJN0sRx8Rllo=; b=BdGUjRyLt/LrcQH4061m0RKGoZ2yWRzvcIrpyqpDJncFCe75J9idI0Ky KZjSb+SU0OP3txGIL0QGUWyOaf/oZbCPibtnf0umaO3rmh7mbRjYXIE// Ucy7IgET5dMDAXKGLmCtS6wnEVgvTnrX++CXM6zkHjxgy2/GEs18BT3dF 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAAD1/Qta/49dJa1RCQMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgzZkboQmih+PIoF9llqCEQofhRwChQU/GAEBAQEBAQEBAWs?= =?us-ascii?q?ohR8BBR0GDwFUAgsQCAICJgICGzwQAwgBAReKCapZgieLGAEBAQEGAQEBASQFg?= =?us-ascii?q?QqCJYIHgVWCEoMBhFgBKQkuJoJOgmMFkXABgRSPMpUGghWJaodFijKLe4E5Hzi?= =?us-ascii?q?BdFUlFYMuCIJTHIIFI4ZVgkIBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="318972414"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 08:44:29 +0000
Received: from [10.24.101.203] ([10.24.101.203]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAF8iRrx022603 for ; Wed, 15 Nov 2017 08:44:27 GMT
To: netmod@ietf.org
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local>
From: Joe Clarke 
Organization: Cisco
Message-ID: <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com>
Date: Wed, 15 Nov 2017 03:44:26 -0500
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: <20171115053046.nr33ypoibdn4jufv@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 08:44:45 -0000

On 11/15/17 00:30, Juergen Schoenwaelder wrote:
> Another thing to consider is that foo and foo2 allows an
> implementation to support both during transition, with foo {semver
> 1.x.y} and foo {semver 2.x.y} this may be harder.

I'm not convinced this a bad thing.  If a server supports multiple
versions of a given module, which should a client use?  Did the server
vendor test each one?

I suppose my gut reaction to Lou's question as to whether a server
should support multiple versions was, "no."  A client may have multiple
versions loaded to support servers that support different versions.  I
may be convinced otherwise, but I feel that this will become untenable
over time (even if module names change).

Joe

> 
> /js
> 
> On Tue, Nov 14, 2017 at 10:22:10PM +0100, Juergen Schoenwaelder wrote:
>> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
>>>    Whenever a client OSS implements some higher level logic for a network
>>>    function, something that can not be implemented in a purely model driven
>>>    way, it is always dependent on a specific version of the Yang Module
>>>    (YAM). If the client finds that the module has been updated on the network
>>>    node, it has to decide if it tries to handle it as it did the previous
>>>    version of the model or if it just stops to avoid problems. To make this
>>>    decision the client needs to know if the module was updated in a backward
>>>    compatible way or not. This is not addressed with the current versioning.
>>
>> The current rules aim at guaranteeing that definitions (with status
>> current) remain backwards compatible. Do you have an example what the
>> current rules fail to achieve this? Definitions with status deprecated
>> or obsolete may not be present. But if they are present, they have the
>> same semantics. This is the promise made to a client. (Note also that
>> objects may be absent for reasons document in deviations or simply not
>> accessible due to access control.)
>>
>>>    While having PYANG based checks for backward compatibility is a very good
>>>    idea, a  comparison based check will never be a complete check. It is
>>>    quite possible to change just the behavior of an rpc/action/etc.  without
>>>    changing the YANG definition.  This will only show up as a change of the
>>>    description statement that can not be analyzed by PYANG.
>>
>> The problem is to decide whether a change can break client
>> expectations or not. Even 'bug fixes' can cause a client written to
>> expect the old 'buggy' behaviour to fail. Also tricky are situations
>> where behaviour was not clearly enough described and this is 'fixed'
>> in a module update.
>>
>> Semantic versioning assumes that one always can clearly distinguish
>> between incompatible updates and compatible updates. This may not be
>> so clearly cut in practice, see above. (But then, we have the same
>> judgement call at the end with today's update rules.)
>>
>>>    When upgrading a network node we might introduce non-backward compatible
>>>    (NBC) changes. Today we need to introduce a new module for this. That
>>>    means during the upgrade process the node must convert stored
>>>    configuration instance data from ietf-routing to ietf-routing-2 format.
>>>    Instead of solving this data transformation/transfer problem just for a
>>>    few NBC data nodes, we will have to do it for the full model. This is
>>>    complicated. In many cases the transformation of a few NBC leafs can be
>>>    handled by good defaults or with a small script. Transferring the full
>>>    data set is more complicated. If we allow NBC updates in some cases this
>>>    problem is avoided.
>>
>> In XML land, this is mostly a change of the namespace (not of the
>> prefix) if one keeps the same structure, no? In JSON land, the change
>> of the module name more directly becomes visible in instance data; but
>> this is all encoding details.
>>
>>>    If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
>>>    the prefix?
>>
>> I guess you mean the namespace, not the prefix. You can use any prefix
>> you like.
>>
>>>    In one sense it should be kept as it is the same module
>>>    "logically"; we also might have stored data including the prefix
>>>    (identityrefs, instance-identifiers). On the other hand having multiple
>>>    modules with the same prefix is a problem. The only good solution is to
>>>    allow incompatible updates in some cases.
>>
>> If we move towards allowing incompabile updates, then we need to have
>> a mechanism to tell which versions of modules can work together and
>> which combinations are affected by an incompatible update. We probably
>> need to require strict import by revision or at least 'import by
>> compatible revision' (whatever this means at the end).
>>
>>>    CH 1)
>>>
>>>    You write
>>>    "The YANG data modeling language [RFC7950] specifies strict rules for
>>>    updating..."
>>>    and again
>>>    "When the same YANG module name is kept, the new YANG module  revision
>>>    must always be updated in a backward-compatible way."
>>>
>>>    I strongly disagree. While we have strict rules about even small
>>>    modifications to existing schema, but you are allowed to
>>>    deprecate/obsolete big parts of the model, thereby possibly deleting
>>>    complete subtrees from the schema. That is anything but strict backward
>>>    compatibility.
>>>    I find this aspect of YANG inconsistent to the level that it would need an
>>>    errata.
>>
>> Marking something deprecated / obsolete means you can not be sure this
>> is implemented. But then, even definitions with status current may not
>> be implemented (see deviations) or they may not be accessible to a
>> client due to access control. However, if implemented and accessible,
>> the guarantee today is that the semantics stay the same and don't
>> change unexpectedly.
>>
>>>    So practically the current rules allow backward incompatible changes that
>>>    can only be detected by a line by line comparison of the yang modules. In
>>>    a system with semantic versioning, you could determine backward
>>>    compatibility just by reading the version numbers.
>>
>> I do not see why you need a line by line comparison. With semantic
>> versioning, you _hope_ the semantic version number is a good enough
>> indicator. It might also be that your client is only using a subset
>> that did not really change even though the semantic version number
>> changed. Or the semantic version number indicates only minor changes
>> that sill break your client.
>>
>>>    CH 2.3)
>>>    As we need to create a new Yang Module (YAM) even for the smallest
>>>    incompatible modification, this increases the number of modules.
>>
>> So it seems to boil down to the question whether foo and foo2 is
>> significantly more expensive than foo { semver 1.x.y } and foo {
>> semver 2.x.y }. The main argument seems to be that the later keeps
>> references that involve module names or namespaces unchanged (but
>> they may or may not mean different things).
>>
>>>    IMHO YANG package definition should be a separate issue, left out of this
>>>    document. Andy has already provided some very good ideas about this topic.
>>
>> I think it is necessary to think about how the semantic version
>> numbers are used. See my remark above about imports. If we allow
>> incompatible changes, than this has side effects and I think we are
>> not done by just adding a semantic version number without going
>> working throught the implications.
>>
>> /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 Nov 15 00:53: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 156F812947E for ; Wed, 15 Nov 2017 00:53:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z8NfX6be6cS for ; Wed, 15 Nov 2017 00:53:42 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7187129474 for ; Wed, 15 Nov 2017 00:53:42 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id E0DC21AE0311; Wed, 15 Nov 2017 09:53:41 +0100 (CET)
Date: Wed, 15 Nov 2017 09:53:41 +0100 (CET)
Message-Id: <20171115.095341.1585161898755400575.mbj@tail-f.com>
To: jclarke@cisco.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com>
References: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@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] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 08:53:45 -0000

Joe Clarke  wrote:
> On 11/15/17 00:30, Juergen Schoenwaelder wrote:
> > Another thing to consider is that foo and foo2 allows an
> > implementation to support both during transition, with foo {semver
> > 1.x.y} and foo {semver 2.x.y} this may be harder.
> 
> I'm not convinced this a bad thing.  If a server supports multiple
> versions of a given module, which should a client use?  Did the server
> vendor test each one?
> 
> I suppose my gut reaction to Lou's question as to whether a server
> should support multiple versions was, "no."

Exactly.  With the current solution, the sever can still implement the
deprecated or obsolete nodes in order to support old clients.

With a MAJOR update in a semver world, it means that the old nodes are
removed (or rather, possibly, that the old nodes have new syntax
and/or semantics).


> A client may have multiple
> versions loaded to support servers that support different versions.  I
> may be convinced otherwise, but I feel that this will become untenable
> over time (even if module names change).

I think the proposed solution will make it even harder for clients,
since the same paths will mean very different things on different
servers.


/martin


> 
> Joe
> 
> > 
> > /js
> > 
> > On Tue, Nov 14, 2017 at 10:22:10PM +0100, Juergen Schoenwaelder wrote:
> >> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
> >>>    Whenever a client OSS implements some higher level logic for a network
> >>>    function, something that can not be implemented in a purely model driven
> >>>    way, it is always dependent on a specific version of the Yang Module
> >>>    (YAM). If the client finds that the module has been updated on the network
> >>>    node, it has to decide if it tries to handle it as it did the previous
> >>>    version of the model or if it just stops to avoid problems. To make this
> >>>    decision the client needs to know if the module was updated in a backward
> >>>    compatible way or not. This is not addressed with the current versioning.
> >>
> >> The current rules aim at guaranteeing that definitions (with status
> >> current) remain backwards compatible. Do you have an example what the
> >> current rules fail to achieve this? Definitions with status deprecated
> >> or obsolete may not be present. But if they are present, they have the
> >> same semantics. This is the promise made to a client. (Note also that
> >> objects may be absent for reasons document in deviations or simply not
> >> accessible due to access control.)
> >>
> >>>    While having PYANG based checks for backward compatibility is a very good
> >>>    idea, a  comparison based check will never be a complete check. It is
> >>>    quite possible to change just the behavior of an rpc/action/etc.  without
> >>>    changing the YANG definition.  This will only show up as a change of the
> >>>    description statement that can not be analyzed by PYANG.
> >>
> >> The problem is to decide whether a change can break client
> >> expectations or not. Even 'bug fixes' can cause a client written to
> >> expect the old 'buggy' behaviour to fail. Also tricky are situations
> >> where behaviour was not clearly enough described and this is 'fixed'
> >> in a module update.
> >>
> >> Semantic versioning assumes that one always can clearly distinguish
> >> between incompatible updates and compatible updates. This may not be
> >> so clearly cut in practice, see above. (But then, we have the same
> >> judgement call at the end with today's update rules.)
> >>
> >>>    When upgrading a network node we might introduce non-backward compatible
> >>>    (NBC) changes. Today we need to introduce a new module for this. That
> >>>    means during the upgrade process the node must convert stored
> >>>    configuration instance data from ietf-routing to ietf-routing-2 format.
> >>>    Instead of solving this data transformation/transfer problem just for a
> >>>    few NBC data nodes, we will have to do it for the full model. This is
> >>>    complicated. In many cases the transformation of a few NBC leafs can be
> >>>    handled by good defaults or with a small script. Transferring the full
> >>>    data set is more complicated. If we allow NBC updates in some cases this
> >>>    problem is avoided.
> >>
> >> In XML land, this is mostly a change of the namespace (not of the
> >> prefix) if one keeps the same structure, no? In JSON land, the change
> >> of the module name more directly becomes visible in instance data; but
> >> this is all encoding details.
> >>
> >>>    If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
> >>>    the prefix?
> >>
> >> I guess you mean the namespace, not the prefix. You can use any prefix
> >> you like.
> >>
> >>>    In one sense it should be kept as it is the same module
> >>>    "logically"; we also might have stored data including the prefix
> >>>    (identityrefs, instance-identifiers). On the other hand having multiple
> >>>    modules with the same prefix is a problem. The only good solution is to
> >>>    allow incompatible updates in some cases.
> >>
> >> If we move towards allowing incompabile updates, then we need to have
> >> a mechanism to tell which versions of modules can work together and
> >> which combinations are affected by an incompatible update. We probably
> >> need to require strict import by revision or at least 'import by
> >> compatible revision' (whatever this means at the end).
> >>
> >>>    CH 1)
> >>>
> >>>    You write
> >>>    "The YANG data modeling language [RFC7950] specifies strict rules for
> >>>    updating..."
> >>>    and again
> >>>    "When the same YANG module name is kept, the new YANG module  revision
> >>>    must always be updated in a backward-compatible way."
> >>>
> >>>    I strongly disagree. While we have strict rules about even small
> >>>    modifications to existing schema, but you are allowed to
> >>>    deprecate/obsolete big parts of the model, thereby possibly deleting
> >>>    complete subtrees from the schema. That is anything but strict backward
> >>>    compatibility.
> >>>    I find this aspect of YANG inconsistent to the level that it would need an
> >>>    errata.
> >>
> >> Marking something deprecated / obsolete means you can not be sure this
> >> is implemented. But then, even definitions with status current may not
> >> be implemented (see deviations) or they may not be accessible to a
> >> client due to access control. However, if implemented and accessible,
> >> the guarantee today is that the semantics stay the same and don't
> >> change unexpectedly.
> >>
> >>>    So practically the current rules allow backward incompatible changes that
> >>>    can only be detected by a line by line comparison of the yang modules. In
> >>>    a system with semantic versioning, you could determine backward
> >>>    compatibility just by reading the version numbers.
> >>
> >> I do not see why you need a line by line comparison. With semantic
> >> versioning, you _hope_ the semantic version number is a good enough
> >> indicator. It might also be that your client is only using a subset
> >> that did not really change even though the semantic version number
> >> changed. Or the semantic version number indicates only minor changes
> >> that sill break your client.
> >>
> >>>    CH 2.3)
> >>>    As we need to create a new Yang Module (YAM) even for the smallest
> >>>    incompatible modification, this increases the number of modules.
> >>
> >> So it seems to boil down to the question whether foo and foo2 is
> >> significantly more expensive than foo { semver 1.x.y } and foo {
> >> semver 2.x.y }. The main argument seems to be that the later keeps
> >> references that involve module names or namespaces unchanged (but
> >> they may or may not mean different things).
> >>
> >>>    IMHO YANG package definition should be a separate issue, left out of this
> >>>    document. Andy has already provided some very good ideas about this topic.
> >>
> >> I think it is necessary to think about how the semantic version
> >> numbers are used. See my remark above about imports. If we allow
> >> incompatible changes, than this has side effects and I think we are
> >> not done by just adding a semantic version number without going
> >> working throught the implications.
> >>
> >> /js
> >>
> >> -- 
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103         
> > 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Nov 15 01:14: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 D2BF11287A7 for ; Wed, 15 Nov 2017 01:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 njJu5zcIdc5l for ; Wed, 15 Nov 2017 01:14:55 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE35126C0F for ; Wed, 15 Nov 2017 01:14:55 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 717961AE0311 for ; Wed, 15 Nov 2017 10:14:54 +0100 (CET)
Date: Wed, 15 Nov 2017 10:14:54 +0100 (CET)
Message-Id: <20171115.101454.1576716701146734257.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] tree diagram guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 09:14:57 -0000

Hi,

There was a proposal in the meeting today to have the guidelines for
tree diagrams in a wiki, instead of having them in 6087bis or in the
tree diagram document.

Was the proposal really to have a wiki for just the tree guidelines,
or was the proposal to withdraw 6087bis from the process and instead
publish all guidelines as a wiki?

If it is the former, is it really worth it?

Advantages with a wiki:

  +  It can be updated more easily

Some drawbacks:

  -  It can be updated more easily
     (meaning they are less stable)

  -  Wikis tend to not be alive after some time, and are not that
     easy to find.  Just try to find the various YANG-related wikis
     we've tried to maintain over the years.

  -  Links in RFCs also have problems.  Sites are re-orginized etc.
     As an example, the link to the security guidelines template in
     RFC 6087 doesn't work anymore.

  -  People that are looking for a stable reference will have problems
     (I think Rob mentioned that IEEE still refer to RFC 6087 (which
     is understandable; that's the published version).

  -  Who maintains the Wiki, and what are the rules for updating it?


I suggest we have the tree-related guidelines (actually just a few
sentences) in the tree draft, and since 6087bis already refers to this
document it is not a big problem that guidelines are spread out over
several documents that are difficult to find.



/martin


From nobody Wed Nov 15 01:42: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 95A28128DF3 for ; Wed, 15 Nov 2017 01:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsZswzdk7rQ7 for ; Wed, 15 Nov 2017 01:42:00 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3AC127337 for ; Wed, 15 Nov 2017 01:42:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 327261406929; Wed, 15 Nov 2017 10:41:58 +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 KUdxhkhVAWqU; Wed, 15 Nov 2017 10:41:58 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 04232140692B; Wed, 15 Nov 2017 10:41:58 +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 i3lC_un7Q6M5; Wed, 15 Nov 2017 10:41:57 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id D14A41406928; Wed, 15 Nov 2017 10:41:57 +0100 (CET)
To: Robert Wilton , "netmod@ietf.org" 
References:   <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>   <8584c894-473a-f268-29f0-20de225fa7c4@cisco.com>  
From: Vladimir Vassilev 
Message-ID: 
Date: Wed, 15 Nov 2017 10:41:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 09:42:05 -0000

On 11/15/2017 01:06 AM, Robert Wilton wrote:
>
>
> On 14/11/2017 23:41, Vladimir Vassilev wrote:
>>
>>
>> On 11/13/2017 04:27 PM, Robert Wilton wrote:
>>>
>>> Hi Vladimir,
>>>
>>>
>>> On 12/11/2017 10:39, Vladimir Vassilev wrote:
>>>>
>>>>
>>>>
>>>> On 11/11/2017 08:07 PM, Andy Bierman wrote:
>>>>>
>>>>>
>>>>> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton >>>> > wrote:
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 Hi Andy,
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 The NMDA datastore draft
>>>>> =C2=A0=C2=A0=C2=A0 (draft-ietf-netmod-revised-datastores-06) mandat=
es two
>>>>> =C2=A0=C2=A0=C2=A0 constraints that must apply:
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 (1) All conventional datastores must have exactl=
y the same
>>>>> =C2=A0=C2=A0=C2=A0 schema.=C2=A0 Hence differences in deviations or=
 features are allowed
>>>>> =C2=A0=C2=A0=C2=A0 between these datastores. (sec 5.1, first paragr=
aph)
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 (2) The schema for operational must be a superse=
t of all
>>>>> =C2=A0=C2=A0=C2=A0 configuration datatstores, but that data nodes m=
ay be omitted
>>>>> =C2=A0=C2=A0=C2=A0 (sec 5.3, third paragraph).
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 This implies that only the following differences=
 between
>>>>> =C2=A0=C2=A0=C2=A0 datastores are allowed:
>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0(i) a feature can be disabled in conventio=
nal (and/or dynamic
>>>>> =C2=A0=C2=A0=C2=A0 configuration datastores), but enabled in operat=
ional (e.g. for
>>>>> =C2=A0=C2=A0=C2=A0 configurable router-id).
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0(ii) deviations apply in all datastores, e=
xcept that
>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 a) a deviation can remove nodes in the co=
nventional datastores
>>>>> =C2=A0=C2=A0=C2=A0 (if they were not configurable, like the feature=
 example)
>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 b) a deviation can remove nodes in a dyna=
mic datastore (e.g.
>>>>> =C2=A0=C2=A0=C2=A0 like I2RS)
>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 c) a deviation can remove nodes from oper=
ational only if a
>>>>> =C2=A0=C2=A0=C2=A0 server is unable to accurately report them.
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 (iii) modules exist in all datastores, except:
>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 a) a module can be omitted from conventio=
nal datastores (e.g.
>>>>> =C2=A0=C2=A0=C2=A0 if the module is not configurable)
>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 b) a module can be omitted from a dynamic=
 datastore (e.g. like
>>>>> =C2=A0=C2=A0=C2=A0 I2RS)
>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 c) a module can be omitted from operation=
al only if a server
>>>>> =C2=A0=C2=A0=C2=A0 is unable to accurately report the data nodes wi=
thin the module.
>>>>>
>>>>>
>>>>>
>>>>> I am not convinced that moving to a datastore-centric conformance=20
>>>>> model instead of server-centric
>>>>> is a good idea.
>>>> +1
>>>> IMO yang-library:1.1 can and should be optional. As a first step=20
>>>> NMDA modules and the minimal protocol support  etc. can=20
>>>> be implemented without yang-library 1.0 to 1.1 transition (read=20
>>>> server-centric to datastore-centric conformance model transition).=20
>>>> draft-ietf-netconf-nmda-netconf-01.txt requires migration to=20
>>>> yang-library:1.1. I do not see good argument to support this=20
>>>> limitation and there are usecases that can benefit from NMDA with=20
>>>> uniform datastore model design.
>>>
>>> YANG library bis is the mechanism to indicate which datastores are=20
>>> available to the client.=C2=A0 E.g. a NMDA compatible client would=20
>>> attempt to read YANG library bis on the new path using the=20
>>>  RPC to determine whether NMDA is supported, and what=20
>>> datastores are supported.
>>>
>>> The existing module-state path in YANG library is preserved, but=20
>>> marked as deprecated, so the intention is that it can be made=20
>>> backwards compatible to clients.
>> I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library=20
>> Capability'=C2=A0 states exactly that. IMO this text can be changed an=
d=20
>> allow the case described above ( implementation with NMDA=20
>> modules implemented as indicated by yang-library:1.0 uniform model=20
>> applying to all datastores. For cases where the datastores do not=20
>> have common model yang-library:1.1 should still be mandatory). In=20
>> other words if yang-library:1.0 shows implemented=20
>> ietf-netconf-datastores  and NMDA modules listed as=20
>> implemented will not need yang-library:1.1 implementation which takes=20
>> one obstacle out of the way to rolling NMDA module implementations.
>>
>> Is there an argument making the proposed change unreasonable?
> Yes, I think so.
>
> In an NMDA implementation, the YANG library information reported in=20
> the new structure can be entirely accurate.=C2=A0 I.e. it can report wh=
ich=20
> modules are available in which datastores.
>
> Of course, it is not possible to represent this in the old YANG=20
> library, so the information that a NMDA server provides via the old=20
> YANG library could be inaccurate.=C2=A0 I.e. I think that it has to rep=
ort=20
> all modules and deviations as being reported in all datastores.
>
> Hence the only way that a client would be able to know that it is=20
> talking to an NMDA server with modules not implemented in some=20
> datastores, or with deviations in some datastores would be for it to=20
> query the new YANG library path.=C2=A0 The new YANG library structures =
that=20
> we are proposing below are intended to be easier for a client to=20
> determine this, e.g. by checking whether any of the=20
> "not-implemented-in" leaf-lists are populated.
>
> So the aim for keeping the old YANG library path is to inter-operate=20
> with old clients that don't know about NMDA, and hence would not be=20
> expected to use the  or  RPCs.
>
> Thanks,
> Rob
I still do not see an argument against supporting=C2=A0 NMDA modules with=
=20
yang-library:1.0 in the case when and only when there are no deviations=20
and the implemented module sets are exactly identical for all datastores.
>
>
>>
>> Vladimir
>>
>>>
>>> Thanks,
>>> Rob
>>>
>>>>> =C2=A0I get it that it is supposed to allow the server to accuratel=
y=20
>>>>> reflect its implementation,
>>>>> but it actually says that servers MAY implement whatever partial=20
>>>>> subset of a module they want,
>>>>> and a client MUST deal with the mess.
>>>>>
>>>>> IMO, YANG says that features and deviations are server-wide, not=20
>>>>> per-datastore.
>>>>> This new complexity is non-trivial to implement, so it may not be=20
>>>>> widely supported.
>>>>>
>>>>> The WG seems confused about the difference between a conformance=20
>>>>> model and capabilities reporting.
>>>>> (ii)(c) and (iii)(c) is about reporting, not conformance. There is=20
>>>>> still no way to express
>>>>> trivial use-cases in the conformance model such as "this module is=20
>>>>> intended for the I2RS ephemeral datastore only"
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 Changing the type of a node between datastores, =
or changing its
>>>>> =C2=A0=C2=A0=C2=A0 properties is not allowed.=C2=A0 The only differ=
ence allowed between
>>>>> =C2=A0=C2=A0=C2=A0 data nodes in different datastores is the nodes =
existence.
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 These rules seem more restrictive that what a se=
rver using split
>>>>> =C2=A0=C2=A0=C2=A0 config state trees (IETF style, or OpenConfig st=
yle) can achieve
>>>>> =C2=A0=C2=A0=C2=A0 using deviations today.
>>>>>
>>>>>
>>>>>
>>>>> Lots of rules to enforce actually makes the code harder, not easier=
.
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 Thanks,
>>>>> =C2=A0=C2=A0=C2=A0 Rob
>>>>>
>>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>> =C2=A0=C2=A0=C2=A0 On 09/11/2017 19:33, Andy Bierman wrote:
>>>>>> =C2=A0=C2=A0=C2=A0 Hi,
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0 The new structure still has the same problems f=
or the client as
>>>>>> =C2=A0=C2=A0=C2=A0 before.
>>>>>> =C2=A0=C2=A0=C2=A0 It is a major change in the architecture to hav=
e different
>>>>>> =C2=A0=C2=A0=C2=A0 schema trees per datastore instead of per-serve=
r.
>>>>>> =C2=A0=C2=A0=C2=A0 The server is allowed to have different feature=
s and deviations
>>>>>> =C2=A0=C2=A0=C2=A0 for the same objects.
>>>>>> =C2=A0=C2=A0=C2=A0 The client is completely on its own trying to c=
ompare
>>>>>> =C2=A0=C2=A0=C2=A0  to anything
>>>>>> =C2=A0=C2=A0=C2=A0 if the schema trees are different
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 container foo {
>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 leaf bar {
>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature X;
>>>>>> =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 leaf baz {
>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not X";
>>>>>> =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 How does the client compare  to  if the
>>>>>> =C2=A0=C2=A0=C2=A0 features do not match?
>>>>>> =C2=A0=C2=A0=C2=A0 If the server deviates the leaf (e.g. change ty=
pe string to
>>>>>> =C2=A0=C2=A0=C2=A0 int32) how does the client
>>>>>> =C2=A0=C2=A0=C2=A0 compare the values?
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0 This new complexity would be mandatory for the =
client to
>>>>>> =C2=A0=C2=A0=C2=A0 support in some proprietary
>>>>>> =C2=A0=C2=A0=C2=A0 manner since the NMDA standard ignores these pr=
oblems.
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0 NMDA was supposed to be simpler because the cli=
ent could
>>>>>> =C2=A0=C2=A0=C2=A0 compare intended
>>>>>> =C2=A0=C2=A0=C2=A0 and applied values using the same object path. =
openconfig
>>>>>> =C2=A0=C2=A0=C2=A0 required a data
>>>>>> =C2=A0=C2=A0=C2=A0 model change and a trivial name-mapping. In rea=
lity, NMDA
>>>>>> =C2=A0=C2=A0=C2=A0 is far more disruptive to existing implementati=
ons.
>>>>>>
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0 Andy
>>>>>>
>>>>>>
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0 On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton
>>>>>> =C2=A0=C2=A0=C2=A0 > =
wrote:
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi,
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Given some of the feedb=
ack related to the complexity of the
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 YANG library bis struct=
ure, we have come up with two other
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 possible structures for=
 the YANG library data:
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (1) A simplified struct=
ure to make YANG library meet the
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NMDA requirements, but =
that is closer to the existing YANG
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 library structure, and =
arguably simpler.
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (2) An enhanced version=
 of the structure (1) above, that is
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 also extended to allow =
the structure to be reused for
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schema-mount via an aug=
mentation.
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For reference, at the e=
nd of this email, I have also
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 included the tree diagr=
am of the existing YANG library, and
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the current YANG librar=
y bis draft
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (draft-ietf-netconf-rfc=
7895bis-02) version.
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Considering the two new=
 YANG library structures:
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----------------------=
-
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *(1) A simplified struc=
ture to make YANG library meet the
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NMDA requirements, but =
that is closer to the existing YANG
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 library structure.*
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The main changes are:
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (i) Split "implemented =
modules" and "import-only-modules"
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 into two separate lists=
, making the most important list
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (i.e. implemented modul=
es) keyed by module name only and
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hence easier to referen=
ce.
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (ii) Assume modules are=
 implemented in all datastores by
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default (with a "not-im=
plemented-in" leaflist of datastores
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a module is not im=
plemented in).
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (iii) Assume that featu=
res are implemented in all
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 datastores by default (=
with a "not-implemented-in" leaflist
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of datastores that a fe=
ature is not implemented in).
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (iv) Deleted module-set=
s.
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (v) Datastores are now =
just a list of supported datastores
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (that could potentially=
 be extended with further per
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 datastore properties in=
 future).
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Manually generated tree=
 output for proposed YANG library:
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module: ietf-yang-libra=
ry
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0+--ro yang-librar=
y
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +--r=
o modules
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro module* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro revision? revision-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 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:=
uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro submodule* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro revision? yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro not-implemented-in*
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> /yang-library/datastore/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 +--ro feature* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> /yang-library/datastore/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 +--ro deviation*
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 | -> ../name
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro import-only-module* [name revision]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [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 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision yang:revision-iden=
tifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=
=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +--r=
o datastore* [name] // Allows future per datastore
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 properties.
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro name identityref
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +--r=
o checksum 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 *(2) An enhanced versio=
n of the structure (1) above, that
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is extended to allow th=
e structure to be reused for
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schema-mount via an aug=
mentation.*
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is similar to the =
structure above, except that the
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "the set of modules" is=
 contained in a list of named schema
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e.g. similar to the sc=
hema mount draft), allowing this
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 structure to be re-used=
 for schema mount.
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Schema mount would be e=
xpected to augment yang-library to
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 add in the additional s=
chema mount information. In the
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tree diagram, I have sh=
own the schema-mount mount-point
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 augmentation, but not i=
ncluding namespaces yet.
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Every server would be r=
equired to provide at least one
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schema in the schema li=
st, and the primary schema for the
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 device would always be =
given the name "primary".
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module: ietf-yang-libra=
ry
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0+--ro yang-librar=
y
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +--r=
o schema* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro name string
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro checksum string
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro module* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro revision? yang:revision-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 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:=
uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro submodule* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro revision? yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro not-implemented-in*
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> /yang-library/datastore/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 +--ro feature* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> /yang-library/datastore/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 +--ro deviation*
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> ../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 +- schema-mount:mount-point* [label]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro label yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 boolean
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (schema-ref)
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 | +--:(inline)
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 | +--:(use-schema)
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro u=
se-schema* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 +--ro name
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/schema/name
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 +--ro parent-reference* yang:xpath1.0
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro import-only-module* [name revision]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [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 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision yang:revision-iden=
tifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=
=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +--r=
o datastore* [name] // Allows future per datastore
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 properties.
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro name identityref
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +--r=
o checksum string
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please can you provide =
comments on these structures, in
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 particular:
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is this version better =
(i.e. simpler) that the version
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 currently in draft-ietf=
-netconf-rfc7895bis-02 (below)?
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should we try and make =
the structure extensible for
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schema-mount via augmen=
tation (i.e. version (2)), or is it
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 better that schema-moun=
t has its own separate subtree?
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For reference only I ha=
ve included the existing YANG
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 library and YANG librar=
y bis draft tree diagrams.
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rob
>>>>>>
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----------------------=
------
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *** FOR REFERENCE ONLY =
***
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (3)=C2=A0 The current Y=
ANG library structure in YANG library bis
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (draft-ietf-netconf-rfc=
7895bis-02)
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 module: ietf-yang-library
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro modules
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [id]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o id 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 +--r=
o name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o revision? revision-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=C2=A0=C2=A0=C2=A0 +--r=
o schema? inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o namespace inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o feature* yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o deviation* [module]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro module=C2=A0=C2=A0=C2=A0 -> ../../id
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o conformance-type enumeration
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o submodule* [name]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro revision? revision-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=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module-sets
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module-set* [id]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o module*=C2=A0=C2=A0 ->=20
>>>>>> ../../../modules/module/id
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastores
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro datastore* [name=
]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o module-set
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->=20
>>>>>> ../../../module-sets/module-set/id
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 string
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----------------------=
------
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *** FOR REFERENCE ONLY =
***
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (4)=C2=A0 The current Y=
ANG library structure (RFC 7895)
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro modules-state
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module-set-id=C2=A0=C2=A0=C2=A0=
 string
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module* [name revision]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:ya=
ng-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=C2=A0 +--ro revision=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:u=
ri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro feature* yan=
g:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro deviation* [=
name revision]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=
 yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro revi=
sion=C2=A0=C2=A0=C2=A0 union
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro conformance-=
type enumeration
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [=
name revision]
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--ro name yang:yang-identifier
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--ro revision=C2=A0=C2=A0=C2=A0 union
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Wed Nov 15 01:57: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 1E18F1243FE for ; Wed, 15 Nov 2017 01:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 fF8ZR8uBAXbf for ; Wed, 15 Nov 2017 01:57:46 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C63A124205 for ; Wed, 15 Nov 2017 01:57:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2074; q=dns/txt; s=iport; t=1510739866; x=1511949466; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pp1k8KeRp771jVdULRGI/uhlTMqf84OTE2jvWLgzJHU=; b=Dkkj6+xZdW8631IuLDbqgCQFB1WUtlrHo93J6j+7nKhK1kUsoZdoc1Ms NIpX3ZEQa0RnLFHTZqeGPwDwKBFTkTOinPMpEs94ZLBg8QCr4zAwK7LyX x+Sw1U1lluDj7eTRt3CC8MfbEwd12qA4bhmciztVe6lRRJ4q/Q88yIyHv s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAABpDwxa/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4nB4N4ih+PIZhXghEKGAuESU8CGoRtPxgBAQEBAQEBAQF?= =?us-ascii?q?rKIUfAgEDAQEhETobAgEIGgImAgICJQsVEAIEARKKJBCqXYInixcBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEbBYEPgiWCB4ZohRiDFYJDIAWiNwKVBJNElgACERkBgTgBHzi?= =?us-ascii?q?BdHoVSYJkglwcgWd3h1CBEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="31179163"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 09:57:32 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAF9vWkn020228 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 09:57:32 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; Wed, 15 Nov 2017 04:57:31 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 04:57:31 -0500
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , NETMOD WG 
Thread-Topic: [netmod] document organization
Thread-Index: AQHTXdoXMSrLxtRyWkSNGcNUcFG0VaMVNI4A
Date: Wed, 15 Nov 2017 09:57:31 +0000
Message-ID: 
References: <1510726990.12151.10.camel@nic.cz>
In-Reply-To: <1510726990.12151.10.camel@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.122.132]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9406C9E3759CCF43A9F0A89D27AE8B53@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] document organization
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 09:57:48 -0000

SGkgTGFkYSwgDQpJZiB0aGUgY29uc2Vuc3VzIGlzIG5vdCBzcGxpdCB0aGUgZG9jdW1lbnQsIEkg
dGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvDQpmb3JtYWxseSBkZWZpbmUgdGhlIOKAnGlubGlu
ZeKAnSBhbmQg4oCcdXNlc+KAnSBvcHRpb25zIHdpdGggZXhhbXBsZXMgdmVyeSBlYXJseS4NCkFz
IGl0IGlzLCB0aGVyZSBpcyBhIGJyaWVmIGRlZmluaXRpb24gb2Yg4oCcaW5saW5l4oCdIGJ1dCBu
b3RoaW5nIGZvciDigJx1c2Vz4oCdDQphbmQgb25lIG11c3QgZGVkdWN0IHRoaXMgaW1wbGljaXRs
eS4NCg0KVGhhbmtzLA0KQWNlZSANCg0KT24gMTEvMTUvMTcsIDE6MjMgQU0sICJuZXRtb2Qgb24g
YmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBi
ZWhhbGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQoNCj5IaSwNCj4NCj5yZWdhcmRpbmcgbXkg
cHJvcG9zZWQgcmVvcmdhbml6YXRpb24gb2YgZG9jdW1lbnRzOiBJIHN0cm9uZ2x5IGRpc2FncmVl
DQo+d2l0aA0KPk1hcnRpbidzIGNvbW1lbnQgb24gamFiYmVyIHRoYXQgaXQgd291bGQgYmUgYSBt
ZXJlIHNwbGl0IG9mIHRoZSBjb250ZW50cw0KPmludG8NCj50d28gZG9jdW1lbnRzLiBJdCBpcyBj
ZXJ0YWlubHkgbm90IHRydWUgYmVjYXVzZQ0KPg0KPi0gd2UgY291bGQgZ2V0IHJpZCBvZiB0aGUg
dXNlLXNjaGVtYS9pbmxpbmUgY2hvaWNlIGluIHNjaGVtYS1tb3VudHMgZGF0YToNCj50aGUNCj5p
bmxpbmUgY2FzZSBuZWVkcyB0byBzdGF0ZSBkYXRhIGluIHRoZSBwYXJlbnQgdHJlZSBhdCBhbGwN
Cj4NCj4tIHRoZXJlIGFyZSBtYW55IENMUnMgdGhhdCBhcmUgcmVsZXZhbnQgb25seSB0byBvbmUg
b2YgdGhlIG1ldGhvZHMsIHNvDQo+aGF2ZSB0bw0KPmRpc3Rpbmd1aXNoIHRoZSBjYXNlcyBpbiB0
aGUgdGV4dDsgZm9yIGV4YW1wbGUsIHBhcmVudC1yZWZlcmVuY2VzIGRvbid0DQo+YXBwbHkgdG8N
Cj4iaW5saW5lIg0KPg0KPi0gKG1vc3QgaW1wb3J0YW50IGZvciBtZSkgdGhlIHR3byBtZXRob2Rz
IGFyZSByZWFsbHkgdHdvIGRpZmZlcmVudA0KPm1lY2hhbmlzbXMsDQo+YW5kIHRoZSAiaW5saW5l
IiBtZXRob2QgaW52aXRlcyB2YXJpb3VzIGluc3RhbmNlLXJlbGF0ZWQgY29uc2lkZXJhdGlvbnMN
Cj53aGVyZWFzDQo+InVzZS1zY2hlbWEiIGRvZXNuJ3Q7IGl0J3MgYmVlbiBteSBleHBlcmllbmNl
IHRoYXQgcGVvcGxlIGtlZXAgY29uZnVzaW5nDQo+c2NoZW1hDQo+Y29uc3RydWN0aW9uIGFuZCBp
bnN0YW5jZSBkYXRhIG1vdW50aW5nLg0KPg0KPkxhZGENCj4gICANCj4tLSANCj5MYWRpc2xhdiBM
aG90a2ENCj5IZWFkLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2
Nw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Wed Nov 15 02:03: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 4CEF212008A for ; Wed, 15 Nov 2017 02:03:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.11
X-Spam-Level: 
X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 RLwurSQFsG0J for ; Wed, 15 Nov 2017 02:03:20 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDA5129449 for ; Wed, 15 Nov 2017 02:03:19 -0800 (PST)
X-AuditID: c1b4fb2d-2ec699c000001e3d-c3-5a0c10e5dab1
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.7A.07741.5E01C0A5; Wed, 15 Nov 2017 11:03:18 +0100 (CET)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 11:03:14 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Vq4xRuT2OIvkoAzvdaCD0AyO7Qfnf6OhK09uic4PqmI=; b=KphqU9l5ZpU0g5gAr3IQ+LBUGfDh99Ffa7LIPj5KDj3o8nfuzGIVUWBNMzSmojZ98ZvcFZ05+W7vL3gdarNWobhkMBgqcvp6kj0ZP2JE1SjEJMPG37wf3571UoEeEZU5ceRH0mfxJtTV9Z0/tueZlE1+ZVFNiExVZuha870EtJo=
Received: from [IPv6:2001:67c:370:128:e196:b266:ad4f:77e2] (2001:67c:370:128:e196:b266:ad4f:77e2) by AM4PR07MB3426.eurprd07.prod.outlook.com (2603:10a6:205:b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Wed, 15 Nov 2017 10:03:13 +0000
To: Joe Clarke , 
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com>
From: Balazs Lengyel 
Message-ID: <614c9b33-774a-cbe0-0328-cfc7ad9ac11b@ericsson.com>
Date: Wed, 15 Nov 2017 18:02:52 +0800
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: <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [2001:67c:370:128:e196:b266:ad4f:77e2]
X-ClientProxiedBy: SG2PR06CA0099.apcprd06.prod.outlook.com (2603:1096:3:14::25) To AM4PR07MB3426.eurprd07.prod.outlook.com (2603:10a6:205:b::11)
X-MS-Office365-Filtering-Correlation-Id: c45f533d-7e03-4504-a395-08d52c1015d1
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:AM4PR07MB3426; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 3:RGBO34kJXA9vBv1fAa3n3R+1JFdTwDclLm0BHQkh52jLSACOYy8KizKvl/QUZAkHEWTwJqiVLo/EmjvRTx1+7e92xzQSLGrzInXzfb0zSn2VYqmhtOVGTDixKhjrxz0bm96O35lWM3s7U3Ft5BYOio/SooTPAEcpPUqv3p8L2TrIn+07IoERcozaxMOkGvA5+WuAu7oFvX+Fxc5bhq4ROEnLNoeLDZoTvIPfhfWCxtXqLxuyTgRGTeyF1+sYDC/3; 25:ZHYbFLnZEEn1we1LK6t7URoqkhX9Q+my2/Dv9sQuBEZBRmJLQhjT+TaAZwciQRKxSOTTQsRQ2cWnr3sFmQZx88k/qvitEDTR9bOYYbpFuzKgxLlOiA6mkkwXvnJuBJSYpDcRSAlFig5OBfphg3YtVnqDgh7W4R6aJMDwVX8BTlKRxv9Jr7S3R4HV2NuYHdO6d1B/lOK7pWCeXSMIy1mDz1Qf5U89EF84OMyU2EUHP3rYGI4B/mO2Ee++Pxa9uTIHa15vozDKj/qSYt5jJQs2RIIH2/LvO+jOnd23tHzVNZBdbatnTFfjujNmoBSDx3xXHHZPqPcCiR2DpqILTLTtLli1C1Q8dvT0NCX/gHkM52o=; 31:6jNRMKeNpQNAzL44n+K+unxepAid+4Yvt0UN18J5PqP9l0BojY0rnnESItTzRKi958EZ+oAHQqhk6WJ4zxwX0v+D4UR++HSO2QxvCiBk3pOCLqwQ0SKB7MFeCmeBSqzh9+x7wytQt4pvewVR7C4LyNmUDLmMDgR5yK7TCmXLvUx//YpKm7vWm4MEXOwL87hd2MjmUhBWI2MSCKrEa1g5GTD2LCm5rQBon5nmBDnRMno=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM4PR07MB3426:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 20:VSIHVrObqzPAy3PgMYOQAx3zurJKaF8hdishiZNTmpHMVXyaVy0E5QE45vZJ/sqm65/Ba8RKjK92+Fx5ryGlxBdio/wMscV+T2wB42YI0RSsSTKUWbNhyZ+olVNZLlFGge+M2oGx2ZOWkKlFOSEqzeg8CvzTAGnowrrvtc57RcNABSZn+uwDSCZAreukBRT3LB8kx7IGqS/p6AU94dYdaMiuc2vCM/APbab7TqRCuJFSAofCRxqSrcuSJEampJOzwzhpO2IXJum8SAwD4P9rRto5Wn1huoYpnZrBZLirKNTmW6TJXkj0AIsUmv1vZnLjl8fYr0mwclZw7uNSVoQUr4yvXhX9X58xN8u/i4jvZBKQoOAw8PT12R0z5AoiO3C1kTSkOxuHhNClxhlglHAUgYx15A1kLtfD12XFsiTVIUtmjJuqt5Np7TgDA9TmdiJ4U2dVuxyhp6GFRh24R4jIGecZ/R6vOivh/DrAMVzMwEVXQ5J4HEfoUHGQ6rKs1XZr; 4:y1niFw2VLvIgZXz37nM9GQ48aVg62DIRO1TB5RcK8NCN1v1hdWyB6GDhHOTR9prz5OT4yS3yyFwct3TopUIPQcqa/0lHSTsqb0awtjNjtyIKEaQLR8eQ7RcRcnwNZxX1oEtRH/5rxB5aXZuFKJ/rV63e4SYrDYS52GAD5U3PSWKZ8ed1o0D/6UlkCMktzejjk4TC8XbeOkX6GYF2VqzzyZAkLaF10wjLUF/DBqyQaEuIs0BSbmfDj4YhvnzL4oQlBxBo6ID+YCjt9bQRZeyPJRToPeYLEvDWKlXRKBb5twOL9ehtazkYKb33yuDoGyXDu2kTIpxqprAeEJVh10HEvCcwRo8MEcKbzOQbD6qB3Ow=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3231022)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3426; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3426; 
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(377424004)(189002)(24454002)(199003)(252514010)(33646002)(86362001)(2420400007)(6116002)(8936002)(8676002)(106356001)(36756003)(15650500001)(65826007)(53546010)(25786009)(67846002)(23676003)(81166006)(7736002)(81156014)(6666003)(1706002)(2950100002)(305945005)(4001150100001)(31696002)(97736004)(105586002)(64126003)(47776003)(50466002)(31686004)(7110500001)(58126008)(83506002)(53936002)(54356999)(101416001)(230783001)(6306002)(6486002)(229853002)(478600001)(76176999)(189998001)(966005)(5660300001)(2870700001)(6246003)(93886005)(2906002)(68736007)(65956001)(10710500007)(65806001)(50986999)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3426; H:[IPv6:2001:67c:370:128:e196:b266:ad4f:77e2]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI2OzIzOjd3Y1dnU0NTSVZSOW1ybVRpUURnelQ1WlNQ?= =?utf-8?B?eHFmMi9XVmxVQjN4R05wZ2JpS05aaHc3ajZWODFJeWREajZpUnAxTkh0eTBO?= =?utf-8?B?UCtUemlCUlRoODY5eGFwN1kxdS9SWCtkeW54dkpDSWRlWlh0ODlRZEpMUi94?= =?utf-8?B?ODQzZUYwdmJ2dUM1ZHJBNUs0bGJNVU5wUDArQ2hUY3IrL2pIVHBHVlJNVEtQ?= =?utf-8?B?WHFwbmlNbFp0eVBzUDV4MXFvbG1ZbTAzNDVzMkdwNHVUcGVXQ0RIVUFBRlhz?= =?utf-8?B?MUVMZTBIdUVRanVuaFRiamFuOE9OSmNQT1pwWlFTYUltc1BPQzVIL2FBeUg4?= =?utf-8?B?ME04ZWlhR2pSS2ZOTHNMVVBVMUVHbzBDa0lzRUZFTVVpY3VNeEJHSkp3UHJl?= =?utf-8?B?RFUzVStrMVdpSC9Hd1lqNmdoY2hpRUJLSmNyN2xISHI2NUV6STVVN2o0Ung0?= =?utf-8?B?NEF2ZjI5dzIzQVFqVHB3c284K3dzTURPS0dRRjdSK0RvUXZYaFU0bTFnMk5Z?= =?utf-8?B?RXNxdWNIdlk2TzBTUHZ2NlBJYUlDVkQyTUlOQVpZNWJxYXlBZzNCT3hmUlUz?= =?utf-8?B?RC8ycHlZS3d0RFJoQlluVFlTYWlRTmFab05qdFViSkdGcTEvbjRLYkdmNWps?= =?utf-8?B?aVJ6ZStXVHdlWVRXWFhMRXRsWE9udG5qaDVPRUtUem42amxyMkJrNGZOakNw?= =?utf-8?B?Tmh4YklwTTBnbUlCRmVOT09kaXhMM0g4ZWp5cm01T2lEbnJxbHN6aEZVeFNS?= =?utf-8?B?Mk5CVTVOK3NBR3l3c0NmWVlnVnI4VXJKTjZ6QURIRElQQm9wZ1hrcVBPUUUw?= =?utf-8?B?NEVjZCszUUhhWTJHMXhpaDFwbjhaMXJQdC9PWHhocmtMb1BId20wQjNKbkFG?= =?utf-8?B?c0FvK3drRUtxdGN1WEszZ29wRjM3Q25VS3FuMldYOS9ZTjQwbzAwWHRCTkRx?= =?utf-8?B?azFrbEtndHR5Z2FOc0ZGd3NUNlQ4UlZyc3RzN0FnaGJLQ0VKLzMrSHJBMkZ6?= =?utf-8?B?MFAva09uTStUVGJvczNFZDlPZXQ0WldoMjdteUFkVXdtOVpWb2FpUjFSOUs4?= =?utf-8?B?RHkxU0JhMk5oQUdsa2FHVzVJM1NvZ21haE1EZytiZXZTRG1aYUFqTklrV3VW?= =?utf-8?B?S1BuY0tUYTVreGhySTFzWjhPU0JVMkdpVXJLYmZWcjZmNUxOdHBndzA4TWpG?= =?utf-8?B?K1JHYlNjaUNYeUhPOEF3K2VyRWg0SXhPR1crZ05HN0dqL2E1a0h0QXZFNUxh?= =?utf-8?B?K05Ga0EzV0hLeE0rTmpiTEpIZHVQM0loRGZqRG9UV2FiSE0rbFFvMkhmOTNr?= =?utf-8?B?a1VMaW51dUZUT2s3OEdVOERpdVpBcnVxUjBDOEVLOVY2YXVXMWFnWTl5ajMz?= =?utf-8?B?RVRlc2VlS2ExbmpiUW5HbjJlUWw1ejZwYUVmblp4Z3AwK3ZvL255ZVc0UmNo?= =?utf-8?B?SmlXeVM0N21iS3RveGVvRU13UjAzY2xoT2ZDNVZTS3BqVlpuS2tBNEhHbDRo?= =?utf-8?B?RkhVZkRnN0dmc0lwaTNrZXMwTHQ2dVlFSzlSd0RyQllPU2ErWkJVNnhFbGdt?= =?utf-8?B?VTQxaWE1UmIydmpIeDg3RWtnRzZEbjRVd2ppcXdHRk1aSU1zV3laZTM3eXkr?= =?utf-8?B?czRHbHppUDQzbkJiTHFjMDY4bFVIellxSitqY3dnT2xMWGoweU5ucFQvdXMv?= =?utf-8?B?VGxUK3Zrc3FxQlJzNUxlSFl0aHZiQXJwTFBTdmhXL2IwYTNCanZ3aUExVXI5?= =?utf-8?B?MXUyWllNL3lRUENVc3ZndG9NWHhsZVhPR21ld3lVNzhJci9aeHhIRE15ZTJy?= =?utf-8?B?cUtUS1BYKy9wazUzZDltd2JsWmd5RXpzUkJHK1UrdG42VXVybmpLZTB0MGRq?= =?utf-8?B?OWdoZDY4Y1MyTTVTT2Z5TlhJVFNBWThFbjY2cE5zd0tFNFZIZTlLT2VvNmUy?= =?utf-8?B?SWF3MlpoRVdJbnduSUhDSkNMbEVsOWRGWFZ6RUhmU3JNT0Z3RXlaQ05QT2d4?= =?utf-8?B?ck9UUktsd2Z2alpjc2R5bVhySE1xODFJMEJQZz09?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 6:zJFNRSDvrMSjjsUNsG+0urooGHrJOao83gcpFO8Gb4wdEBgg704fbM+ssCQTPjrto85DikS3ijZI8CajTZbnbr3xFe5cQtjdF9ie32NBkPXnjak57BPcgA4yj/t/BKa+CY70O/2Kw01AbuQQeVjBjNsPhkz7Hw4oObhLi1+GdDmaPXX+RbbHKdqc0984uH/k6rlFHM/Z4UXRla6fOqonNR6aWgoIh20tBJj7LBeQ/pmxhLUy++lXE7FqaCreygWZKF5TGvUaRmhQjtk+b1oLqazTML/4TzG9AsK93Ibhm4ftrsQ5xFL4Psi9Cy8xv/Y9FZEmQArQBdVHPRt2YkFJXeZPaGZwj+nGNVg7iDMz3sQ=; 5:d+8Z8YVzzxEmWGQH7a3ZVMjK7T9A+xuMFsjyx2FYUO747p0KfJhka4BJKvqc17DgMx5yQbG12aSmYVlY6U4spPevUhguooKxA5wei43QhTlzgXT10mvzR+cwDoyzRsHHQHcC0Aap0e+bPPqHDfC6PSsUxQNBXUSdhWmbSFWnPnI=; 24:/ccd4L5y01FRNWsxxhY6opJhk+Oy31MhS6BYcjsLXly0Vv3tswrK1I2L7rHEBwQFLuCXzFbmwqDCT8EO3gSHtXblPQ2I6BTJoycnMA9JcZ8=; 7:pzUNJH5AoGuv3/3nJdGsBe4EBnktkC1kZ0T1AXgHfg+SBp3i9syWdNu0YoznUTUKOakKJ7nYcYJKIFCcqLqKXH4llPh4O2SzS99er3LvCvBSczMG3OBlfiEIdrbXiH1sx+sTTk2kWEOQTOnYDMwqXUJS0CFUccBef2cktZ5OpFZYA3T2SMM6y4I9J/cQgQ+uckT+O8rOFISr6/KUxXY8XFC9Pwte1IfBsQxBN/yKEYjWREfWe77pu/PI+U2Keh9j
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 10:03:13.0264 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c45f533d-7e03-4504-a395-08d52c1015d1
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3426
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42KZGbHdWPeZAE+UQetsZot9V/8wWsy/2Mjq wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGVsv7GDqWCNW8XO9xsZGxgXmXcxcnJICJhI rGw8xwRiCwkcZpR43WDRxcgFZJ9glHjxeBMzSIJFoJdZYv0zN4ii3UwSC3+VgdjCAp4S+zr/ sILYIgKmEmv/zGCGaL7CKDF3x1+wqWwCRhJT+8+zgNi8AvYSGycchRqqKnFyxwawuKhAjMTE BxcZIWoEJU7OfAIW5xSwlXh6/iPYHGYBC4mZ888zQtjyEs1bZzND2OISt57MZ4L4xkLixdvj YEdICEwBOmLqQnaIqzUkHl74C3QpB1DCV6LjhzpEzUxGidaOnSxQDewSv/+8Z4WYJCtx9Owc FogGLYnr7xVBwowCcRI71yxkhahfwi6xpXcvM0R9tsS0rqPsELa3RPuzy+wQRVdYJd5uO8wC kZCROHljLyNEYj+bxKb911gnMGrPQvL2LCSvzkLy6iwkry5gZFnFKFqcWlycm25krJdalJlc XJyfp5eXWrKJEZg4Dm75rbuDcfVrx0OMAhyMSjy8zBw8UUKsiWXFlbmHGCU4mJVEeJP7uaOE eFMSK6tSi/Lji0pzUosPMUpzsCiJ83qIAKUE0hNLUrNTUwtSi2CyTBycUg2MMwKOzvi18Xao 0s74NJW+GTcTXISdw67PufdE28b1msOqva0CbzuzMz/mcfw9vW26Lp/9skwzvim9ngvfP/sa tjngh8Z2vcesNq+LZk/e1LQwe7qCSKGUNVtRnGzy2gKVx5Msfs/6fHum4HZL748y30616OsF t9/O5wyQDJhzXed9QfAiM7kHSizFGYmGWsxFxYkAmykqChgDAAA=
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:03:28 -0000

While a server may correctly support multiple versions, the human 
operator on the CLI has a 99% chance of mixing up which version he is 
using. Humans will not check every type and leaf  to check that they 
remember the little differences between model versions. It is a recipe 
for human mistakes. According to some statistics 50% of downtime is 
caused by human errors, so we should not provide the operator with a gun 
to shoot himself. Ericsson has a rule never to have multiple versions of 
the same module on a network node.

regards Balazs


On 2017-11-15 16:44, Joe Clarke wrote:
> On 11/15/17 00:30, Juergen Schoenwaelder wrote:
>> Another thing to consider is that foo and foo2 allows an
>> implementation to support both during transition, with foo {semver
>> 1.x.y} and foo {semver 2.x.y} this may be harder.
> I'm not convinced this a bad thing.  If a server supports multiple
> versions of a given module, which should a client use?  Did the server
> vendor test each one?
>
> I suppose my gut reaction to Lou's question as to whether a server
> should support multiple versions was, "no."  A client may have multiple
> versions loaded to support servers that support different versions.  I
> may be convinced otherwise, but I feel that this will become untenable
> over time (even if module names change).
>
> Joe
>
>> /js
>>
>> On Tue, Nov 14, 2017 at 10:22:10PM +0100, Juergen Schoenwaelder wrote:
>>> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
>>>>     Whenever a client OSS implements some higher level logic for a network
>>>>     function, something that can not be implemented in a purely model driven
>>>>     way, it is always dependent on a specific version of the Yang Module
>>>>     (YAM). If the client finds that the module has been updated on the network
>>>>     node, it has to decide if it tries to handle it as it did the previous
>>>>     version of the model or if it just stops to avoid problems. To make this
>>>>     decision the client needs to know if the module was updated in a backward
>>>>     compatible way or not. This is not addressed with the current versioning.
>>> The current rules aim at guaranteeing that definitions (with status
>>> current) remain backwards compatible. Do you have an example what the
>>> current rules fail to achieve this? Definitions with status deprecated
>>> or obsolete may not be present. But if they are present, they have the
>>> same semantics. This is the promise made to a client. (Note also that
>>> objects may be absent for reasons document in deviations or simply not
>>> accessible due to access control.)
>>>
>>>>     While having PYANG based checks for backward compatibility is a very good
>>>>     idea, a  comparison based check will never be a complete check. It is
>>>>     quite possible to change just the behavior of an rpc/action/etc.  without
>>>>     changing the YANG definition.  This will only show up as a change of the
>>>>     description statement that can not be analyzed by PYANG.
>>> The problem is to decide whether a change can break client
>>> expectations or not. Even 'bug fixes' can cause a client written to
>>> expect the old 'buggy' behaviour to fail. Also tricky are situations
>>> where behaviour was not clearly enough described and this is 'fixed'
>>> in a module update.
>>>
>>> Semantic versioning assumes that one always can clearly distinguish
>>> between incompatible updates and compatible updates. This may not be
>>> so clearly cut in practice, see above. (But then, we have the same
>>> judgement call at the end with today's update rules.)
>>>
>>>>     When upgrading a network node we might introduce non-backward compatible
>>>>     (NBC) changes. Today we need to introduce a new module for this. That
>>>>     means during the upgrade process the node must convert stored
>>>>     configuration instance data from ietf-routing to ietf-routing-2 format.
>>>>     Instead of solving this data transformation/transfer problem just for a
>>>>     few NBC data nodes, we will have to do it for the full model. This is
>>>>     complicated. In many cases the transformation of a few NBC leafs can be
>>>>     handled by good defaults or with a small script. Transferring the full
>>>>     data set is more complicated. If we allow NBC updates in some cases this
>>>>     problem is avoided.
>>> In XML land, this is mostly a change of the namespace (not of the
>>> prefix) if one keeps the same structure, no? In JSON land, the change
>>> of the module name more directly becomes visible in instance data; but
>>> this is all encoding details.
>>>
>>>>     If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
>>>>     the prefix?
>>> I guess you mean the namespace, not the prefix. You can use any prefix
>>> you like.
>>>
>>>>     In one sense it should be kept as it is the same module
>>>>     "logically"; we also might have stored data including the prefix
>>>>     (identityrefs, instance-identifiers). On the other hand having multiple
>>>>     modules with the same prefix is a problem. The only good solution is to
>>>>     allow incompatible updates in some cases.
>>> If we move towards allowing incompabile updates, then we need to have
>>> a mechanism to tell which versions of modules can work together and
>>> which combinations are affected by an incompatible update. We probably
>>> need to require strict import by revision or at least 'import by
>>> compatible revision' (whatever this means at the end).
>>>
>>>>     CH 1)
>>>>
>>>>     You write
>>>>     "The YANG data modeling language [RFC7950] specifies strict rules for
>>>>     updating..."
>>>>     and again
>>>>     "When the same YANG module name is kept, the new YANG module  revision
>>>>     must always be updated in a backward-compatible way."
>>>>
>>>>     I strongly disagree. While we have strict rules about even small
>>>>     modifications to existing schema, but you are allowed to
>>>>     deprecate/obsolete big parts of the model, thereby possibly deleting
>>>>     complete subtrees from the schema. That is anything but strict backward
>>>>     compatibility.
>>>>     I find this aspect of YANG inconsistent to the level that it would need an
>>>>     errata.
>>> Marking something deprecated / obsolete means you can not be sure this
>>> is implemented. But then, even definitions with status current may not
>>> be implemented (see deviations) or they may not be accessible to a
>>> client due to access control. However, if implemented and accessible,
>>> the guarantee today is that the semantics stay the same and don't
>>> change unexpectedly.
>>>
>>>>     So practically the current rules allow backward incompatible changes that
>>>>     can only be detected by a line by line comparison of the yang modules. In
>>>>     a system with semantic versioning, you could determine backward
>>>>     compatibility just by reading the version numbers.
>>> I do not see why you need a line by line comparison. With semantic
>>> versioning, you _hope_ the semantic version number is a good enough
>>> indicator. It might also be that your client is only using a subset
>>> that did not really change even though the semantic version number
>>> changed. Or the semantic version number indicates only minor changes
>>> that sill break your client.
>>>
>>>>     CH 2.3)
>>>>     As we need to create a new Yang Module (YAM) even for the smallest
>>>>     incompatible modification, this increases the number of modules.
>>> So it seems to boil down to the question whether foo and foo2 is
>>> significantly more expensive than foo { semver 1.x.y } and foo {
>>> semver 2.x.y }. The main argument seems to be that the later keeps
>>> references that involve module names or namespaces unchanged (but
>>> they may or may not mean different things).
>>>
>>>>     IMHO YANG package definition should be a separate issue, left out of this
>>>>     document. Andy has already provided some very good ideas about this topic.
>>> I think it is necessary to think about how the semantic version
>>> numbers are used. See my remark above about imports. If we allow
>>> incompatible changes, than this has side effects and I think we are
>>> not done by just adding a semantic version number without going
>>> working throught the implications.
>>>
>>> /js
>>>
>>> -- 
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103         
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


From nobody Wed Nov 15 02:05: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 67C2C12706D for ; Wed, 15 Nov 2017 02:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJBeP7V4dTin for ; Wed, 15 Nov 2017 02:05:43 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 56F9112008A for ; Wed, 15 Nov 2017 02:05:43 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id B2B8018215DD; Wed, 15 Nov 2017 11:04:23 +0100 (CET)
Received: from localhost (dhcp-9083.meeting.ietf.org [31.133.144.131]) by trail.lhotka.name (Postfix) with ESMTPSA id F2DD91820F76; Wed, 15 Nov 2017 11:04:19 +0100 (CET)
From: Ladislav Lhotka 
To: Joe Clarke , netmod@ietf.org
In-Reply-To: <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com>
Mail-Followup-To: Joe Clarke , netmod@ietf.org
Date: Wed, 15 Nov 2017 18:06:43 +0800
Message-ID: <87inebdff0.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:05:47 -0000

Joe Clarke  writes:

> On 11/15/17 00:30, Juergen Schoenwaelder wrote:
>> Another thing to consider is that foo and foo2 allows an
>> implementation to support both during transition, with foo {semver
>> 1.x.y} and foo {semver 2.x.y} this may be harder.
>
> I'm not convinced this a bad thing.  If a server supports multiple
> versions of a given module, which should a client use?  Did the server
> vendor test each one?
>
> I suppose my gut reaction to Lou's question as to whether a server
> should support multiple versions was, "no."  A client may have multiple
> versions loaded to support servers that support different versions.  I
> may be convinced otherwise, but I feel that this will become untenable
> over time (even if module names change).

There are use cases for modules that are imported (i.e. not
implemented): it could be that a module author wants to use some
definitions from an old version of an imported module while, at the same
time, other definitions from a new version.

The semver-aware "import" statement should be able to deal with this.

Lada

>
> Joe
>
>> 
>> /js
>> 
>> On Tue, Nov 14, 2017 at 10:22:10PM +0100, Juergen Schoenwaelder wrote:
>>> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
>>>>    Whenever a client OSS implements some higher level logic for a network
>>>>    function, something that can not be implemented in a purely model driven
>>>>    way, it is always dependent on a specific version of the Yang Module
>>>>    (YAM). If the client finds that the module has been updated on the network
>>>>    node, it has to decide if it tries to handle it as it did the previous
>>>>    version of the model or if it just stops to avoid problems. To make this
>>>>    decision the client needs to know if the module was updated in a backward
>>>>    compatible way or not. This is not addressed with the current versioning.
>>>
>>> The current rules aim at guaranteeing that definitions (with status
>>> current) remain backwards compatible. Do you have an example what the
>>> current rules fail to achieve this? Definitions with status deprecated
>>> or obsolete may not be present. But if they are present, they have the
>>> same semantics. This is the promise made to a client. (Note also that
>>> objects may be absent for reasons document in deviations or simply not
>>> accessible due to access control.)
>>>
>>>>    While having PYANG based checks for backward compatibility is a very good
>>>>    idea, a  comparison based check will never be a complete check. It is
>>>>    quite possible to change just the behavior of an rpc/action/etc.  without
>>>>    changing the YANG definition.  This will only show up as a change of the
>>>>    description statement that can not be analyzed by PYANG.
>>>
>>> The problem is to decide whether a change can break client
>>> expectations or not. Even 'bug fixes' can cause a client written to
>>> expect the old 'buggy' behaviour to fail. Also tricky are situations
>>> where behaviour was not clearly enough described and this is 'fixed'
>>> in a module update.
>>>
>>> Semantic versioning assumes that one always can clearly distinguish
>>> between incompatible updates and compatible updates. This may not be
>>> so clearly cut in practice, see above. (But then, we have the same
>>> judgement call at the end with today's update rules.)
>>>
>>>>    When upgrading a network node we might introduce non-backward compatible
>>>>    (NBC) changes. Today we need to introduce a new module for this. That
>>>>    means during the upgrade process the node must convert stored
>>>>    configuration instance data from ietf-routing to ietf-routing-2 format.
>>>>    Instead of solving this data transformation/transfer problem just for a
>>>>    few NBC data nodes, we will have to do it for the full model. This is
>>>>    complicated. In many cases the transformation of a few NBC leafs can be
>>>>    handled by good defaults or with a small script. Transferring the full
>>>>    data set is more complicated. If we allow NBC updates in some cases this
>>>>    problem is avoided.
>>>
>>> In XML land, this is mostly a change of the namespace (not of the
>>> prefix) if one keeps the same structure, no? In JSON land, the change
>>> of the module name more directly becomes visible in instance data; but
>>> this is all encoding details.
>>>
>>>>    If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
>>>>    the prefix?
>>>
>>> I guess you mean the namespace, not the prefix. You can use any prefix
>>> you like.
>>>
>>>>    In one sense it should be kept as it is the same module
>>>>    "logically"; we also might have stored data including the prefix
>>>>    (identityrefs, instance-identifiers). On the other hand having multiple
>>>>    modules with the same prefix is a problem. The only good solution is to
>>>>    allow incompatible updates in some cases.
>>>
>>> If we move towards allowing incompabile updates, then we need to have
>>> a mechanism to tell which versions of modules can work together and
>>> which combinations are affected by an incompatible update. We probably
>>> need to require strict import by revision or at least 'import by
>>> compatible revision' (whatever this means at the end).
>>>
>>>>    CH 1)
>>>>
>>>>    You write
>>>>    "The YANG data modeling language [RFC7950] specifies strict rules for
>>>>    updating..."
>>>>    and again
>>>>    "When the same YANG module name is kept, the new YANG module  revision
>>>>    must always be updated in a backward-compatible way."
>>>>
>>>>    I strongly disagree. While we have strict rules about even small
>>>>    modifications to existing schema, but you are allowed to
>>>>    deprecate/obsolete big parts of the model, thereby possibly deleting
>>>>    complete subtrees from the schema. That is anything but strict backward
>>>>    compatibility.
>>>>    I find this aspect of YANG inconsistent to the level that it would need an
>>>>    errata.
>>>
>>> Marking something deprecated / obsolete means you can not be sure this
>>> is implemented. But then, even definitions with status current may not
>>> be implemented (see deviations) or they may not be accessible to a
>>> client due to access control. However, if implemented and accessible,
>>> the guarantee today is that the semantics stay the same and don't
>>> change unexpectedly.
>>>
>>>>    So practically the current rules allow backward incompatible changes that
>>>>    can only be detected by a line by line comparison of the yang modules. In
>>>>    a system with semantic versioning, you could determine backward
>>>>    compatibility just by reading the version numbers.
>>>
>>> I do not see why you need a line by line comparison. With semantic
>>> versioning, you _hope_ the semantic version number is a good enough
>>> indicator. It might also be that your client is only using a subset
>>> that did not really change even though the semantic version number
>>> changed. Or the semantic version number indicates only minor changes
>>> that sill break your client.
>>>
>>>>    CH 2.3)
>>>>    As we need to create a new Yang Module (YAM) even for the smallest
>>>>    incompatible modification, this increases the number of modules.
>>>
>>> So it seems to boil down to the question whether foo and foo2 is
>>> significantly more expensive than foo { semver 1.x.y } and foo {
>>> semver 2.x.y }. The main argument seems to be that the later keeps
>>> references that involve module names or namespaces unchanged (but
>>> they may or may not mean different things).
>>>
>>>>    IMHO YANG package definition should be a separate issue, left out of this
>>>>    document. Andy has already provided some very good ideas about this topic.
>>>
>>> I think it is necessary to think about how the semantic version
>>> numbers are used. See my remark above about imports. If we allow
>>> incompatible changes, than this has side effects and I think we are
>>> not done by just adding a semantic version number without going
>>> working throught the implications.
>>>
>>> /js
>>>
>>> -- 
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103         
>> 
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Wed Nov 15 02:12: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 18D0D12008A for ; Wed, 15 Nov 2017 02:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.11
X-Spam-Level: 
X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 Lms8oQnyWm8Z for ; Wed, 15 Nov 2017 02:12:31 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EA512706D for ; Wed, 15 Nov 2017 02:12:30 -0800 (PST)
X-AuditID: c1b4fb25-d91ff700000020f7-6d-5a0c130d3d04
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AB.A6.08439.D031C0A5; Wed, 15 Nov 2017 11:12:29 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 11:12:28 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KoRv1QRMpaIerieKXQ4YNxnnozP9advlvhGQTa5FDf0=; b=HUsBAFi9qMi0KGBu5gq/H3uIvbhwa/8HRV+sebTLR42SgLEc8YILKgcALJpnQdHzDmZA6YrQY+Kzrfpd37VDOerZDpBTjsjTbeDAv+qizvh4hHUDW2Svr6+nJPCqxU/VmllPC3PDN6oKIT1RQEm0oIDyxHpMpARfBNsz4KPVqps=
Received: from [IPv6:2001:67c:370:128:e196:b266:ad4f:77e2] (2001:67c:370:128:e196:b266:ad4f:77e2) by AM4PR07MB3428.eurprd07.prod.outlook.com (2603:10a6:205:b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.4; Wed, 15 Nov 2017 10:12:24 +0000
To: Martin Bjorklund , 
CC: 
References: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <20171115.095341.1585161898755400575.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com>
Date: Wed, 15 Nov 2017 18:12:04 +0800
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: <20171115.095341.1585161898755400575.mbj@tail-f.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [2001:67c:370:128:e196:b266:ad4f:77e2]
X-ClientProxiedBy: CY4PR22CA0068.namprd22.prod.outlook.com (2603:10b6:903:ae::30) To AM4PR07MB3428.eurprd07.prod.outlook.com (2603:10a6:205:b::13)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: a43f65da-b8e1-4c08-4bda-08d52c115eda
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:AM4PR07MB3428; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 3:a7Nz4ZJX5HSWEfgx2S5tvxGEoStFD58Sv8BBEL0GIToEpgkTARIFZ+wO9Iu11GXkdaSmBdhjlVGm8AIAnCVrzjGNzXfE8LLi3WQEEY0OoM9VgKmLZ5+J5DHyQhtnHhspYgchNH5BLosUpRth23ZHkZ1aiHpvbCj3ffMRajfk/DrdshZQc6qwHBd7LDNuf9A+F7pLZN4O2Aj/kAPaqVGykxL0ooVBjePlL2vi9fuYfo+itg/yFWIaZnlRgdVn+D1p; 25:3CS2DIz7ZMUzuAdhq05cmARo3a47QFUc1unlkoSIEQY4biQ21VcGnHodibQLmj6RJwvSCivJhRAAGkLmpjWHsajJkFpUV/JM3xx2XtRE64f/OBhE2DFRY9yYKaKQNkY0a7Bo8G1wmQTdTvMke3G0yasnntqIs5mwFTsqt9ZYbaDyFVYhDUI+Z0AGVsVvfRY67HNSCDV0HZWwLt9lzlP3aUw/U0ZfW8Dj7DQ0P2ll00ddMXpiByBt75EKuVwnBEes5R/narb8yzGZXxj/Hdf2/U4eaY6Ol93PoGwbswJg3WdaNLBOd9g5Iz7UxODogwmjH6uxAhfEYktBbByMpYckRA==; 31:oaKtJMwqn5+/M3JVXUmIchsgpQ3pCihB9fIKQVNmGyMpHwAHP4KdRlhnl/HwsGzYCxnWGJNaGUmpH1rPkgfRQRkWE3mbfZBtHsdiK68fdv1XcTktRWzgvRi3QM1RZL2VUH6mSZ8Wk6ZPC99xgkwqGBUiDTu0hyONwPX9mg8nX7wcNiJMaqf61PnRowLZqxA+LYc7h6Wd7kgmzd1fBhetw/q6wcESDp0lmChPO1UNnAw=
X-MS-TrafficTypeDiagnostic: AM4PR07MB3428:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 20:Ynjjc1h2mLg+aqFhygBnQVUg2Eci9fbMLrf3nZ8gqFsMH9deGm3uw86EKfgi/3tKc9VUycrEvwT/yo2Q3R6AkOtlddCgb3ly3kHmK//IM9xtgCFMiC1vDSucDHo9inVwrSBYhhNR6WCr+tU3eBMF2a4XTaRHPwRJdgSDe2Iguu1odB13TcJCH0yFLWyhYcuFjMIrf0yoDiHKGHr27l4kbngE1KdLyl1+Mrdy7XhK5yit2ViXPEvTJmNdF7G2oNrwBDhGkxEQAdhIAUqGq+0ULpiFTtLlk5T8RoNJddVusqhXPLk1nRZ14W47ypirYL4CH5KZbwej6Xf38E+190bA5BaMRN9R+WdftRHUBMB5X3FPLR9/ygQW63pRK75nKbY15ZwuAsLlSHDnKJH14BPN6kzNMGesbT+d6OmELYCnXvni/zMXtjdJrW37uOieXjetH+GHpv/loCV1cUEwggXAyAFzHaJLLgtB0fRXfAvWdCOWxqI43q+vu6u1pXqtBvup; 4:KwrJwpjTz795oZzSI0CM2skAxkn80r0pZjrE37GlDxxd12MCx+NO6vJBTCJ5QHLvLnHPZM7EkjuYBUxNui5ktvgKxtsbW6an9IPOybCFyRjC/R1om3b9YMADG2C9nJLgwH6ts4NrdG5mrE8Qp9mRn1ok8yOiwWUo8ldbKNHoTuebVpBZ9VmKwVmD/EWudehWFrCk18xE0F0TO97e2k5bGRIcfqmTv1hw+FxxHYLD+xNq1iDeUHZn5C4/aEUty8/i/S8scGukMmRLpqqQON5LqK7UNMzCBUkffAWR4z9aJM/O3y/KYYTzhtPIs3eu9lX5xqMRmz/bbngLwginlw0+vn3d8EfCAgYKQ9RRvZqpSO3vp66KS7mcfgmnhooje4AD
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(788757137089); 
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)(3231022)(100000703101)(100105400095)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3428; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3428; 
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(199003)(24454002)(377424004)(252514010)(189002)(36756003)(2906002)(230783001)(31696002)(2870700001)(478600001)(81156014)(316002)(50466002)(6246003)(2950100002)(68736007)(23676003)(8676002)(6486002)(67846002)(5660300001)(86362001)(83506002)(53546010)(33646002)(64126003)(105586002)(106356001)(25786009)(58126008)(53936002)(31686004)(305945005)(7736002)(15650500001)(4001150100001)(229853002)(47776003)(54356999)(76176999)(93886005)(8936002)(65806001)(6666003)(4326008)(81166006)(97736004)(50986999)(101416001)(65956001)(6116002)(65826007)(189998001)(1706002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3428; H:[IPv6:2001:67c:370:128:e196:b266:ad4f:77e2]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI4OzIzOmoxMTlrTTArcGZOOWpuNEZ1cmR4U1I2Z1g5?= =?utf-8?B?VDZSYUJqUDBHbU42YktVaUY5R2NoZlVYSE9NeHBpUzNWdnZ5cWphWUZMUVlS?= =?utf-8?B?SHhIOERqOEdHQWVxSDI0UTdsRXh4dHVwdE1iVUpXWDJMaW1TU1h5VHdMdTdI?= =?utf-8?B?SlZhMWpjL3FnT2N3QXZIK1UvWVA5ZEU1VmNCWmk0VGduRUVYWk9UdDdycXls?= =?utf-8?B?Z0JZTkU3alhaeGkyd3QwNmhWdmZCd0dLOEcxZ24rS3AwK3lvczA3bS8yU2hZ?= =?utf-8?B?TVRTVG5QTzdsMGhOSjdjRXRPMEhXeGg1ZG40TkthajBpR0tJVDJ0WFVkWW9h?= =?utf-8?B?MkJTcGV6T1c2ZXBkUjlSK2JLQitsTE0wczVteWw2M3FBeVZGZlhqYWdIYnJp?= =?utf-8?B?QVRzWjl5OTRmNlRDTDQwMjRsYWZGWDFhSmJ2L0RyMWNWR1A5WTRCR0NOQTNv?= =?utf-8?B?TTRXWk5lOUczaDFjTUlON3dTdkxkN1h1V1loUm5kSy9KaTRyb1ZZQUlnSzJH?= =?utf-8?B?R3E1VG80ZnNIaThKSXNxYklZNXk4L3c4QlNock15TDBqV0tldlRMOXlMbTEr?= =?utf-8?B?RTljYnBZcDliOFZOcFZ6M1ZQNUVlVHZWMjE5NjRtUXUyb0NsWXhvTGlKWXRk?= =?utf-8?B?d2M1QkE5Y2FQUlpVc1R5aWdwS3AyWVBQeGNmTGRvOWFFMllXZHc4TWVGZXlh?= =?utf-8?B?d1A4VmQvM1FPV1VkRDBWU0MvRHYveE14OGdjb2IyVzVRM1hrWE5PM2hza0pr?= =?utf-8?B?OGNyOXRGQVl0ZHFnb2tkbGhwOG5GQWwxUGdxWWxtL09YdWg3TzFWb2t1bm1O?= =?utf-8?B?MytzRVRpd3VBcU9yVzdkQVI5T1Z2NVNLRnR0U20xc2JEYWRnZDBrT1gzQXhY?= =?utf-8?B?Q0hvdjIwQ3IxelkyQXdTcWhCamtBcXY5RVdSNWFOTnVWc3gra1NXQ1JTUENh?= =?utf-8?B?aXROLzJGTFA1TGpNck92Rml5UG44aFpkUkx3RmdjL1pTbkp6R2tKR1ZYZTVL?= =?utf-8?B?SVltSW5oMGhuUHdJQTFiNE1HRmRNcFJNMTZpdnlHR1JJMGhLMzVDdTcrL2Qr?= =?utf-8?B?Q2JxSUlzWEgzWWZBVkNvOUlpMXBnSmFZMDJkSXVlRWhsYkR3VzA3cEE3bXlm?= =?utf-8?B?V01uN3FjQ0hsM2JMcXpIRHpNQzJ2QmFjZjJGVWNVUkRxRFU0MXdVeFl3aWhi?= =?utf-8?B?MkFIZU1JRkZwM1hESktxWjBpaG5HTDNVRWxsODUvaVU1Uk92c0hnV0VjZmhn?= =?utf-8?B?N3VXbFU3dzQ3RkpISHBORG9Ea2pHUFZXRkZMckJKd2UxbCticngycU1GVHRD?= =?utf-8?B?RXM4NUNVMnRWelY0bE5rcUhLYWN0VUhwV1h2QWlFb2p6Q0laWFgvdWlqQzdO?= =?utf-8?B?L0VaTUhmcm9hT05OQllGbVZkZURBWmN2T3lTZHgxRnB1Mk04SU96ZVpaY2ll?= =?utf-8?B?aUQ0WUlMei9HRjJ6YXExU3BTd2xYdHFPOWMvdVRWYWVzeFkxbVhPTFJGMnFo?= =?utf-8?B?RHZVaUVhbjVuNkdWRThaMHRLWm03NGVtVnBEUXh0NVVWYnhNOHgvaHdPUTc4?= =?utf-8?B?bkVtckkwMXVKWlNJd2FFbjdOVjE5MXUxT0JEN0hiTGFReFJtemtGbWVFZVBn?= =?utf-8?B?dHdKazEwNW9YN0E5NHQyeVpFRzZyQUpSckJhb0h0Ui8xTkc3ZDNhRC80TGx0?= =?utf-8?B?b2pXZG1zM3ZrNWtHam02R3hlRldESUVsc1RnV1MrMHBIeEFDeVJwU21jV2xn?= =?utf-8?B?cGQzUlZVTWhnaTRVdFUzQXdSQ3o0ZlpnT2cxZFRqYk93V3RFRG9YcXV6dVhI?= =?utf-8?B?T0EwM3llZjR4S2Y2Y2cvOStwbUsybkxPc1pOWkI2Yi8ybzFFbldaMWpSYkEx?= =?utf-8?Q?NIskuVibY57/2ST1yg6LgrL8DfCPGuCs?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 6:dOGZyHa1p2oYrur3V4EuitvRD7UCe33fPkWCe+hTbZGrOGfuHaol5/xX7jw9+lA3VScN185vIn3bC994zQINSiKFAOVhGTTXFTgj1J8SSCuTOAU3CpLrizYmdLdxM2JfOsuiqPUgatXi4NtmA/WqVitimW3heiPA+M6pEo8qe/UDX/w7UNv5ezm5jvVwv/Yf2+FkNj00sCb0EarVdsZPw8dDA22u8pSZDD4COdodk8w/SsSmXvGhGu5WfPZrv+CmwTLb0IO2scmvlKZhHJoLmfBn01UdpqJnPKPOTwqAZnk0WSd2fOe0Ie1uh5fGqEL1PXtwL7+5Pz5/kWjtwW/QbyTC81Mr4j4O5kBh9eUKFkw=; 5:L8uduRUC5DHVrURH5chN694Hrt0w4nItIWWn+kS3EUflQAuRr1NeB722oW1F9+pB7U3WA+S0r4/vqCebuvCVdDkqe1+JWYeMxupYJbZfsnERfdpyEXqE5GH2/EKyIr6Nyw/DYg+TfhVBcAc5qw4sl0YMgmw1iekTYSlIbv/cQRI=; 24:o9jiz/LcbUK7qOLu0pI2980qimEz5Xv598of4qjh4CUkVaUf0SJUbL/KNfkY+4MsyZRrCmjpGMLc3hCEgbpcZBvglFz4aUAtgXavUyGNyBU=; 7:Clnfp6pckSsuNZoQZHLgzR+AZ4YM7r7H4xbh+rv1Mvspo4HAzWajlYpNZH8vFKgJ9ne2KHQ4PQ+JQ55pT4G9vIodAW3non83gqqbqmDsJh5Tqu/wpdBdhgi2A3xyLzvvSaiD0Vv2By0CLIKaRetcGHb9gWcGQn1Pz/+AJs98nf7tdxzSI8ECmrYaSSpx3wGV0XQ24RWtxgIBeOGguCO/ZxKqFQJh2I2suTtP0qkYmzcwsd0Co/i7pW/8osRJTR4H
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 10:12:24.3348 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a43f65da-b8e1-4c08-4bda-08d52c115eda
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3428
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUyM2K7sS6vME+UwZ9OGYt9V/8wWnR3P2O3 mH+xkdWB2WPK742sHkuW/GTy2PhrMUsAcxSXTUpqTmZZapG+XQJXxqQJ7xkLZnFUzL72gLmB cQlbFyMnh4SAicS6ue+Yuxi5OIQEDjNK9Pz8zwrhnGCUWLhtDliGRaCXWWL9yplQZbuZJD78 e8EK0i8s4Cmxr/MPmC0iYCXxrv01I4jNLCAqsf7iJSaIhquMEt+6P4Ml2ASMJKb2n2cBsXkF 7CV6N55jArFZBFQlms78ALNFBWIkJj64yAhRIyhxcuYTsHpOAUeJrhkHoRZYSMycfx7Klpdo 3jqbGcIWl7j1ZD4TxHMWEi/eHge7WkJgGqPE39+7wRqEBDQkHl74ywpRJCtx9OwcFgjbV2LF hfWMEA0zGSUWnTrHCuE0sEtM/NwIVaUl0TF9A9gkRoE4iZ1rFkIV7WCX6H5xC2p3tsTMuZuh 7EiJiXfPskMUXWGV2N1ylR0iISNx8sZexgmMOrOQ/DoLyX+zkPw3C8l/CxhZVjGKFqcWJ+Wm GxnrpRZlJhcX5+fp5aWWbGIEJpWDW36r7mC8/MbxEKMAB6MSD28MG0+UEGtiWXFl7iFGCQ5m JRHe5H7uKCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8HiJAKYH0xJLU7NTUgtQimCwTB6dUA6P6 Zr+FXBvustfKfTmztEg8nMngx66Xs0skrRjOPZ6s9O9G4zsZu5RjtrveRuhUle8R7r18ITeV ySrn0qby4kzr/aaR/fPaPFLmbvibWHW6/5HN5b9Mzg9+bVw4Y09diCr/trTrXxbu6pndnWCp wcySdm6lqueDJ+16STyBpTPOFPk5vK19ka7EUpyRaKjFXFScCAD4TYneJgMAAA==
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:12:33 -0000

The server MAY implement obsoleted nodes or MAY NOT. This may or may 
not  is not good enough as a contract for the management client.  My 
problem is that the current solution is just not good enough. IMHO we 
need to change it.

Even after semver you can still obsolete the old stuff and provide the 
new stuff with a new name, although that might not be the common 
practice.  Which is a good thing, as I believe it is sometimes better to 
correct existing definitions then to replace them.

regards Balazs


On 2017-11-15 16:53, Martin Bjorklund wrote:
> Exactly.  With the current solution, the sever can still implement the
> deprecated or obsolete nodes in order to support old clients.
>
> With a MAJOR update in a semver world, it means that the old nodes are
> removed (or rather, possibly, that the old nodes have new syntax
> and/or semantics).
>
>
>

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


From nobody Wed Nov 15 02:19: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 93817129571 for ; Wed, 15 Nov 2017 02:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 61_nLKFST2LT for ; Wed, 15 Nov 2017 02:19:37 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D845129480 for ; Wed, 15 Nov 2017 02:19:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9611; q=dns/txt; s=iport; t=1510741177; x=1511950777; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PlwN5V0DrGygrmXkw7hWJBfBH+S0urovv0WyN84uiyA=; b=eNzm31xHEKMTdkLK4EpaRshCYg8kq8sgamEAHtxcPCZzyHwEjdt25aQl aeSNHUddgst61+Pm4aHPcDqCxqDJkrtxsooiKAro1vPCD4ZQLGPThq4p2 2Y2W8UZo20egslP4yFiHFUumW/5WQ2jTY2JyQ3oaoS2q70YrUebFSCHVr I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAAAVFAxa/5hdJa1RCQMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgzZkbieDf4ofjyGBfZZaEIIBChgLhElPAoUHPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUeAQEBAQIBAQEbBg8BOwsOAgsOAggCAiYCAhsMMAYKAwYCAQEXigEIE?= =?us-ascii?q?KdggieLFwEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQqCJYIHgVWCEoMBhFgBJwI?= =?us-ascii?q?JLiaCToJjBZFwAYEUjzKLVokwghWJaodFijKLe4E5HziBdFUlFUmCZAmCUxyCB?= =?us-ascii?q?SM2hh+CQgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="31822290"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 10:19:36 +0000
Received: from [10.24.101.203] ([10.24.101.203]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAFAJYRe029652; Wed, 15 Nov 2017 10:19:35 GMT
To: Martin Bjorklund 
Cc: netmod@ietf.org
References: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <20171115.095341.1585161898755400575.mbj@tail-f.com>
From: Joe Clarke 
Organization: Cisco
Message-ID: <407c8a67-dfea-da19-96a7-b65f9523d8de@cisco.com>
Date: Wed, 15 Nov 2017 05:19:33 -0500
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: <20171115.095341.1585161898755400575.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:19:39 -0000

On 11/15/17 03:53, Martin Bjorklund wrote:
> Joe Clarke  wrote:
>> On 11/15/17 00:30, Juergen Schoenwaelder wrote:
>>> Another thing to consider is that foo and foo2 allows an
>>> implementation to support both during transition, with foo {semver
>>> 1.x.y} and foo {semver 2.x.y} this may be harder.
>>
>> I'm not convinced this a bad thing.  If a server supports multiple
>> versions of a given module, which should a client use?  Did the server
>> vendor test each one?
>>
>> I suppose my gut reaction to Lou's question as to whether a server
>> should support multiple versions was, "no."
> 
> Exactly.  With the current solution, the sever can still implement the
> deprecated or obsolete nodes in order to support old clients.

I'm not convinced a vendor would do this in reality.  Though I suppose
they could advertise this with a deviation.  There would still be
additional burden on the client.  That is, the client would want to make
sure that the obsolete nodes are actually supported by this server and
not just there returning potentially bogus values.

In a semver world, obsolete nodes could be reintroduced with vendor
modules via augments or in proprietary trees.

> 
> With a MAJOR update in a semver world, it means that the old nodes are
> removed (or rather, possibly, that the old nodes have new syntax
> and/or semantics).
> 
> 
>> A client may have multiple
>> versions loaded to support servers that support different versions.  I
>> may be convinced otherwise, but I feel that this will become untenable
>> over time (even if module names change).
> 
> I think the proposed solution will make it even harder for clients,
> since the same paths will mean very different things on different
> servers.

I agree there is burden on the client, but the client would know of
these differences assuming yang-lib and capabilities report the right thing.

Joe

> 
> 
> /martin
> 
> 
>>
>> Joe
>>
>>>
>>> /js
>>>
>>> On Tue, Nov 14, 2017 at 10:22:10PM +0100, Juergen Schoenwaelder wrote:
>>>> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
>>>>>    Whenever a client OSS implements some higher level logic for a network
>>>>>    function, something that can not be implemented in a purely model driven
>>>>>    way, it is always dependent on a specific version of the Yang Module
>>>>>    (YAM). If the client finds that the module has been updated on the network
>>>>>    node, it has to decide if it tries to handle it as it did the previous
>>>>>    version of the model or if it just stops to avoid problems. To make this
>>>>>    decision the client needs to know if the module was updated in a backward
>>>>>    compatible way or not. This is not addressed with the current versioning.
>>>>
>>>> The current rules aim at guaranteeing that definitions (with status
>>>> current) remain backwards compatible. Do you have an example what the
>>>> current rules fail to achieve this? Definitions with status deprecated
>>>> or obsolete may not be present. But if they are present, they have the
>>>> same semantics. This is the promise made to a client. (Note also that
>>>> objects may be absent for reasons document in deviations or simply not
>>>> accessible due to access control.)
>>>>
>>>>>    While having PYANG based checks for backward compatibility is a very good
>>>>>    idea, a  comparison based check will never be a complete check. It is
>>>>>    quite possible to change just the behavior of an rpc/action/etc.  without
>>>>>    changing the YANG definition.  This will only show up as a change of the
>>>>>    description statement that can not be analyzed by PYANG.
>>>>
>>>> The problem is to decide whether a change can break client
>>>> expectations or not. Even 'bug fixes' can cause a client written to
>>>> expect the old 'buggy' behaviour to fail. Also tricky are situations
>>>> where behaviour was not clearly enough described and this is 'fixed'
>>>> in a module update.
>>>>
>>>> Semantic versioning assumes that one always can clearly distinguish
>>>> between incompatible updates and compatible updates. This may not be
>>>> so clearly cut in practice, see above. (But then, we have the same
>>>> judgement call at the end with today's update rules.)
>>>>
>>>>>    When upgrading a network node we might introduce non-backward compatible
>>>>>    (NBC) changes. Today we need to introduce a new module for this. That
>>>>>    means during the upgrade process the node must convert stored
>>>>>    configuration instance data from ietf-routing to ietf-routing-2 format.
>>>>>    Instead of solving this data transformation/transfer problem just for a
>>>>>    few NBC data nodes, we will have to do it for the full model. This is
>>>>>    complicated. In many cases the transformation of a few NBC leafs can be
>>>>>    handled by good defaults or with a small script. Transferring the full
>>>>>    data set is more complicated. If we allow NBC updates in some cases this
>>>>>    problem is avoided.
>>>>
>>>> In XML land, this is mostly a change of the namespace (not of the
>>>> prefix) if one keeps the same structure, no? In JSON land, the change
>>>> of the module name more directly becomes visible in instance data; but
>>>> this is all encoding details.
>>>>
>>>>>    If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
>>>>>    the prefix?
>>>>
>>>> I guess you mean the namespace, not the prefix. You can use any prefix
>>>> you like.
>>>>
>>>>>    In one sense it should be kept as it is the same module
>>>>>    "logically"; we also might have stored data including the prefix
>>>>>    (identityrefs, instance-identifiers). On the other hand having multiple
>>>>>    modules with the same prefix is a problem. The only good solution is to
>>>>>    allow incompatible updates in some cases.
>>>>
>>>> If we move towards allowing incompabile updates, then we need to have
>>>> a mechanism to tell which versions of modules can work together and
>>>> which combinations are affected by an incompatible update. We probably
>>>> need to require strict import by revision or at least 'import by
>>>> compatible revision' (whatever this means at the end).
>>>>
>>>>>    CH 1)
>>>>>
>>>>>    You write
>>>>>    "The YANG data modeling language [RFC7950] specifies strict rules for
>>>>>    updating..."
>>>>>    and again
>>>>>    "When the same YANG module name is kept, the new YANG module  revision
>>>>>    must always be updated in a backward-compatible way."
>>>>>
>>>>>    I strongly disagree. While we have strict rules about even small
>>>>>    modifications to existing schema, but you are allowed to
>>>>>    deprecate/obsolete big parts of the model, thereby possibly deleting
>>>>>    complete subtrees from the schema. That is anything but strict backward
>>>>>    compatibility.
>>>>>    I find this aspect of YANG inconsistent to the level that it would need an
>>>>>    errata.
>>>>
>>>> Marking something deprecated / obsolete means you can not be sure this
>>>> is implemented. But then, even definitions with status current may not
>>>> be implemented (see deviations) or they may not be accessible to a
>>>> client due to access control. However, if implemented and accessible,
>>>> the guarantee today is that the semantics stay the same and don't
>>>> change unexpectedly.
>>>>
>>>>>    So practically the current rules allow backward incompatible changes that
>>>>>    can only be detected by a line by line comparison of the yang modules. In
>>>>>    a system with semantic versioning, you could determine backward
>>>>>    compatibility just by reading the version numbers.
>>>>
>>>> I do not see why you need a line by line comparison. With semantic
>>>> versioning, you _hope_ the semantic version number is a good enough
>>>> indicator. It might also be that your client is only using a subset
>>>> that did not really change even though the semantic version number
>>>> changed. Or the semantic version number indicates only minor changes
>>>> that sill break your client.
>>>>
>>>>>    CH 2.3)
>>>>>    As we need to create a new Yang Module (YAM) even for the smallest
>>>>>    incompatible modification, this increases the number of modules.
>>>>
>>>> So it seems to boil down to the question whether foo and foo2 is
>>>> significantly more expensive than foo { semver 1.x.y } and foo {
>>>> semver 2.x.y }. The main argument seems to be that the later keeps
>>>> references that involve module names or namespaces unchanged (but
>>>> they may or may not mean different things).
>>>>
>>>>>    IMHO YANG package definition should be a separate issue, left out of this
>>>>>    document. Andy has already provided some very good ideas about this topic.
>>>>
>>>> I think it is necessary to think about how the semantic version
>>>> numbers are used. See my remark above about imports. If we allow
>>>> incompatible changes, than this has side effects and I think we are
>>>> not done by just adding a semantic version number without going
>>>> working throught the implications.
>>>>
>>>> /js
>>>>
>>>> -- 
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103         
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>


From nobody Wed Nov 15 02:21: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 F15ED12706D for ; Wed, 15 Nov 2017 02:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level: 
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 IgCvRL_CMYaO for ; Wed, 15 Nov 2017 02:21:15 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E95E129501 for ; Wed, 15 Nov 2017 02:21:15 -0800 (PST)
X-AuditID: c1b4fb30-a0dff70000002554-92-5a0c1519ab0a
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2F.FB.09556.9151C0A5; Wed, 15 Nov 2017 11:21:13 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 11:21:12 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MV2Q6rrzVVWBLmrEUDWotxVUMKY9DMH8dI1s5sgS0aE=; b=BkdsnLeU2syNUa+XBWBxrm+/EbaWGsalByPfn2yKeNeg66wdkJfbkAhYS5SaOS8wV4aoZDuzImbvp5yJjbE5+Safwjx7Lrt15ts8X720L4h8jAB3gvbhYGAVMltgcGcEby7J5PNeQi68QjTnO+lbQ9SclLtZI4b78E1PwEUjE4I=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [IPv6:2001:67c:370:128:e196:b266:ad4f:77e2] (2001:67c:370:128:e196:b266:ad4f:77e2) by AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Wed, 15 Nov 2017 10:21:10 +0000
To: "netmod@ietf.org" 
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com>
From: Balazs Lengyel 
Message-ID: 
Date: Wed, 15 Nov 2017 18:20:51 +0800
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: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [2001:67c:370:128:e196:b266:ad4f:77e2]
X-ClientProxiedBy: CY4PR22CA0072.namprd22.prod.outlook.com (2603:10b6:903:ae::34) To AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 89e40dff-7182-40fa-1ab7-08d52c12980c
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR07MB3425; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 3:YIFb5Kuv0vZSVfySfv7a2ekRt2nK8bpz7tfE0bx0k2ymyA8GH4Y6OPCFprXqLFWy4NOjwQCpCc4tcTGCHsD5kyTzX7F/aGwWp2lFvDIiFPPcnsJVApJi1FqcK10xXwdG1n+EV+q54J0mjyJFFYrQUUrZ4PyBVeua+Jx1XFZsbl4QOqHa98u7ggnJLyjX0WB/UAigv2ObNdUBXfc5cQJOmXbkI3WUSDHZ9sxplZQ67kTGBmRRgXW0hTmRRweFPWba; 25:NA6keh/lkMIN9/kikpJvmU07OIJZT9yBdWdskGsnBg9tbXr+mjdDOrFWLXkCzQANBAuj8CbkHEZ15yOcm9I62EvyS27CiRJUlBDoRka/DpUyGihZJ+sjzPNSDBSAjFLOQIhDlTjPp7WOrgscYRO8qFe/fBIWlB2JdShpEddAJb8qqGXpmGbZ7YrhIhQlPeFsPkuyNBHV8YnqMLctT/ap2oVDI7U7PkOSQ0zUSSm+i4YSlr9ZFt04jhquWXtgslrVr2FGwg1ITUcJIJb1zi61hzsnn3lCwarOl02KRoU56TP0uEQ2+CFjVOj0FqoYgE6BvtXu0JFQv0CUEXMMcNNOJd1pd1+KzKpuCPB45BbnokA=; 31:3WemoNEpXWKfpQN/pajdVNWiaS0z5PV0ENmxAzjLifR/oZGM1LHC3z/hqcKr5Re4EYO+QXIJTYuNEVV08XEtW856k5HTEyk5gUcMafVfd7AoCznKUINbhgKse023gv+GkE/gP54HAd//F9DH3AdTob4VVAsZQEKVnHl9o8REh5DoA3fAMKvqwwDuqqJbKZy5X+2RkSj090teBJbdFG9KwqHKaMm5ltnKe02zVceEcKQ=
X-MS-TrafficTypeDiagnostic: AM4PR07MB3425:
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 20:RDpvm0rrXyF1Ldeub54a37kztj0cFZCekmBeLkBR3U4t40qA3GK5cxZOKDeYt67rPB2v8x8Pqmuf4t/Rzn3CaMBxaH+0JSF/uXeRykhJROiCT6qmm58NDJBtsoTBNCjXN0qIN7ts7DMMto5wWRK8mRz3OO2rwrEl/q9H6UQZglEEWUMQ+fWCOyuoOSNY4i4/L66132CueY6k6poQ2OL91TblknmqvPkRJag1a0yV/RDoEnOetFIgCis53Plc0O2k2Do4GIZhFi5kbPj6mr+pMqtrzpRw/QBOahPZffImMltu45e/dinAm/d5YmXFI22x0xJaRTtnEaOYdutt7Mb5TTqT3uJDXLIZf/IQBu7JLoTdc00oBur/hfDoN+Cv77cVRCGnJ/tHfQuS7AsilEeoD3KzOfWeVIkdik/LLuzgzBGd4kKh9Hk0Y0ptJjgmOvj0x2dpAYEgKPDRaXPBJUFUz5bfLxVFm0sUvVeBAa0p83MS375BQCbj+LitFGb23GnR; 4:GXOV/vr2eNpAZMIJI7cgs5nA6oqZU0hfb2c8kkEsClh+7Y720U9Se2hqhU57c2m7RpySoBb+PVzfqOKoT88+eQP5dxUVpVjWyplu2f5xG9Mon1Fm8SXpExqKvIfRTj4CKr/6w9mSk3O2pkyrOPLxLFgTeHenTbbSz2brPeK/atr8jBzuYf73qyRibK4mbyXUtuN0FMNr4qaC1XDyzIxhOjcvCLmb3+A2LOUOz7bvHwX1eeHB19eq+d4/zLUSdJAd6Y1XsoJ4rnR6eM7fjv6GYVEt4wKQJhNC8A7dqxz6E/xFuobaAQIX9Muc2XyFZsL1
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3425; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3425; 
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(24454002)(377424004)(199003)(252514010)(189002)(23676003)(2950100002)(31696002)(86362001)(23846002)(8676002)(2906002)(68736007)(478600001)(5640700003)(1730700003)(76176999)(31686004)(58126008)(50986999)(54356999)(189998001)(64126003)(6486002)(81156014)(7736002)(4001150100001)(97736004)(230783001)(2870700001)(83506002)(36756003)(81166006)(8936002)(15650500001)(65806001)(2501003)(2351001)(53936002)(25786009)(106356001)(65956001)(236005)(33646002)(1706002)(6666003)(6916009)(316002)(5660300001)(50466002)(65826007)(54896002)(229853002)(6116002)(6246003)(53546010)(101416001)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3425; H:[IPv6:2001:67c:370:128:e196:b266:ad4f:77e2]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI1OzIzOmY1R3BsK1ZBTFUzZy9LQjBZYlN1WVpsa0hT?= =?utf-8?B?SFlWSkVsZUtuWXpqeC95aHJlMVZqNDZjQlZxdEdKM3lxYmNwSm5kMWhwYWZ6?= =?utf-8?B?SklxZUpqOFhnQ2xPQUlycURvV1lpNmcxUldRYXpGTSt0SkE2ckhpTUwxUkp0?= =?utf-8?B?MEJ3UzEwRjUvVE15aGFpRWNDNUxCVWlzYVIxa1RwWTU3NkU5ODlVUWduKzU1?= =?utf-8?B?ekVXREFYdTlnNjlRSllkd3M5SDUyWUo5MTREZ0toR1dLNEFJazlGeTNwb0hn?= =?utf-8?B?RW9ETmVhaXB3RkVTTXhmb0phNUNzUEVHWEQrYzZRSlNUY2tqcDQvR1E0bTNV?= =?utf-8?B?UkJUSy95NUVZZXV2V0JpcytCR3VHcmRGMElQRUxFYzdOdkt0Zm5ZbTdhK05V?= =?utf-8?B?bHhUQTZEVjRzS2x3NWlxdmZMb0hJbFRjeFNFZ3FKVXE1SmpRcG91aHVIdzcx?= =?utf-8?B?VEp6cUx1WEpwNnFIbVIvWEljYWU3bDg4MFptdTc4SlExYTY5UElNTWpFZmpi?= =?utf-8?B?NS96NlFOaStleFZTUFBOL0dZSWIxeUNoMy9xREdycWxkV1dxWUZCUnZvZ1Rh?= =?utf-8?B?b0xQVVpTSTNSbW5vVjVkMWFmRTVIYUlkNU5USGhBTUU0Y0xkcUZEelpxMVI4?= =?utf-8?B?bC9wR1VXNERPdlVFZUcwSWNxalVTNGR2YlJJblBhRFd2WWFENDM0ejVsR3Nm?= =?utf-8?B?YVVPbUxmSUtMSmxzbHlWdFVQR05pbHZvdFoyN1dDQ205UGtuUXVwYkZVSHlF?= =?utf-8?B?cmlnQTh6YlFLdFVGTHYwR1c0WG5BcjBCVkFOYnUyYy9ueXpHdDY0Sy9iZFVP?= =?utf-8?B?azdtOWplaUJWcDM5M3lEOVJzbmd4dWlYa3RxQ25jWGpVbERWUHpjNzhxcENH?= =?utf-8?B?VFIvc01UdWE4RWxzMUJQS1dOTHFLT093YzU1MFF2OWVZQWFWUk9kdzFKNHZF?= =?utf-8?B?d0FTUGpVK2FaY2J0T2kvMTZ1RVpSUElDejdiek1Zd3J1Ulh1MkN1Skl4Z29P?= =?utf-8?B?NTlEQ1NKT2RQaHJDT3FUVnZ2ODB0WFZBSmVMVGR3VDZuQUxoN1JoRHVpZDBP?= =?utf-8?B?ZVk0cCtwc1VObnN0bE42M3hWMXBpL2M2SzJzL2ZOTDNqWjdtZCtRbW5KSDRT?= =?utf-8?B?eWFub0FIZ3M2M3ZnVTJreS9qWmtHRTY2Y0s0WUo5eGZYS3BXRXJvb0R4OU9q?= =?utf-8?B?WUlCMVIzbFFxTXpITTdWYWFJU0thQ1lpTzFzVkNkWFF2TUJRS3JpR3Z1ZzFP?= =?utf-8?B?UFpsQ3crbVBKYjRRS2tHWVk0RjkxcGppZUU5eDBjUGd2eFdhQnBYdDlqeVdF?= =?utf-8?B?Q2sxdENRUnVkUGVKY3JOK1B6bWxOdU96ZTFSNlpOcDdIRlVXRVh2T1BUZk1P?= =?utf-8?B?M3FFVEJOUThWYWx0MS8vL2dueXlXSUp2cDFBcGFlb1lBakRrOTdRTTFGbk9k?= =?utf-8?B?azFNQjV1QzdyRldFclAzbzVtdlVaR2p6cVNHaDdSV1FVSUU1aE0wazAyRmpN?= =?utf-8?B?ZzBkMW5PSklHVFVrSlliTkRoaEFWcmhhSlJ6dTRlMnlOMkR4c2VQRXhwMUxW?= =?utf-8?B?MVI4NGhzdE1WMmM5RXdBNG5ZZlFsNkp2T0YyNlk2cElZcmhDVG5yZWYwN216?= =?utf-8?B?dXh1dk9IUEFzUDd2VTlIazlOWUZ4ME9qU2ZNWDhCbStHMU9UOHg1Q0NwT2RO?= =?utf-8?B?SW0yeXFiM3NRZFFURzB6V2paU3Eza2g1eU90RTM0ZENsOFUwTlA4aDBVN2Er?= =?utf-8?B?ZVBWcFRlVzZwcCtYcWl6MW03Z0JMVTUxbmhqcTBzNGJobVRreW9WN3J4RFJG?= =?utf-8?B?ek55aS83dk03c3FmaE5RV2YvVHVUQXdEaU1oMEdvWXo1bTkrcGhsNU1ES1dU?= =?utf-8?B?RTdEK1B3bVRxTHVSTWg3OFFHODEwKzJCZU8xL3RJK0ZrRHo5ZjFOTURpdVlK?= =?utf-8?Q?Fi6iAc2YqrCQTJyc2iev/d6mcikQz4=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 6:DNkuY5jKzOouSvUWyYnwQUcD6YBG9i77BR3PGzf+e3Dv2Fi7xLiWSFZcU9hwV7j6LOuacapdgBcGyVTQF+7Yb3LGquTA2oFEeReBqR61XlcPjxCtlpharrSXy2D3ayONbKI4MLcTQO9IohAaGnIM0dLxpC/409f+THwRod/okiRXY3E3WogNOtAr12tZZ8xU2nGRwhYtODISymPRq9HwGnTOnCAmT+B80+Qb6Te679dHCRSFc7rm9EMU8k/SPKDfbO6q01bGs7uZyabzGX3168yRnD2wvFysRhdr6VzmQOqdy1VEO1JZK25Kjgs6yrsZAt7veMRh/oY7N+mDdSvaFkdfOLpG591LLD3ZhtToO7U=; 5:7mgGlIzMmELNsOVuUZQujeA69HYAcCDF5E03L+Jf5MxcZnv9BdTwkGWdxi4YgkV90MzztcoF+8vUZusPCnt8V2la6DMDLfkggsGXqMaopC18bkuqG5BGOS4qYuq3Gyq8zboKvl/+nLS5sOJpjsHDi/z9NZI47XNO+1aujYBlQRs=; 24:B84YSHjzfmM5feIMmk3utA8oTHPKvtdlnkqMBDwGRT9E4SCKkhO3vhwt7T6cnyzOnzp0Rt6gLgDOImF/jsot7CH2MdrxdLhLeHDt/lXDROs=; 7:6z8rzpuTFi/wgVbGVDe4fnuwSIzYdyZYYxUArPnFM5xh4ATIj+a5glGZFJ7oNt+3ohxz9pqGOsTvydfnLLPW/s9wJlvSl6w+0Aj6HtLYh7MNcEbKXpkvlCLwPEZ2TmVye9qKQOg55G4dCCozoxlnG885IY9poo02rnZFaxGkbBXs33Y7Cjofd7AgabB2BlPL56EI9OvO2TGUlVAWvnf7jWJapKTsANltnlgsxeSDuCm4Fws882xicH3wWNN8tZNK
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 10:21:10.3506 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 89e40dff-7182-40fa-1ab7-08d52c12980c
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3425
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUyM2K7q66kKE+UwYFp4hbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEr485S6YLVlhXXLwc0MM7X7GLk5JAQMJF4+X4jYxcjF4eQwGFG iY8b7rNBOCcYJXral7OCOCwCvcwS96/uZgFpYRSIk9i5ZiEriC0ksJtJ4tsUUxBbWMBB4tTn C4wgtoiAusTMneuBJnEA1dhLLHhfARJmEzCSmNp/HmwML1D4xemdTCA2i4CqxLoDJ8BsUYEY iYkPLjJC1AhKnJz5hAVkDCfQ+Pbj4iBhZgENidY5c9khbHGJW0/mM0HY8hLNW2czQzxmIfHi 7XFmkPMlBKYxSnQs2A11sobEwwt/WSGKZCWOnp3DAmH7Siw+94IRomEmo8SnlZdYIZwp7BLH b3+CGqslMePIMjaIxA82iScHHzJCJLIlFsz9AVVkJfH613eoUVdYJRa/nAhVJCNx8sZeqMQy Non9D5+xTWDUnoXk11lIHpyF5MFZSB5cwMiyilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMw RRzc8ttgB+PL546HGAU4GJV4eDU5eKKEWBPLiitzDzFKcDArifAm93NHCfGmJFZWpRblxxeV 5qQWH2KU5mBREuf1EAFKCaQnlqRmp6YWpBbBZJk4OKUaGFMDl0exH1cJrY6ZMHu9YXjfjQoG nWWnNH5OfRx1xs9UNvDcvicKj+POrD89J/bxapnUrU+XrlaOUWF9dnJtmZGOoaS717SKC7Jz jj95zsZy91Zl55KlPZ9iny1M/3TR6POrSbsLKtit3J5f2Bjy50o0V/cDuZ6Pm7c3TpOz4d2t Vnpz0dE5FzcosRRnJBpqMRcVJwIA0QtUKw0DAAA=
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:21:21 -0000


  
    
  
  
    
Hello,

    
I would like to extend my list of base problems to 3:

    
    
      
  1.  Non-backward compatible (NBC) changes should be allowed in
        some limited cases
    2. 
      
  2.  It should be possible to determine two module versions'
        compatibility without a line-by-line comparison
    3. 
      
  3. It should be possible to indicate that a part of a schema is
        deprecated, but is still present, implemented and usable
    4. 
    

    
3) Is needed because we need to be able to warn the consumers of
      a YANG module (YAM) that some part will be going away, while at
      the same time we need to promise them  that it is still usable. We
      need a firm contract not a maybe about this.

    

    
regards Balazs

    

    

    
On 2017-11-15 00:51, Balazs Lengyel
      wrote:

    

    

      
      
Hello,

      
First of all Ericsson very strongly supports this draft. This
        is a problem we definitely have, and for which we had to create
        our own internal solution. So we would love to see an IETF
        solution!

      
General)

      
The document does not mention some other problems with the
        current versioning. These stem from

      
    
        
  • we should allow non-backward compatible (NBC) changes in
          some limited cases
    • 
        
  • it should be possible to determine two module versions'
          compatibility without a line-by-line comparison
    
        
    • 
      

      
Whenever a client OSS implements some higher level logic for a
        network function, something that can not be implemented in a
        purely model driven way, it is always dependent on a specific
        version of the Yang Module (YAM). If the client finds that the
        module has been updated on the network node, it has to decide if
        it tries to handle it as it did the previous version of the
        model or if it just stops to avoid problems. To make this
        decision the client needs to know if the module was updated in a
        backward compatible way or not. This is not addressed with the
        current versioning.

      
While having PYANG based checks for backward compatibility is a
        very good idea, a  comparison based check will never be a
        complete check. It is quite possible to change just the behavior
        of an rpc/action/etc.  without changing the YANG definition. 
        This will only show up as a change of the description statement
        that can not be analyzed by PYANG.

      
When upgrading a network node we might introduce non-backward
        compatible (NBC) changes. Today we need to introduce a new
        module for this. That means during the upgrade process the node
        must convert stored configuration instance data from
        ietf-routing to ietf-routing-2 format. Instead of solving this
        data transformation/transfer problem just for a few NBC data
        nodes, we will have to do it for the full model. This is
        complicated. In many cases the transformation of a few NBC leafs
        can be handled by good defaults or with a small script.
        Transferring the full data set is more complicated. If we allow
        NBC updates in some cases this problem is avoided.

      

      
If we update the module from ietf-routing to ietf-routing-2 ?
        Do we keep the prefix?  In one sense it should be kept as it is
        the same module "logically"; we also might have stored data
        including the prefix (identityrefs, instance-identifiers). On
        the other hand having multiple modules with the same prefix is a
        problem. The only good solution is to allow incompatible updates
        in some cases.

      
CH 1) 

      

      
You write

        "The YANG data modeling language [RFC7950] specifies strict
        rules for updating..." 

        and again

        "When the same YANG module name is kept, the new YANG module 
        revision must always be updated in a backward-compatible way."

      

      
I strongly disagree. While we have strict rules about even
        small modifications to existing schema, but you are allowed to
        deprecate/obsolete big parts of the model, thereby possibly
        deleting complete subtrees from the schema. That is anything but
        strict backward compatibility.

        I find this aspect of YANG inconsistent to the level that it
        would need an errata. 

      

      
So practically the current rules allow backward incompatible
        changes that can only be detected by a line by line comparison
        of the yang modules. In a system with semantic versioning, you
        could determine backward compatibility just by reading the
        version numbers.

      
CH 2.3) 

        As we need to create a new Yang Module (YAM) even for the
        smallest incompatible modification, this increases the number of
        modules.

      

      
CH 2.5)  We already have vendor modules depending on
        ietf-routing

      
CH3.1) 

      

      
I propose that the semantic version should be a mandatory
        substatement of the YANG revision statement. It should be
        updated every time, and it would be good to see the older
        semantic versions as well. 

      

      
I would propose to have 3 separate statements for x,y,z. I
        don't like structured strings. It would be much easier to
        compare simple integers.

      
I can if needed provide some more detailed rules for x,y,z e.g.
        if x is stepped y and z MUST be set to 0.

      
IMHO YANG package definition should be a separate issue, left
        out of this document. Andy has already provided some very good
        ideas about this topic.

      
I also think the current definition of deprecated and obsolete
        in YANG 1.1 is near useless, as all it says that both deprecated
        and obsolete items may or may not be there. We need something
        better.  

      

      
regards Balazs

      

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


    

    

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


  



From nobody Wed Nov 15 02:27: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 987CB129553 for ; Wed, 15 Nov 2017 02:27:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xpwGuQM1XUcU for ; Wed, 15 Nov 2017 02:27:22 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C3012954B for ; Wed, 15 Nov 2017 02:27:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=980; q=dns/txt; s=iport; t=1510741642; x=1511951242; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=dSiNs7ovqCZVb1EeAzn4r5EXyUqIGcpIj7RJDgiQ+AI=; b=QtiC0kC1uiYXnTaKeZ5ijVaYmvlIB9G+oaOuc3uQlNDwV7FITKknciQZ /O3LmwSix3SiaEA4Fw9F4O7IyAa8NuNyT/tfawXDpLxk7My7fjnwndecV t8skTzE9Lp1NLkKGH+/m0haBxYer25Tb+6T6U5hb2Hzoj5kIetkXJqUx8 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AQD7FQxa/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2gVKEJplAgX2WWoIRCoU7AoUHQRYBAQEBAQEBAQFrKIUfAQU?= =?us-ascii?q?jDwFWCxgCAiYCAlcTCAEBiiCneYInixcBAQEBBgIBJYEPgiWCB4FVghKDAYUCY?= =?us-ascii?q?oJJgmMFkwWPMpUGghWJaodFijKLe4E5JQExgXRVJRWDLoR8I4kXAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="31697972"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 10:27:22 +0000
Received: from [10.24.101.203] ([10.24.101.203]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vAFARKbh010441 for ; Wed, 15 Nov 2017 10:27:21 GMT
To: netmod@ietf.org
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <87inebdff0.fsf@nic.cz>
From: Joe Clarke 
Organization: Cisco
Message-ID: <2daae313-cbf1-c26a-c176-a3d31b57092d@cisco.com>
Date: Wed, 15 Nov 2017 05:27:20 -0500
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: <87inebdff0.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:27:23 -0000

On 11/15/17 05:06, Ladislav Lhotka wrote:
>> I suppose my gut reaction to Lou's question as to whether a server
>> should support multiple versions was, "no."  A client may have multiple
>> versions loaded to support servers that support different versions.  I
>> may be convinced otherwise, but I feel that this will become untenable
>> over time (even if module names change).
> 
> There are use cases for modules that are imported (i.e. not
> implemented): it could be that a module author wants to use some
> definitions from an old version of an imported module while, at the same
> time, other definitions from a new version.
> 
> The semver-aware "import" statement should be able to deal with this.

I think it could be, but I also think importing from different versions
of the same module feels messy.  How would this work with different
module names today?  Just use different prefixes?  Are there defined use
cases for this in the wild today?

Joe


From nobody Wed Nov 15 02:30: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 A2F89128DF2 for ; Wed, 15 Nov 2017 02:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K9wcJ_Q09w2p for ; Wed, 15 Nov 2017 02:30:34 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28BE12954B for ; Wed, 15 Nov 2017 02:30:34 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 755B665B; Wed, 15 Nov 2017 11:30:33 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id NKP7FFlTlazu; Wed, 15 Nov 2017 11:30:33 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Nov 2017 11:30:33 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 624BF2011F; Wed, 15 Nov 2017 11:30:33 +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 Rv2Ne2sIbhhK; Wed, 15 Nov 2017 11:30:33 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01D902011E; Wed, 15 Nov 2017 11:30:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id A2B754158E6C; Wed, 15 Nov 2017 11:29:04 +0100 (CET)
Date: Wed, 15 Nov 2017 11:29:03 +0100
From: Juergen Schoenwaelder 
To: Joe Clarke 
Cc: Martin Bjorklund , netmod@ietf.org
Message-ID: <20171115102903.yivnjvanrt4wdarh@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Joe Clarke , Martin Bjorklund , netmod@ietf.org
References: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <20171115.095341.1585161898755400575.mbj@tail-f.com> <407c8a67-dfea-da19-96a7-b65f9523d8de@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <407c8a67-dfea-da19-96a7-b65f9523d8de@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:30:37 -0000

On Wed, Nov 15, 2017 at 05:19:33AM -0500, Joe Clarke wrote:
> 
> In a semver world, obsolete nodes could be reintroduced with vendor
> modules via augments or in proprietary trees.
>

This obviously does not fix a client that got broken (without updating
the client). Is it generally true that clients always move at least as
fast as servers?

/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 Nov 15 02:34: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 B65BF126CC7 for ; Wed, 15 Nov 2017 02:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Dfn7OvMd5Vmd for ; Wed, 15 Nov 2017 02:34:21 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9668912706D for ; Wed, 15 Nov 2017 02:34:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=566; q=dns/txt; s=iport; t=1510742061; x=1511951661; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8qKEpzmSQs8US+JEho0A9rKRoy/MS/ziAmdEk+Pj3Qw=; b=l1XWu/ni0Qqg8XTbodLQzU3l5DPwWOtXPu2DDummeNrfmABvCw4syGvD M3edh2zBl5tYH7iVbgQ5Z2jgrPp2jNENSw8yCElX/t5GWxWqTJO1J3v1Y qY78IVS7Qt/ldUfvJNgVB6WpREe3zD134xj3Izwil2+roOkhYLslfi+4z g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAACjFwxa/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2gVKEJoofjyGBfZZaghEKhTsChQc/GAEBAQEBAQEBAWsohR8?= =?us-ascii?q?BBSNmCw4KAgImAgJXBgEMCAEBiiCnc4InixcBAQEBAQEBAQEBAQEBAQEBASGBD?= =?us-ascii?q?4IlggeBVYISgwGFAoMrgmMFkwWPMpUGgXwZiWqHRYoyi3uBOR84gXRVJRWDLoR?= =?us-ascii?q?8I4kXAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="320852483"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 10:34:20 +0000
Received: from [10.24.101.203] ([10.24.101.203]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAFAYIYZ001690; Wed, 15 Nov 2017 10:34:19 GMT
To: Martin Bjorklund , netmod@ietf.org
References: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <20171115.095341.1585161898755400575.mbj@tail-f.com> <407c8a67-dfea-da19-96a7-b65f9523d8de@cisco.com> <20171115102903.yivnjvanrt4wdarh@elstar.local>
From: Joe Clarke 
Organization: Cisco
Message-ID: <3868e5f1-b243-bce6-c391-20e7640158fb@cisco.com>
Date: Wed, 15 Nov 2017 05:34:17 -0500
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: <20171115102903.yivnjvanrt4wdarh@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:34:23 -0000

On 11/15/17 05:29, Juergen Schoenwaelder wrote:
> On Wed, Nov 15, 2017 at 05:19:33AM -0500, Joe Clarke wrote:
>>
>> In a semver world, obsolete nodes could be reintroduced with vendor
>> modules via augments or in proprietary trees.
>>
> 
> This obviously does not fix a client that got broken (without updating
> the client). Is it generally true that clients always move at least as
> fast as servers?

In my experience, it depends.  It may sometimes be quicker to apply
patches to a client versus update a server (or a collection of servers).

Joe


From nobody Wed Nov 15 02: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 654A4126CC7 for ; Wed, 15 Nov 2017 02:37:33 -0800 (PST)
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 QIwx7uO7ReJV for ; Wed, 15 Nov 2017 02:37:31 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B6D126C0F for ; Wed, 15 Nov 2017 02:37:31 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id 0A07D6423B for ; Wed, 15 Nov 2017 11:37:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510742249; bh=QF/X0dbKK7JFFSv3qcvvgISkFV2wQ/tkw807L7YWPto=; h=From:To:Date; b=YftvQOdYTItaBnduSTIKqvVCKKlNXu9NEvlv0zmY3YEZNhIz0i+SfKZjpfZNe8cdD NNULZ5aSyz7IxJx5qKH5COaZKO6pmE5ikwyg90s6esbJWHQGT+mEY58GKd+RYjJHek YnUdnoI/8L09hkEfkG5ZZKfOoVaGHoAtVBhmQbl0=
Message-ID: <1510742316.21877.6.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 15 Nov 2017 18:38:36 +0800
In-Reply-To: <2daae313-cbf1-c26a-c176-a3d31b57092d@cisco.com>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <87inebdff0.fsf@nic.cz> <2daae313-cbf1-c26a-c176-a3d31b57092d@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:37:33 -0000

On Wed, 2017-11-15 at 05:27 -0500, Joe Clarke wrote:
> On 11/15/17 05:06, Ladislav Lhotka wrote:
> > > I suppose my gut reaction to Lou's question as to whether a server
> > > should support multiple versions was, "no."  A client may have multiple
> > > versions loaded to support servers that support different versions.  I
> > > may be convinced otherwise, but I feel that this will become untenable
> > > over time (even if module names change).
> > 
> > There are use cases for modules that are imported (i.e. not
> > implemented): it could be that a module author wants to use some
> > definitions from an old version of an imported module while, at the same
> > time, other definitions from a new version.
> > 
> > The semver-aware "import" statement should be able to deal with this.
> 
> I think it could be, but I also think importing from different versions
> of the same module feels messy.  How would this work with different
> module names today?  Just use different prefixes?  Are there defined use
> cases for this in the wild today?

Let's say a new version of a module adds new enums to two different enumeration
types, but an implementor (for some reason) is only able to update one of them
in the back-end and not the other.

Lada

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


From nobody Wed Nov 15 02:43: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 A1C3D129426 for ; Wed, 15 Nov 2017 02:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 H_oPYSzQuwWe for ; Wed, 15 Nov 2017 02:43:00 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263D312706D for ; Wed, 15 Nov 2017 02:43:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24193; q=dns/txt; s=iport; t=1510742580; x=1511952180; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=eV1w6eCGHBzSP2ri6xVYxlJgIgS7g/oIJddha6XoYcg=; b=mI+7WcMEuggUQlK176qjcP6Ps1agG9rO9qac5u3GoKO3HI6Irb993g4F HlQpn8X+oMrkgxAOF3M6LRQofYpU0bkwBQ4Az9srqIxgNJqyLkbFG55Tu LeOMXsS6iepcYmnZC70Ys4lwfVXRt9DzmQEF9AOAZ/NVj7Jlh62tahAGo g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAADWGAxa/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4ng3+KH48hgVcmlloQgX4DChgLhElPAoUHPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUfAQEBAwEBGAkECwEFNhsJAhIGAgIjAwICJx8DDgYBDAYCAQGKIBCJd?= =?us-ascii?q?Z1ogW06ixcBAQEBAQEBAQEBAQEBAQEBAQEBGgWBD4IlggeBVYFpKQuCdoRlARI?= =?us-ascii?q?BCYMrgmMFijSHPZBGlQaCFYYKg2AkhyGOOYd0gTkfOIEDcTQhCB0VSYJkhGBAN?= =?us-ascii?q?oYsgjUBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="31830792"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 10:42:59 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vAFAgvAJ027718; Wed, 15 Nov 2017 10:42:58 GMT
To: Vladimir Vassilev , "netmod@ietf.org" 
References:   <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>   <8584c894-473a-f268-29f0-20de225fa7c4@cisco.com>   
From: Robert Wilton 
Message-ID: <47e8298b-20bb-fdbb-4181-9609a489a312@cisco.com>
Date: Wed, 15 Nov 2017 11:42: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] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 10:43:04 -0000

On 15/11/2017 10:41, Vladimir Vassilev wrote:
>
>
> On 11/15/2017 01:06 AM, Robert Wilton wrote:
>>
>>
>> On 14/11/2017 23:41, Vladimir Vassilev wrote:
>>>
>>>
>>> On 11/13/2017 04:27 PM, Robert Wilton wrote:
>>>>
>>>> Hi Vladimir,
>>>>
>>>>
>>>> On 12/11/2017 10:39, Vladimir Vassilev wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 11/11/2017 08:07 PM, Andy Bierman wrote:
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton >>>>> > wrote:
>>>>>>
>>>>>>     Hi Andy,
>>>>>>
>>>>>>     The NMDA datastore draft
>>>>>>     (draft-ietf-netmod-revised-datastores-06) mandates two
>>>>>>     constraints that must apply:
>>>>>>
>>>>>>     (1) All conventional datastores must have exactly the same
>>>>>>     schema.  Hence differences in deviations or features are allowed
>>>>>>     between these datastores. (sec 5.1, first paragraph)
>>>>>>
>>>>>>     (2) The schema for operational must be a superset of all
>>>>>>     configuration datatstores, but that data nodes may be omitted
>>>>>>     (sec 5.3, third paragraph).
>>>>>>
>>>>>>
>>>>>>     This implies that only the following differences between
>>>>>>     datastores are allowed:
>>>>>>      (i) a feature can be disabled in conventional (and/or dynamic
>>>>>>     configuration datastores), but enabled in operational (e.g. for
>>>>>>     configurable router-id).
>>>>>>
>>>>>>      (ii) deviations apply in all datastores, except that
>>>>>>       a) a deviation can remove nodes in the conventional datastores
>>>>>>     (if they were not configurable, like the feature example)
>>>>>>       b) a deviation can remove nodes in a dynamic datastore (e.g.
>>>>>>     like I2RS)
>>>>>>       c) a deviation can remove nodes from operational only if a
>>>>>>     server is unable to accurately report them.
>>>>>>
>>>>>>     (iii) modules exist in all datastores, except:
>>>>>>       a) a module can be omitted from conventional datastores (e.g.
>>>>>>     if the module is not configurable)
>>>>>>       b) a module can be omitted from a dynamic datastore (e.g. like
>>>>>>     I2RS)
>>>>>>       c) a module can be omitted from operational only if a server
>>>>>>     is unable to accurately report the data nodes within the module.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am not convinced that moving to a datastore-centric conformance 
>>>>>> model instead of server-centric
>>>>>> is a good idea.
>>>>> +1
>>>>> IMO yang-library:1.1 can and should be optional. As a first step 
>>>>> NMDA modules and the minimal protocol support  etc. can 
>>>>> be implemented without yang-library 1.0 to 1.1 transition (read 
>>>>> server-centric to datastore-centric conformance model transition). 
>>>>> draft-ietf-netconf-nmda-netconf-01.txt requires migration to 
>>>>> yang-library:1.1. I do not see good argument to support this 
>>>>> limitation and there are usecases that can benefit from NMDA with 
>>>>> uniform datastore model design.
>>>>
>>>> YANG library bis is the mechanism to indicate which datastores are 
>>>> available to the client.  E.g. a NMDA compatible client would 
>>>> attempt to read YANG library bis on the new path using the 
>>>>  RPC to determine whether NMDA is supported, and what 
>>>> datastores are supported.
>>>>
>>>> The existing module-state path in YANG library is preserved, but 
>>>> marked as deprecated, so the intention is that it can be made 
>>>> backwards compatible to clients.
>>> I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library 
>>> Capability'  states exactly that. IMO this text can be changed and 
>>> allow the case described above ( implementation with NMDA 
>>> modules implemented as indicated by yang-library:1.0 uniform model 
>>> applying to all datastores. For cases where the datastores do not 
>>> have common model yang-library:1.1 should still be mandatory). In 
>>> other words if yang-library:1.0 shows implemented 
>>> ietf-netconf-datastores  and NMDA modules listed as 
>>> implemented will not need yang-library:1.1 implementation which 
>>> takes one obstacle out of the way to rolling NMDA module 
>>> implementations.
>>>
>>> Is there an argument making the proposed change unreasonable?
>> Yes, I think so.
>>
>> In an NMDA implementation, the YANG library information reported in 
>> the new structure can be entirely accurate.  I.e. it can report which 
>> modules are available in which datastores.
>>
>> Of course, it is not possible to represent this in the old YANG 
>> library, so the information that a NMDA server provides via the old 
>> YANG library could be inaccurate.  I.e. I think that it has to report 
>> all modules and deviations as being reported in all datastores.
>>
>> Hence the only way that a client would be able to know that it is 
>> talking to an NMDA server with modules not implemented in some 
>> datastores, or with deviations in some datastores would be for it to 
>> query the new YANG library path.  The new YANG library structures 
>> that we are proposing below are intended to be easier for a client to 
>> determine this, e.g. by checking whether any of the 
>> "not-implemented-in" leaf-lists are populated.
>>
>> So the aim for keeping the old YANG library path is to inter-operate 
>> with old clients that don't know about NMDA, and hence would not be 
>> expected to use the  or  RPCs.
>>
>> Thanks,
>> Rob
> I still do not see an argument against supporting  NMDA modules with 
> yang-library:1.0 in the case when and only when there are no 
> deviations and the implemented module sets are exactly identical for 
> all datastores.
OK, so when a client reads the YANG modules on the old YANG library 
path, then how do they distinguish between:
(i) the information is accurate and correct
(ii) the information isn't precise because there are per datastore 
differences.

Thanks,
Rob


>>
>>
>>>
>>> Vladimir
>>>
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>>>  I get it that it is supposed to allow the server to accurately 
>>>>>> reflect its implementation,
>>>>>> but it actually says that servers MAY implement whatever partial 
>>>>>> subset of a module they want,
>>>>>> and a client MUST deal with the mess.
>>>>>>
>>>>>> IMO, YANG says that features and deviations are server-wide, not 
>>>>>> per-datastore.
>>>>>> This new complexity is non-trivial to implement, so it may not be 
>>>>>> widely supported.
>>>>>>
>>>>>> The WG seems confused about the difference between a conformance 
>>>>>> model and capabilities reporting.
>>>>>> (ii)(c) and (iii)(c) is about reporting, not conformance. There 
>>>>>> is still no way to express
>>>>>> trivial use-cases in the conformance model such as "this module 
>>>>>> is intended for the I2RS ephemeral datastore only"
>>>>>>
>>>>>>
>>>>>>     Changing the type of a node between datastores, or changing its
>>>>>>     properties is not allowed.  The only difference allowed between
>>>>>>     data nodes in different datastores is the nodes existence.
>>>>>>
>>>>>>     These rules seem more restrictive that what a server using split
>>>>>>     config state trees (IETF style, or OpenConfig style) can achieve
>>>>>>     using deviations today.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Lots of rules to enforce actually makes the code harder, not easier.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On 09/11/2017 19:33, Andy Bierman wrote:
>>>>>>>     Hi,
>>>>>>>
>>>>>>>     The new structure still has the same problems for the client as
>>>>>>>     before.
>>>>>>>     It is a major change in the architecture to have different
>>>>>>>     schema trees per datastore instead of per-server.
>>>>>>>     The server is allowed to have different features and deviations
>>>>>>>     for the same objects.
>>>>>>>     The client is completely on its own trying to compare
>>>>>>>      to anything
>>>>>>>     if the schema trees are different
>>>>>>>
>>>>>>>       container foo {
>>>>>>>         leaf bar {
>>>>>>>            if-feature X;
>>>>>>>            type string;
>>>>>>>         }
>>>>>>>         leaf baz {
>>>>>>>            if-feature "not X";
>>>>>>>            type string;
>>>>>>>         }
>>>>>>>      }
>>>>>>>
>>>>>>>     How does the client compare  to  if the
>>>>>>>     features do not match?
>>>>>>>     If the server deviates the leaf (e.g. change type string to
>>>>>>>     int32) how does the client
>>>>>>>     compare the values?
>>>>>>>
>>>>>>>     This new complexity would be mandatory for the client to
>>>>>>>     support in some proprietary
>>>>>>>     manner since the NMDA standard ignores these problems.
>>>>>>>
>>>>>>>     NMDA was supposed to be simpler because the client could
>>>>>>>     compare intended
>>>>>>>     and applied values using the same object path. openconfig
>>>>>>>     required a data
>>>>>>>     model change and a trivial name-mapping. In reality, NMDA
>>>>>>>     is far more disruptive to existing implementations.
>>>>>>>
>>>>>>>
>>>>>>>     Andy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton
>>>>>>>     > wrote:
>>>>>>>
>>>>>>>         Hi,
>>>>>>>
>>>>>>>         Given some of the feedback related to the complexity of the
>>>>>>>         YANG library bis structure, we have come up with two other
>>>>>>>         possible structures for the YANG library data:
>>>>>>>
>>>>>>>         (1) A simplified structure to make YANG library meet the
>>>>>>>         NMDA requirements, but that is closer to the existing YANG
>>>>>>>         library structure, and arguably simpler.
>>>>>>>         (2) An enhanced version of the structure (1) above, that is
>>>>>>>         also extended to allow the structure to be reused for
>>>>>>>         schema-mount via an augmentation.
>>>>>>>
>>>>>>>         For reference, at the end of this email, I have also
>>>>>>>         included the tree diagram of the existing YANG library, and
>>>>>>>         the current YANG library bis draft
>>>>>>>         (draft-ietf-netconf-rfc7895bis-02) version.
>>>>>>>
>>>>>>>         Considering the two new YANG library structures:
>>>>>>>
>>>>>>>         ------------------------
>>>>>>>
>>>>>>>         *(1) A simplified structure to make YANG library meet the
>>>>>>>         NMDA requirements, but that is closer to the existing YANG
>>>>>>>         library structure.*
>>>>>>>
>>>>>>>         The main changes are:
>>>>>>>         (i) Split "implemented modules" and "import-only-modules"
>>>>>>>         into two separate lists, making the most important list
>>>>>>>         (i.e. implemented modules) keyed by module name only and
>>>>>>>         hence easier to reference.
>>>>>>>         (ii) Assume modules are implemented in all datastores by
>>>>>>>         default (with a "not-implemented-in" leaflist of datastores
>>>>>>>         that a module is not implemented in).
>>>>>>>         (iii) Assume that features are implemented in all
>>>>>>>         datastores by default (with a "not-implemented-in" leaflist
>>>>>>>         of datastores that a feature is not implemented in).
>>>>>>>         (iv) Deleted module-sets.
>>>>>>>         (v) Datastores are now just a list of supported datastores
>>>>>>>         (that could potentially be extended with further per
>>>>>>>         datastore properties in future).
>>>>>>>
>>>>>>>         Manually generated tree output for proposed YANG library:
>>>>>>>
>>>>>>>         module: ietf-yang-library
>>>>>>>          +--ro yang-library
>>>>>>>             +--ro modules
>>>>>>>             |  +--ro module* [name]
>>>>>>>             |  |  +--ro name yang:yang-identifier
>>>>>>>             |  |  +--ro revision? revision-identifier
>>>>>>>             |  |  +--ro schema?        inet:uri
>>>>>>>             |  |  +--ro namespace      inet:uri
>>>>>>>             |  |  +--ro submodule* [name]
>>>>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>>>>             |  |  |  +--ro revision? yang:yang-identifier
>>>>>>>             |  |  |  +--ro schema?     inet:uri
>>>>>>>             |  |  +--ro not-implemented-in*
>>>>>>>             |  |  | -> /yang-library/datastore/name
>>>>>>>             |  |  +--ro feature* [name]
>>>>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>>>>             |  |  |  +--ro not-implemented-in*
>>>>>>>             |  |  | -> /yang-library/datastore/name
>>>>>>>             |  |  +--ro deviation*
>>>>>>>             |  | -> ../name
>>>>>>>             |  |
>>>>>>>             |  +--ro import-only-module* [name revision]
>>>>>>>             |     +--ro name yang:yang-identifier
>>>>>>>             |     +--ro revision            union
>>>>>>>             |     +--ro schema?             inet:uri
>>>>>>>             |     +--ro namespace           inet:uri
>>>>>>>             |     +--ro submodule* [name]
>>>>>>>             |        +--ro name yang:yang-identifier
>>>>>>>             |        +--ro revision yang:revision-identifier
>>>>>>>             |        +--ro schema?     inet:uri
>>>>>>>             +--ro datastore* [name] // Allows future per datastore
>>>>>>>         properties.
>>>>>>>             |  +--ro name identityref
>>>>>>>             +--ro checksum string
>>>>>>>
>>>>>>>         ------------------------------
>>>>>>>
>>>>>>>         *(2) An enhanced version of the structure (1) above, that
>>>>>>>         is extended to allow the structure to be reused for
>>>>>>>         schema-mount via an augmentation.*
>>>>>>>
>>>>>>>         This is similar to the structure above, except that the
>>>>>>>         "the set of modules" is contained in a list of named schema
>>>>>>>         (e.g. similar to the schema mount draft), allowing this
>>>>>>>         structure to be re-used for schema mount.
>>>>>>>
>>>>>>>         Schema mount would be expected to augment yang-library to
>>>>>>>         add in the additional schema mount information. In the
>>>>>>>         tree diagram, I have shown the schema-mount mount-point
>>>>>>>         augmentation, but not including namespaces yet.
>>>>>>>
>>>>>>>         Every server would be required to provide at least one
>>>>>>>         schema in the schema list, and the primary schema for the
>>>>>>>         device would always be given the name "primary".
>>>>>>>
>>>>>>>         module: ietf-yang-library
>>>>>>>          +--ro yang-library
>>>>>>>             +--ro schema* [name]
>>>>>>>             |  +--ro name string
>>>>>>>             |  +--ro checksum string
>>>>>>>             |  +--ro module* [name]
>>>>>>>             |  |  +--ro name yang:yang-identifier
>>>>>>>             |  |  +--ro revision? yang:revision-identifier
>>>>>>>             |  |  +--ro schema?        inet:uri
>>>>>>>             |  |  +--ro namespace      inet:uri
>>>>>>>             |  |  +--ro submodule* [name]
>>>>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>>>>             |  |  |  +--ro revision? yang:yang-identifier
>>>>>>>             |  |  |  +--ro schema?     inet:uri
>>>>>>>             |  |  +--ro not-implemented-in*
>>>>>>>             |  |  | -> /yang-library/datastore/name
>>>>>>>             |  |  +--ro feature* [name]
>>>>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>>>>             |  |  |  +--ro not-implemented-in*
>>>>>>>             |  |  | -> /yang-library/datastore/name
>>>>>>>             |  |  +--ro deviation*
>>>>>>>             |  |  | -> ../name
>>>>>>>             |  |  +- schema-mount:mount-point* [label]
>>>>>>>             |  |     +--ro label yang:yang-identifier
>>>>>>>             |  |     +--ro config?       boolean
>>>>>>>             |  |     +--ro (schema-ref)
>>>>>>>             |  | +--:(inline)
>>>>>>>             |  |        |  +--ro inline?       empty
>>>>>>>             |  | +--:(use-schema)
>>>>>>>             |  |           +--ro use-schema* [name]
>>>>>>>             |  |              +--ro name
>>>>>>>             |  | |       -> /yang-library/schema/name
>>>>>>>             |  |              +--ro parent-reference* yang:xpath1.0
>>>>>>>             |  |
>>>>>>>             |  +--ro import-only-module* [name revision]
>>>>>>>             |     +--ro name yang:yang-identifier
>>>>>>>             |     +--ro revision            union
>>>>>>>             |     +--ro schema?             inet:uri
>>>>>>>             |     +--ro namespace           inet:uri
>>>>>>>             |     +--ro submodule* [name]
>>>>>>>             |        +--ro name yang:yang-identifier
>>>>>>>             |        +--ro revision yang:revision-identifier
>>>>>>>             |        +--ro schema?     inet:uri
>>>>>>>             +--ro datastore* [name] // Allows future per datastore
>>>>>>>         properties.
>>>>>>>             |  +--ro name identityref
>>>>>>>             +--ro checksum string
>>>>>>>
>>>>>>>         Please can you provide comments on these structures, in
>>>>>>>         particular:
>>>>>>>
>>>>>>>         Is this version better (i.e. simpler) that the version
>>>>>>>         currently in draft-ietf-netconf-rfc7895bis-02 (below)?
>>>>>>>
>>>>>>>         Should we try and make the structure extensible for
>>>>>>>         schema-mount via augmentation (i.e. version (2)), or is it
>>>>>>>         better that schema-mount has its own separate subtree?
>>>>>>>
>>>>>>>         For reference only I have included the existing YANG
>>>>>>>         library and YANG library bis draft tree diagrams.
>>>>>>>
>>>>>>>         Thanks,
>>>>>>>         Rob
>>>>>>>
>>>>>>>
>>>>>>>         -----------------------------
>>>>>>>
>>>>>>>         *** FOR REFERENCE ONLY ***
>>>>>>>
>>>>>>>         (3)  The current YANG library structure in YANG library bis
>>>>>>>         (draft-ietf-netconf-rfc7895bis-02)
>>>>>>>
>>>>>>>             module: ietf-yang-library
>>>>>>>                 +--ro yang-library
>>>>>>>                    +--ro modules
>>>>>>>                    |  +--ro module* [id]
>>>>>>>                    |     +--ro id string
>>>>>>>                    |     +--ro name yang:yang-identifier
>>>>>>>                    |     +--ro revision? revision-identifier
>>>>>>>                    |     +--ro schema? inet:uri
>>>>>>>                    |     +--ro namespace inet:uri
>>>>>>>                    |     +--ro feature* yang:yang-identifier
>>>>>>>                    |     +--ro deviation* [module]
>>>>>>>                    |     |  +--ro module    -> ../../id
>>>>>>>                    |     +--ro conformance-type enumeration
>>>>>>>                    |     +--ro submodule* [name]
>>>>>>>                    |        +--ro name yang:yang-identifier
>>>>>>>                    |        +--ro revision? revision-identifier
>>>>>>>                    |        +--ro schema?     inet:uri
>>>>>>>                    +--ro module-sets
>>>>>>>                    |  +--ro module-set* [id]
>>>>>>>                    |     +--ro id        string
>>>>>>>                    |     +--ro module*   -> 
>>>>>>> ../../../modules/module/id
>>>>>>>                    +--ro datastores
>>>>>>>                    |  +--ro datastore* [name]
>>>>>>>                    |     +--ro name identityref
>>>>>>>                    |     +--ro module-set
>>>>>>>                    |             -> 
>>>>>>> ../../../module-sets/module-set/id
>>>>>>>                    +--ro checksum       string
>>>>>>>
>>>>>>>         -----------------------------
>>>>>>>
>>>>>>>         *** FOR REFERENCE ONLY ***
>>>>>>>
>>>>>>>         (4)  The current YANG library structure (RFC 7895)
>>>>>>>
>>>>>>>                +--ro modules-state
>>>>>>>                   +--ro module-set-id    string
>>>>>>>                   +--ro module* [name revision]
>>>>>>>                      +--ro name yang:yang-identifier
>>>>>>>                      +--ro revision            union
>>>>>>>                      +--ro schema? inet:uri
>>>>>>>                      +--ro namespace inet:uri
>>>>>>>                      +--ro feature* yang:yang-identifier
>>>>>>>                      +--ro deviation* [name revision]
>>>>>>>                      |  +--ro name yang:yang-identifier
>>>>>>>                      |  +--ro revision    union
>>>>>>>                      +--ro conformance-type enumeration
>>>>>>>                      +--ro submodule* [name revision]
>>>>>>>                         +--ro name yang:yang-identifier
>>>>>>>                         +--ro revision    union
>>>>>>>                         +--ro schema?     inet:uri
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 Wed Nov 15 02: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 27DD4128D2E for ; Wed, 15 Nov 2017 02:52:05 -0800 (PST)
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 4pkpw9tRlm-d for ; Wed, 15 Nov 2017 02:52:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B0E124BE8 for ; Wed, 15 Nov 2017 02:52:03 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id CADB864262 for ; Wed, 15 Nov 2017 11:52:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510743121; bh=bIU6pJU7ZbofYdP6Msw6igkq5oE0RMSlVivX9Md9BDc=; h=From:To:Date; b=cTVhknjAeog1r1dg0ko3UB6zIZ+6XueQ+TXvUxl5IWx1vYWPK8SfRVmgxDTSiw+Nn ec6BitjznZkWs7EdleQSpGG3suzsJaBx5hAj18OIsJTrS+mwInCPa8CvM2o+c+NZlc uJwfzMscM/Rxef6PfETMzCa7nuut0HS29ZYdwq14=
Message-ID: <1510743187.21877.13.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 15 Nov 2017 18:53:07 +0800
In-Reply-To: <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com>
References: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <20171115.095341.1585161898755400575.mbj@tail-f.com> <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:52:05 -0000

On Wed, 2017-11-15 at 18:12 +0800, Balazs Lengyel wrote:
> The server MAY implement obsoleted nodes or MAY NOT. This may or may 
> not  is not good enough as a contract for the management client.  My 
> problem is that the current solution is just not good enough. IMHO we 
> need to change it.

I agree. My observation has been that the YANG contract is often interpreted in
a very server-centric way: clients just have to be prepared to any surprises.
(This reminds me of the contracts I have with insurance companies.)

Yet I think it is quite important to also support dumb clients that are written
to do some job, and may easily break if a node suddenly disappears.

Lada

> 
> Even after semver you can still obsolete the old stuff and provide the 
> new stuff with a new name, although that might not be the common 
> practice.  Which is a good thing, as I believe it is sometimes better to 
> correct existing definitions then to replace them.
> 
> regards Balazs
> 
> 
> On 2017-11-15 16:53, Martin Bjorklund wrote:
> > Exactly.  With the current solution, the sever can still implement the
> > deprecated or obsolete nodes in order to support old clients.
> > 
> > With a MAJOR update in a semver world, it means that the old nodes are
> > removed (or rather, possibly, that the old nodes have new syntax
> > and/or semantics).
> > 
> > 
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Nov 15 02:53: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 B154B124BE8 for ; Wed, 15 Nov 2017 02:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 BnI95l2CfjWX for ; Wed, 15 Nov 2017 02:53:35 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5C1126CC7 for ; Wed, 15 Nov 2017 02:53:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2280; q=dns/txt; s=iport; t=1510743215; x=1511952815; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=cj1q/r/sRr70a9Q4nuXFqwym1UR8lKTnV0PVllvMnB0=; b=fw4itiVEYPpNXF38imcv9ijFKO9syxLc32CtVQxhNuInncw3Qb8T7QFL fjIu8cWDCot6Hb1nAG0g7YDCMAKprOqbICr/531G6iG0zYZI/Sq77vjCs PKJBiLw0Q/zOajAfgmQXfiJxH0Z5NOmOUASc7c38DYAcKNn24nkUTqmLv U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AQBeHAxa/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4ng3+ZQIF9llqCEQoYC4RJTwKFB0EWAQEBAQEBAQEBayi?= =?us-ascii?q?FHwEBAQMBASEPAQU2CxALDgoCAiYCAicwBgEMBgIBAYogEKdggieLFwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGQWBD4IlggeBVYISgwGEZINJgmMFojeVBot/h0WOOYd?= =?us-ascii?q?0gTkmBiuBdDQhCB0VSYJkhGBANohhAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="31180452"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 10:53:26 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vAFArOws027548; Wed, 15 Nov 2017 10:53:25 GMT
To: Martin Bjorklund , netmod@ietf.org
References: <20171115.101454.1576716701146734257.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Wed, 15 Nov 2017 11:53: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: <20171115.101454.1576716701146734257.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] tree diagram guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 10:53:37 -0000

I liked the suggestion from Chris Hopps:

I think that it was along the lines of ...

The RFC contains a reference at the top that states that updates to the 
guidelines is available on a wiki at ....

Every few years the guidelines on the wiki can be folded into a latest 
version of the guidelines draft.

6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, or 
MEF be using the latest draft guidelines, or should then use the 
published RFC until 6087bis is actually republshed?

Thanks,
Rob


On 15/11/2017 10:14, Martin Bjorklund wrote:
> Hi,
>
> There was a proposal in the meeting today to have the guidelines for
> tree diagrams in a wiki, instead of having them in 6087bis or in the
> tree diagram document.
>
> Was the proposal really to have a wiki for just the tree guidelines,
> or was the proposal to withdraw 6087bis from the process and instead
> publish all guidelines as a wiki?
>
> If it is the former, is it really worth it?
>
> Advantages with a wiki:
>
>    +  It can be updated more easily
>
> Some drawbacks:
>
>    -  It can be updated more easily
>       (meaning they are less stable)
>
>    -  Wikis tend to not be alive after some time, and are not that
>       easy to find.  Just try to find the various YANG-related wikis
>       we've tried to maintain over the years.
>
>    -  Links in RFCs also have problems.  Sites are re-orginized etc.
>       As an example, the link to the security guidelines template in
>       RFC 6087 doesn't work anymore.
>
>    -  People that are looking for a stable reference will have problems
>       (I think Rob mentioned that IEEE still refer to RFC 6087 (which
>       is understandable; that's the published version).
>
>    -  Who maintains the Wiki, and what are the rules for updating it?
>
>
> I suggest we have the tree-related guidelines (actually just a few
> sentences) in the tree draft, and since 6087bis already refers to this
> document it is not a big problem that guidelines are spread out over
> several documents that are difficult to find.
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Nov 15 03:00: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 CF6B3129454 for ; Wed, 15 Nov 2017 03:00:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level: 
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 nHKN0Ek9REzx for ; Wed, 15 Nov 2017 03:00:02 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C654129409 for ; Wed, 15 Nov 2017 03:00:01 -0800 (PST)
X-AuditID: c1b4fb30-df9f99c000002554-8a-5a0c1e2f78c1
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 80.74.09556.F2E1C0A5; Wed, 15 Nov 2017 11:59:59 +0100 (CET)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 11:59:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=23RZrycUaZ8BRxBl6ZKaQTCstpMppCnuBLnSDiU9Zjs=; b=bngJAdGNrggDRTdjeQClYB/EwT6Y+NZg7J62I34tvZNb8ZBb88J5ZJx0xBdkRzuGwaiL3TwY1rLFKGb0lW3qmGV0YSJReXYWReUQxBeQ8Sss4faQAUrzxCVY5qWdGohE9RUP+pjHpN3tshizrMUPDbjRWbmEXtKhumzN2oOB7jU=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [IPv6:2001:67c:370:128:e196:b266:ad4f:77e2] (2001:67c:370:128:e196:b266:ad4f:77e2) by AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Wed, 15 Nov 2017 10:59:20 +0000
To: "netmod@ietf.org" 
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> 
From: Balazs Lengyel 
Message-ID: <46190ef2-65d7-a766-70ae-4a4b284ea0fc@ericsson.com>
Date: Wed, 15 Nov 2017 18:59:02 +0800
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: 
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [2001:67c:370:128:e196:b266:ad4f:77e2]
X-ClientProxiedBy: SG2PR06CA0180.apcprd06.prod.outlook.com (2603:1096:1:1e::34) To AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ae58d5ea-a939-421e-b18e-08d52c17ec85
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR07MB3425; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 3:lR5A8ML0f0MGjro5A/MPH3wuqaTKzGdCq4RTKdnjnr1HGkgxF/4tRMMhTeA/PJN9Skb7boGzeZAERVxYV/Of+BaM16iQHbqgDhayv6UWQsu32H1IseX2Dksoycy/6KDHJriwA8woLo6dqcMqYl976y2Kyj3zg6UC2U9QgBSu4CQ4j0LjGGpEI68EdK9aFE8vGBc7RGxWwoPbkuIFWkKrtCHsIaEm2RyybPK31tIfm84OTrSBPKQlGIt5EQSTUHmX; 25:iiuzSP22aNtzLhgn6wyjvJB6pOzYzobQ3bXGSaQDQHPy/OE+sIXIFUVvQ43bz7wZoy6l5lvQ/dM3iawTFYzMfE9Jl7fgNKSWv3GNJtJIUzRmzM/C+Vd9SYQBwO4SB1G+raLCPc6Z56OrNmVJ4YrkpQ4RycjYGfsvbaLvTWemktFaLCfzXKgTC+OY7WTeS8FaSG8G7h8qgw/wcYcDOaF6vUmbyLtztJNmwKYs8Y10DFt3ulfvACk6LMUtPo8NUuT+B9Ro4Iui+YVHXv5oLdOHE2jVEUcg7hpELYo53io5BTZyiCKE++52ZWGN/+Z+h4FMtVMnJkrv9RHB7qavHKTbSg==; 31:LDeAAX4QJ4xQkCadHRfz2YnUJy8v8ypcSWiEqbUoeSycNmEwpV89ZjeSpyHLgMw8yIoxHu6oHJlPjvTgboZM97MsjnkY8bLkTuyG8o75o/qFThCLvbYRT93NN0mUw+X2Dokn+HLxs0CcXefnBnym4wVwnBmKFfrojmyRAj4AfuKUUGWgufzAzD1ykjyf/AvZf4KMDrTNdyEPAIxOoYVSvG9YSaoNUBGQ1G8YpBxkyHM=
X-MS-TrafficTypeDiagnostic: AM4PR07MB3425:
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 20:HusnReJSOmDkLxxGPPTZuqZIVHzcFmsm8LX/4D2vhw0jhdwAOQNxZ/ggc06GcsaHal8hCrzgj8tk7UwBcfvQ+i7zNXiZrZLeP0LKo0PeSW7pN/7no2dliA43XfQH3wWKB3OR739mGjwsg8TBsWM9q0eWvjiktmzzQLZlFmjYbf/Laz/Dg0sq8lJV2ezNDGOJPUPWpqiqrPBQvsNEBLdk0zu0AHS2d8oTxSr/MbzX5O70traQYWUw3p73ATU7IS8D6jHez//HnnUsX6h9MB2BGs8WzTBhFDhc+cIDeW961jrxpWYcb23GfgCP6m7DhDEOCy75eoM58O2OlExc3WaXO1niQesNUK1dAxc326jMsgmVuUT+YALzD3QcZJ8Vpr/YEM+6oiPmsUxk+3H344RvXGL7UKT2VKfLiATNO854ReERw89PZfYgrxsNYgkWY4A49I3vAHHD8Q+OFo1CUrS30cCn1VEhjIbQqOakRvui0a6MYPabeftTl/jDXiMVU5Y2; 4:4oVKbBmGUvd8hRpU0VAzjP7YTVHx0vsUM1CZLPykcEmJrNA2+wyysSLBOZL73g65baAWaPHv2PazW/yLUfTBL2E0VzA8keUh1z1B6w0GdS7GGLBWDwgeEf+Au7qf2T0jlCE6GngUhjPhQbIrSRhpjW70GJ8H6r7beJUwOEe+J33A+LT8jOUouE10jPYUseu3LRShl/WIhR4bP00e6qxQPZQMPjJyOz3qmuxKQXdl2a+qjuzb7xAcLgXJPt18mkJ4fPV8imc6NZPcAQiUjYKIgyMxehufhHqnAWyc0W3ykcdVosCnned8R0O/CgY4mhrrPMkZmQCIjkKuLzEOWuuKXYJxZ3gPwsrbAI0x/2OYdb4=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3425; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3425; 
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(252514010)(189002)(199003)(106356001)(65956001)(236005)(33646002)(65806001)(1706002)(25786009)(2351001)(2501003)(53936002)(101416001)(105586002)(6306002)(65826007)(54896002)(6916009)(6666003)(50466002)(316002)(5660300001)(606006)(6116002)(6486002)(58126008)(50986999)(76176999)(31686004)(64126003)(54356999)(189998001)(81156014)(53946003)(31696002)(86362001)(23846002)(2950100002)(23676003)(478600001)(68736007)(5640700003)(1730700003)(8676002)(2906002)(8936002)(7736002)(966005)(97736004)(83506002)(36756003)(81166006)(2870700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3425; H:[IPv6:2001:67c:370:128:e196:b266:ad4f:77e2]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI1OzIzOndtQ21XbUlQSGRHT3VkaW03dDNiQVJEd2NJ?= =?utf-8?B?RDVmM0F0ZkdaNzRWeHJsTGdIQUtLTmxTMHNsaThpWnB5ejAwdm1wMFl6bVpU?= =?utf-8?B?cFdra21jeDFpMHhQWU56SW5DZ3VuU2NJSzBIS2UvTEcwYVB6M1hMU3pCVDh1?= =?utf-8?B?ZXc4MkFSR1ZIRkVxOXFrZWRVdFQvWXBmNSsvZDhsMGR1QVEyYzJ3dyswTk83?= =?utf-8?B?NmhTT2g1VjNGRVVNc2xnVDBUdno2S1JvWTFtdk9zZTJrYzk0K1NrVDFtbGQ4?= =?utf-8?B?dE5TbnBRdkNNK3g5MElCUEx5TGJ3bEYzaWJtNFpyNEJDNkxVQXhwb1R5SlZt?= =?utf-8?B?Q3NkdzJIMkhMU1JrSmo4b2lXY2JKT216L1A0Y0FoREsyR00ySlo2UENCNkti?= =?utf-8?B?c3lkaFNBZmJ5TlZLTnFCMS82Vy8veDJTZDZNVUpXVkRkVTRySWQxcnp4aUFh?= =?utf-8?B?dDVzY29TWFRJMndhd29RZCtybUIrcEJnTTZjak5ZQ2V0REhNNGpKbE1vSTJZ?= =?utf-8?B?Z1FaYlZOdEhNbDhEYjcyUGZPRzg2cGg0S0czU1lCaDVHVWRHRmU4N1AyVzli?= =?utf-8?B?ZFFwQzQycVJvNmhYS1hLL0tEbDg5SndkN2ljUkQ4K21sQlNNd1ZwTjcwS3Vs?= =?utf-8?B?bENNcGVvTnV5OTEzNFg1eno5OHhWMkdvR2lZemQ5amEvYWhmbzJUdkpsQ0lr?= =?utf-8?B?cExVZEFPM1hJNmRJS1k1SWxnODNBVjZiVldobCtBNUJ1TVNuUmxZZmQxWWFw?= =?utf-8?B?eDVqSURyWEprOVE3SGgyS0RFTmVNbDhJdnFrM3B4bFlFQTY2Q2RtTFZLTVU4?= =?utf-8?B?UENMNW5PdUluWk9yc2ZBcjVNQUZxaDlUY2V5T09HQnZvdHorMUIxeDYwQ2lW?= =?utf-8?B?bElqZVJUa3RQTkkvZDJmMGxaSHVhWExLNkcyTHlwZk5jckE5anpmZjBEUSty?= =?utf-8?B?Q1ZlSkJyajdqWFFhYzhPT2UyNTdCV25reWlybWkzckpaMWwwdTBUZWhJaVRO?= =?utf-8?B?OU9XR014dE4reGpKVnF0d2dLMi9BZFpPdlZvb3ZSOTlYZHZmTW41OXQrN2Ju?= =?utf-8?B?V1FaNzVYaHVmRFRKYkJ3TGpLWHByQTF3M0JEZyt1STk3ZFNDUkZTSXZrMWxo?= =?utf-8?B?eWhvYzNIZWsvMkorSldsY0JwR210dDZpbUlPL3oyTGxNdVczSytvMmg1M2pV?= =?utf-8?B?S0Z5SEFqMXZqeUNXQ0NpZmpzbC9TaU0rQU1KTWQrZ0NKK2g5T2FmcEtyN1M4?= =?utf-8?B?Q1lBV2tPQ1Y2U1FxcUp1VkZ5eUVEN01MOUNEL09KYnc5NTkydHUwUExPVENM?= =?utf-8?B?TEZuWkFZS21KNFdRd3ZyeGVBRnpWR3gvR1FvWXJIYmZ1dFAwclZEQzdnNzZk?= =?utf-8?B?SmJ3RU5ZRVhwd3BHNW9qZElkT0pmL0ovTE9FREJJcHMvd3FzRFVDZFVSdmZh?= =?utf-8?B?TVdEcVBGd1hMTXZlZU5LNXRwajRuREY5VzZnT2ZoZDVnZkxQZTJSOGQzSElH?= =?utf-8?B?M0xKQTlCY3A4bGwvQncwRnNvNjhVU3AvWXl1cy9lekNWK0VkRHNQT2ljZW5Y?= =?utf-8?B?NVMxdGZQL3pjV2xrUFVoVmx4R29UdUNUVGEyOTdkb2tWeTdZdk5jRTJoRW9D?= =?utf-8?B?eFBBdXQ3MnFRN3R3ZnROVCsxOVk4Mi84MEZtSUpURGdKVGNpMGs3NnR4K2Q5?= =?utf-8?B?WHg4SExYWHVLc09vY2syaE1TZEdvVFp0TFRwK0lXS0NmN0dKTi9LV0wyODFZ?= =?utf-8?Q?1s/IIoMfcUCZvUG3zitZtw3cOfluTrw0HlLCM=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 6:1QYw50G+Q7ZuUr9xwvHMNHEZMnCKQTn9jz+7exoi3Ca85wExs2Xhg+N48N5SO7aDNPN8ruO7JBuAelccmrfjJ1DbyNFlfy2Md4VDM6XjwRxPdVJB6YcasDzi0+g8d/zgyBbchRjlRwjeHv8ie70JDVV3/KQYwfic2LY24xh13xXiLOHswoc3NcDw+praYBovdDNpNlJXA999skCGU4RmjavQKL2EUTjmf+cYgdyx7kBjMPJpi87DnrX+qzQ/9f+zO5yb78ue2w9O9tsdJthlKbAoLELjZLuo6ehA0Fj0KEIreAd5UI+fN7+XgpNX4o5PMgKg15OB9/fdE3c1biDm7c6GnJedDFAFq5SaHHyacGg=; 5:q6PBNoBV0T+vwV6qchxTkGQW+q677MeE01hXIdYWF0JDErZxAhLigDoRXeo3Mg0SWTYCFSUdKOzhIGuHZJr1IAmcdyqBa+EnnOdThnEtg4K8LH1AqFW2nXILHVSGAx/MPHRRKRe+mvJipVQQh0kK9rM4ZAmEWPpRuC35KaeVEMs=; 24:qzCuyk4QnxGpX1/7K6VrW9tOFabbBTpcPLLNP2z4WFTlnoeJ0sOy4MBtHieZl72pJx8C6RXafHztyn0TGie6ZxskNa6j3BPSdS+RIa4dJOw=; 7:bHh6/BWbuLkvKcAQFFygwJ3DsH98cnJhVoc+Qw3YQGYy62PTPRcztbUy46zVlgT8jLJD+wG7Jlt8dcdUjYE2dgeDYQwwQekBXXhWkoMPZwDzW7uQLdC0pbqy9U/ZFNLZLz9GupFbGjakwxpMs/v+8rLm2yiBE9zIyjOZPJW0IKrxZTwORXTWCpN45N8R68TfZV3pmSbSUukUZfhE09yOgOEfrrdwB/wmk1cUJzMC7/OGO3vkHc6G47rMFIF/3Y5z
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 10:59:20.0441 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ae58d5ea-a939-421e-b18e-08d52c17ec85
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3425
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42KZGbFdXVdfjifKoPOAjsX8i42sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaHv4ma3g0Hqmio6lDxgbGL80M3UxcnJICJhIvNp6gL2LkYtD SOAwo8SnI9tYIJwTjBIrd0xhAnFYBHqZJdbO2skI0sIoECexc81CVoiq3UwSv/4/YOti5OAQ FtCRuP7OHqRGREBdYubO9WwgtpBAqcSDpzPYQWw2ASOJqf3nWUBsXgF7iSetM8FsFgFVibuL foKdJCoQIzHxwUVGiBpBiZMzn4DVcAo4SHQ1HgebySygIdE6Zy47hC0ucevJfCYIW16ieets ZojXLCRevD3ODHKnhMAURokVveuYIA7SkHh44S8rRJGsxNGzc1ggbF+JabueMEE0zASGxcpL rBBOA7vE7PnbGSGqtCRmHFnGBpFYwi5xZelZdohEtsTcZ5Ohirwl2p9dZocousIqcXTVMWh4 y0icvLGXESLxnlViy5O3bBMYtWcheXYWkgdnIXlwFpIHFzCyrGIULU4tTspNNzLSSy3KTC4u zs/Ty0st2cQITBcHt/w22MH48rnjIUYBDkYlHl5NDp4oIdbEsuLK3EOMEhzMSiK8yf3cUUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5PUSAUgLpiSWp2ampBalFMFkmDk6pBsbo/Xxvpv2JcHd2 LhernpO1tOkk416Woz7XL8wQ3V0WNr17r6+Ym+X3DUILYpk87h59s4X5mFKyWHrU597eMpm6 Ryxf3Y7v8J6YpM0ie03+dUCWuvZUL3ONySxZ8654/jlQ187xa/O5k493HbX7uMN69h0O5Xmx u80v/C+1M8+WE2yN97jq+UCJpTgj0VCLuag4EQDwXQY0EwMAAA==
Archived-At: 
Subject: [netmod] Obsolete and deprecated in RFC 7950
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 11:00:04 -0000


  
    
  
  
    Hello,

    https://tools.ietf.org/html/rfc7950#section-7.21.2

    
   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.


    As I understand this both means that a node that is either
    deprecated or obsolete MAY be 

    not implemented. In both cases it is allowed not-to-implement the
    node. 

    This really works as if there would be an if-feature statement on
    each deprecated schema node 

    where the server does not advertise whether the feature is supported
    of not. Why is it not advertised?

    

    YANG is considered an interface contract,  however a "maybe
    implemented" is unusable in a contract.

    

    I would like to propose an alternate definition: 

    
    
   o  "deprecated" schema nodes MUST still work as defined by the YANG module. 
       The deprecated status serves only as a a warning that the schema node 
       will be removed or obsoleted in the future." 

    
I know this is a
        significant change, but I consider the current definition of
        deprecated not really usable, 

        so we need to do something. 

      

    
YANG already has a feature
        to make some schema parts optional,  based 

        on the decision of the implementer: its called feature. Lets use
        that one. 

        This would allow the client to understand if the relevant parts
        are still there.  

      

    
As an example what I would
        do is:

    
module ietf-system {
   feature pre-nmda-support ;

   container system {...}

   container system-state {
      if-feature pre-nmda-support ;
      status deprecated;
   }
}


    
regards Balazs

      

    

    

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


  



From nobody Wed Nov 15 03:17: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 6B9DE12711E for ; Wed, 15 Nov 2017 03:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIf_vaKCt-0v for ; Wed, 15 Nov 2017 03:17:18 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E32BF126B6E for ; Wed, 15 Nov 2017 03:17:17 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 0F14A1AE0311; Wed, 15 Nov 2017 12:17:17 +0100 (CET)
Date: Wed, 15 Nov 2017 12:17:16 +0100 (CET)
Message-Id: <20171115.121716.454716475078719607.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: jclarke@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com>
References: <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <20171115.095341.1585161898755400575.mbj@tail-f.com> <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@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=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:17:20 -0000

Balazs Lengyel  wrote:
> The server MAY implement obsoleted nodes or MAY NOT. This may or may
> not=A0 is not good enough as a contract for the management client.=A0=
 My
> problem is that the current solution is just not good enough. IMHO we=

> need to change it.

Note that if a server implements version 1 of a module, and then the
module doesn't change, but the server in the next sw version drops
support for the module, the client will also be unhappy.  We (the
IETF) can't have rules for these kinds of things.

> Even after semver you can still obsolete the old stuff and provide th=
e
> new stuff with a new name, although that might not be the common
> practice.=A0 Which is a good thing, as I believe it is sometimes bett=
er
> to correct existing definitions then to replace them.

But you still want to require servers to implement even obsolete
nodes?


/martin


> =

> regards Balazs
> =

> =

> On 2017-11-15 16:53, Martin Bjorklund wrote:
> > Exactly.  With the current solution, the sever can still implement =
the
> > deprecated or obsolete nodes in order to support old clients.
> >
> > With a MAJOR update in a semver world, it means that the old nodes =
are
> > removed (or rather, possibly, that the old nodes have new syntax
> > and/or semantics).
> >
> >
> >
> =

> -- =

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


From nobody Wed Nov 15 04:10: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 1EAF01294CC for ; Wed, 15 Nov 2017 04:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HOAO-6xbu-30 for ; Wed, 15 Nov 2017 04:10:45 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8854127775 for ; Wed, 15 Nov 2017 04:10:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 34E491406959; Wed, 15 Nov 2017 13:10:42 +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 BAXPUSajzefh; Wed, 15 Nov 2017 13:10:42 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 086001406958; Wed, 15 Nov 2017 13:10:42 +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 c-pdybgRKJll; Wed, 15 Nov 2017 13:10:41 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id D55EB1406954; Wed, 15 Nov 2017 13:10:41 +0100 (CET)
To: Robert Wilton 
References:   <9096e95e-8621-f578-2c84-e502109e0a64@cisco.com>   <8584c894-473a-f268-29f0-20de225fa7c4@cisco.com>    <47e8298b-20bb-fdbb-4181-9609a489a312@cisco.com>
From: Vladimir Vassilev 
Cc: "netmod@ietf.org" 
Message-ID: <3706518a-af15-1427-2660-f357824132f9@transpacket.com>
Date: Wed, 15 Nov 2017 13:10:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <47e8298b-20bb-fdbb-4181-9609a489a312@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 12:10:49 -0000

On 11/15/2017 11:42 AM, Robert Wilton wrote:
>
>
> On 15/11/2017 10:41, Vladimir Vassilev wrote:
>>
>>
>> On 11/15/2017 01:06 AM, Robert Wilton wrote:
>>>
>>>
>>> On 14/11/2017 23:41, Vladimir Vassilev wrote:
>>>>
>>>>
>>>> On 11/13/2017 04:27 PM, Robert Wilton wrote:
>>>>>
>>>>> Hi Vladimir,
>>>>>
>>>>>
>>>>> On 12/11/2017 10:39, Vladimir Vassilev wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/11/2017 08:07 PM, Andy Bierman wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton=20
>>>>>>> > wrote:
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 Hi Andy,
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 The NMDA datastore draft
>>>>>>> =C2=A0=C2=A0=C2=A0 (draft-ietf-netmod-revised-datastores-06) mand=
ates two
>>>>>>> =C2=A0=C2=A0=C2=A0 constraints that must apply:
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 (1) All conventional datastores must have exac=
tly the same
>>>>>>> =C2=A0=C2=A0=C2=A0 schema.=C2=A0 Hence differences in deviations =
or features are=20
>>>>>>> allowed
>>>>>>> =C2=A0=C2=A0=C2=A0 between these datastores. (sec 5.1, first para=
graph)
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 (2) The schema for operational must be a super=
set of all
>>>>>>> =C2=A0=C2=A0=C2=A0 configuration datatstores, but that data nodes=
 may be omitted
>>>>>>> =C2=A0=C2=A0=C2=A0 (sec 5.3, third paragraph).
>>>>>>>
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 This implies that only the following differenc=
es between
>>>>>>> =C2=A0=C2=A0=C2=A0 datastores are allowed:
>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0(i) a feature can be disabled in convent=
ional (and/or dynamic
>>>>>>> =C2=A0=C2=A0=C2=A0 configuration datastores), but enabled in oper=
ational (e.g. for
>>>>>>> =C2=A0=C2=A0=C2=A0 configurable router-id).
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0(ii) deviations apply in all datastores,=
 except that
>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 a) a deviation can remove nodes in the =
conventional=20
>>>>>>> datastores
>>>>>>> =C2=A0=C2=A0=C2=A0 (if they were not configurable, like the featu=
re example)
>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 b) a deviation can remove nodes in a dy=
namic datastore (e.g.
>>>>>>> =C2=A0=C2=A0=C2=A0 like I2RS)
>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 c) a deviation can remove nodes from op=
erational only if a
>>>>>>> =C2=A0=C2=A0=C2=A0 server is unable to accurately report them.
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 (iii) modules exist in all datastores, except:
>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 a) a module can be omitted from convent=
ional datastores (e.g.
>>>>>>> =C2=A0=C2=A0=C2=A0 if the module is not configurable)
>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 b) a module can be omitted from a dynam=
ic datastore (e.g.=20
>>>>>>> like
>>>>>>> =C2=A0=C2=A0=C2=A0 I2RS)
>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 c) a module can be omitted from operati=
onal only if a server
>>>>>>> =C2=A0=C2=A0=C2=A0 is unable to accurately report the data nodes =
within the=20
>>>>>>> module.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I am not convinced that moving to a datastore-centric=20
>>>>>>> conformance model instead of server-centric
>>>>>>> is a good idea.
>>>>>> +1
>>>>>> IMO yang-library:1.1 can and should be optional. As a first step=20
>>>>>> NMDA modules and the minimal protocol support  etc. can=20
>>>>>> be implemented without yang-library 1.0 to 1.1 transition (read=20
>>>>>> server-centric to datastore-centric conformance model=20
>>>>>> transition). draft-ietf-netconf-nmda-netconf-01.txt requires=20
>>>>>> migration to yang-library:1.1. I do not see good argument to=20
>>>>>> support this limitation and there are usecases that can benefit=20
>>>>>> from NMDA with uniform datastore model design.
>>>>>
>>>>> YANG library bis is the mechanism to indicate which datastores are=20
>>>>> available to the client.=C2=A0 E.g. a NMDA compatible client would=20
>>>>> attempt to read YANG library bis on the new path using the=20
>>>>>  RPC to determine whether NMDA is supported, and what=20
>>>>> datastores are supported.
>>>>>
>>>>> The existing module-state path in YANG library is preserved, but=20
>>>>> marked as deprecated, so the intention is that it can be made=20
>>>>> backwards compatible to clients.
>>>> I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library=20
>>>> Capability'=C2=A0 states exactly that. IMO this text can be changed =
and=20
>>>> allow the case described above ( implementation with NMDA=20
>>>> modules implemented as indicated by yang-library:1.0 uniform model=20
>>>> applying to all datastores. For cases where the datastores do not=20
>>>> have common model yang-library:1.1 should still be mandatory). In=20
>>>> other words if yang-library:1.0 shows implemented=20
>>>> ietf-netconf-datastores  and NMDA modules listed as=20
>>>> implemented will not need yang-library:1.1 implementation which=20
>>>> takes one obstacle out of the way to rolling NMDA module=20
>>>> implementations.
>>>>
>>>> Is there an argument making the proposed change unreasonable?
>>> Yes, I think so.
>>>
>>> In an NMDA implementation, the YANG library information reported in=20
>>> the new structure can be entirely accurate.=C2=A0 I.e. it can report=20
>>> which modules are available in which datastores.
>>>
>>> Of course, it is not possible to represent this in the old YANG=20
>>> library, so the information that a NMDA server provides via the old=20
>>> YANG library could be inaccurate.=C2=A0 I.e. I think that it has to=20
>>> report all modules and deviations as being reported in all datastores=
.
>>>
>>> Hence the only way that a client would be able to know that it is=20
>>> talking to an NMDA server with modules not implemented in some=20
>>> datastores, or with deviations in some datastores would be for it to=20
>>> query the new YANG library path.=C2=A0 The new YANG library structure=
s=20
>>> that we are proposing below are intended to be easier for a client=20
>>> to determine this, e.g. by checking whether any of the=20
>>> "not-implemented-in" leaf-lists are populated.
>>>
>>> So the aim for keeping the old YANG library path is to inter-operate=20
>>> with old clients that don't know about NMDA, and hence would not be=20
>>> expected to use the  or  RPCs.
>>>
>>> Thanks,
>>> Rob
>> I still do not see an argument against supporting=C2=A0 NMDA modules w=
ith=20
>> yang-library:1.0 in the case when and only when there are no=20
>> deviations and the implemented module sets are exactly identical for=20
>> all datastores.
> OK, so when a client reads the YANG modules on the old YANG library=20
> path, then how do they distinguish between:
> (i) the information is accurate and correct
> (ii) the information isn't precise because there are per datastore=20
> differences.
It is clear that datastores with non-identical models can not be=20
supported with yang-library:1.0. However for the many usecases that do=20
not require the complexity of having different datastore models=20
(variation of the set of modules and the relevant deviations e.g. more=20
complex datastore centric conformance model) one can implement NMDA with=20
yang-library:1.0.

My initial proposal was a change to draft-ietf-netconf-nmda-netconf-01=20
sec. 2.4. 'YANG Library Capability' to allow that usecase:

OLD:
Support for NMDA requires the server to implement at least revision=20
201X-XX-XX of the "ietf-yang-library"
...
NEW:
Support for NMDA with datastores with non-identical models requires the=20
server to implement at least revision 201X-XX-XX of the "ietf-yang-librar=
y"
...

With that there is no room left for (i) is the only option.

Vladimir
> Thanks,
> Rob
>
>
>>>
>>>
>>>>
>>>> Vladimir
>>>>
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>>> =C2=A0I get it that it is supposed to allow the server to accurat=
ely=20
>>>>>>> reflect its implementation,
>>>>>>> but it actually says that servers MAY implement whatever partial=20
>>>>>>> subset of a module they want,
>>>>>>> and a client MUST deal with the mess.
>>>>>>>
>>>>>>> IMO, YANG says that features and deviations are server-wide, not=20
>>>>>>> per-datastore.
>>>>>>> This new complexity is non-trivial to implement, so it may not=20
>>>>>>> be widely supported.
>>>>>>>
>>>>>>> The WG seems confused about the difference between a conformance=20
>>>>>>> model and capabilities reporting.
>>>>>>> (ii)(c) and (iii)(c) is about reporting, not conformance. There=20
>>>>>>> is still no way to express
>>>>>>> trivial use-cases in the conformance model such as "this module=20
>>>>>>> is intended for the I2RS ephemeral datastore only"
>>>>>>>
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 Changing the type of a node between datastores=
, or changing its
>>>>>>> =C2=A0=C2=A0=C2=A0 properties is not allowed.=C2=A0 The only diff=
erence allowed between
>>>>>>> =C2=A0=C2=A0=C2=A0 data nodes in different datastores is the node=
s existence.
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 These rules seem more restrictive that what a =
server using=20
>>>>>>> split
>>>>>>> =C2=A0=C2=A0=C2=A0 config state trees (IETF style, or OpenConfig =
style) can=20
>>>>>>> achieve
>>>>>>> =C2=A0=C2=A0=C2=A0 using deviations today.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Lots of rules to enforce actually makes the code harder, not=20
>>>>>>> easier.
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 Thanks,
>>>>>>> =C2=A0=C2=A0=C2=A0 Rob
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0 On 09/11/2017 19:33, Andy Bierman wrote:
>>>>>>>> =C2=A0=C2=A0=C2=A0 Hi,
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 The new structure still has the same problems=
 for the=20
>>>>>>>> client as
>>>>>>>> =C2=A0=C2=A0=C2=A0 before.
>>>>>>>> =C2=A0=C2=A0=C2=A0 It is a major change in the architecture to h=
ave different
>>>>>>>> =C2=A0=C2=A0=C2=A0 schema trees per datastore instead of per-ser=
ver.
>>>>>>>> =C2=A0=C2=A0=C2=A0 The server is allowed to have different featu=
res and=20
>>>>>>>> deviations
>>>>>>>> =C2=A0=C2=A0=C2=A0 for the same objects.
>>>>>>>> =C2=A0=C2=A0=C2=A0 The client is completely on its own trying to=
 compare
>>>>>>>> =C2=A0=C2=A0=C2=A0  to anything
>>>>>>>> =C2=A0=C2=A0=C2=A0 if the schema trees are different
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 container foo {
>>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 leaf bar {
>>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature X;
>>>>>>>> =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 leaf baz {
>>>>>>>> =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not X"=
;
>>>>>>>> =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 How does the client compare  to  if the
>>>>>>>> =C2=A0=C2=A0=C2=A0 features do not match?
>>>>>>>> =C2=A0=C2=A0=C2=A0 If the server deviates the leaf (e.g. change =
type string to
>>>>>>>> =C2=A0=C2=A0=C2=A0 int32) how does the client
>>>>>>>> =C2=A0=C2=A0=C2=A0 compare the values?
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 This new complexity would be mandatory for th=
e client to
>>>>>>>> =C2=A0=C2=A0=C2=A0 support in some proprietary
>>>>>>>> =C2=A0=C2=A0=C2=A0 manner since the NMDA standard ignores these =
problems.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 NMDA was supposed to be simpler because the c=
lient could
>>>>>>>> =C2=A0=C2=A0=C2=A0 compare intended
>>>>>>>> =C2=A0=C2=A0=C2=A0 and applied values using the same object path=
. openconfig
>>>>>>>> =C2=A0=C2=A0=C2=A0 required a data
>>>>>>>> =C2=A0=C2=A0=C2=A0 model change and a trivial name-mapping. In r=
eality, NMDA
>>>>>>>> =C2=A0=C2=A0=C2=A0 is far more disruptive to existing implementa=
tions.
>>>>>>>>
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 Andy
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0 On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton
>>>>>>>> =C2=A0=C2=A0=C2=A0 =
> wrote:
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi,
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Given some of the fee=
dback related to the complexity of=20
>>>>>>>> the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 YANG library bis stru=
cture, we have come up with two other
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 possible structures f=
or the YANG library data:
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (1) A simplified stru=
cture to make YANG library meet the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NMDA requirements, bu=
t that is closer to the existing YANG
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 library structure, an=
d arguably simpler.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (2) An enhanced versi=
on of the structure (1) above,=20
>>>>>>>> that is
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 also extended to allo=
w the structure to be reused for
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schema-mount via an a=
ugmentation.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For reference, at the=
 end of this email, I have also
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 included the tree dia=
gram of the existing YANG library,=20
>>>>>>>> and
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the current YANG libr=
ary bis draft
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (draft-ietf-netconf-r=
fc7895bis-02) version.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Considering the two n=
ew YANG library structures:
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ---------------------=
---
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *(1) A simplified str=
ucture to make YANG library meet the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NMDA requirements, bu=
t that is closer to the existing YANG
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 library structure.*
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The main changes are:
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (i) Split "implemente=
d modules" and "import-only-modules"
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 into two separate lis=
ts, making the most important list
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (i.e. implemented mod=
ules) keyed by module name only and
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hence easier to refer=
ence.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (ii) Assume modules a=
re implemented in all datastores by
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default (with a "not-=
implemented-in" leaflist of=20
>>>>>>>> datastores
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that a module is not =
implemented in).
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (iii) Assume that fea=
tures are implemented in all
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 datastores by default=
 (with a "not-implemented-in"=20
>>>>>>>> leaflist
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of datastores that a =
feature is not implemented in).
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (iv) Deleted module-s=
ets.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (v) Datastores are no=
w just a list of supported datastores
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (that could potential=
ly be extended with further per
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 datastore properties =
in future).
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Manually generated tr=
ee output for proposed YANG library:
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module: ietf-yang-lib=
rary
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0+--ro yang-libr=
ary
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +-=
-ro modules
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro module* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro revision? revision-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 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:=
uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro submodule* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro revision? yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro not-implemented-in*
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> /yang-library/datastore/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 +--ro feature* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> /yang-library/datastore/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 +--ro deviation*
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 | -> ../name
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro import-only-module* [name revision]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [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 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision yang:revision-iden=
tifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=
=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +-=
-ro datastore* [name] // Allows future per datastore
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 properties.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro name identityref
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +-=
-ro checksum 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 *(2) An enhanced vers=
ion of the structure (1) above, that
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is extended to allow =
the structure to be reused for
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schema-mount via an a=
ugmentation.*
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is similar to th=
e structure above, except that the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "the set of modules" =
is contained in a list of named=20
>>>>>>>> schema
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e.g. similar to the =
schema mount draft), allowing this
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 structure to be re-us=
ed for schema mount.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Schema mount would be=
 expected to augment yang-library to
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 add in the additional=
 schema mount information. In the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tree diagram, I have =
shown the schema-mount mount-point
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 augmentation, but not=
 including namespaces yet.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Every server would be=
 required to provide at least one
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schema in the schema =
list, and the primary schema for the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 device would always b=
e given the name "primary".
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 module: ietf-yang-lib=
rary
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0+--ro yang-libr=
ary
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +-=
-ro schema* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro name string
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro checksum string
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro module* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro revision? yang:revision-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 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:=
uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro submodule* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro revision? yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 +--ro not-implemented-in*
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> /yang-library/datastore/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 +--ro feature* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> /yang-library/datastore/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 +--ro deviation*
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0 | -> ../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 +- schema-mount:mount-point* [label]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro label yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 boolean
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (schema-ref)
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 | +--:(inline)
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 | +--:(use-schema)
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro u=
se-schema* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 +--ro name
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/schema/name
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 +--ro parent-reference*=20
>>>>>>>> yang:xpath1.0
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 |
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro import-only-module* [name revision]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [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 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision yang:revision-iden=
tifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=
=A0 inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +-=
-ro datastore* [name] // Allows future per datastore
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 properties.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro name identityref
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 +-=
-ro checksum string
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please can you provid=
e comments on these structures, in
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 particular:
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is this version bette=
r (i.e. simpler) that the version
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 currently in draft-ie=
tf-netconf-rfc7895bis-02 (below)?
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Should we try and mak=
e the structure extensible for
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 schema-mount via augm=
entation (i.e. version (2)), or is it
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 better that schema-mo=
unt has its own separate subtree?
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For reference only I =
have included the existing YANG
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 library and YANG libr=
ary bis draft tree diagrams.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks,
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rob
>>>>>>>>
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ---------------------=
--------
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *** FOR REFERENCE ONL=
Y ***
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (3)=C2=A0 The current=
 YANG library structure in YANG library=20
>>>>>>>> bis
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (draft-ietf-netconf-r=
fc7895bis-02)
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 module: ietf-yang-library
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro modules
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [id]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o id 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 +--r=
o name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o revision? revision-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=C2=A0=C2=A0=C2=A0 +--r=
o schema? inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o namespace inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o feature* yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o deviation* [module]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0 +--ro module=C2=A0=C2=A0=C2=A0 -> ../../id
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o conformance-type enumeration
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o submodule* [name]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro revision? revision-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=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +--ro schema? inet:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module-sets
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module-set* [id]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o module*=C2=A0=C2=A0 ->=20
>>>>>>>> ../../../modules/module/id
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastores
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro datastore* [name=
]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o name identityref
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
o module-set
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->=20
>>>>>>>> ../../../module-sets/module-set/id
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 string
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ---------------------=
--------
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *** FOR REFERENCE ONL=
Y ***
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (4)=C2=A0 The current=
 YANG library structure (RFC 7895)
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro modules-state
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module-set-id=C2=A0=C2=A0=C2=A0=
 string
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module* [name revision]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:ya=
ng-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=C2=A0 +--ro revision=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema? inet=
:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace in=
et:uri
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro feature* yan=
g:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro deviation* [=
name revision]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=
 yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro revi=
sion=C2=A0=C2=A0=C2=A0 union
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro conformance-=
type enumeration
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [=
name revision]
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--ro name yang:yang-identifier
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--ro revision=C2=A0=C2=A0=C2=A0 union
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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 Wed Nov 15 04:14: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 BAD04127867 for ; Wed, 15 Nov 2017 04:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikhsnaZbctwP for ; Wed, 15 Nov 2017 04:14:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id ACEEE127775 for ; Wed, 15 Nov 2017 04:14:47 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id F27891AE0311; Wed, 15 Nov 2017 13:14:46 +0100 (CET)
Date: Wed, 15 Nov 2017 13:14:46 +0100 (CET)
Message-Id: <20171115.131446.662734976962171507.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1510726990.12151.10.camel@nic.cz>
References: <1510726990.12151.10.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] document organization
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 12:14:48 -0000

Ladislav Lhotka  wrote:
> Hi,
> 
> regarding my proposed reorganization of documents: I strongly disagree with
> Martin's comment on jabber that it would be a mere split of the contents into
> two documents. It is certainly not true because
> 
> - we could get rid of the use-schema/inline choice in schema-mounts data: the
> inline case needs to state data in the parent tree at all

If this was the case, we could remove 'inline' even today from this
choice.  But we can't do that unless we don't use an extension also
for "use-schema", which I know you want to get rid of, but the WG
wants to keep.

> - there are many CLRs that are relevant only to one of the methods, so have to
> distinguish the cases in the text; for example, parent-references don't apply to
> "inline"

Correct.  OTOH with two documents you probably need additional text to
explain the relationship between them.

> - (most important for me) the two methods are really two different mechanisms,
> and the "inline" method invites various instance-related considerations whereas
> "use-schema" doesn't; it's been my experience that people keep confusing schema
> construction and instance data mounting.

"inline" doesn't imply instance data mounting.  Our implementation
uses "inline" w/o instance data mounting.


/martin


From nobody Wed Nov 15 04:20: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 DDF8D129436 for ; Wed, 15 Nov 2017 04:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GSlV39fMbM1a for ; Wed, 15 Nov 2017 04:20:12 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A640B129401 for ; Wed, 15 Nov 2017 04:20:12 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id D1A441AE0311; Wed, 15 Nov 2017 13:20:11 +0100 (CET)
Date: Wed, 15 Nov 2017 13:20:11 +0100 (CET)
Message-Id: <20171115.132011.1461354023659143851.mbj@tail-f.com>
To: vladimir@transpacket.com
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <3706518a-af15-1427-2660-f357824132f9@transpacket.com>
References:  <47e8298b-20bb-fdbb-4181-9609a489a312@cisco.com> <3706518a-af15-1427-2660-f357824132f9@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] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 12:20:14 -0000

Vladimir Vassilev  wrote:

[...]

> It is clear that datastores with non-identical models can not be
> supported with yang-library:1.0. However for the many usecases that do
> not require the complexity of having different datastore models
> (variation of the set of modules and the relevant deviations e.g. more
> complex datastore centric conformance model) one can implement NMDA
> with yang-library:1.0.
> 
> My initial proposal was a change to draft-ietf-netconf-nmda-netconf-01
> sec. 2.4. 'YANG Library Capability' to allow that usecase:
> 
> OLD:
> Support for NMDA requires the server to implement at least revision
> 201X-XX-XX of the "ietf-yang-library"
> ...
> NEW:
> Support for NMDA with datastores with non-identical models requires
> the server to implement at least revision 201X-XX-XX of the
> "ietf-yang-library"

But that would imply that we keep two versions of ietf-yang-library
around, and "current".

Also note that the new proposed version is very similar in structure
to the old yang library.  And if the server implements "identicial
models", then the "not-implemented-in" will be empty, and so the
contents of yang-library 1.1 is more or less the same as yang-library
1.0.


/martin


From nobody Wed Nov 15 04:58: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 EDCF51294B2 for ; Wed, 15 Nov 2017 04:58:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HmFy00kbDFqy for ; Wed, 15 Nov 2017 04:58:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 852C71270A7 for ; Wed, 15 Nov 2017 04:58:19 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 430951AE0311 for ; Wed, 15 Nov 2017 13:58:18 +0100 (CET)
Date: Wed, 15 Nov 2017 13:58:18 +0100 (CET)
Message-Id: <20171115.135818.591114714397486064.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] intended status of the tree diagram document
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 12:58:21 -0000

Hi,

Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
Standards Track.  I think I heard during the meeting today that it
ought to be Informational.  I think this makes sense.  It would then
imply that other standards track documents will have the tree diagram
document as an informative reference.

Should we make this change?


/martin


From nobody Wed Nov 15 05:05: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 324BE126DCA for ; Wed, 15 Nov 2017 05:05:35 -0800 (PST)
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 CkUWDAfeCuwu for ; Wed, 15 Nov 2017 05:05:30 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCA41270A7 for ; Wed, 15 Nov 2017 05:05:30 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id 060EA643EF for ; Wed, 15 Nov 2017 14:05:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510751128; bh=mmvDEs48wCQZpJSuSKRlwMz91K+r3Bjw0yOJzV9DcoU=; h=From:To:Date; b=fHHyPnaiwNGqHFOTcGsWW7P3J+qxbq3ZX1yd4ME005QbwablMVI/BxSiJCll33ct4 ieGClGhQK0HkktxwFS66jMlfgXBP8AwKXBw7v8JkODh3Dfpp98Ivz+UMim0KlV52RE VhzfNjWvdZaHgDE531YdseJgQLLEkqiUSfA9PRas=
Message-ID: <1510751195.21877.25.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 15 Nov 2017 21:06:35 +0800
In-Reply-To: <20171115.121716.454716475078719607.mbj@tail-f.com>
References: <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <20171115.095341.1585161898755400575.mbj@tail-f.com> <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com> <20171115.121716.454716475078719607.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 13:05:35 -0000

On Wed, 2017-11-15 at 12:17 +0100, Martin Bjorklund wrote:
> Balazs Lengyel  wrote:
> > The server MAY implement obsoleted nodes or MAY NOT. This may or may
> > not  is not good enough as a contract for the management client.  My
> > problem is that the current solution is just not good enough. IMHO we
> > need to change it.
> 
> Note that if a server implements version 1 of a module, and then the
> module doesn't change, but the server in the next sw version drops
> support for the module, the client will also be unhappy.  We (the
> IETF) can't have rules for these kinds of things.

If the server drops support for a module, then that module has to disappear from
YANG library, so it is a priori known that it happened. With deprecated/obsolete
nodes, a server may drop their support without any notice, within the same
module&revision. 

> 
> > Even after semver you can still obsolete the old stuff and provide the
> > new stuff with a new name, although that might not be the common
> > practice.  Which is a good thing, as I believe it is sometimes better
> > to correct existing definitions then to replace them.
> 
> But you still want to require servers to implement even obsolete
> nodes?

I think with semver support there will be no need for the "status" statement -
the nodes just get removed and version number bumped.

Lada

> 
> 
> /martin
> 
> 
> > 
> > regards Balazs
> > 
> > 
> > On 2017-11-15 16:53, Martin Bjorklund wrote:
> > > Exactly.  With the current solution, the sever can still implement the
> > > deprecated or obsolete nodes in order to support old clients.
> > > 
> > > With a MAJOR update in a semver world, it means that the old nodes are
> > > removed (or rather, possibly, that the old nodes have new syntax
> > > and/or semantics).
> > > 
> > > 
> > > 
> > 
> > -- 
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com
> > 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Nov 15 05:09: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 6B9BE1270A7 for ; Wed, 15 Nov 2017 05:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TmXNvib2kx82 for ; Wed, 15 Nov 2017 05:09:34 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2683C126DCA for ; Wed, 15 Nov 2017 05:09:34 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7C12C6CB; Wed, 15 Nov 2017 14:09:32 +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 ZvVcfBGOmGHK; Wed, 15 Nov 2017 14:09:32 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Nov 2017 14:09:32 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67BB62011F; Wed, 15 Nov 2017 14:09:32 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VljnQkXkw6yg; Wed, 15 Nov 2017 14:09:32 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0607B2011E; Wed, 15 Nov 2017 14:09:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 216D3415938D; Wed, 15 Nov 2017 14:08:03 +0100 (CET)
Date: Wed, 15 Nov 2017 14:08:03 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Message-ID: <20171115130803.k7bqhj625tsnmd4i@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20171115.135818.591114714397486064.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171115.135818.591114714397486064.mbj@tail-f.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] intended status of the tree diagram document
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 13:09:35 -0000

On Wed, Nov 15, 2017 at 01:58:18PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
> Standards Track.  I think I heard during the meeting today that it
> ought to be Informational.  I think this makes sense.  It would then
> imply that other standards track documents will have the tree diagram
> document as an informative reference.
> 
> Should we make this change?
>

Makes sense to me. I could ask what you will do with the RFC 2119
language in the ID but hey I do not ask these questions anymore. ;-)

/js

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


From nobody Wed Nov 15 05:18: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 69060126DCA for ; Wed, 15 Nov 2017 05:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYpBOWpUy2aA for ; Wed, 15 Nov 2017 05:18:44 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 53C90124B17 for ; Wed, 15 Nov 2017 05:18:44 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 9743C1AE0311; Wed, 15 Nov 2017 14:18:43 +0100 (CET)
Date: Wed, 15 Nov 2017 14:18:43 +0100 (CET)
Message-Id: <20171115.141843.1847219398633474861.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20171115130803.k7bqhj625tsnmd4i@elstar.local>
References: <20171115.135818.591114714397486064.mbj@tail-f.com> <20171115130803.k7bqhj625tsnmd4i@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] intended status of the tree diagram document
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 13:18:45 -0000

Juergen Schoenwaelder  wrote:
> On Wed, Nov 15, 2017 at 01:58:18PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
> > Standards Track.  I think I heard during the meeting today that it
> > ought to be Informational.  I think this makes sense.  It would then
> > imply that other standards track documents will have the tree diagram
> > document as an informative reference.
> > 
> > Should we make this change?
> >
> 
> Makes sense to me. I could ask what you will do with the RFC 2119
> language in the ID but hey I do not ask these questions anymore. ;-)

Hmm, there is no 2119 language in this draft, so it should be ok.


/martin


From nobody Wed Nov 15 05:20: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 49658126DCA for ; Wed, 15 Nov 2017 05:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5vdkp5FiA_d for ; Wed, 15 Nov 2017 05:20:18 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 34C43124B17 for ; Wed, 15 Nov 2017 05:20:18 -0800 (PST)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 7617E1AE0311; Wed, 15 Nov 2017 14:20:17 +0100 (CET)
Date: Wed, 15 Nov 2017 14:20:17 +0100 (CET)
Message-Id: <20171115.142017.1071562845381546650.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1510751195.21877.25.camel@nic.cz>
References: <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com> <20171115.121716.454716475078719607.mbj@tail-f.com> <1510751195.21877.25.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 13:20:21 -0000

Ladislav Lhotka  wrote:
> On Wed, 2017-11-15 at 12:17 +0100, Martin Bjorklund wrote:
> > Balazs Lengyel  wrote:
> > > The server MAY implement obsoleted nodes or MAY NOT. This may or may
> > > not  is not good enough as a contract for the management client.  My
> > > problem is that the current solution is just not good enough. IMHO we
> > > need to change it.
> > 
> > Note that if a server implements version 1 of a module, and then the
> > module doesn't change, but the server in the next sw version drops
> > support for the module, the client will also be unhappy.  We (the
> > IETF) can't have rules for these kinds of things.
> 
> If the server drops support for a module, then that module has to disappear from
> YANG library, so it is a priori known that it happened. With deprecated/obsolete
> nodes, a server may drop their support without any notice, within the same
> module&revision. 

I agree that *that* is a problem, but that's not what Balazs asked about.


/martin

> > > new stuff with a new name, although that might not be the common
> > > practice.  Which is a good thing, as I believe it is sometimes better
> > > to correct existing definitions then to replace them.
> > 
> > But you still want to require servers to implement even obsolete
> > nodes?
> 
> I think with semver support there will be no need for the "status" statement -
> the nodes just get removed and version number bumped.
> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > 
> > > 
> > > regards Balazs
> > > 
> > > 
> > > On 2017-11-15 16:53, Martin Bjorklund wrote:
> > > > Exactly.  With the current solution, the sever can still implement the
> > > > deprecated or obsolete nodes in order to support old clients.
> > > > 
> > > > With a MAJOR update in a semver world, it means that the old nodes are
> > > > removed (or rather, possibly, that the old nodes have new syntax
> > > > and/or semantics).
> > > > 
> > > > 
> > > > 
> > > 
> > > -- 
> > > Balazs Lengyel                       Ericsson Hungary Ltd.
> > > Senior Specialist
> > > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com
> > > 
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Nov 15 05:41: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 9CD2E126579 for ; Wed, 15 Nov 2017 05:41:29 -0800 (PST)
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 IsKY0PvJgbT6 for ; Wed, 15 Nov 2017 05:41:27 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321DD124B17 for ; Wed, 15 Nov 2017 05:41:27 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id D56AD6445D; Wed, 15 Nov 2017 14:41:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510753285; bh=7M9KFH8Gv5e04hYAXpXldSwKLktO62Ofa7kPtOef1rE=; h=From:To:Date; b=E6vKTGX+zbwXOhioUlbrTzYFAMl8geoSUM2O6kFPZ+4MtzoOXlyuR+nav99ipHDyB lv+4sOM8irhJ44e6x+JIepN+rRU5PD/jkE+4Y9E6aOrjXl/oUwPjqUDgDn449j6xZY nsfcTKPwOBiZjL9/HW+LLIXjf45RmjGY+UkgYdS8=
Message-ID: <1510753352.21877.51.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Date: Wed, 15 Nov 2017 21:42:32 +0800
In-Reply-To: <20171115.131446.662734976962171507.mbj@tail-f.com>
References: <1510726990.12151.10.camel@nic.cz> <20171115.131446.662734976962171507.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] document organization
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 13:41:30 -0000

On Wed, 2017-11-15 at 13:14 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > regarding my proposed reorganization of documents: I strongly disagree with
> > Martin's comment on jabber that it would be a mere split of the contents into
> > two documents. It is certainly not true because
> > 
> > - we could get rid of the use-schema/inline choice in schema-mounts data: the
> > inline case needs to state data in the parent tree at all
> 
> If this was the case, we could remove 'inline' even today from this
> choice.  But we can't do that unless we don't use an extension also
> for "use-schema", which I know you want to get rid of, but the WG
> wants to keep.

The WG should then give me a single technical reason why the "mount-point"
extension is superior to using a schema node identifier, as we do in augments.

The argument that it permits the data modeller to restrict the locations where
schema mount can add nodes is actually a red herring - such nodes can be added
even to containers and lists that are not labelled with "mount-point":

module foo {
    ...
    container bar {
        // no "yangmnt:mount-point" here
        ...
    }

This simple augmenting module then does the trick, at the expense of one extra
container "root":

module baz {
    ...
    augment "/foo:bar" {
        container root {
            yangmnt:mount-point unwanted-children;
        }
    }
}


> 
> > - there are many CLRs that are relevant only to one of the methods, so have to
> > distinguish the cases in the text; for example, parent-references don't apply to
> > "inline"
> 
> Correct.  OTOH with two documents you probably need additional text to
> explain the relationship between them.

Not really, because there needn't in fact be any relationship whatsoever. Both
methods could still be used together but they would be explained separately.

> 
> > - (most important for me) the two methods are really two different mechanisms,
> > and the "inline" method invites various instance-related considerations whereas
> > "use-schema" doesn't; it's been my experience that people keep confusing schema
> > construction and instance data mounting.
> 
> "inline" doesn't imply instance data mounting.  Our implementation
> uses "inline" w/o instance data mounting.

Well, the embedded YANG library that describes the mounted schema is part of
instance data, so it has to be added either from elsewhere or later at run time.
If it was there from the start and wouldn't change, then there is no reason to
do it this way and one can apply the "use-schema" method.

Lada

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


From nobody Wed Nov 15 05:44: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 03C7D124B17 for ; Wed, 15 Nov 2017 05:44:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAkjlfXP9bwa for ; Wed, 15 Nov 2017 05:44:07 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3354C1243F3 for ; Wed, 15 Nov 2017 05:44:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 7105214064CC; Wed, 15 Nov 2017 14:44:05 +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 JLLzmvYxtMVP; Wed, 15 Nov 2017 14:44:05 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 45AD3140697A; Wed, 15 Nov 2017 14:44:05 +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 jQms0GryyNsW; Wed, 15 Nov 2017 14:44:05 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 132BE1406977; Wed, 15 Nov 2017 14:44:05 +0100 (CET)
To: Martin Bjorklund , "netmod@ietf.org" 
References:  <47e8298b-20bb-fdbb-4181-9609a489a312@cisco.com> <3706518a-af15-1427-2660-f357824132f9@transpacket.com> <20171115.132011.1461354023659143851.mbj@tail-f.com>
From: Vladimir Vassilev 
Message-ID: <6e7804f1-82b2-3d93-1044-c98a9550f736@transpacket.com>
Date: Wed, 15 Nov 2017 14:44:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171115.132011.1461354023659143851.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: nb
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 13:44:10 -0000

On 11/15/2017 01:20 PM, Martin Bjorklund wrote:
> Vladimir Vassilev  wrote:
>
> [...]
>
>> It is clear that datastores with non-identical models can not be
>> supported with yang-library:1.0. However for the many usecases that do
>> not require the complexity of having different datastore models
>> (variation of the set of modules and the relevant deviations e.g. more
>> complex datastore centric conformance model) one can implement NMDA
>> with yang-library:1.0.
>>
>> My initial proposal was a change to draft-ietf-netconf-nmda-netconf-01
>> sec. 2.4. 'YANG Library Capability' to allow that usecase:
>>
>> OLD:
>> Support for NMDA requires the server to implement at least revision
>> 201X-XX-XX of the "ietf-yang-library"
>> ...
>> NEW:
>> Support for NMDA with datastores with non-identical models requires
>> the server to implement at least revision 201X-XX-XX of the
>> "ietf-yang-library"
> But that would imply that we keep two versions of ietf-yang-library
> around, and "current".
>
> Also note that the new proposed version is very similar in structure
> to the old yang library.  And if the server implements "identicial
> models", then the "not-implemented-in" will be empty, and so the
> contents of yang-library 1.1 is more or less the same as yang-library
> 1.0.
I aggree with what you say. My point is that the upgrade to 
yang-library:1.1 can come later then the upgrade to NMDA ietf-interfaces 
 etc. I will implement yang-library:1.1 as soon as I find a 
single usecase that justifies the work needed. At the moment I only have 
motivation to implement  and migrate to the NMDA modules and 
the only issue with that plan is the text in 
draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library Capability'.

Following my gut feeling I would rather wait to see if yang-library:1.2 
is not coming up before I am done with the process of migrating to NMDA 
with identical datastore models. A reasonable concern taking into 
account yang-library:1.0 is about to be obsoleted so soon after the 
publication of rfc7895 because of a feature (introduction of 
datastore-centric conformance model) that has no value for me at the 
moment unlike the feature (unification of configuration and state trees) 
introduced with NMDA.

That said there might be a counter argument that the confusion of 
allowing NMDA implementations with both yang-library:1.0 and 
yang-library:1.1 is worse then forcing all NMDA applications to 
implement only yang-library:1.1. If this is so that should be stated 
clearly.

Vladimir

> /martin


From nobody Wed Nov 15 05:46: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 97574126DED for ; Wed, 15 Nov 2017 05:46:34 -0800 (PST)
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 1y5MRFbmaier for ; Wed, 15 Nov 2017 05:46:33 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825D4126579 for ; Wed, 15 Nov 2017 05:46:33 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id 3FBCD6446A for ; Wed, 15 Nov 2017 14:46:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510753591; bh=lC/zvTi4dM42RiQQmQZnquALHnPXICdKI/Y/L0rUfeY=; h=From:To:Date; b=IgsbyaTACn/04LWJypyj1EuQj3/w8P39JPqJQQOavoOcx/yZLh7ov8yXdGMYn/n4h 6zVEWOlYgSqY5YeqNpCnUJGZfjdOJLE36rDWj1DIh689gmlfw7N6Mw4DEqPEdCEZ47 yZwdPYq9kw62kvJ2WGLm+XaatWeAY6TnKKgIMdcQ=
Message-ID: <1510753658.21877.54.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 15 Nov 2017 21:47:38 +0800
In-Reply-To: <20171115130803.k7bqhj625tsnmd4i@elstar.local>
References: <20171115.135818.591114714397486064.mbj@tail-f.com> <20171115130803.k7bqhj625tsnmd4i@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] intended status of the tree diagram document
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 13:46:35 -0000

On Wed, 2017-11-15 at 14:08 +0100, Juergen Schoenwaelder wrote:
> On Wed, Nov 15, 2017 at 01:58:18PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
> > Standards Track.  I think I heard during the meeting today that it
> > ought to be Informational.  I think this makes sense.  It would then
> > imply that other standards track documents will have the tree diagram
> > document as an informative reference.
> > 
> > Should we make this change?
> > 
> 
> Makes sense to me. I could ask what you will do with the RFC 2119
> language in the ID but hey I do not ask these questions anymore. ;-)

+1

2119 terms should be replaced with plain words.

Lada

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


From nobody Wed Nov 15 06: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 440831275C5 for ; Wed, 15 Nov 2017 06:50:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WKJh59muS32M for ; Wed, 15 Nov 2017 06:49:59 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1364B12751F for ; Wed, 15 Nov 2017 06:49:59 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D5058F80; Wed, 15 Nov 2017 15:49:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id gIUJ5v5sBrC1; Wed, 15 Nov 2017 15:49:57 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Nov 2017 15:49:57 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF7E42011F; Wed, 15 Nov 2017 15:49:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1Un_yvX79ldD; Wed, 15 Nov 2017 15:49:57 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48E702011E; Wed, 15 Nov 2017 15:49:57 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 20E62415949C; Wed, 15 Nov 2017 15:48:29 +0100 (CET)
Date: Wed, 15 Nov 2017 15:48:28 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Message-ID: <20171115144828.bxhixbmpp4qo7ikj@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20171115.135818.591114714397486064.mbj@tail-f.com> <20171115130803.k7bqhj625tsnmd4i@elstar.local> <20171115.141843.1847219398633474861.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171115.141843.1847219398633474861.mbj@tail-f.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] intended status of the tree diagram document
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 14:50:01 -0000

On Wed, Nov 15, 2017 at 02:18:43PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Wed, Nov 15, 2017 at 01:58:18PM +0100, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
> > > Standards Track.  I think I heard during the meeting today that it
> > > ought to be Informational.  I think this makes sense.  It would then
> > > imply that other standards track documents will have the tree diagram
> > > document as an informative reference.
> > > 
> > > Should we make this change?
> > >
> > 
> > Makes sense to me. I could ask what you will do with the RFC 2119
> > language in the ID but hey I do not ask these questions anymore. ;-)
> 
> Hmm, there is no 2119 language in this draft, so it should be ok.
>

Good that I did not ask. :)

/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 Nov 15 07:27: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 C9F0E1204DA for ; Wed, 15 Nov 2017 07:27:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5a3l1WPPCTi for ; Wed, 15 Nov 2017 07:27:52 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 F2B7D1200FC for ; Wed, 15 Nov 2017 07:27:51 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id q4so9121762pfg.13 for ; Wed, 15 Nov 2017 07:27:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=TNMUfuDmpP4hpDcXVBdcxi45NxBWubQdNNGzUsw+JnU=; b=HdH8Rro2vsVZardCOH2gYLI/1rB5g5cAeskrqOUxLM5MK9fpRWGrWJKrKE46kD6a/e 2Ym27nrDPoJ8jGX0wRckNj+NqcEqoXjpj2s+r7DiRVhPqZnSkak428rGFj5/3EY8gl1n CGysQNeKFJwyc7iDkSEmj9NNnXw+dpBtGNOMmwxgEia5Arm/SkSHvowatAJdEhPteUbC Rhvy6Pw2RJd0lyufMShB8uxshXofs5I4eQ16y4GXYqbGsGNfBGyal2HnUUbDgGvQHTDN qDth9KlulTFcwXSsoQq1YoJqU/DwscUUv/JBUGuSb6OzWzjMUu8sM0VxMRmDaSkOjdaR oHmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=TNMUfuDmpP4hpDcXVBdcxi45NxBWubQdNNGzUsw+JnU=; b=lCihFEtWyZyn1II56GaHjKm5CJQRjBmS6Q47ExQ6Z+qKwSyDU7dZy1Y9Muu8nyx8LR woJ9oaUfdf1FW1OWkm7KAfx0AVxz9FkEAdlFYxfSNBBZVzvVBnp/t6jmpcG0Ga8y1Wz2 E2m5FVlzK7ZdodoX37t9iiHLHO4gfyTAiO0t0LHSrLS2BAcpWR6Hlz9aSyHSkCtN2xzF EN9itfurbulb9QO+HQsMmKLVC1Zg3uRVStP7ZdjZObiXUDiZO5JTaYzgEUMWVxl/hWIp Vf3mOBny2czcXVW5qH4KjeIz/onbMfDgZqlcmiLgciEO6uWzvaeGVUBDxzbSD49ZIETP 3JMw==
X-Gm-Message-State: AJaThX6dBuaAGdma2qR6nozv79c9yWZo36JAtgQxMNO9kFH/vn43IIgi XbNRkuu5+EXSUZjb2ZHG2JZ63Q==
X-Google-Smtp-Source: AGs4zMa7ihZEmEMnmFLuWQfYxtChwqpMLF8rbMPXVHK2qQeBEUv4Wdlcf7WYRszFa0eokPrNoLI62A==
X-Received: by 10.159.233.198 with SMTP id b6mr3935168plr.350.1510759671562; Wed, 15 Nov 2017 07:27:51 -0800 (PST)
Received: from DESKTOPFLHJVQJ ([2001:67c:1232:144:6d1f:df87:592f:459b]) by smtp.gmail.com with ESMTPSA id t9sm36853382pgr.3.2017.11.15.07.27.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 07:27:50 -0800 (PST)
From: "Mehmet Ersue" 
To: "'Robert Wilton'" , "'Martin Bjorklund'" , 
References: <20171115.101454.1576716701146734257.mbj@tail-f.com> 
In-Reply-To: 
Date: Wed, 15 Nov 2017 23:27:49 +0800
Message-ID: <00f201d35e26$4d6d4010$e847c030$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGxefq6yqyvOLF6jhxyeqpBlh8GFwHgxCcMo0pQdmA=
Content-Language: de
Archived-At: 
Subject: Re: [netmod] tree diagram guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 15:27:54 -0000

Hi All,

I think having the tree-related guidelines in the tree draft and =
finalizing 6087bis as planned is useful.
That said a NETMOD wiki explaining the available guidelines with =
pointers can be used as a starting point and would be additionally =
helpful.

Mehmet

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
> Wilton
> Sent: Wednesday, November 15, 2017 6:53 PM
> To: Martin Bjorklund ; netmod@ietf.org
> Subject: Re: [netmod] tree diagram guidelines
>=20
> I liked the suggestion from Chris Hopps:
>=20
> I think that it was along the lines of ...
>=20
> The RFC contains a reference at the top that states that updates to =
the
> guidelines is available on a wiki at ....
>=20
> Every few years the guidelines on the wiki can be folded into a latest =
version
> of the guidelines draft.
>=20
> 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, =
or MEF be
> using the latest draft guidelines, or should then use the published =
RFC until
> 6087bis is actually republshed?
>=20
> Thanks,
> Rob
>=20
>=20
> On 15/11/2017 10:14, Martin Bjorklund wrote:
> > Hi,
> >
> > There was a proposal in the meeting today to have the guidelines for
> > tree diagrams in a wiki, instead of having them in 6087bis or in the
> > tree diagram document.
> >
> > Was the proposal really to have a wiki for just the tree guidelines,
> > or was the proposal to withdraw 6087bis from the process and instead
> > publish all guidelines as a wiki?
> >
> > If it is the former, is it really worth it?
> >
> > Advantages with a wiki:
> >
> >    +  It can be updated more easily
> >
> > Some drawbacks:
> >
> >    -  It can be updated more easily
> >       (meaning they are less stable)
> >
> >    -  Wikis tend to not be alive after some time, and are not that
> >       easy to find.  Just try to find the various YANG-related wikis
> >       we've tried to maintain over the years.
> >
> >    -  Links in RFCs also have problems.  Sites are re-orginized etc.
> >       As an example, the link to the security guidelines template in
> >       RFC 6087 doesn't work anymore.
> >
> >    -  People that are looking for a stable reference will have =
problems
> >       (I think Rob mentioned that IEEE still refer to RFC 6087 =
(which
> >       is understandable; that's the published version).
> >
> >    -  Who maintains the Wiki, and what are the rules for updating =
it?
> >
> >
> > I suggest we have the tree-related guidelines (actually just a few
> > sentences) in the tree draft, and since 6087bis already refers to =
this
> > document it is not a big problem that guidelines are spread out over
> > several documents that are difficult to find.
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > 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


From nobody Wed Nov 15 09:21:35 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E205E1272E1 for ; Wed, 15 Nov 2017 09:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HSLNGipypfn0 for ; Wed, 15 Nov 2017 09:21:30 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DD8127241 for ; Wed, 15 Nov 2017 09:21:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id D0CFF1406999; Wed, 15 Nov 2017 18:21:27 +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 WX8Omiv_LjPV; Wed, 15 Nov 2017 18:21:27 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id AA23B1406998; Wed, 15 Nov 2017 18:21:27 +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 npheC5acNITC; Wed, 15 Nov 2017 18:21:27 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 63FAF1406974; Wed, 15 Nov 2017 18:21:27 +0100 (CET)
To: Robert Wilton , "netmod@ietf.org" 
References: 
From: Vladimir Vassilev 
Message-ID: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com>
Date: Wed, 15 Nov 2017 18:21:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C0806452879FAD904629D7A9"
Content-Language: nb
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 17:21:34 -0000

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

Hello,

I have a proposal based on  that provides an elegant solution=20
to consider as a 3rd option.=C2=A0 It is based on keeping exactly the sam=
e=20
model as in RFC 7895 and using  RPC to retrieve datastore=20
specific yang-library instance data in a similar way one would use=20
 to retrieve the datastore contents. In addition a top level=20
config=3Dfalse container e.g. /datastores with list of supported=20
datastores that does not need to be part of the yang-library module:

module: ietf-datastores
+--ro datastores
|=C2=A0 +--ro datastore* [name]
|=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 identityref

Vladimir

On 11/09/2017 05:51 PM, Robert Wilton wrote:
>
> Hi,
>
> Given some of the feedback related to the complexity of the YANG=20
> library bis structure, we have come up with two other possible=20
> structures for the YANG library data:
>
> (1) A simplified structure to make YANG library meet the NMDA=20
> requirements, but that is closer to the existing YANG library=20
> structure, and arguably simpler.
> (2) An enhanced version of the structure (1) above, that is also=20
> extended to allow the structure to be reused for schema-mount via an=20
> augmentation.
>
> For reference, at the end of this email, I have also included the tree=20
> diagram of the existing YANG library, and the current YANG library bis=20
> draft (draft-ietf-netconf-rfc7895bis-02) version.
>
> Considering the two new YANG library structures:
>
> ------------------------
>
> *(1) A simplified structure to make YANG library meet the NMDA=20
> requirements, but that is closer to the existing YANG library structure=
.*
>
> The main changes are:
> (i) Split "implemented modules" and "import-only-modules" into two=20
> separate lists, making the most important list (i.e. implemented=20
> modules) keyed by module name only and hence easier to reference.
> (ii) Assume modules are implemented in all datastores by default (with=20
> a "not-implemented-in" leaflist of datastores that a module is not=20
> implemented in).
> (iii) Assume that features are implemented in all datastores by=20
> default (with a "not-implemented-in" leaflist of datastores that a=20
> feature is not implemented in).
> (iv) Deleted module-sets.
> (v) Datastores are now just a list of supported datastores (that could=20
> potentially be extended with further per datastore properties in future=
).
>
> Manually generated tree output for proposed YANG library:
>
> module: ietf-yang-library
> =C2=A0+--ro yang-library
> =C2=A0=C2=A0=C2=A0 +--ro modules
> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 revision-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0 =
yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=
=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/nam=
e
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/nam=
e
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |
> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name revision]
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:yang-ident=
ifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro na=
me=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro re=
vision=C2=A0=C2=A0=C2=A0 yang:revision-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro sc=
hema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future per datasto=
re properties.
> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 identityref
> =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s=
tring
>
> ------------------------------
>
> *(2) An enhanced version of the structure (1) above, that is extended=20
> to allow the structure to be reused for schema-mount via an augmentatio=
n.*
>
> This is similar to the structure above, except that the "the set of=20
> modules" is contained in a list of named schema (e.g. similar to the=20
> schema mount draft), allowing this structure to be re-used for schema=20
> mount.
>
> Schema mount would be expected to augment yang-library to add in the=20
> additional schema mount information.=C2=A0 In the tree diagram, I have=20
> shown the schema-mount mount-point augmentation, but not including=20
> namespaces yet.
>
> Every server would be required to provide at least one schema in the=20
> schema list, and the primary schema for the device would always be=20
> given the name "primary".
>
> module: ietf-yang-library
> =C2=A0+--ro yang-library
> =C2=A0=C2=A0=C2=A0 +--ro schema* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 string
> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 string
> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 yang:revision-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=C2=A0 =
yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=
=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/nam=
e
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented-in*
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/nam=
e
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-mount:mount-point* [label]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro label=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro config?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (schema-ref)
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--:(inline)
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
|=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--:(use-schema)
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 +--ro use-schema* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=
> /yang-library/schema/name
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro parent-reference* yang:xpath1.0
> =C2=A0=C2=A0=C2=A0 |=C2=A0 |
> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [name revision]
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name yang:yang-ident=
ifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro namespace=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submodule* [name]
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro na=
me=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro re=
vision=C2=A0=C2=A0=C2=A0 yang:revision-identifier
> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro sc=
hema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
> =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows future per datasto=
re properties.
> =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 identityref
> =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s=
tring
>
> Please can you provide comments on these structures, in particular:
>
> Is this version better (i.e. simpler) that the version currently in=20
> draft-ietf-netconf-rfc7895bis-02 (below)?
>
> Should we try and make the structure extensible for schema-mount via=20
> augmentation (i.e. version (2)), or is it better that schema-mount has=20
> its own separate subtree?
>
> For reference only I have included the existing YANG library and YANG=20
> library bis draft tree diagrams.
>
> Thanks,
> Rob
>
>
> -----------------------------
>
> *** FOR REFERENCE ONLY ***
>
> (3)=C2=A0 The current YANG library structure in YANG library bis=20
> (draft-ietf-netconf-rfc7895bis-02)
>
>     module: ietf-yang-library
>         +--ro yang-library
>            +--ro modules
>            |  +--ro module* [id]
>            |     +--ro id                  string
>            |     +--ro name                yang:yang-identifier
>            |     +--ro revision?           revision-identifier
>            |     +--ro schema?             inet:uri
>            |     +--ro namespace           inet:uri
>            |     +--ro feature*            yang:yang-identifier
>            |     +--ro deviation* [module]
>            |     |  +--ro module    -> ../../id
>            |     +--ro conformance-type    enumeration
>            |     +--ro submodule* [name]
>            |        +--ro name        yang:yang-identifier
>            |        +--ro revision?   revision-identifier
>            |        +--ro schema?     inet:uri
>            +--ro module-sets
>            |  +--ro module-set* [id]
>            |     +--ro id        string
>            |     +--ro module*   -> ../../../modules/module/id
>            +--ro datastores
>            |  +--ro datastore* [name]
>            |     +--ro name          identityref
>            |     +--ro module-set
>            |             -> ../../../module-sets/module-set/id
>            +--ro checksum       string
>
> -----------------------------
>
> *** FOR REFERENCE ONLY ***
>
> (4)=C2=A0 The current YANG library structure (RFC 7895)
>
>        +--ro modules-state
>           +--ro module-set-id    string
>           +--ro module* [name revision]
>              +--ro name                yang:yang-identifier
>              +--ro revision            union
>              +--ro schema?             inet:uri
>              +--ro namespace           inet:uri
>              +--ro feature*            yang:yang-identifier
>              +--ro deviation* [name revision]
>              |  +--ro name        yang:yang-identifier
>              |  +--ro revision    union
>              +--ro conformance-type    enumeration
>              +--ro submodule* [name revision]
>                 +--ro name        yang:yang-identifier
>                 +--ro revision    union
>                 +--ro schema?     inet:uri
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--------------C0806452879FAD904629D7A9
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Hello,

    

    I have a proposal based on <get-data> that provides an elegant
    solution to consider as a 3rd option.=C2=A0 It is based on keeping
    exactly the same model as in RFC 7895 and using <get-data> RPC
    to retrieve datastore specific yang-library instance data in a
    similar way one would use <get-data> to retrieve the datastore
    contents. In addition a top level config=3Dfalse container e.g.
    /datastores with list of supported datastores that does not need to
    be part of the yang-library module:

    

    module: ietf-datastores

    +--ro datastores

    |=C2=A0 +--ro datastore* [name]

    |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 identityref

    

    Vladimir

    

    On 11/09/2017 05:51 PM, Robert Wilton wrote:

    

      
      
Hi,

      
Given some of the feedback related to the complexity of the
        YANG library bis structure, we have come up with two other
        possible structures for the YANG library data:

      
(1) A simplified structure to make YANG library meet the NMDA
        requirements, but that is closer to the existing YANG library
        structure, and arguably simpler.

        (2) An enhanced version of the structure (1) above, that is also
        extended to allow the structure to be reused for schema-mount
        via an augmentation.

      
For reference, at the end of this email, I have also included
        the tree diagram of the existing YANG library, and the current
        YANG library bis draft (draft-ietf-netconf-rfc7895bis-02)
        version.

      

      
Considering the two new YANG library structures:

      

      
------------------------

      

      
(1) A simplified structure to make YANG library meet the
          NMDA requirements, but that is closer to the existing YANG
          library structure.

      
The main changes are:

        (i) Split "implemented modules" and "import-only-modules" into
        two separate lists, making the most important list (i.e.
        implemented modules) keyed by module name only and hence easier
        to reference.

        (ii) Assume modules are implemented in all datastores by default
        (with a "not-implemented-in" leaflist of datastores that a
        module is not implemented in).

        (iii) Assume that features are implemented in all datastores by
        default (with a "not-implemented-in" leaflist of datastores that
        a feature is not implemented in).

        (iv) Deleted module-sets.

        (v) Datastores are now just a list of supported datastores (that
        could potentially be extended with further per datastore
        properties in future).

      

      
Manually generated tree output for proposed YANG library:

      
module: ietf-yang-library

        =C2=A0+--ro yang-library

        =C2=A0=C2=A0=C2=A0 +--ro modules

        =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]=


        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 revision-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [nam=
e]

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revisio=
n?=C2=A0=C2=A0 yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented=
-in*

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
          /yang-library/datastore/name

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]=


        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-imp=
lemented-in*

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
          /yang-library/datastore/name

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*=


        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> =
../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 +--ro import-only-module* [na=
me revision]

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
          yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revis=
ion=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uni=
on

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schem=
a?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 inet:uri

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro names=
pace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri=


        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submo=
dule* [name]

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-ide=
ntifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0 yang:revision-identifier=


        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

        =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows fut=
ure per
          datastore properties.

        =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

        =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 string

      

      
------------------------------

      
(2) An enhanced version of the structure (1) above, that is
          extended to allow the structure to be reused for schema-mount
          via an augmentation.

      
This is similar to the structure above, except that the "the
        set of modules" is contained in a list of named schema (e.g.
        similar to the schema mount draft), allowing this structure to
        be re-used for schema mount.

      
Schema mount would be expected to augment yang-library to add
        in the additional schema mount information.=C2=A0 In the tree
        diagram, I have shown the schema-mount mount-point augmentation,
        but not including namespaces yet.

      
Every server would be required to provide at least one schema
        in the schema list, and the primary schema for the device would
        always be given the name "primary".

      
module: ietf-yang-library

        =C2=A0+--ro yang-library

        =C2=A0=C2=A0=C2=A0 +--ro schema* [name]

        =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

        =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 string

        =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]=


        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 yang:revision-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [nam=
e]

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revisio=
n?=C2=A0=C2=A0 yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented=
-in*

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
          /yang-library/datastore/name

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]=


        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-imp=
lemented-in*

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
          /yang-library/datastore/name

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*=


        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-mount:mount=
-point* [label]

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--=
ro label=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identi=
fier

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--=
ro config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--=
ro (schema-ref)

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +--:(inline)

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 em=
pty

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +--:(use-schema)

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro use-schema* [name]

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 ->
          /yang-library/schema/name

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro parent-reference*=C2=
=A0=C2=A0
          yang:xpath1.0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 

        =C2=A0=C2=A0=C2=A0 |=C2=A0 |

        =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [na=
me revision]

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
          yang:yang-identifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revis=
ion=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uni=
on

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schem=
a?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 inet:uri

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro names=
pace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri=


        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submo=
dule* [name]

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-ide=
ntifier

        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0 yang:revision-identifier=


        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

        =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows fut=
ure per
          datastore properties.

        =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

        =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 string

      
Please can you provide comments on these structures, in
        particular:

      
Is this version better (i.e. simpler) that the version
        currently in draft-ietf-netconf-rfc7895bis-02 (below)?

      

      
Should we try and make the structure extensible for
        schema-mount via augmentation (i.e. version (2)), or is it
        better that schema-mount has its own separate subtree?

      
For reference only I have included the existing YANG library
        and YANG library bis draft tree diagrams.

      

      
Thanks,

        Rob

      

      


      

      
-----------------------------

      
*** FOR REFERENCE ONLY ***

      

      
(3)=C2=A0 The current YANG library structure in YANG library bis
        (draft-ietf-netconf-rfc7895bis-02)

      

      
   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

      
-----------------------------

      
*** FOR REFERENCE ONLY ***

      

      
(4)=C2=A0 The current YANG library structure (RFC 7895)

      
      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



      
 

      

      

      

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


    

    

  


--------------C0806452879FAD904629D7A9--


From nobody Wed Nov 15 09:29: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 6FE8C127241 for ; Wed, 15 Nov 2017 09:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 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, 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 s5zZVsZ7xfpi for ; Wed, 15 Nov 2017 09:29:29 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC31E126CD8 for ; Wed, 15 Nov 2017 09:29:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28169; q=dns/txt; s=iport; t=1510766968; x=1511976568; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=sThAUiTYlU5aAZYpnp3a1/Jv7VSXGlwBoQ9rfs3TINs=; b=ObNW+GOH5h/zBXQO3pp+9ezD9TbNpTfxxzkSFknDikAqs7YBtGgSf4Y/ 1j54n/khL3him3XuHOmEF59prgH/TPQyrkz8LeOjANrtAPIt6Vlk7vjjA vWjE3Jd0TvDlppAtwe3jojAv41pOyP2t0HCSUc1zvyr89+nIF5EhxPasr 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAQDMeAxa/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuJ4N/ih+PIIFXJpZdEIIBChgBCoRJTwKFDj8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHwEBBAEBIQRHGwkCGCAKAgInMAYBDAYCAQEXigkQiyudaIFtOiaKb?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgzSCB4FVgWkpC4FpgQ2EZQESAQmDK4J?= =?us-ascii?q?jBYo0hz2BE48zlQaCFYYKg2CHRY46h3SBOR84QkFxNCEIHRVJgmSEbDQ2iVuCN?= =?us-ascii?q?QEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,399,1505779200"; d="scan'208,217"; a="31348139"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 17:29:27 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAFHTQUU031879; Wed, 15 Nov 2017 17:29:26 GMT
To: Vladimir Vassilev , "netmod@ietf.org" 
References:  <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com>
From: Robert Wilton 
Message-ID: <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com>
Date: Thu, 16 Nov 2017 01:29:25 +0800
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: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com>
Content-Type: multipart/alternative; boundary="------------ACEDF0DCD72BF670F763C3CB"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 17:29:32 -0000

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

I don't think that this is really a good idea.  You would end up 
returning server metadata in addition to the configuration.

I still think that the YANG library proposal is the best solution.

Thanks,
Rob


On 16/11/2017 01:21, Vladimir Vassilev wrote:
> Hello,
>
> I have a proposal based on  that provides an elegant 
> solution to consider as a 3rd option.  It is based on keeping exactly 
> the same model as in RFC 7895 and using  RPC to retrieve 
> datastore specific yang-library instance data in a similar way one 
> would use  to retrieve the datastore contents. In addition a 
> top level config=false container e.g. /datastores with list of 
> supported datastores that does not need to be part of the yang-library 
> module:
>
> module: ietf-datastores
> +--ro datastores
> |  +--ro datastore* [name]
> |     +--ro name          identityref
>
> Vladimir
>
> On 11/09/2017 05:51 PM, Robert Wilton wrote:
>>
>> Hi,
>>
>> Given some of the feedback related to the complexity of the YANG 
>> library bis structure, we have come up with two other possible 
>> structures for the YANG library data:
>>
>> (1) A simplified structure to make YANG library meet the NMDA 
>> requirements, but that is closer to the existing YANG library 
>> structure, and arguably simpler.
>> (2) An enhanced version of the structure (1) above, that is also 
>> extended to allow the structure to be reused for schema-mount via an 
>> augmentation.
>>
>> For reference, at the end of this email, I have also included the 
>> tree diagram of the existing YANG library, and the current YANG 
>> library bis draft (draft-ietf-netconf-rfc7895bis-02) version.
>>
>> Considering the two new YANG library structures:
>>
>> ------------------------
>>
>> *(1) A simplified structure to make YANG library meet the NMDA 
>> requirements, but that is closer to the existing YANG library structure.*
>>
>> The main changes are:
>> (i) Split "implemented modules" and "import-only-modules" into two 
>> separate lists, making the most important list (i.e. implemented 
>> modules) keyed by module name only and hence easier to reference.
>> (ii) Assume modules are implemented in all datastores by default 
>> (with a "not-implemented-in" leaflist of datastores that a module is 
>> not implemented in).
>> (iii) Assume that features are implemented in all datastores by 
>> default (with a "not-implemented-in" leaflist of datastores that a 
>> feature is not implemented in).
>> (iv) Deleted module-sets.
>> (v) Datastores are now just a list of supported datastores (that 
>> could potentially be extended with further per datastore properties 
>> in future).
>>
>> Manually generated tree output for proposed YANG library:
>>
>> module: ietf-yang-library
>>  +--ro yang-library
>>     +--ro modules
>>     |  +--ro module* [name]
>>     |  |  +--ro name           yang:yang-identifier
>>     |  |  +--ro revision?      revision-identifier
>>     |  |  +--ro schema?        inet:uri
>>     |  |  +--ro namespace      inet:uri
>>     |  |  +--ro submodule* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro revision?   yang:yang-identifier
>>     |  |  |  +--ro schema?     inet:uri
>>     |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro feature* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro deviation*
>>     |  |                 -> ../name
>>     |  |
>>     |  +--ro import-only-module* [name revision]
>>     |     +--ro name yang:yang-identifier
>>     |     +--ro revision            union
>>     |     +--ro schema?             inet:uri
>>     |     +--ro namespace           inet:uri
>>     |     +--ro submodule* [name]
>>     |        +--ro name        yang:yang-identifier
>>     |        +--ro revision yang:revision-identifier
>>     |        +--ro schema?     inet:uri
>>     +--ro datastore* [name] // Allows future per datastore properties.
>>     |  +--ro name          identityref
>>     +--ro checksum       string
>>
>> ------------------------------
>>
>> *(2) An enhanced version of the structure (1) above, that is extended 
>> to allow the structure to be reused for schema-mount via an 
>> augmentation.*
>>
>> This is similar to the structure above, except that the "the set of 
>> modules" is contained in a list of named schema (e.g. similar to the 
>> schema mount draft), allowing this structure to be re-used for schema 
>> mount.
>>
>> Schema mount would be expected to augment yang-library to add in the 
>> additional schema mount information.  In the tree diagram, I have 
>> shown the schema-mount mount-point augmentation, but not including 
>> namespaces yet.
>>
>> Every server would be required to provide at least one schema in the 
>> schema list, and the primary schema for the device would always be 
>> given the name "primary".
>>
>> module: ietf-yang-library
>>  +--ro yang-library
>>     +--ro schema* [name]
>>     |  +--ro name           string
>>     |  +--ro checksum       string
>>     |  +--ro module* [name]
>>     |  |  +--ro name           yang:yang-identifier
>>     |  |  +--ro revision? yang:revision-identifier
>>     |  |  +--ro schema?        inet:uri
>>     |  |  +--ro namespace      inet:uri
>>     |  |  +--ro submodule* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro revision?   yang:yang-identifier
>>     |  |  |  +--ro schema?     inet:uri
>>     |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro feature* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro deviation*
>>     |  |  |              -> ../name
>>     |  |  +- schema-mount:mount-point* [label]
>>     |  |     +--ro label         yang:yang-identifier
>>     |  |     +--ro config?       boolean
>>     |  |     +--ro (schema-ref)
>>     |  |        +--:(inline)
>>     |  |        |  +--ro inline?       empty
>>     |  |        +--:(use-schema)
>>     |  |           +--ro use-schema* [name]
>>     |  |              +--ro name
>>     |  |              |       -> /yang-library/schema/name
>>     |  |              +--ro parent-reference* yang:xpath1.0
>>     |  |
>>     |  +--ro import-only-module* [name revision]
>>     |     +--ro name yang:yang-identifier
>>     |     +--ro revision            union
>>     |     +--ro schema?             inet:uri
>>     |     +--ro namespace           inet:uri
>>     |     +--ro submodule* [name]
>>     |        +--ro name        yang:yang-identifier
>>     |        +--ro revision yang:revision-identifier
>>     |        +--ro schema?     inet:uri
>>     +--ro datastore* [name] // Allows future per datastore properties.
>>     |  +--ro name          identityref
>>     +--ro checksum       string
>>
>> Please can you provide comments on these structures, in particular:
>>
>> Is this version better (i.e. simpler) that the version currently in 
>> draft-ietf-netconf-rfc7895bis-02 (below)?
>>
>> Should we try and make the structure extensible for schema-mount via 
>> augmentation (i.e. version (2)), or is it better that schema-mount 
>> has its own separate subtree?
>>
>> For reference only I have included the existing YANG library and YANG 
>> library bis draft tree diagrams.
>>
>> Thanks,
>> Rob
>>
>>
>> -----------------------------
>>
>> *** FOR REFERENCE ONLY ***
>>
>> (3)  The current YANG library structure in YANG library bis 
>> (draft-ietf-netconf-rfc7895bis-02)
>>
>>     module: ietf-yang-library
>>         +--ro yang-library
>>            +--ro modules
>>            |  +--ro module* [id]
>>            |     +--ro id                  string
>>            |     +--ro name                yang:yang-identifier
>>            |     +--ro revision?           revision-identifier
>>            |     +--ro schema?             inet:uri
>>            |     +--ro namespace           inet:uri
>>            |     +--ro feature*            yang:yang-identifier
>>            |     +--ro deviation* [module]
>>            |     |  +--ro module    -> ../../id
>>            |     +--ro conformance-type    enumeration
>>            |     +--ro submodule* [name]
>>            |        +--ro name        yang:yang-identifier
>>            |        +--ro revision?   revision-identifier
>>            |        +--ro schema?     inet:uri
>>            +--ro module-sets
>>            |  +--ro module-set* [id]
>>            |     +--ro id        string
>>            |     +--ro module*   -> ../../../modules/module/id
>>            +--ro datastores
>>            |  +--ro datastore* [name]
>>            |     +--ro name          identityref
>>            |     +--ro module-set
>>            |             -> ../../../module-sets/module-set/id
>>            +--ro checksum       string
>>
>> -----------------------------
>>
>> *** FOR REFERENCE ONLY ***
>>
>> (4)  The current YANG library structure (RFC 7895)
>>
>>        +--ro modules-state
>>           +--ro module-set-id    string
>>           +--ro module* [name revision]
>>              +--ro name                yang:yang-identifier
>>              +--ro revision            union
>>              +--ro schema?             inet:uri
>>              +--ro namespace           inet:uri
>>              +--ro feature*            yang:yang-identifier
>>              +--ro deviation* [name revision]
>>              |  +--ro name        yang:yang-identifier
>>              |  +--ro revision    union
>>              +--ro conformance-type    enumeration
>>              +--ro submodule* [name revision]
>>                 +--ro name        yang:yang-identifier
>>                 +--ro revision    union
>>                 +--ro schema?     inet:uri
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>


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


  
    
  
  
    I don't think that this is really a good idea.  You would end up
    returning server metadata in addition to the configuration.

    

    I still think that the YANG library proposal is the best solution.

    

    Thanks,

    Rob

    

    

    
On 16/11/2017 01:21, Vladimir Vassilev
      wrote:

    

    

      
      Hello,

      

      I have a proposal based on <get-data> that provides an
      elegant solution to consider as a 3rd option.  It is based on
      keeping exactly the same model as in RFC 7895 and using
      <get-data> RPC to retrieve datastore specific yang-library
      instance data in a similar way one would use <get-data> to
      retrieve the datastore contents. In addition a top level
      config=false container e.g. /datastores with list of supported
      datastores that does not need to be part of the yang-library
      module:

      

      module: ietf-datastores

      +--ro datastores

      |  +--ro datastore* [name]

      |     +--ro name          identityref

      

      Vladimir

      

      On 11/09/2017 05:51 PM, Robert Wilton wrote:

      

        
Hi,

        
Given some of the feedback related to the complexity of the
          YANG library bis structure, we have come up with two other
          possible structures for the YANG library data:

        
(1) A simplified structure to make YANG library meet the NMDA
          requirements, but that is closer to the existing YANG library
          structure, and arguably simpler.

          (2) An enhanced version of the structure (1) above, that is
          also extended to allow the structure to be reused for
          schema-mount via an augmentation.

        
For reference, at the end of this email, I have also included
          the tree diagram of the existing YANG library, and the current
          YANG library bis draft (draft-ietf-netconf-rfc7895bis-02)
          version.

        

        
Considering the two new YANG library structures:

        

        
------------------------

        

        
(1) A simplified structure to make YANG library meet the
            NMDA requirements, but that is closer to the existing YANG
            library structure.

        
The main changes are:

          (i) Split "implemented modules" and "import-only-modules" into
          two separate lists, making the most important list (i.e.
          implemented modules) keyed by module name only and hence
          easier to reference.

          (ii) Assume modules are implemented in all datastores by
          default (with a "not-implemented-in" leaflist of datastores
          that a module is not implemented in).

          (iii) Assume that features are implemented in all datastores
          by default (with a "not-implemented-in" leaflist of datastores
          that a feature is not implemented in).

          (iv) Deleted module-sets.

          (v) Datastores are now just a list of supported datastores
          (that could potentially be extended with further per datastore
          properties in future).

        

        
Manually generated tree output for proposed YANG library:

        
module: ietf-yang-library

           +--ro yang-library

              +--ro modules

              |  +--ro module* [name]

              |  |  +--ro name           yang:yang-identifier

              |  |  +--ro revision?      revision-identifier

              |  |  +--ro schema?        inet:uri

              |  |  +--ro namespace      inet:uri

              |  |  +--ro submodule* [name]

              |  |  |  +--ro name        yang:yang-identifier

              |  |  |  +--ro revision?   yang:yang-identifier

              |  |  |  +--ro schema?     inet:uri

              |  |  +--ro not-implemented-in*

              |  |  |              ->
            /yang-library/datastore/name

              |  |  +--ro feature* [name]

              |  |  |  +--ro name        yang:yang-identifier

              |  |  |  +--ro not-implemented-in*

              |  |  |              ->
            /yang-library/datastore/name

              |  |  +--ro deviation*

              |  |                 -> ../name              

              |  |

              |  +--ro import-only-module* [name revision]

              |     +--ro name               
            yang:yang-identifier

              |     +--ro revision            union

              |     +--ro schema?             inet:uri

              |     +--ro namespace           inet:uri

              |     +--ro submodule* [name]

              |        +--ro name        yang:yang-identifier

              |        +--ro revision   
            yang:revision-identifier

              |        +--ro schema?     inet:uri

              +--ro datastore* [name] // Allows future per
            datastore properties.

              |  +--ro name          identityref

              +--ro checksum       string

        

        
------------------------------

        
(2) An enhanced version of the structure (1) above, that
            is extended to allow the structure to be reused for
            schema-mount via an augmentation.

        
This is similar to the structure above, except that the "the
          set of modules" is contained in a list of named schema (e.g.
          similar to the schema mount draft), allowing this structure to
          be re-used for schema mount.

        
Schema mount would be expected to augment yang-library to add
          in the additional schema mount information.  In the tree
          diagram, I have shown the schema-mount mount-point
          augmentation, but not including namespaces yet.

        
Every server would be required to provide at least one schema
          in the schema list, and the primary schema for the device
          would always be given the name "primary".

        
module: ietf-yang-library

           +--ro yang-library

              +--ro schema* [name]

              |  +--ro name           string

              |  +--ro checksum       string

              |  +--ro module* [name]

              |  |  +--ro name           yang:yang-identifier

              |  |  +--ro revision?     
            yang:revision-identifier

              |  |  +--ro schema?        inet:uri

              |  |  +--ro namespace      inet:uri

              |  |  +--ro submodule* [name]

              |  |  |  +--ro name        yang:yang-identifier

              |  |  |  +--ro revision?   yang:yang-identifier

              |  |  |  +--ro schema?     inet:uri

              |  |  +--ro not-implemented-in*

              |  |  |              ->
            /yang-library/datastore/name

              |  |  +--ro feature* [name]

              |  |  |  +--ro name        yang:yang-identifier

              |  |  |  +--ro not-implemented-in*

              |  |  |              ->
            /yang-library/datastore/name

              |  |  +--ro deviation*

              |  |  |              -> ../name       

              |  |  +- schema-mount:mount-point* [label]

              |  |     +--ro label         yang:yang-identifier

              |  |     +--ro config?       boolean

              |  |     +--ro (schema-ref)

              |  |        +--:(inline)

              |  |        |  +--ro inline?       empty

              |  |        +--:(use-schema)

              |  |           +--ro use-schema* [name]

              |  |              +--ro name

              |  |              |       ->
            /yang-library/schema/name

              |  |              +--ro parent-reference*  
            yang:xpath1.0          

              |  |

              |  +--ro import-only-module* [name revision]

              |     +--ro name               
            yang:yang-identifier

              |     +--ro revision            union

              |     +--ro schema?             inet:uri

              |     +--ro namespace           inet:uri

              |     +--ro submodule* [name]

              |        +--ro name        yang:yang-identifier

              |        +--ro revision   
            yang:revision-identifier

              |        +--ro schema?     inet:uri

              +--ro datastore* [name] // Allows future per
            datastore properties.

              |  +--ro name          identityref

              +--ro checksum       string

        
Please can you provide comments on these structures, in
          particular:

        
Is this version better (i.e. simpler) that the version
          currently in draft-ietf-netconf-rfc7895bis-02 (below)?

        

        
Should we try and make the structure extensible for
          schema-mount via augmentation (i.e. version (2)), or is it
          better that schema-mount has its own separate subtree?

        
For reference only I have included the existing YANG library
          and YANG library bis draft tree diagrams.

        

        
Thanks,

          Rob

        

        


        

        
-----------------------------

        
*** FOR REFERENCE ONLY ***

        

        
(3)  The current YANG library structure in YANG library bis
          (draft-ietf-netconf-rfc7895bis-02)

        

        
   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

        
-----------------------------

        
*** FOR REFERENCE ONLY ***

        

        
(4)  The current YANG library structure (RFC 7895)

        
      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



        
 

        

        

        

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


      

      

    

    

  


--------------ACEDF0DCD72BF670F763C3CB--


From nobody Wed Nov 15 09:41: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 DF15F1200F1 for ; Wed, 15 Nov 2017 09:41:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level: 
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 NPOGnpOJ9J5F for ; Wed, 15 Nov 2017 09:41:53 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90ADB1276AF for ; Wed, 15 Nov 2017 09:41:52 -0800 (PST)
X-AuditID: c1b4fb2d-f23ff70000001e3d-55-5a0c7c5e608b
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AF.3A.07741.E5C7C0A5; Wed, 15 Nov 2017 18:41:50 +0100 (CET)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 18:41:50 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ez2iaR1HHJHIuKeCJ9I3wN0YeRHWEQ0l6TqPwRPCoHg=; b=jrMS5xmFLppKLDN+Wy08ErQRnXrlESjfsyWNut0h2x6JMyeuTKCe5V4IBaIBJzXKhDKw7wqJAIqP1tDTUrZba/kVi6SzXUa4yue9Ukbud+9kkiEbOqGqmPXxKKMvPGKwFrRFc8ichiahAIkZ1/H/HS8CSc3geYu/aOJGD1juXX0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [10.10.12.142] (103.26.221.241) by HE1PR07MB3434.eurprd07.prod.outlook.com (2603:10a6:7:2c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Wed, 15 Nov 2017 17:41:47 +0000
To: Martin Bjorklund , 
CC: 
References: <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com> <20171115.121716.454716475078719607.mbj@tail-f.com> <1510751195.21877.25.camel@nic.cz> <20171115.142017.1071562845381546650.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: <7f716912-3dcb-93cd-ed8e-9a2a168e91a7@ericsson.com>
Date: Thu, 16 Nov 2017 01:41:29 +0800
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: <20171115.142017.1071562845381546650.mbj@tail-f.com>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [103.26.221.241]
X-ClientProxiedBy: SG2PR0302CA0018.apcprd03.prod.outlook.com (2603:1096:3:2::28) To HE1PR07MB3434.eurprd07.prod.outlook.com (2603:10a6:7:2c::13)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: fc6b4400-7f89-492d-89f5-08d52c5025f4
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR07MB3434; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3434; 3:WNbJm4XSFNWrfETw3KzEKdLuB/+y8UGQRmW/KR36UT9hDg8SxTcJiZY1FmHZemP/Fxa2l/F/vAjwmLMK6bqOn3NwoTX/tM6SVy8jqI72mcJYeh3PVpXL9fTFFYh+y171TryYPU3Dxu5DzMszTpViAzk9BE640GakpDA7xamSuAHrsEZ/MJEqcsH/+HxNh9t6IgZAbwRzbNQco1ft1F5xSUwMVqRZPs/rDg+oqQGMrRHOKfq1CTFgOVr+h182mMJr; 25:jRdyM2Mo2Zws7Siz0TALGVvGZ/6gn1tVX4Zc+nsbU8lv5n8PBPkghYUGe5yyd7NW4RUZvLvmrySXvQfwlf/Er20kGG2kfEfs0qnKnJSg0hJsepeS6YZvGKHmGcO1Yj5sJ51T0oYlGXQeoe97PpYCgqA1inAi6LaVsJESzngQOlo+lwPtK88BPYy7SPisIiNCOONmFXwPAWltgevHfFwiJA8/jRpKUEbqJXU7THgvITN6OmeVpjvwz2SDjbtd779mQwU1XShoeyvdAxjhO1kGi69gPeWsTTXGpy4TNjjUiUHwAv2FBT6jmF8nDYf0NJtOnTbcCiH1JJSxwJfBl/eEng==; 31:pHzVoOeWcmy3xu6D6dWy76fLdDrhhEcTcDbS2soad1+sdMltHAtkALCq13n2zOh7F+21z7L+z/KwYgYSAVEnY178CYX8Rjvtyew43ER02HFQ4sUaFw3TKGKJwUk8CLnXmriDQxz/v+BxxizqGXaVSWBFbAXr0hBA0loAkTzQtvWCKF5dDjYEghOhzK0hcWmQhRLHUHWKz6hVKBYRl34QT87vCsMAmUL8p3kHXKnfX/w=
X-MS-TrafficTypeDiagnostic: HE1PR07MB3434:
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3434; 20:n1CCcFiQasrWBP7GoiSeJVwTHO+SHmP71hSIbZtUcnKe6Zf8XDlpGqL5Qh1X8BVxu2dX0RaWTaOC+ERLyqU7lN8sU/Z7Y+p7xZmhWLW4jWUjQfdzw/bq1FhiWGeu/f+8fEL0hJ+tWasRTugDQtSBuTnbT7NgK59yF1DNHt+PA1XyrP4EhT7yHz2PXRpkJkFGBZjUJiyhb7cnBg45e2k3vLKOvzLeImvDIgdr33ErHbr8qot4vuEPck9jkotw6oyQDa1kxCckoarqOWc2wII7ShJjk1qbMIJwOPt3guRsTWom89EKey4FSOJMfyJqVH98E8zO2Eg5KCL7ErPLKnFxv+oGh8flkMXSL7xf2aiPHO26OKTS5ZswyuVQWGlSDyTv8mg4Sy+EMhDCEvGRDq+W06XivOU/tygecRcd6OhglSDTra6XB0G98kJVhYtoF0PuBycQCEiRg8mL3HByAKBYr8QbQeJHQkfxqbeldDHg5KsakKYPCjAM4sOQDm33KeCZ; 4:ndriTlXIw7E+DbWsRhtexSV6ZBjiVXTsmL/8sQAGBcz0yGSTqAcmu/4U7Co5WnnqyKYB17H1njh0nSorUBtqc3IusMpEhOaitV0RhI0XdNwLEOocuNEzTUpK3Vun/+3EvAJ/wHtFNCDacDvjfJJlV4bztTLQRVSmixe78LIzImBW+qejpOPvSzIwt/D43Lp4l563RDQ5dR1BVsdaW0Li+ViTji+SCgfxQ/AwOo+it/nVinchUR5zln2xMeclCDw0yvwPdBwwfylpLCm5zYB4br1ajzi4vsvDF+PKnl648ZKGGiH8oLPO2MiuqSguXbeIjJnbvDF3l/4iMbaDJU0dVShrsvhQWBR+P0go9CZozb+m4Gh2sIxXEilCWQVp3ak4
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(788757137089); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3434; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3434; 
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(376002)(39860400002)(252514010)(24454002)(377424004)(189002)(199003)(36756003)(97736004)(65826007)(23846002)(25786009)(77096006)(6486002)(83506002)(50466002)(15650500001)(68736007)(31696002)(5660300001)(2906002)(86362001)(53546010)(8936002)(58126008)(93886005)(189998001)(64126003)(316002)(230783001)(16576012)(54356999)(81156014)(76176999)(2950100002)(4001150100001)(53936002)(230700001)(8676002)(31686004)(33646002)(6666003)(4326008)(81166006)(105586002)(6246003)(478600001)(106356001)(65806001)(16526018)(229853002)(101416001)(561944003)(7736002)(66066001)(6116002)(3846002)(236005)(65956001)(54896002)(23676003)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3434; H:[10.10.12.142]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDM0OzIzOlB4WXRNTkVubDgzb1E5ajJIMW81Umk5LzBz?= =?utf-8?B?d2ZsR25vUDFPUU1Xa2hLZTQ2bmduM3F2MTA5bDAzSjI1NXJobXQwd1JnenAw?= =?utf-8?B?MjVTN2dhNkNsM2Q0ZmpLZUtTRGNPNWZxNThZR09jRWJYZEpleWNUaFpQZGhO?= =?utf-8?B?clhXVDlGQTF0eFEycVlnVHRTanAzeUg3eW92OTZEMU5zRmVRM3FKK0grV3Bh?= =?utf-8?B?TEdDSEwvMWk3TE1NWG9yWDVXUndUWDJ3QmRRM0NIblRMazIxRkc1dHlwT2JG?= =?utf-8?B?VmR4V0dqaEVjSEEveDlBb2h1KzF0MDBPNDdvZURZczU1OVR5V2crSVFGZTlx?= =?utf-8?B?eWcwUm5DaVVpa29NcnlJS0RmUTVXVHhSV3phNTZMNEhDbncyUUJ2YkxRRHNv?= =?utf-8?B?b05zY3VYdStxNEh3Z2dZUitmRDBWL1c0enJsZ1RrU0MyNjI0SVFKUVErRm5O?= =?utf-8?B?Zk9qYVMwZUtMbEVHa3ZZbzg2a1VLKzQ2aWdiZS9NWWJGbm5WVmh0ak54Nk5y?= =?utf-8?B?VnhmNHBJU3l2NVZkRGd2dnlzcEx1QktsZGhtdmVCWUQ4NldoMUhyR3lpUEw1?= =?utf-8?B?T2dXSmZLdTRabU1XUHIyRUc3QmdqT0tadm11Qkg0WGk2Zmt5eGh5UEJKWlo1?= =?utf-8?B?WGdWUmhQOHdBUEZmQUtZUzJKdHhOaHpldVpnMkp1T2EvUnRWMzg3Q2UwRnNy?= =?utf-8?B?RUZORFNHYzc5OVRFWnE3VEFYbFEwSUR6RG9BZUtjckxQUXZFZWEwclEzZG9L?= =?utf-8?B?UFZ4WkRmbCtSWEJUUDVVMHZ1ZFNBbkpvMUVUbGsvcEYxTmRxNmM2NU1PUG5C?= =?utf-8?B?UTBsL2FGWFZaVUdyVHRFVFlCQjJtMkpvdUc0UXJJSXhqRUdnUUdVUHdwRkVZ?= =?utf-8?B?Q1FwVXBTdzcxVXF5Ny9uem04VEJqN0E5cU1zVG40cVIzSFNRVzJNcUdTOUlJ?= =?utf-8?B?a3NadFJrOUxERVlMc2FtSmtUSXlUdzUzVWZPUFN5cFBGS2ozSndlNGhueDRn?= =?utf-8?B?TVEwbHlCNDYwSlRjYWF5M2tyRlNjc2xUT1BkVzl6RHZKVVl1d3h0YXNrVHpQ?= =?utf-8?B?TXhMeXFJMWRYbEc0N2hJaEhMRjNleW9uMUVlYmxkL2tuL0d3T2ZKOXdldUpz?= =?utf-8?B?V1d6c2JwNmJnZXFseS9vMmZjVE82eDhCaVJiVzgwcnpVcFBjQ2VpaVE0bTdK?= =?utf-8?B?bVhPYlZ0SnluVy9nd3pGOXhpQ3VVSys0QW9PYjMxdjVOY3g4anFlTGZoWCt0?= =?utf-8?B?MmF6MmVKSnI0NStnRFAzb3FoZ2lSdnk0UitxQTlqUVV3cEh0MXBmRFFwRnpY?= =?utf-8?B?N3EvYUkyZEREVTBmNVZWazZkNEtaRnIrd3Y3OHgzcU5RaFdhT1pXSTRiRWRx?= =?utf-8?B?WWE1dmNqc2pRNFNVR3UvbXFGMW02alNrWmhpelo0OHZDRUl3cE04Vitsc0cx?= =?utf-8?B?Yk8zSkNISTQ3S3lzT00wTmFzdVRjZmlEb1NOK0NzSWc3eFg2V2liK2VMMHdR?= =?utf-8?B?eUl1MlBkR280TG9TZ1FNNTg4OXdjcFdYbFdicmp6YnNLVmJEdGtpOEpIR0Zk?= =?utf-8?B?aGMvcThJNVFLRnNmdnJKaTZWams2NXdFZVBSSzhWNmlLVjF6TGhqU2Q3Nytu?= =?utf-8?B?UmdQTldOUlE4MS93UzNsem1tTmprU1BJbmxPeS8xams3NGltbGdyeDRDSUwz?= =?utf-8?B?aHlOOVBobkNwWGhPZndOUTFGT1gvb2orM2V1Rjd1ZVlvL0FpNG8xc0FNNUtu?= =?utf-8?B?Y3dGOGZBbFg3WEdLbTA3ZkhuNWhjbmVpVkdKbzlUZUpGZlUvNzNOdXFyUWM3?= =?utf-8?B?VGlJZXhwZzZaZEdxSGtyc1Y2Y3RFMWMrbVlQb1lwRFZ2WFdBWDNJdUpubmlP?= =?utf-8?B?MDRoYWIyaCtxNVZaNFFQcUVSZ2diVldpUkx4NFJpYkxKYlU0SHhvc1BwSlZT?= =?utf-8?B?ZlRheEUzT3dNMkNzYXVOTktvaFU3cVNXMk9rSU1wZ09FQzFUMi93c0xRU3Fo?= =?utf-8?B?TG5zYVRKclNYWVJaL1llYVBvRER3eXlydzZudz09?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3434; 6:WHf1JPNSVY+uITlE14FBzmhQjkQVTV93eega5sGttdXWKZMTrjTQ0ymPZXyw1p26ZMb73rRnHqFFVkvUdED68+PinnFCqLErsB7as3wRYp13RyifPx+aVr0Tm7uel2bIpi295WPByPZRCR38lC0WvYYUQS/E2BBvMYfSYNwJXjYy+QA4VPxZ8Oer3Zw94N9Ik4APJNvB7KVBorV7x8VLBCFsL5DDF6arGISSeGdonUIK0k2UZ5vWjr9Qv14G7Jx7cYUZ8BMolRS/z3eFeQSqaZmPJ3hwgIYrO6xPqV33kWmKP1EQl5lpyoShVBlosTqBntUjSrnHqJfIbawdPAlFcM7uwUICivAdmgaqwx2YkIk=; 5:XtjyiW+LaDdG3tq9U21hbSGZwAtKsegTZog7/XxGR4Rab6k5WLOCR8m+lODr7yL/T4VGKwjKxYhN9Fy/FFQnhrCEpqcXYAFQRq9l7R4HzuoazE15DdEbtkcMeDE/sC/rVH/bLcftmW6M2XUTaQdlA55+gdfDmIj25p3AC9jxDN0=; 24:vSwKd61jxq0yt0Q3Uu6rljau2J//XrtRKFNsfMR1GAY3NInQayTh87GaPvFTDmmEsB7MNQkTDfP7eNL+z4hfw1DyoKstcc5E9H3g2hAk+Ws=; 7:K66NbD1pw9QR6CrqdM0dpUFrzUHHkTPAOJgPHBTpmk4UOfXlIyqaYlruzyHPRb3CEazMwBKqchzYmKqrGzuGTWgEQfYLdNwlh+rJsSKM0cFk8D6tzaLzozUnDKQRx1wBzmMKJmQzrY1PsfFZsyuhNIxgdiT6av+JdG70103LWlzdoGxHQXaonX6RUSpD2/XdWaeJ4iaTFHxhMC5uYEgf4O/KMHya1dI9GYn8hIkWqvmKJCfLsQiZAZmpGDpP+0c6
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 17:41:47.8425 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fc6b4400-7f89-492d-89f5-08d52c5025f4
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3434
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUyM2K7tG5cDU+UwbYOE4sLq+ayWXR3P2O3 mH+xkdWB2WPJkp9MHpsu32H02PhrMUsAcxSXTUpqTmZZapG+XQJXxp7JO1gLlkhXHPrQydLA +Eaki5GTQ0LAROLKx7ssXYxcHEIChxklZk//BeWcYJRoWneEDcRhEehllvjZ9pEFpIVRIE5i 55qFrBBVrUwS02ZMZQZJCAt4Suzr/MMKYosImEl8avsFFmcWEJVYf/ESE0TDRUaJ/0vXgCXY BIwkpvafB5vKK2Av8WrpfCYQm0VAVaKz4xKYLSoQIzHxwUVGiBpBiZMznwDVc3BwCjhK3Njt CTFfQ6J1zlx2CFtc4tYTiDHMAvIS29/OYYb4U0niQfsDdgh7CqPEyY+2ILYQUO/DC39ZIeKy EkfPzmGBsH0lXm9vAvteQmAmo8TMBWtZIZwGdolpLS/ZIKq0JP5cugmV2MEu0Xz4JNSKbInr 698yQtiREhPvnmWHKLrCKrH48Fyom2QkTt7YyziBUWcWku9mIXlpFpKXZiF5aQEjyypG0eLU 4uLcdCNjvdSizOTi4vw8vbzUkk2MwIRycMtv3R2Mq187HmIU4GBU4uHtSeaJEmJNLCuuzD3E KMHBrCTC61IGFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rIcIdJSSQnliSmp2aWpBaBJNl4uCU amA07viWH5HjcuTcxU3vBeedNH5+ilF10i87Hv/kxcVfr4tzFv6+ckt9z9+n2y4/PGOyvtJm aed/76cLDfoeSO9JSJrb5qpyV3HPt776fWvnKHpbT1l5Oy7geLxtyn6vI4EqdV8ZI03uXph/ bVOE4fKnXKvkvPqDkwJ6dy9cOivcJygiddYaW2ZHJZbijERDLeai4kQAgaH8ACQDAAA=
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 17:41:55 -0000


  
    
  
  
    


    

    

    
On 2017-11-15 21:20, Martin Bjorklund
      wrote:

    

    

      
Ladislav Lhotka <lhotka@nic.cz> wrote:


      

        
On Wed, 2017-11-15 at 12:17 +0100, Martin Bjorklund wrote:


        

          
Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:


          

            
The server MAY implement obsoleted nodes or MAY NOT. This may or may
not  is not good enough as a contract for the management client.  My
problem is that the current solution is just not good enough. IMHO we
need to change it.


          

          
Note that if a server implements version 1 of a module, and then the
module doesn't change, but the server in the next sw version drops
support for the module, the client will also be unhappy.  We (the
IETF) can't have rules for these kinds of things.


        

        
If the server drops support for a module, then that module has to disappear from
YANG library, so it is a priori known that it happened. With deprecated/obsolete
nodes, a server may drop their support without any notice, within the same
module&revision. 


      

      
I agree that *that* is a problem, but that's not what Balazs asked about.


/martin

    

    BALAZS: Actually this exactly one of my problems. See other letter
    for my 3 problems. This is one cause of 2)

    

      



      

        

          

            
new stuff with a new name, although that might not be the common
practice.  Which is a good thing, as I believe it is sometimes better
to correct existing definitions then to replace them.


          

          
But you still want to require servers to implement even obsolete
nodes?


        

        
I think with semver support there will be no need for the "status" statement -
the nodes just get removed and version number bumped.

Lada

      

    

    BALAZS: You still need at leaast deprecated: my proposal

    
o  "deprecated" schema nodes MUST still work as defined by the YANG module. 
       The deprecated status serves only as a a warning that the schema node 
       will be removed or obsoleted in the future." 

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


  



From nobody Wed Nov 15 10:29: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 BB051126C22 for ; Wed, 15 Nov 2017 10:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 SNrhGmAi07ig for ; Wed, 15 Nov 2017 10:29:37 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF3B1200B9 for ; Wed, 15 Nov 2017 10:29:36 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id 73so13023401lfu.10 for ; Wed, 15 Nov 2017 10:29:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1xvxlbh0LejcuvE3uv+GV6G5ZCI4c7ItKhIw0zta1Oc=; b=hSvFC9RoVzwM3MZrtLohCTT9DT7ThT6sbKekU03DtClksT9jK98U27foh5JFBmxMPP S2XLu7ls3hSFY4kscUekwJzt1HqlR5DNofBldb1djtPNQJeTGlxiOsh/L1a7MNa6ooly v4ZWs527gPqPIkUDIkGPx6gu2x5QS57Lln7aWOGMUgMP54gSaVDLLirszDXxA2uRezUB 38YpKLeb+oqyzhWsxU0lJqON5G4Q4LSfnzbvU0a6DdEDniPkWLm3m/4ufoH/iV/G1v7D Ks35+Ml2t688trLKbYTqjp1n7o/iK6AjYo7Oh8iBDTtFzTvL6rSH9jZTkz1Pyd5r5via Z3bQ==
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=1xvxlbh0LejcuvE3uv+GV6G5ZCI4c7ItKhIw0zta1Oc=; b=aTAbJVu0rqemwwTR1TodNH3hLHWki+U5F5GDvJavtxsC+sQGXxd4inkOyQlQ+bxgSM rda2VZz3euHhrvd9S4Fxd5y7SsbCdig9ni1EEVMt/S2/uqASnXeF/lING2QqSrDm0dPF fICFwyUCB4D28x265IHJWSRRpeCkOmwNmsfaCFzueMMobMKDZKgqq8wSe/WhKSwPhRId 9Y51UFg6FAMIvSLg7hgB716NpxFkRp7erH1J+wpYCqrJEYXLonhJZrKgIo6+7dnPlNxb wtOwAgR6V0tk03+f5kFl2d0rBGzjbCVpK8dXBLzx++wMgsftJf1Z67bkOI0Kxg3669sR XydQ==
X-Gm-Message-State: AJaThX6ACLHHJ1zkUluaiDDehjHqZ/YCtqI3yAl39j+rKN5SkqQfih2D NACYpxv/GWqRA+fZsbc1Newz0EKQAqt5KQsRyIOKvA==
X-Google-Smtp-Source: AGs4zMYzQUt7yD5CxSeSEmhOqUEzHEzWkm5QrQ1Vxqg/EPxWfWL1e91x0BWKAqX0rNJrJhBnlc14ey83fstytjWe1XQ=
X-Received: by 10.25.162.140 with SMTP id l134mr5557760lfe.126.1510770574299;  Wed, 15 Nov 2017 10:29:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 15 Nov 2017 10:29:33 -0800 (PST)
In-Reply-To: <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com>
References:  <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com>
From: Andy Bierman 
Date: Wed, 15 Nov 2017 10:29:33 -0800
Message-ID: 
To: Robert Wilton 
Cc: Vladimir Vassilev , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11411a4c6b371d055e09afe0"
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 18:29:40 -0000

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

Hi,

The per-datastore feature aspect of NMDA is a new and significant change to
YANG.

    |  |  +--ro feature* [name]
    |  |  |  +--ro name        yang:yang-identifier
    |  |  |  +--ro not-implemented-in*
    |  |  |              -> /yang-library/datastore/name


YANG does not define feature conformance at this granularity.
I strongly object to this change to YANG conformance.
A server can only advertise a YANG feature if it implemented on the entire
server.

This extra complexity is not present on the openconfig solution or
requirements.
Comparing any datastore to  is much more complex (any may not
be possible)
if the features are different for a given module.

I do not see how  can be true superset of the conventional
datastores
if the features are different.


Andy


On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton  wrote:

> I don't think that this is really a good idea.  You would end up returning
> server metadata in addition to the configuration.
>
> I still think that the YANG library proposal is the best solution.
>
> Thanks,
> Rob
>
>
> On 16/11/2017 01:21, Vladimir Vassilev wrote:
>
> Hello,
>
> I have a proposal based on  that provides an elegant solution to
> consider as a 3rd option.  It is based on keeping exactly the same model as
> in RFC 7895 and using  RPC to retrieve datastore specific
> yang-library instance data in a similar way one would use  to
> retrieve the datastore contents. In addition a top level config=false
> container e.g. /datastores with list of supported datastores that does not
> need to be part of the yang-library module:
>
> module: ietf-datastores
> +--ro datastores
> |  +--ro datastore* [name]
> |     +--ro name          identityref
>
> Vladimir
>
> On 11/09/2017 05:51 PM, Robert Wilton wrote:
>
> Hi,
>
> Given some of the feedback related to the complexity of the YANG library
> bis structure, we have come up with two other possible structures for the
> YANG library data:
>
> (1) A simplified structure to make YANG library meet the NMDA
> requirements, but that is closer to the existing YANG library structure,
> and arguably simpler.
> (2) An enhanced version of the structure (1) above, that is also extended
> to allow the structure to be reused for schema-mount via an augmentation.
>
> For reference, at the end of this email, I have also included the tree
> diagram of the existing YANG library, and the current YANG library bis
> draft (draft-ietf-netconf-rfc7895bis-02) version.
>
> Considering the two new YANG library structures:
>
> ------------------------
>
> *(1) A simplified structure to make YANG library meet the NMDA
> requirements, but that is closer to the existing YANG library structure.*
>
> The main changes are:
> (i) Split "implemented modules" and "import-only-modules" into two
> separate lists, making the most important list (i.e. implemented modules)
> keyed by module name only and hence easier to reference.
> (ii) Assume modules are implemented in all datastores by default (with a
> "not-implemented-in" leaflist of datastores that a module is not
> implemented in).
> (iii) Assume that features are implemented in all datastores by default
> (with a "not-implemented-in" leaflist of datastores that a feature is not
> implemented in).
> (iv) Deleted module-sets.
> (v) Datastores are now just a list of supported datastores (that could
> potentially be extended with further per datastore properties in future).
>
> Manually generated tree output for proposed YANG library:
>
> module: ietf-yang-library
>  +--ro yang-library
>     +--ro modules
>     |  +--ro module* [name]
>     |  |  +--ro name           yang:yang-identifier
>     |  |  +--ro revision?      revision-identifier
>     |  |  +--ro schema?        inet:uri
>     |  |  +--ro namespace      inet:uri
>     |  |  +--ro submodule* [name]
>     |  |  |  +--ro name        yang:yang-identifier
>     |  |  |  +--ro revision?   yang:yang-identifier
>     |  |  |  +--ro schema?     inet:uri
>     |  |  +--ro not-implemented-in*
>     |  |  |              -> /yang-library/datastore/name
>     |  |  +--ro feature* [name]
>     |  |  |  +--ro name        yang:yang-identifier
>     |  |  |  +--ro not-implemented-in*
>     |  |  |              -> /yang-library/datastore/name
>     |  |  +--ro deviation*
>     |  |                 -> ../name
>     |  |
>     |  +--ro import-only-module* [name revision]
>     |     +--ro name                yang:yang-identifier
>     |     +--ro revision            union
>     |     +--ro schema?             inet:uri
>     |     +--ro namespace           inet:uri
>     |     +--ro submodule* [name]
>     |        +--ro name        yang:yang-identifier
>     |        +--ro revision    yang:revision-identifier
>     |        +--ro schema?     inet:uri
>     +--ro datastore* [name] // Allows future per datastore properties.
>     |  +--ro name          identityref
>     +--ro checksum       string
>
> ------------------------------
>
> *(2) An enhanced version of the structure (1) above, that is extended to
> allow the structure to be reused for schema-mount via an augmentation.*
>
> This is similar to the structure above, except that the "the set of
> modules" is contained in a list of named schema (e.g. similar to the schema
> mount draft), allowing this structure to be re-used for schema mount.
>
> Schema mount would be expected to augment yang-library to add in the
> additional schema mount information.  In the tree diagram, I have shown the
> schema-mount mount-point augmentation, but not including namespaces yet.
>
> Every server would be required to provide at least one schema in the
> schema list, and the primary schema for the device would always be given
> the name "primary".
>
> module: ietf-yang-library
>  +--ro yang-library
>     +--ro schema* [name]
>     |  +--ro name           string
>     |  +--ro checksum       string
>     |  +--ro module* [name]
>     |  |  +--ro name           yang:yang-identifier
>     |  |  +--ro revision?      yang:revision-identifier
>     |  |  +--ro schema?        inet:uri
>     |  |  +--ro namespace      inet:uri
>     |  |  +--ro submodule* [name]
>     |  |  |  +--ro name        yang:yang-identifier
>     |  |  |  +--ro revision?   yang:yang-identifier
>     |  |  |  +--ro schema?     inet:uri
>     |  |  +--ro not-implemented-in*
>     |  |  |              -> /yang-library/datastore/name
>     |  |  +--ro feature* [name]
>     |  |  |  +--ro name        yang:yang-identifier
>     |  |  |  +--ro not-implemented-in*
>     |  |  |              -> /yang-library/datastore/name
>     |  |  +--ro deviation*
>     |  |  |              -> ../name
>     |  |  +- schema-mount:mount-point* [label]
>     |  |     +--ro label         yang:yang-identifier
>     |  |     +--ro config?       boolean
>     |  |     +--ro (schema-ref)
>     |  |        +--:(inline)
>     |  |        |  +--ro inline?       empty
>     |  |        +--:(use-schema)
>     |  |           +--ro use-schema* [name]
>     |  |              +--ro name
>     |  |              |       -> /yang-library/schema/name
>     |  |              +--ro parent-reference*   yang:xpath1.0
>     |  |
>     |  +--ro import-only-module* [name revision]
>     |     +--ro name                yang:yang-identifier
>     |     +--ro revision            union
>     |     +--ro schema?             inet:uri
>     |     +--ro namespace           inet:uri
>     |     +--ro submodule* [name]
>     |        +--ro name        yang:yang-identifier
>     |        +--ro revision    yang:revision-identifier
>     |        +--ro schema?     inet:uri
>     +--ro datastore* [name] // Allows future per datastore properties.
>     |  +--ro name          identityref
>     +--ro checksum       string
>
> Please can you provide comments on these structures, in particular:
>
> Is this version better (i.e. simpler) that the version currently in
> draft-ietf-netconf-rfc7895bis-02 (below)?
>
> Should we try and make the structure extensible for schema-mount via
> augmentation (i.e. version (2)), or is it better that schema-mount has its
> own separate subtree?
>
> For reference only I have included the existing YANG library and YANG
> library bis draft tree diagrams.
>
> Thanks,
> Rob
>
>
> -----------------------------
>
> *** FOR REFERENCE ONLY ***
>
> (3)  The current YANG library structure in YANG library bis
> (draft-ietf-netconf-rfc7895bis-02)
>
>    module: ietf-yang-library
>        +--ro yang-library
>           +--ro modules
>           |  +--ro module* [id]
>           |     +--ro id                  string
>           |     +--ro name                yang:yang-identifier
>           |     +--ro revision?           revision-identifier
>           |     +--ro schema?             inet:uri
>           |     +--ro namespace           inet:uri
>           |     +--ro feature*            yang:yang-identifier
>           |     +--ro deviation* [module]
>           |     |  +--ro module    -> ../../id
>           |     +--ro conformance-type    enumeration
>           |     +--ro submodule* [name]
>           |        +--ro name        yang:yang-identifier
>           |        +--ro revision?   revision-identifier
>           |        +--ro schema?     inet:uri
>           +--ro module-sets
>           |  +--ro module-set* [id]
>           |     +--ro id        string
>           |     +--ro module*   -> ../../../modules/module/id
>           +--ro datastores
>           |  +--ro datastore* [name]
>           |     +--ro name          identityref
>           |     +--ro module-set
>           |             -> ../../../module-sets/module-set/id
>           +--ro checksum       string
>
> -----------------------------
>
> *** FOR REFERENCE ONLY ***
>
> (4)  The current YANG library structure (RFC 7895)
>
>       +--ro modules-state
>          +--ro module-set-id    string
>          +--ro module* [name revision]
>             +--ro name                yang:yang-identifier
>             +--ro revision            union
>             +--ro schema?             inet:uri
>             +--ro namespace           inet:uri
>             +--ro feature*            yang:yang-identifier
>             +--ro deviation* [name revision]
>             |  +--ro name        yang:yang-identifier
>             |  +--ro revision    union
>             +--ro conformance-type    enumeration
>             +--ro submodule* [name revision]
>                +--ro name        yang:yang-identifier
>                +--ro revision    union
>                +--ro schema?     inet:uri
>
>
>
>
> _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Hi,

The per-datastore feature aspect of=
 NMDA is a new and significant change to YANG.

=C2=A0 =C2=A0 |=C2=
=A0 |=C2=A0 +--ro feature* [name]
=C2=A0=C2=A0=C2=A0 |=
=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 yang:yang-identifier
=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=
=A0 |=C2=A0 +--ro not-implemented-in*
=C2=A0=C2=A0=C2=
=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 -> /yang-library/datastore/name

YANG does not define feature conformance at=
 this granularity.
I strongly object to this change to YANG confo=
rmance.
A server can only advertise a YANG feature if it implemen=
ted on the entire server.

This extra complexity is=
 not present on the openconfig solution or requirements.
Comparin=
g any datastore to <operational> is much more complex (any may not be=
 possible)
if the features are different for a given module.

I do not see how <operational> can be true super=
set of the conventional datastores
if the features are different.=



Andy


On Wed, Nov 15, 2017=
 at 9:29 AM, Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    I don't think that this is really a good idea.=C2=A0 You would end =
up
    returning server metadata in addition to the configuration.

    

    I still think that the YANG library proposal is the best solution.

    

    Thanks,

    Rob

    

    

    
On 16/11/2017 01:2=
1, Vladimir Vassilev
      wrote:

    

    

     =20
      Hello,

      

      I have a proposal based on <get-data> that provides an
      elegant solution to consider as a 3rd option.=C2=A0 It is based on
      keeping exactly the same model as in RFC 7895 and using
      <get-data> RPC to retrieve datastore specific yang-library
      instance data in a similar way one would use <get-data> to
      retrieve the datastore contents. In addition a top level
      config=3Dfalse container e.g. /datastores with list of supported
      datastores that does not need to be part of the yang-library
      module:

      

      module: ietf-datastores

      +--ro datastores

      |=C2=A0 +--ro datastore* [name]

      |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 identityref

      

      Vladimir

      

      On 11/09/2017 05:51 PM, Robert Wilton wrote:

      

        
Hi,

        
Given some of the feedback related to the complexity of the
          YANG library bis structure, we have come up with two other
          possible structures for the YANG library data:

        
(1) A simplified structure to make YANG library meet the NMDA
          requirements, but that is closer to the existing YANG library
          structure, and arguably simpler.

          (2) An enhanced version of the structure (1) above, that is
          also extended to allow the structure to be reused for
          schema-mount via an augmentation.

        
For reference, at the end of this email, I have also included
          the tree diagram of the existing YANG library, and the current
          YANG library bis draft (draft-ietf-netconf-rfc7895bis-02)
          version.

        

        
Considering the two new YANG library structures:

        

        
------------------------

        

        
(1) A simplified structure to make YANG library meet the
            NMDA requirements, but that is closer to the existing YANG
            library structure.

        
The main changes are:

          (i) Split "implemented modules" and "import-only-m=
odules" into
          two separate lists, making the most important list (i.e.
          implemented modules) keyed by module name only and hence
          easier to reference.

          (ii) Assume modules are implemented in all datastores by
          default (with a "not-implemented-in" leaflist of datast=
ores
          that a module is not implemented in).

          (iii) Assume that features are implemented in all datastores
          by default (with a "not-implemented-in" leaflist of dat=
astores
          that a feature is not implemented in).

          (iv) Deleted module-sets.

          (v) Datastores are now just a list of supported datastores
          (that could potentially be extended with further per datastore
          properties in future).

        

        
Manually generated tree output for proposed YANG library:

        
module: ietf-yang-library

          =C2=A0+--ro yang-library

          =C2=A0=C2=A0=C2=A0 +--ro modules

          =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]=


          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 revision-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [nam=
e]

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revisio=
n?=C2=A0=C2=A0 yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented=
-in*

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
            /yang-library/datastore/name

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]=


          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-imp=
lemented-in*

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
            /yang-library/datastore/name

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*=


          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->=
 ../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 +--ro import-only-module* [na=
me revision]

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
            yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revis=
ion=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union=


          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schem=
a?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro names=
pace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submo=
dule* [name]

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-ident=
ifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0
            yang:revision-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows fut=
ure per
            datastore properties.

          =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

          =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 string

        

        
------------------------------

        
(2) An enhanced version of the structure (1) above, that
            is extended to allow the structure to be reused for
            schema-mount via an augmentation.

        
This is similar to the structure above, except that the "th=
e
          set of modules" is contained in a list of named schema (e.g.
          similar to the schema mount draft), allowing this structure to
          be re-used for schema mount.

        
Schema mount would be expected to augment yang-library to add
          in the additional schema mount information.=C2=A0 In the tree
          diagram, I have shown the schema-mount mount-point
          augmentation, but not including namespaces yet.

        
Every server would be required to provide at least one schema
          in the schema list, and the primary schema for the device
          would always be given the name "primary".

        
module: ietf-yang-library

          =C2=A0+--ro yang-library

          =C2=A0=C2=A0=C2=A0 +--ro schema* [name]

          =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

          =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 string

          =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name]=


          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revision?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
            yang:revision-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro namespace=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submodule* [nam=
e]

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro revisio=
n?=C2=A0=C2=A0 yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro schema?=
=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-implemented=
-in*

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
            /yang-library/datastore/name

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]=


          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not-imp=
lemented-in*

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
            /yang-library/datastore/name

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro deviation*=


          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> ../name=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-mount:mount=
-point* [label]

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--=
ro label=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifi=
er

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--=
ro config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--=
ro (schema-ref)

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 +--:(inline)

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 e=
mpty

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 +--:(use-schema)

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro use-schema* [name]

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 ->
            /yang-library/schema/name

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro parent-reference*=
=C2=A0=C2=A0
            yang:xpath1.0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 

          =C2=A0=C2=A0=C2=A0 |=C2=A0 |

          =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-module* [na=
me revision]

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
            yang:yang-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revis=
ion=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 union=


          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schem=
a?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro names=
pace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro submo=
dule* [name]

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-ident=
ifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0
            yang:revision-identifier

          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

          =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // Allows fut=
ure per
            datastore properties.

          =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

          =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 string

        
Please can you provide comments on these structures, in
          particular:

        
Is this version better (i.e. simpler) that the version
          currently in draft-ietf-netconf-rfc7895bis-02 (below)?

        

        
Should we try and make the structure extensible for
          schema-mount via augmentation (i.e. version (2)), or is it
          better that schema-mount has its own separate subtree?

        
For reference only I have included the existing YANG library
          and YANG library bis draft tree diagrams.

        

        
Thanks,

          Rob

        

        


        

        
-----------------------------

        
*** FOR REFERENCE ONLY ***

        

        
(3)=C2=A0 The current YANG library structure in YANG library bis
          (draft-ietf-netconf-rfc7895bis-02)

        

        
   module: ietf-yang-=
library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

        
-----------------------------

        
*** FOR REFERENCE ONLY ***

        

        
(4)=C2=A0 The current YANG library structure (RFC 7895)

        
      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



        
 

        

        

        

        
_______________________________________________
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




--001a11411a4c6b371d055e09afe0--


From nobody Wed Nov 15 11:07: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 05568126CBF for ; Wed, 15 Nov 2017 11:07:31 -0800 (PST)
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, 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 jqeycCkdk-1t for ; Wed, 15 Nov 2017 11:07:29 -0800 (PST)
Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com [209.85.192.170]) (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 7784E126D74 for ; Wed, 15 Nov 2017 11:07:29 -0800 (PST)
Received: by mail-pf0-f170.google.com with SMTP id l24so5249819pfj.6 for ; Wed, 15 Nov 2017 11:07:29 -0800 (PST)
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=/bfLp0LsGDtXerBUS5xF/LI7j30ieuMOEtPBqu6ClFk=; b=f7zeddA9k5PbY7OAvsQPWynFR+zFUki8Cuxwy9qGkUcN9EuLYITMsTxwkc9Sg6OKwC xUC1VF9k7Wam4wuTFoERAgSEOfV7ckOKFsbwpd/Zs9xoE/N0oUAs9AoQU6HIQ+YphqcN PSc+fb/bdO9lWu38U+Zk2acBrX0P/WsgqWZXP9PtUUB/7ywj0AtG7d5QzKET3YEmoh+C SrLFGnfq2vKbinTxbMIPvdbOyZD+dzx4YrsBol0LIXoZJpUqwVaxFeOl5pVvBm7IQKmE caa6IdlZBdTWcdINaI7ckCemHYjhO5vScRSPzKP0Meg3V8XuGVW6yMe5hNBjOtnXa6bc jWSQ==
X-Gm-Message-State: AJaThX4KvzjG/QnDpgHW+f/jgJZnsT7qiXOJgpvl3L9LCQCb4vDHeZ9S ByIQP9CHxDh9Gi16qQbKA3MJukK2HXw=
X-Google-Smtp-Source: AGs4zMaN7WCvLrWEoWrvja2QOuirqtHVTrJoLRC1k2lfRdmFhnc0xHC55e70ZrvGMUems/IQB1lWBQ==
X-Received: by 10.98.248.5 with SMTP id d5mr18791121pfh.118.1510772848591; Wed, 15 Nov 2017 11:07:28 -0800 (PST)
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 t25sm44974136pfh.67.2017.11.15.11.07.27 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 11:07:28 -0800 (PST)
To: netmod@ietf.org
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <614c9b33-774a-cbe0-0328-cfc7ad9ac11b@ericsson.com>
From: Randy Presuhn 
Message-ID: <02d86058-4ebb-1bf8-0ecc-3ff464664479@alumni.stanford.edu>
Date: Wed, 15 Nov 2017 11:07:27 -0800
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: <614c9b33-774a-cbe0-0328-cfc7ad9ac11b@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 19:07:31 -0000

Hi -

On 11/15/2017 2:02 AM, Balazs Lengyel wrote:
> While a server may correctly support multiple versions, the human 
> operator on the CLI has a 99% chance of mixing up which version he is 
> using. Humans will not check every type and leaf  to check that they 
> remember the little differences between model versions. It is a recipe 
> for human mistakes. According to some statistics 50% of downtime is 
> caused by human errors, so we should not provide the operator with a gun 
> to shoot himself. Ericsson has a rule never to have multiple versions of 
> the same module on a network node.

Does this mean that they require all line cards in a chassis to have
exactly the same firmware revision level?  If so, when a card with a
newer firmware revision level is swapped in, does that require all other
cards of the same type in that chassis to also be replaced concurrently?
Sounds like even a fairly routine/minor update/repair would effectively
result in a system outage.

Randy


From nobody Wed Nov 15 15:01: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 2BBA4128BB7 for ; Wed, 15 Nov 2017 15:01:21 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 F_ECerdRDdLz for ; Wed, 15 Nov 2017 15:01:19 -0800 (PST)
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 89862128B93 for ; Wed, 15 Nov 2017 15:01:19 -0800 (PST)
Received: from cmgw3 (cmgw4 [10.0.90.84]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id D424B175AC7 for ; Wed, 15 Nov 2017 16:01:15 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id aP1C1w01C2SSUrH01P1FYF; Wed, 15 Nov 2017 16:01:15 -0700
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=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=ARNkrULPAAAA:20 a=bES2lQTYoQqcbcTwNHMA:9 a=QEXdDO2ut3YA:10 a=8Q7M2idXEiQA:10 a=gUXmQ8eWAGYA: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:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc: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=Fyos6FreKkOmIHHoQkr7tkafd89dGhWSHvnzMDJBPXQ=; b=tPdzIO02LtqOOnhWf/79vOYTdI u0yCUafveKI689QbeoaPOXv3FJOHycjQySCyphFm/3KHqLMInR46ln8GFdk3cKLhyhmJ9E80geoVF tX7DJvGGcEllRrEEjJ/0k2M0x;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:53670 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eF6gC-001kij-8n for netmod@ietf.org; Wed, 15 Nov 2017 16:01:12 -0700
To: "netmod@ietf.org" 
From: Lou Berger 
Message-ID: <3cf8595a-c19f-7895-c0e5-1a3e14ce46fa@labn.net>
Date: Thu, 16 Nov 2017 07:01:07 +0800
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-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: 1eF6gC-001kij-8n
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]:53670
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Raw notes from session (incomplete, need help!)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 23:01:21 -0000

Hi,
	As usual, raw notes from our session are available in etherpad: 
http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-netmod

Please review and make additions/corrections based on what took place in 
the session (comments should be sent to the list.)  To aid in the 
review, please see:

Recording:
     https://www.ietf.org/audio/ietf100/ietf100-sophia-20171115-1330.mp3
     https://www.ietf.org/audio/ietf100/ietf100-sophia-20171115-1520.mp3

Youtube is not yet posted, but should be available sometime later today 
at:https://www.youtube.com/user/ietf/playlists

We really need help with this as there are currently some major gaps in 
the notes!  Also you need not have been present to help with the notes.

Thank you!
Lou (Kent and Michael)


From nobody Wed Nov 15 15:39: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 C2E7D127876 for ; Wed, 15 Nov 2017 15:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I19ZFsO_zS2W for ; Wed, 15 Nov 2017 15:39:27 -0800 (PST)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 A9CB4126CD8 for ; Wed, 15 Nov 2017 15:39:27 -0800 (PST)
Received: by mail-pg0-x234.google.com with SMTP id 4so10266165pge.1 for ; Wed, 15 Nov 2017 15:39:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zOK3KEmasNDdtEezknZidVXGeoWtkrzW9PelV3Mdaqo=; b=Q8plQIRuOvOHVut9lviB0vSx+8LXJqQma7MRZHxte2CDjZ2FRUPBpdWmk7qx4fNKrz CNgqRa2LsonyhB0nh9KBg8kDdfZNFDBD8prj5V/QtwbWgIWut9Bazeh0YtapAg5uiUej MfX/DqpgKl17IQwAw24wde0lmasp6ZkBGL/Nuhux7AwfoPhgH8gyya+HDAQuDdIK59iP FTvXdc4y5pvQNNz13xGDxGHu2E1yZ+QsVdB8+zixW0PSoX/KXtv5CIRxy2kCNhDq78fN 5qGKZuxQ4JqGvTJbiEkqtKSFzgu/DmKrNHejHtqsFj0ZIqczoM/Jr6RMD5TUBg1T4jH3 SfIQ==
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=zOK3KEmasNDdtEezknZidVXGeoWtkrzW9PelV3Mdaqo=; b=cHB+MdqzTt9820mMfQhMUVKdKUvxIUNMkZs4HFEvFAypiZMqNhkP7gRHeZymfXWBbV APtElYpiKfAEzlvJuVeKkNq8J/IjfzE+T0GDFnRkO5oSF4/3jbUHW1DLg1PnOjiK+OCE IFnsqsxX/6n/o2k4CBk8IvcnAPgn9Q2EOvQphlNKlIGx3QFwEAGxegp7F3zbUij9mcJZ jPI8zzoXnLAhjwtO0fBvGn7WXhHec36dhkCqbepfYfjSFEScf4TBtDIWot58kWOkG10n oKAggGuPZ/ccq21jpwSkZPvn0AzACHnSVG2M+DiBrq6whFMErZ2+9RwJ/WooNEZEL80n SFaw==
X-Gm-Message-State: AJaThX4wpr5n2M7l8VM2LD0lfvDijB7KjbDhAn/A3rnOxFPnL/W6Wac2 TNuHwFoSbYzSiN8dqln1xZgUz29aF1k=
X-Google-Smtp-Source: AGs4zMYZSccdD/P1nTqEgCJnGwfhP1eUmFrJNauTSnG9nZ2UnTJGJBeNLQyxhWGwLAgQOk4We30prg==
X-Received: by 10.101.82.129 with SMTP id y1mr17441726pgp.137.1510789167171; Wed, 15 Nov 2017 15:39:27 -0800 (PST)
Received: from dhcp-927c.meeting.ietf.org (dhcp-927c.meeting.ietf.org. [31.133.146.124]) by smtp.gmail.com with ESMTPSA id y27sm43764610pfi.107.2017.11.15.15.39.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Nov 2017 15:39:25 -0800 (PST)
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: Thu, 16 Nov 2017 07:39:23 +0800
Cc: Martin Bjorklund , netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com>
References: <20171115.101454.1576716701146734257.mbj@tail-f.com> 
To: Robert Wilton 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] tree diagram guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Nov 2017 23:39:30 -0000

Other SDOs can and follow the work in IETF through the RFCs we publish. =
They do not follow wiki=E2=80=99s, unless the document itself says, =
=E2=80=9Chere are the guidelines, but if you are looking for the latest, =
go to this wiki=E2=80=9D. I therefore would support the proposal =
outlined below. It gives the SDO a stable point of reference with a =
document, which gets updated occasionally, but also allows them to peak =
at what is coming down the pipeline.

Thanks.

> On Nov 15, 2017, at 6:53 PM, Robert Wilton  wrote:
>=20
> I liked the suggestion from Chris Hopps:
>=20
> I think that it was along the lines of ...
>=20
> The RFC contains a reference at the top that states that updates to =
the guidelines is available on a wiki at ....
>=20
> Every few years the guidelines on the wiki can be folded into a latest =
version of the guidelines draft.
>=20
> 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, =
or MEF be using the latest draft guidelines, or should then use the =
published RFC until 6087bis is actually republshed?
>=20
> Thanks,
> Rob
>=20
>=20
> On 15/11/2017 10:14, Martin Bjorklund wrote:
>> Hi,
>>=20
>> There was a proposal in the meeting today to have the guidelines for
>> tree diagrams in a wiki, instead of having them in 6087bis or in the
>> tree diagram document.
>>=20
>> Was the proposal really to have a wiki for just the tree guidelines,
>> or was the proposal to withdraw 6087bis from the process and instead
>> publish all guidelines as a wiki?
>>=20
>> If it is the former, is it really worth it?
>>=20
>> Advantages with a wiki:
>>=20
>>   +  It can be updated more easily
>>=20
>> Some drawbacks:
>>=20
>>   -  It can be updated more easily
>>      (meaning they are less stable)
>>=20
>>   -  Wikis tend to not be alive after some time, and are not that
>>      easy to find.  Just try to find the various YANG-related wikis
>>      we've tried to maintain over the years.
>>=20
>>   -  Links in RFCs also have problems.  Sites are re-orginized etc.
>>      As an example, the link to the security guidelines template in
>>      RFC 6087 doesn't work anymore.
>>=20
>>   -  People that are looking for a stable reference will have =
problems
>>      (I think Rob mentioned that IEEE still refer to RFC 6087 (which
>>      is understandable; that's the published version).
>>=20
>>   -  Who maintains the Wiki, and what are the rules for updating it?
>>=20
>>=20
>> I suggest we have the tree-related guidelines (actually just a few
>> sentences) in the tree draft, and since 6087bis already refers to =
this
>> document it is not a big problem that guidelines are spread out over
>> several documents that are difficult to find.
>>=20
>>=20
>>=20
>> /martin
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Wed Nov 15 16:53: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 B66CD120227 for ; Wed, 15 Nov 2017 16:53:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_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 2ArlnXVUyRqz for ; Wed, 15 Nov 2017 16:53:22 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619071293DF for ; Wed, 15 Nov 2017 16:53:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39366; q=dns/txt; s=iport; t=1510793602; x=1512003202; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=4OIEI8Yhcx7CXxUzHZWVEwDIzmVe0zFnutL2RZeyAY4=; b=Z/k/sY5AxVTGl2CAbjTopBZLocfY+v72PRSVIxGd4EuMXP8uaY37LPAm 0ku7uKdnClUVSQkQpPkBM9Le1KuMSF5FcE6kzD4IKtFr2Kt2l5YXOKSSn CvxloIGOQXuYpP/2thr6Znl8gkDhjweFBfhGivcEOWwoOu8QsLtiUe92g k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAAD44Axa/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuJ4N/ih+PIIF9ll0QgX4DChgBCoRJTwKFDj8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHgEBAQMBAQEYCQRHCwULCQIYIAEGAwICJx8RBg0GAgEBF4oBCBCLf?= =?us-ascii?q?J1ogW06JoppAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDNIIHgVWBaSmBdIENhGU?= =?us-ascii?q?BEgEJTIJfgmMFijQHhzaBE4YaiRmVBoIVgXuED4Ngh0WOOod0gTkfOEJBcTQhC?= =?us-ascii?q?B0VSYJkgiOCSTQ2iGWCNQEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,401,1505779200"; d="scan'208,217"; a="32045323"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 00:53:21 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAG0rJ4R015836; Thu, 16 Nov 2017 00:53:19 GMT
To: Andy Bierman 
Cc: Vladimir Vassilev , "netmod@ietf.org" 
References:  <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Thu, 16 Nov 2017 08:53:18 +0800
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="------------96541FCDCA4FD5F9E0A030F6"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Nov 2017 00:53:26 -0000

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

Hi Andy,


On 16/11/2017 02:29, Andy Bierman wrote:
> Hi,
>
> The per-datastore feature aspect of NMDA is a new and significant 
> change to YANG.
>
>>     |  |  +--ro feature* [name]
>>     |  |  |  +--ro name yang:yang-identifier
>>     |  |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>
>
> YANG does not define feature conformance at this granularity.
> I strongly object to this change to YANG conformance.
> A server can only advertise a YANG feature if it implemented on the 
> entire server.
>
> This extra complexity is not present on the openconfig solution or 
> requirements.
In terms of comparison, it definitely is:
- you can have different features for the config and state trees (e.g. 
"router-id" feature in RFC 8022).
- sometimes the conventions are not followed completely consistently, 
e.g. different types, or semantics between config and state.
- sometimes the structures differ between config and state.

So, the problem comparing between config and state is not easier in 
either the IETF split tree or OpenConfig solutions.

> Comparing any datastore to  is much more complex (any may 
> not be possible)
> if the features are different for a given module.
You can always compare (except deviations in operational).  If a feature 
is enabled on any configuration datastore then it must also be enabled 
on operational.

E.g.  take "router-id" feature from RFC8022bis (that was also defined in 
RFC8022).

This feature can be enabled:
(i) everywhere (i.e.  +  + ), or
(ii)  + , or
(iii)  + , or
(iv)  only, or
(v) or in none of them.

Hence,  always contains a superset of the nodes.

>
> I do not see how  can be true superset of the 
> conventional datastores
> if the features are different.

Because of the statement above.

Thanks,
Rob

>
>
> Andy
>
>
> On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton  > wrote:
>
>     I don't think that this is really a good idea.  You would end up
>     returning server metadata in addition to the configuration.
>
>     I still think that the YANG library proposal is the best solution.
>
>     Thanks,
>     Rob
>
>
>     On 16/11/2017 01:21, Vladimir Vassilev wrote:
>>     Hello,
>>
>>     I have a proposal based on  that provides an elegant
>>     solution to consider as a 3rd option.  It is based on keeping
>>     exactly the same model as in RFC 7895 and using  RPC to
>>     retrieve datastore specific yang-library instance data in a
>>     similar way one would use  to retrieve the datastore
>>     contents. In addition a top level config=false container e.g.
>>     /datastores with list of supported datastores that does not need
>>     to be part of the yang-library module:
>>
>>     module: ietf-datastores
>>     +--ro datastores
>>     |  +--ro datastore* [name]
>>     |     +--ro name          identityref
>>
>>     Vladimir
>>
>>     On 11/09/2017 05:51 PM, Robert Wilton wrote:
>>>
>>>     Hi,
>>>
>>>     Given some of the feedback related to the complexity of the YANG
>>>     library bis structure, we have come up with two other possible
>>>     structures for the YANG library data:
>>>
>>>     (1) A simplified structure to make YANG library meet the NMDA
>>>     requirements, but that is closer to the existing YANG library
>>>     structure, and arguably simpler.
>>>     (2) An enhanced version of the structure (1) above, that is also
>>>     extended to allow the structure to be reused for schema-mount
>>>     via an augmentation.
>>>
>>>     For reference, at the end of this email, I have also included
>>>     the tree diagram of the existing YANG library, and the current
>>>     YANG library bis draft (draft-ietf-netconf-rfc7895bis-02) version.
>>>
>>>     Considering the two new YANG library structures:
>>>
>>>     ------------------------
>>>
>>>     *(1) A simplified structure to make YANG library meet the NMDA
>>>     requirements, but that is closer to the existing YANG library
>>>     structure.*
>>>
>>>     The main changes are:
>>>     (i) Split "implemented modules" and "import-only-modules" into
>>>     two separate lists, making the most important list (i.e.
>>>     implemented modules) keyed by module name only and hence easier
>>>     to reference.
>>>     (ii) Assume modules are implemented in all datastores by default
>>>     (with a "not-implemented-in" leaflist of datastores that a
>>>     module is not implemented in).
>>>     (iii) Assume that features are implemented in all datastores by
>>>     default (with a "not-implemented-in" leaflist of datastores that
>>>     a feature is not implemented in).
>>>     (iv) Deleted module-sets.
>>>     (v) Datastores are now just a list of supported datastores (that
>>>     could potentially be extended with further per datastore
>>>     properties in future).
>>>
>>>     Manually generated tree output for proposed YANG library:
>>>
>>>     module: ietf-yang-library
>>>      +--ro yang-library
>>>         +--ro modules
>>>         |  +--ro module* [name]
>>>         |  |  +--ro name yang:yang-identifier
>>>         |  |  +--ro revision? revision-identifier
>>>         |  |  +--ro schema?        inet:uri
>>>         |  |  +--ro namespace      inet:uri
>>>         |  |  +--ro submodule* [name]
>>>         |  |  |  +--ro name yang:yang-identifier
>>>         |  |  |  +--ro revision? yang:yang-identifier
>>>         |  |  |  +--ro schema?     inet:uri
>>>         |  |  +--ro not-implemented-in*
>>>         |  |  |              -> /yang-library/datastore/name
>>>         |  |  +--ro feature* [name]
>>>         |  |  |  +--ro name yang:yang-identifier
>>>         |  |  |  +--ro not-implemented-in*
>>>         |  |  |              -> /yang-library/datastore/name
>>>         |  |  +--ro deviation*
>>>         |  |                 -> ../name
>>>         |  |
>>>         |  +--ro import-only-module* [name revision]
>>>         |     +--ro name yang:yang-identifier
>>>         |     +--ro revision            union
>>>         |     +--ro schema? inet:uri
>>>         |     +--ro namespace inet:uri
>>>         |     +--ro submodule* [name]
>>>         |        +--ro name yang:yang-identifier
>>>         |        +--ro revision yang:revision-identifier
>>>         |        +--ro schema?     inet:uri
>>>         +--ro datastore* [name] // Allows future per datastore
>>>     properties.
>>>         |  +--ro name          identityref
>>>         +--ro checksum       string
>>>
>>>     ------------------------------
>>>
>>>     *(2) An enhanced version of the structure (1) above, that is
>>>     extended to allow the structure to be reused for schema-mount
>>>     via an augmentation.*
>>>
>>>     This is similar to the structure above, except that the "the set
>>>     of modules" is contained in a list of named schema (e.g. similar
>>>     to the schema mount draft), allowing this structure to be
>>>     re-used for schema mount.
>>>
>>>     Schema mount would be expected to augment yang-library to add in
>>>     the additional schema mount information.  In the tree diagram, I
>>>     have shown the schema-mount mount-point augmentation, but not
>>>     including namespaces yet.
>>>
>>>     Every server would be required to provide at least one schema in
>>>     the schema list, and the primary schema for the device would
>>>     always be given the name "primary".
>>>
>>>     module: ietf-yang-library
>>>      +--ro yang-library
>>>         +--ro schema* [name]
>>>         |  +--ro name           string
>>>         |  +--ro checksum       string
>>>         |  +--ro module* [name]
>>>         |  |  +--ro name yang:yang-identifier
>>>         |  |  +--ro revision? yang:revision-identifier
>>>         |  |  +--ro schema?        inet:uri
>>>         |  |  +--ro namespace      inet:uri
>>>         |  |  +--ro submodule* [name]
>>>         |  |  |  +--ro name yang:yang-identifier
>>>         |  |  |  +--ro revision? yang:yang-identifier
>>>         |  |  |  +--ro schema?     inet:uri
>>>         |  |  +--ro not-implemented-in*
>>>         |  |  |              -> /yang-library/datastore/name
>>>         |  |  +--ro feature* [name]
>>>         |  |  |  +--ro name yang:yang-identifier
>>>         |  |  |  +--ro not-implemented-in*
>>>         |  |  |              -> /yang-library/datastore/name
>>>         |  |  +--ro deviation*
>>>         |  |  |              -> ../name
>>>         |  |  +- schema-mount:mount-point* [label]
>>>         |  |     +--ro label yang:yang-identifier
>>>         |  |     +--ro config?       boolean
>>>         |  |     +--ro (schema-ref)
>>>         |  |        +--:(inline)
>>>         |  |        |  +--ro inline? empty
>>>         |  |        +--:(use-schema)
>>>         |  |           +--ro use-schema* [name]
>>>         |  |              +--ro name
>>>         |  |              |       -> /yang-library/schema/name
>>>         |  |              +--ro parent-reference*   yang:xpath1.0
>>>         |  |
>>>         |  +--ro import-only-module* [name revision]
>>>         |     +--ro name yang:yang-identifier
>>>         |     +--ro revision            union
>>>         |     +--ro schema? inet:uri
>>>         |     +--ro namespace inet:uri
>>>         |     +--ro submodule* [name]
>>>         |        +--ro name yang:yang-identifier
>>>         |        +--ro revision yang:revision-identifier
>>>         |        +--ro schema?     inet:uri
>>>         +--ro datastore* [name] // Allows future per datastore
>>>     properties.
>>>         |  +--ro name          identityref
>>>         +--ro checksum       string
>>>
>>>     Please can you provide comments on these structures, in particular:
>>>
>>>     Is this version better (i.e. simpler) that the version currently
>>>     in draft-ietf-netconf-rfc7895bis-02 (below)?
>>>
>>>     Should we try and make the structure extensible for schema-mount
>>>     via augmentation (i.e. version (2)), or is it better that
>>>     schema-mount has its own separate subtree?
>>>
>>>     For reference only I have included the existing YANG library and
>>>     YANG library bis draft tree diagrams.
>>>
>>>     Thanks,
>>>     Rob
>>>
>>>
>>>     -----------------------------
>>>
>>>     *** FOR REFERENCE ONLY ***
>>>
>>>     (3)  The current YANG library structure in YANG library bis
>>>     (draft-ietf-netconf-rfc7895bis-02)
>>>
>>>         module: ietf-yang-library
>>>             +--ro yang-library
>>>                +--ro modules
>>>                |  +--ro module* [id]
>>>                |     +--ro id                  string
>>>                |     +--ro name                yang:yang-identifier
>>>                |     +--ro revision?           revision-identifier
>>>                |     +--ro schema?             inet:uri
>>>                |     +--ro namespace           inet:uri
>>>                |     +--ro feature*            yang:yang-identifier
>>>                |     +--ro deviation* [module]
>>>                |     |  +--ro module    -> ../../id
>>>                |     +--ro conformance-type    enumeration
>>>                |     +--ro submodule* [name]
>>>                |        +--ro name        yang:yang-identifier
>>>                |        +--ro revision?   revision-identifier
>>>                |        +--ro schema?     inet:uri
>>>                +--ro module-sets
>>>                |  +--ro module-set* [id]
>>>                |     +--ro id        string
>>>                |     +--ro module*   -> ../../../modules/module/id
>>>                +--ro datastores
>>>                |  +--ro datastore* [name]
>>>                |     +--ro name          identityref
>>>                |     +--ro module-set
>>>                |             -> ../../../module-sets/module-set/id
>>>                +--ro checksum       string
>>>
>>>     -----------------------------
>>>
>>>     *** FOR REFERENCE ONLY ***
>>>
>>>     (4)  The current YANG library structure (RFC 7895)
>>>
>>>            +--ro modules-state
>>>               +--ro module-set-id    string
>>>               +--ro module* [name revision]
>>>                  +--ro name                yang:yang-identifier
>>>                  +--ro revision            union
>>>                  +--ro schema?             inet:uri
>>>                  +--ro namespace           inet:uri
>>>                  +--ro feature*            yang:yang-identifier
>>>                  +--ro deviation* [name revision]
>>>                  |  +--ro name        yang:yang-identifier
>>>                  |  +--ro revision    union
>>>                  +--ro conformance-type    enumeration
>>>                  +--ro submodule* [name revision]
>>>                     +--ro name        yang:yang-identifier
>>>                     +--ro revision    union
>>>                     +--ro schema?     inet:uri
>>>
>>>
>>>
>>>     _______________________________________________
>>>     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
>     
>
>


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


  
    
  
  
    
Hi Andy,

    

    

    
On 16/11/2017 02:29, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
The per-datastore feature aspect of NMDA is a new and
          significant change to YANG.

        


        

        

          

            
    |  |  +--ro feature* [name]

                  |  |  |  +--ro name       
                yang:yang-identifier

                  |  |  |  +--ro not-implemented-in*

                  |  |  |              ->
                /yang-library/datastore/name

          

        

        


        

        
YANG does not define feature conformance at this
          granularity.

        
I strongly object to this change to YANG conformance.

        
A server can only advertise a YANG feature if it
          implemented on the entire server.

      

    

    

      

        


        

        
This extra complexity is not present on the openconfig
          solution or requirements.

      

    

    In terms of comparison, it definitely is:

    - you can have different features for the config and state trees
    (e.g. "router-id" feature in RFC 8022).

    - sometimes the conventions are not followed completely
    consistently, e.g. different types, or semantics between config and
    state.

    - sometimes the structures differ between config and state.

    

    So, the problem comparing between config and state is not easier in
    either the IETF split tree or OpenConfig solutions. 

    

    

      

        
Comparing any datastore to <operational> is much more
          complex (any may not be possible)

        
if the features are different for a given module.

      

    

    You can always compare (except deviations in operational).  If a
    feature is enabled on any configuration datastore then it must also
    be enabled on operational.

    

    E.g.  take "router-id" feature from RFC8022bis (that was also
    defined in RFC8022).

    

    This feature can be enabled:

    (i) everywhere (i.e. <conventional> + <i2rs-ephemeral> +
    <operational>), or

    (ii) <conventional> + <operational>, or

    (iii) <i2rs-ephemral> + <operational>, or

    (iv) <operational> only, or

    (v) or in none of them.

    

    Hence, <operational> always contains a superset of the nodes.

    

    

      

        


        

        
I do not see how <operational> can be true superset
          of the conventional datastores

        
if the features are different.

      

    

    

    Because of the statement above.

    

    Thanks,

    Rob

    

    

      

        


        

        


        

        
Andy

        


        

      

      


        
On Wed, Nov 15, 2017 at 9:29 AM, Robert
          Wilton <rwilton@cisco.com>
          wrote:

          

            
 I don't think that
              this is really a good idea.  You would end up returning
              server metadata in addition to the configuration.

              

              I still think that the YANG library proposal is the best
              solution.

              

              Thanks,

              Rob

              

              

              
On
                16/11/2017 01:21, Vladimir Vassilev wrote:

              

              
 Hello,

                

                I have a proposal based on <get-data> that
                provides an elegant solution to consider as a 3rd
                option.  It is based on keeping exactly the same model
                as in RFC 7895 and using <get-data> RPC to
                retrieve datastore specific yang-library instance data
                in a similar way one would use <get-data> to
                retrieve the datastore contents. In addition a top level
                config=false container e.g. /datastores with list of
                supported datastores that does not need to be part of
                the yang-library module:

                

                module: ietf-datastores

                +--ro datastores

                |  +--ro datastore* [name]

                |     +--ro name          identityref

                

                Vladimir

                

                On 11/09/2017 05:51 PM, Robert Wilton wrote:

                

                  
Hi,

                  
Given some of the feedback related to the
                    complexity of the YANG library bis structure, we
                    have come up with two other possible structures for
                    the YANG library data:

                  
(1) A simplified structure to make YANG library
                    meet the NMDA requirements, but that is closer to
                    the existing YANG library structure, and arguably
                    simpler.

                    (2) An enhanced version of the structure (1) above,
                    that is also extended to allow the structure to be
                    reused for schema-mount via an augmentation.

                  
For reference, at the end of this email, I have
                    also included the tree diagram of the existing YANG
                    library, and the current YANG library bis draft
                    (draft-ietf-netconf-rfc7895bis-02) version.

                  

                  
Considering the two new YANG library structures:

                  

                  
------------------------

                  

                  
(1) A simplified structure to make YANG library
                      meet the NMDA requirements, but that is closer to
                      the existing YANG library structure.

                  
The main changes are:

                    (i) Split "implemented modules" and
                    "import-only-modules" into two separate lists,
                    making the most important list (i.e. implemented
                    modules) keyed by module name only and hence easier
                    to reference.

                    (ii) Assume modules are implemented in all
                    datastores by default (with a "not-implemented-in"
                    leaflist of datastores that a module is not
                    implemented in).

                    (iii) Assume that features are implemented in all
                    datastores by default (with a "not-implemented-in"
                    leaflist of datastores that a feature is not
                    implemented in).

                    (iv) Deleted module-sets.

                    (v) Datastores are now just a list of supported
                    datastores (that could potentially be extended with
                    further per datastore properties in future).

                  

                  
Manually generated tree output for proposed YANG
                    library:

                  
module: ietf-yang-library

                     +--ro yang-library

                        +--ro modules

                        |  +--ro module* [name]

                        |  |  +--ro name          
                      yang:yang-identifier

                        |  |  +--ro revision?     
                      revision-identifier

                        |  |  +--ro schema?        inet:uri

                        |  |  +--ro namespace      inet:uri

                        |  |  +--ro submodule* [name]

                        |  |  |  +--ro name       
                      yang:yang-identifier

                        |  |  |  +--ro revision?  
                      yang:yang-identifier

                        |  |  |  +--ro schema?     inet:uri

                        |  |  +--ro not-implemented-in*

                        |  |  |              ->
                      /yang-library/datastore/name

                        |  |  +--ro feature* [name]

                        |  |  |  +--ro name       
                      yang:yang-identifier

                        |  |  |  +--ro not-implemented-in*

                        |  |  |              ->
                      /yang-library/datastore/name

                        |  |  +--ro deviation*

                        |  |                 ->
                      ../name              

                        |  |

                        |  +--ro import-only-module* [name
                      revision]

                        |     +--ro name               
                      yang:yang-identifier

                        |     +--ro revision            union

                        |     +--ro schema?            
                      inet:uri

                        |     +--ro namespace          
                      inet:uri

                        |     +--ro submodule* [name]

                        |        +--ro name       
                      yang:yang-identifier

                        |        +--ro revision   
                      yang:revision-identifier

                        |        +--ro schema?     inet:uri

                        +--ro datastore* [name] // Allows
                      future per datastore properties.

                        |  +--ro name          identityref

                        +--ro checksum       string

                  

                  
------------------------------

                  
(2) An enhanced version of the structure (1)
                      above, that is extended to allow the structure to
                      be reused for schema-mount via an augmentation.

                  
This is similar to the structure above, except that
                    the "the set of modules" is contained in a list of
                    named schema (e.g. similar to the schema mount
                    draft), allowing this structure to be re-used for
                    schema mount.

                  
Schema mount would be expected to augment
                    yang-library to add in the additional schema mount
                    information.  In the tree diagram, I have shown the
                    schema-mount mount-point augmentation, but not
                    including namespaces yet.

                  
Every server would be required to provide at least
                    one schema in the schema list, and the primary
                    schema for the device would always be given the name
                    "primary".

                  
module: ietf-yang-library

                     +--ro yang-library

                        +--ro schema* [name]

                        |  +--ro name           string

                        |  +--ro checksum       string

                        |  +--ro module* [name]

                        |  |  +--ro name          
                      yang:yang-identifier

                        |  |  +--ro revision?     
                      yang:revision-identifier

                        |  |  +--ro schema?        inet:uri

                        |  |  +--ro namespace      inet:uri

                        |  |  +--ro submodule* [name]

                        |  |  |  +--ro name       
                      yang:yang-identifier

                        |  |  |  +--ro revision?  
                      yang:yang-identifier

                        |  |  |  +--ro schema?     inet:uri

                        |  |  +--ro not-implemented-in*

                        |  |  |              ->
                      /yang-library/datastore/name

                        |  |  +--ro feature* [name]

                        |  |  |  +--ro name       
                      yang:yang-identifier

                        |  |  |  +--ro not-implemented-in*

                        |  |  |              ->
                      /yang-library/datastore/name

                        |  |  +--ro deviation*

                        |  |  |              ->
                      ../name       

                        |  |  +- schema-mount:mount-point*
                      [label]

                        |  |     +--ro label        
                      yang:yang-identifier

                        |  |     +--ro config?       boolean

                        |  |     +--ro (schema-ref)

                        |  |        +--:(inline)

                        |  |        |  +--ro inline?      
                      empty

                        |  |        +--:(use-schema)

                        |  |           +--ro use-schema* [name]

                        |  |              +--ro name

                        |  |              |       ->
                      /yang-library/schema/name

                        |  |              +--ro
                      parent-reference*   yang:xpath1.0          

                        |  |

                        |  +--ro import-only-module* [name
                      revision]

                        |     +--ro name               
                      yang:yang-identifier

                        |     +--ro revision            union

                        |     +--ro schema?            
                      inet:uri

                        |     +--ro namespace          
                      inet:uri

                        |     +--ro submodule* [name]

                        |        +--ro name       
                      yang:yang-identifier

                        |        +--ro revision   
                      yang:revision-identifier

                        |        +--ro schema?     inet:uri

                        +--ro datastore* [name] // Allows
                      future per datastore properties.

                        |  +--ro name          identityref

                        +--ro checksum       string

                  
Please can you provide comments on these
                    structures, in particular:

                  
Is this version better (i.e. simpler) that the
                    version currently in draft-ietf-netconf-rfc7895bis-02
                    (below)?

                  

                  
Should we try and make the structure extensible for
                    schema-mount via augmentation (i.e. version (2)), or
                    is it better that schema-mount has its own separate
                    subtree?

                  
For reference only I have included the existing
                    YANG library and YANG library bis draft tree
                    diagrams.

                  

                  
Thanks,

                    Rob

                  

                  


                  

                  
-----------------------------

                  
*** FOR REFERENCE ONLY ***

                  

                  
(3)  The current YANG library structure in YANG
                    library bis (draft-ietf-netconf-rfc7895bis-02)

                  

                  
   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

                  
-----------------------------

                  
*** FOR REFERENCE ONLY ***

                  

                  
(4)  The current YANG library structure (RFC 7895)

                  
      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



                  
 

                  

                  

                  

                  
_______________________________________________
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

            

          

        

        

      

    

    

  


--------------96541FCDCA4FD5F9E0A030F6--


From nobody Wed Nov 15 18: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 38BC6120227 for ; Wed, 15 Nov 2017 18:06:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNDaYsRfSFdL for ; Wed, 15 Nov 2017 18:06:55 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 07E85127867 for ; Wed, 15 Nov 2017 18:06:55 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id E337018215DC; Thu, 16 Nov 2017 03:05:30 +0100 (CET)
Received: from localhost (dhcp-9083.meeting.ietf.org [31.133.144.131]) by trail.lhotka.name (Postfix) with ESMTPSA id B952C1820F76 for ; Thu, 16 Nov 2017 03:05:28 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
Mail-Followup-To: netmod@ietf.org
Date: Thu, 16 Nov 2017 10:07:56 +0800
Message-ID: <87375f9ds3.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 02:06:57 -0000

Balazs Lengyel  writes:

> On 2017-11-15 21:20, Martin Bjorklund wrote:
>
>  Ladislav Lhotka  wrote:
>
>  On Wed, 2017-11-15 at 12:17 +0100, Martin Bjorklund wrote:
>
>  Balazs Lengyel  wrote:
>
>  The server MAY implement obsoleted nodes or MAY NOT. This may
>  or may
> not  is not good enough as a contract for the management client.  My
> problem is that the current solution is just not good enough. IMHO we
> need to change it.
>
>
> Note that if a server implements version 1 of a module, and then the
> module doesn't change, but the server in the next sw version drops
> support for the module, the client will also be unhappy.  We (the
> IETF) can't have rules for these kinds of things.
>
>
> If the server drops support for a module, then that module has to disappear from
> YANG library, so it is a priori known that it happened. With deprecated/obsolete
> nodes, a server may drop their support without any notice, within the same
> module&revision. 
>
>
> I agree that *that* is a problem, but that's not what Balazs asked about.
>
>
> /martin
>
> BALAZS: Actually this exactly one of my problems. See other letter for
> my 3 problems. This is one cause of 2)

Thank you, Balazs, I was getting confused. ;-)

>
>  
>
>  new stuff with a new name, although that might not be the common
> practice.  Which is a good thing, as I believe it is sometimes better
> to correct existing definitions then to replace them.
>
>
> But you still want to require servers to implement even obsolete
> nodes?
>
>
> I think with semver support there will be no need for the "status" statement -
> the nodes just get removed and version number bumped.
>
> Lada
>
> BALAZS: You still need at leaast deprecated: my proposal
> o  "deprecated" schema nodes MUST still work as defined by the YANG module. 
>        The deprecated status serves only as a a warning that the schema node 
>        will be removed or obsoleted in the future."

But is this really necessary? As long as the new (incompatible) version
doesn't get pulled in automatically, implementors needn't care too
much. And if they decide to upgrade to the new version, they have to
check the differences anyway - as you said, they may not be in the
schema.

Lada

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

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
-------------------- End of forwarded message --------------------

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


From nobody Wed Nov 15 18:10: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 8FF4E126CC4 for ; Wed, 15 Nov 2017 18:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFOevIV3V1YY for ; Wed, 15 Nov 2017 18:10:01 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB35120227 for ; Wed, 15 Nov 2017 18:10:01 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 4271F18215DD; Thu, 16 Nov 2017 03:08:38 +0100 (CET)
Received: from localhost (dhcp-9083.meeting.ietf.org [31.133.144.131]) by trail.lhotka.name (Postfix) with ESMTPSA id DB6201820F76; Thu, 16 Nov 2017 03:08:34 +0100 (CET)
From: Ladislav Lhotka 
To: Randy Presuhn , netmod@ietf.org
In-Reply-To: <02d86058-4ebb-1bf8-0ecc-3ff464664479@alumni.stanford.edu>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <614c9b33-774a-cbe0-0328-cfc7ad9ac11b@ericsson.com> <02d86058-4ebb-1bf8-0ecc-3ff464664479@alumni.stanford.edu>
Mail-Followup-To: Randy Presuhn , netmod@ietf.org
Date: Thu, 16 Nov 2017 10:11:01 +0800
Message-ID: <87zi7n7z2i.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 02:10:04 -0000

Randy Presuhn  writes:

> Hi -
>
> On 11/15/2017 2:02 AM, Balazs Lengyel wrote:
>> While a server may correctly support multiple versions, the human=20
>> operator on the CLI has a 99% chance of mixing up which version he is=20
>> using. Humans will not check every type and leaf=C2=A0 to check that the=
y=20
>> remember the little differences between model versions. It is a recipe=20
>> for human mistakes. According to some statistics 50% of downtime is=20
>> caused by human errors, so we should not provide the operator with a gun=
=20
>> to shoot himself. Ericsson has a rule never to have multiple versions of=
=20
>> the same module on a network node.
>
> Does this mean that they require all line cards in a chassis to have
> exactly the same firmware revision level?  If so, when a card with a
> newer firmware revision level is swapped in, does that require all other
> cards of the same type in that chassis to also be replaced concurrently?
> Sounds like even a fairly routine/minor update/repair would effectively
> result in a system outage.

To be fair, there is no good solution to this in the current state of
affairs either. The limiting factor is the document-oriented nature of
YANG. It is a good use case for schema mount though.

Lada

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

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


From nobody Wed Nov 15 18:42: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 DF680126DFB for ; Wed, 15 Nov 2017 18:42:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jouwkw-fFQyH for ; Wed, 15 Nov 2017 18:42:24 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9223012940B for ; Wed, 15 Nov 2017 18:42:23 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id i14so552005lfc.1 for ; Wed, 15 Nov 2017 18:42:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yRhikocCnyKm2xoZpv4Ij5OtGYqsJiUGNvL5cGEThcY=; b=U3nzQEo7ipZ0Ch+C2sCyZTCaxNP77mcDnh+tN/MTjMUxzqL88h87eBVcjv0OhZVitB LGcpAO7+ih9vZjmUsImgVreejVlYMBHe3r3ZER8r3jMZx76GEcfsrBkGOIRbJF/AHJaJ fqYGsf4aOgqmsf017DMpxUVBfghOxQVK41yhuq6WY9/pp3paLZBZ6vxDHuM0O3wESqz/ 5dzMTcQjEdxgeNkuLNeVOinJKpn1CAj/Tpl1RbEKJJ9nvYhzqIAx+Totl78K+ZunV37o UzUJn53OalTMaSczhsgJNqzdEhTa09OHs8rqINyxCBt1e3N/aVC0PRbepP4AE8T7N2KA KyAQ==
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=yRhikocCnyKm2xoZpv4Ij5OtGYqsJiUGNvL5cGEThcY=; b=gmk4qhyr96oXCgN09/1KynsG7qNDXAttFBmDgrj8wx6n+VqIBz64mTqyS00pWLt0h5 0Ei1JyqtFGA6kCTDl9nhuJCkrDm2HJwCuKUb8jIuDyNEjwj/T0YIlG00Mc+ettttoPEm v7ufzObGG7nz2jmFUJ86gSykUC+riPzQAfNr3eDiibDtLf546gbde9ioYFUuludG1Uri pzNE4GmxaHz0INMRa1EXRBgpLAEIHoYIsCPeCs3P+RxLFNtuKmJKdK8vyjbyo3Trz3BO 01EksSnB/VcNxPO4DsAHyFujPFnb4+q9Z36hS8MamF+2SHZlmLDwn555FppvczTkOURs r35A==
X-Gm-Message-State: AJaThX7Ts7vWgcTe0Rw1o+eSigZxXUYX3yRx9bkssG+QvJ798nPCdtKk sA2aW9b9u7WSt/U0topsHNRTAtXooRQ+0ePhz7F/rw==
X-Google-Smtp-Source: AGs4zMYeSfdBmT6uxSIe+/qQfxkqosR9gPZJgubv0+yOva0QC2xPsqqx7B9twqqyYvSmFdjhtobuxSyZIbK6RladdYo=
X-Received: by 10.25.225.140 with SMTP id l12mr51953lfk.106.1510800141701; Wed, 15 Nov 2017 18:42:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Wed, 15 Nov 2017 18:42:20 -0800 (PST)
In-Reply-To: 
References:  <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com>  
From: Andy Bierman 
Date: Wed, 15 Nov 2017 18:42:20 -0800
Message-ID: 
To: Robert Wilton 
Cc: Vladimir Vassilev , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113c2f46c5eaf3055e1091c5"
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Nov 2017 02:42:30 -0000

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

On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton  wrote:

> Hi Andy,
>
> On 16/11/2017 02:29, Andy Bierman wrote:
>
> Hi,
>
> The per-datastore feature aspect of NMDA is a new and significant change
> to YANG.
>
>     |  |  +--ro feature* [name]
>     |  |  |  +--ro name        yang:yang-identifier
>     |  |  |  +--ro not-implemented-in*
>     |  |  |              -> /yang-library/datastore/name
>
>
> YANG does not define feature conformance at this granularity.
> I strongly object to this change to YANG conformance.
> A server can only advertise a YANG feature if it implemented on the entire
> server.
>
>
> This extra complexity is not present on the openconfig solution or
> requirements.
>
> In terms of comparison, it definitely is:
> - you can have different features for the config and state trees (e.g.
> "router-id" feature in RFC 8022).
> - sometimes the conventions are not followed completely consistently, e.g.
> different types, or semantics between config and state.
> - sometimes the structures differ between config and state.
>
> So, the problem comparing between config and state is not easier in either
> the IETF split tree or OpenConfig solutions.
>
> Comparing any datastore to  is much more complex (any may not
> be possible)
> if the features are different for a given module.
>
> You can always compare (except deviations in operational).  If a feature
> is enabled on any configuration datastore then it must also be enabled on
> operational.
>
>
This is not apparent from the text. The draft-02 library is very out of
date at this point.

I only care about restricting the conventional datastores,  and
.
It will be a massive client rewrite if the client cannot compare 
to 
with 1 schema tree.

If the updated draft reflects the feature-in-operational requirement above
then
I have no objections to the proposed YANG library functionality.

I am still concerned about per-datastore deviations.
IMO, the server MUST implement the same deviations in these special
datastores.
If that cannot be done, the operational node will not be present. Another
leaf node
(like admin-state/oper-state) needs to be used instead.

If the server does implement per-datastore deviations,
clients may not work (if they use the conventional datastore schema tree
for ).
The same thing happens if the client ignores plain-old-deviations now,
so this is not a big deal.




E.g.  take "router-id" feature from RFC8022bis (that was also defined in
> RFC8022).
>
> This feature can be enabled:
> (i) everywhere (i.e.  +  + ), or
> (ii)  + , or
> (iii)  + , or
> (iv)  only, or
> (v) or in none of them.
>
>

I still think the WG needs to define YANG conformance for datastores,
The question "what datastores does server implementation X support for
module foo?" is covered.
The question "what datastores MUST, SHOULD, MAY a compliant server
implementation
support for module foo?" is totally ignored.


Hence,  always contains a superset of the nodes.
>
>
> I do not see how  can be true superset of the conventional
> datastores
> if the features are different.
>
>
> Because of the statement above.
>
> Thanks,
> Rob
>
>


Andy


>
>
> Andy
>
>
> On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton  wrote:
>
>> I don't think that this is really a good idea.  You would end up
>> returning server metadata in addition to the configuration.
>>
>> I still think that the YANG library proposal is the best solution.
>>
>> Thanks,
>> Rob
>>
>>
>> On 16/11/2017 01:21, Vladimir Vassilev wrote:
>>
>> Hello,
>>
>> I have a proposal based on  that provides an elegant solution
>> to consider as a 3rd option.  It is based on keeping exactly the same model
>> as in RFC 7895 and using  RPC to retrieve datastore specific
>> yang-library instance data in a similar way one would use  to
>> retrieve the datastore contents. In addition a top level config=false
>> container e.g. /datastores with list of supported datastores that does not
>> need to be part of the yang-library module:
>>
>> module: ietf-datastores
>> +--ro datastores
>> |  +--ro datastore* [name]
>> |     +--ro name          identityref
>>
>> Vladimir
>>
>> On 11/09/2017 05:51 PM, Robert Wilton wrote:
>>
>> Hi,
>>
>> Given some of the feedback related to the complexity of the YANG library
>> bis structure, we have come up with two other possible structures for the
>> YANG library data:
>>
>> (1) A simplified structure to make YANG library meet the NMDA
>> requirements, but that is closer to the existing YANG library structure,
>> and arguably simpler.
>> (2) An enhanced version of the structure (1) above, that is also extended
>> to allow the structure to be reused for schema-mount via an augmentation.
>>
>> For reference, at the end of this email, I have also included the tree
>> diagram of the existing YANG library, and the current YANG library bis
>> draft (draft-ietf-netconf-rfc7895bis-02) version.
>>
>> Considering the two new YANG library structures:
>>
>> ------------------------
>>
>> *(1) A simplified structure to make YANG library meet the NMDA
>> requirements, but that is closer to the existing YANG library structure.*
>>
>> The main changes are:
>> (i) Split "implemented modules" and "import-only-modules" into two
>> separate lists, making the most important list (i.e. implemented modules)
>> keyed by module name only and hence easier to reference.
>> (ii) Assume modules are implemented in all datastores by default (with a
>> "not-implemented-in" leaflist of datastores that a module is not
>> implemented in).
>> (iii) Assume that features are implemented in all datastores by default
>> (with a "not-implemented-in" leaflist of datastores that a feature is not
>> implemented in).
>> (iv) Deleted module-sets.
>> (v) Datastores are now just a list of supported datastores (that could
>> potentially be extended with further per datastore properties in future).
>>
>> Manually generated tree output for proposed YANG library:
>>
>> module: ietf-yang-library
>>  +--ro yang-library
>>     +--ro modules
>>     |  +--ro module* [name]
>>     |  |  +--ro name           yang:yang-identifier
>>     |  |  +--ro revision?      revision-identifier
>>     |  |  +--ro schema?        inet:uri
>>     |  |  +--ro namespace      inet:uri
>>     |  |  +--ro submodule* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro revision?   yang:yang-identifier
>>     |  |  |  +--ro schema?     inet:uri
>>     |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro feature* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro deviation*
>>     |  |                 -> ../name
>>     |  |
>>     |  +--ro import-only-module* [name revision]
>>     |     +--ro name                yang:yang-identifier
>>     |     +--ro revision            union
>>     |     +--ro schema?             inet:uri
>>     |     +--ro namespace           inet:uri
>>     |     +--ro submodule* [name]
>>     |        +--ro name        yang:yang-identifier
>>     |        +--ro revision    yang:revision-identifier
>>     |        +--ro schema?     inet:uri
>>     +--ro datastore* [name] // Allows future per datastore properties.
>>     |  +--ro name          identityref
>>     +--ro checksum       string
>>
>> ------------------------------
>>
>> *(2) An enhanced version of the structure (1) above, that is extended to
>> allow the structure to be reused for schema-mount via an augmentation.*
>>
>> This is similar to the structure above, except that the "the set of
>> modules" is contained in a list of named schema (e.g. similar to the schema
>> mount draft), allowing this structure to be re-used for schema mount.
>>
>> Schema mount would be expected to augment yang-library to add in the
>> additional schema mount information.  In the tree diagram, I have shown the
>> schema-mount mount-point augmentation, but not including namespaces yet.
>>
>> Every server would be required to provide at least one schema in the
>> schema list, and the primary schema for the device would always be given
>> the name "primary".
>>
>> module: ietf-yang-library
>>  +--ro yang-library
>>     +--ro schema* [name]
>>     |  +--ro name           string
>>     |  +--ro checksum       string
>>     |  +--ro module* [name]
>>     |  |  +--ro name           yang:yang-identifier
>>     |  |  +--ro revision?      yang:revision-identifier
>>     |  |  +--ro schema?        inet:uri
>>     |  |  +--ro namespace      inet:uri
>>     |  |  +--ro submodule* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro revision?   yang:yang-identifier
>>     |  |  |  +--ro schema?     inet:uri
>>     |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro feature* [name]
>>     |  |  |  +--ro name        yang:yang-identifier
>>     |  |  |  +--ro not-implemented-in*
>>     |  |  |              -> /yang-library/datastore/name
>>     |  |  +--ro deviation*
>>     |  |  |              -> ../name
>>     |  |  +- schema-mount:mount-point* [label]
>>     |  |     +--ro label         yang:yang-identifier
>>     |  |     +--ro config?       boolean
>>     |  |     +--ro (schema-ref)
>>     |  |        +--:(inline)
>>     |  |        |  +--ro inline?       empty
>>     |  |        +--:(use-schema)
>>     |  |           +--ro use-schema* [name]
>>     |  |              +--ro name
>>     |  |              |       -> /yang-library/schema/name
>>     |  |              +--ro parent-reference*   yang:xpath1.0
>>     |  |
>>     |  +--ro import-only-module* [name revision]
>>     |     +--ro name                yang:yang-identifier
>>     |     +--ro revision            union
>>     |     +--ro schema?             inet:uri
>>     |     +--ro namespace           inet:uri
>>     |     +--ro submodule* [name]
>>     |        +--ro name        yang:yang-identifier
>>     |        +--ro revision    yang:revision-identifier
>>     |        +--ro schema?     inet:uri
>>     +--ro datastore* [name] // Allows future per datastore properties.
>>     |  +--ro name          identityref
>>     +--ro checksum       string
>>
>> Please can you provide comments on these structures, in particular:
>>
>> Is this version better (i.e. simpler) that the version currently in
>> draft-ietf-netconf-rfc7895bis-02 (below)?
>>
>> Should we try and make the structure extensible for schema-mount via
>> augmentation (i.e. version (2)), or is it better that schema-mount has its
>> own separate subtree?
>>
>> For reference only I have included the existing YANG library and YANG
>> library bis draft tree diagrams.
>>
>> Thanks,
>> Rob
>>
>>
>> -----------------------------
>>
>> *** FOR REFERENCE ONLY ***
>>
>> (3)  The current YANG library structure in YANG library bis
>> (draft-ietf-netconf-rfc7895bis-02)
>>
>>    module: ietf-yang-library
>>        +--ro yang-library
>>           +--ro modules
>>           |  +--ro module* [id]
>>           |     +--ro id                  string
>>           |     +--ro name                yang:yang-identifier
>>           |     +--ro revision?           revision-identifier
>>           |     +--ro schema?             inet:uri
>>           |     +--ro namespace           inet:uri
>>           |     +--ro feature*            yang:yang-identifier
>>           |     +--ro deviation* [module]
>>           |     |  +--ro module    -> ../../id
>>           |     +--ro conformance-type    enumeration
>>           |     +--ro submodule* [name]
>>           |        +--ro name        yang:yang-identifier
>>           |        +--ro revision?   revision-identifier
>>           |        +--ro schema?     inet:uri
>>           +--ro module-sets
>>           |  +--ro module-set* [id]
>>           |     +--ro id        string
>>           |     +--ro module*   -> ../../../modules/module/id
>>           +--ro datastores
>>           |  +--ro datastore* [name]
>>           |     +--ro name          identityref
>>           |     +--ro module-set
>>           |             -> ../../../module-sets/module-set/id
>>           +--ro checksum       string
>>
>> -----------------------------
>>
>> *** FOR REFERENCE ONLY ***
>>
>> (4)  The current YANG library structure (RFC 7895)
>>
>>       +--ro modules-state
>>          +--ro module-set-id    string
>>          +--ro module* [name revision]
>>             +--ro name                yang:yang-identifier
>>             +--ro revision            union
>>             +--ro schema?             inet:uri
>>             +--ro namespace           inet:uri
>>             +--ro feature*            yang:yang-identifier
>>             +--ro deviation* [name revision]
>>             |  +--ro name        yang:yang-identifier
>>             |  +--ro revision    union
>>             +--ro conformance-type    enumeration
>>             +--ro submodule* [name revision]
>>                +--ro name        yang:yang-identifier
>>                +--ro revision    union
>>                +--ro schema?     inet:uri
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
>

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




On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Andy,

    

    

    
On 16/11/2017 02:2=
9, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
The per-datastore feature aspect of NMDA is a new and
          significant change to YANG.

        


        

        

          

            
=C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--ro feature* [name]=


              =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro nam=
e=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                yang:yang-identifier

              =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--ro not=
-implemented-in*

              =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
                /yang-library/datastore/name

          

        

        


        

        
YANG does not define feature conformance at this
          granularity.

        
I strongly object to this change to YANG conformance.

        
A server can only advertise a YANG feature if it
          implemented on the entire server.

      

    

    

      

        


        

        
This extra complexity is not present on the openconfig
          solution or requirements.

      

    

    In terms of comparison, it definitely is:

    - you can have different features for the config and state trees
    (e.g. "router-id" feature in RFC 8022).

    - sometimes the conventions are not followed completely
    consistently, e.g. different types, or semantics between config and
    state.

    - sometimes the structures differ between config and state.

    

    So, the problem comparing between config and state is not easier in
    either the IETF split tree or OpenConfig solutions. 

    

    

      

        
Comparing any datastore to <operational> is much more
          complex (any may not be possible)

        
if the features are different for a given module.

      

    

    You can always compare (except deviations in operational).=C2=A0 If a
    feature is enabled on any configuration datastore then it must also
    be enabled on operational.

    

This is not apparent from th=
e text. The draft-02 library is very out of date at this point.
<=
br>
I only care about restricting the conventional datastores, &l=
t;intended> and <operational>.
It will be a massive clie=
nt rewrite if the client cannot compare <intended> to <operational=
>
with 1 schema tree.

If the updated =
draft reflects the feature-in-operational requirement above then
=
I have no objections to the proposed YANG library functionality. =C2=A0

I am still concerned about per-datastore deviations.<=
/div>
IMO, the server MUST implement the same deviations in these speci=
al datastores.
If that cannot be done, the operational node will =
not be present. Another leaf node
(like admin-state/oper-state) n=
eeds to be used instead.

If the server does implem=
ent per-datastore deviations,
clients may not work (if they use t=
he conventional datastore schema tree for <operational>).
T=
he same thing happens if the client ignores plain-old-deviations now,
=

so this is not a big deal.




    E.g.=C2=A0 take "router-id" feature from RFC8022bis (that was=
 also
    defined in RFC8022).

    

    This feature can be enabled:

    (i) everywhere (i.e. <conventional> + <i2rs-ephemeral> +
    <operational>), or

    (ii) <conventional> + <operational>, or

    (iii) <i2rs-ephemral> + <operational>, or

    (iv) <operational> only, or

    (v) or in none of them.

    


I still think=
 the WG needs to define YANG conformance for datastores,
The ques=
tion "what datastores does server implementation X support for module =
foo?" is covered.
The question "what datastores MUST, S=
HOULD, MAY a compliant server implementation
support for module f=
oo?" is totally ignored.



    Hence, <operational> always contains a superset of the nodes.

    

    

      

        


        

        
I do not see how <operational> can be true superset
          of the conventional datastores

        
if the features are different.

      

    

    

    Because of the statement above.

    

    Thanks,

    Rob

    



Andy
=C2=A0

    

      

        


        

        


        

        
Andy

        


        

      

      


        
On Wed, Nov 15, 2017 at 9:29 AM, Robert
          Wilton <rwilton@cisco.com>
          wrote:

          

            
 I don't think th=
at
              this is really a good idea.=C2=A0 You would end up returning
              server metadata in addition to the configuration.

              

              I still think that the YANG library proposal is the best
              solution.

              

              Thanks,

              Rob

              

              

              
On
                16/11/2017 01:21, Vladimir Vassilev wrote:

              

              
 Hello,

                

                I have a proposal based on <get-data> that
                provides an elegant solution to consider as a 3rd
                option.=C2=A0 It is based on keeping exactly the same model
                as in RFC 7895 and using <get-data> RPC to
                retrieve datastore specific yang-library instance data
                in a similar way one would use <get-data> to
                retrieve the datastore contents. In addition a top level
                config=3Dfalse container e.g. /datastores with list of
                supported datastores that does not need to be part of
                the yang-library module:

                

                module: ietf-datastores

                +--ro datastores

                |=C2=A0 +--ro datastore* [name]

                |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

                

                Vladimir

                

                On 11/09/2017 05:51 PM, Robert Wilton wrote:

                

                  
Hi,

                  
Given some of the feedback related to the
                    complexity of the YANG library bis structure, we
                    have come up with two other possible structures for
                    the YANG library data:

                  
(1) A simplified structure to make YANG library
                    meet the NMDA requirements, but that is closer to
                    the existing YANG library structure, and arguably
                    simpler.

                    (2) An enhanced version of the structure (1) above,
                    that is also extended to allow the structure to be
                    reused for schema-mount via an augmentation.

                  
For reference, at the end of this email, I have
                    also included the tree diagram of the existing YANG
                    library, and the current YANG library bis draft
                    (draft-ietf-netconf-rfc7895bis-02) version.

                  

                  
Considering the two new YANG library structures:

                  

                  
------------------------

                  

                  
(1) A simplified structure to make YANG library
                      meet the NMDA requirements, but that is closer to
                      the existing YANG library structure.

                  
The main changes are:

                    (i) Split "implemented modules" and
                    "import-only-modules" into two separate lists=
,
                    making the most important list (i.e. implemented
                    modules) keyed by module name only and hence easier
                    to reference.

                    (ii) Assume modules are implemented in all
                    datastores by default (with a "not-implemented-in&=
quot;
                    leaflist of datastores that a module is not
                    implemented in).

                    (iii) Assume that features are implemented in all
                    datastores by default (with a "not-implemented-in&=
quot;
                    leaflist of datastores that a feature is not
                    implemented in).

                    (iv) Deleted module-sets.

                    (v) Datastores are now just a list of supported
                    datastores (that could potentially be extended with
                    further per datastore properties in future).

                  

                  
Manually generated tree output for proposed YANG
                    library:

                  
module: ietf-yang-library

                    =C2=A0+--ro yang-library

                    =C2=A0=C2=A0=C2=A0 +--ro modules

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name=
]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revis=
ion?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      revision-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schem=
a?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro names=
pace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submo=
dule* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro revision?=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-i=
mplemented-in*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
                      /yang-library/datastore/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro featu=
re* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro not-implemented-in*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
                      /yang-library/datastore/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro devia=
tion*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ->
                      ../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 +--ro import-only-m=
odule* [name
                      revision]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 union

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                      inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro submodule* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0
                      yang:revision-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri<=
br>
                    =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // =
Allows
                      future per datastore properties.

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

                    =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 string

                  

                  
------------------------------

                  
(2) An enhanced version of the structure (1)
                      above, that is extended to allow the structure to
                      be reused for schema-mount via an augmentation.
                  
This is similar to the structure above, except that
                    the "the set of modules" is contained in a li=
st of
                    named schema (e.g. similar to the schema mount
                    draft), allowing this structure to be re-used for
                    schema mount.

                  
Schema mount would be expected to augment
                    yang-library to add in the additional schema mount
                    information.=C2=A0 In the tree diagram, I have shown th=
e
                    schema-mount mount-point augmentation, but not
                    including namespaces yet.

                  
Every server would be required to provide at least
                    one schema in the schema list, and the primary
                    schema for the device would always be given the name
                    "primary".

                  
module: ietf-yang-library

                    =C2=A0+--ro yang-library

                    =C2=A0=C2=A0=C2=A0 +--ro schema* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro checksum=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro module* [name=
]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro name=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro revis=
ion?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:revision-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro schem=
a?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro names=
pace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro submo=
dule* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro revision?=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro not-i=
mplemented-in*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
                      /yang-library/datastore/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro featu=
re* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0 +--=
ro not-implemented-in*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
                      /yang-library/datastore/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +--ro devia=
tion*

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ->
                      ../name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =


                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0 +- schema-m=
ount:mount-point*
                      [label]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro label=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean
                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro (schema-ref)

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--:(inline)

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                      empty

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--:(use-schema)

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro use-schema* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 ->
                      /yang-library/schema/name

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro
                      parent-reference*=C2=A0=C2=A0 yang:xpath1.0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 |

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro import-only-m=
odule* [name
                      revision]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 union

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                      inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      inet:uri

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +=
--ro submodule* [name]

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                      yang:yang-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0
                      yang:revision-identifier

                    =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri<=
br>
                    =C2=A0=C2=A0=C2=A0 +--ro datastore* [name] // =
Allows
                      future per datastore properties.

                    =C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref

                    =C2=A0=C2=A0=C2=A0 +--ro checksum=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 string

                  
Please can you provide comments on these
                    structures, in particular:

                  
Is this version better (i.e. simpler) that the
                    version currently in draft-ietf-netconf-rfc7895bis-02
                    (below)?

                  

                  
Should we try and make the structure extensible for
                    schema-mount via augmentation (i.e. version (2)), or
                    is it better that schema-mount has its own separate
                    subtree?

                  
For reference only I have included the existing
                    YANG library and YANG library bis draft tree
                    diagrams.

                  

                  
Thanks,

                    Rob

                  

                  


                  

                  
-----------------------------

                  
*** FOR REFERENCE ONLY ***

                  

                  
(3)=C2=A0 The current YANG library structure in YANG
                    library bis (draft-ietf-netconf-rfc7895bis-02)

                  

                  
   module: =
ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

                  
-----------------------------

                  
*** FOR REFERENCE ONLY ***

                  

                  
(4)=C2=A0 The current YANG library structure (RFC 7895=
)

                  
      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



                  
 

                  

                  

                  

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


                

                

              

              

            

            

            _______________________________________________

            netmod mailing list

            netmod@iet=
f.org

            https://www.ietf.org/mailman/listinfo/n=
etmod

            

          

        

        

      

    

    

  






--001a113c2f46c5eaf3055e1091c5--


From nobody Wed Nov 15 19:04: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 640B5129407 for ; Wed, 15 Nov 2017 19:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ug-omgIbdMMm for ; Wed, 15 Nov 2017 19:04:18 -0800 (PST)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CC8126CC4 for ; Wed, 15 Nov 2017 19:04:18 -0800 (PST)
Received: by mail-pg0-x22f.google.com with SMTP id 4so10639339pge.1 for ; Wed, 15 Nov 2017 19:04:18 -0800 (PST)
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:content-transfer-encoding:content-language :thread-index; bh=an7AtvV2B1iF8Nyjsgi+C2mF7WqTDvOyFxAFqKR4AQw=; b=o9h3d16bmFMKBO4TF1PjUM4E5Qnu5dnR8A5/Fg4kubWd7JbKVQEZb4H0LXT37e1hNI 7dyIAIHjDLekyb3CeS1i0Tnwh/dy26DohXk9dBND8hCIu4VtAsGySHTmkljR+Mjqk6Yq 45VJMmAfkD2lUJ+yyCmhcpgbw9vsg6w0AUQs4E2cMabxD6hejiuWVgzn9Un2GJ4fRysY YPLJv/m0cvBLC66t10sLY2S0loiJ4MBaVeOma+umR0MXXMtjH33P8j5CYECUkJYTeQy8 HMbvlqFjIq7Uvsf1UJEt7zWC+VB/oNOh9+KcZFkJKSnYrSVtOx4r3kfOeYXCjPOJvA4H G3Qg==
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:content-transfer-encoding:content-language :thread-index; bh=an7AtvV2B1iF8Nyjsgi+C2mF7WqTDvOyFxAFqKR4AQw=; b=thICRloNfa0tupVS4cGGoTVHQjMqHtivYqkm6ELK4fe+W8qx4j7mcOYIXii0XPSh4a GIceVjgWvEDUxXzR8NPbDX2xyxrW8gZrfocgJD9rltbW7Qy2r4ggLABVA2j+UchEzzLh h6B9QIlkSaIzyKgOfTAOYf20bBWqZJUONZY0C4tyZkDAG7+RffHVBQsyhqizc+w17dO7 wMVISLKhvFV73vnwNfPGJSwtk6fNsnchZ235dvzbU7qVcBUR/3EzFlphYxoyPd4R/2xg skFRJfk3RammumKbCFSl/o/E1sReTxHWaoxz9P/7g9oqeyt8QG/1/YnZRE4IK4OajECa qrbw==
X-Gm-Message-State: AJaThX6YiuT8DMHb8Ic2pCkEpM6u06y/E1dgOYn/HUr90OSC394EilGR eExtEyAZ/4aX19uFMnqoBBA=
X-Google-Smtp-Source: AGs4zMYWnDcXSU7EfiAQ3luPSho11AXRO59wBOx2ymKseUJ8mtd3g456yJkhbUquzpDpSmLfryE6pw==
X-Received: by 10.99.124.88 with SMTP id l24mr210483pgn.355.1510801457561; Wed, 15 Nov 2017 19:04:17 -0800 (PST)
Received: from DESKTOPFLHJVQJ ([2001:67c:1232:144:6d1f:df87:592f:459b]) by smtp.gmail.com with ESMTPSA id d2sm122282pfe.164.2017.11.15.19.04.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 19:04:17 -0800 (PST)
From: "Mehmet Ersue" 
To: "'Mahesh Jethanandani'" , "'Robert Wilton'" 
Cc: 
References: <20171115.101454.1576716701146734257.mbj@tail-f.com>  <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com>
In-Reply-To: <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com>
Date: Thu, 16 Nov 2017 11:04:17 +0800
Message-ID: <014a01d35e87$98797950$c96c6bf0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: de
Thread-Index: AQGxefq6yqyvOLF6jhxyeqpBlh8GFwHgxCcMAmPZNyujN/VQ8A==
Archived-At: 
Subject: Re: [netmod] tree diagram guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Nov 2017 03:04:20 -0000

The Wiki is useful as a starting point providing a collection of =
pointers to guideline RFCs and the bis-revisions in development.

Cheers,
Mehmet

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh
> Jethanandani
> Sent: Thursday, November 16, 2017 7:39 AM
> To: Robert Wilton 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] tree diagram guidelines
>=20
> Other SDOs can and follow the work in IETF through the RFCs we =
publish.
> They do not follow wiki=E2=80=99s, unless the document itself says, =
=E2=80=9Chere are the
> guidelines, but if you are looking for the latest, go to this =
wiki=E2=80=9D. I therefore
> would support the proposal outlined below. It gives the SDO a stable =
point of
> reference with a document, which gets updated occasionally, but also =
allows
> them to peak at what is coming down the pipeline.
>=20
> Thanks.
>=20
> > On Nov 15, 2017, at 6:53 PM, Robert Wilton  =
wrote:
> >
> > I liked the suggestion from Chris Hopps:
> >
> > I think that it was along the lines of ...
> >
> > The RFC contains a reference at the top that states that updates to =
the
> guidelines is available on a wiki at ....
> >
> > Every few years the guidelines on the wiki can be folded into a =
latest
> version of the guidelines draft.
> >
> > 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, =
IEEE, or MEF be
> using the latest draft guidelines, or should then use the published =
RFC until
> 6087bis is actually republshed?
> >
> > Thanks,
> > Rob
> >
> >
> > On 15/11/2017 10:14, Martin Bjorklund wrote:
> >> Hi,
> >>
> >> There was a proposal in the meeting today to have the guidelines =
for
> >> tree diagrams in a wiki, instead of having them in 6087bis or in =
the
> >> tree diagram document.
> >>
> >> Was the proposal really to have a wiki for just the tree =
guidelines,
> >> or was the proposal to withdraw 6087bis from the process and =
instead
> >> publish all guidelines as a wiki?
> >>
> >> If it is the former, is it really worth it?
> >>
> >> Advantages with a wiki:
> >>
> >>   +  It can be updated more easily
> >>
> >> Some drawbacks:
> >>
> >>   -  It can be updated more easily
> >>      (meaning they are less stable)
> >>
> >>   -  Wikis tend to not be alive after some time, and are not that
> >>      easy to find.  Just try to find the various YANG-related wikis
> >>      we've tried to maintain over the years.
> >>
> >>   -  Links in RFCs also have problems.  Sites are re-orginized etc.
> >>      As an example, the link to the security guidelines template in
> >>      RFC 6087 doesn't work anymore.
> >>
> >>   -  People that are looking for a stable reference will have =
problems
> >>      (I think Rob mentioned that IEEE still refer to RFC 6087 =
(which
> >>      is understandable; that's the published version).
> >>
> >>   -  Who maintains the Wiki, and what are the rules for updating =
it?
> >>
> >>
> >> I suggest we have the tree-related guidelines (actually just a few
> >> sentences) in the tree draft, and since 6087bis already refers to
> >> this document it is not a big problem that guidelines are spread =
out
> >> over several documents that are difficult to find.
> >>
> >>
> >>
> >> /martin
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> .
> >>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> Mahesh Jethanandani
> mjethanandani@gmail.com
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Nov 15 20:35: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 9453D127419 for ; Wed, 15 Nov 2017 20:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.111
X-Spam-Level: 
X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 nQKbGoj-XcD6 for ; Wed, 15 Nov 2017 20:35:45 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0781201F2 for ; Wed, 15 Nov 2017 20:35:45 -0800 (PST)
X-AuditID: c1b4fb2d-f0bff70000001e3d-c6-5a0d159f3ffd
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 87.17.07741.F951D0A5; Thu, 16 Nov 2017 05:35:43 +0100 (CET)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 16 Nov 2017 05:35:42 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ksfFbAJs70z+n6rgUZGkF/HElS31iUv2RtaB44CRvgA=; b=G9g3dQHCK/EhOF66Qg2XO/k9Qx++4N5zKPeImP/cRQQTy/h48KR7x52vNCaStHI/+wfIllvyneF1YlcupjRxZpuVbEXAr8rKknCWN5aI0wF+Rxe2yQbUesBrx2p2qVXzPF+YBr7J72zYuxnaycC4oOa6R0TkdVoVosumbBYMWFM=
Received: from [IPv6:2001:67c:370:128:bc62:6d4e:1967:bfa1] (2001:67c:370:128:bc62:6d4e:1967:bfa1) by DB6PR07MB3429.eurprd07.prod.outlook.com (2603:10a6:6:23::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Thu, 16 Nov 2017 04:35:40 +0000
To: Randy Presuhn , 
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <614c9b33-774a-cbe0-0328-cfc7ad9ac11b@ericsson.com> <02d86058-4ebb-1bf8-0ecc-3ff464664479@alumni.stanford.edu>
From: Balazs Lengyel 
Message-ID: 
Date: Thu, 16 Nov 2017 12:35:18 +0800
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: <02d86058-4ebb-1bf8-0ecc-3ff464664479@alumni.stanford.edu>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [2001:67c:370:128:bc62:6d4e:1967:bfa1]
X-ClientProxiedBy: SG2PR06CA0097.apcprd06.prod.outlook.com (2603:1096:3:14::23) To DB6PR07MB3429.eurprd07.prod.outlook.com (2603:10a6:6:23::20)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e56a6dfb-1d0d-4b68-6a48-08d52cab7eb4
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:DB6PR07MB3429; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3429; 3:DrCKzghnoPV+QrD+hM9yeD9pax2HxtmRpBA69TKBX+K98AD4KSxhHzVwVxtjzp6RrLchr5rbdwq2DvmKSxKoZweO1Xq51ugTZhNgjBFbDoW5ZVLiYA1eTC5pI07oN8lUeNU0LBsCPgXUykI97+LjqqPvftDnlLV8sJ7kROz++u9hqIFC0RxAsm/Z0WS0D2EhPJiMQdx5T2zOtYCHEf9kHJafB+3uTSglpGNTeYnnxovqwfpxBA2B9IXtj61Z0Kr7; 25:3eDZVZHRJ5x4GfTPzfSxxANrn15/1nzGkWxbUzR7tXKAj4vNGCW25z2oTZ8YRDoLbz1J1/Dzabsy8Z465g0jdyY64zL3snC9+1AoRLz4mroZc1T2PxcWqshFx6s55HJRAx2e5eambkBTLVNKbjspsQwKkUD7cwhAiVGa+BSenCiBGvQS/TORPdtfMjenIPY5/r+of02HlVfvu8O/0HOaLlLPyE8LTATb5mWXqMQwPgrl7EynoAVmhfzU9ob0QpQkgiOZ9wd6TUnQhrHc0gdH8PT/r0/1cPeiH2knuG9DDjiFjEXUvv6SLwTidg0nod23M0Qv6DHVOAvZCOY7HWrufQ==; 31:m/C33TmbhWYSD//11MB0q5cRnehM2ZGVUlqSS+phe9HLZad8EcSddTfEgz9/1MjLMBylIaQOqJIT/XzlMWsTVzM3Ep+DnRlJM/4StNGVOaEPEUrkjiQvrlpBD1cjoryoIfgY4jOl6f1vXOsolZnnV3Z7TCjXHnv/hRJWax4j/i7IZSErjYOobhwnGy1G2XPf606oyeGEiw7e8GYG8RMAXwluGs3sGOL3c0B/y3sfQy4=
X-MS-TrafficTypeDiagnostic: DB6PR07MB3429:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3429; 20:Jl9gl7K0abY5RoF0IUhYkynXtCbtzNF9vZqZ66RTnsmyny/z4sxnjUiCAXaHb9DrBLELydsfCuku2bv261t6l6P6clLOzpWh3uoxlmIsAr5d3VLlotovJcbEvwptkp+alcPpKRapeKevlkyfKM79THPZ45QswQvZNstaCHOTtE/81wk5bFEDF7TZXhptxXmgQldmaVFrE20RUR9I/1phv4g77iFMTFuqICrqk+1dtBb2ZU2YPPHHKyCaZGdQ17bc3jCmRlFGWj9GjHRNBkUTYVrC++eQ5RuqAxJrQMI+tc6oA5OHXLgy0YBEWqSycNtZflYB9T/DSayiZEX3x2kGnY2Zr0ywCYpLVTj55KlMz7k0K+8gO0oOLDwGKZSmpaXO9OjMbxm25O2vyF9A2AV4wcoosSGOuYiITQpGBBa1Ianxj+FfCc11AhBdmRtRygWJMSjvCZ4pCzcVk7k8TMB/wRqkODFs7r6YpInoviMFn87GDKzXSjMPa+K7LfjfeoPG; 4:RsdFe/PAXrBXQvnXFL19ZgqffWSk8JyEstt2Qv6S3zDB2TnbPqY9S1txqOZSjrhn8fITKo0vyBNhHs0GAu60b3rEDIaADXbRHV4KCEvggUM3MXsd5UI6/tabKOuZ59u+THtBDKOBq7j/4e5Y3e0Gyqji7/WS2RjzTaUQNVlPZUhl8F38lXSkN99wjaMkRjZ1i2Y64cCitaEUaEHW9Yzc9B+XI/BexGS+5RZwzgBSDnLdq4xEeefdjKObErR4Sd4oaXX4dZnXXcPJ331+QjhTO2MXgEReGmakox9a+IljgiCPvYSBzlPCaWjwbB4RxxVB5vvSkyQz/Ge60BflY+dNY7fFd+IDNgXva8ww4FJluQM=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(3231022)(93006095)(93001095)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR07MB3429; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR07MB3429; 
X-Forefront-PRVS: 0493852DA9
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39860400002)(252514010)(199003)(24454002)(189002)(377424004)(966005)(106356001)(65806001)(4001150100001)(6246003)(81156014)(316002)(81166006)(58126008)(33646002)(230783001)(93886005)(8676002)(478600001)(86362001)(105586002)(25786009)(47776003)(31696002)(65956001)(53546010)(6486002)(36756003)(50986999)(67846002)(54356999)(101416001)(64126003)(76176999)(7736002)(50466002)(83506002)(2906002)(6116002)(2870700001)(97736004)(23676003)(2171002)(8936002)(6306002)(2950100002)(68736007)(53936002)(6666003)(15650500001)(229853002)(65826007)(31686004)(1706002)(5660300001)(305945005)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3429; H:[IPv6:2001:67c:370:128:bc62:6d4e:1967:bfa1]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3TUIzNDI5OzIzOjFGZWVKVEZNUCtCYSt2R2NsME1ibUh4UGxh?= =?utf-8?B?SnQyN25EVkd3N0kwUFB6d1NkQVM1d29pNmRxMVJEbklDQlFUS3dPcWJmU0lZ?= =?utf-8?B?MzJMcDB1NkkzN2FTZ2pxVEhKYWFBWUZSTFZpa1FYaG5yQWx0OVNlQVZyYUZV?= =?utf-8?B?OVYvQjBKYTY2TUt1a1FQUWV2cWwxaTRPR0NQaEFBK3Rqa0FOTSs3LzY1NTNj?= =?utf-8?B?WmsxbXdXdW1UczBTeEs4Z2RuOHZ1MUhyWUxyY1NNSVlrdFpCT1Z6YVI0YUo1?= =?utf-8?B?WmNIYXJDbDNSeG1mU3RSQ0tVNWVFODRRNEN3LzlTRmt3dUdHeGtLZHo1MG43?= =?utf-8?B?SDgwWFM0RGpGNkRTMUxNVnEyU3lnSVFlc0Q4ZUppWkJ2a2hrMUpUZXczN1Fl?= =?utf-8?B?Z2g3R29odFZ1SEZtdjg1MGt0NVgzZEVPcTZOUFBhTG5RZkRkczFTS2c0TU5l?= =?utf-8?B?THZQbVRQQnh1WUlWT2pnQmUxZG5IOUpnUDdPZU1hejd1am96N3lpeXhKcWxN?= =?utf-8?B?YnRhTmRpTm9IejJoTGtqamZ2Z01FcTJQYWdFMHJrM3o2WnVPV0FCaG9aanJD?= =?utf-8?B?VktoZC9RQUpGcHN4QTVDVFVBZ3VFWXB5WGkrL3VTVnpWcXhsOWpobjhJMEp6?= =?utf-8?B?b3dYSHozRUgyL2ZmY0hkcUZvaERxb3JlTnJRb0tucjAwdGVsaVBGcGdzMUx1?= =?utf-8?B?NitDMFpkYVVweHBxaTN1ZytrdVcxT24yQURONFJmaWwra1lYTlI0MmZ5NkJJ?= =?utf-8?B?N2RaMDVtWHdwMFJ5cjZEclBiTGV4OVNPMHBxS3lNaHQ0UkM5UG84YWtONzJh?= =?utf-8?B?eEk5TVdsaTEzbk0xZ1Vla01MRm9kd3E3MU9tUjJ3UEhKRFpqM2hpYUUvNk9s?= =?utf-8?B?bUtrS1hCZ3VWMjl1S3k3ZmxKNXMzMGErcVZlLzlNL25TS0E3S0J4RDJlTDNW?= =?utf-8?B?Q2lFekhYWVJsbEVENFhialYzK285OWgzdHZnTEU4d3BTcy9KZDJ5VmUxMmNh?= =?utf-8?B?WXpLSzlmVU5Pa0lCRzBxQjlyRHdUYUdpVjN4ZVFEUWx4Z3JhTjMycHRiVFZE?= =?utf-8?B?anM3Ymo3N1RjM3V1WjZ5dkZRUjkwTlFkeEk4TlYwQWVuT2I3VkhQbVE3Vk1a?= =?utf-8?B?Sy9nTlBJR3VzT0NlcTRjUTlvbzhlaXZuVERBaFZURHNuZFlrMWhTbTV5VDg3?= =?utf-8?B?WGRTTHgrZGVsaG16Z2JYeW03eVZsODdVRGxwb2JpVjE5YU1rY1RrZFpxYkNs?= =?utf-8?B?WnF5OTY3VVVpTFJ3V3ZtN1k0MVJvV0dpd3FxVFdvWDFUSnVQekxndXF0RHFn?= =?utf-8?B?emR1SDJmUUFLM3Nad3EwWUEyWjFnWStod1o5RlZuMFNXdmJ5Z1gxMi9lYW9F?= =?utf-8?B?ZURGam1xdEd6VG05SXc0NDZNUVN1NXd6bUs3MEdEWFJrM0FCbnVzZzlweUY5?= =?utf-8?B?cHBBcGVqblhjbDVyVXBnZ3AzS1hXTTEwZWFBU1lNSzU2bHB0R2JFTUx5TTFT?= =?utf-8?B?NnZsM2xsUFNTT1Q2V2wxZCs3dk8zRDMxaXZVT1hDS3lQNytZU3JQR0lMNDZB?= =?utf-8?B?R1k1VE5zZzBKOU80NzFPcUM5NHRiQmkydEN1V09LUFYyYzg2TkwxdjJOajdY?= =?utf-8?B?eVQ1ZzF4Z0w2QW0rRTM3UzFteU03Z0V1RXNzdzB1V3VPSVRNZTcwdzMvSmVR?= =?utf-8?B?ckI5WFU1cElyWG90QVNNL3F6b0NlakJOVU0wbnRLSElyZTI1eFcrUUVPVGFj?= =?utf-8?B?MVpFQ04wWmhKb0RiOW5ldWx2VGJEUVNwZnRCL29HaTZDWjNScklqTUJUT1hD?= =?utf-8?B?UlZ3UWZmWUUrcXhsbHBVNWNQWHRwODBGU25WdlRzVU41c25RUGxuKzlPU1NP?= =?utf-8?B?cXhGQ1FzN05zaVppSkcrUkNMaHRtak9tTFhLSzZTVDE5NjVZOW96VWJ6T0RC?= =?utf-8?B?RW9HVkZ1YWZRPT0=?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3429; 6:i3BSEUj7ltqMytj09ZjmSNuEuvvjIRY+3i171MIrUPcWOgAfM6miXF66TiR/4TxmMf9HS1WTqrSkMKvpH5LYt6IapSqVHciCn2ezCPUDPSZPjhjfgZPuvcQGV4ZmGq3C/gZrXh7moWDi4QkSJeylZkS2C1jlz2Y3JtH7GNFBSILt5HTPxQnSK/3etlvMxOmKg3EhdGtXQNTmOAlA6sLyyKi42RQVgDFcitDtwaN2zC5Khsoyei0wpb8nzkPsr+jEsQWWUg4FPEf0UY7Ev+Us1UlUVx3+FYIp1VnYJr6ht8VBKSyaZp+wkpJmZ62s5WEBdypqYzoFLmM4PLXsSBkvlg+ofLEfnohkINMOEcz7H98=; 5:0fz5EncYpezHReJbfkVWIJLx8EfgAjxd9SYzKL3p4nzyYuMO8RGEb0FsYxBOpbDIOuibjA5dDcHvfWbR8f38Ixsql0pPrx8j9a7B7D8D2410F2bxvYrBmjEXcC/1K0Ty/DnFk7n02qmtu44UEWSEtxKMAtX7g8a6iU3P6/Fdh9E=; 24:brajd3rQfMJ9pbhErYnibye42hmJATcYwyYfmpw+4Y9ZsgDZC6JmvxDlsoja+hxO9fRJIYhUQYm2c7WkCUxk2T14smoRotc4KYzxtc3kdUM=; 7:+c5vrvfeGbLliC4mm8tGIP7L+11q5n0rUKyAFsKMGbl7tRHtjM1upVKTubTcDJYa5NW6X5rSxhBZoLoWpYGAr4BEvASzoGT/9tUORmPdYS4CxDSRKFf1A6f6GqfuKUGRz8qwviA3H2Kvwf348R9spI1aBKHnAMNHYFY7RIpt2thq/NKfLXKEECx2k5tzcZ1/4yPJxKywCiiLQS20hio77LbA38ozQ7uRvQGuD4t+GxEVfKfW6OpMXgo1hWvx5bZn
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2017 04:35:40.8482 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e56a6dfb-1d0d-4b68-6a48-08d52cab7eb4
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3429
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42KZGbHdTHe+KG+UwfH3yhbzLzayWvSdX8fu wOTx8fAlFo8lS34yBTBFcdmkpOZklqUW6dslcGUc+rGMuWAmb8XfL39YGxjXcnUxcnJICJhI zLswgQXEFhI4zChxeQlfFyMXkH2CUWLP2vVsIA6LQC+zxIEbq5ghMruYJFZdeswE0iIs4Cmx r/MPK4gtIuAhsaT5KytE0XEmieO9L9hBEmwCRhJT+8+D7eAVsJfYeO4qWJxFQFXi/tZPYINE BWIkJj64yAhRIyhxcuYTsHpOAXeJ2edesYHYzAIWEjPnn2eEsOUlmrfOZoawxSVuPZnPBPGP hUR7Vx/YpRICkxklLq3ZyQbxnIbEwwt/WSGKZCWOnp3DAmH7Suw6+YgNomEmo8TSzzdYIJwG dok7i+4xQ1RpSfRe/ALWzSgQJ7FzzUJWiKIl7BI7Ny8HuokDyMmWmLUhHKLeW6L92WV2iJor rBITXv6DGiQjMWP5LajEYjaJlx1djBMYtWch+XsWkl9nIfl1FpJfFzCyrGIULU4tLs5NNzLW Sy3KTC4uzs/Ty0st2cQITB8Ht/zW3cG4+rXjIUYBDkYlHt4TDLxRQqyJZcWVuYcYJTiYlUR4 IxfyRAnxpiRWVqUW5ccXleakFh9ilOZgURLn9RDhjhISSE8sSc1OTS1ILYLJMnFwSjUwCvFE J+/9JtEW+Dwr7ehjadUWT9ZE9iPZqSviPxRVmj8/djS0TjroaUXio9blPxM8Ns0wrAn7429x 7EZzw5vDLM8/+/56dnOR6venkj+3PPkQtjd4tWwNX+C0hUd83nsduWVi5Nyw7t6nc994WXPS NEL69v5zk4ix4931y/WZgNql7nNmPoFKSizFGYmGWsxFxYkAMoKIKRsDAAA=
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 04:35:48 -0000

Hello Randy,
I agree that the problem can not be eliminated, however it is still a 
nasty problem which we should try to avoid whenever possible. So if we 
can avoid it 75% of the time I am happy. (I don't often _configure_ 
firmware, so I am less worried about that :-)  )
regards Balazs


On 2017-11-16 03:07, Randy Presuhn wrote:
> Hi -
>
> On 11/15/2017 2:02 AM, Balazs Lengyel wrote:
>> While a server may correctly support multiple versions, the human 
>> operator on the CLI has a 99% chance of mixing up which version he is 
>> using. Humans will not check every type and leaf  to check that they 
>> remember the little differences between model versions. It is a 
>> recipe for human mistakes. According to some statistics 50% of 
>> downtime is caused by human errors, so we should not provide the 
>> operator with a gun to shoot himself. Ericsson has a rule never to 
>> have multiple versions of the same module on a network node.
>
> Does this mean that they require all line cards in a chassis to have
> exactly the same firmware revision level?  If so, when a card with a
> newer firmware revision level is swapped in, does that require all other
> cards of the same type in that chassis to also be replaced concurrently?
> Sounds like even a fairly routine/minor update/repair would effectively
> result in a system outage.
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Wed Nov 15 22:48: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 D31AD129541 for ; Wed, 15 Nov 2017 22:48:29 -0800 (PST)
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 gU_LAO8OY6nb for ; Wed, 15 Nov 2017 22:48:27 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2BE1294E8 for ; Wed, 15 Nov 2017 22:48:27 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id 3F2DC645BF for ; Thu, 16 Nov 2017 07:48:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510814905; bh=N5jBDyJBUoIejsWCbYkA7ega9T/o1U8PJcFpkowbAl0=; h=From:To:Date; b=LyY9uYI8v3lIRKV0lTzN2SBopp9q/xOKy8cQkjCH2qnStFKvNzYNbPywMXhsr1BV+ C8KUZsOWUPM+Y5z/n4v4PPMCBJnTAiJZLqrtxBBLnAL/vEAoQR0O1p9sxKkClCmlBj gbbAN1eAtZmamJDq58LSqY7DcIvWd/EzZF7QReGk=
Message-ID: <1510814973.7785.14.camel@nic.cz>
From: Ladislav Lhotka 
To: NETMOD WG 
Date: Thu, 16 Nov 2017 14:49:33 +0800
In-Reply-To: 
References: <55fcf67e-6e27-4bd9-cdd6-62f3fbe11bff@ericsson.com> <20171115.121716.454716475078719607.mbj@tail-f.com> <1510751195.21877.25.camel@nic.cz> <20171115.142017.1071562845381546650.mbj@tail-f.com> <7f716912-3dcb-93cd-ed8e-9a2a168e91a7@ericsson.com> <8760ab9dyb.fsf@nic.cz> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 06:48:30 -0000

On Thu, 2017-11-16 at 12:59 +0800, Balazs Lengyel wrote:
> Hello Lada,
> Yes it is necessary. Just have a look at how Java uses it.  It is formulated: 
> XXX deprecated, use YYY instead.

But the data, at the end of the day, have to correspond to what is implemented
in the device. So even if an IETF WG decides to roll out a shiny new version of
module X, a vendor may still want to keep the old version, possibly forever, and
then the deprecated status information from the old version of X may be false
alarm. It would seem more appropriate for the vendor to do this kind of
signalling before a new release is coming.

On the other hand, it would IMO be too much to require that a node can be
removed only after being deprecated.

Lada

> We want to give client OSS implementers an advance warning that XXX will be
> removed, they better start planing to use YYY instead. This revision is still
> compatible, it still supports XXX, but the next one won't. This way for OSS
> the migration from XXX to YYY is less painful.
> regards Balazs
> 
> On 2017-11-16 10:04, Ladislav Lhotka wrote:
> > > BALAZS: You still need at leaast deprecated: my proposal
> > > o  "deprecated" schema nodes MUST still work as defined by the YANG
> > > module. 
> > >        The deprecated status serves only as a a warning that the schema
> > > node 
> > >        will be removed or obsoleted in the future."
> > 
> > But is this really necessary? As long as the new (incompatible) version
> > doesn't get pulled in automatically, implementors needn't care too
> > much. And if they decide to upgrade to the new version, they have to
> > check the differences anyway - as you said, they may not be in the
> > schema.
> > 
> > Lada
> > 
> 
>  
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Nov 15 22:56: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 044921294F0 for ; Wed, 15 Nov 2017 22:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_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 DA-te40RGl4Z for ; Wed, 15 Nov 2017 22:56:40 -0800 (PST)
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 82BAF1294B3 for ; Wed, 15 Nov 2017 22:56:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60219; q=dns/txt; s=iport; t=1510815400; x=1512025000; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=MJ/h5S+z2CpDkQFNMvMxtSWGQ+u8skTCb2y3j6oewjU=; b=EzfmdIhCD/Cw18XVO3iIddtJ4+PPq4+yU3gJ72pyWLU3SjMijTMrdOMn BpKlPCHcGbyrMxRqqi7xKv70W6Gs3Gyjb8FH9WdRgi3qxaCNZkSFpW5nh qqymTCvMVJl8o7Gf2GgWF2cyyjJK/CpuKZrlWELWapa6rdrkD9AlIHIq5 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAADlNQ1a/5pdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcmRuJ4N/ih+PIIF9ll4QgX4DChgBCoRJTwKFET8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHgEBAQECAQEBGAkERwsFCwkCEgYgAQYDAgInHwMOBg0GAgEBF4oBC?= =?us-ascii?q?BCLXZ1ogW06JoptAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDNIIHgVWBaAEpgXS?= =?us-ascii?q?BDYRlARIBCUyCX4JjBYo0B4c2gROGGokZlQaCFYF7hA+DYIdFjjqHdIE5HzhCQ?= =?us-ascii?q?XE0IQgdFUmCZIIjgkk0Noh3gjUBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200";  d="scan'208,217";a="319423724"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 06:56:37 +0000
Received: from [10.24.103.1] ([10.24.103.1]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAG6uZYg010741; Thu, 16 Nov 2017 06:56:36 GMT
To: Andy Bierman 
Cc: Vladimir Vassilev , "netmod@ietf.org" 
References:  <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com>   
From: Robert Wilton 
Message-ID: 
Date: Thu, 16 Nov 2017 14:56:35 +0800
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="------------3D40FAD797C37C0085B7F86D"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Nov 2017 06:56:45 -0000

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

Hi Andy,


On 16/11/2017 10:42, Andy Bierman wrote:
>
>
> On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton  > wrote:
>
>     Hi Andy,
>
>
>     On 16/11/2017 02:29, Andy Bierman wrote:
>>     Hi,
>>
>>     The per-datastore feature aspect of NMDA is a new and significant
>>     change to YANG.
>>
>>>         |  |  +--ro feature* [name]
>>>         |  |  |  +--ro name yang:yang-identifier
>>>         |  |  |  +--ro not-implemented-in*
>>>         |  |  |              -> /yang-library/datastore/name
>>>
>>
>>     YANG does not define feature conformance at this granularity.
>>     I strongly object to this change to YANG conformance.
>>     A server can only advertise a YANG feature if it implemented on
>>     the entire server.
>>
>>     This extra complexity is not present on the openconfig solution
>>     or requirements.
>     In terms of comparison, it definitely is:
>     - you can have different features for the config and state trees
>     (e.g. "router-id" feature in RFC 8022).
>     - sometimes the conventions are not followed completely
>     consistently, e.g. different types, or semantics between config
>     and state.
>     - sometimes the structures differ between config and state.
>
>     So, the problem comparing between config and state is not easier
>     in either the IETF split tree or OpenConfig solutions.
>
>>     Comparing any datastore to  is much more complex
>>     (any may not be possible)
>>     if the features are different for a given module.
>     You can always compare (except deviations in operational).  If a
>     feature is enabled on any configuration datastore then it must
>     also be enabled on operational.
>
>
> This is not apparent from the text.

I agree that this can be better explained, either in YANG library, 
and/or in the datastores architecture.  This is implied by the datastore 
draft today, but there is no harm to make it a bit more explicit.


> The draft-02 library is very out of date at this point.

Yes, sorry.  The -02 is out of date with the latest proposal which was 
discussed/developed after the cutoff date.   Functionality wise they are 
intended to be capable of expressing the same things, but the proposal 
in this original thread is intended to be simpler.


>
> I only care about restricting the conventional datastores,  
> and .
> It will be a massive client rewrite if the client cannot compare 
>  to 
> with 1 schema tree.

 also counts as a conventional datastore so the list of 
modules, features, deviations MUST be the same as for , 
, and .

But yes, I entirely agree that it must be possible to compare from 
 to  in an easy way.  Arguably that is one of the 
key aspects of this work.


>
> If the updated draft reflects the feature-in-operational requirement 
> above then
> I have no objections to the proposed YANG library functionality.

OK, we will ensure that this is clearly documented.


>
> I am still concerned about per-datastore deviations.
> IMO, the server MUST implement the same deviations in these special 
> datastores.

For a normal server YANG deviation "e.g. changing types, or value space, 
etc" then the same deviations MUST be applied to ALL datastores.


> If that cannot be done, the operational node will not be present. 
> Another leaf node
> (like admin-state/oper-state) needs to be used instead.

Yes, entirely agree.

The only type of per datastore deviation is to remove a node. Further, 
if that deviation is applied to one of the conventional datastores then 
it must apply to all of the conventional datastores.


>
> If the server does implement per-datastore deviations,
> clients may not work (if they use the conventional datastore schema 
> tree for ).
> The same thing happens if the client ignores plain-old-deviations now,
> so this is not a big deal.

I think that I agree.


>
>
>
>
>     E.g.  take "router-id" feature from RFC8022bis (that was also
>     defined in RFC8022).
>
>     This feature can be enabled:
>     (i) everywhere (i.e.  +  +
>     ), or
>     (ii)  + , or
>     (iii)  + , or
>     (iv)  only, or
>     (v) or in none of them.
>
>
>
> I still think the WG needs to define YANG conformance for datastores,
> The question "what datastores does server implementation X support for 
> module foo?" is covered.
> The question "what datastores MUST, SHOULD, MAY a compliant server 
> implementation
> support for module foo?" is totally ignored.

The RESTCONF NMDA draft states:

    An NMDA-compliant RESTCONF server MUST support the operational state
    datastore.  Such a server identifies that it supports NMDA both by
    implementing the {+restconf}/ds/ietf-datastores:operational resource,
    and by implementing at least revision 201X-XX-XX of the
    "ietf-yang-library" module, as specified in
    [I-D.nmdsdt-netconf-rfc7895bis].


The NETCONF NMDA protocol draft should have a similar statement.

Do you think that this conformance statement is insufficient?

Or is your concern about whether modules are expected to be implemented?

Thanks,
Rob


>
>
>     Hence,  always contains a superset of the nodes.
>
>>
>>     I do not see how  can be true superset of the
>>     conventional datastores
>>     if the features are different.
>
>     Because of the statement above.
>
>     Thanks,
>     Rob
>
>
>
>
> Andy
>
>>
>>
>>     Andy
>>
>>
>>     On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton >     > wrote:
>>
>>         I don't think that this is really a good idea.  You would end
>>         up returning server metadata in addition to the configuration.
>>
>>         I still think that the YANG library proposal is the best
>>         solution.
>>
>>         Thanks,
>>         Rob
>>
>>
>>         On 16/11/2017 01:21, Vladimir Vassilev wrote:
>>>         Hello,
>>>
>>>         I have a proposal based on  that provides an
>>>         elegant solution to consider as a 3rd option.  It is based
>>>         on keeping exactly the same model as in RFC 7895 and using
>>>          RPC to retrieve datastore specific yang-library
>>>         instance data in a similar way one would use  to
>>>         retrieve the datastore contents. In addition a top level
>>>         config=false container e.g. /datastores with list of
>>>         supported datastores that does not need to be part of the
>>>         yang-library module:
>>>
>>>         module: ietf-datastores
>>>         +--ro datastores
>>>         |  +--ro datastore* [name]
>>>         |     +--ro name          identityref
>>>
>>>         Vladimir
>>>
>>>         On 11/09/2017 05:51 PM, Robert Wilton wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         Given some of the feedback related to the complexity of the
>>>>         YANG library bis structure, we have come up with two other
>>>>         possible structures for the YANG library data:
>>>>
>>>>         (1) A simplified structure to make YANG library meet the
>>>>         NMDA requirements, but that is closer to the existing YANG
>>>>         library structure, and arguably simpler.
>>>>         (2) An enhanced version of the structure (1) above, that is
>>>>         also extended to allow the structure to be reused for
>>>>         schema-mount via an augmentation.
>>>>
>>>>         For reference, at the end of this email, I have also
>>>>         included the tree diagram of the existing YANG library, and
>>>>         the current YANG library bis draft
>>>>         (draft-ietf-netconf-rfc7895bis-02) version.
>>>>
>>>>         Considering the two new YANG library structures:
>>>>
>>>>         ------------------------
>>>>
>>>>         *(1) A simplified structure to make YANG library meet the
>>>>         NMDA requirements, but that is closer to the existing YANG
>>>>         library structure.*
>>>>
>>>>         The main changes are:
>>>>         (i) Split "implemented modules" and "import-only-modules"
>>>>         into two separate lists, making the most important list
>>>>         (i.e. implemented modules) keyed by module name only and
>>>>         hence easier to reference.
>>>>         (ii) Assume modules are implemented in all datastores by
>>>>         default (with a "not-implemented-in" leaflist of datastores
>>>>         that a module is not implemented in).
>>>>         (iii) Assume that features are implemented in all
>>>>         datastores by default (with a "not-implemented-in" leaflist
>>>>         of datastores that a feature is not implemented in).
>>>>         (iv) Deleted module-sets.
>>>>         (v) Datastores are now just a list of supported datastores
>>>>         (that could potentially be extended with further per
>>>>         datastore properties in future).
>>>>
>>>>         Manually generated tree output for proposed YANG library:
>>>>
>>>>         module: ietf-yang-library
>>>>          +--ro yang-library
>>>>             +--ro modules
>>>>             |  +--ro module* [name]
>>>>             |  |  +--ro name yang:yang-identifier
>>>>             |  |  +--ro revision? revision-identifier
>>>>             |  |  +--ro schema? inet:uri
>>>>             |  |  +--ro namespace inet:uri
>>>>             |  |  +--ro submodule* [name]
>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>             |  |  |  +--ro revision? yang:yang-identifier
>>>>             |  |  |  +--ro schema? inet:uri
>>>>             |  |  +--ro not-implemented-in*
>>>>             |  |  |              -> /yang-library/datastore/name
>>>>             |  |  +--ro feature* [name]
>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>             |  |  |  +--ro not-implemented-in*
>>>>             |  |  |              -> /yang-library/datastore/name
>>>>             |  |  +--ro deviation*
>>>>             |  |                 -> ../name
>>>>             |  |
>>>>             |  +--ro import-only-module* [name revision]
>>>>             |     +--ro name yang:yang-identifier
>>>>             |     +--ro revision            union
>>>>             |     +--ro schema?             inet:uri
>>>>             |     +--ro namespace           inet:uri
>>>>             |     +--ro submodule* [name]
>>>>             |        +--ro name yang:yang-identifier
>>>>             |        +--ro revision yang:revision-identifier
>>>>             |        +--ro schema? inet:uri
>>>>             +--ro datastore* [name] // Allows future per datastore
>>>>         properties.
>>>>             |  +--ro name identityref
>>>>             +--ro checksum       string
>>>>
>>>>         ------------------------------
>>>>
>>>>         *(2) An enhanced version of the structure (1) above, that
>>>>         is extended to allow the structure to be reused for
>>>>         schema-mount via an augmentation.*
>>>>
>>>>         This is similar to the structure above, except that the
>>>>         "the set of modules" is contained in a list of named schema
>>>>         (e.g. similar to the schema mount draft), allowing this
>>>>         structure to be re-used for schema mount.
>>>>
>>>>         Schema mount would be expected to augment yang-library to
>>>>         add in the additional schema mount information.  In the
>>>>         tree diagram, I have shown the schema-mount mount-point
>>>>         augmentation, but not including namespaces yet.
>>>>
>>>>         Every server would be required to provide at least one
>>>>         schema in the schema list, and the primary schema for the
>>>>         device would always be given the name "primary".
>>>>
>>>>         module: ietf-yang-library
>>>>          +--ro yang-library
>>>>             +--ro schema* [name]
>>>>             |  +--ro name string
>>>>             |  +--ro checksum string
>>>>             |  +--ro module* [name]
>>>>             |  |  +--ro name yang:yang-identifier
>>>>             |  |  +--ro revision? yang:revision-identifier
>>>>             |  |  +--ro schema? inet:uri
>>>>             |  |  +--ro namespace inet:uri
>>>>             |  |  +--ro submodule* [name]
>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>             |  |  |  +--ro revision? yang:yang-identifier
>>>>             |  |  |  +--ro schema? inet:uri
>>>>             |  |  +--ro not-implemented-in*
>>>>             |  |  |              -> /yang-library/datastore/name
>>>>             |  |  +--ro feature* [name]
>>>>             |  |  |  +--ro name yang:yang-identifier
>>>>             |  |  |  +--ro not-implemented-in*
>>>>             |  |  |              -> /yang-library/datastore/name
>>>>             |  |  +--ro deviation*
>>>>             |  |  |              -> ../name
>>>>             |  |  +- schema-mount:mount-point* [label]
>>>>             |  |     +--ro label         yang:yang-identifier
>>>>             |  |     +--ro config?       boolean
>>>>             |  |     +--ro (schema-ref)
>>>>             |  |        +--:(inline)
>>>>             |  |        |  +--ro inline?       empty
>>>>             |  | +--:(use-schema)
>>>>             |  |           +--ro use-schema* [name]
>>>>             |  |              +--ro name
>>>>             |  |              | -> /yang-library/schema/name
>>>>             |  |              +--ro parent-reference* yang:xpath1.0
>>>>             |  |
>>>>             |  +--ro import-only-module* [name revision]
>>>>             |     +--ro name yang:yang-identifier
>>>>             |     +--ro revision            union
>>>>             |     +--ro schema?             inet:uri
>>>>             |     +--ro namespace           inet:uri
>>>>             |     +--ro submodule* [name]
>>>>             |        +--ro name yang:yang-identifier
>>>>             |        +--ro revision yang:revision-identifier
>>>>             |        +--ro schema? inet:uri
>>>>             +--ro datastore* [name] // Allows future per datastore
>>>>         properties.
>>>>             |  +--ro name identityref
>>>>             +--ro checksum       string
>>>>
>>>>         Please can you provide comments on these structures, in
>>>>         particular:
>>>>
>>>>         Is this version better (i.e. simpler) that the version
>>>>         currently in draft-ietf-netconf-rfc7895bis-02 (below)?
>>>>
>>>>         Should we try and make the structure extensible for
>>>>         schema-mount via augmentation (i.e. version (2)), or is it
>>>>         better that schema-mount has its own separate subtree?
>>>>
>>>>         For reference only I have included the existing YANG
>>>>         library and YANG library bis draft tree diagrams.
>>>>
>>>>         Thanks,
>>>>         Rob
>>>>
>>>>
>>>>         -----------------------------
>>>>
>>>>         *** FOR REFERENCE ONLY ***
>>>>
>>>>         (3)  The current YANG library structure in YANG library bis
>>>>         (draft-ietf-netconf-rfc7895bis-02)
>>>>
>>>>             module: ietf-yang-library
>>>>                 +--ro yang-library
>>>>                    +--ro modules
>>>>                    |  +--ro module* [id]
>>>>                    |     +--ro id                  string
>>>>                    |     +--ro name                yang:yang-identifier
>>>>                    |     +--ro revision?           revision-identifier
>>>>                    |     +--ro schema?             inet:uri
>>>>                    |     +--ro namespace           inet:uri
>>>>                    |     +--ro feature*            yang:yang-identifier
>>>>                    |     +--ro deviation* [module]
>>>>                    |     |  +--ro module    -> ../../id
>>>>                    |     +--ro conformance-type    enumeration
>>>>                    |     +--ro submodule* [name]
>>>>                    |        +--ro name        yang:yang-identifier
>>>>                    |        +--ro revision?   revision-identifier
>>>>                    |        +--ro schema?     inet:uri
>>>>                    +--ro module-sets
>>>>                    |  +--ro module-set* [id]
>>>>                    |     +--ro id        string
>>>>                    |     +--ro module*   -> ../../../modules/module/id
>>>>                    +--ro datastores
>>>>                    |  +--ro datastore* [name]
>>>>                    |     +--ro name          identityref
>>>>                    |     +--ro module-set
>>>>                    |             -> ../../../module-sets/module-set/id
>>>>                    +--ro checksum       string
>>>>
>>>>         -----------------------------
>>>>
>>>>         *** FOR REFERENCE ONLY ***
>>>>
>>>>         (4)  The current YANG library structure (RFC 7895)
>>>>
>>>>                +--ro modules-state
>>>>                   +--ro module-set-id    string
>>>>                   +--ro module* [name revision]
>>>>                      +--ro name                yang:yang-identifier
>>>>                      +--ro revision            union
>>>>                      +--ro schema?             inet:uri
>>>>                      +--ro namespace           inet:uri
>>>>                      +--ro feature*            yang:yang-identifier
>>>>                      +--ro deviation* [name revision]
>>>>                      |  +--ro name        yang:yang-identifier
>>>>                      |  +--ro revision    union
>>>>                      +--ro conformance-type    enumeration
>>>>                      +--ro submodule* [name revision]
>>>>                         +--ro name        yang:yang-identifier
>>>>                         +--ro revision    union
>>>>                         +--ro schema?     inet:uri
>>>>
>>>>
>>>>
>>>>         _______________________________________________
>>>>         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
>>         
>>
>>
>
>


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


  
    
  
  
    
Hi Andy,

    

    

    
On 16/11/2017 10:42, Andy Bierman
      wrote:

    

    

      
      


        


          
On Wed, Nov 15, 2017 at 4:53 PM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                
Hi Andy,

                

                

                
On
                  16/11/2017 02:29, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
The per-datastore feature aspect of NMDA is a
                      new and significant change to YANG.

                    


                    

                    

                      

                        
    |  |  +--ro feature* [name]

                              |  |  |  +--ro name       
                            yang:yang-identifier

                              |  |  |  +--ro
                            not-implemented-in*

                              |  |  |              ->
                            /yang-library/datastore/name

                      

                    

                    


                    

                    
YANG does not define feature conformance at
                      this granularity.

                    
I strongly object to this change to YANG
                      conformance.

                    
A server can only advertise a YANG feature if
                      it implemented on the entire server.

                  

                

                

                  

                    


                    

                    
This extra complexity is not present on the
                      openconfig solution or requirements.

                  

                

                In terms of comparison, it definitely is:

                - you can have different features for the config and
                state trees (e.g. "router-id" feature in RFC 8022).

                - sometimes the conventions are not followed completely
                consistently, e.g. different types, or semantics between
                config and state.

                - sometimes the structures differ between config and
                state.

                

                So, the problem comparing between config and state is
                not easier in either the IETF split tree or OpenConfig
                solutions. 

                

                

                  

                    
Comparing any datastore to <operational>
                      is much more complex (any may not be possible)

                    
if the features are different for a given
                      module.

                  

                

                You can always compare (except deviations in
                operational).  If a feature is enabled on any
                configuration datastore then it must also be enabled on
                operational.

                

              

            

            


            

            
This is not apparent from the text.

          

        

      

    

    

    I agree that this can be better explained, either in YANG library,
    and/or in the datastores architecture.  This is implied by the
    datastore draft today, but there is no harm to make it a bit more
    explicit.

    

    

    

      

        

          

            
 The draft-02 library is very out of date at this
              point.

          

        

      

    

    

    Yes, sorry.  The -02 is out of date with the latest proposal which
    was discussed/developed after the cutoff date.   Functionality wise
    they are intended to be capable of expressing the same things, but
    the proposal in this original thread is intended to be simpler.

    

    

    

      

        

          

            


            

            
I only care about restricting the conventional
              datastores, <intended> and <operational>.

            
It will be a massive client rewrite if the client
              cannot compare <intended> to <operational>

            
with 1 schema tree.

          

        

      

    

    

    <intended> also counts as a conventional datastore so the list
    of modules, features, deviations MUST be the same as for
    <running>, <startup>, and <candidate>.

    

    But yes, I entirely agree that it must be possible to compare from
    <intended> to <operational> in an easy way.  Arguably
    that is one of the key aspects of this work.

    

    

    

      

        

          

            


            

            
If the updated draft reflects the
              feature-in-operational requirement above then

            
I have no objections to the proposed YANG library
              functionality.  

            

          

        

      

    

    

    OK, we will ensure that this is clearly documented.

    

    

    

      

        

          

            


            

            
I am still concerned about per-datastore deviations.

            
IMO, the server MUST implement the same deviations in
              these special datastores.

          

        

      

    

    

    For a normal server YANG deviation "e.g. changing types, or value
    space, etc" then the same deviations MUST be applied to ALL
    datastores.

    

    

    

      

        

          

            
If that cannot be done, the operational node will not
              be present. Another leaf node

            
(like admin-state/oper-state) needs to be used instead.

          

        

      

    

    

    Yes, entirely agree.

    

    The only type of per datastore deviation is to remove a node. 
    Further, if that deviation is applied to one of the conventional
    datastores then it must apply to all of the conventional datastores.

    

    

    

      

        

          

            


            

            
If the server does implement per-datastore deviations,

            
clients may not work (if they use the conventional
              datastore schema tree for <operational>).

            
The same thing happens if the client ignores
              plain-old-deviations now,

            
so this is not a big deal.

          

        

      

    

    

    I think that I agree.

    

    

    

      

        

          

            


            

            


            

            


            

            


            

            

              
 E.g.  take
                "router-id" feature from RFC8022bis (that was also
                defined in RFC8022).

                

                This feature can be enabled:

                (i) everywhere (i.e. <conventional> +
                <i2rs-ephemeral> + <operational>), or

                (ii) <conventional> + <operational>, or

                (iii) <i2rs-ephemral> + <operational>, or

                (iv) <operational> only, or

                (v) or in none of them.

                

              

            

            


            

            


            

            
I still think the WG needs to define YANG conformance
              for datastores,

            
The question "what datastores does server
              implementation X support for module foo?" is covered.

            
The question "what datastores MUST, SHOULD, MAY a
              compliant server implementation

            
support for module foo?" is totally ignored.

          

        

      

    

    

    The RESTCONF NMDA draft states:

    
   An NMDA-compliant RESTCONF server MUST support the operational state
   datastore.  Such a server identifies that it supports NMDA both by
   implementing the {+restconf}/ds/ietf-datastores:operational resource,
   and by implementing at least revision 201X-XX-XX of the
   "ietf-yang-library" module, as specified in
   [I-D.nmdsdt-netconf-rfc7895bis].

    

    The NETCONF NMDA protocol draft should have a similar statement.

    

    Do you think that this conformance statement is insufficient?

    

    Or is your concern about whether modules are expected to be
    implemented? 

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            


            

            

              
 Hence,
                <operational> always contains a superset of the
                nodes.

                

                

                  

                    


                    

                    
I do not see how <operational> can be
                      true superset of the conventional datastores

                    
if the features are different.

                  

                

                

                Because of the statement above.

                

                Thanks,

                Rob

                

              

            

            


            

            


            

            


            

            
Andy

            
 

            

              

                

                  

                    


                    

                    


                    

                    
Andy

                    


                    

                  

                  


                    
On Wed, Nov 15, 2017 at
                      9:29 AM, Robert Wilton <rwilton@cisco.com>
                      wrote:

                      

                        
 I don't
                          think that this is really a good idea.  You
                          would end up returning server metadata in
                          addition to the configuration.

                          

                          I still think that the YANG library proposal
                          is the best solution.

                          

                          Thanks,

                          Rob

                          

                          

                          
On
                            16/11/2017 01:21, Vladimir Vassilev wrote:

                          

                          
 Hello,

                            

                            I have a proposal based on <get-data>
                            that provides an elegant solution to
                            consider as a 3rd option.  It is based on
                            keeping exactly the same model as in RFC
                            7895 and using <get-data> RPC to
                            retrieve datastore specific yang-library
                            instance data in a similar way one would use
                            <get-data> to retrieve the datastore
                            contents. In addition a top level
                            config=false container e.g. /datastores with
                            list of supported datastores that does not
                            need to be part of the yang-library module:

                            

                            module: ietf-datastores

                            +--ro datastores

                            |  +--ro datastore* [name]

                            |     +--ro name          identityref

                            

                            Vladimir

                            

                            On 11/09/2017 05:51 PM, Robert Wilton wrote:

                            

                              
Hi,

                              
Given some of the feedback related to
                                the complexity of the YANG library bis
                                structure, we have come up with two
                                other possible structures for the YANG
                                library data:

                              
(1) A simplified structure to make YANG
                                library meet the NMDA requirements, but
                                that is closer to the existing YANG
                                library structure, and arguably simpler.

                                (2) An enhanced version of the structure
                                (1) above, that is also extended to
                                allow the structure to be reused for
                                schema-mount via an augmentation.

                              
For reference, at the end of this
                                email, I have also included the tree
                                diagram of the existing YANG library,
                                and the current YANG library bis draft
                                (draft-ietf-netconf-rfc7895bis-02)
                                version.

                              

                              
Considering the two new YANG library
                                structures:

                              

                              
------------------------

                              

                              
(1) A simplified structure to make
                                  YANG library meet the NMDA
                                  requirements, but that is closer to
                                  the existing YANG library structure.

                              
The main changes are:

                                (i) Split "implemented modules" and
                                "import-only-modules" into two separate
                                lists, making the most important list
                                (i.e. implemented modules) keyed by
                                module name only and hence easier to
                                reference.

                                (ii) Assume modules are implemented in
                                all datastores by default (with a
                                "not-implemented-in" leaflist of
                                datastores that a module is not
                                implemented in).

                                (iii) Assume that features are
                                implemented in all datastores by default
                                (with a "not-implemented-in" leaflist of
                                datastores that a feature is not
                                implemented in).

                                (iv) Deleted module-sets.

                                (v) Datastores are now just a list of
                                supported datastores (that could
                                potentially be extended with further per
                                datastore properties in future).

                              

                              
Manually generated tree output for
                                proposed YANG library:

                              
module: ietf-yang-library

                                 +--ro yang-library

                                    +--ro modules

                                    |  +--ro module* [name]

                                    |  |  +--ro name          
                                  yang:yang-identifier

                                    |  |  +--ro revision?     
                                  revision-identifier

                                    |  |  +--ro schema?       
                                  inet:uri

                                    |  |  +--ro namespace     
                                  inet:uri

                                    |  |  +--ro submodule*
                                  [name]

                                    |  |  |  +--ro name       
                                  yang:yang-identifier

                                    |  |  |  +--ro revision?  
                                  yang:yang-identifier

                                    |  |  |  +--ro schema?    
                                  inet:uri

                                    |  |  +--ro
                                  not-implemented-in*

                                    |  |  |              ->
                                  /yang-library/datastore/name

                                    |  |  +--ro feature* [name]

                                    |  |  |  +--ro name       
                                  yang:yang-identifier

                                    |  |  |  +--ro
                                  not-implemented-in*

                                    |  |  |              ->
                                  /yang-library/datastore/name

                                    |  |  +--ro deviation*

                                    |  |                 ->
                                  ../name              

                                    |  |

                                    |  +--ro
                                  import-only-module* [name revision]

                                    |     +--ro
                                  name               
                                  yang:yang-identifier

                                    |     +--ro
                                  revision            union

                                    |     +--ro
                                  schema?             inet:uri

                                    |     +--ro
                                  namespace           inet:uri

                                    |     +--ro submodule*
                                  [name]

                                    |        +--ro name       
                                  yang:yang-identifier

                                    |        +--ro revision   
                                  yang:revision-identifier

                                    |        +--ro schema?    
                                  inet:uri

                                    +--ro datastore* [name] //
                                  Allows future per datastore
                                  properties.

                                    |  +--ro name         
                                  identityref

                                    +--ro checksum       string

                              

                              
------------------------------

                              
(2) An enhanced version of the
                                  structure (1) above, that is extended
                                  to allow the structure to be reused
                                  for schema-mount via an augmentation.

                              
This is similar to the structure above,
                                except that the "the set of modules" is
                                contained in a list of named schema
                                (e.g. similar to the schema mount
                                draft), allowing this structure to be
                                re-used for schema mount.

                              
Schema mount would be expected to
                                augment yang-library to add in the
                                additional schema mount information.  In
                                the tree diagram, I have shown the
                                schema-mount mount-point augmentation,
                                but not including namespaces yet.

                              
Every server would be required to
                                provide at least one schema in the
                                schema list, and the primary schema for
                                the device would always be given the
                                name "primary".

                              
module: ietf-yang-library

                                 +--ro yang-library

                                    +--ro schema* [name]

                                    |  +--ro name          
                                  string

                                    |  +--ro checksum      
                                  string

                                    |  +--ro module* [name]

                                    |  |  +--ro name          
                                  yang:yang-identifier

                                    |  |  +--ro revision?     
                                  yang:revision-identifier

                                    |  |  +--ro schema?       
                                  inet:uri

                                    |  |  +--ro namespace     
                                  inet:uri

                                    |  |  +--ro submodule*
                                  [name]

                                    |  |  |  +--ro name       
                                  yang:yang-identifier

                                    |  |  |  +--ro revision?  
                                  yang:yang-identifier

                                    |  |  |  +--ro schema?    
                                  inet:uri

                                    |  |  +--ro
                                  not-implemented-in*

                                    |  |  |              ->
                                  /yang-library/datastore/name

                                    |  |  +--ro feature* [name]

                                    |  |  |  +--ro name       
                                  yang:yang-identifier

                                    |  |  |  +--ro
                                  not-implemented-in*

                                    |  |  |              ->
                                  /yang-library/datastore/name

                                    |  |  +--ro deviation*

                                    |  |  |              ->
                                  ../name       

                                    |  |  +-
                                  schema-mount:mount-point* [label]

                                    |  |     +--ro
                                  label         yang:yang-identifier

                                    |  |     +--ro
                                  config?       boolean

                                    |  |     +--ro (schema-ref)

                                    |  |        +--:(inline)

                                    |  |        |  +--ro
                                  inline?       empty

                                    |  |       
                                  +--:(use-schema)

                                    |  |           +--ro
                                  use-schema* [name]

                                    |  |              +--ro
                                  name

                                    |  |              |      
                                  -> /yang-library/schema/name

                                    |  |              +--ro
                                  parent-reference*  
                                  yang:xpath1.0          

                                    |  |

                                    |  +--ro
                                  import-only-module* [name revision]

                                    |     +--ro
                                  name               
                                  yang:yang-identifier

                                    |     +--ro
                                  revision            union

                                    |     +--ro
                                  schema?             inet:uri

                                    |     +--ro
                                  namespace           inet:uri

                                    |     +--ro submodule*
                                  [name]

                                    |        +--ro name       
                                  yang:yang-identifier

                                    |        +--ro revision   
                                  yang:revision-identifier

                                    |        +--ro schema?    
                                  inet:uri

                                    +--ro datastore* [name] //
                                  Allows future per datastore
                                  properties.

                                    |  +--ro name         
                                  identityref

                                    +--ro checksum       string

                              
Please can you provide comments on
                                these structures, in particular:

                              
Is this version better (i.e. simpler)
                                that the version currently in
                                draft-ietf-netconf-rfc7895bis-02
                                (below)?

                              

                              
Should we try and make the structure
                                extensible for schema-mount via
                                augmentation (i.e. version (2)), or is
                                it better that schema-mount has its own
                                separate subtree?

                              
For reference only I have included the
                                existing YANG library and YANG library
                                bis draft tree diagrams.

                              

                              
Thanks,

                                Rob

                              

                              


                              

                              
-----------------------------

                              
*** FOR REFERENCE ONLY ***

                              

                              
(3)  The current YANG library structure
                                in YANG library bis
                                (draft-ietf-netconf-rfc7895bis-02)

                              

                              
   module: ietf-yang-library
       +--ro yang-library
          +--ro modules
          |  +--ro module* [id]
          |     +--ro id                  string
          |     +--ro name                yang:yang-identifier
          |     +--ro revision?           revision-identifier
          |     +--ro schema?             inet:uri
          |     +--ro namespace           inet:uri
          |     +--ro feature*            yang:yang-identifier
          |     +--ro deviation* [module]
          |     |  +--ro module    -> ../../id
          |     +--ro conformance-type    enumeration
          |     +--ro submodule* [name]
          |        +--ro name        yang:yang-identifier
          |        +--ro revision?   revision-identifier
          |        +--ro schema?     inet:uri
          +--ro module-sets
          |  +--ro module-set* [id]
          |     +--ro id        string
          |     +--ro module*   -> ../../../modules/module/id
          +--ro datastores
          |  +--ro datastore* [name]
          |     +--ro name          identityref
          |     +--ro module-set
          |             -> ../../../module-sets/module-set/id
          +--ro checksum       string

                              
-----------------------------

                              
*** FOR REFERENCE ONLY ***

                              

                              
(4)  The current YANG library structure
                                (RFC 7895)

                              
      +--ro modules-state
         +--ro module-set-id    string
         +--ro module* [name revision]
            +--ro name                yang:yang-identifier
            +--ro revision            union
            +--ro schema?             inet:uri
            +--ro namespace           inet:uri
            +--ro feature*            yang:yang-identifier
            +--ro deviation* [name revision]
            |  +--ro name        yang:yang-identifier
            |  +--ro revision    union
            +--ro conformance-type    enumeration
            +--ro submodule* [name revision]
               +--ro name        yang:yang-identifier
               +--ro revision    union
               +--ro schema?     inet:uri



                              
 

                              

                              

                              

                              
_______________________________________________
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

                        

                      

                    

                    

                  

                

                

              

            

          

          

        

      

    

    

  


--------------3D40FAD797C37C0085B7F86D--


From nobody Thu Nov 16 03:40: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 A9CAB129468 for ; Thu, 16 Nov 2017 03:40:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Uvxwps63A4D9 for ; Thu, 16 Nov 2017 03:40:21 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 73D2D12946B for ; Thu, 16 Nov 2017 03:40:21 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 94F761AE0383; Thu, 16 Nov 2017 12:40:19 +0100 (CET)
Date: Thu, 16 Nov 2017 12:38:57 +0100 (CET)
Message-Id: <20171116.123857.798672739281378871.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <668cc9e1-c006-ce25-1473-549bc0b71a7d@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] [Netconf] Alternative YANG library structure for 7895bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Nov 2017 11:40:25 -0000

Robert Wilton  wrote:
> Hi Andy,
> =

> =

> On 16/11/2017 02:29, Andy Bierman wrote:
> > Hi,
> >
> > The per-datastore feature aspect of NMDA is a new and significant
> > change to YANG.
> >
> >> =A0 =A0 |=A0 |=A0 +--ro feature* [name]
> >> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name yang:yang-identifier
> >> =A0=A0=A0 |=A0 |=A0 |=A0 +--ro not-implemented-in*
> >> =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -> /y=
ang-library/datastore/name
> >>
> >
> > YANG does not define feature conformance at this granularity.
> > I strongly object to this change to YANG conformance.
> > A server can only advertise a YANG feature if it implemented on the=

> > entire server.
> >
> > This extra complexity is not present on the openconfig solution or
> > requirements.
> In terms of comparison, it definitely is:
> - you can have different features for the config and state trees
> - (e.g. "router-id" feature in RFC 8022).
> - sometimes the conventions are not followed completely consistently,=

> - e.g. different types, or semantics between config and state.
> - sometimes the structures differ between config and state.
> =

> So, the problem comparing between config and state is not easier in
> either the IETF split tree or OpenConfig solutions.
> =

> > Comparing any datastore to  is much more complex (any =
may
> > not be possible)
> > if the features are different for a given module.
> You can always compare (except deviations in operational).=A0 If a
> feature is enabled on any configuration datastore then it must also b=
e
> enabled on operational.

But this is not really correct, since features can be negated,
e.g. you might have:

  feature bar;

  leaf foo {
    if-feature "not bar";
    ...
  }

In this case, it is fine to have "bar" in config but not oper.

I think that saying that the schema for operational MUST be a superset
of the schema for conventional handles this case.


/martin



> =

> E.g.=A0 take "router-id" feature from RFC8022bis (that was also defin=
ed
> in RFC8022).
> =

> This feature can be enabled:
> (i) everywhere (i.e.  +  +
> ), or
> (ii)  + , or
> (iii)  + , or
> (iv)  only, or
> (v) or in none of them.
> =

> Hence,  always contains a superset of the nodes.
> =

> >
> > I do not see how  can be true superset of the
> > conventional datastores
> > if the features are different.
> =

> Because of the statement above.
> =

> Thanks,
> Rob
> =

> >
> >
> > Andy
> >
> >
> > On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton  > > wrote:
> >
> >     I don't think that this is really a good idea.=A0 You would end=
 up
> >     returning server metadata in addition to the configuration.
> >
> >     I still think that the YANG library proposal is the best soluti=
on.
> >
> >     Thanks,
> >     Rob
> >
> >
> >     On 16/11/2017 01:21, Vladimir Vassilev wrote:
> >>     Hello,
> >>
> >>     I have a proposal based on  that provides an elegant=

> >>     solution to consider as a 3rd option.=A0 It is based on keepin=
g
> >>     exactly the same model as in RFC 7895 and using  RPC=
 to
> >>     retrieve datastore specific yang-library instance data in a
> >>     similar way one would use  to retrieve the datastore=

> >>     contents. In addition a top level config=3Dfalse container e.g=
.=

> >>     /datastores with list of supported datastores that does not ne=
ed
> >>     to be part of the yang-library module:
> >>
> >>     module: ietf-datastores
> >>     +--ro datastores
> >>     |=A0 +--ro datastore* [name]
> >>     |=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identityre=
f
> >>
> >>     Vladimir
> >>
> >>     On 11/09/2017 05:51 PM, Robert Wilton wrote:
> >>>
> >>>     Hi,
> >>>
> >>>     Given some of the feedback related to the complexity of the Y=
ANG
> >>>     library bis structure, we have come up with two other possibl=
e
> >>>     structures for the YANG library data:
> >>>
> >>>     (1) A simplified structure to make YANG library meet the NMDA=

> >>>     requirements, but that is closer to the existing YANG library=

> >>>     structure, and arguably simpler.
> >>>     (2) An enhanced version of the structure (1) above, that is a=
lso
> >>>     extended to allow the structure to be reused for schema-mount=

> >>>     via an augmentation.
> >>>
> >>>     For reference, at the end of this email, I have also included=

> >>>     the tree diagram of the existing YANG library, and the curren=
t
> >>>     YANG library bis draft (draft-ietf-netconf-rfc7895bis-02) ver=
sion.
> >>>
> >>>     Considering the two new YANG library structures:
> >>>
> >>>     ------------------------
> >>>
> >>>     *(1) A simplified structure to make YANG library meet the NMD=
A
> >>>     requirements, but that is closer to the existing YANG library=

> >>>     structure.*
> >>>
> >>>     The main changes are:
> >>>     (i) Split "implemented modules" and "import-only-modules" int=
o
> >>>     two separate lists, making the most important list (i.e.
> >>>     implemented modules) keyed by module name only and hence easi=
er
> >>>     to reference.
> >>>     (ii) Assume modules are implemented in all datastores by defa=
ult
> >>>     (with a "not-implemented-in" leaflist of datastores that a
> >>>     module is not implemented in).
> >>>     (iii) Assume that features are implemented in all datastores =
by
> >>>     default (with a "not-implemented-in" leaflist of datastores t=
hat
> >>>     a feature is not implemented in).
> >>>     (iv) Deleted module-sets.
> >>>     (v) Datastores are now just a list of supported datastores (t=
hat
> >>>     could potentially be extended with further per datastore
> >>>     properties in future).
> >>>
> >>>     Manually generated tree output for proposed YANG library:
> >>>
> >>>     module: ietf-yang-library
> >>>     =A0+--ro yang-library
> >>>     =A0=A0=A0 +--ro modules
> >>>     =A0=A0=A0 |=A0 +--ro module* [name]
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro name yang:yang-identifier
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro revision? revision-identifier
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro schema?=A0=A0=A0=A0=A0=A0=A0 inet:u=
ri
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro namespace=A0=A0=A0=A0=A0 inet:uri
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro submodule* [name]
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name yang:yang-identifier
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro revision? yang:yang-identifier=

> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro schema?=A0=A0=A0=A0 inet:uri
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro not-implemented-in*
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
-> /yang-library/datastore/name
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro feature* [name]
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name yang:yang-identifier
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro not-implemented-in*
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
-> /yang-library/datastore/name
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro deviation*
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 -> ../name
> >>>     =A0=A0=A0 |=A0 |
> >>>     =A0=A0=A0 |=A0 +--ro import-only-module* [name revision]
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro name yang:yang-identifier
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro revision=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 union
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro schema? inet:uri
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro namespace inet:uri
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro submodule* [name]
> >>>     =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro name yang:yang-identif=
ier
> >>>     =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro revision yang:revision=
-identifier
> >>>     =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro schema?=A0=A0=A0=A0 in=
et:uri
> >>>     =A0=A0=A0 +--ro datastore* [name] // Allows future per datast=
ore
> >>>     properties.
> >>>     =A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identity=
ref
> >>>     =A0=A0=A0 +--ro checksum=A0=A0=A0=A0=A0=A0 string
> >>>
> >>>     ------------------------------
> >>>
> >>>     *(2) An enhanced version of the structure (1) above, that is
> >>>     extended to allow the structure to be reused for schema-mount=

> >>>     via an augmentation.*
> >>>
> >>>     This is similar to the structure above, except that the "the =
set
> >>>     of modules" is contained in a list of named schema (e.g. simi=
lar
> >>>     to the schema mount draft), allowing this structure to be
> >>>     re-used for schema mount.
> >>>
> >>>     Schema mount would be expected to augment yang-library to add=
 in
> >>>     the additional schema mount information.=A0 In the tree diagr=
am, I
> >>>     have shown the schema-mount mount-point augmentation, but not=

> >>>     including namespaces yet.
> >>>
> >>>     Every server would be required to provide at least one schema=
 in
> >>>     the schema list, and the primary schema for the device would
> >>>     always be given the name "primary".
> >>>
> >>>     module: ietf-yang-library
> >>>     =A0+--ro yang-library
> >>>     =A0=A0=A0 +--ro schema* [name]
> >>>     =A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 strin=
g
> >>>     =A0=A0=A0 |=A0 +--ro checksum=A0=A0=A0=A0=A0=A0 string
> >>>     =A0=A0=A0 |=A0 +--ro module* [name]
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro name yang:yang-identifier
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro revision? yang:revision-identifier
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro schema?=A0=A0=A0=A0=A0=A0=A0 inet:u=
ri
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro namespace=A0=A0=A0=A0=A0 inet:uri
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro submodule* [name]
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name yang:yang-identifier
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro revision? yang:yang-identifier=

> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro schema?=A0=A0=A0=A0 inet:uri
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro not-implemented-in*
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
-> /yang-library/datastore/name
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro feature* [name]
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro name yang:yang-identifier
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0 +--ro not-implemented-in*
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
-> /yang-library/datastore/name
> >>>     =A0=A0=A0 |=A0 |=A0 +--ro deviation*
> >>>     =A0=A0=A0 |=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
-> ../name
> >>>     =A0=A0=A0 |=A0 |=A0 +- schema-mount:mount-point* [label]
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0 +--ro label yang:yang-identifier=

> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0 +--ro config?=A0=A0=A0=A0=A0=A0 =
boolean
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0 +--ro (schema-ref)
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0 +--:(inline)
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro inline? empt=
y
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0 +--:(use-schema)
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro use-sche=
ma* [name]
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro=
 name
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=
=A0=A0=A0=A0 -> /yang-library/schema/name
> >>>     =A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro=
 parent-reference*=A0=A0 yang:xpath1.0
> >>>     =A0=A0=A0 |=A0 |
> >>>     =A0=A0=A0 |=A0 +--ro import-only-module* [name revision]
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro name yang:yang-identifier
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro revision=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 union
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro schema? inet:uri
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro namespace inet:uri
> >>>     =A0=A0=A0 |=A0=A0=A0=A0 +--ro submodule* [name]
> >>>     =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro name yang:yang-identif=
ier
> >>>     =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro revision yang:revision=
-identifier
> >>>     =A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro schema?=A0=A0=A0=A0 in=
et:uri
> >>>     =A0=A0=A0 +--ro datastore* [name] // Allows future per datast=
ore
> >>>     properties.
> >>>     =A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identity=
ref
> >>>     =A0=A0=A0 +--ro checksum=A0=A0=A0=A0=A0=A0 string
> >>>
> >>>     Please can you provide comments on these structures, in parti=
cular:
> >>>
> >>>     Is this version better (i.e. simpler) that the version curren=
tly
> >>>     in draft-ietf-netconf-rfc7895bis-02 (below)?
> >>>
> >>>     Should we try and make the structure extensible for schema-mo=
unt
> >>>     via augmentation (i.e. version (2)), or is it better that
> >>>     schema-mount has its own separate subtree?
> >>>
> >>>     For reference only I have included the existing YANG library =
and
> >>>     YANG library bis draft tree diagrams.
> >>>
> >>>     Thanks,
> >>>     Rob
> >>>
> >>>
> >>>     -----------------------------
> >>>
> >>>     *** FOR REFERENCE ONLY ***
> >>>
> >>>     (3)=A0 The current YANG library structure in YANG library bis=

> >>>     (draft-ietf-netconf-rfc7895bis-02)
> >>>
> >>>         module: ietf-yang-library
> >>>             +--ro yang-library
> >>>                +--ro modules
> >>>                |  +--ro module* [id]
> >>>                |     +--ro id                  string
> >>>                |     +--ro name                yang:yang-identifi=
er
> >>>                |     +--ro revision?           revision-identifie=
r
> >>>                |     +--ro schema?             inet:uri
> >>>                |     +--ro namespace           inet:uri
> >>>                |     +--ro feature*            yang:yang-identifi=
er
> >>>                |     +--ro deviation* [module]
> >>>                |     |  +--ro module    -> ../../id
> >>>                |     +--ro conformance-type    enumeration
> >>>                |     +--ro submodule* [name]
> >>>                |        +--ro name        yang:yang-identifier
> >>>                |        +--ro revision?   revision-identifier
> >>>                |        +--ro schema?     inet:uri
> >>>                +--ro module-sets
> >>>                |  +--ro module-set* [id]
> >>>                |     +--ro id        string
> >>>                |     +--ro module*   -> ../../../modules/module/i=
d
> >>>                +--ro datastores
> >>>                |  +--ro datastore* [name]
> >>>                |     +--ro name          identityref
> >>>                |     +--ro module-set
> >>>                |             -> ../../../module-sets/module-set/i=
d
> >>>                +--ro checksum       string
> >>>
> >>>     -----------------------------
> >>>
> >>>     *** FOR REFERENCE ONLY ***
> >>>
> >>>     (4)=A0 The current YANG library structure (RFC 7895)
> >>>
> >>>            +--ro modules-state
> >>>               +--ro module-set-id    string
> >>>               +--ro module* [name revision]
> >>>                  +--ro name                yang:yang-identifier
> >>>                  +--ro revision            union
> >>>                  +--ro schema?             inet:uri
> >>>                  +--ro namespace           inet:uri
> >>>                  +--ro feature*            yang:yang-identifier
> >>>                  +--ro deviation* [name revision]
> >>>                  |  +--ro name        yang:yang-identifier
> >>>                  |  +--ro revision    union
> >>>                  +--ro conformance-type    enumeration
> >>>                  +--ro submodule* [name revision]
> >>>                     +--ro name        yang:yang-identifier
> >>>                     +--ro revision    union
> >>>                     +--ro schema?     inet:uri
> >>>
> >>>
> >>>
> >>>     _______________________________________________
> >>>     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 Thu Nov 16 15:37: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 D19531270A0 for ; Thu, 16 Nov 2017 15:37:10 -0800 (PST)
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 u71fgcKp2Csr for ; Thu, 16 Nov 2017 15:37:08 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D49712708C for ; Thu, 16 Nov 2017 15:37:08 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 1A9951E0946 for ; Thu, 16 Nov 2017 16:37:06 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id and31w0082SSUrH01nd6rH; Thu, 16 Nov 2017 16:37:06 -0700
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=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=EHgEyL0dNdGARj3ba7EA: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=Rtx57k8Yfweqs1mxOV9FjByS31g2Q+gvEmONbMBEgh0=; b=ghR7dA53+OFcj1nOTAKLnFdro+ d3QVGmq5LQQFS6vst8O+FlqxAYuiNGBxbm/z8sM6e8NMa2uItMC+lVK5mpTmlKgvFlnYVcFDP18Q8 7iThLGLMqV5IilrJ8Qyv8Sx3E;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:59302 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eFTiQ-002YlW-ND; Thu, 16 Nov 2017 16:37:03 -0700
To: Martin Bjorklund , netmod@ietf.org
References: <20171115.135818.591114714397486064.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net>
Date: Fri, 17 Nov 2017 07:36:58 +0800
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: <20171115.135818.591114714397486064.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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: 1eFTiQ-002YlW-ND
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]:59302
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] intended status of the tree diagram document
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Nov 2017 23:37:11 -0000

Martin,
	I think you are correct.  We should leave as is.

I'm sure Kent/the document Shepherd makes sure whatever we do is right 
before publication in any case.

Lou (as contributor)

On 11/15/2017 8:58 PM, Martin Bjorklund wrote:
> Hi,
> 
> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
> Standards Track.  I think I heard during the meeting today that it
> ought to be Informational.  I think this makes sense.  It would then
> imply that other standards track documents will have the tree diagram
> document as an informative reference.
> 
> Should we make this change?
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Nov 16 16:01: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 585551273E2 for ; Thu, 16 Nov 2017 16:01:24 -0800 (PST)
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 mBbqxJPZCK58 for ; Thu, 16 Nov 2017 16:01:22 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 95C7B126DED for ; Thu, 16 Nov 2017 16:01:22 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id F341214130E for ; Thu, 16 Nov 2017 16:42:41 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id anie1w00W2SSUrH01nihAf; Thu, 16 Nov 2017 16:42:41 -0700
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=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=pGLkceISAAAA:8 a=eO7wzvSnhovw2FUgVcEA: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: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=IooCkLhidkIzkDx0JXVMnnyPXVpZnQ34HfloJqOixS4=; b=LNMB+42qECL+GAwrLyYiaVqu/m KK1CCaCvj0073hMascDDCumcNjwa4+1YKFfjjsMB9Vw0P6U7/baGoMWH6pn1GbVbOfyPn78PFQqya 224pFe+UtWGSqZ+ziWOvwp5fd;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:59542 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eFTnq-002a3B-Hj; Thu, 16 Nov 2017 16:42:38 -0700
To: Mehmet Ersue , 'Mahesh Jethanandani' , 'Robert Wilton' 
Cc: netmod@ietf.org
References: <20171115.101454.1576716701146734257.mbj@tail-f.com>  <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com>
From: Lou Berger 
Message-ID: <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net>
Date: Fri, 17 Nov 2017 07:42:33 +0800
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: <014a01d35e87$98797950$c96c6bf0$@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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: 1eFTnq-002a3B-Hj
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]:59542
X-Source-Auth: lberger@labn.net
X-Email-Count: 13
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] tree diagram guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Nov 2017 00:01:24 -0000

To circle back to this.  My sense of this discussion (as contributor) is
(a) the tree diagrams draft should be updated to point to a "guidelines" 
wiki page for "the most current guidelines"
(b) the tree diagrams draft should be updated to include a full set of 
the current tree related guidelines
(c) 6087bis should be updated to point to a "guidelines" wiki page for 
"the most current guidelines"
(d) 6087bis should have it's tree guidelines point to the tree diagrams 
document -- in addition to pointing to the wiki

Does this sound right?

Lou
(as tree co-author)

On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
> The Wiki is useful as a starting point providing a collection of pointers to guideline RFCs and the bis-revisions in development.
> 
> Cheers,
> Mehmet
> 
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh
>> Jethanandani
>> Sent: Thursday, November 16, 2017 7:39 AM
>> To: Robert Wilton 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] tree diagram guidelines
>>
>> Other SDOs can and follow the work in IETF through the RFCs we publish.
>> They do not follow wiki’s, unless the document itself says, “here are the
>> guidelines, but if you are looking for the latest, go to this wiki”. I therefore
>> would support the proposal outlined below. It gives the SDO a stable point of
>> reference with a document, which gets updated occasionally, but also allows
>> them to peak at what is coming down the pipeline.
>>
>> Thanks.
>>
>>> On Nov 15, 2017, at 6:53 PM, Robert Wilton  wrote:
>>>
>>> I liked the suggestion from Chris Hopps:
>>>
>>> I think that it was along the lines of ...
>>>
>>> The RFC contains a reference at the top that states that updates to the
>> guidelines is available on a wiki at ....
>>>
>>> Every few years the guidelines on the wiki can be folded into a latest
>> version of the guidelines draft.
>>>
>>> 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, or MEF be
>> using the latest draft guidelines, or should then use the published RFC until
>> 6087bis is actually republshed?
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 15/11/2017 10:14, Martin Bjorklund wrote:
>>>> Hi,
>>>>
>>>> There was a proposal in the meeting today to have the guidelines for
>>>> tree diagrams in a wiki, instead of having them in 6087bis or in the
>>>> tree diagram document.
>>>>
>>>> Was the proposal really to have a wiki for just the tree guidelines,
>>>> or was the proposal to withdraw 6087bis from the process and instead
>>>> publish all guidelines as a wiki?
>>>>
>>>> If it is the former, is it really worth it?
>>>>
>>>> Advantages with a wiki:
>>>>
>>>>    +  It can be updated more easily
>>>>
>>>> Some drawbacks:
>>>>
>>>>    -  It can be updated more easily
>>>>       (meaning they are less stable)
>>>>
>>>>    -  Wikis tend to not be alive after some time, and are not that
>>>>       easy to find.  Just try to find the various YANG-related wikis
>>>>       we've tried to maintain over the years.
>>>>
>>>>    -  Links in RFCs also have problems.  Sites are re-orginized etc.
>>>>       As an example, the link to the security guidelines template in
>>>>       RFC 6087 doesn't work anymore.
>>>>
>>>>    -  People that are looking for a stable reference will have problems
>>>>       (I think Rob mentioned that IEEE still refer to RFC 6087 (which
>>>>       is understandable; that's the published version).
>>>>
>>>>    -  Who maintains the Wiki, and what are the rules for updating it?
>>>>
>>>>
>>>> I suggest we have the tree-related guidelines (actually just a few
>>>> sentences) in the tree draft, and since 6087bis already refers to
>>>> this document it is not a big problem that guidelines are spread out
>>>> over several documents that are difficult to find.
>>>>
>>>>
>>>>
>>>> /martin
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> .
>>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
>> _______________________________________________
>> 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 Nov 16 16:53: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 9C21D126CB6 for ; Thu, 16 Nov 2017 16:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c18VTJ5H44h for ; Thu, 16 Nov 2017 16:53:40 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524A6126BF0 for ; Thu, 16 Nov 2017 16:53:40 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id i15so658183pfa.3 for ; Thu, 16 Nov 2017 16:53:40 -0800 (PST)
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:content-transfer-encoding:content-language :thread-index; bh=8t5pPY8BeY3yt9D4h+kfAW9Kg2vBx4C63CD8UwE9e9k=; b=JnDCvlySNs6FvGK4rn3hO4uRm/XVB4HfQeEKvOBdiXglkqi32GlrtKHo6a9+mYoaTT qv5/NzQJFmkk/3NeeeWIbvsueyyBiLMzb7KjYngTHR7aDUGJXuhfsylnXPigZWw+PbxP qNh/qSW8fVmEaB6zVx8qA5RmQCcPXQWg4/o+/dU8V6h4k9PRyclbIjp50uY9c7iMRLYQ 7/E5ZnyiJbh1BrTAY1Ld2yK9L7EcXVWYKfaD8Vjopa8aZPB/uld3s33gA3Oj7R+IrwM4 Gd2w08oGZkLo0Nq/QyaGm6tql6IdPCQ6STo2APVjdbwmeJKtvOr23p77MKOpPEaNjM8V vI3Q==
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:content-transfer-encoding:content-language :thread-index; bh=8t5pPY8BeY3yt9D4h+kfAW9Kg2vBx4C63CD8UwE9e9k=; b=TAON93tIxpH2OziBj6RtRGAd87dFZUAD4ebOx6/Y7UeSxXOxvQAlT2cjDRQrSKrpMK DkdCtBFpoW8yVFXQ/AZdTAcuR0NNEWOgVHgUmdd7nuMwXEXDOV4D1pIM7nBpBu8IxPcV YbWZxZWTT6/p+JnPvslnVh28KhHjR18vsPGKZNtqie9oPVv5tC2XPUMzpIS61Ip0+jJR tJD0FUd5a2xNVePVzyO4Zav0YzKszSs4YN0h1oUSCWfbWD2qOUhcvymhO6ZUB5I+rePX jJHYmxWg1ljlGJgsr9mvK84ebUzxdZHKzN+Acp46r9WfSCKQIpTCiXgDqf6hH4I8fuHR iNKQ==
X-Gm-Message-State: AJaThX5V3jeojqlBENxjoPbKNVLi98QvpsOgHeqAuk7Fzk/2PAXelmzo 37nJE/OdBq+bpTJLAMEcGo4=
X-Google-Smtp-Source: AGs4zMYRV2TAkGLzeeDppUYEEgz6vPvX8awHqH4Gjfu5sdAWVdhQNjk7s8ak5IhC4slzwigaQWR2Sw==
X-Received: by 10.84.240.1 with SMTP id y1mr3508830plk.391.1510880019831; Thu, 16 Nov 2017 16:53:39 -0800 (PST)
Received: from DESKTOPFLHJVQJ ([2001:67c:1232:144:6d1f:df87:592f:459b]) by smtp.gmail.com with ESMTPSA id h29sm6002982pfd.65.2017.11.16.16.53.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 16:53:38 -0800 (PST)
From: "Mehmet Ersue" 
To: "'Lou Berger'" , "'Mahesh Jethanandani'" , "'Robert Wilton'" 
Cc: 
References: <20171115.101454.1576716701146734257.mbj@tail-f.com>  <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com> <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net>
In-Reply-To: <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net>
Date: Fri, 17 Nov 2017 08:53:38 +0800
Message-ID: <009a01d35f3e$8330c960$89925c20$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: de
Thread-Index: AQGxefq6yqyvOLF6jhxyeqpBlh8GFwHgxCcMAmPZNysCzQvFewIu7OMMoxGESOA=
Archived-At: 
Subject: Re: [netmod] tree diagram guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Nov 2017 00:53:43 -0000

Sounds perfect to me.

Mehmet

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Friday, November 17, 2017 7:43 AM
> To: Mehmet Ersue ; 'Mahesh Jethanandani'
> ; 'Robert Wilton' 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] tree diagram guidelines
>=20
> To circle back to this.  My sense of this discussion (as contributor) =
is
> (a) the tree diagrams draft should be updated to point to a =
"guidelines"
> wiki page for "the most current guidelines"
> (b) the tree diagrams draft should be updated to include a full set of =
the
> current tree related guidelines
> (c) 6087bis should be updated to point to a "guidelines" wiki page for =
"the
> most current guidelines"
> (d) 6087bis should have it's tree guidelines point to the tree =
diagrams
> document -- in addition to pointing to the wiki
>=20
> Does this sound right?
>=20
> Lou
> (as tree co-author)
>=20
> On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
> > The Wiki is useful as a starting point providing a collection of =
pointers to
> guideline RFCs and the bis-revisions in development.
> >
> > Cheers,
> > Mehmet
> >
> >> -----Original Message-----
> >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh
> >> Jethanandani
> >> Sent: Thursday, November 16, 2017 7:39 AM
> >> To: Robert Wilton 
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] tree diagram guidelines
> >>
> >> Other SDOs can and follow the work in IETF through the RFCs we =
publish.
> >> They do not follow wiki=E2=80=99s, unless the document itself says, =
=E2=80=9Chere are
> >> the guidelines, but if you are looking for the latest, go to this
> >> wiki=E2=80=9D. I therefore would support the proposal outlined =
below. It
> >> gives the SDO a stable point of reference with a document, which =
gets
> >> updated occasionally, but also allows them to peak at what is =
coming
> down the pipeline.
> >>
> >> Thanks.
> >>
> >>> On Nov 15, 2017, at 6:53 PM, Robert Wilton  =
wrote:
> >>>
> >>> I liked the suggestion from Chris Hopps:
> >>>
> >>> I think that it was along the lines of ...
> >>>
> >>> The RFC contains a reference at the top that states that updates =
to
> >>> the
> >> guidelines is available on a wiki at ....
> >>>
> >>> Every few years the guidelines on the wiki can be folded into a
> >>> latest
> >> version of the guidelines draft.
> >>>
> >>> 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,,
> >>> IEEE, or MEF be
> >> using the latest draft guidelines, or should then use the published
> >> RFC until 6087bis is actually republshed?
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>> On 15/11/2017 10:14, Martin Bjorklund wrote:
> >>>> Hi,
> >>>>
> >>>> There was a proposal in the meeting today to have the guidelines
> >>>> for tree diagrams in a wiki, instead of having them in 6087bis or
> >>>> in the tree diagram document.
> >>>>
> >>>> Was the proposal really to have a wiki for just the tree
> >>>> guidelines, or was the proposal to withdraw 6087bis from the
> >>>> process and instead publish all guidelines as a wiki?
> >>>>
> >>>> If it is the former, is it really worth it?
> >>>>
> >>>> Advantages with a wiki:
> >>>>
> >>>>    +  It can be updated more easily
> >>>>
> >>>> Some drawbacks:
> >>>>
> >>>>    -  It can be updated more easily
> >>>>       (meaning they are less stable)
> >>>>
> >>>>    -  Wikis tend to not be alive after some time, and are not =
that
> >>>>       easy to find.  Just try to find the various YANG-related =
wikis
> >>>>       we've tried to maintain over the years.
> >>>>
> >>>>    -  Links in RFCs also have problems.  Sites are re-orginized =
etc.
> >>>>       As an example, the link to the security guidelines template =
in
> >>>>       RFC 6087 doesn't work anymore.
> >>>>
> >>>>    -  People that are looking for a stable reference will have =
problems
> >>>>       (I think Rob mentioned that IEEE still refer to RFC 6087 =
(which
> >>>>       is understandable; that's the published version).
> >>>>
> >>>>    -  Who maintains the Wiki, and what are the rules for updating =
it?
> >>>>
> >>>>
> >>>> I suggest we have the tree-related guidelines (actually just a =
few
> >>>> sentences) in the tree draft, and since 6087bis already refers to
> >>>> this document it is not a big problem that guidelines are spread
> >>>> out over several documents that are difficult to find.
> >>>>
> >>>>
> >>>>
> >>>> /martin
> >>>>
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> netmod@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>> .
> >>>>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> Mahesh Jethanandani
> >> mjethanandani@gmail.com
> >>
> >> _______________________________________________
> >> 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 Nov 16 17:27: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 B7F19124207 for ; Thu, 16 Nov 2017 17:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CcZmcXKpScCR for ; Thu, 16 Nov 2017 17:27:39 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6FB124239 for ; Thu, 16 Nov 2017 17:27:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=452; q=dns/txt; s=iport; t=1510882059; x=1512091659; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=5/5pbNwPCOGY23vm+s1e7NMy/0ya+WQ70xSuMBjQ8zc=; b=Ohuf2+Chppgo0xEFefQuPrbc0HwUJGsotpJqgWYGren1/C3LbwGGcYoy 0jM5AIlm5m5dX8AdnOe+sasmnYOh9q8oruHhQ2o2kLkcaikMFsX30s3rB aswGHR1BKOYNCrfmflApxL0oHPsDY2gzspepcor+xRQXjHlMQokWBoffT s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAQCGOg5a/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2gVKEJplFmFyCEQqFMYRrQRYBAQEBAQEBAQFrHQuFSA8BewI?= =?us-ascii?q?mAl8NCAEBiiCpMIIniwIBAQgCASWBD4IlggeBVYISiy+CYwWTB480gXaJZIkwg?= =?us-ascii?q?XwBGIlsJIcjljCBOSYFLYF0VSUVSYJlhHwjjDwBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,405,1505779200"; d="scan'208";a="32058835"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Nov 2017 01:27:38 +0000
Received: from [10.24.74.101] ([10.24.74.101]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vAH1RbAZ032724 for ; Fri, 17 Nov 2017 01:27:38 GMT
To: "netmod@ietf.org" 
From: Joe Clarke 
Organization: Cisco
Message-ID: 
Date: Thu, 16 Nov 2017 20:27:36 -0500
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
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [netmod] Support for draft-bierman-netmod-yang-data-ext
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Nov 2017 01:27:41 -0000

I wanted to drop a note to the list in support of adoption for
draft-bierman-netmod-yang-data-ext.  I had a strong need for this in the
recent past in order to create a model for a complex data structure, and
I had to do some unnatural stuff to achieve my goal.

In my read through the document, the only comment I have is that the
example for augment-yang-data augments rc:yang-data instead of
yd:yang-data.  Just seemed strange to me.

Joe


From nobody Thu Nov 16 18:55: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 6D129124D68 for ; Thu, 16 Nov 2017 18:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Q9c2VMoU4WML for ; Thu, 16 Nov 2017 18:55:48 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C901267BB for ; Thu, 16 Nov 2017 18:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1528; q=dns/txt; s=iport; t=1510887348; x=1512096948; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=3lkvne9KdBB/er3Rv9YITJLmB0CDUXIQNbfjq219OCk=; b=nItC/jZCEBq5XLBsN0xT126n7C9xh7eRD+WxCXEB1iWMw9cgaDODR72y OEuydcTb9aeSuVYguOYhchFCuVB8lnACyNm4kyUMAMXviBi+q6CNMJqGy m0bn7q08ApS/FbgS0IVQV/3TovhPk2xxNPy/DzwPTeeWXCGEudR04zAVG s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgCPTg5a/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8gVKEJplEgU4vlmKCEQqFOwKEX0EWAQEBAQEBAQEBayiFHwE?= =?us-ascii?q?FI2YLGAICJgICVwYBDAgBAYogqTKCJ4sDAQEBAQEBAQEBAQEBAQEBAQEhgQ+CJ?= =?us-ascii?q?YIHgVWCEoMChQKDK4JjBZMHjzSVCoIViWwkhyOKNIt8gTkmCyeBdFUlFYMuhHw?= =?us-ascii?q?jiwcBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,406,1505779200"; d="scan'208";a="32732017"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2017 02:55:47 +0000
Received: from [10.24.74.101] ([10.24.74.101]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAH2tjjF028221; Fri, 17 Nov 2017 02:55:46 GMT
To: Ladislav Lhotka , netmod@ietf.org
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <87inebdff0.fsf@nic.cz> <2daae313-cbf1-c26a-c176-a3d31b57092d@cisco.com> <1510742316.21877.6.camel@nic.cz>
From: Joe Clarke 
Organization: Cisco
Message-ID: <7eaa576f-d158-d5c1-774e-c41ee9015105@cisco.com>
Date: Thu, 16 Nov 2017 21:55:45 -0500
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: <1510742316.21877.6.camel@nic.cz>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 02:55:49 -0000

On 11/15/17 05:38, Ladislav Lhotka wrote:
> On Wed, 2017-11-15 at 05:27 -0500, Joe Clarke wrote:
>> On 11/15/17 05:06, Ladislav Lhotka wrote:
>>>> I suppose my gut reaction to Lou's question as to whether a server
>>>> should support multiple versions was, "no."  A client may have multiple
>>>> versions loaded to support servers that support different versions.  I
>>>> may be convinced otherwise, but I feel that this will become untenable
>>>> over time (even if module names change).
>>>
>>> There are use cases for modules that are imported (i.e. not
>>> implemented): it could be that a module author wants to use some
>>> definitions from an old version of an imported module while, at the same
>>> time, other definitions from a new version.
>>>
>>> The semver-aware "import" statement should be able to deal with this.
>>
>> I think it could be, but I also think importing from different versions
>> of the same module feels messy.  How would this work with different
>> module names today?  Just use different prefixes?  Are there defined use
>> cases for this in the wild today?
> 
> Let's say a new version of a module adds new enums to two different enumeration
> types, but an implementor (for some reason) is only able to update one of them
> in the back-end and not the other.

I read implementor to be "vendor" here.  And if a vendor cannot
implement one of the enums, would they not just add a deviation?  I
don't see why they'd have to keep the old module around for this.

Joe


From nobody Thu Nov 16 22: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 B382C128D16 for ; Thu, 16 Nov 2017 22:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mFLUj_CPG5b9 for ; Thu, 16 Nov 2017 22:55:55 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27426128D0F for ; Thu, 16 Nov 2017 22:55:55 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 28ACA70F; Fri, 17 Nov 2017 07:55:53 +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 GfTCVBbA1wfU; Fri, 17 Nov 2017 07:55:52 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Nov 2017 07:55:53 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1562E20120; Fri, 17 Nov 2017 07:55:53 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LWaJFo9wbNby; Fri, 17 Nov 2017 07:55:52 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F5902011F; Fri, 17 Nov 2017 07:55:52 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id AC029415C163; Fri, 17 Nov 2017 07:54:24 +0100 (CET)
Date: Fri, 17 Nov 2017 07:54:24 +0100
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Martin Bjorklund , netmod@ietf.org
Message-ID: <20171117065424.ccnx3dufs7e5abk3@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod@ietf.org
References: <20171115.135818.591114714397486064.mbj@tail-f.com> <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <69960a0c-1441-ec80-d8fb-287d8c474300@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] intended status of the tree diagram document
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Nov 2017 06:55:58 -0000

Lou,

right now, the document says standards track, Martin's proposal was to
move to informational. So how do I parse "I think you are correct.  We
should leave as is."?

/js

On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote:
> Martin,
> 	I think you are correct.  We should leave as is.
> 
> I'm sure Kent/the document Shepherd makes sure whatever we do is right
> before publication in any case.
> 
> Lou (as contributor)
> 
> On 11/15/2017 8:58 PM, Martin Bjorklund wrote:
> > Hi,
> > 
> > Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
> > Standards Track.  I think I heard during the meeting today that it
> > ought to be Informational.  I think this makes sense.  It would then
> > imply that other standards track documents will have the tree diagram
> > document as an informative reference.
> > 
> > Should we make this change?
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Thu Nov 16 23:02: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 3D8261292D3 for ; Thu, 16 Nov 2017 23:02:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xiNOtqIaH23H for ; Thu, 16 Nov 2017 23:02:14 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD9E128C84 for ; Thu, 16 Nov 2017 23:02:14 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 144B870F; Fri, 17 Nov 2017 08:02:13 +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 5W33RzmDBoos; Fri, 17 Nov 2017 08:02:11 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Nov 2017 08:02:13 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EEC6720120; Fri, 17 Nov 2017 08:02:12 +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 wBAdSuGuM0LQ; Fri, 17 Nov 2017 08:02:12 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B9082011F; Fri, 17 Nov 2017 08:02:12 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 98C80415C1C8; Fri, 17 Nov 2017 08:00:43 +0100 (CET)
Date: Fri, 17 Nov 2017 08:00:43 +0100
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Mehmet Ersue , 'Mahesh Jethanandani' , 'Robert Wilton' , netmod@ietf.org
Message-ID: <20171117070043.pm7rn25yj3hxum3q@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Mehmet Ersue , 'Mahesh Jethanandani' , 'Robert Wilton' , netmod@ietf.org
References: <20171115.101454.1576716701146734257.mbj@tail-f.com>  <0696749C-0E80-40CC-9905-BD8187CB6D78@gmail.com> <014a01d35e87$98797950$c96c6bf0$@gmail.com> <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <00143927-dc4d-5db8-e3ce-dbd56366a06c@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] tree diagram guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Nov 2017 07:02:22 -0000

I am confused. I think there was some consensus to

- include all tree related guidelines in the tree document, remove all tree
  related guidelines from 6087bis and have 6087bis point to the tree document
  (which it already does)

The rest is pointless since AFAIK there is no wiki guidelines pages to
point to and there is AFAIK nobody in place to actually maintain such
a wiki page. Perhaps a wiki is the future but until future has
arrived, we should not point to it.

The other proposal I heard was to have a landing page that points to
the current guideline work which points to the relevant documents. A
wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not
affect the documents.

/js

PS: I am happy to add pointers to guidelines as a section to the
    wikipedia page.

On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote:
> To circle back to this.  My sense of this discussion (as contributor) is
> (a) the tree diagrams draft should be updated to point to a "guidelines"
> wiki page for "the most current guidelines"
> (b) the tree diagrams draft should be updated to include a full set of the
> current tree related guidelines
> (c) 6087bis should be updated to point to a "guidelines" wiki page for "the
> most current guidelines"
> (d) 6087bis should have it's tree guidelines point to the tree diagrams
> document -- in addition to pointing to the wiki
> 
> Does this sound right?
> 
> Lou
> (as tree co-author)
> 
> On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
> > The Wiki is useful as a starting point providing a collection of pointers to guideline RFCs and the bis-revisions in development.
> > 
> > Cheers,
> > Mehmet
> > 
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Mahesh
> > > Jethanandani
> > > Sent: Thursday, November 16, 2017 7:39 AM
> > > To: Robert Wilton 
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] tree diagram guidelines
> > > 
> > > Other SDOs can and follow the work in IETF through the RFCs we publish.
> > > They do not follow wiki’s, unless the document itself says, “here are the
> > > guidelines, but if you are looking for the latest, go to this wiki”. I therefore
> > > would support the proposal outlined below. It gives the SDO a stable point of
> > > reference with a document, which gets updated occasionally, but also allows
> > > them to peak at what is coming down the pipeline.
> > > 
> > > Thanks.
> > > 
> > > > On Nov 15, 2017, at 6:53 PM, Robert Wilton  wrote:
> > > > 
> > > > I liked the suggestion from Chris Hopps:
> > > > 
> > > > I think that it was along the lines of ...
> > > > 
> > > > The RFC contains a reference at the top that states that updates to the
> > > guidelines is available on a wiki at ....
> > > > 
> > > > Every few years the guidelines on the wiki can be folded into a latest
> > > version of the guidelines draft.
> > > > 
> > > > 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, or MEF be
> > > using the latest draft guidelines, or should then use the published RFC until
> > > 6087bis is actually republshed?
> > > > 
> > > > Thanks,
> > > > Rob
> > > > 
> > > > 
> > > > On 15/11/2017 10:14, Martin Bjorklund wrote:
> > > > > Hi,
> > > > > 
> > > > > There was a proposal in the meeting today to have the guidelines for
> > > > > tree diagrams in a wiki, instead of having them in 6087bis or in the
> > > > > tree diagram document.
> > > > > 
> > > > > Was the proposal really to have a wiki for just the tree guidelines,
> > > > > or was the proposal to withdraw 6087bis from the process and instead
> > > > > publish all guidelines as a wiki?
> > > > > 
> > > > > If it is the former, is it really worth it?
> > > > > 
> > > > > Advantages with a wiki:
> > > > > 
> > > > >    +  It can be updated more easily
> > > > > 
> > > > > Some drawbacks:
> > > > > 
> > > > >    -  It can be updated more easily
> > > > >       (meaning they are less stable)
> > > > > 
> > > > >    -  Wikis tend to not be alive after some time, and are not that
> > > > >       easy to find.  Just try to find the various YANG-related wikis
> > > > >       we've tried to maintain over the years.
> > > > > 
> > > > >    -  Links in RFCs also have problems.  Sites are re-orginized etc.
> > > > >       As an example, the link to the security guidelines template in
> > > > >       RFC 6087 doesn't work anymore.
> > > > > 
> > > > >    -  People that are looking for a stable reference will have problems
> > > > >       (I think Rob mentioned that IEEE still refer to RFC 6087 (which
> > > > >       is understandable; that's the published version).
> > > > > 
> > > > >    -  Who maintains the Wiki, and what are the rules for updating it?
> > > > > 
> > > > > 
> > > > > I suggest we have the tree-related guidelines (actually just a few
> > > > > sentences) in the tree draft, and since 6087bis already refers to
> > > > > this document it is not a big problem that guidelines are spread out
> > > > > over several documents that are difficult to find.
> > > > > 
> > > > > 
> > > > > 
> > > > > /martin
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > .
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > > Mahesh Jethanandani
> > > mjethanandani@gmail.com
> > > 
> > > _______________________________________________
> > > 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 Mon Nov 20 04:13: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 3401012956C for ; Mon, 20 Nov 2017 04:13:44 -0800 (PST)
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 fxZNnpS4tvBo for ; Mon, 20 Nov 2017 04:13:42 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D11126BFD for ; Mon, 20 Nov 2017 04:13:41 -0800 (PST)
Received: from birdie14010 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id D21A963355; Mon, 20 Nov 2017 13:13:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1511180017; bh=LMHkNs9ealTmF4ltisCkphNSST38yz7fUmOJWK4DjSE=; h=From:To:Date; b=BAoYb211/Tjp4Qrcqi5ibWrS08+u3yYtIgwgVuksftl3cTP1rGWEAcBQ7ceOznirI haKsuP/B8snxp+XwytmcSclQSDGIuTiDiMBaM7vF0+ugOA6IyNPcpJ7Vcel3xURpKg fvF0HmULfRjspTcUXg68Q6IYlGHNZxBOmj6Wpc1s=
Message-ID: <1511180091.4492.13.camel@nic.cz>
From: Ladislav Lhotka 
To: Joe Clarke , netmod@ietf.org
Date: Mon, 20 Nov 2017 13:14:51 +0100
In-Reply-To: <7eaa576f-d158-d5c1-774e-c41ee9015105@cisco.com>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com> <87inebdff0.fsf@nic.cz> <2daae313-cbf1-c26a-c176-a3d31b57092d@cisco.com> <1510742316.21877.6.camel@nic.cz> <7eaa576f-d158-d5c1-774e-c41ee9015105@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2 
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] Comment on draft-clacla-netmod-yang-model-update-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, 20 Nov 2017 12:13:44 -0000

On Thu, 2017-11-16 at 21:55 -0500, Joe Clarke wrote:
> On 11/15/17 05:38, Ladislav Lhotka wrote:
> > On Wed, 2017-11-15 at 05:27 -0500, Joe Clarke wrote:
> > > On 11/15/17 05:06, Ladislav Lhotka wrote:
> > > > > I suppose my gut reaction to Lou's question as to whether a server
> > > > > should support multiple versions was, "no."  A client may have
> > > > > multiple
> > > > > versions loaded to support servers that support different versions.  I
> > > > > may be convinced otherwise, but I feel that this will become untenable
> > > > > over time (even if module names change).
> > > > 
> > > > There are use cases for modules that are imported (i.e. not
> > > > implemented): it could be that a module author wants to use some
> > > > definitions from an old version of an imported module while, at the same
> > > > time, other definitions from a new version.
> > > > 
> > > > The semver-aware "import" statement should be able to deal with this.
> > > 
> > > I think it could be, but I also think importing from different versions
> > > of the same module feels messy.  How would this work with different
> > > module names today?  Just use different prefixes?  Are there defined use
> > > cases for this in the wild today?
> > 
> > Let's say a new version of a module adds new enums to two different
> > enumeration
> > types, but an implementor (for some reason) is only able to update one of
> > them
> > in the back-end and not the other.
> 
> I read implementor to be "vendor" here.  And if a vendor cannot

Instead of "implementor" I should have said "module author" - it could be a
vendor or IETF WG or whatever. A realistic example might be a module for certain
IANA parameters such as

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

If IANA updates this registry, the author of a module that uses it might want to
update some enumerations while keeping others in the old version. The reason for
doing so may be, for example, that some cipher has to be removed for security
reasons, but migrating completely to the new registry version is a long shot
that needs more time.

> implement one of the enums, would they not just add a deviation?  I

Vendors generally don't like to declare deviations, and I think it would be
really weird if an IETF standard track module contained a deviation.

Lada   

> don't see why they'd have to keep the old module around for this.
> 
> Joe
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Nov 20 05:34: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 5984D129A8E; Mon, 20 Nov 2017 05:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level: 
X-Spam-Status: No, score=-3.647 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, URG_BIZ=0.573, 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 uJeYECKoF2SL; Mon, 20 Nov 2017 05:34:39 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D075129AA3; Mon, 20 Nov 2017 05:34:39 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 469A5366D01BF; Mon, 20 Nov 2017 13:34:35 +0000 (GMT)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 20 Nov 2017 13:34:36 +0000
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.47]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 21:34:23 +0800
From: Jiangyuanlong 
To: "tictoc@ietf.org" , Alex Campbell , Rodney Cummings , Karen O'Donoghue 
CC: Xian Liu , Xujinchun , "netmod@ietf.org" 
Thread-Topic: Using instance-number or instance-name issue - RE:  WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTYgRGm15KQMSipkqKj0T8PnrXLA==
Date: Mon, 20 Nov 2017 13:34:23 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>
References: +ADw-150906887826.22201.5033565145094897903.idtracker+AEA-ietfa.amsl.com+AD4-, +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97+AEA-dggeml507-mbx.china.huawei.com+AD4- +ADw-1509329710965.52658+AEA-Aviatnet.com+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8+AEA-dggeml507-mbs.china.huawei.com+AD4- +ADw-02fb01d35893+ACQ-2081f160+ACQ-4001a8c0+AEA-gateway.2wire.net+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62E74B+AEA-dggeml507-mbs.china.huawei.com+AD4- <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net>
In-Reply-To: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net>
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-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Using instance-number or instance-name issue - RE: 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, 20 Nov 2017 13:34:48 -0000

Hi all,

Item +ACM-5 below is the last open issue we discussed both in emails and in=
 IEEE 1588 mailing list on draft-ietf-tictoc-1588v2-yang. =20
In a summary: in draft-ietf-tictoc-1588v2-yang, list instance-list has a ke=
y of +ACI-instance-number+ACI-, but there were discussions whether to use i=
nstance-name (a string) instead.

Currently, +ACI-instance-number+ACI- in draft-ietf-tictoc-1588v2-yang-06 al=
igns well with the texts in the new revision of IEEE 1588 (D1.2/2017):=20
   +ACI-The instanceList is indexed using a number that is unique per PTP I=
nstance within the PTP Node, applicable to the=20
   management context only (i.e. not used in PTP messages). The domainNumbe=
r of the PTP Instance must not be used as the index=20
   to instanceList, since it is possible for a PTP Node to contain multiple=
 PTP Instances using the same domainNumber.+ACI-

The main requirement of instanceList in IEEE 1588 is the uniqueness of its =
index, and the +ACI-key+ACI- statement of YANG serves this purpose very wel=
l.

That is, when instance-number is used as a key, a PTP Node with multiple PT=
P Instances cannot use the same instance-number value for these PTP Instanc=
es (just according to YANG semantics).

Using instance-name (string) can also guarantee the uniqueness of the index=
 of a list, but compared with an integer, a string is usually more complex =
to process and store. If instance-name is modeled as an arbitrary length of=
 string, there is even a risk of buffer-overflow attack.

Furthermore, it should be noted that draft-ietf-tictoc-1588v2-yang is targe=
ted at IEEE 1588-2008, for which most products today only have a single PTP=
 instance, and not have a name for this instance, it seems quite weird to i=
ntroduce a name for this instance.

Therefore, I would suggest we keep on using instance-number as a key. But a=
s 65536 limit is a concern, I further suggest to change its type to uint32.

Any comments or concerns on this suggestion to move forward?

Thanks,
Yuanlong

----- Original Message -----
From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4-
To: +ACI-Alex Campbell+ACI- +ADw-Alex.Campbell+AEA-Aviatnet.com+AD4AOw- +AD=
w-tictoc+AEA-ietf.org+AD4-
Cc: +ACI-Xian Liu+ACI- +ADw-lene.liuxian+AEA-foxmail.com+AD4AOw- +ACI-Xujin=
chun+ACI-
+ADw-xujinchun+AEA-huawei.com+AD4AOw- +ADw-netmod+AEA-ietf.org+AD4-
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


+AD4- Hi Alex,
+AD4-
+AD4- Sorry for a late reply as I spent the last week for an urgent busines=
s
trip.
+AD4- Please see my comments in line with +AFs-YJ+AF0-
+AD4-
+AD4- Thanks,
+AD4- Yuanlong
+AD4-
+AD4- -----Original Message-----
+AD4- From: Alex Campbell +AFs-mailto:Alex.Campbell+AEA-Aviatnet.com+AF0-
+AD4- Sent: Monday, October 30, 2017 10:15 AM
+AD4- To: Jiangyuanlong+ADs- tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Hi,
+AD4- I've reviewed this latest draft and have some more comments.
+AD4-
+AD4- 1. I find the introduction to be unnecessarily wordy+ADs- it feels li=
ke it
was written with a view of not missing any information out, rather than try=
ing to keep it concise.
+AD4-    For example, there is no need to elaborate on YANG data types here=
.
It is also not here to sell YANG.
+AD4-
+AD4- +AFs-YJ+AF0- Yes, we are trying to give some introductory information=
 for an
outsider who may not be familiar with PTP or YANG, and explain why a YANG f=
or PTP is needed. The juicy part of this document is its YANG module, and p=
eople can skip all the other texts if they are familiar with PTP and YANG.
+AD4- Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear message f=
rom the TICTOC chairs to introduce any big changes at this last call stage.
+AD4-
+AD4-
+AD4- OLD:
+AD4-
+AD4-    As a synchronization protocol, IEEE 1588-2008 +AFs-IEEE1588+AF0- i=
s widely
+AD4-    supported in the carrier networks, industrial networks, automotive
+AD4-    networks, and many other applications. It can provide high
+AD4-    precision time synchronization as fine as nano-seconds. The
+AD4-    protocol depends on a Precision Time Protocol (PTP) engine to
+AD4-    decide its own state automatically, and a PTP transportation layer
+AD4-    to carry the PTP timing and various quality messages. The
+AD4-    configuration parameters and state data sets of IEEE 1588-2008 are
+AD4-    numerous.
+AD4-
+AD4-    According to the concepts described in +AFs-RFC3444+AF0-, IEEE 158=
8-2008
+AD4-    itself provides an information model in its normative
+AD4-    specifications for the data sets (in IEEE 1588-2008 clause 8). Som=
e
+AD4-    standardization organizations including the IETF have specified
+AD4-    data models in MIBs (Management Information Bases) for IEEE 1588-
+AD4-    2008 data sets (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0-). The=
se MIBs are
+AD4-    typically focused on retrieval of state data using the Simple
+AD4-    Network Management Protocol (SNMP), furthermore, configuration of
+AD4-    PTP data sets is not considered in +AFs-RFC8173+AF0-.
+AD4-
+AD4-    Some service providers and applications require that the managemen=
t
+AD4-    of the IEEE 1588-2008 synchronization network be flexible and more
+AD4-    Internet-based (typically overlaid on their transport networks).
+AD4-    Software Defined Network (SDN) is another driving factor, which
+AD4-    demands an improved configuration capability of synchronization
+AD4-    networks.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
+AD4-    configuration and state data manipulated by network management
+AD4-    protocols like the Network Configuration Protocol (NETCONF)
+AD4-    +AFs-RFC6241+AF0-. A small set of built-in data types are defined =
in
+AD4-    +AFs-RFC6020+AF0-, and a collection of common data types are furth=
er
+AD4-    defined in +AFs-RFC6991+AF0-. Advantages of YANG include Internet =
based
+AD4-    configuration capability, validation, rollback and so on. All of
+AD4-    these characteristics make it attractive to become another
+AD4-    candidate modeling language for IEEE 1588-2008.
+AD4-
+AD4- NEW:
+AD4-
+AD4-    IEEE 1588-2008 is a time protocol that provides high precision tim=
e
+AD4-    synchronization as fine as nano-seconds.
+AD4-
+AD4-    IEEE 1588-2008 itself provides an information model in its
normative
+AD4-    specifications for the data sets (IEEE 1588-2008 clause 8).
+AD4-    Standard information models (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021=
AS+AF0-) have
been
+AD4-    previously defined as MIBs focused on the retrieval of state data
using
+AD4-    SNMP +AFs-RFC1157+AF0-.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
configuration
+AD4-    and state data manipulated by network management protocols like
NETCONF
+AD4-    +AFs-RFC6241+AF0-.
+AD4-
+AD4- 2. Can we refer to the system as simply PTP rather than IEEE
1588(-2008)?
+AD4- +AFs-YJ+AF0- Advice from IEEE 1588 is, we need to use +ACI-1588-2008+=
ACI- as much as
possible to help clarify that the scope of this YANG is limited to the publ=
ished 1588 standard.
+AD4-
+AD4-
+AD4- 3. There is insufficient spacing here to separate the terms from thei=
r
definitions:
+AD4- OLD
+AD4-
+AD4-    PTP dataset  Structured attributes of clocks (an OC, BC or TC) use=
d
+AD4-    for PTP protocol decisions and for providing values for PTP messag=
e
+AD4-    fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance A PTP implementation in the device (i.e., an OC or BC=
)
+AD4-    represented by a specific PTP dataset.
+AD4-
+AD4- NEW
+AD4-
+AD4-    PTP dataset
+AD4-      Structured attributes of clocks (an OC, BC or TC) used
+AD4-      for PTP protocol decisions and for providing values for PTP
message
+AD4-      fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance
+AD4-      A PTP implementation in the device (i.e., an OC or BC)
+AD4-      represented by a specific PTP dataset.
+AD4- +AFs-YJ+AF0- OK.
+AD4-
+AD4- 4. There's a singular/plural mismatch here:
+AD4-
+AD4-    module. Query and configuration of device wide or port specific
+AD4-    configuration information and clock data set is described for this
+AD4-    version.
+AD4- +AFs-YJ+AF0- Good, we will change 'is' to 'are'.
+AD4-
+AD4- and here:
+AD4-
+AD4-    Query and configuration of clock information include:
+AD4-
+AD4-
+AD4- 5. The choice of uint16 as instance-number limits implementations to
65536 distinct instances.
+AD4-    While I have a hard time imagining a system with more than 65536
PTP instances, I would prefer to avoid imposing arbitrary limits.
+AD4-    I would recommend changing instance-number to a string (and
renaming it to instance-name or just name).
+AD4- +AFs-YJ+AF0- The 1588-2008 supports multiple instances of PTP, but it=
 is
ambiguous in its organization of those PTP instances, especially with regar=
d to management.
+AD4-  In the 1588 new revision, there is an explicit list of PTP instances=
,
and that list is indexed using a number (not name). Thus to align with the =
new revision, we need to keep it instance-number.
+AD4-  If 65536 limit is a concern, how about change it to uint32, any
concerns?
+AD4-
+AD4-
+AD4- 6. I still recommend removing -ds from the YANG element names that
still include it. It doesn't appear to add any value.
+AD4- +AFs-YJ+AF0- Rodney's opinion: the value of using 'ds' is that the 15=
88
document on which this YANG model is based uses +ACI-DefaultDS+ACI- as a te=
rm.
PTP experts even say +ACI-default dee ess+ACI- verbally when referring to t=
his data. If we changed this to just +ACI-default+ACI-, PTP experts might a=
ssume that we are referring to something entirely new to YANG. Thus, to ali=
gn with 1588-2008, the same set of terminologies are used.
+AD4-
+AD4- 7. What+ADs-s the relevance of injection attacks relevant to this YAN=
G
module?
+AD4- +AFs-YJ+AF0- This is a general statement which is applicable to this =
YANG
module and other YANG modules as well.
+AD4- Thanks again,
+AD4- Yuanlong
+AD4-
+AD4- Alex
+AD4-
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-
+AD4- From: netmod +ADw-netmod-bounces+AEA-ietf.org+AD4- on behalf of Jiang=
yuanlong
+ADw-jiangyuanlong+AEA-huawei.com+AD4-
+AD4- Sent: Friday, 27 October 2017 3:21 p.m.
+AD4- To: tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Dear all,
+AD4-
+AD4- Based on all the comments we received during the WG Last Call process=
,
we've updated the document to version 6.
+AD4- We believe all the LC comments are resolved and the consensus is
reflected in this new revision.
+AD4- Many thanks to Martin, Tal, Opher, Alex, John and many others who had
reviewed and commented on this draft.
+AD4-
+AD4- Cheers,
+AD4- Yuanlong on behalf of all coauthors
+AD4-
+AD4- -----Original Message-----
+AD4- From: internet-drafts+AEA-ietf.org +AFs-mailto:internet-drafts+AEA-ie=
tf.org+AF0-
+AD4- Sent: Friday, October 27, 2017 9:48 AM
+AD4- To: Xian Liu+ADs- Rodney Cummings+ADs- rodney.cummings+AEA-ni.com+ADs=
- Jiangyuanlong+ADs-
Xujinchun
+AD4- Subject: New Version Notification for
draft-ietf-tictoc-1588v2-yang-06.txt
+AD4-
+AD4-
+AD4- A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
+AD4- has been successfully submitted by Yuanlong Jiang and posted to the
IETF repository.
+AD4-
+AD4- Name:           draft-ietf-tictoc-1588v2-yang
+AD4- Revision:       06
+AD4- Title:          YANG Data Model for IEEE 1588-2008
+AD4- Document date:  2017-10-26
+AD4- Group:          tictoc
+AD4- Pages:          30
+AD4- URL:
https://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588v2-yang-06.tx
t
+AD4- Status:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
+AD4- Htmlized:
https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-06
+AD4- Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-06
+AD4- Diff:
https://www.ietf.org/rfcdiff?url2+AD0-draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Abstract:
+AD4-    This document defines a YANG data model for the configuration of
+AD4-    IEEE 1588-2008 devices and clocks, and also retrieval of the
+AD4-    configuration information, data set and running states of IEEE
+AD4-    1588-2008 clocks.
+AD4-
+AD4-
+AD4-
+AD4-
+AD4- 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.
+AD4-
+AD4- The IETF Secretariat
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://www.ietf.org/mailman/listinfo/netmod
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Nov 21 08:25: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 F1C8D129ACD for ; Tue, 21 Nov 2017 08:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVlGMTrmbwOZ for ; Tue, 21 Nov 2017 08:25:14 -0800 (PST)
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 0048E124D6C for ; Tue, 21 Nov 2017 08:25:13 -0800 (PST)
Received: by mail-pg0-x231.google.com with SMTP id r12so10527253pgu.10 for ; Tue, 21 Nov 2017 08:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=1X9tPdG78gc6I85BSb3nlxDnsHbfULJ/Hd8l1g2zyvY=; b=cTNB7cljdoAEaUI/gD0Y5isTofCRdNbql8A5Mxfuj6RBQ70Iyf2Z6Eb1dDC4CLPRqY zPoh7kAK+1JFbzTzx0Lhw8FcJUSYspwiA8ls0a3uUrgZpuqjdeudi8g66XF82osPp53O n2VBU4PjaxsKoKzCMljRuQsGKzU1Q6sujyFtj6s1L1DwhmM0OjJ9Go0Bh5WqNAt3LqJg FTWfsHCd33xJCOzV/K6WCyeVBw64dr9SKSVBhwbPWnOZP8mbxpS+Yu8UZ4AimjkaB4O/ 1UltAOt4QLsb+Kz3eN0NwD3f8hhA3YpoPy/Giio53PGFpqZd97tugGeILyvyISmCw3BN d5Ng==
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=1X9tPdG78gc6I85BSb3nlxDnsHbfULJ/Hd8l1g2zyvY=; b=dNaQrOqSLAH34jXVfniQTD6x79ykW3rfhAFrdKFMHbvdHyI/V4LaQRMQvYu75J5Vcx O1X6dwinUjLoIARLMwyN6xqqMf/pJhhCNlslcch0BnajG5V6xpEG6x8FToWEnc+2MD+0 b4CexXCNxoWDFkRoIE6OvmYzTIAzw8RUok0uC7ma6Gon0J8aHA9FlHrz0kdodIYQ3ytp Rdbuz4SDJaPLygFXXT2hskIpyfsm5J42WnMc7D0itCASY/izfg8wMA76/B+I7WRC6hHv wOWl9PFO+n4wK5nX1iPBKwgtnn1HWj8pk+ElwW808V/jP67jIxd2IbO7KTd9YiuJhub+ Ldgg==
X-Gm-Message-State: AJaThX5k8CJNUi1TPLY49sL+xhfWOnkhaM7bKu/8KrYZScVYq92gfYNa E2/dAtbzNxjWrLBs+q6/gckhBaxN
X-Google-Smtp-Source: AGs4zMZtNdRJ/9IUUs7iwh/G8HtCogyyoG5/4aXrT48SQrSmObyZgG4ImhdYTFDgTCY9orALUH1eGg==
X-Received: by 10.99.39.198 with SMTP id n189mr17051264pgn.78.1511281512902; Tue, 21 Nov 2017 08:25:12 -0800 (PST)
Received: from ?IPv6:2600:1700:edb0:8fd0:f892:b5d6:b814:d0d0? ([2600:1700:edb0:8fd0:f892:b5d6:b814:d0d0]) by smtp.gmail.com with ESMTPSA id l14sm22568063pgn.35.2017.11.21.08.25.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Nov 2017 08:25:12 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_915F6118-5150-45C7-B098-D477FA913B53"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net>
Date: Tue, 21 Nov 2017 08:25:10 -0800
Cc: Kristian Larsson , Kristian Larsson , Kent Watsen , "Einar Nilsen-Nygaard (einarnn)" , "Sonal Agarwal (agarwaso)" , Robert Wilton , Kristian Larsson , Jeffrey Haas 
Message-Id: <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com>
References:   <91E820DA-7186-4F2A-B2D4-59A86D6CEBA2@gmail.com> <20171115093443.GA28741@spritelink.se> <791DC1EA-467B-41FE-9BBC-374FE73B1A17@juniper.net> <7CF89803-912E-4970-8C14-0192E055FE03@gmail.com>   <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net>
To: NetMod WG 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] IETF 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, 21 Nov 2017 16:25:21 -0000

--Apple-Mail=_915F6118-5150-45C7-B098-D477FA913B53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[Taking the discussion to the mailing list]

The summary of the discussion happening on a private thread has to do =
with the =E2=80=98any=E2=80=99 container (now leaf) definition in the =
ACL model for something that matches anything, much like a =E2=80=98*=E2=80=
=99 would do in regex. The discussion has come down to:

- leave the definition as is, so users would have to explicitly define =
it
  pro: It is explicit and there would be no confusion about its presence =
or absence.=20
  con: It is verbose, in that every access list entry would have to =
define it.

- remove the any definition, so an absence of the definition implies =
match on all. The text in the draft would have to be updated to state =
this, and YANG parsers would need to watch out for the non-definition in =
the match container.

Opinion? Preferences?

p.s. Current CLI configurations require explicit declaration of =
=E2=80=98any=E2=80=99.

> On Nov 20, 2017, at 2:20 PM, Jeff Haas  wrote:
>=20
>>=20
>> On Nov 20, 2017, at 4:54 PM, Kristian Larsson =
 wrote:
>>=20
>>=20
>>=20
>> On 2017-11-20 18:26, Jeff Haas wrote:
>>> IMO, the contention here is a consequence of proof by assertion. >
>>>> On Nov 17, 2017, at 5:56 AM, Kristian Larsson > wrote:
>>>>=20
>>>>>>=20
>>>>>> Changes I'd like to see to this PR:
>>>>>> * remove any-acl completely as it serves no purpose (we achieve
>>>>>>  this through a ACE with no match conditions)
>>>>> Will let Jeff respond as he articulated this requirement. Agree =
that most platforms have deny as the default. But what if the ace entry =
is something like this:
>>>>> access-list 11 permit tcp any any
>>>>> Would the absence of match rules for IP addresses imply any any?
>>>>=20
>>>> An absence of any match means it matches on everything. If there =
are no IP matches at all, then yes, it implies any source or destination =
address. I don't see why we would need to explicitly have an any-acl =
container or leaf to point this out. With the same concept applied =
uniformly you would explicitly call out "any" matches for all types of =
matches. That would be extremely verbose.
>>> Where in the model does it say that the absence of a matches =
container implies a match all vs. match none?
>>> Where in the normative text of the internet-draft does it say that?
>>> In the absence of either of the above, an "any" removes ambiguity.
>>> FWIW, I'm totally fine with removing the any; however you *MUST* =
clarify the above.  Preferably both in the matches container and also in =
the normative text.  For my part, I think it's easier on the parser if =
you basically require at least one item from the container so you don't =
have to deal with optional contents.  But I'm not the one writing yang =
parsers for a living.
>>=20
>> I think it's clear that if no match condition is defined for a =
particular (header) field then that means any value will match. It is =
only an extension of this that no match conditions at all means we match =
any and all packets. I think that is logical.
>>=20
>> This can naturally be spelled out in the text :)
>=20
> You think it's clear, but where is it in the document or model?
>=20
> Of such "implied clarity" is many interop bugs made. :-P
>=20
> -- Jeff
>=20
>>=20
>> Kind regards,
>>  Kristian.

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_915F6118-5150-45C7-B098-D477FA913B53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

[Taking the discussion to the mailing list]

The summary of the discussion happening =
on a private thread has to do with the =E2=80=98any=E2=80=99 container =
(now leaf) definition in the ACL model for something that matches =
anything, much like a =E2=80=98*=E2=80=99 would do in regex. The =
discussion has come down to:

- leave the definition as is, so users =
would have to explicitly define it
  pro: It =
is explicit and there would be no confusion about its presence or =
absence. 
  con: It is verbose, in that =
every access list entry would have to define it.

- remove the any definition, so an =
absence of the definition implies match on all. The text in the draft =
would have to be updated to state this, and YANG parsers would need to =
watch out for the non-definition in the match container.

Opinion? =
Preferences?

p.s. Current CLI configurations require explicit declaration =
of =E2=80=98any=E2=80=99.

On =
Nov 20, 2017, at 2:20 PM, Jeff Haas <jhaas@juniper.net> =
wrote:


On Nov 20, 2017, at =
4:54 PM, Kristian Larsson <kristian@spritelink.net> wrote:



On 2017-11-20 18:26, Jeff Haas =
wrote:
IMO, the =
contention here is a consequence of proof by assertion. >
On Nov 17, 2017, at 5:56 =
AM, Kristian Larsson <kll@dev.terastrm.net <mailto:kll@dev.terastrm.net>> wrote:


Changes I'd like to see to this =
PR:
* remove any-acl completely as it serves no purpose =
(we achieve
 this through a ACE with no match =
conditions)
Will let Jeff respond as he =
articulated this requirement. Agree that most platforms have deny as the =
default. But what if the ace entry is something like this:
access-list 11 permit tcp any any
Would the =
absence of match rules for IP addresses imply any any?

An absence of any match means it =
matches on everything. If there are no IP matches at all, then yes, it =
implies any source or destination address. I don't see why we would need =
to explicitly have an any-acl container or leaf to point this out. With =
the same concept applied uniformly you would explicitly call out "any" =
matches for all types of matches. That would be extremely verbose.
Where in the model does it say that the absence =
of a matches container implies a match all vs. match none?
Where in the normative text of the internet-draft does it say =
that?
In the absence of either of the above, an "any" =
removes ambiguity.
FWIW, I'm totally fine with removing =
the any; however you *MUST* clarify the above.  Preferably both in =
the matches container and also in the normative text.  For my part, =
I think it's easier on the parser if you basically require at least one =
item from the container so you don't have to deal with optional =
contents.  But I'm not the one writing yang parsers for a =
living.

I think it's clear =
that if no match condition is defined for a particular (header) field =
then that means any value will match. It is only an extension of this =
that no match conditions at all means we match any and all packets. I =
think that is logical.

This can naturally =
be spelled out in the text :)

You think it's =
clear, but where is it in the document or model?

Of such "implied clarity" is many interop =
bugs made. :-P

-- Jeff


Kind regards,
 Kristian.



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_915F6118-5150-45C7-B098-D477FA913B53--


From nobody Tue Nov 21 08:39: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 3D3CC129B0D for ; Tue, 21 Nov 2017 08:39:50 -0800 (PST)
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 m-6sHjDsAMC5 for ; Tue, 21 Nov 2017 08:39:48 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C18124D6C for ; Tue, 21 Nov 2017 08:39:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18190; q=dns/txt; s=iport; t=1511282388; x=1512491988; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=5RGhzAK/LOrvyXY/Prk8xgwdy7dFw07EqC6FxZ/909E=; b=m5gA0Fx5nOqr2YJsKvFIGwVq/kUppr6dsO3n6gbzcqwjdfkdmmwz1UpB 8dl5sij/t77cIYz5JTUOJ0RcGtbxT7YbZhliVCSx+O/0vZrMEBy7zty0/ uaLJHuFX0kjDgXhNvad2HGL3jhxRAh152gVrltIpFid73X/Tp8YJt63h7 o=;
X-IronPort-AV: E=Sophos;i="5.44,432,1505779200"; d="scan'208,217";a="356349"
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 Nov 2017 16:39:46 +0000
Received: from [10.63.23.168] (dhcp-ensft1-uk-vla370-10-63-23-168.cisco.com [10.63.23.168]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vALGdjmS010439; Tue, 21 Nov 2017 16:39:46 GMT
To: Mahesh Jethanandani , NetMod WG 
Cc: Kristian Larsson , Kristian Larsson , Kent Watsen , "Einar Nilsen-Nygaard (einarnn)" , "Sonal Agarwal (agarwaso)" , Kristian Larsson , Jeffrey Haas 
References:   <91E820DA-7186-4F2A-B2D4-59A86D6CEBA2@gmail.com> <20171115093443.GA28741@spritelink.se> <791DC1EA-467B-41FE-9BBC-374FE73B1A17@juniper.net> <7CF89803-912E-4970-8C14-0192E055FE03@gmail.com>   <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net> <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com>
From: Robert Wilton 
Message-ID: <9850dd69-220e-c131-b35e-c125d484c3df@cisco.com>
Date: Tue, 21 Nov 2017 16:39:45 +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: <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com>
Content-Type: multipart/alternative; boundary="------------4A814F6A16F6AA2BE296564D"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] IETF 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, 21 Nov 2017 16:39:50 -0000

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

On 21/11/2017 16:25, Mahesh Jethanandani wrote:
> [Taking the discussion to the mailing list]
>
> The summary of the discussion happening on a private thread has to do 
> with the ‘any’ container (now leaf) definition in the ACL model for 
> something that matches anything, much like a ‘*’ would do in regex. 
> The discussion has come down to:
>
> - leave the definition as is, so users would have to explicitly define it
What would it mean if the client configured an ACL type of "any" but 
didn't configure the "any" leaf?


>   pro: It is explicit and there would be no confusion about its 
> presence or absence.
>   con: It is verbose, in that every access list entry would have to 
> define it.
>
> - remove the any definition, so an absence of the definition implies 
> match on all. The text in the draft would have to be updated to state 
> this, and YANG parsers would need to watch out for the non-definition 
> in the match container.
>
> Opinion? Preferences?
>
> p.s. Current CLI configurations require explicit declaration of ‘any’.

If we have an "any" leaf that it seems that:
- it only applies for an ACL of type "any-acl", and can't be used for 
other ACL types.
- it has to be applied for an ACL of type "any-acl" (to have any use).
- it makes is ambiguous if the leaf isn't configured, which would sort 
of force the any leaf to be mandatory for ACLs of type "any-acl".

So it seems redundant to me.  I.e. I'm not sure what extra information 
an "any" leaf imparts beyond knowing that the ACL is of type"any-acl".

Thanks,
Rob


>
>> On Nov 20, 2017, at 2:20 PM, Jeff Haas > > wrote:
>>
>>>
>>> On Nov 20, 2017, at 4:54 PM, Kristian Larsson 
>>> > wrote:
>>>
>>>
>>>
>>> On 2017-11-20 18:26, Jeff Haas wrote:
>>>> IMO, the contention here is a consequence of proof by assertion. >
>>>>> On Nov 17, 2017, at 5:56 AM, Kristian Larsson 
>>>>>  
>>>>> > wrote:
>>>>>
>>>>>>>
>>>>>>> Changes I'd like to see to this PR:
>>>>>>> * remove any-acl completely as it serves no purpose (we achieve
>>>>>>>  this through a ACE with no match conditions)
>>>>>> Will let Jeff respond as he articulated this requirement. Agree 
>>>>>> that most platforms have deny as the default. But what if the ace 
>>>>>> entry is something like this:
>>>>>> access-list 11 permit tcp any any
>>>>>> Would the absence of match rules for IP addresses imply any any?
>>>>>
>>>>> An absence of any match means it matches on everything. If there 
>>>>> are no IP matches at all, then yes, it implies any source or 
>>>>> destination address. I don't see why we would need to explicitly 
>>>>> have an any-acl container or leaf to point this out. With the same 
>>>>> concept applied uniformly you would explicitly call out "any" 
>>>>> matches for all types of matches. That would be extremely verbose.
>>>> Where in the model does it say that the absence of a matches 
>>>> container implies a match all vs. match none?
>>>> Where in the normative text of the internet-draft does it say that?
>>>> In the absence of either of the above, an "any" removes ambiguity.
>>>> FWIW, I'm totally fine with removing the any; however you *MUST* 
>>>> clarify the above.  Preferably both in the matches container and 
>>>> also in the normative text.  For my part, I think it's easier on 
>>>> the parser if you basically require at least one item from the 
>>>> container so you don't have to deal with optional contents.  But 
>>>> I'm not the one writing yang parsers for a living.
>>>
>>> I think it's clear that if no match condition is defined for a 
>>> particular (header) field then that means any value will match. It 
>>> is only an extension of this that no match conditions at all means 
>>> we match any and all packets. I think that is logical.
>>>
>>> This can naturally be spelled out in the text :)
>>
>> You think it's clear, but where is it in the document or model?
>>
>> Of such "implied clarity" is many interop bugs made. :-P
>>
>> -- Jeff
>>
>>>
>>> Kind regards,
>>>  Kristian.
>
> Mahesh Jethanandani
> mjethanandani@gmail.com 
>


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


  
    
  
  
    On 21/11/2017 16:25, Mahesh Jethanandani wrote:

    

      
      [Taking the discussion to the mailing list]
      


      

      
The summary of the discussion happening on a private
        thread has to do with the ‘any’ container (now leaf) definition
        in the ACL model for something that matches anything, much like
        a ‘*’ would do in regex. The discussion has come down to:

      


      

      
- leave the definition as is, so users would have to
        explicitly define it

    

    What would it mean if the client configured an ACL type of "any" but
    didn't configure the "any" leaf?

    

    

    

      
  pro: It is explicit and there would be no
        confusion about its presence or absence. 

      
  con: It is verbose, in that every access list
        entry would have to define it.

      


      

      
- remove the any definition, so an absence of the
        definition implies match on all. The text in the draft would
        have to be updated to state this, and YANG parsers would need to
        watch out for the non-definition in the match container.

      


      

      
Opinion? Preferences?

      


      

      
p.s. Current CLI configurations require explicit
        declaration of ‘any’.

    

    

    If we have an "any" leaf that it seems that:

    - it only applies for an ACL of type "any-acl", and can't be used
    for other ACL types.

    - it has to be applied for an ACL of type "any-acl" (to have any
    use).

    - it makes is ambiguous if the leaf isn't configured, which would
    sort of force the any leaf to be mandatory for ACLs of type
    "any-acl".

    

    So it seems redundant to me.  I.e. I'm not sure what extra
    information an "any" leaf imparts beyond knowing that the ACL is of
    type"any-acl".

    

    Thanks,

    Rob

    

    

    

      


        

          

            
On Nov 20, 2017, at 2:20 PM, Jeff Haas <jhaas@juniper.net> wrote:

            

            

              


                On Nov 20, 2017, at 4:54 PM, Kristian Larsson <kristian@spritelink.net>
                wrote:

                

                

                

                On 2017-11-20 18:26, Jeff Haas wrote:

                
IMO, the contention
                  here is a consequence of proof by assertion. >

                  
On Nov 17, 2017, at
                    5:56 AM, Kristian Larsson <kll@dev.terastrm.net
                    <mailto:kll@dev.terastrm.net>>
                    wrote:

                    

                    

                      


                        Changes I'd like to see to this PR:

                        * remove any-acl completely as it serves no
                        purpose (we achieve

                         this through a ACE with no match conditions)

                      

                      Will let Jeff respond as he articulated this
                      requirement. Agree that most platforms have deny
                      as the default. But what if the ace entry is
                      something like this:

                      access-list 11 permit tcp any any

                      Would the absence of match rules for IP addresses
                      imply any any?

                    

                    

                    An absence of any match means it matches on
                    everything. If there are no IP matches at all, then
                    yes, it implies any source or destination address. I
                    don't see why we would need to explicitly have an
                    any-acl container or leaf to point this out. With
                    the same concept applied uniformly you would
                    explicitly call out "any" matches for all types of
                    matches. That would be extremely verbose.

                  

                  Where in the model does it say that the absence of a
                  matches container implies a match all vs. match none?

                  Where in the normative text of the internet-draft does
                  it say that?

                  In the absence of either of the above, an "any"
                  removes ambiguity.

                  FWIW, I'm totally fine with removing the any; however
                  you *MUST* clarify the above.  Preferably both in the
                  matches container and also in the normative text.  For
                  my part, I think it's easier on the parser if you
                  basically require at least one item from the container
                  so you don't have to deal with optional contents.  But
                  I'm not the one writing yang parsers for a living.

                

                

                I think it's clear that if no match condition is defined
                for a particular (header) field then that means any
                value will match. It is only an extension of this that
                no match conditions at all means we match any and all
                packets. I think that is logical.

                

                This can naturally be spelled out in the text :)

              

              

              You
                think it's clear, but where is it in the document or
                model?

              

              Of
                such "implied clarity" is many interop bugs made. :-P

              

              --
                Jeff

              

              


                Kind regards,

                 Kristian.

            

          

        

        

        

          
Mahesh Jethanandani

          
        

        

      

    

    

  


--------------4A814F6A16F6AA2BE296564D--


From nobody Tue Nov 21 09: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 8E7131201F2; Tue, 21 Nov 2017 09:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Level: 
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URG_BIZ=0.573] autolearn=no 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 8Ph-ibrelqdd; Tue, 21 Nov 2017 09:55:56 -0800 (PST)
Received: from mx0b-00010702.pphosted.com (mx0b-00010702.pphosted.com [148.163.158.57]) (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 30C9B1294FF; Tue, 21 Nov 2017 09:55:55 -0800 (PST)
Received: from pps.filterd (m0098779.ppops.net [127.0.0.1]) by mx0b-00010702.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vALHsCrW006786; Tue, 21 Nov 2017 11:55:42 -0600
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0183.outbound.protection.outlook.com [216.32.180.183]) by mx0b-00010702.pphosted.com with ESMTP id 2eakj774w3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 21 Nov 2017 11:55:41 -0600
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=phzPH3PC3n0zgeAcmWO/DJJKUnfWdMUwkyZn8X6IJxc=; b=l//TZGTrGMOVOt8dQ8ctpZO5sI5K1w9eN3SB3Fqif66aMOznXnOwgcHU+HyYCovR5Vhkzpo+9N6cpemMddvfttsiCzhka/vVFZSy5yNTPO3LwaGzAWo2lsLpO0xPm2DMmB4jgV2ymvyPA2juEz+56ewHNb1Qwv26YqYeKpyhM7w=
Received: from CY1PR0401MB1536.namprd04.prod.outlook.com (10.163.19.154) by CY1PR0401MB1533.namprd04.prod.outlook.com (10.163.19.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 17:55:39 +0000
Received: from CY1PR0401MB1536.namprd04.prod.outlook.com ([10.163.19.154]) by CY1PR0401MB1536.namprd04.prod.outlook.com ([10.163.19.154]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 17:55:38 +0000
From: Rodney Cummings 
To: Jiangyuanlong , "tictoc@ietf.org" , Alex Campbell , Karen O'Donoghue 
CC: Xian Liu , Xujinchun , "netmod@ietf.org" 
Thread-Topic: Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTYgRWOrV538T3MkCQ2eWpBz9P4KMfHxkQ
Date: Tue, 21 Nov 2017 17:55:38 +0000
Message-ID: 
References: +ADw-150906887826.22201.5033565145094897903.idtracker+AEA-ietfa.amsl.com+AD4-, +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97+AEA-dggeml507-mbx.china.huawei.com+AD4- +ADw-1509329710965.52658+AEA-Aviatnet.com+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8+AEA-dggeml507-mbs.china.huawei.com+AD4- +ADw-02fb01d35893+ACQ-2081f160+ACQ-4001a8c0+AEA-gateway.2wire.net+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62E74B+AEA-dggeml507-mbs.china.huawei.com+AD4- <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.82.221.21]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR0401MB1533; 6:nfhazFXqUfJn4ENgMX/mWpLRkhPM5qz2VoUSckhJYNiMg3fSOIDsOvFrTU4UlKtQSVIDhkW8m708ddnQ4p8qfhQrbAJbHtnfapOQjYPXIp9NVHZSmyaQZiPMX4JQM4Us6Tsuszu6+g/OFhXOWpbVSryt4R/+13kx8/7WwJciOLYfrAvWHmxB3QxWDeMGurS5g9ADJK7FPwAQZVZLJ74oMlDCunwH0JS6B9NplOyAG5PyPvjjhvpFgJHFe4noZlMsIFdioQ2ZmnG5Mz2tZN+ktqjj1JdnX12/OdnicTkHAEg5JC/D8c6YUF5nYs6LduSLDrGrJdbMDhvhZzEM+qJzBuLfZ7ZEl21x1Vq/znZwl/M=; 5:Ca2rbG9o/8oTKdBGqZQXa1Mu1S0eiZfAiQPX1g8rbI/BcUdNDVfhWvb4TmID4taLbsyE/qiuSjeITU4CRSuyyyWwaWccN1oO1qNNlc9XHVBUtK8u5vDXiL1NgDSlGd/k8+viHos4ELATeEOLKqAleczNeVHyrooEwC05hJ+VhxM=; 24:wRX1wUNAY809ilBsxABJViCNbBntTk7d+VhYGYICdmJo6tWnm9MnK69u9Kl+T5ilwxx3kFX23PpEMmKLf8MX5g0krH/e1B4d+9/9gZrSZKY=; 7:TL8oW+gDkFzS2V6Ztr/nHf53PhhpYfpqH9AxT70CfA/K+eZeBPDFmbOtKJ3SOOtwjVDRO/PllGiRkuycGbEDTPy/v4JRnc8WE1zj9VZ8yE86D7unkEnpnqpFkUTsVzNhCAknZpYBhG1PI9YUwGk7Jz70y78accb22Qj7uOmv8kxAyco0wwus7MMm79vtB4xgb+pBIJ1H40il82sVdovFJLg2fmE4ZdR/X0fvjMrm7/GKe9s24TX+k9N5WoynrZN3
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: a2104d76-1486-4b8d-6d41-08d531091331
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY1PR0401MB1533; 
x-ms-traffictypediagnostic: CY1PR0401MB1533:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278428928389397)(50582790962513)(100405760836317)(265557217796441)(145744241990776)(10436049006162);
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)(3231022)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0401MB1533; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0401MB1533; 
x-forefront-prvs: 049897979A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(53754006)(43784003)(377424004)(13464003)(189002)(199003)(53546010)(33656002)(229853002)(50986999)(14454004)(76176999)(106356001)(105586002)(54356999)(316002)(2950100002)(4326008)(102836003)(2900100001)(3280700002)(189998001)(5660300001)(966005)(6116002)(2906002)(101416001)(3660700001)(478600001)(3846002)(8936002)(7696004)(575784001)(53936002)(25786009)(86362001)(55016002)(66066001)(4001150100001)(8676002)(81166006)(81156014)(2501003)(9686003)(6306002)(8666007)(68736007)(230783001)(97736004)(54906003)(6246003)(7736002)(6506006)(74316002)(110136005)(99286004)(77096006)(305945005)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0401MB1533; H:CY1PR0401MB1536.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ni.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a2104d76-1486-4b8d-6d41-08d531091331
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 17:55:38.5359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1533
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-21_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_policy_notspam policy=inbound_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-1709140000 definitions=main-1711210235
Archived-At: 
Subject: Re: [netmod] Using instance-number or instance-name issue - RE: 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: Tue, 21 Nov 2017 17:55:58 -0000

Hi Yuanlong,

I have no concerns with instance-number, as that is what the upcoming 1588 =
revision outlines for management.

I also have no strong objections against changing instance-number to instan=
ce-name. If we do that, I think it would be best to make the same change in=
 the upcoming 1588 revision. I asked the 1588 working group for opinion, bu=
t I haven't heard back on that.

All things being equal, my preference is to go with instance-number.

Rodney

-----Original Message-----
From: Jiangyuanlong +AFs-mailto:jiangyuanlong+AEA-huawei.com+AF0-=20
Sent: Monday, November 20, 2017 7:34 AM
To: tictoc+AEA-ietf.org+ADs- Alex Campbell +ADs- Rodney Cummings +ADs- Kare=
n O'Donoghue=20
Cc: Xian Liu +ADs- Xujinchun +ADs- netmod+AEA-ietf.org
Subject: Using instance-number or instance-name issue - RE: WG Last Call re=
solutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Hi all,

Item +ACM-5 below is the last open issue we discussed both in emails and in=
 IEEE 1588 mailing list on draft-ietf-tictoc-1588v2-yang. =20
In a summary: in draft-ietf-tictoc-1588v2-yang, list instance-list has a ke=
y of +ACI-instance-number+ACI-, but there were discussions whether to use i=
nstance-name (a string) instead.

Currently, +ACI-instance-number+ACI- in draft-ietf-tictoc-1588v2-yang-06 al=
igns well with the texts in the new revision of IEEE 1588 (D1.2/2017):=20
   +ACI-The instanceList is indexed using a number that is unique per PTP I=
nstance within the PTP Node, applicable to the=20
   management context only (i.e. not used in PTP messages). The domainNumbe=
r of the PTP Instance must not be used as the index=20
   to instanceList, since it is possible for a PTP Node to contain multiple=
 PTP Instances using the same domainNumber.+ACI-

The main requirement of instanceList in IEEE 1588 is the uniqueness of its =
index, and the +ACI-key+ACI- statement of YANG serves this purpose very wel=
l.

That is, when instance-number is used as a key, a PTP Node with multiple PT=
P Instances cannot use the same instance-number value for these PTP Instanc=
es (just according to YANG semantics).

Using instance-name (string) can also guarantee the uniqueness of the index=
 of a list, but compared with an integer, a string is usually more complex =
to process and store. If instance-name is modeled as an arbitrary length of=
 string, there is even a risk of buffer-overflow attack.

Furthermore, it should be noted that draft-ietf-tictoc-1588v2-yang is targe=
ted at IEEE 1588-2008, for which most products today only have a single PTP=
 instance, and not have a name for this instance, it seems quite weird to i=
ntroduce a name for this instance.

Therefore, I would suggest we keep on using instance-number as a key. But a=
s 65536 limit is a concern, I further suggest to change its type to uint32.

Any comments or concerns on this suggestion to move forward?

Thanks,
Yuanlong

----- Original Message -----
From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4-
To: +ACI-Alex Campbell+ACI- +ADw-Alex.Campbell+AEA-Aviatnet.com+AD4AOw- +AD=
w-tictoc+AEA-ietf.org+AD4-
Cc: +ACI-Xian Liu+ACI- +ADw-lene.liuxian+AEA-foxmail.com+AD4AOw- +ACI-Xujin=
chun+ACI-
+ADw-xujinchun+AEA-huawei.com+AD4AOw- +ADw-netmod+AEA-ietf.org+AD4-
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


+AD4- Hi Alex,
+AD4-
+AD4- Sorry for a late reply as I spent the last week for an urgent busines=
s
trip.
+AD4- Please see my comments in line with +AFs-YJ+AF0-
+AD4-
+AD4- Thanks,
+AD4- Yuanlong
+AD4-
+AD4- -----Original Message-----
+AD4- From: Alex Campbell +AFs-mailto:Alex.Campbell+AEA-Aviatnet.com+AF0-
+AD4- Sent: Monday, October 30, 2017 10:15 AM
+AD4- To: Jiangyuanlong+ADs- tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Hi,
+AD4- I've reviewed this latest draft and have some more comments.
+AD4-
+AD4- 1. I find the introduction to be unnecessarily wordy+ADs- it feels li=
ke it
was written with a view of not missing any information out, rather than try=
ing to keep it concise.
+AD4-    For example, there is no need to elaborate on YANG data types here=
.
It is also not here to sell YANG.
+AD4-
+AD4- +AFs-YJ+AF0- Yes, we are trying to give some introductory information=
 for an
outsider who may not be familiar with PTP or YANG, and explain why a YANG f=
or PTP is needed. The juicy part of this document is its YANG module, and p=
eople can skip all the other texts if they are familiar with PTP and YANG.
+AD4- Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear message f=
rom the TICTOC chairs to introduce any big changes at this last call stage.
+AD4-
+AD4-
+AD4- OLD:
+AD4-
+AD4-    As a synchronization protocol, IEEE 1588-2008 +AFs-IEEE1588+AF0- i=
s widely
+AD4-    supported in the carrier networks, industrial networks, automotive
+AD4-    networks, and many other applications. It can provide high
+AD4-    precision time synchronization as fine as nano-seconds. The
+AD4-    protocol depends on a Precision Time Protocol (PTP) engine to
+AD4-    decide its own state automatically, and a PTP transportation layer
+AD4-    to carry the PTP timing and various quality messages. The
+AD4-    configuration parameters and state data sets of IEEE 1588-2008 are
+AD4-    numerous.
+AD4-
+AD4-    According to the concepts described in +AFs-RFC3444+AF0-, IEEE 158=
8-2008
+AD4-    itself provides an information model in its normative
+AD4-    specifications for the data sets (in IEEE 1588-2008 clause 8). Som=
e
+AD4-    standardization organizations including the IETF have specified
+AD4-    data models in MIBs (Management Information Bases) for IEEE 1588-
+AD4-    2008 data sets (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0-). The=
se MIBs are
+AD4-    typically focused on retrieval of state data using the Simple
+AD4-    Network Management Protocol (SNMP), furthermore, configuration of
+AD4-    PTP data sets is not considered in +AFs-RFC8173+AF0-.
+AD4-
+AD4-    Some service providers and applications require that the managemen=
t
+AD4-    of the IEEE 1588-2008 synchronization network be flexible and more
+AD4-    Internet-based (typically overlaid on their transport networks).
+AD4-    Software Defined Network (SDN) is another driving factor, which
+AD4-    demands an improved configuration capability of synchronization
+AD4-    networks.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
+AD4-    configuration and state data manipulated by network management
+AD4-    protocols like the Network Configuration Protocol (NETCONF)
+AD4-    +AFs-RFC6241+AF0-. A small set of built-in data types are defined =
in
+AD4-    +AFs-RFC6020+AF0-, and a collection of common data types are furth=
er
+AD4-    defined in +AFs-RFC6991+AF0-. Advantages of YANG include Internet =
based
+AD4-    configuration capability, validation, rollback and so on. All of
+AD4-    these characteristics make it attractive to become another
+AD4-    candidate modeling language for IEEE 1588-2008.
+AD4-
+AD4- NEW:
+AD4-
+AD4-    IEEE 1588-2008 is a time protocol that provides high precision tim=
e
+AD4-    synchronization as fine as nano-seconds.
+AD4-
+AD4-    IEEE 1588-2008 itself provides an information model in its
normative
+AD4-    specifications for the data sets (IEEE 1588-2008 clause 8).
+AD4-    Standard information models (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021=
AS+AF0-) have
been
+AD4-    previously defined as MIBs focused on the retrieval of state data
using
+AD4-    SNMP +AFs-RFC1157+AF0-.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
configuration
+AD4-    and state data manipulated by network management protocols like
NETCONF
+AD4-    +AFs-RFC6241+AF0-.
+AD4-
+AD4- 2. Can we refer to the system as simply PTP rather than IEEE
1588(-2008)?
+AD4- +AFs-YJ+AF0- Advice from IEEE 1588 is, we need to use +ACI-1588-2008+=
ACI- as much as
possible to help clarify that the scope of this YANG is limited to the publ=
ished 1588 standard.
+AD4-
+AD4-
+AD4- 3. There is insufficient spacing here to separate the terms from thei=
r
definitions:
+AD4- OLD
+AD4-
+AD4-    PTP dataset  Structured attributes of clocks (an OC, BC or TC) use=
d
+AD4-    for PTP protocol decisions and for providing values for PTP messag=
e
+AD4-    fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance A PTP implementation in the device (i.e., an OC or BC=
)
+AD4-    represented by a specific PTP dataset.
+AD4-
+AD4- NEW
+AD4-
+AD4-    PTP dataset
+AD4-      Structured attributes of clocks (an OC, BC or TC) used
+AD4-      for PTP protocol decisions and for providing values for PTP
message
+AD4-      fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance
+AD4-      A PTP implementation in the device (i.e., an OC or BC)
+AD4-      represented by a specific PTP dataset.
+AD4- +AFs-YJ+AF0- OK.
+AD4-
+AD4- 4. There's a singular/plural mismatch here:
+AD4-
+AD4-    module. Query and configuration of device wide or port specific
+AD4-    configuration information and clock data set is described for this
+AD4-    version.
+AD4- +AFs-YJ+AF0- Good, we will change 'is' to 'are'.
+AD4-
+AD4- and here:
+AD4-
+AD4-    Query and configuration of clock information include:
+AD4-
+AD4-
+AD4- 5. The choice of uint16 as instance-number limits implementations to
65536 distinct instances.
+AD4-    While I have a hard time imagining a system with more than 65536
PTP instances, I would prefer to avoid imposing arbitrary limits.
+AD4-    I would recommend changing instance-number to a string (and
renaming it to instance-name or just name).
+AD4- +AFs-YJ+AF0- The 1588-2008 supports multiple instances of PTP, but it=
 is
ambiguous in its organization of those PTP instances, especially with regar=
d to management.
+AD4-  In the 1588 new revision, there is an explicit list of PTP instances=
,
and that list is indexed using a number (not name). Thus to align with the =
new revision, we need to keep it instance-number.
+AD4-  If 65536 limit is a concern, how about change it to uint32, any
concerns?
+AD4-
+AD4-
+AD4- 6. I still recommend removing -ds from the YANG element names that
still include it. It doesn't appear to add any value.
+AD4- +AFs-YJ+AF0- Rodney's opinion: the value of using 'ds' is that the 15=
88
document on which this YANG model is based uses +ACI-DefaultDS+ACI- as a te=
rm.
PTP experts even say +ACI-default dee ess+ACI- verbally when referring to t=
his data. If we changed this to just +ACI-default+ACI-, PTP experts might a=
ssume that we are referring to something entirely new to YANG. Thus, to ali=
gn with 1588-2008, the same set of terminologies are used.
+AD4-
+AD4- 7. What+ADs-s the relevance of injection attacks relevant to this YAN=
G
module?
+AD4- +AFs-YJ+AF0- This is a general statement which is applicable to this =
YANG
module and other YANG modules as well.
+AD4- Thanks again,
+AD4- Yuanlong
+AD4-
+AD4- Alex
+AD4-
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-
+AD4- From: netmod +ADw-netmod-bounces+AEA-ietf.org+AD4- on behalf of Jiang=
yuanlong
+ADw-jiangyuanlong+AEA-huawei.com+AD4-
+AD4- Sent: Friday, 27 October 2017 3:21 p.m.
+AD4- To: tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Dear all,
+AD4-
+AD4- Based on all the comments we received during the WG Last Call process=
,
we've updated the document to version 6.
+AD4- We believe all the LC comments are resolved and the consensus is
reflected in this new revision.
+AD4- Many thanks to Martin, Tal, Opher, Alex, John and many others who had
reviewed and commented on this draft.
+AD4-
+AD4- Cheers,
+AD4- Yuanlong on behalf of all coauthors
+AD4-
+AD4- -----Original Message-----
+AD4- From: internet-drafts+AEA-ietf.org +AFs-mailto:internet-drafts+AEA-ie=
tf.org+AF0-
+AD4- Sent: Friday, October 27, 2017 9:48 AM
+AD4- To: Xian Liu+ADs- Rodney Cummings+ADs- rodney.cummings+AEA-ni.com+ADs=
- Jiangyuanlong+ADs-
Xujinchun
+AD4- Subject: New Version Notification for
draft-ietf-tictoc-1588v2-yang-06.txt
+AD4-
+AD4-
+AD4- A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
+AD4- has been successfully submitted by Yuanlong Jiang and posted to the
IETF repository.
+AD4-
+AD4- Name:           draft-ietf-tictoc-1588v2-yang
+AD4- Revision:       06
+AD4- Title:          YANG Data Model for IEEE 1588-2008
+AD4- Document date:  2017-10-26
+AD4- Group:          tictoc
+AD4- Pages:          30
+AD4- URL:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-www.ietf.org=
+AF8-internet-2Ddrafts+AF8-draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06.tx+AC=
Y-d+AD0-DwIFgQ+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+AC=
Y-r+AD0-WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-=
rtyk18e89Fir82kLxurUC4yXciXZMIqStw+ACY-s+AD0-N0N5kBPcGMivXWwspHEOc-bP0mbYpk=
Ku2IvM2Asyf+AF8-8+ACY-e+AD0-
t
+AD4- Status:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-datatracker.=
ietf.org+AF8-doc+AF8-draft-2Dietf-2Dtictoc-2D1588v2-2Dyang+AF8AJg-d+AD0-DwI=
FgQ+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-WA7=
1sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e89Fi=
r82kLxurUC4yXciXZMIqStw+ACY-s+AD0-aYlovx+AF8-kTQtAiJAUMTJn8NCRZQIi+AF8-jEVN=
a-tC+AF8-5HFlk+ACY-e+AD0-
+AD4- Htmlized:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-tools.ietf.o=
rg+AF8-html+AF8-draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06+ACY-d+AD0-DwIFgQ=
+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-WA71sf=
2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e89Fir82=
kLxurUC4yXciXZMIqStw+ACY-s+AD0-j1aDjiU7AeuEV-p20PNwNpvZPrGSbBiHLHta7q05pak+=
ACY-e+AD0-
+AD4- Htmlized:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-datatracker.=
ietf.org+AF8-doc+AF8-html+AF8-draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06+AC=
Y-d+AD0-DwIFgQ+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+AC=
Y-r+AD0-WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-=
rtyk18e89Fir82kLxurUC4yXciXZMIqStw+ACY-s+AD0-7tYOv1M+AF8-EYHCPG1MiOq3BVl7vp=
B0w-LSiDYcQHM4ayM+ACY-e+AD0-
+AD4- Diff:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-www.ietf.org=
+AF8-rfcdiff-3Furl2-3Ddraft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06+ACY-d+AD0-=
DwIFgQ+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-=
WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e8=
9Fir82kLxurUC4yXciXZMIqStw+ACY-s+AD0-Z12Xm+AF8-2k7cEAlV7lFQb+AF8-zw7A-D-HL7=
7C-Kuy2BgyCHA+ACY-e+AD0-
+AD4-
+AD4- Abstract:
+AD4-    This document defines a YANG data model for the configuration of
+AD4-    IEEE 1588-2008 devices and clocks, and also retrieval of the
+AD4-    configuration information, data set and running states of IEEE
+AD4-    1588-2008 clocks.
+AD4-
+AD4-
+AD4-
+AD4-
+AD4- 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.
+AD4-
+AD4- The IETF Secretariat
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-www.ie=
tf.org+AF8-mailman+AF8-listinfo+AF8-netmod+ACY-d+AD0-DwIFgQ+ACY-c+AD0-I+AF8=
-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-WA71sf2o7Dw7CbYhFt24DP=
jt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e89Fir82kLxurUC4yXciXZMI=
qStw+ACY-s+AD0-cUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4+ACY-e+AD0-
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-www.ie=
tf.org+AF8-mailman+AF8-listinfo+AF8-netmod+ACY-d+AD0-DwIFgQ+ACY-c+AD0-I+AF8=
-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-WA71sf2o7Dw7CbYhFt24DP=
jt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e89Fir82kLxurUC4yXciXZMI=
qStw+ACY-s+AD0-cUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4+ACY-e+AD0-


From nobody Tue Nov 21 19:18:35 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B22129C1D; Tue, 21 Nov 2017 19:18:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level: 
X-Spam-Status: No, score=-3.647 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, URG_BIZ=0.573, 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 1ZFjuhKKOp-5; Tue, 21 Nov 2017 19:18:29 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66DA6129483; Tue, 21 Nov 2017 19:18:29 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E688E7951ADF5; Wed, 22 Nov 2017 03:18:25 +0000 (GMT)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 03:18:26 +0000
Received: from DGGEML506-MBX.china.huawei.com ([169.254.9.229]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0361.001; Wed, 22 Nov 2017 11:18:17 +0800
From: Xujinchun 
To: Rodney Cummings , Jiangyuanlong , "tictoc@ietf.org" , "Alex Campbell" , Karen O'Donoghue 
CC: Xian Liu , "netmod@ietf.org" 
Thread-Topic: Using instance-number or instance-name issue - RE:  WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTYgRNRHUhnxRFrEa8qWOD401b+KMembsAgAEe08A=
Date: Wed, 22 Nov 2017 03:18:16 +0000
Message-ID: <01992158370DC941ABFFAB7233E2346046348DAB@dggeml506-mbx.china.huawei.com>
References: +ADw-150906887826.22201.5033565145094897903.idtracker+AEA-ietfa.amsl.com+AD4-, +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB604A97+AEA-dggeml507-mbx.china.huawei.com+AD4- +ADw-1509329710965.52658+AEA-Aviatnet.com+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62C3F8+AEA-dggeml507-mbs.china.huawei.com+AD4- +ADw-02fb01d35893+ACQ-2081f160+ACQ-4001a8c0+AEA-gateway.2wire.net+AD4- +ADw-3B0A1BED22CAD649A1B3E97BE5DDD68BBB62E74B+AEA-dggeml507-mbs.china.huawei.com+AD4- <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.163.99]
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Using instance-number or instance-name issue - RE: 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: Wed, 22 Nov 2017 03:18:32 -0000

Hi Rodney,

In my opinion, instance-name or instance-number does not matter if the numb=
er of instances are small. But if the instances may grow into hundreds or m=
ore in scale, then string should not be a choice.

We know how awkward it is to store and sort out a key of string compared wi=
th an integer.

Thanks

Jinchun XU

-----+kK5O9lOfTvY------
+U9FO9k66-: Rodney Cummings +AFs-mailto:rodney.cummings+AEA-ni.com+AF0-=20
+U9GQAWX2lfQ-: 2017+XnQ-11+Zwg-22+ZeU- 1:56
+ZTZO9k66-: Jiangyuanlong+ADs- tictoc+AEA-ietf.org+ADs- Alex Campbell+ADs- =
Karen O'Donoghue
+YoSQAQ-: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+TjuYmA-: RE: Using instance-number or instance-name issue - RE: WG Last Ca=
ll resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Hi Yuanlong,

I have no concerns with instance-number, as that is what the upcoming 1588 =
revision outlines for management.

I also have no strong objections against changing instance-number to instan=
ce-name. If we do that, I think it would be best to make the same change in=
 the upcoming 1588 revision. I asked the 1588 working group for opinion, bu=
t I haven't heard back on that.

All things being equal, my preference is to go with instance-number.

Rodney

-----Original Message-----
From: Jiangyuanlong +AFs-mailto:jiangyuanlong+AEA-huawei.com+AF0-=20
Sent: Monday, November 20, 2017 7:34 AM
To: tictoc+AEA-ietf.org+ADs- Alex Campbell +ADs- Rodney Cummings +ADs- Kare=
n O'Donoghue=20
Cc: Xian Liu +ADs- Xujinchun +ADs- netmod+AEA-ietf.org
Subject: Using instance-number or instance-name issue - RE: WG Last Call re=
solutions incorporated in draft-ietf-tictoc-1588v2-yang-06

Hi all,

Item +ACM-5 below is the last open issue we discussed both in emails and in=
 IEEE 1588 mailing list on draft-ietf-tictoc-1588v2-yang. =20
In a summary: in draft-ietf-tictoc-1588v2-yang, list instance-list has a ke=
y of +ACI-instance-number+ACI-, but there were discussions whether to use i=
nstance-name (a string) instead.

Currently, +ACI-instance-number+ACI- in draft-ietf-tictoc-1588v2-yang-06 al=
igns well with the texts in the new revision of IEEE 1588 (D1.2/2017):=20
   +ACI-The instanceList is indexed using a number that is unique per PTP I=
nstance within the PTP Node, applicable to the=20
   management context only (i.e. not used in PTP messages). The domainNumbe=
r of the PTP Instance must not be used as the index=20
   to instanceList, since it is possible for a PTP Node to contain multiple=
 PTP Instances using the same domainNumber.+ACI-

The main requirement of instanceList in IEEE 1588 is the uniqueness of its =
index, and the +ACI-key+ACI- statement of YANG serves this purpose very wel=
l.

That is, when instance-number is used as a key, a PTP Node with multiple PT=
P Instances cannot use the same instance-number value for these PTP Instanc=
es (just according to YANG semantics).

Using instance-name (string) can also guarantee the uniqueness of the index=
 of a list, but compared with an integer, a string is usually more complex =
to process and store. If instance-name is modeled as an arbitrary length of=
 string, there is even a risk of buffer-overflow attack.

Furthermore, it should be noted that draft-ietf-tictoc-1588v2-yang is targe=
ted at IEEE 1588-2008, for which most products today only have a single PTP=
 instance, and not have a name for this instance, it seems quite weird to i=
ntroduce a name for this instance.

Therefore, I would suggest we keep on using instance-number as a key. But a=
s 65536 limit is a concern, I further suggest to change its type to uint32.

Any comments or concerns on this suggestion to move forward?

Thanks,
Yuanlong

----- Original Message -----
From: +ACI-Jiangyuanlong+ACI- +ADw-jiangyuanlong+AEA-huawei.com+AD4-
To: +ACI-Alex Campbell+ACI- +ADw-Alex.Campbell+AEA-Aviatnet.com+AD4AOw- +AD=
w-tictoc+AEA-ietf.org+AD4-
Cc: +ACI-Xian Liu+ACI- +ADw-lene.liuxian+AEA-foxmail.com+AD4AOw- +ACI-Xujin=
chun+ACI-
+ADw-xujinchun+AEA-huawei.com+AD4AOw- +ADw-netmod+AEA-ietf.org+AD4-
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


+AD4- Hi Alex,
+AD4-
+AD4- Sorry for a late reply as I spent the last week for an urgent busines=
s
trip.
+AD4- Please see my comments in line with +AFs-YJ+AF0-
+AD4-
+AD4- Thanks,
+AD4- Yuanlong
+AD4-
+AD4- -----Original Message-----
+AD4- From: Alex Campbell +AFs-mailto:Alex.Campbell+AEA-Aviatnet.com+AF0-
+AD4- Sent: Monday, October 30, 2017 10:15 AM
+AD4- To: Jiangyuanlong+ADs- tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Hi,
+AD4- I've reviewed this latest draft and have some more comments.
+AD4-
+AD4- 1. I find the introduction to be unnecessarily wordy+ADs- it feels li=
ke it
was written with a view of not missing any information out, rather than try=
ing to keep it concise.
+AD4-    For example, there is no need to elaborate on YANG data types here=
.
It is also not here to sell YANG.
+AD4-
+AD4- +AFs-YJ+AF0- Yes, we are trying to give some introductory information=
 for an
outsider who may not be familiar with PTP or YANG, and explain why a YANG f=
or PTP is needed. The juicy part of this document is its YANG module, and p=
eople can skip all the other texts if they are familiar with PTP and YANG.
+AD4- Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear message f=
rom the TICTOC chairs to introduce any big changes at this last call stage.
+AD4-
+AD4-
+AD4- OLD:
+AD4-
+AD4-    As a synchronization protocol, IEEE 1588-2008 +AFs-IEEE1588+AF0- i=
s widely
+AD4-    supported in the carrier networks, industrial networks, automotive
+AD4-    networks, and many other applications. It can provide high
+AD4-    precision time synchronization as fine as nano-seconds. The
+AD4-    protocol depends on a Precision Time Protocol (PTP) engine to
+AD4-    decide its own state automatically, and a PTP transportation layer
+AD4-    to carry the PTP timing and various quality messages. The
+AD4-    configuration parameters and state data sets of IEEE 1588-2008 are
+AD4-    numerous.
+AD4-
+AD4-    According to the concepts described in +AFs-RFC3444+AF0-, IEEE 158=
8-2008
+AD4-    itself provides an information model in its normative
+AD4-    specifications for the data sets (in IEEE 1588-2008 clause 8). Som=
e
+AD4-    standardization organizations including the IETF have specified
+AD4-    data models in MIBs (Management Information Bases) for IEEE 1588-
+AD4-    2008 data sets (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021AS+AF0-). The=
se MIBs are
+AD4-    typically focused on retrieval of state data using the Simple
+AD4-    Network Management Protocol (SNMP), furthermore, configuration of
+AD4-    PTP data sets is not considered in +AFs-RFC8173+AF0-.
+AD4-
+AD4-    Some service providers and applications require that the managemen=
t
+AD4-    of the IEEE 1588-2008 synchronization network be flexible and more
+AD4-    Internet-based (typically overlaid on their transport networks).
+AD4-    Software Defined Network (SDN) is another driving factor, which
+AD4-    demands an improved configuration capability of synchronization
+AD4-    networks.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
+AD4-    configuration and state data manipulated by network management
+AD4-    protocols like the Network Configuration Protocol (NETCONF)
+AD4-    +AFs-RFC6241+AF0-. A small set of built-in data types are defined =
in
+AD4-    +AFs-RFC6020+AF0-, and a collection of common data types are furth=
er
+AD4-    defined in +AFs-RFC6991+AF0-. Advantages of YANG include Internet =
based
+AD4-    configuration capability, validation, rollback and so on. All of
+AD4-    these characteristics make it attractive to become another
+AD4-    candidate modeling language for IEEE 1588-2008.
+AD4-
+AD4- NEW:
+AD4-
+AD4-    IEEE 1588-2008 is a time protocol that provides high precision tim=
e
+AD4-    synchronization as fine as nano-seconds.
+AD4-
+AD4-    IEEE 1588-2008 itself provides an information model in its
normative
+AD4-    specifications for the data sets (IEEE 1588-2008 clause 8).
+AD4-    Standard information models (e.g. +AFs-RFC8173+AF0-, +AFs-IEEE8021=
AS+AF0-) have
been
+AD4-    previously defined as MIBs focused on the retrieval of state data
using
+AD4-    SNMP +AFs-RFC1157+AF0-.
+AD4-
+AD4-    YANG +AFs-RFC6020+AF0- is a data modeling language used to model
configuration
+AD4-    and state data manipulated by network management protocols like
NETCONF
+AD4-    +AFs-RFC6241+AF0-.
+AD4-
+AD4- 2. Can we refer to the system as simply PTP rather than IEEE
1588(-2008)?
+AD4- +AFs-YJ+AF0- Advice from IEEE 1588 is, we need to use +ACI-1588-2008+=
ACI- as much as
possible to help clarify that the scope of this YANG is limited to the publ=
ished 1588 standard.
+AD4-
+AD4-
+AD4- 3. There is insufficient spacing here to separate the terms from thei=
r
definitions:
+AD4- OLD
+AD4-
+AD4-    PTP dataset  Structured attributes of clocks (an OC, BC or TC) use=
d
+AD4-    for PTP protocol decisions and for providing values for PTP messag=
e
+AD4-    fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance A PTP implementation in the device (i.e., an OC or BC=
)
+AD4-    represented by a specific PTP dataset.
+AD4-
+AD4- NEW
+AD4-
+AD4-    PTP dataset
+AD4-      Structured attributes of clocks (an OC, BC or TC) used
+AD4-      for PTP protocol decisions and for providing values for PTP
message
+AD4-      fields, see Section 8 of +AFs-IEEE1588+AF0-.
+AD4-
+AD4-    PTP instance
+AD4-      A PTP implementation in the device (i.e., an OC or BC)
+AD4-      represented by a specific PTP dataset.
+AD4- +AFs-YJ+AF0- OK.
+AD4-
+AD4- 4. There's a singular/plural mismatch here:
+AD4-
+AD4-    module. Query and configuration of device wide or port specific
+AD4-    configuration information and clock data set is described for this
+AD4-    version.
+AD4- +AFs-YJ+AF0- Good, we will change 'is' to 'are'.
+AD4-
+AD4- and here:
+AD4-
+AD4-    Query and configuration of clock information include:
+AD4-
+AD4-
+AD4- 5. The choice of uint16 as instance-number limits implementations to
65536 distinct instances.
+AD4-    While I have a hard time imagining a system with more than 65536
PTP instances, I would prefer to avoid imposing arbitrary limits.
+AD4-    I would recommend changing instance-number to a string (and
renaming it to instance-name or just name).
+AD4- +AFs-YJ+AF0- The 1588-2008 supports multiple instances of PTP, but it=
 is
ambiguous in its organization of those PTP instances, especially with regar=
d to management.
+AD4-  In the 1588 new revision, there is an explicit list of PTP instances=
,
and that list is indexed using a number (not name). Thus to align with the =
new revision, we need to keep it instance-number.
+AD4-  If 65536 limit is a concern, how about change it to uint32, any
concerns?
+AD4-
+AD4-
+AD4- 6. I still recommend removing -ds from the YANG element names that
still include it. It doesn't appear to add any value.
+AD4- +AFs-YJ+AF0- Rodney's opinion: the value of using 'ds' is that the 15=
88
document on which this YANG model is based uses +ACI-DefaultDS+ACI- as a te=
rm.
PTP experts even say +ACI-default dee ess+ACI- verbally when referring to t=
his data. If we changed this to just +ACI-default+ACI-, PTP experts might a=
ssume that we are referring to something entirely new to YANG. Thus, to ali=
gn with 1588-2008, the same set of terminologies are used.
+AD4-
+AD4- 7. What+ADs-s the relevance of injection attacks relevant to this YAN=
G
module?
+AD4- +AFs-YJ+AF0- This is a general statement which is applicable to this =
YANG
module and other YANG modules as well.
+AD4- Thanks again,
+AD4- Yuanlong
+AD4-
+AD4- Alex
+AD4-
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-
+AD4- From: netmod +ADw-netmod-bounces+AEA-ietf.org+AD4- on behalf of Jiang=
yuanlong
+ADw-jiangyuanlong+AEA-huawei.com+AD4-
+AD4- Sent: Friday, 27 October 2017 3:21 p.m.
+AD4- To: tictoc+AEA-ietf.org
+AD4- Cc: Xian Liu+ADs- Xujinchun+ADs- netmod+AEA-ietf.org
+AD4- Subject: +AFs-netmod+AF0- WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
+AD4-
+AD4- Dear all,
+AD4-
+AD4- Based on all the comments we received during the WG Last Call process=
,
we've updated the document to version 6.
+AD4- We believe all the LC comments are resolved and the consensus is
reflected in this new revision.
+AD4- Many thanks to Martin, Tal, Opher, Alex, John and many others who had
reviewed and commented on this draft.
+AD4-
+AD4- Cheers,
+AD4- Yuanlong on behalf of all coauthors
+AD4-
+AD4- -----Original Message-----
+AD4- From: internet-drafts+AEA-ietf.org +AFs-mailto:internet-drafts+AEA-ie=
tf.org+AF0-
+AD4- Sent: Friday, October 27, 2017 9:48 AM
+AD4- To: Xian Liu+ADs- Rodney Cummings+ADs- rodney.cummings+AEA-ni.com+ADs=
- Jiangyuanlong+ADs-
Xujinchun
+AD4- Subject: New Version Notification for
draft-ietf-tictoc-1588v2-yang-06.txt
+AD4-
+AD4-
+AD4- A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
+AD4- has been successfully submitted by Yuanlong Jiang and posted to the
IETF repository.
+AD4-
+AD4- Name:           draft-ietf-tictoc-1588v2-yang
+AD4- Revision:       06
+AD4- Title:          YANG Data Model for IEEE 1588-2008
+AD4- Document date:  2017-10-26
+AD4- Group:          tictoc
+AD4- Pages:          30
+AD4- URL:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-www.ietf.org=
+AF8-internet-2Ddrafts+AF8-draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06.tx+AC=
Y-d+AD0-DwIFgQ+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+AC=
Y-r+AD0-WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-=
rtyk18e89Fir82kLxurUC4yXciXZMIqStw+ACY-s+AD0-N0N5kBPcGMivXWwspHEOc-bP0mbYpk=
Ku2IvM2Asyf+AF8-8+ACY-e+AD0-
t
+AD4- Status:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-datatracker.=
ietf.org+AF8-doc+AF8-draft-2Dietf-2Dtictoc-2D1588v2-2Dyang+AF8AJg-d+AD0-DwI=
FgQ+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-WA7=
1sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e89Fi=
r82kLxurUC4yXciXZMIqStw+ACY-s+AD0-aYlovx+AF8-kTQtAiJAUMTJn8NCRZQIi+AF8-jEVN=
a-tC+AF8-5HFlk+ACY-e+AD0-
+AD4- Htmlized:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-tools.ietf.o=
rg+AF8-html+AF8-draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06+ACY-d+AD0-DwIFgQ=
+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-WA71sf=
2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e89Fir82=
kLxurUC4yXciXZMIqStw+ACY-s+AD0-j1aDjiU7AeuEV-p20PNwNpvZPrGSbBiHLHta7q05pak+=
ACY-e+AD0-
+AD4- Htmlized:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-datatracker.=
ietf.org+AF8-doc+AF8-html+AF8-draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06+AC=
Y-d+AD0-DwIFgQ+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+AC=
Y-r+AD0-WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-=
rtyk18e89Fir82kLxurUC4yXciXZMIqStw+ACY-s+AD0-7tYOv1M+AF8-EYHCPG1MiOq3BVl7vp=
B0w-LSiDYcQHM4ayM+ACY-e+AD0-
+AD4- Diff:
https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-www.ietf.org=
+AF8-rfcdiff-3Furl2-3Ddraft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06+ACY-d+AD0-=
DwIFgQ+ACY-c+AD0-I+AF8-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-=
WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e8=
9Fir82kLxurUC4yXciXZMIqStw+ACY-s+AD0-Z12Xm+AF8-2k7cEAlV7lFQb+AF8-zw7A-D-HL7=
7C-Kuy2BgyCHA+ACY-e+AD0-
+AD4-
+AD4- Abstract:
+AD4-    This document defines a YANG data model for the configuration of
+AD4-    IEEE 1588-2008 devices and clocks, and also retrieval of the
+AD4-    configuration information, data set and running states of IEEE
+AD4-    1588-2008 clocks.
+AD4-
+AD4-
+AD4-
+AD4-
+AD4- 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.
+AD4-
+AD4- The IETF Secretariat
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-www.ie=
tf.org+AF8-mailman+AF8-listinfo+AF8-netmod+ACY-d+AD0-DwIFgQ+ACY-c+AD0-I+AF8=
-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-WA71sf2o7Dw7CbYhFt24DP=
jt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e89Fir82kLxurUC4yXciXZMI=
qStw+ACY-s+AD0-cUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4+ACY-e+AD0-
+AD4-
+AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8A=
XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
+AD4- netmod mailing list
+AD4- netmod+AEA-ietf.org
+AD4- https://urldefense.proofpoint.com/v2/url?u+AD0-https-3A+AF8AXw-www.ie=
tf.org+AF8-mailman+AF8-listinfo+AF8-netmod+ACY-d+AD0-DwIFgQ+ACY-c+AD0-I+AF8=
-0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA+ACY-r+AD0-WA71sf2o7Dw7CbYhFt24DP=
jt3lJuupswWYdnboKbZ8k+ACY-m+AD0-oQTuhx0E+AF8-rtyk18e89Fir82kLxurUC4yXciXZMI=
qStw+ACY-s+AD0-cUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4+ACY-e+AD0-


From nobody Wed Nov 22 00:40: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 94A7C128AFE for ; Wed, 22 Nov 2017 00:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFUCPivG1EUS for ; Wed, 22 Nov 2017 00:40:29 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E4C431289C3 for ; Wed, 22 Nov 2017 00:40:28 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 675131AE034F; Wed, 22 Nov 2017 09:40:26 +0100 (CET)
Date: Wed, 22 Nov 2017 09:39:04 +0100 (CET)
Message-Id: <20171122.093904.670536605936490886.mbj@tail-f.com>
To: mjethanandani@gmail.com
Cc: netmod@ietf.org, agarwaso@cisco.com, kll@spritelink.net, kll@dev.terastrm.net, jhaas@juniper.net
From: Martin Bjorklund 
In-Reply-To: <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com>
References: <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net> <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@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] IETF 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: Wed, 22 Nov 2017 08:40:31 -0000

TWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+IHdyb3RlOg0KPiBb
VGFraW5nIHRoZSBkaXNjdXNzaW9uIHRvIHRoZSBtYWlsaW5nIGxpc3RdDQo+IA0KPiBUaGUgc3Vt
bWFyeSBvZiB0aGUgZGlzY3Vzc2lvbiBoYXBwZW5pbmcgb24gYSBwcml2YXRlIHRocmVhZCBoYXMg
dG8NCj4gZG8gd2l0aCB0aGUg4oCYYW554oCZIGNvbnRhaW5lciAobm93IGxlYWYpIGRlZmluaXRp
b24gaW4gdGhlIEFDTCBtb2RlbA0KPiBmb3Igc29tZXRoaW5nIHRoYXQgbWF0Y2hlcyBhbnl0aGlu
ZywgbXVjaCBsaWtlIGEg4oCYKuKAmSB3b3VsZCBkbyBpbg0KPiByZWdleC4gVGhlIGRpc2N1c3Np
b24gaGFzIGNvbWUgZG93biB0bzogDQo+IA0KPiAtIGxlYXZlIHRoZSBkZWZpbml0aW9uIGFzIGlz
LCBzbyB1c2VycyB3b3VsZCBoYXZlIHRvIGV4cGxpY2l0bHkgZGVmaW5lIGl0DQo+ICAgcHJvOiBJ
dCBpcyBleHBsaWNpdCBhbmQgdGhlcmUgd291bGQgYmUgbm8gY29uZnVzaW9uIGFib3V0IGl0cw0K
PiAgIHByZXNlbmNlIG9yIGFic2VuY2UuDQoNCj4gICBjb246IEl0IGlzIHZlcmJvc2UsIGluIHRo
YXQgZXZlcnkgYWNjZXNzIGxpc3QgZW50cnkgd291bGQgaGF2ZSB0bw0KPiAgIGRlZmluZSBpdC4N
Cj4gDQo+IC0gcmVtb3ZlIHRoZSBhbnkgZGVmaW5pdGlvbiwgc28gYW4gYWJzZW5jZSBvZiB0aGUg
ZGVmaW5pdGlvbiBpbXBsaWVzDQo+ICAgbWF0Y2ggb24gYWxsLg0KDQpJdCB3b3VsZG4ndCBiZSB0
aGUgKmFic2VuY2UqIHRoYXQgaW1wbGllcyBtYXRjaCBvbiBhbGwsIGJ1dCByYXRoZXIgaXQNCmlz
IHRoZSBleHBsaWNpdCBzZXR0aW5nIG9mIHRoZSB0eXBlIHRvICdhbnktYWNsJyB0aGF0IG1lYW5z
IG1hdGNoIG9uDQphbGw6DQoNCiAgPGFjbD4NCiAgICA8bmFtZT5teS1hbnktYWNsPC9uYW1lPg0K
ICAgIDx0eXBlPmFueS1hY2w8L3R5cGU+DQogIDwvYWNsPg0KDQpIYXZpbmcgdG8gYWxzbyBkZWZp
bmUgdGhlIGxlYWYgImFueSIgYXMgd2VsbCB3b3VsZCBqdXN0IGJlIHJlZHVuZGFudDoNCg0KICA8
YWNsPg0KICAgIDxuYW1lPm15LWFueS1hY2w8L25hbWU+DQogICAgPHR5cGU+YW55LWFjbDwvdHlw
ZT4NCiAgICA8YWNlcz4NCiAgICAgIDxhY2U+DQogICAgICAgIDxuYW1lPm15LWFueS1ydWxlPC9u
YW1lPg0KICAgICAgICA8YW55Lz4NCiAgICAgIDwvYWNlPg0KICAgIDwvYWNlcz4NCiAgPC9hY2w+
DQoNCg0KQlRXLCBJIHN1cHBvcnQgS3Jpc3RpYW4ncyBzdWdnZXN0aW9uIG9mIGhhdmUganVzdCB0
aGUgIm5hbWUiIGFzIHRoZQ0Ka2V5IGluIHRoZSAiYWNsIiBsaXN0LCBhbmQgbWFraW5nICJ0eXBl
IiBtYW5kYXRvcnkuDQoNCkkgYWxzbyBzdWdnZXN0IHlvdSByZW1vdmUgcmVkdW5kYW50IHByZWZp
eGVzIGluIHRoZSBsZWFmIG5hbWVzLA0KZS5nLiBhcyBhYm92ZSBzL2FjbC10eXBlL3R5cGUvIHMv
YWNsLW5hbWUvbmFtZS8gYW5kDQpzL3J1bGUtbmFtZS9uYW1lLy4gIFRoaXMgaXMgaG93IHdlIHVz
dWFsbHkgbmFtZSBub2RlcyBpbiB0aGUgSUVURiBZQU5HDQptb2RlbHMuDQoNCj4gVGhlIHRleHQg
aW4gdGhlIGRyYWZ0IHdvdWxkIGhhdmUgdG8gYmUgdXBkYXRlZCB0bw0KPiAgIHN0YXRlIHRoaXMs
IGFuZCBZQU5HIHBhcnNlcnMgd291bGQgbmVlZCB0byB3YXRjaCBvdXQgZm9yIHRoZQ0KPiAgIG5v
bi1kZWZpbml0aW9uIGluIHRoZSBtYXRjaCBjb250YWluZXIuDQo+IA0KPiBPcGluaW9uPyBQcmVm
ZXJlbmNlcz8NCj4gDQo+IHAucy4gQ3VycmVudCBDTEkgY29uZmlndXJhdGlvbnMgcmVxdWlyZSBl
eHBsaWNpdCBkZWNsYXJhdGlvbiBvZiDigJhhbnnigJkuDQoNCkJ1dCBkbyB0aGV5IGFsc28gaGF2
ZSB0aGUgYWNsIHR5cGUgZGVmaW5pdGlvbj8NCg0KDQovbWFydGluDQoNCg0KDQo+IA0KPiA+IE9u
IE5vdiAyMCwgMjAxNywgYXQgMjoyMCBQTSwgSmVmZiBIYWFzIDxqaGFhc0BqdW5pcGVyLm5ldD4g
d3JvdGU6DQo+ID4gDQo+ID4+IA0KPiA+PiBPbiBOb3YgMjAsIDIwMTcsIGF0IDQ6NTQgUE0sIEty
aXN0aWFuIExhcnNzb24gPGtyaXN0aWFuQHNwcml0ZWxpbmsubmV0PiB3cm90ZToNCj4gPj4gDQo+
ID4+IA0KPiA+PiANCj4gPj4gT24gMjAxNy0xMS0yMCAxODoyNiwgSmVmZiBIYWFzIHdyb3RlOg0K
PiA+Pj4gSU1PLCB0aGUgY29udGVudGlvbiBoZXJlIGlzIGEgY29uc2VxdWVuY2Ugb2YgcHJvb2Yg
YnkgYXNzZXJ0aW9uLiA+DQo+ID4+Pj4gT24gTm92IDE3LCAyMDE3LCBhdCA1OjU2IEFNLCBLcmlz
dGlhbiBMYXJzc29uIDxrbGxAZGV2LnRlcmFzdHJtLm5ldCA8bWFpbHRvOmtsbEBkZXYudGVyYXN0
cm0ubmV0Pj4gd3JvdGU6DQo+ID4+Pj4gDQo+ID4+Pj4+PiANCj4gPj4+Pj4+IENoYW5nZXMgSSdk
IGxpa2UgdG8gc2VlIHRvIHRoaXMgUFI6DQo+ID4+Pj4+PiAqIHJlbW92ZSBhbnktYWNsIGNvbXBs
ZXRlbHkgYXMgaXQgc2VydmVzIG5vIHB1cnBvc2UgKHdlIGFjaGlldmUNCj4gPj4+Pj4+ICB0aGlz
IHRocm91Z2ggYSBBQ0Ugd2l0aCBubyBtYXRjaCBjb25kaXRpb25zKQ0KPiA+Pj4+PiBXaWxsIGxl
dCBKZWZmIHJlc3BvbmQgYXMgaGUgYXJ0aWN1bGF0ZWQgdGhpcyByZXF1aXJlbWVudC4gQWdyZWUg
dGhhdCBtb3N0IHBsYXRmb3JtcyBoYXZlIGRlbnkgYXMgdGhlIGRlZmF1bHQuIEJ1dCB3aGF0IGlm
IHRoZSBhY2UgZW50cnkgaXMgc29tZXRoaW5nIGxpa2UgdGhpczoNCj4gPj4+Pj4gYWNjZXNzLWxp
c3QgMTEgcGVybWl0IHRjcCBhbnkgYW55DQo+ID4+Pj4+IFdvdWxkIHRoZSBhYnNlbmNlIG9mIG1h
dGNoIHJ1bGVzIGZvciBJUCBhZGRyZXNzZXMgaW1wbHkgYW55IGFueT8NCj4gPj4+PiANCj4gPj4+
PiBBbiBhYnNlbmNlIG9mIGFueSBtYXRjaCBtZWFucyBpdCBtYXRjaGVzIG9uIGV2ZXJ5dGhpbmcu
IElmIHRoZXJlIGFyZSBubyBJUCBtYXRjaGVzIGF0IGFsbCwgdGhlbiB5ZXMsIGl0IGltcGxpZXMg
YW55IHNvdXJjZSBvciBkZXN0aW5hdGlvbiBhZGRyZXNzLiBJIGRvbid0IHNlZSB3aHkgd2Ugd291
bGQgbmVlZCB0byBleHBsaWNpdGx5IGhhdmUgYW4gYW55LWFjbCBjb250YWluZXIgb3IgbGVhZiB0
byBwb2ludCB0aGlzIG91dC4gV2l0aCB0aGUgc2FtZSBjb25jZXB0IGFwcGxpZWQgdW5pZm9ybWx5
IHlvdSB3b3VsZCBleHBsaWNpdGx5IGNhbGwgb3V0ICJhbnkiIG1hdGNoZXMgZm9yIGFsbCB0eXBl
cyBvZiBtYXRjaGVzLiBUaGF0IHdvdWxkIGJlIGV4dHJlbWVseSB2ZXJib3NlLg0KPiA+Pj4gV2hl
cmUgaW4gdGhlIG1vZGVsIGRvZXMgaXQgc2F5IHRoYXQgdGhlIGFic2VuY2Ugb2YgYSBtYXRjaGVz
IGNvbnRhaW5lciBpbXBsaWVzIGEgbWF0Y2ggYWxsIHZzLiBtYXRjaCBub25lPw0KPiA+Pj4gV2hl
cmUgaW4gdGhlIG5vcm1hdGl2ZSB0ZXh0IG9mIHRoZSBpbnRlcm5ldC1kcmFmdCBkb2VzIGl0IHNh
eSB0aGF0Pw0KPiA+Pj4gSW4gdGhlIGFic2VuY2Ugb2YgZWl0aGVyIG9mIHRoZSBhYm92ZSwgYW4g
ImFueSIgcmVtb3ZlcyBhbWJpZ3VpdHkuDQo+ID4+PiBGV0lXLCBJJ20gdG90YWxseSBmaW5lIHdp
dGggcmVtb3ZpbmcgdGhlIGFueTsgaG93ZXZlciB5b3UgKk1VU1QqIGNsYXJpZnkgdGhlIGFib3Zl
LiAgUHJlZmVyYWJseSBib3RoIGluIHRoZSBtYXRjaGVzIGNvbnRhaW5lciBhbmQgYWxzbyBpbiB0
aGUgbm9ybWF0aXZlIHRleHQuICBGb3IgbXkgcGFydCwgSSB0aGluayBpdCdzIGVhc2llciBvbiB0
aGUgcGFyc2VyIGlmIHlvdSBiYXNpY2FsbHkgcmVxdWlyZSBhdCBsZWFzdCBvbmUgaXRlbSBmcm9t
IHRoZSBjb250YWluZXIgc28geW91IGRvbid0IGhhdmUgdG8gZGVhbCB3aXRoIG9wdGlvbmFsIGNv
bnRlbnRzLiAgQnV0IEknbSBub3QgdGhlIG9uZSB3cml0aW5nIHlhbmcgcGFyc2VycyBmb3IgYSBs
aXZpbmcuDQo+ID4+IA0KPiA+PiBJIHRoaW5rIGl0J3MgY2xlYXIgdGhhdCBpZiBubyBtYXRjaCBj
b25kaXRpb24gaXMgZGVmaW5lZCBmb3IgYSBwYXJ0aWN1bGFyIChoZWFkZXIpIGZpZWxkIHRoZW4g
dGhhdCBtZWFucyBhbnkgdmFsdWUgd2lsbCBtYXRjaC4gSXQgaXMgb25seSBhbiBleHRlbnNpb24g
b2YgdGhpcyB0aGF0IG5vIG1hdGNoIGNvbmRpdGlvbnMgYXQgYWxsIG1lYW5zIHdlIG1hdGNoIGFu
eSBhbmQgYWxsIHBhY2tldHMuIEkgdGhpbmsgdGhhdCBpcyBsb2dpY2FsLg0KPiA+PiANCj4gPj4g
VGhpcyBjYW4gbmF0dXJhbGx5IGJlIHNwZWxsZWQgb3V0IGluIHRoZSB0ZXh0IDopDQo+ID4gDQo+
ID4gWW91IHRoaW5rIGl0J3MgY2xlYXIsIGJ1dCB3aGVyZSBpcyBpdCBpbiB0aGUgZG9jdW1lbnQg
b3IgbW9kZWw/DQo+ID4gDQo+ID4gT2Ygc3VjaCAiaW1wbGllZCBjbGFyaXR5IiBpcyBtYW55IGlu
dGVyb3AgYnVncyBtYWRlLiA6LVANCj4gPiANCj4gPiAtLSBKZWZmDQo+ID4gDQo+ID4+IA0KPiA+
PiBLaW5kIHJlZ2FyZHMsDQo+ID4+ICBLcmlzdGlhbi4NCj4gDQo+IE1haGVzaCBKZXRoYW5hbmRh
bmkNCj4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCj4gDQo=


From nobody Wed Nov 22 05:16: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 DCCAA127010 for ; Wed, 22 Nov 2017 05:16:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.426
X-Spam-Level: 
X-Spam-Status: No, score=-1.426 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, URG_BIZ=0.573, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=n1k.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmgyLIi7y-Cu for ; Wed, 22 Nov 2017 05:16:27 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 3A95312942F for ; Wed, 22 Nov 2017 05:16:27 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id j12so1973248qtc.9 for ; Wed, 22 Nov 2017 05:16:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n1k.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vbh/nwVX8QqrjudCD1ZCOBf3OLOqDpKD5fdH7XLU43g=; b=SJIdimRVN6exWUvYNOMifHQZrAIArBw+6hx1yOyRhfFOnbgNRrp8gpC+iuq87kMVC2 GLghag7kevVYb9ZpPMBuybA9iZ3xLn37ssbXXXaAUpa3HydaYTciwD1h8bE920K7Xs/s 5YtCUostfobDCztV9A74P/tFIrSJv1TJG89lU=
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=vbh/nwVX8QqrjudCD1ZCOBf3OLOqDpKD5fdH7XLU43g=; b=GW3jogB/MiP2Km8k/gZesoAV8PUHja0cTumGoBlVjRWzx0F2iKasqyFdNj4NtUougy t2Za7yGZ+7yJgwZ1KkbHDMjNZo9okq4T/p2BXWA4O7xzIhJiapDMgjPzgm/Sc/nyvhbd 2FiBGlhikpGtDDWL/F9CEzfNBpaMDC+C/yN3lvKhmsWRmC34V8I4IHj0zPfCdebn+ebl ZJdytFjCQE7wfR9oFeME3i2ssLYLbKGUA4RZM3RdofTgxWwB6TtK1y48fwYLBEWpSMTz Jy0yCgmqkxoUJdHaCwU3JlPn6nZ8j9eyY+t3SXOwNya1yQ2FH1kkOUpN7BaarXHvi0Nu SRUQ==
X-Gm-Message-State: AJaThX5uHsPixNQD3YL+YJqw6Fki5TrQB47IwKxCVGsYZT+vT+tG0LUe Z3R/EJXndGhHVhNvtviOix/flw==
X-Google-Smtp-Source: AGs4zMbDv/jDSwR9rWY1bQueudsf+NIHD1Kq6hWl/5MKXq2Q4S9vyMhQigE/fiw9iX+oZYyUo4tqMQ==
X-Received: by 10.200.51.91 with SMTP id u27mr31554287qta.0.1511356586199; Wed, 22 Nov 2017 05:16:26 -0800 (PST)
Received: from [192.168.3.118] (c-174-59-234-33.hsd1.pa.comcast.net. [174.59.234.33]) by smtp.gmail.com with ESMTPSA id k9sm10611651qkl.10.2017.11.22.05.16.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 05:16:25 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Bob kb8tq 
In-Reply-To: <01992158370DC941ABFFAB7233E2346046348DAB@dggeml506-mbx.china.huawei.com>
Date: Wed, 22 Nov 2017 08:16:22 -0500
Cc: Rodney Cummings , Jiangyuanlong , "tictoc@ietf.org" , Alex Campbell , Karen O'Donoghue , Xian Liu , "netmod@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <354261BF-322C-46AE-8B0D-573065A7C62B@n1k.org>
References: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>  <01992158370DC941ABFFAB7233E2346046348DAB@dggeml506-mbx.china.huawei.com>
To: Xujinchun 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: Re: [netmod] [TICTOC] Using instance-number or instance-name issue - RE: 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: Wed, 22 Nov 2017 13:16:30 -0000

Hi

If you change to =E2=80=9Cinstance name=E2=80=9D be very clear on the =
character set(s) allowed. I have seen some really bad side=20
effects when unexpected character sets show up in ID fields. Software =
tries to parse it for presentation on a screen
or into a log. The result is a crash or lockup.=20

Bob=20

> On Nov 21, 2017, at 10:18 PM, Xujinchun  wrote:
>=20
> Hi Rodney,
>=20
> In my opinion, instance-name or instance-number does not matter if the =
number of instances are small. But if the instances may grow into =
hundreds or more in scale, then string should not be a choice.
>=20
> We know how awkward it is to store and sort out a key of string =
compared with an integer.
>=20
> Thanks
>=20
> Jinchun XU
>=20
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Rodney Cummings =
[mailto:rodney.cummings@ni.com]=20
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B411=E6=9C=8822=E6=97=A5=
 1:56
> =E6=94=B6=E4=BB=B6=E4=BA=BA: Jiangyuanlong; tictoc@ietf.org; Alex =
Campbell; Karen O'Donoghue
> =E6=8A=84=E9=80=81: Xian Liu; Xujinchun; netmod@ietf.org
> =E4=B8=BB=E9=A2=98: RE: Using instance-number or instance-name issue - =
RE: WG Last Call resolutions incorporated in =
draft-ietf-tictoc-1588v2-yang-06
>=20
> Hi Yuanlong,
>=20
> I have no concerns with instance-number, as that is what the upcoming =
1588 revision outlines for management.
>=20
> I also have no strong objections against changing instance-number to =
instance-name. If we do that, I think it would be best to make the same =
change in the upcoming 1588 revision. I asked the 1588 working group for =
opinion, but I haven't heard back on that.
>=20
> All things being equal, my preference is to go with instance-number.
>=20
> Rodney
>=20
> -----Original Message-----
> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]=20
> Sent: Monday, November 20, 2017 7:34 AM
> To: tictoc@ietf.org; Alex Campbell ; Rodney Cummings ; Karen =
O'Donoghue=20
> Cc: Xian Liu ; Xujinchun ; netmod@ietf.org
> Subject: Using instance-number or instance-name issue - RE: WG Last =
Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
>=20
> Hi all,
>=20
> Item #5 below is the last open issue we discussed both in emails and =
in IEEE 1588 mailing list on draft-ietf-tictoc-1588v2-yang. =20
> In a summary: in draft-ietf-tictoc-1588v2-yang, list instance-list has =
a key of "instance-number", but there were discussions whether to use =
instance-name (a string) instead.
>=20
> Currently, "instance-number" in draft-ietf-tictoc-1588v2-yang-06 =
aligns well with the texts in the new revision of IEEE 1588 (D1.2/2017):=20=

>   "The instanceList is indexed using a number that is unique per PTP =
Instance within the PTP Node, applicable to the=20
>   management context only (i.e. not used in PTP messages). The =
domainNumber of the PTP Instance must not be used as the index=20
>   to instanceList, since it is possible for a PTP Node to contain =
multiple PTP Instances using the same domainNumber."
>=20
> The main requirement of instanceList in IEEE 1588 is the uniqueness of =
its index, and the "key" statement of YANG serves this purpose very =
well.
>=20
> That is, when instance-number is used as a key, a PTP Node with =
multiple PTP Instances cannot use the same instance-number value for =
these PTP Instances (just according to YANG semantics).
>=20
> Using instance-name (string) can also guarantee the uniqueness of the =
index of a list, but compared with an integer, a string is usually more =
complex to process and store. If instance-name is modeled as an =
arbitrary length of string, there is even a risk of buffer-overflow =
attack.
>=20
> Furthermore, it should be noted that draft-ietf-tictoc-1588v2-yang is =
targeted at IEEE 1588-2008, for which most products today only have a =
single PTP instance, and not have a name for this instance, it seems =
quite weird to introduce a name for this instance.
>=20
> Therefore, I would suggest we keep on using instance-number as a key. =
But as 65536 limit is a concern, I further suggest to change its type to =
uint32.
>=20
> Any comments or concerns on this suggestion to move forward?
>=20
> Thanks,
> Yuanlong
>=20
> ----- Original Message -----
> From: "Jiangyuanlong" 
> To: "Alex Campbell" ; 
> Cc: "Xian Liu" ; "Xujinchun"
> ; 
> Sent: Tuesday, November 07, 2017 7:53 AM
> Subject: Re: [netmod] WG Last Call resolutions incorporated in
> draft-ietf-tictoc-1588v2-yang-06
>=20
>=20
>> Hi Alex,
>>=20
>> Sorry for a late reply as I spent the last week for an urgent =
business
> trip.
>> Please see my comments in line with [YJ]
>>=20
>> Thanks,
>> Yuanlong
>>=20
>> -----Original Message-----
>> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
>> Sent: Monday, October 30, 2017 10:15 AM
>> To: Jiangyuanlong; tictoc@ietf.org
>> Cc: Xian Liu; Xujinchun; netmod@ietf.org
>> Subject: Re: WG Last Call resolutions incorporated in
> draft-ietf-tictoc-1588v2-yang-06
>>=20
>> Hi,
>> I've reviewed this latest draft and have some more comments.
>>=20
>> 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.
>>   For example, there is no need to elaborate on YANG data types here.
> It is also not here to sell YANG.
>>=20
>> [YJ] Yes, we are trying to give some introductory information for an
> outsider who may not be familiar with PTP or YANG, and explain why a =
YANG for PTP is needed. The juicy part of this document is its YANG =
module, and people can skip all the other texts if they are familiar =
with PTP and YANG.
>> Besides, these texts have been contributed by multiple sources and
> undergone several rounds of reviews, thus I will wait for a clear =
message from the TICTOC chairs to introduce any big changes at this last =
call stage.
>>=20
>>=20
>> OLD:
>>=20
>>   As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
>>   supported in the carrier networks, industrial networks, automotive
>>   networks, and many other applications. It can provide high
>>   precision time synchronization as fine as nano-seconds. The
>>   protocol depends on a Precision Time Protocol (PTP) engine to
>>   decide its own state automatically, and a PTP transportation layer
>>   to carry the PTP timing and various quality messages. The
>>   configuration parameters and state data sets of IEEE 1588-2008 are
>>   numerous.
>>=20
>>   According to the concepts described in [RFC3444], IEEE 1588-2008
>>   itself provides an information model in its normative
>>   specifications for the data sets (in IEEE 1588-2008 clause 8). Some
>>   standardization organizations including the IETF have specified
>>   data models in MIBs (Management Information Bases) for IEEE 1588-
>>   2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
>>   typically focused on retrieval of state data using the Simple
>>   Network Management Protocol (SNMP), furthermore, configuration of
>>   PTP data sets is not considered in [RFC8173].
>>=20
>>   Some service providers and applications require that the management
>>   of the IEEE 1588-2008 synchronization network be flexible and more
>>   Internet-based (typically overlaid on their transport networks).
>>   Software Defined Network (SDN) is another driving factor, which
>>   demands an improved configuration capability of synchronization
>>   networks.
>>=20
>>   YANG [RFC6020] is a data modeling language used to model
>>   configuration and state data manipulated by network management
>>   protocols like the Network Configuration Protocol (NETCONF)
>>   [RFC6241]. A small set of built-in data types are defined in
>>   [RFC6020], and a collection of common data types are further
>>   defined in [RFC6991]. Advantages of YANG include Internet based
>>   configuration capability, validation, rollback and so on. All of
>>   these characteristics make it attractive to become another
>>   candidate modeling language for IEEE 1588-2008.
>>=20
>> NEW:
>>=20
>>   IEEE 1588-2008 is a time protocol that provides high precision time
>>   synchronization as fine as nano-seconds.
>>=20
>>   IEEE 1588-2008 itself provides an information model in its
> normative
>>   specifications for the data sets (IEEE 1588-2008 clause 8).
>>   Standard information models (e.g. [RFC8173], [IEEE8021AS]) have
> been
>>   previously defined as MIBs focused on the retrieval of state data
> using
>>   SNMP [RFC1157].
>>=20
>>   YANG [RFC6020] is a data modeling language used to model
> configuration
>>   and state data manipulated by network management protocols like
> NETCONF
>>   [RFC6241].
>>=20
>> 2. Can we refer to the system as simply PTP rather than IEEE
> 1588(-2008)?
>> [YJ] Advice from IEEE 1588 is, we need to use "1588-2008" as much as
> possible to help clarify that the scope of this YANG is limited to the =
published 1588 standard.
>>=20
>>=20
>> 3. There is insufficient spacing here to separate the terms from =
their
> definitions:
>> OLD
>>=20
>>   PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
>>   for PTP protocol decisions and for providing values for PTP message
>>   fields, see Section 8 of [IEEE1588].
>>=20
>>   PTP instance A PTP implementation in the device (i.e., an OC or BC)
>>   represented by a specific PTP dataset.
>>=20
>> NEW
>>=20
>>   PTP dataset
>>     Structured attributes of clocks (an OC, BC or TC) used
>>     for PTP protocol decisions and for providing values for PTP
> message
>>     fields, see Section 8 of [IEEE1588].
>>=20
>>   PTP instance
>>     A PTP implementation in the device (i.e., an OC or BC)
>>     represented by a specific PTP dataset.
>> [YJ] OK.
>>=20
>> 4. There's a singular/plural mismatch here:
>>=20
>>   module. Query and configuration of device wide or port specific
>>   configuration information and clock data set is described for this
>>   version.
>> [YJ] Good, we will change 'is' to 'are'.
>>=20
>> and here:
>>=20
>>   Query and configuration of clock information include:
>>=20
>>=20
>> 5. The choice of uint16 as instance-number limits implementations to
> 65536 distinct instances.
>>   While I have a hard time imagining a system with more than 65536
> PTP instances, I would prefer to avoid imposing arbitrary limits.
>>   I would recommend changing instance-number to a string (and
> renaming it to instance-name or just name).
>> [YJ] The 1588-2008 supports multiple instances of PTP, but it is
> ambiguous in its organization of those PTP instances, especially with =
regard to management.
>> In the 1588 new revision, there is an explicit list of PTP instances,
> and that list is indexed using a number (not name). Thus to align with =
the new revision, we need to keep it instance-number.
>> If 65536 limit is a concern, how about change it to uint32, any
> concerns?
>>=20
>>=20
>> 6. I still recommend removing -ds from the YANG element names that
> still include it. It doesn't appear to add any value.
>> [YJ] Rodney's opinion: the value of using 'ds' is that the 1588
> document on which this YANG model is based uses "DefaultDS" as a term.
> PTP experts even say "default dee ess" verbally when referring to this =
data. If we changed this to just "default", PTP experts might assume =
that we are referring to something entirely new to YANG. Thus, to align =
with 1588-2008, the same set of terminologies are used.
>>=20
>> 7. What;s the relevance of injection attacks relevant to this YANG
> module?
>> [YJ] This is a general statement which is applicable to this YANG
> module and other YANG modules as well.
>> Thanks again,
>> Yuanlong
>>=20
>> Alex
>>=20
>>=20
>> ________________________________________
>> From: netmod  on behalf of Jiangyuanlong
> 
>> Sent: Friday, 27 October 2017 3:21 p.m.
>> To: tictoc@ietf.org
>> Cc: Xian Liu; Xujinchun; netmod@ietf.org
>> Subject: [netmod] WG Last Call resolutions incorporated in
> draft-ietf-tictoc-1588v2-yang-06
>>=20
>> Dear all,
>>=20
>> Based on all the comments we received during the WG Last Call =
process,
> we've updated the document to version 6.
>> We believe all the LC comments are resolved and the consensus is
> reflected in this new revision.
>> Many thanks to Martin, Tal, Opher, Alex, John and many others who had
> reviewed and commented on this draft.
>>=20
>> Cheers,
>> Yuanlong on behalf of all coauthors
>>=20
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Friday, October 27, 2017 9:48 AM
>> To: Xian Liu; Rodney Cummings; rodney.cummings@ni.com; Jiangyuanlong;
> Xujinchun
>> Subject: New Version Notification for
> draft-ietf-tictoc-1588v2-yang-06.txt
>>=20
>>=20
>> A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
>> has been successfully submitted by Yuanlong Jiang and posted to the
> IETF repository.
>>=20
>> Name:           draft-ietf-tictoc-1588v2-yang
>> Revision:       06
>> Title:          YANG Data Model for IEEE 1588-2008
>> Document date:  2017-10-26
>> Group:          tictoc
>> Pages:          30
>> URL:
> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_intern=
et-2Ddrafts_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06.tx&d=3DDwIFgQ&c=3DI=
_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJ=
uupswWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3DN0N5k=
BPcGMivXWwspHEOc-bP0mbYpkKu2IvM2Asyf_8&e=3D
> t
>> Status:
> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or=
g_doc_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang_&d=3DDwIFgQ&c=3DI_0YwoKy7z5LMT=
VdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKb=
Z8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3DaYlovx_kTQtAiJAUMT=
Jn8NCRZQIi_jEVNa-tC_5HFlk&e=3D
>> Htmlized:
> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html=
_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=3DDwIFgQ&c=3DI_0YwoKy7z5LMTV=
dyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ=
8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3Dj1aDjiU7AeuEV-p20PN=
wNpvZPrGSbBiHLHta7q05pak&e=3D
>> Htmlized:
> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or=
g_doc_html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=3DDwIFgQ&c=3DI_0Yw=
oKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuups=
wWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3D7tYOv1M_E=
YHCPG1MiOq3BVl7vpB0w-LSiDYcQHM4ayM&e=3D
>> Diff:
> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdif=
f-3Furl2-3Ddraft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=3DDwIFgQ&c=3DI_0Yw=
oKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuups=
wWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3DZ12Xm_2k7=
cEAlV7lFQb_zw7A-D-HL77C-Kuy2BgyCHA&e=3D
>>=20
>> Abstract:
>>   This document defines a YANG data model for the configuration of
>>   IEEE 1588-2008 devices and clocks, and also retrieval of the
>>   configuration information, data set and running states of IEEE
>>   1588-2008 clocks.
>>=20
>>=20
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at =
tools.ietf.org.
>>=20
>> The IETF Secretariat
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_netmod&d=3DDwIFgQ&c=3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSji=
xA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89F=
ir82kLxurUC4yXciXZMIqStw&s=3DcUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4&e=
=3D
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_netmod&d=3DDwIFgQ&c=3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSji=
xA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89F=
ir82kLxurUC4yXciXZMIqStw&s=3DcUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4&e=
=3D
>=20
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc


From nobody Wed Nov 22 06:01: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 B376F129401 for ; Wed, 22 Nov 2017 06:01:14 -0800 (PST)
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 0qdIUXVV3gAF for ; Wed, 22 Nov 2017 06:01:12 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2855712421A for ; Wed, 22 Nov 2017 06:01:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5572; q=dns/txt; s=iport; t=1511359272; x=1512568872; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NSbaE2uAtyS281AxwQd7oHHzHh2mwDLae3HEiIS6M0g=; b=lWmnK1g3K2gZINDPl9F6h650YkVa77ansBxeARw362XFmrNDd+N356s4 ZJgO16/zzWqykjON9SD3B9hh2bFvJeM0ohg+7OPww7CAtZLBMXl7G4cVF 3u/w0A5SrnEPkxIashsNQmPOldEM56mS6Dxit2eIoBa4JiTOI50LITjYZ k=;
X-IronPort-AV: E=Sophos;i="5.44,436,1505779200";  d="scan'208";a="419195"
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; 22 Nov 2017 14:01:10 +0000
Received: from [10.63.23.168] (dhcp-ensft1-uk-vla370-10-63-23-168.cisco.com [10.63.23.168]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAME19PG025014; Wed, 22 Nov 2017 14:01:10 GMT
To: Martin Bjorklund , mjethanandani@gmail.com
Cc: jhaas@juniper.net, kll@dev.terastrm.net, agarwaso@cisco.com, netmod@ietf.org, kll@spritelink.net
References: <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net> <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com> <20171122.093904.670536605936490886.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Wed, 22 Nov 2017 14:01:09 +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: <20171122.093904.670536605936490886.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 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: Wed, 22 Nov 2017 14:01:15 -0000

Thinking about this some more.  I'm not sure what it means for the "ACL 
Type" to be "any-acl".  It seems that the "match any packet" should be a 
type of ACE, e.g. perhaps as the last entry of an ACL, rather than a 
type of ACL.

Otherwise if the ACL type is "any-acl" then this only allows two types 
of ACLs to be defined, neither of which seem to be particularly useful:
(1) An ACL that matches all traffic and permits it, i.e. the same as 
having no ACL at all.
(2) An ACL that matches all traffic and drops.

So I think perhaps the answer here is to define neither ACL type 
"any-acl" nor leaf "any".  The presumption could be that any ACE that is 
configured to match no fields implicitly matches all packets (because 
all non specified fields are treated as wildcards), and then applies the 
permit/deny rule associated with the ACE.  This logic can apply to all 
ACL types.

Thanks,
Rob


On 22/11/2017 08:39, Martin Bjorklund wrote:
> Mahesh Jethanandani  wrote:
>> [Taking the discussion to the mailing list]
>>
>> The summary of the discussion happening on a private thread has to
>> do with the ‘any’ container (now leaf) definition in the ACL model
>> for something that matches anything, much like a ‘*’ would do in
>> regex. The discussion has come down to:
>>
>> - leave the definition as is, so users would have to explicitly define it
>>    pro: It is explicit and there would be no confusion about its
>>    presence or absence.
>>    con: It is verbose, in that every access list entry would have to
>>    define it.
>>
>> - remove the any definition, so an absence of the definition implies
>>    match on all.
> It wouldn't be the *absence* that implies match on all, but rather it
> is the explicit setting of the type to 'any-acl' that means match on
> all:
>
>    
>      my-any-acl
>      any-acl
>    
>
> Having to also define the leaf "any" as well would just be redundant:
>
>    
>      my-any-acl
>      any-acl
>      
>        
>          my-any-rule
>          
>        
>      
>    
>
>
> BTW, I support Kristian's suggestion of have just the "name" as the
> key in the "acl" list, and making "type" mandatory.
>
> I also suggest you remove redundant prefixes in the leaf names,
> e.g. as above s/acl-type/type/ s/acl-name/name/ and
> s/rule-name/name/.  This is how we usually name nodes in the IETF YANG
> models.
>
>> The text in the draft would have to be updated to
>>    state this, and YANG parsers would need to watch out for the
>>    non-definition in the match container.
>>
>> Opinion? Preferences?
>>
>> p.s. Current CLI configurations require explicit declaration of ‘any’.
> But do they also have the acl type definition?
>
>
> /martin
>
>
>
>>> On Nov 20, 2017, at 2:20 PM, Jeff Haas  wrote:
>>>
>>>> On Nov 20, 2017, at 4:54 PM, Kristian Larsson  wrote:
>>>>
>>>>
>>>>
>>>> On 2017-11-20 18:26, Jeff Haas wrote:
>>>>> IMO, the contention here is a consequence of proof by assertion. >
>>>>>> On Nov 17, 2017, at 5:56 AM, Kristian Larsson > wrote:
>>>>>>
>>>>>>>> Changes I'd like to see to this PR:
>>>>>>>> * remove any-acl completely as it serves no purpose (we achieve
>>>>>>>>   this through a ACE with no match conditions)
>>>>>>> Will let Jeff respond as he articulated this requirement. Agree that most platforms have deny as the default. But what if the ace entry is something like this:
>>>>>>> access-list 11 permit tcp any any
>>>>>>> Would the absence of match rules for IP addresses imply any any?
>>>>>> An absence of any match means it matches on everything. If there are no IP matches at all, then yes, it implies any source or destination address. I don't see why we would need to explicitly have an any-acl container or leaf to point this out. With the same concept applied uniformly you would explicitly call out "any" matches for all types of matches. That would be extremely verbose.
>>>>> Where in the model does it say that the absence of a matches container implies a match all vs. match none?
>>>>> Where in the normative text of the internet-draft does it say that?
>>>>> In the absence of either of the above, an "any" removes ambiguity.
>>>>> FWIW, I'm totally fine with removing the any; however you *MUST* clarify the above.  Preferably both in the matches container and also in the normative text.  For my part, I think it's easier on the parser if you basically require at least one item from the container so you don't have to deal with optional contents.  But I'm not the one writing yang parsers for a living.
>>>> I think it's clear that if no match condition is defined for a particular (header) field then that means any value will match. It is only an extension of this that no match conditions at all means we match any and all packets. I think that is logical.
>>>>
>>>> This can naturally be spelled out in the text :)
>>> You think it's clear, but where is it in the document or model?
>>>
>>> Of such "implied clarity" is many interop bugs made. :-P
>>>
>>> -- Jeff
>>>
>>>> Kind regards,
>>>>   Kristian.
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Nov 22 06:52: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 BD1ED12783A; Wed, 22 Nov 2017 06:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.326
X-Spam-Level: 
X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URG_BIZ=0.573, 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 FhTcH7JWqCwE; Wed, 22 Nov 2017 06:52:45 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2671200FC; Wed, 22 Nov 2017 06:52:44 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1E6866AE; Wed, 22 Nov 2017 15:52:43 +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 TL4BXHJvqL7V; Wed, 22 Nov 2017 15:52:42 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Nov 2017 15:52:42 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB86520123; Wed, 22 Nov 2017 15:52:42 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jnoVhPogEhca; Wed, 22 Nov 2017 15:52:40 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D5BD20121; Wed, 22 Nov 2017 15:52:40 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 76D78417CBF2; Wed, 22 Nov 2017 15:51:12 +0100 (CET)
Date: Wed, 22 Nov 2017 15:51:12 +0100
From: Juergen Schoenwaelder 
To: Bob kb8tq 
Cc: Xujinchun , "netmod@ietf.org" , Karen O'Donoghue , Xian Liu , "tictoc@ietf.org" 
Message-ID: <20171122145112.koipskvauriwpepq@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Bob kb8tq , Xujinchun ,  "netmod@ietf.org" , Karen O'Donoghue , Xian Liu , "tictoc@ietf.org" 
References: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>  <01992158370DC941ABFFAB7233E2346046348DAB@dggeml506-mbx.china.huawei.com> <354261BF-322C-46AE-8B0D-573065A7C62B@n1k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <354261BF-322C-46AE-8B0D-573065A7C62B@n1k.org>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] [TICTOC] Using instance-number or instance-name issue - RE: 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: Wed, 22 Nov 2017 14:52:49 -0000

According to RFC 7950, section 9.4, YANG strings are Unicode and
ISO/IEC 10646 characters, including tab, carriage return, and line
feed but excluding the other C0 control characters, the surrogate
blocks, and the noncharacters. Of course, handling Unicode correctly
can still be a lot of fun and systems that do not get this right might
still crash or lockup.

/js

On Wed, Nov 22, 2017 at 08:16:22AM -0500, Bob kb8tq wrote:
> Hi
> 
> If you change to “instance name” be very clear on the character set(s) allowed. I have seen some really bad side 
> effects when unexpected character sets show up in ID fields. Software tries to parse it for presentation on a screen
> or into a log. The result is a crash or lockup. 
> 
> Bob 
> 
> > On Nov 21, 2017, at 10:18 PM, Xujinchun  wrote:
> > 
> > Hi Rodney,
> > 
> > In my opinion, instance-name or instance-number does not matter if the number of instances are small. But if the instances may grow into hundreds or more in scale, then string should not be a choice.
> > 
> > We know how awkward it is to store and sort out a key of string compared with an integer.
> > 
> > Thanks
> > 
> > Jinchun XU
> > 
> > -----邮件原件-----
> > 发件人: Rodney Cummings [mailto:rodney.cummings@ni.com] 
> > 发送时间: 2017年11月22日 1:56
> > 收件人: Jiangyuanlong; tictoc@ietf.org; Alex Campbell; Karen O'Donoghue
> > 抄送: Xian Liu; Xujinchun; netmod@ietf.org
> > 主题: RE: Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
> > 
> > Hi Yuanlong,
> > 
> > I have no concerns with instance-number, as that is what the upcoming 1588 revision outlines for management.
> > 
> > I also have no strong objections against changing instance-number to instance-name. If we do that, I think it would be best to make the same change in the upcoming 1588 revision. I asked the 1588 working group for opinion, but I haven't heard back on that.
> > 
> > All things being equal, my preference is to go with instance-number.
> > 
> > Rodney
> > 
> > -----Original Message-----
> > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com] 
> > Sent: Monday, November 20, 2017 7:34 AM
> > To: tictoc@ietf.org; Alex Campbell ; Rodney Cummings ; Karen O'Donoghue 
> > Cc: Xian Liu ; Xujinchun ; netmod@ietf.org
> > Subject: Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
> > 
> > Hi all,
> > 
> > Item #5 below is the last open issue we discussed both in emails and in IEEE 1588 mailing list on draft-ietf-tictoc-1588v2-yang.  
> > In a summary: in draft-ietf-tictoc-1588v2-yang, list instance-list has a key of "instance-number", but there were discussions whether to use instance-name (a string) instead.
> > 
> > Currently, "instance-number" in draft-ietf-tictoc-1588v2-yang-06 aligns well with the texts in the new revision of IEEE 1588 (D1.2/2017): 
> >   "The instanceList is indexed using a number that is unique per PTP Instance within the PTP Node, applicable to the 
> >   management context only (i.e. not used in PTP messages). The domainNumber of the PTP Instance must not be used as the index 
> >   to instanceList, since it is possible for a PTP Node to contain multiple PTP Instances using the same domainNumber."
> > 
> > The main requirement of instanceList in IEEE 1588 is the uniqueness of its index, and the "key" statement of YANG serves this purpose very well.
> > 
> > That is, when instance-number is used as a key, a PTP Node with multiple PTP Instances cannot use the same instance-number value for these PTP Instances (just according to YANG semantics).
> > 
> > Using instance-name (string) can also guarantee the uniqueness of the index of a list, but compared with an integer, a string is usually more complex to process and store. If instance-name is modeled as an arbitrary length of string, there is even a risk of buffer-overflow attack.
> > 
> > Furthermore, it should be noted that draft-ietf-tictoc-1588v2-yang is targeted at IEEE 1588-2008, for which most products today only have a single PTP instance, and not have a name for this instance, it seems quite weird to introduce a name for this instance.
> > 
> > Therefore, I would suggest we keep on using instance-number as a key. But as 65536 limit is a concern, I further suggest to change its type to uint32.
> > 
> > Any comments or concerns on this suggestion to move forward?
> > 
> > Thanks,
> > Yuanlong
> > 
> > ----- Original Message -----
> > From: "Jiangyuanlong" 
> > To: "Alex Campbell" ; 
> > Cc: "Xian Liu" ; "Xujinchun"
> > ; 
> > Sent: Tuesday, November 07, 2017 7:53 AM
> > Subject: Re: [netmod] WG Last Call resolutions incorporated in
> > draft-ietf-tictoc-1588v2-yang-06
> > 
> > 
> >> Hi Alex,
> >> 
> >> Sorry for a late reply as I spent the last week for an urgent business
> > trip.
> >> Please see my comments in line with [YJ]
> >> 
> >> Thanks,
> >> Yuanlong
> >> 
> >> -----Original Message-----
> >> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
> >> Sent: Monday, October 30, 2017 10:15 AM
> >> To: Jiangyuanlong; tictoc@ietf.org
> >> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> >> Subject: Re: WG Last Call resolutions incorporated in
> > draft-ietf-tictoc-1588v2-yang-06
> >> 
> >> Hi,
> >> I've reviewed this latest draft and have some more comments.
> >> 
> >> 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.
> >>   For example, there is no need to elaborate on YANG data types here.
> > It is also not here to sell YANG.
> >> 
> >> [YJ] Yes, we are trying to give some introductory information for an
> > outsider who may not be familiar with PTP or YANG, and explain why a YANG for PTP is needed. The juicy part of this document is its YANG module, and people can skip all the other texts if they are familiar with PTP and YANG.
> >> Besides, these texts have been contributed by multiple sources and
> > undergone several rounds of reviews, thus I will wait for a clear message from the TICTOC chairs to introduce any big changes at this last call stage.
> >> 
> >> 
> >> OLD:
> >> 
> >>   As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
> >>   supported in the carrier networks, industrial networks, automotive
> >>   networks, and many other applications. It can provide high
> >>   precision time synchronization as fine as nano-seconds. The
> >>   protocol depends on a Precision Time Protocol (PTP) engine to
> >>   decide its own state automatically, and a PTP transportation layer
> >>   to carry the PTP timing and various quality messages. The
> >>   configuration parameters and state data sets of IEEE 1588-2008 are
> >>   numerous.
> >> 
> >>   According to the concepts described in [RFC3444], IEEE 1588-2008
> >>   itself provides an information model in its normative
> >>   specifications for the data sets (in IEEE 1588-2008 clause 8). Some
> >>   standardization organizations including the IETF have specified
> >>   data models in MIBs (Management Information Bases) for IEEE 1588-
> >>   2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
> >>   typically focused on retrieval of state data using the Simple
> >>   Network Management Protocol (SNMP), furthermore, configuration of
> >>   PTP data sets is not considered in [RFC8173].
> >> 
> >>   Some service providers and applications require that the management
> >>   of the IEEE 1588-2008 synchronization network be flexible and more
> >>   Internet-based (typically overlaid on their transport networks).
> >>   Software Defined Network (SDN) is another driving factor, which
> >>   demands an improved configuration capability of synchronization
> >>   networks.
> >> 
> >>   YANG [RFC6020] is a data modeling language used to model
> >>   configuration and state data manipulated by network management
> >>   protocols like the Network Configuration Protocol (NETCONF)
> >>   [RFC6241]. A small set of built-in data types are defined in
> >>   [RFC6020], and a collection of common data types are further
> >>   defined in [RFC6991]. Advantages of YANG include Internet based
> >>   configuration capability, validation, rollback and so on. All of
> >>   these characteristics make it attractive to become another
> >>   candidate modeling language for IEEE 1588-2008.
> >> 
> >> NEW:
> >> 
> >>   IEEE 1588-2008 is a time protocol that provides high precision time
> >>   synchronization as fine as nano-seconds.
> >> 
> >>   IEEE 1588-2008 itself provides an information model in its
> > normative
> >>   specifications for the data sets (IEEE 1588-2008 clause 8).
> >>   Standard information models (e.g. [RFC8173], [IEEE8021AS]) have
> > been
> >>   previously defined as MIBs focused on the retrieval of state data
> > using
> >>   SNMP [RFC1157].
> >> 
> >>   YANG [RFC6020] is a data modeling language used to model
> > configuration
> >>   and state data manipulated by network management protocols like
> > NETCONF
> >>   [RFC6241].
> >> 
> >> 2. Can we refer to the system as simply PTP rather than IEEE
> > 1588(-2008)?
> >> [YJ] Advice from IEEE 1588 is, we need to use "1588-2008" as much as
> > possible to help clarify that the scope of this YANG is limited to the published 1588 standard.
> >> 
> >> 
> >> 3. There is insufficient spacing here to separate the terms from their
> > definitions:
> >> OLD
> >> 
> >>   PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
> >>   for PTP protocol decisions and for providing values for PTP message
> >>   fields, see Section 8 of [IEEE1588].
> >> 
> >>   PTP instance A PTP implementation in the device (i.e., an OC or BC)
> >>   represented by a specific PTP dataset.
> >> 
> >> NEW
> >> 
> >>   PTP dataset
> >>     Structured attributes of clocks (an OC, BC or TC) used
> >>     for PTP protocol decisions and for providing values for PTP
> > message
> >>     fields, see Section 8 of [IEEE1588].
> >> 
> >>   PTP instance
> >>     A PTP implementation in the device (i.e., an OC or BC)
> >>     represented by a specific PTP dataset.
> >> [YJ] OK.
> >> 
> >> 4. There's a singular/plural mismatch here:
> >> 
> >>   module. Query and configuration of device wide or port specific
> >>   configuration information and clock data set is described for this
> >>   version.
> >> [YJ] Good, we will change 'is' to 'are'.
> >> 
> >> and here:
> >> 
> >>   Query and configuration of clock information include:
> >> 
> >> 
> >> 5. The choice of uint16 as instance-number limits implementations to
> > 65536 distinct instances.
> >>   While I have a hard time imagining a system with more than 65536
> > PTP instances, I would prefer to avoid imposing arbitrary limits.
> >>   I would recommend changing instance-number to a string (and
> > renaming it to instance-name or just name).
> >> [YJ] The 1588-2008 supports multiple instances of PTP, but it is
> > ambiguous in its organization of those PTP instances, especially with regard to management.
> >> In the 1588 new revision, there is an explicit list of PTP instances,
> > and that list is indexed using a number (not name). Thus to align with the new revision, we need to keep it instance-number.
> >> If 65536 limit is a concern, how about change it to uint32, any
> > concerns?
> >> 
> >> 
> >> 6. I still recommend removing -ds from the YANG element names that
> > still include it. It doesn't appear to add any value.
> >> [YJ] Rodney's opinion: the value of using 'ds' is that the 1588
> > document on which this YANG model is based uses "DefaultDS" as a term.
> > PTP experts even say "default dee ess" verbally when referring to this data. If we changed this to just "default", PTP experts might assume that we are referring to something entirely new to YANG. Thus, to align with 1588-2008, the same set of terminologies are used.
> >> 
> >> 7. What;s the relevance of injection attacks relevant to this YANG
> > module?
> >> [YJ] This is a general statement which is applicable to this YANG
> > module and other YANG modules as well.
> >> Thanks again,
> >> Yuanlong
> >> 
> >> Alex
> >> 
> >> 
> >> ________________________________________
> >> From: netmod  on behalf of Jiangyuanlong
> > 
> >> Sent: Friday, 27 October 2017 3:21 p.m.
> >> To: tictoc@ietf.org
> >> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> >> Subject: [netmod] WG Last Call resolutions incorporated in
> > draft-ietf-tictoc-1588v2-yang-06
> >> 
> >> Dear all,
> >> 
> >> Based on all the comments we received during the WG Last Call process,
> > we've updated the document to version 6.
> >> We believe all the LC comments are resolved and the consensus is
> > reflected in this new revision.
> >> Many thanks to Martin, Tal, Opher, Alex, John and many others who had
> > reviewed and commented on this draft.
> >> 
> >> Cheers,
> >> Yuanlong on behalf of all coauthors
> >> 
> >> -----Original Message-----
> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> Sent: Friday, October 27, 2017 9:48 AM
> >> To: Xian Liu; Rodney Cummings; rodney.cummings@ni.com; Jiangyuanlong;
> > Xujinchun
> >> Subject: New Version Notification for
> > draft-ietf-tictoc-1588v2-yang-06.txt
> >> 
> >> 
> >> A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
> >> has been successfully submitted by Yuanlong Jiang and posted to the
> > IETF repository.
> >> 
> >> Name:           draft-ietf-tictoc-1588v2-yang
> >> Revision:       06
> >> Title:          YANG Data Model for IEEE 1588-2008
> >> Document date:  2017-10-26
> >> Group:          tictoc
> >> Pages:          30
> >> URL:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06.tx&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=N0N5kBPcGMivXWwspHEOc-bP0mbYpkKu2IvM2Asyf_8&e=
> > t
> >> Status:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang_&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=aYlovx_kTQtAiJAUMTJn8NCRZQIi_jEVNa-tC_5HFlk&e=
> >> Htmlized:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=j1aDjiU7AeuEV-p20PNwNpvZPrGSbBiHLHta7q05pak&e=
> >> Htmlized:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=7tYOv1M_EYHCPG1MiOq3BVl7vpB0w-LSiDYcQHM4ayM&e=
> >> Diff:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=Z12Xm_2k7cEAlV7lFQb_zw7A-D-HL77C-Kuy2BgyCHA&e=
> >> 
> >> Abstract:
> >>   This document defines a YANG data model for the configuration of
> >>   IEEE 1588-2008 devices and clocks, and also retrieval of the
> >>   configuration information, data set and running states of IEEE
> >>   1588-2008 clocks.
> >> 
> >> 
> >> 
> >> 
> >> 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
> >> 
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=cUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4&e=
> >> 
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=cUl0d0wDX9fIwjIEHlhcrfg17x7phpI9QiF5PuXsYd4&e=
> > 
> > _______________________________________________
> > TICTOC mailing list
> > TICTOC@ietf.org
> > https://www.ietf.org/mailman/listinfo/tictoc
> 
> _______________________________________________
> 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 Nov 22 07:02: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 E4D8C129447 for ; Wed, 22 Nov 2017 07:02:47 -0800 (PST)
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 1s9EbNcdcMqp for ; Wed, 22 Nov 2017 07:02:46 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6344D12783A for ; Wed, 22 Nov 2017 07:02:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2736; q=dns/txt; s=iport; t=1511362966; x=1512572566; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=7S0rf5Zaj/LNhksSX2zsOrPBhyAvli3RI7/5g6BTZbc=; b=NLaO5Bi+fcTivqw0xUhLY7O9LG7A4deo6pO7VhYaYhNGkcxeGP3ySmKE RoFVqSQIDkuTMrugFwHLOTPrj3QL9XN3dctETegWxYBGRXqbPVsFqtdbj WWU46C6iiFaZurt0HsCmUQ+Or5g9c+EbBBYnAHSsTR+J04eKUmBcCWGYS M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQD0kBVa/xbLJq1cGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYQibieDf4ofdI94JpEchUkQggEKJYUWAoVbGAEBAQEBAQEBAWsohR4BBiN?= =?us-ascii?q?LGw8NAwECKwICTQIIBg0GAgEBih4QqCqCJyaKUgEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgzqDXIISC4J3gUmDGliCdYJjBYxfjEWJHJUMjASHSY5Dh3SBOh85gXU?= =?us-ascii?q?0IQgdFUmCZIJogXhANot8AQEB?=
X-IronPort-AV: E=Sophos;i="5.44,436,1505779200"; d="scan'208,217";a="419295"
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; 22 Nov 2017 15:02:44 +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 vAMF2iWr006140 for ; Wed, 22 Nov 2017 15:02:44 GMT
References: <8e4cec79-e248-56fa-7168-e9a31b5e5eff@cisco.com>
To: NETMOD Working Group 
From: Benoit Claise 
X-Forwarded-Message-Id: <8e4cec79-e248-56fa-7168-e9a31b5e5eff@cisco.com>
Message-ID: 
Date: Wed, 22 Nov 2017 16:02:44 +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: <8e4cec79-e248-56fa-7168-e9a31b5e5eff@cisco.com>
Content-Type: multipart/alternative; boundary="------------C9D9CDD27D23467909993B92"
Content-Language: en-US
Archived-At: 
Subject: [netmod] Fwd: Blog: YANG Catalog Latest Developments (IETF 100 Hackathon)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2017 15:02:48 -0000

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

Forwarding.
I know that some of you are not on the ietf@ietf.org mailing list.

Regards, Benoit.

-------- Forwarded Message --------
Subject: 	Blog: YANG Catalog Latest Developments (IETF 100 Hackathon)
Date: 	Wed, 22 Nov 2017 16:01:49 +0100
From: 	Benoit Claise 
To: 	IETF-Discussion list 



Dear all,

https://www.ietf.org/blog/2017/11/yang-catalog-latest-developments-ietf-100-hackathon/ 

Enjoy.

Regards, Benoit


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


  

    
  
  
    Forwarding.

    I know that some of you are not on the ietf@ietf.org mailing list.

    


      Regards, Benoit.

      

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

        
          

            Subject:
            
            Blog: YANG Catalog Latest Developments (IETF 100
              Hackathon)
          

          

            Date: 
            Wed, 22 Nov 2017 16:01:49 +0100
          

          

            From: 
            Benoit Claise <bclaise@cisco.com>
          

          

            To: 
            IETF-Discussion list <ietf@ietf.org>
          

        
      

      

      

      
      Dear all, 

      

      https://www.ietf.org/blog/2017/11/yang-catalog-latest-developments-ietf-100-hackathon/
      

      Enjoy. 

      

      Regards, Benoit 

      

    

  


--------------C9D9CDD27D23467909993B92--


From nobody Wed Nov 22 08:13: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 F02A0129463 for ; Wed, 22 Nov 2017 08:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 W0Uh7JltNXHA for ; Wed, 22 Nov 2017 08:13:26 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834501243F6 for ; Wed, 22 Nov 2017 08:13:26 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 51FB86AE; Wed, 22 Nov 2017 17:13:25 +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 C7q2OSGA1Q4z; Wed, 22 Nov 2017 17:13:24 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Nov 2017 17:13:25 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2020D20123; Wed, 22 Nov 2017 17:13:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CztMt0X7uZq6; Wed, 22 Nov 2017 17:13: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 921C320121; Wed, 22 Nov 2017 17:13:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 081E0417CE29; Wed, 22 Nov 2017 17:11:56 +0100 (CET)
Date: Wed, 22 Nov 2017 17:11:56 +0100
From: Juergen Schoenwaelder 
To: Benoit Claise 
Cc: NETMOD Working Group 
Message-ID: <20171122161156.kqlskb73vtwmg23p@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Benoit Claise , NETMOD Working Group 
References: <8e4cec79-e248-56fa-7168-e9a31b5e5eff@cisco.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] Fwd: Blog: YANG Catalog Latest Developments (IETF 100 Hackathon)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2017 16:13:28 -0000

I like the 'IETF 1000 hackathon' typo - this makes it indeed 'best
continuing work' I would say. ;-)

/js

On Wed, Nov 22, 2017 at 04:02:44PM +0100, Benoit Claise wrote:
> Forwarding.
> I know that some of you are not on the ietf@ietf.org mailing list.
> 
> Regards, Benoit.
> 
> -------- Forwarded Message --------
> Subject: 	Blog: YANG Catalog Latest Developments (IETF 100 Hackathon)
> Date: 	Wed, 22 Nov 2017 16:01:49 +0100
> From: 	Benoit Claise 
> To: 	IETF-Discussion list 
> 
> 
> 
> Dear all,
> 
> https://www.ietf.org/blog/2017/11/yang-catalog-latest-developments-ietf-100-hackathon/
> 
> Enjoy.
> 
> Regards, Benoit
> 

> _______________________________________________
> 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 Nov 22 08:27: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 09577129463 for ; Wed, 22 Nov 2017 08:27:24 -0800 (PST)
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 0RXgpnbky7nw for ; Wed, 22 Nov 2017 08:27:22 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0831270A3 for ; Wed, 22 Nov 2017 08:27:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=918; q=dns/txt; s=iport; t=1511368042; x=1512577642; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=r3uwORzmb1uVi101LeJy6CfukUokKbYgPXwKRsg56H0=; b=OGy5t58K9pmDMDyc40vOPKklNIzRDbtL+E6GK5VTYDcU1K5ZpENOdOc+ FX0SADLwH8JY+GevAzckpQ7rlNkOgn9WVD2yTUbfaU6/9qB3oeYItxbUO D+l6gGJ56lyUSMReqf7Lnxl9ZJzh4Ia2k4KEbU3uuiXc666oF7h92lRXa s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQA5pBVa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQibieDf4sTj3kmlmUQggEKGA2ER08ChWEWAQEBAQEBAQEBayi?= =?us-ascii?q?FHgEBAQQBASEVNgsQCw4DAwECAQICJgICJygIBg0GAgEBih4QqDaCJ4p4AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARoFgQ+CK4NcghILgneBSYMag02CYwWMX5VhlQyMBId?= =?us-ascii?q?JjkOHdIE6JgUtgXU0IQgdFUmCZIJogXhANot8AQEB?=
X-IronPort-AV: E=Sophos;i="5.44,436,1505779200";  d="scan'208";a="376154"
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; 22 Nov 2017 16:27:20 +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 vAMGRKeF023816; Wed, 22 Nov 2017 16:27:20 GMT
To: Juergen Schoenwaelder 
References: <8e4cec79-e248-56fa-7168-e9a31b5e5eff@cisco.com>  <20171122161156.kqlskb73vtwmg23p@elstar.local>
Cc: NETMOD Working Group 
From: Benoit Claise 
Message-ID: 
Date: Wed, 22 Nov 2017 17:27:19 +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: <20171122161156.kqlskb73vtwmg23p@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Fwd: Blog: YANG Catalog Latest Developments (IETF 100 Hackathon)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2017 16:27:24 -0000

Good one. I thought about keeping it, just because :-)
> I like the 'IETF 1000 hackathon' typo - this makes it indeed 'best
> continuing work' I would say. ;-)
>
> /js
>
> On Wed, Nov 22, 2017 at 04:02:44PM +0100, Benoit Claise wrote:
>> Forwarding.
>> I know that some of you are not on the ietf@ietf.org mailing list.
>>
>> Regards, Benoit.
>>
>> -------- Forwarded Message --------
>> Subject: 	Blog: YANG Catalog Latest Developments (IETF 100 Hackathon)
>> Date: 	Wed, 22 Nov 2017 16:01:49 +0100
>> From: 	Benoit Claise 
>> To: 	IETF-Discussion list 
>>
>>
>>
>> Dear all,
>>
>> https://www.ietf.org/blog/2017/11/yang-catalog-latest-developments-ietf-100-hackathon/
>>
>> Enjoy.
>>
>> Regards, Benoit
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Nov 22 18:17: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 60C661205D3; Wed, 22 Nov 2017 18:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.648
X-Spam-Level: 
X-Spam-Status: No, score=-3.648 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, URG_BIZ=0.573] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzupx6XAmm5Y; Wed, 22 Nov 2017 18:17:47 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B5812708C; Wed, 22 Nov 2017 18:17:47 -0800 (PST)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 36E5EC4B39945; Thu, 23 Nov 2017 02:17:44 +0000 (GMT)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 23 Nov 2017 02:17:43 +0000
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.47]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0361.001; Thu, 23 Nov 2017 10:17:33 +0800
From: Jiangyuanlong 
To: Juergen Schoenwaelder , Bob kb8tq 
CC: Xian Liu , Xujinchun , Karen O'Donoghue , "netmod@ietf.org" , "tictoc@ietf.org" 
Thread-Topic: [TICTOC] [netmod] Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTY6GZvGtCTd+lTU6e3ETiT9N5kaMhNnRQ
Date: Thu, 23 Nov 2017 02:17:33 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB652B15@dggeml507-mbx.china.huawei.com>
References: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>  <01992158370DC941ABFFAB7233E2346046348DAB@dggeml506-mbx.china.huawei.com> <354261BF-322C-46AE-8B0D-573065A7C62B@n1k.org> <20171122145112.koipskvauriwpepq@elstar.local>
In-Reply-To: <20171122145112.koipskvauriwpepq@elstar.local>
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
Archived-At: 
Subject: Re: [netmod] [TICTOC] Using instance-number or instance-name issue - RE: 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: Thu, 23 Nov 2017 02:17:50 -0000

SnVlcmdlbiAmIEJvYiwgDQoNCkNhbiBJIGFzc3VtZSB5b3UgYXJlIGluIHN1cHBvcnQgb2YgdXNp
bmcgaW5zdGFuY2UtbnVtYmVyIGluIHRoaXMgY2FzZT8gXiZeDQpCdXQgc2VyaW91c2x5LCBtYXli
ZSBpdCBtYWtlcyBzZW5zZSB0byByZXN0cmljdCB0aGUgdmFsaWQgY2hhcmFjdGVycyBvZiBhIHN0
cmluZywgZXNwZWNpYWxseSB3aGVuIGl0IGlzIHVzZWQgYXMgYSBrZXkuDQpPdGhlcndpc2UsIHdl
IG5lZWQgdG8gbm90ZSB0aGlzIHJpc2sgaW4gIlNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIiBvZiBh
IFJGQyAoYWN0dWFsbHkgaXQgY2FuIGJlY29tZSBhIGtpbmQgb2YgRG9TIGF0dGFjaykuIA0KDQpU
aGFua3MsDQpZdWFubG9uZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVElD
VE9DIFttYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWVyZ2Vu
IFNjaG9lbndhZWxkZXINClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjIsIDIwMTcgMTA6NTEg
UE0NClRvOiBCb2Iga2I4dHENCkNjOiBYaWFuIExpdTsgWHVqaW5jaHVuOyBLYXJlbiBPJ0Rvbm9n
aHVlOyBuZXRtb2RAaWV0Zi5vcmc7IHRpY3RvY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUSUNU
T0NdIFtuZXRtb2RdIFVzaW5nIGluc3RhbmNlLW51bWJlciBvciBpbnN0YW5jZS1uYW1lIGlzc3Vl
IC0gUkU6IFdHIExhc3QgQ2FsbCByZXNvbHV0aW9ucyBpbmNvcnBvcmF0ZWQgaW4gZHJhZnQtaWV0
Zi10aWN0b2MtMTU4OHYyLXlhbmctMDYNCg0KQWNjb3JkaW5nIHRvIFJGQyA3OTUwLCBzZWN0aW9u
IDkuNCwgWUFORyBzdHJpbmdzIGFyZSBVbmljb2RlIGFuZCBJU08vSUVDIDEwNjQ2IGNoYXJhY3Rl
cnMsIGluY2x1ZGluZyB0YWIsIGNhcnJpYWdlIHJldHVybiwgYW5kIGxpbmUgZmVlZCBidXQgZXhj
bHVkaW5nIHRoZSBvdGhlciBDMCBjb250cm9sIGNoYXJhY3RlcnMsIHRoZSBzdXJyb2dhdGUgYmxv
Y2tzLCBhbmQgdGhlIG5vbmNoYXJhY3RlcnMuIE9mIGNvdXJzZSwgaGFuZGxpbmcgVW5pY29kZSBj
b3JyZWN0bHkgY2FuIHN0aWxsIGJlIGEgbG90IG9mIGZ1biBhbmQgc3lzdGVtcyB0aGF0IGRvIG5v
dCBnZXQgdGhpcyByaWdodCBtaWdodCBzdGlsbCBjcmFzaCBvciBsb2NrdXAuDQoNCi9qcw0KDQpP
biBXZWQsIE5vdiAyMiwgMjAxNyBhdCAwODoxNjoyMkFNIC0wNTAwLCBCb2Iga2I4dHEgd3JvdGU6
DQo+IEhpDQo+IA0KPiBJZiB5b3UgY2hhbmdlIHRvIOKAnGluc3RhbmNlIG5hbWXigJ0gYmUgdmVy
eSBjbGVhciBvbiB0aGUgY2hhcmFjdGVyIHNldChzKSANCj4gYWxsb3dlZC4gSSBoYXZlIHNlZW4g
c29tZSByZWFsbHkgYmFkIHNpZGUgZWZmZWN0cyB3aGVuIHVuZXhwZWN0ZWQgDQo+IGNoYXJhY3Rl
ciBzZXRzIHNob3cgdXAgaW4gSUQgZmllbGRzLiBTb2Z0d2FyZSB0cmllcyB0byBwYXJzZSBpdCBm
b3IgcHJlc2VudGF0aW9uIG9uIGEgc2NyZWVuIG9yIGludG8gYSBsb2cuIFRoZSByZXN1bHQgaXMg
YSBjcmFzaCBvciBsb2NrdXAuDQo+IA0KPiBCb2INCj4gDQo+ID4gT24gTm92IDIxLCAyMDE3LCBh
dCAxMDoxOCBQTSwgWHVqaW5jaHVuIDx4dWppbmNodW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4g
DQo+ID4gSGkgUm9kbmV5LA0KPiA+IA0KPiA+IEluIG15IG9waW5pb24sIGluc3RhbmNlLW5hbWUg
b3IgaW5zdGFuY2UtbnVtYmVyIGRvZXMgbm90IG1hdHRlciBpZiB0aGUgbnVtYmVyIG9mIGluc3Rh
bmNlcyBhcmUgc21hbGwuIEJ1dCBpZiB0aGUgaW5zdGFuY2VzIG1heSBncm93IGludG8gaHVuZHJl
ZHMgb3IgbW9yZSBpbiBzY2FsZSwgdGhlbiBzdHJpbmcgc2hvdWxkIG5vdCBiZSBhIGNob2ljZS4N
Cj4gPiANCj4gPiBXZSBrbm93IGhvdyBhd2t3YXJkIGl0IGlzIHRvIHN0b3JlIGFuZCBzb3J0IG91
dCBhIGtleSBvZiBzdHJpbmcgY29tcGFyZWQgd2l0aCBhbiBpbnRlZ2VyLg0KPiA+IA0KPiA+IFRo
YW5rcw0KPiA+IA0KPiA+IEppbmNodW4gWFUNCj4gPiANCj4gPiAtLS0tLemCruS7tuWOn+S7ti0t
LS0tDQo+ID4g5Y+R5Lu25Lq6OiBSb2RuZXkgQ3VtbWluZ3MgW21haWx0bzpyb2RuZXkuY3VtbWlu
Z3NAbmkuY29tXQ0KPiA+IOWPkemAgeaXtumXtDogMjAxN+W5tDEx5pyIMjLml6UgMTo1Ng0KPiA+
IOaUtuS7tuS6ujogSmlhbmd5dWFubG9uZzsgdGljdG9jQGlldGYub3JnOyBBbGV4IENhbXBiZWxs
OyBLYXJlbiBPJ0Rvbm9naHVlDQo+ID4g5oqE6YCBOiBYaWFuIExpdTsgWHVqaW5jaHVuOyBuZXRt
b2RAaWV0Zi5vcmcNCj4gPiDkuLvpopg6IFJFOiBVc2luZyBpbnN0YW5jZS1udW1iZXIgb3IgaW5z
dGFuY2UtbmFtZSBpc3N1ZSAtIFJFOiBXRyBMYXN0IA0KPiA+IENhbGwgcmVzb2x1dGlvbnMgaW5j
b3Jwb3JhdGVkIGluIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA2DQo+ID4gDQo+ID4g
SGkgWXVhbmxvbmcsDQo+ID4gDQo+ID4gSSBoYXZlIG5vIGNvbmNlcm5zIHdpdGggaW5zdGFuY2Ut
bnVtYmVyLCBhcyB0aGF0IGlzIHdoYXQgdGhlIHVwY29taW5nIDE1ODggcmV2aXNpb24gb3V0bGlu
ZXMgZm9yIG1hbmFnZW1lbnQuDQo+ID4gDQo+ID4gSSBhbHNvIGhhdmUgbm8gc3Ryb25nIG9iamVj
dGlvbnMgYWdhaW5zdCBjaGFuZ2luZyBpbnN0YW5jZS1udW1iZXIgdG8gaW5zdGFuY2UtbmFtZS4g
SWYgd2UgZG8gdGhhdCwgSSB0aGluayBpdCB3b3VsZCBiZSBiZXN0IHRvIG1ha2UgdGhlIHNhbWUg
Y2hhbmdlIGluIHRoZSB1cGNvbWluZyAxNTg4IHJldmlzaW9uLiBJIGFza2VkIHRoZSAxNTg4IHdv
cmtpbmcgZ3JvdXAgZm9yIG9waW5pb24sIGJ1dCBJIGhhdmVuJ3QgaGVhcmQgYmFjayBvbiB0aGF0
Lg0KPiA+IA0KPiA+IEFsbCB0aGluZ3MgYmVpbmcgZXF1YWwsIG15IHByZWZlcmVuY2UgaXMgdG8g
Z28gd2l0aCBpbnN0YW5jZS1udW1iZXIuDQo+ID4gDQo+ID4gUm9kbmV5DQo+ID4gDQo+ID4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBKaWFuZ3l1YW5sb25nIFttYWlsdG86
amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjAs
IDIwMTcgNzozNCBBTQ0KPiA+IFRvOiB0aWN0b2NAaWV0Zi5vcmc7IEFsZXggQ2FtcGJlbGwgOyBS
b2RuZXkgQ3VtbWluZ3MgOyBLYXJlbiANCj4gPiBPJ0Rvbm9naHVlDQo+ID4gQ2M6IFhpYW4gTGl1
IDsgWHVqaW5jaHVuIDsgbmV0bW9kQGlldGYub3JnDQo+ID4gU3ViamVjdDogVXNpbmcgaW5zdGFu
Y2UtbnVtYmVyIG9yIGluc3RhbmNlLW5hbWUgaXNzdWUgLSBSRTogV0cgTGFzdCANCj4gPiBDYWxs
IHJlc29sdXRpb25zIGluY29ycG9yYXRlZCBpbiBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFu
Zy0wNg0KPiA+IA0KPiA+IEhpIGFsbCwNCj4gPiANCj4gPiBJdGVtICM1IGJlbG93IGlzIHRoZSBs
YXN0IG9wZW4gaXNzdWUgd2UgZGlzY3Vzc2VkIGJvdGggaW4gZW1haWxzIGFuZCBpbiBJRUVFIDE1
ODggbWFpbGluZyBsaXN0IG9uIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLiAgDQo+ID4g
SW4gYSBzdW1tYXJ5OiBpbiBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZywgbGlzdCBpbnN0
YW5jZS1saXN0IGhhcyBhIGtleSBvZiAiaW5zdGFuY2UtbnVtYmVyIiwgYnV0IHRoZXJlIHdlcmUg
ZGlzY3Vzc2lvbnMgd2hldGhlciB0byB1c2UgaW5zdGFuY2UtbmFtZSAoYSBzdHJpbmcpIGluc3Rl
YWQuDQo+ID4gDQo+ID4gQ3VycmVudGx5LCAiaW5zdGFuY2UtbnVtYmVyIiBpbiBkcmFmdC1pZXRm
LXRpY3RvYy0xNTg4djIteWFuZy0wNiBhbGlnbnMgd2VsbCB3aXRoIHRoZSB0ZXh0cyBpbiB0aGUg
bmV3IHJldmlzaW9uIG9mIElFRUUgMTU4OCAoRDEuMi8yMDE3KTogDQo+ID4gICAiVGhlIGluc3Rh
bmNlTGlzdCBpcyBpbmRleGVkIHVzaW5nIGEgbnVtYmVyIHRoYXQgaXMgdW5pcXVlIHBlciBQVFAg
SW5zdGFuY2Ugd2l0aGluIHRoZSBQVFAgTm9kZSwgYXBwbGljYWJsZSB0byB0aGUgDQo+ID4gICBt
YW5hZ2VtZW50IGNvbnRleHQgb25seSAoaS5lLiBub3QgdXNlZCBpbiBQVFAgbWVzc2FnZXMpLiBU
aGUgZG9tYWluTnVtYmVyIG9mIHRoZSBQVFAgSW5zdGFuY2UgbXVzdCBub3QgYmUgdXNlZCBhcyB0
aGUgaW5kZXggDQo+ID4gICB0byBpbnN0YW5jZUxpc3QsIHNpbmNlIGl0IGlzIHBvc3NpYmxlIGZv
ciBhIFBUUCBOb2RlIHRvIGNvbnRhaW4gbXVsdGlwbGUgUFRQIEluc3RhbmNlcyB1c2luZyB0aGUg
c2FtZSBkb21haW5OdW1iZXIuIg0KPiA+IA0KPiA+IFRoZSBtYWluIHJlcXVpcmVtZW50IG9mIGlu
c3RhbmNlTGlzdCBpbiBJRUVFIDE1ODggaXMgdGhlIHVuaXF1ZW5lc3Mgb2YgaXRzIGluZGV4LCBh
bmQgdGhlICJrZXkiIHN0YXRlbWVudCBvZiBZQU5HIHNlcnZlcyB0aGlzIHB1cnBvc2UgdmVyeSB3
ZWxsLg0KPiA+IA0KPiA+IFRoYXQgaXMsIHdoZW4gaW5zdGFuY2UtbnVtYmVyIGlzIHVzZWQgYXMg
YSBrZXksIGEgUFRQIE5vZGUgd2l0aCBtdWx0aXBsZSBQVFAgSW5zdGFuY2VzIGNhbm5vdCB1c2Ug
dGhlIHNhbWUgaW5zdGFuY2UtbnVtYmVyIHZhbHVlIGZvciB0aGVzZSBQVFAgSW5zdGFuY2VzIChq
dXN0IGFjY29yZGluZyB0byBZQU5HIHNlbWFudGljcykuDQo+ID4gDQo+ID4gVXNpbmcgaW5zdGFu
Y2UtbmFtZSAoc3RyaW5nKSBjYW4gYWxzbyBndWFyYW50ZWUgdGhlIHVuaXF1ZW5lc3Mgb2YgdGhl
IGluZGV4IG9mIGEgbGlzdCwgYnV0IGNvbXBhcmVkIHdpdGggYW4gaW50ZWdlciwgYSBzdHJpbmcg
aXMgdXN1YWxseSBtb3JlIGNvbXBsZXggdG8gcHJvY2VzcyBhbmQgc3RvcmUuIElmIGluc3RhbmNl
LW5hbWUgaXMgbW9kZWxlZCBhcyBhbiBhcmJpdHJhcnkgbGVuZ3RoIG9mIHN0cmluZywgdGhlcmUg
aXMgZXZlbiBhIHJpc2sgb2YgYnVmZmVyLW92ZXJmbG93IGF0dGFjay4NCj4gPiANCj4gPiBGdXJ0
aGVybW9yZSwgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYy
LXlhbmcgaXMgdGFyZ2V0ZWQgYXQgSUVFRSAxNTg4LTIwMDgsIGZvciB3aGljaCBtb3N0IHByb2R1
Y3RzIHRvZGF5IG9ubHkgaGF2ZSBhIHNpbmdsZSBQVFAgaW5zdGFuY2UsIGFuZCBub3QgaGF2ZSBh
IG5hbWUgZm9yIHRoaXMgaW5zdGFuY2UsIGl0IHNlZW1zIHF1aXRlIHdlaXJkIHRvIGludHJvZHVj
ZSBhIG5hbWUgZm9yIHRoaXMgaW5zdGFuY2UuDQo+ID4gDQo+ID4gVGhlcmVmb3JlLCBJIHdvdWxk
IHN1Z2dlc3Qgd2Uga2VlcCBvbiB1c2luZyBpbnN0YW5jZS1udW1iZXIgYXMgYSBrZXkuIEJ1dCBh
cyA2NTUzNiBsaW1pdCBpcyBhIGNvbmNlcm4sIEkgZnVydGhlciBzdWdnZXN0IHRvIGNoYW5nZSBp
dHMgdHlwZSB0byB1aW50MzIuDQo+ID4gDQo+ID4gQW55IGNvbW1lbnRzIG9yIGNvbmNlcm5zIG9u
IHRoaXMgc3VnZ2VzdGlvbiB0byBtb3ZlIGZvcndhcmQ/DQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+
IFl1YW5sb25nDQo+ID4gDQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+IEZy
b206ICJKaWFuZ3l1YW5sb25nIiA8amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tPg0KPiA+IFRvOiAi
QWxleCBDYW1wYmVsbCIgPEFsZXguQ2FtcGJlbGxAQXZpYXRuZXQuY29tPjsgPHRpY3RvY0BpZXRm
Lm9yZz4NCj4gPiBDYzogIlhpYW4gTGl1IiA8bGVuZS5saXV4aWFuQGZveG1haWwuY29tPjsgIlh1
amluY2h1biINCj4gPiA8eHVqaW5jaHVuQGh1YXdlaS5jb20+OyA8bmV0bW9kQGlldGYub3JnPg0K
PiA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA3LCAyMDE3IDc6NTMgQU0NCj4gPiBTdWJqZWN0
OiBSZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsIHJlc29sdXRpb25zIGluY29ycG9yYXRlZCBpbg0K
PiA+IGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA2DQo+ID4gDQo+ID4gDQo+ID4+IEhp
IEFsZXgsDQo+ID4+IA0KPiA+PiBTb3JyeSBmb3IgYSBsYXRlIHJlcGx5IGFzIEkgc3BlbnQgdGhl
IGxhc3Qgd2VlayBmb3IgYW4gdXJnZW50IA0KPiA+PiBidXNpbmVzcw0KPiA+IHRyaXAuDQo+ID4+
IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW4gbGluZSB3aXRoIFtZSl0NCj4gPj4gDQo+ID4+IFRo
YW5rcywNCj4gPj4gWXVhbmxvbmcNCj4gPj4gDQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+ID4+IEZyb206IEFsZXggQ2FtcGJlbGwgW21haWx0bzpBbGV4LkNhbXBiZWxsQEF2aWF0
bmV0LmNvbV0NCj4gPj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDMwLCAyMDE3IDEwOjE1IEFNDQo+
ID4+IFRvOiBKaWFuZ3l1YW5sb25nOyB0aWN0b2NAaWV0Zi5vcmcNCj4gPj4gQ2M6IFhpYW4gTGl1
OyBYdWppbmNodW47IG5ldG1vZEBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogV0cgTGFzdCBD
YWxsIHJlc29sdXRpb25zIGluY29ycG9yYXRlZCBpbg0KPiA+IGRyYWZ0LWlldGYtdGljdG9jLTE1
ODh2Mi15YW5nLTA2DQo+ID4+IA0KPiA+PiBIaSwNCj4gPj4gSSd2ZSByZXZpZXdlZCB0aGlzIGxh
dGVzdCBkcmFmdCBhbmQgaGF2ZSBzb21lIG1vcmUgY29tbWVudHMuDQo+ID4+IA0KPiA+PiAxLiBJ
IGZpbmQgdGhlIGludHJvZHVjdGlvbiB0byBiZSB1bm5lY2Vzc2FyaWx5IHdvcmR5OyBpdCBmZWVs
cyBsaWtlIA0KPiA+PiBpdA0KPiA+IHdhcyB3cml0dGVuIHdpdGggYSB2aWV3IG9mIG5vdCBtaXNz
aW5nIGFueSBpbmZvcm1hdGlvbiBvdXQsIHJhdGhlciB0aGFuIHRyeWluZyB0byBrZWVwIGl0IGNv
bmNpc2UuDQo+ID4+ICAgRm9yIGV4YW1wbGUsIHRoZXJlIGlzIG5vIG5lZWQgdG8gZWxhYm9yYXRl
IG9uIFlBTkcgZGF0YSB0eXBlcyBoZXJlLg0KPiA+IEl0IGlzIGFsc28gbm90IGhlcmUgdG8gc2Vs
bCBZQU5HLg0KPiA+PiANCj4gPj4gW1lKXSBZZXMsIHdlIGFyZSB0cnlpbmcgdG8gZ2l2ZSBzb21l
IGludHJvZHVjdG9yeSBpbmZvcm1hdGlvbiBmb3IgDQo+ID4+IGFuDQo+ID4gb3V0c2lkZXIgd2hv
IG1heSBub3QgYmUgZmFtaWxpYXIgd2l0aCBQVFAgb3IgWUFORywgYW5kIGV4cGxhaW4gd2h5IGEg
WUFORyBmb3IgUFRQIGlzIG5lZWRlZC4gVGhlIGp1aWN5IHBhcnQgb2YgdGhpcyBkb2N1bWVudCBp
cyBpdHMgWUFORyBtb2R1bGUsIGFuZCBwZW9wbGUgY2FuIHNraXAgYWxsIHRoZSBvdGhlciB0ZXh0
cyBpZiB0aGV5IGFyZSBmYW1pbGlhciB3aXRoIFBUUCBhbmQgWUFORy4NCj4gPj4gQmVzaWRlcywg
dGhlc2UgdGV4dHMgaGF2ZSBiZWVuIGNvbnRyaWJ1dGVkIGJ5IG11bHRpcGxlIHNvdXJjZXMgYW5k
DQo+ID4gdW5kZXJnb25lIHNldmVyYWwgcm91bmRzIG9mIHJldmlld3MsIHRodXMgSSB3aWxsIHdh
aXQgZm9yIGEgY2xlYXIgbWVzc2FnZSBmcm9tIHRoZSBUSUNUT0MgY2hhaXJzIHRvIGludHJvZHVj
ZSBhbnkgYmlnIGNoYW5nZXMgYXQgdGhpcyBsYXN0IGNhbGwgc3RhZ2UuDQo+ID4+IA0KPiA+PiAN
Cj4gPj4gT0xEOg0KPiA+PiANCj4gPj4gICBBcyBhIHN5bmNocm9uaXphdGlvbiBwcm90b2NvbCwg
SUVFRSAxNTg4LTIwMDggW0lFRUUxNTg4XSBpcyB3aWRlbHkNCj4gPj4gICBzdXBwb3J0ZWQgaW4g
dGhlIGNhcnJpZXIgbmV0d29ya3MsIGluZHVzdHJpYWwgbmV0d29ya3MsIGF1dG9tb3RpdmUNCj4g
Pj4gICBuZXR3b3JrcywgYW5kIG1hbnkgb3RoZXIgYXBwbGljYXRpb25zLiBJdCBjYW4gcHJvdmlk
ZSBoaWdoDQo+ID4+ICAgcHJlY2lzaW9uIHRpbWUgc3luY2hyb25pemF0aW9uIGFzIGZpbmUgYXMg
bmFuby1zZWNvbmRzLiBUaGUNCj4gPj4gICBwcm90b2NvbCBkZXBlbmRzIG9uIGEgUHJlY2lzaW9u
IFRpbWUgUHJvdG9jb2wgKFBUUCkgZW5naW5lIHRvDQo+ID4+ICAgZGVjaWRlIGl0cyBvd24gc3Rh
dGUgYXV0b21hdGljYWxseSwgYW5kIGEgUFRQIHRyYW5zcG9ydGF0aW9uIGxheWVyDQo+ID4+ICAg
dG8gY2FycnkgdGhlIFBUUCB0aW1pbmcgYW5kIHZhcmlvdXMgcXVhbGl0eSBtZXNzYWdlcy4gVGhl
DQo+ID4+ICAgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIGFuZCBzdGF0ZSBkYXRhIHNldHMgb2Yg
SUVFRSAxNTg4LTIwMDggYXJlDQo+ID4+ICAgbnVtZXJvdXMuDQo+ID4+IA0KPiA+PiAgIEFjY29y
ZGluZyB0byB0aGUgY29uY2VwdHMgZGVzY3JpYmVkIGluIFtSRkMzNDQ0XSwgSUVFRSAxNTg4LTIw
MDgNCj4gPj4gICBpdHNlbGYgcHJvdmlkZXMgYW4gaW5mb3JtYXRpb24gbW9kZWwgaW4gaXRzIG5v
cm1hdGl2ZQ0KPiA+PiAgIHNwZWNpZmljYXRpb25zIGZvciB0aGUgZGF0YSBzZXRzIChpbiBJRUVF
IDE1ODgtMjAwOCBjbGF1c2UgOCkuIFNvbWUNCj4gPj4gICBzdGFuZGFyZGl6YXRpb24gb3JnYW5p
emF0aW9ucyBpbmNsdWRpbmcgdGhlIElFVEYgaGF2ZSBzcGVjaWZpZWQNCj4gPj4gICBkYXRhIG1v
ZGVscyBpbiBNSUJzIChNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2VzKSBmb3IgSUVFRSAxNTg4
LQ0KPiA+PiAgIDIwMDggZGF0YSBzZXRzIChlLmcuIFtSRkM4MTczXSwgW0lFRUU4MDIxQVNdKS4g
VGhlc2UgTUlCcyBhcmUNCj4gPj4gICB0eXBpY2FsbHkgZm9jdXNlZCBvbiByZXRyaWV2YWwgb2Yg
c3RhdGUgZGF0YSB1c2luZyB0aGUgU2ltcGxlDQo+ID4+ICAgTmV0d29yayBNYW5hZ2VtZW50IFBy
b3RvY29sIChTTk1QKSwgZnVydGhlcm1vcmUsIGNvbmZpZ3VyYXRpb24gb2YNCj4gPj4gICBQVFAg
ZGF0YSBzZXRzIGlzIG5vdCBjb25zaWRlcmVkIGluIFtSRkM4MTczXS4NCj4gPj4gDQo+ID4+ICAg
U29tZSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgYXBwbGljYXRpb25zIHJlcXVpcmUgdGhhdCB0aGUg
bWFuYWdlbWVudA0KPiA+PiAgIG9mIHRoZSBJRUVFIDE1ODgtMjAwOCBzeW5jaHJvbml6YXRpb24g
bmV0d29yayBiZSBmbGV4aWJsZSBhbmQgbW9yZQ0KPiA+PiAgIEludGVybmV0LWJhc2VkICh0eXBp
Y2FsbHkgb3ZlcmxhaWQgb24gdGhlaXIgdHJhbnNwb3J0IG5ldHdvcmtzKS4NCj4gPj4gICBTb2Z0
d2FyZSBEZWZpbmVkIE5ldHdvcmsgKFNETikgaXMgYW5vdGhlciBkcml2aW5nIGZhY3Rvciwgd2hp
Y2gNCj4gPj4gICBkZW1hbmRzIGFuIGltcHJvdmVkIGNvbmZpZ3VyYXRpb24gY2FwYWJpbGl0eSBv
ZiBzeW5jaHJvbml6YXRpb24NCj4gPj4gICBuZXR3b3Jrcy4NCj4gPj4gDQo+ID4+ICAgWUFORyBb
UkZDNjAyMF0gaXMgYSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIHVzZWQgdG8gbW9kZWwNCj4gPj4g
ICBjb25maWd1cmF0aW9uIGFuZCBzdGF0ZSBkYXRhIG1hbmlwdWxhdGVkIGJ5IG5ldHdvcmsgbWFu
YWdlbWVudA0KPiA+PiAgIHByb3RvY29scyBsaWtlIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24g
UHJvdG9jb2wgKE5FVENPTkYpDQo+ID4+ICAgW1JGQzYyNDFdLiBBIHNtYWxsIHNldCBvZiBidWls
dC1pbiBkYXRhIHR5cGVzIGFyZSBkZWZpbmVkIGluDQo+ID4+ICAgW1JGQzYwMjBdLCBhbmQgYSBj
b2xsZWN0aW9uIG9mIGNvbW1vbiBkYXRhIHR5cGVzIGFyZSBmdXJ0aGVyDQo+ID4+ICAgZGVmaW5l
ZCBpbiBbUkZDNjk5MV0uIEFkdmFudGFnZXMgb2YgWUFORyBpbmNsdWRlIEludGVybmV0IGJhc2Vk
DQo+ID4+ICAgY29uZmlndXJhdGlvbiBjYXBhYmlsaXR5LCB2YWxpZGF0aW9uLCByb2xsYmFjayBh
bmQgc28gb24uIEFsbCBvZg0KPiA+PiAgIHRoZXNlIGNoYXJhY3RlcmlzdGljcyBtYWtlIGl0IGF0
dHJhY3RpdmUgdG8gYmVjb21lIGFub3RoZXINCj4gPj4gICBjYW5kaWRhdGUgbW9kZWxpbmcgbGFu
Z3VhZ2UgZm9yIElFRUUgMTU4OC0yMDA4Lg0KPiA+PiANCj4gPj4gTkVXOg0KPiA+PiANCj4gPj4g
ICBJRUVFIDE1ODgtMjAwOCBpcyBhIHRpbWUgcHJvdG9jb2wgdGhhdCBwcm92aWRlcyBoaWdoIHBy
ZWNpc2lvbiB0aW1lDQo+ID4+ICAgc3luY2hyb25pemF0aW9uIGFzIGZpbmUgYXMgbmFuby1zZWNv
bmRzLg0KPiA+PiANCj4gPj4gICBJRUVFIDE1ODgtMjAwOCBpdHNlbGYgcHJvdmlkZXMgYW4gaW5m
b3JtYXRpb24gbW9kZWwgaW4gaXRzDQo+ID4gbm9ybWF0aXZlDQo+ID4+ICAgc3BlY2lmaWNhdGlv
bnMgZm9yIHRoZSBkYXRhIHNldHMgKElFRUUgMTU4OC0yMDA4IGNsYXVzZSA4KS4NCj4gPj4gICBT
dGFuZGFyZCBpbmZvcm1hdGlvbiBtb2RlbHMgKGUuZy4gW1JGQzgxNzNdLCBbSUVFRTgwMjFBU10p
IGhhdmUNCj4gPiBiZWVuDQo+ID4+ICAgcHJldmlvdXNseSBkZWZpbmVkIGFzIE1JQnMgZm9jdXNl
ZCBvbiB0aGUgcmV0cmlldmFsIG9mIHN0YXRlIGRhdGENCj4gPiB1c2luZw0KPiA+PiAgIFNOTVAg
W1JGQzExNTddLg0KPiA+PiANCj4gPj4gICBZQU5HIFtSRkM2MDIwXSBpcyBhIGRhdGEgbW9kZWxp
bmcgbGFuZ3VhZ2UgdXNlZCB0byBtb2RlbA0KPiA+IGNvbmZpZ3VyYXRpb24NCj4gPj4gICBhbmQg
c3RhdGUgZGF0YSBtYW5pcHVsYXRlZCBieSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGxp
a2UNCj4gPiBORVRDT05GDQo+ID4+ICAgW1JGQzYyNDFdLg0KPiA+PiANCj4gPj4gMi4gQ2FuIHdl
IHJlZmVyIHRvIHRoZSBzeXN0ZW0gYXMgc2ltcGx5IFBUUCByYXRoZXIgdGhhbiBJRUVFDQo+ID4g
MTU4OCgtMjAwOCk/DQo+ID4+IFtZSl0gQWR2aWNlIGZyb20gSUVFRSAxNTg4IGlzLCB3ZSBuZWVk
IHRvIHVzZSAiMTU4OC0yMDA4IiBhcyBtdWNoIA0KPiA+PiBhcw0KPiA+IHBvc3NpYmxlIHRvIGhl
bHAgY2xhcmlmeSB0aGF0IHRoZSBzY29wZSBvZiB0aGlzIFlBTkcgaXMgbGltaXRlZCB0byB0aGUg
cHVibGlzaGVkIDE1ODggc3RhbmRhcmQuDQo+ID4+IA0KPiA+PiANCj4gPj4gMy4gVGhlcmUgaXMg
aW5zdWZmaWNpZW50IHNwYWNpbmcgaGVyZSB0byBzZXBhcmF0ZSB0aGUgdGVybXMgZnJvbSANCj4g
Pj4gdGhlaXINCj4gPiBkZWZpbml0aW9uczoNCj4gPj4gT0xEDQo+ID4+IA0KPiA+PiAgIFBUUCBk
YXRhc2V0ICBTdHJ1Y3R1cmVkIGF0dHJpYnV0ZXMgb2YgY2xvY2tzIChhbiBPQywgQkMgb3IgVEMp
IHVzZWQNCj4gPj4gICBmb3IgUFRQIHByb3RvY29sIGRlY2lzaW9ucyBhbmQgZm9yIHByb3ZpZGlu
ZyB2YWx1ZXMgZm9yIFBUUCBtZXNzYWdlDQo+ID4+ICAgZmllbGRzLCBzZWUgU2VjdGlvbiA4IG9m
IFtJRUVFMTU4OF0uDQo+ID4+IA0KPiA+PiAgIFBUUCBpbnN0YW5jZSBBIFBUUCBpbXBsZW1lbnRh
dGlvbiBpbiB0aGUgZGV2aWNlIChpLmUuLCBhbiBPQyBvciBCQykNCj4gPj4gICByZXByZXNlbnRl
ZCBieSBhIHNwZWNpZmljIFBUUCBkYXRhc2V0Lg0KPiA+PiANCj4gPj4gTkVXDQo+ID4+IA0KPiA+
PiAgIFBUUCBkYXRhc2V0DQo+ID4+ICAgICBTdHJ1Y3R1cmVkIGF0dHJpYnV0ZXMgb2YgY2xvY2tz
IChhbiBPQywgQkMgb3IgVEMpIHVzZWQNCj4gPj4gICAgIGZvciBQVFAgcHJvdG9jb2wgZGVjaXNp
b25zIGFuZCBmb3IgcHJvdmlkaW5nIHZhbHVlcyBmb3IgUFRQDQo+ID4gbWVzc2FnZQ0KPiA+PiAg
ICAgZmllbGRzLCBzZWUgU2VjdGlvbiA4IG9mIFtJRUVFMTU4OF0uDQo+ID4+IA0KPiA+PiAgIFBU
UCBpbnN0YW5jZQ0KPiA+PiAgICAgQSBQVFAgaW1wbGVtZW50YXRpb24gaW4gdGhlIGRldmljZSAo
aS5lLiwgYW4gT0Mgb3IgQkMpDQo+ID4+ICAgICByZXByZXNlbnRlZCBieSBhIHNwZWNpZmljIFBU
UCBkYXRhc2V0Lg0KPiA+PiBbWUpdIE9LLg0KPiA+PiANCj4gPj4gNC4gVGhlcmUncyBhIHNpbmd1
bGFyL3BsdXJhbCBtaXNtYXRjaCBoZXJlOg0KPiA+PiANCj4gPj4gICBtb2R1bGUuIFF1ZXJ5IGFu
ZCBjb25maWd1cmF0aW9uIG9mIGRldmljZSB3aWRlIG9yIHBvcnQgc3BlY2lmaWMNCj4gPj4gICBj
b25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGFuZCBjbG9jayBkYXRhIHNldCBpcyBkZXNjcmliZWQg
Zm9yIHRoaXMNCj4gPj4gICB2ZXJzaW9uLg0KPiA+PiBbWUpdIEdvb2QsIHdlIHdpbGwgY2hhbmdl
ICdpcycgdG8gJ2FyZScuDQo+ID4+IA0KPiA+PiBhbmQgaGVyZToNCj4gPj4gDQo+ID4+ICAgUXVl
cnkgYW5kIGNvbmZpZ3VyYXRpb24gb2YgY2xvY2sgaW5mb3JtYXRpb24gaW5jbHVkZToNCj4gPj4g
DQo+ID4+IA0KPiA+PiA1LiBUaGUgY2hvaWNlIG9mIHVpbnQxNiBhcyBpbnN0YW5jZS1udW1iZXIg
bGltaXRzIGltcGxlbWVudGF0aW9ucyANCj4gPj4gdG8NCj4gPiA2NTUzNiBkaXN0aW5jdCBpbnN0
YW5jZXMuDQo+ID4+ICAgV2hpbGUgSSBoYXZlIGEgaGFyZCB0aW1lIGltYWdpbmluZyBhIHN5c3Rl
bSB3aXRoIG1vcmUgdGhhbiA2NTUzNg0KPiA+IFBUUCBpbnN0YW5jZXMsIEkgd291bGQgcHJlZmVy
IHRvIGF2b2lkIGltcG9zaW5nIGFyYml0cmFyeSBsaW1pdHMuDQo+ID4+ICAgSSB3b3VsZCByZWNv
bW1lbmQgY2hhbmdpbmcgaW5zdGFuY2UtbnVtYmVyIHRvIGEgc3RyaW5nIChhbmQNCj4gPiByZW5h
bWluZyBpdCB0byBpbnN0YW5jZS1uYW1lIG9yIGp1c3QgbmFtZSkuDQo+ID4+IFtZSl0gVGhlIDE1
ODgtMjAwOCBzdXBwb3J0cyBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgUFRQLCBidXQgaXQgaXMNCj4g
PiBhbWJpZ3VvdXMgaW4gaXRzIG9yZ2FuaXphdGlvbiBvZiB0aG9zZSBQVFAgaW5zdGFuY2VzLCBl
c3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIG1hbmFnZW1lbnQuDQo+ID4+IEluIHRoZSAxNTg4IG5l
dyByZXZpc2lvbiwgdGhlcmUgaXMgYW4gZXhwbGljaXQgbGlzdCBvZiBQVFAgDQo+ID4+IGluc3Rh
bmNlcywNCj4gPiBhbmQgdGhhdCBsaXN0IGlzIGluZGV4ZWQgdXNpbmcgYSBudW1iZXIgKG5vdCBu
YW1lKS4gVGh1cyB0byBhbGlnbiB3aXRoIHRoZSBuZXcgcmV2aXNpb24sIHdlIG5lZWQgdG8ga2Vl
cCBpdCBpbnN0YW5jZS1udW1iZXIuDQo+ID4+IElmIDY1NTM2IGxpbWl0IGlzIGEgY29uY2Vybiwg
aG93IGFib3V0IGNoYW5nZSBpdCB0byB1aW50MzIsIGFueQ0KPiA+IGNvbmNlcm5zPw0KPiA+PiAN
Cj4gPj4gDQo+ID4+IDYuIEkgc3RpbGwgcmVjb21tZW5kIHJlbW92aW5nIC1kcyBmcm9tIHRoZSBZ
QU5HIGVsZW1lbnQgbmFtZXMgdGhhdA0KPiA+IHN0aWxsIGluY2x1ZGUgaXQuIEl0IGRvZXNuJ3Qg
YXBwZWFyIHRvIGFkZCBhbnkgdmFsdWUuDQo+ID4+IFtZSl0gUm9kbmV5J3Mgb3BpbmlvbjogdGhl
IHZhbHVlIG9mIHVzaW5nICdkcycgaXMgdGhhdCB0aGUgMTU4OA0KPiA+IGRvY3VtZW50IG9uIHdo
aWNoIHRoaXMgWUFORyBtb2RlbCBpcyBiYXNlZCB1c2VzICJEZWZhdWx0RFMiIGFzIGEgdGVybS4N
Cj4gPiBQVFAgZXhwZXJ0cyBldmVuIHNheSAiZGVmYXVsdCBkZWUgZXNzIiB2ZXJiYWxseSB3aGVu
IHJlZmVycmluZyB0byB0aGlzIGRhdGEuIElmIHdlIGNoYW5nZWQgdGhpcyB0byBqdXN0ICJkZWZh
dWx0IiwgUFRQIGV4cGVydHMgbWlnaHQgYXNzdW1lIHRoYXQgd2UgYXJlIHJlZmVycmluZyB0byBz
b21ldGhpbmcgZW50aXJlbHkgbmV3IHRvIFlBTkcuIFRodXMsIHRvIGFsaWduIHdpdGggMTU4OC0y
MDA4LCB0aGUgc2FtZSBzZXQgb2YgdGVybWlub2xvZ2llcyBhcmUgdXNlZC4NCj4gPj4gDQo+ID4+
IDcuIFdoYXQ7cyB0aGUgcmVsZXZhbmNlIG9mIGluamVjdGlvbiBhdHRhY2tzIHJlbGV2YW50IHRv
IHRoaXMgWUFORw0KPiA+IG1vZHVsZT8NCj4gPj4gW1lKXSBUaGlzIGlzIGEgZ2VuZXJhbCBzdGF0
ZW1lbnQgd2hpY2ggaXMgYXBwbGljYWJsZSB0byB0aGlzIFlBTkcNCj4gPiBtb2R1bGUgYW5kIG90
aGVyIFlBTkcgbW9kdWxlcyBhcyB3ZWxsLg0KPiA+PiBUaGFua3MgYWdhaW4sDQo+ID4+IFl1YW5s
b25nDQo+ID4+IA0KPiA+PiBBbGV4DQo+ID4+IA0KPiA+PiANCj4gPj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSmlhbmd5dWFubG9uZw0KPiA+IDxqaWFuZ3l1YW5s
b25nQGh1YXdlaS5jb20+DQo+ID4+IFNlbnQ6IEZyaWRheSwgMjcgT2N0b2JlciAyMDE3IDM6MjEg
cC5tLg0KPiA+PiBUbzogdGljdG9jQGlldGYub3JnDQo+ID4+IENjOiBYaWFuIExpdTsgWHVqaW5j
aHVuOyBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogW25ldG1vZF0gV0cgTGFzdCBDYWxs
IHJlc29sdXRpb25zIGluY29ycG9yYXRlZCBpbg0KPiA+IGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2
Mi15YW5nLTA2DQo+ID4+IA0KPiA+PiBEZWFyIGFsbCwNCj4gPj4gDQo+ID4+IEJhc2VkIG9uIGFs
bCB0aGUgY29tbWVudHMgd2UgcmVjZWl2ZWQgZHVyaW5nIHRoZSBXRyBMYXN0IENhbGwgDQo+ID4+
IHByb2Nlc3MsDQo+ID4gd2UndmUgdXBkYXRlZCB0aGUgZG9jdW1lbnQgdG8gdmVyc2lvbiA2Lg0K
PiA+PiBXZSBiZWxpZXZlIGFsbCB0aGUgTEMgY29tbWVudHMgYXJlIHJlc29sdmVkIGFuZCB0aGUg
Y29uc2Vuc3VzIGlzDQo+ID4gcmVmbGVjdGVkIGluIHRoaXMgbmV3IHJldmlzaW9uLg0KPiA+PiBN
YW55IHRoYW5rcyB0byBNYXJ0aW4sIFRhbCwgT3BoZXIsIEFsZXgsIEpvaG4gYW5kIG1hbnkgb3Ro
ZXJzIHdobyANCj4gPj4gaGFkDQo+ID4gcmV2aWV3ZWQgYW5kIGNvbW1lbnRlZCBvbiB0aGlzIGRy
YWZ0Lg0KPiA+PiANCj4gPj4gQ2hlZXJzLA0KPiA+PiBZdWFubG9uZyBvbiBiZWhhbGYgb2YgYWxs
IGNvYXV0aG9ycw0KPiA+PiANCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g
RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll
dGYub3JnXQ0KPiA+PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjcsIDIwMTcgOTo0OCBBTQ0KPiA+
PiBUbzogWGlhbiBMaXU7IFJvZG5leSBDdW1taW5nczsgcm9kbmV5LmN1bW1pbmdzQG5pLmNvbTsg
DQo+ID4+IEppYW5neXVhbmxvbmc7DQo+ID4gWHVqaW5jaHVuDQo+ID4+IFN1YmplY3Q6IE5ldyBW
ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFu
Zy0wNi50eHQNCj4gPj4gDQo+ID4+IA0KPiA+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt
aWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDYudHh0DQo+ID4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs
eSBzdWJtaXR0ZWQgYnkgWXVhbmxvbmcgSmlhbmcgYW5kIHBvc3RlZCB0byB0aGUNCj4gPiBJRVRG
IHJlcG9zaXRvcnkuDQo+ID4+IA0KPiA+PiBOYW1lOiAgICAgICAgICAgZHJhZnQtaWV0Zi10aWN0
b2MtMTU4OHYyLXlhbmcNCj4gPj4gUmV2aXNpb246ICAgICAgIDA2DQo+ID4+IFRpdGxlOiAgICAg
ICAgICBZQU5HIERhdGEgTW9kZWwgZm9yIElFRUUgMTU4OC0yMDA4DQo+ID4+IERvY3VtZW50IGRh
dGU6ICAyMDE3LTEwLTI2DQo+ID4+IEdyb3VwOiAgICAgICAgICB0aWN0b2MNCj4gPj4gUGFnZXM6
ICAgICAgICAgIDMwDQo+ID4+IFVSTDoNCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu
dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pbg0KPiA+IHRlcm5ldC0yRGRy
YWZ0c19kcmFmdC0yRGlldGYtMkR0aWN0b2MtMkQxNTg4djItMkR5YW5nLTJEMDYudHgmZD1Ed0lG
DQo+ID4gZ1EmYz1JXzBZd29LeTd6NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1NqaXhBJnI9
V0E3MXNmMm83RHc3Q2JZaEYNCj4gPiB0MjREUGp0M2xKdXVwc3dXWWRuYm9LYlo4ayZtPW9RVHVo
eDBFX3J0eWsxOGU4OUZpcjgya0x4dXJVQzR5WGNpWFpNSQ0KPiA+IHFTdHcmcz1OME41a0JQY0dN
aXZYV3dzcEhFT2MtYlAwbWJZcGtLdTJJdk0yQXN5Zl84JmU9DQo+ID4gdA0KPiA+PiBTdGF0dXM6
DQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB
X19kYXRhdHJhY2tlci5pZXQNCj4gPiBmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEdGljdG9jLTJE
MTU4OHYyLTJEeWFuZ18mZD1Ed0lGZ1EmYz1JXzBZd29LeQ0KPiA+IDd6NUxNVFZkeU82WUNpRTJ1
ekkxampaWnVJUGVsY1NqaXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjREUGp0M2xKdXVwDQo+ID4g
c3dXWWRuYm9LYlo4ayZtPW9RVHVoeDBFX3J0eWsxOGU4OUZpcjgya0x4dXJVQzR5WGNpWFpNSXFT
dHcmcz1hWWxvdngNCj4gPiBfa1RRdEFpSkFVTVRKbjhOQ1JaUUlpX2pFVk5hLXRDXzVIRmxrJmU9
DQo+ID4+IEh0bWxpemVkOg0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfDQo+ID4gaHRtbF9kcmFmdC0yRGlldGYt
MkR0aWN0b2MtMkQxNTg4djItMkR5YW5nLTJEMDYmZD1Ed0lGZ1EmYz1JXzBZd29LeTcNCj4gPiB6
NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1NqaXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjRE
UGp0M2xKdXVwcw0KPiA+IHdXWWRuYm9LYlo4ayZtPW9RVHVoeDBFX3J0eWsxOGU4OUZpcjgya0x4
dXJVQzR5WGNpWFpNSXFTdHcmcz1qMWFEamlVDQo+ID4gN0FldUVWLXAyMFBOd05wdlpQckdTYkJp
SExIdGE3cTA1cGFrJmU9DQo+ID4+IEh0bWxpemVkOg0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5w
cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0DQo+ID4gZi5v
cmdfZG9jX2h0bWxfZHJhZnQtMkRpZXRmLTJEdGljdG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA2JmQ9
RHdJRmdRJmMNCj4gPiA9SV8wWXdvS3k3ejVMTVRWZHlPNllDaUUydXpJMWpqWlp1SVBlbGNTaml4
QSZyPVdBNzFzZjJvN0R3N0NiWWhGdDI0RA0KPiA+IFBqdDNsSnV1cHN3V1lkbmJvS2JaOGsmbT1v
UVR1aHgwRV9ydHlrMThlODlGaXI4MmtMeHVyVUM0eVhjaVhaTUlxU3R3DQo+ID4gJnM9N3RZT3Yx
TV9FWUhDUEcxTWlPcTNCVmw3dnBCMHctTFNpRFljUUhNNGF5TSZlPQ0KPiA+PiBEaWZmOg0KPiA+
IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3
LmlldGYub3JnX3JmDQo+ID4gY2RpZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJEdGljdG9jLTJE
MTU4OHYyLTJEeWFuZy0yRDA2JmQ9RHdJRmdRJmMNCj4gPiA9SV8wWXdvS3k3ejVMTVRWZHlPNllD
aUUydXpJMWpqWlp1SVBlbGNTaml4QSZyPVdBNzFzZjJvN0R3N0NiWWhGdDI0RA0KPiA+IFBqdDNs
SnV1cHN3V1lkbmJvS2JaOGsmbT1vUVR1aHgwRV9ydHlrMThlODlGaXI4MmtMeHVyVUM0eVhjaVha
TUlxU3R3DQo+ID4gJnM9WjEyWG1fMms3Y0VBbFY3bEZRYl96dzdBLUQtSEw3N0MtS3V5MkJneUNI
QSZlPQ0KPiA+PiANCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz
IGEgWUFORyBkYXRhIG1vZGVsIGZvciB0aGUgY29uZmlndXJhdGlvbiBvZg0KPiA+PiAgIElFRUUg
MTU4OC0yMDA4IGRldmljZXMgYW5kIGNsb2NrcywgYW5kIGFsc28gcmV0cmlldmFsIG9mIHRoZQ0K
PiA+PiAgIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24sIGRhdGEgc2V0IGFuZCBydW5uaW5nIHN0
YXRlcyBvZiBJRUVFDQo+ID4+ICAgMTU4OC0yMDA4IGNsb2Nrcy4NCj4gPj4gDQo+ID4+IA0KPiA+
PiANCj4gPj4gDQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg
bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6
ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+
PiANCj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4gDQo+ID4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG5ldG1vZCBtYWlsaW5nIGxp
c3QNCj4gPj4gbmV0bW9kQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX20NCj4gPj4gYWlsbWFuX2xp
c3RpbmZvX25ldG1vZCZkPUR3SUZnUSZjPUlfMFl3b0t5N3o1TE1UVmR5TzZZQ2lFMnV6STFqalpa
dQ0KPiA+PiBJUGVsY1NqaXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjREUGp0M2xKdXVwc3dXWWRu
Ym9LYlo4ayZtPW9RVHVoeDBFDQo+ID4+IF9ydHlrMThlODlGaXI4MmtMeHVyVUM0eVhjaVhaTUlx
U3R3JnM9Y1VsMGQwd0RYOWZJd2pJRUhsaGNyZmcxN3g3cGgNCj4gPj4gcEk5UWlGNVB1WHNZZDQm
ZT0NCj4gPj4gDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPj4gbmV0bW9kQGlldGYub3JnDQo+
ID4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
d3d3LmlldGYub3JnX20NCj4gPj4gYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUZnUSZjPUlf
MFl3b0t5N3o1TE1UVmR5TzZZQ2lFMnV6STFqalpadQ0KPiA+PiBJUGVsY1NqaXhBJnI9V0E3MXNm
Mm83RHc3Q2JZaEZ0MjREUGp0M2xKdXVwc3dXWWRuYm9LYlo4ayZtPW9RVHVoeDBFDQo+ID4+IF9y
dHlrMThlODlGaXI4MmtMeHVyVUM0eVhjaVhaTUlxU3R3JnM9Y1VsMGQwd0RYOWZJd2pJRUhsaGNy
ZmcxN3g3cGgNCj4gPj4gcEk5UWlGNVB1WHNZZDQmZT0NCj4gPiANCj4gPiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFRJQ1RPQyBtYWlsaW5nIGxp
c3QNCj4gPiBUSUNUT0NAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3RpY3RvYw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcN
Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KLS0gDQpK
dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn
R21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3
NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0
cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpUSUNUT0MgbWFpbGluZyBsaXN0DQpUSUNUT0NAaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGljdG9jDQo=


From nobody Wed Nov 22 18:57: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 5B9631293E4 for ; Wed, 22 Nov 2017 18:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.427
X-Spam-Level: 
X-Spam-Status: No, score=-1.427 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, URG_BIZ=0.573] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=n1k.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-uBNDn7GhWA for ; Wed, 22 Nov 2017 18:57:36 -0800 (PST)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 6864A120454 for ; Wed, 22 Nov 2017 18:57:36 -0800 (PST)
Received: by mail-qt0-x22e.google.com with SMTP id w10so14359326qtb.10 for ; Wed, 22 Nov 2017 18:57:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n1k.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Wa9kYqnDb3ZjlyIdJdOgjAUn55GuCnjR3D73W0fkiDA=; b=ZGthsJBK9awRJvIuGOWuFaG0thGpkBlaf6tGGpNfZ4+tITZbXQurFvGoPkcrmoQGKb /6+D0HxkoZfj2QnMCFmEuKb4DkxEDKKEAInpvfBQJ1xga/9mPCuDgzuTJ4V8JIGz0L9K X81x530szKumV9gaSMzepnfAInCEVV3FTkf8c=
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=Wa9kYqnDb3ZjlyIdJdOgjAUn55GuCnjR3D73W0fkiDA=; b=SvJ3852fNsqjizc1KoakO1H7EiIYnC6vJmpcLakP2lCBCnksPPkqeT+N44Ax16Hubb V1WRNZOL52mkEiqFjCMi9J463Kt8LsMR697/9qNh0LG+fO309/NXu6xX2kRrtrFtjLqy 7uLktaB9tywmtwaiEtBknvxRjBoeAWEzpq1ouPPMTSYtO/GOtyK/ddTfhrw5tqDUFwEY xS/2Rew46YQM2YFBBuPIyel6veClpH7Ql0CyxecvXdfkcZOdf9qTRr9mZLSBu6pNmKJs 44sW7WCbrSnOhD8LzVPX35CRWrXiSUcXYd4GX7tXQgKRvh2LYfmGn/26W11q0rs0XzN4 LvEw==
X-Gm-Message-State: AJaThX5KD6wYNmIbNGStuJWL2nwEYqpeP8M87yihmNFJO5YXZKEnmgze NKG8gVHiWVMEENJf7Lj/rcHUXg==
X-Google-Smtp-Source: AGs4zMac8zAG1LJ7PrtL+0V+kFKaOykWNoQqek4B8mCilSOSN0mhNMpi2lIQWp00rwZ9mobj3AzgIQ==
X-Received: by 10.237.63.184 with SMTP id s53mr10520277qth.89.1511405855385; Wed, 22 Nov 2017 18:57:35 -0800 (PST)
Received: from [192.168.3.118] (c-174-59-234-33.hsd1.pa.comcast.net. [174.59.234.33]) by smtp.gmail.com with ESMTPSA id j66sm9377649qkd.42.2017.11.22.18.57.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 18:57:34 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Bob kb8tq 
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB652B15@dggeml507-mbx.china.huawei.com>
Date: Wed, 22 Nov 2017 21:57:32 -0500
Cc: Juergen Schoenwaelder , Xian Liu , Xujinchun , Karen O'Donoghue , "netmod@ietf.org" , "tictoc@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>  <01992158370DC941ABFFAB7233E2346046348DAB@dggeml506-mbx.china.huawei.com> <354261BF-322C-46AE-8B0D-573065A7C62B@n1k.org> <20171122145112.koipskvauriwpepq@elstar.local> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB652B15@dggeml507-mbx.china.huawei.com>
To: Jiangyuanlong 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: Re: [netmod] [TICTOC] Using instance-number or instance-name issue - RE: 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: Thu, 23 Nov 2017 02:57:39 -0000

Hi

I=E2=80=99m fine with instance number. I would not rule out instance =
name. I=E2=80=99m simply concerned about
a wide open field.=20

I would suggest a specific sub-set of characters be allowed if it goes =
to =E2=80=9Cinstance name=E2=80=9D. The
normal printable characters should be adequate. They generally are =
handled well by just about
anything you would ever use.

This is not something that is going to be an immediate crash sort of =
issue. It only will be a source of odd=20
system to system weirdness. Tracking those sorts of issues down can be =
very painful. The last one
I ran into took about 4 months of poking at this and poking at that. =
Indeed a few lines of code would=20
have prevented the problem altogether. Possibly I=E2=80=99ve just been =
uniquely un-lucky in this regard.=20

Bob

> On Nov 22, 2017, at 9:17 PM, Jiangyuanlong  =
wrote:
>=20
> Juergen & Bob,=20
>=20
> Can I assume you are in support of using instance-number in this case? =
^&^
> But seriously, maybe it makes sense to restrict the valid characters =
of a string, especially when it is used as a key.
> Otherwise, we need to note this risk in "Security considerations" of a =
RFC (actually it can become a kind of DoS attack).=20
>=20
> Thanks,
> Yuanlong
>=20
> -----Original Message-----
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Juergen =
Schoenwaelder
> Sent: Wednesday, November 22, 2017 10:51 PM
> To: Bob kb8tq
> Cc: Xian Liu; Xujinchun; Karen O'Donoghue; netmod@ietf.org; =
tictoc@ietf.org
> Subject: Re: [TICTOC] [netmod] Using instance-number or instance-name =
issue - RE: WG Last Call resolutions incorporated in =
draft-ietf-tictoc-1588v2-yang-06
>=20
> According to RFC 7950, section 9.4, YANG strings are Unicode and =
ISO/IEC 10646 characters, including tab, carriage return, and line feed =
but excluding the other C0 control characters, the surrogate blocks, and =
the noncharacters. Of course, handling Unicode correctly can still be a =
lot of fun and systems that do not get this right might still crash or =
lockup.
>=20
> /js
>=20
> On Wed, Nov 22, 2017 at 08:16:22AM -0500, Bob kb8tq wrote:
>> Hi
>>=20
>> If you change to =E2=80=9Cinstance name=E2=80=9D be very clear on the =
character set(s)=20
>> allowed. I have seen some really bad side effects when unexpected=20
>> character sets show up in ID fields. Software tries to parse it for =
presentation on a screen or into a log. The result is a crash or lockup.
>>=20
>> Bob
>>=20
>>> On Nov 21, 2017, at 10:18 PM, Xujinchun  =
wrote:
>>>=20
>>> Hi Rodney,
>>>=20
>>> In my opinion, instance-name or instance-number does not matter if =
the number of instances are small. But if the instances may grow into =
hundreds or more in scale, then string should not be a choice.
>>>=20
>>> We know how awkward it is to store and sort out a key of string =
compared with an integer.
>>>=20
>>> Thanks
>>>=20
>>> Jinchun XU
>>>=20
>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Rodney Cummings =
[mailto:rodney.cummings@ni.com]
>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B411=E6=9C=8822=E6=97=
=A5 1:56
>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Jiangyuanlong; tictoc@ietf.org; Alex =
Campbell; Karen O'Donoghue
>>> =E6=8A=84=E9=80=81: Xian Liu; Xujinchun; netmod@ietf.org
>>> =E4=B8=BB=E9=A2=98: RE: Using instance-number or instance-name issue =
- RE: WG Last=20
>>> Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
>>>=20
>>> Hi Yuanlong,
>>>=20
>>> I have no concerns with instance-number, as that is what the =
upcoming 1588 revision outlines for management.
>>>=20
>>> I also have no strong objections against changing instance-number to =
instance-name. If we do that, I think it would be best to make the same =
change in the upcoming 1588 revision. I asked the 1588 working group for =
opinion, but I haven't heard back on that.
>>>=20
>>> All things being equal, my preference is to go with instance-number.
>>>=20
>>> Rodney
>>>=20
>>> -----Original Message-----
>>> From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]
>>> Sent: Monday, November 20, 2017 7:34 AM
>>> To: tictoc@ietf.org; Alex Campbell ; Rodney Cummings ; Karen=20
>>> O'Donoghue
>>> Cc: Xian Liu ; Xujinchun ; netmod@ietf.org
>>> Subject: Using instance-number or instance-name issue - RE: WG Last=20=

>>> Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
>>>=20
>>> Hi all,
>>>=20
>>> Item #5 below is the last open issue we discussed both in emails and =
in IEEE 1588 mailing list on draft-ietf-tictoc-1588v2-yang. =20
>>> In a summary: in draft-ietf-tictoc-1588v2-yang, list instance-list =
has a key of "instance-number", but there were discussions whether to =
use instance-name (a string) instead.
>>>=20
>>> Currently, "instance-number" in draft-ietf-tictoc-1588v2-yang-06 =
aligns well with the texts in the new revision of IEEE 1588 (D1.2/2017):=20=

>>>  "The instanceList is indexed using a number that is unique per PTP =
Instance within the PTP Node, applicable to the=20
>>>  management context only (i.e. not used in PTP messages). The =
domainNumber of the PTP Instance must not be used as the index=20
>>>  to instanceList, since it is possible for a PTP Node to contain =
multiple PTP Instances using the same domainNumber."
>>>=20
>>> The main requirement of instanceList in IEEE 1588 is the uniqueness =
of its index, and the "key" statement of YANG serves this purpose very =
well.
>>>=20
>>> That is, when instance-number is used as a key, a PTP Node with =
multiple PTP Instances cannot use the same instance-number value for =
these PTP Instances (just according to YANG semantics).
>>>=20
>>> Using instance-name (string) can also guarantee the uniqueness of =
the index of a list, but compared with an integer, a string is usually =
more complex to process and store. If instance-name is modeled as an =
arbitrary length of string, there is even a risk of buffer-overflow =
attack.
>>>=20
>>> Furthermore, it should be noted that draft-ietf-tictoc-1588v2-yang =
is targeted at IEEE 1588-2008, for which most products today only have a =
single PTP instance, and not have a name for this instance, it seems =
quite weird to introduce a name for this instance.
>>>=20
>>> Therefore, I would suggest we keep on using instance-number as a =
key. But as 65536 limit is a concern, I further suggest to change its =
type to uint32.
>>>=20
>>> Any comments or concerns on this suggestion to move forward?
>>>=20
>>> Thanks,
>>> Yuanlong
>>>=20
>>> ----- Original Message -----
>>> From: "Jiangyuanlong" 
>>> To: "Alex Campbell" ; 
>>> Cc: "Xian Liu" ; "Xujinchun"
>>> ; 
>>> Sent: Tuesday, November 07, 2017 7:53 AM
>>> Subject: Re: [netmod] WG Last Call resolutions incorporated in
>>> draft-ietf-tictoc-1588v2-yang-06
>>>=20
>>>=20
>>>> Hi Alex,
>>>>=20
>>>> Sorry for a late reply as I spent the last week for an urgent=20
>>>> business
>>> trip.
>>>> Please see my comments in line with [YJ]
>>>>=20
>>>> Thanks,
>>>> Yuanlong
>>>>=20
>>>> -----Original Message-----
>>>> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
>>>> Sent: Monday, October 30, 2017 10:15 AM
>>>> To: Jiangyuanlong; tictoc@ietf.org
>>>> Cc: Xian Liu; Xujinchun; netmod@ietf.org
>>>> Subject: Re: WG Last Call resolutions incorporated in
>>> draft-ietf-tictoc-1588v2-yang-06
>>>>=20
>>>> Hi,
>>>> I've reviewed this latest draft and have some more comments.
>>>>=20
>>>> 1. I find the introduction to be unnecessarily wordy; it feels like=20=

>>>> it
>>> was written with a view of not missing any information out, rather =
than trying to keep it concise.
>>>>  For example, there is no need to elaborate on YANG data types =
here.
>>> It is also not here to sell YANG.
>>>>=20
>>>> [YJ] Yes, we are trying to give some introductory information for=20=

>>>> an
>>> outsider who may not be familiar with PTP or YANG, and explain why a =
YANG for PTP is needed. The juicy part of this document is its YANG =
module, and people can skip all the other texts if they are familiar =
with PTP and YANG.
>>>> Besides, these texts have been contributed by multiple sources and
>>> undergone several rounds of reviews, thus I will wait for a clear =
message from the TICTOC chairs to introduce any big changes at this last =
call stage.
>>>>=20
>>>>=20
>>>> OLD:
>>>>=20
>>>>  As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
>>>>  supported in the carrier networks, industrial networks, automotive
>>>>  networks, and many other applications. It can provide high
>>>>  precision time synchronization as fine as nano-seconds. The
>>>>  protocol depends on a Precision Time Protocol (PTP) engine to
>>>>  decide its own state automatically, and a PTP transportation layer
>>>>  to carry the PTP timing and various quality messages. The
>>>>  configuration parameters and state data sets of IEEE 1588-2008 are
>>>>  numerous.
>>>>=20
>>>>  According to the concepts described in [RFC3444], IEEE 1588-2008
>>>>  itself provides an information model in its normative
>>>>  specifications for the data sets (in IEEE 1588-2008 clause 8). =
Some
>>>>  standardization organizations including the IETF have specified
>>>>  data models in MIBs (Management Information Bases) for IEEE 1588-
>>>>  2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
>>>>  typically focused on retrieval of state data using the Simple
>>>>  Network Management Protocol (SNMP), furthermore, configuration of
>>>>  PTP data sets is not considered in [RFC8173].
>>>>=20
>>>>  Some service providers and applications require that the =
management
>>>>  of the IEEE 1588-2008 synchronization network be flexible and more
>>>>  Internet-based (typically overlaid on their transport networks).
>>>>  Software Defined Network (SDN) is another driving factor, which
>>>>  demands an improved configuration capability of synchronization
>>>>  networks.
>>>>=20
>>>>  YANG [RFC6020] is a data modeling language used to model
>>>>  configuration and state data manipulated by network management
>>>>  protocols like the Network Configuration Protocol (NETCONF)
>>>>  [RFC6241]. A small set of built-in data types are defined in
>>>>  [RFC6020], and a collection of common data types are further
>>>>  defined in [RFC6991]. Advantages of YANG include Internet based
>>>>  configuration capability, validation, rollback and so on. All of
>>>>  these characteristics make it attractive to become another
>>>>  candidate modeling language for IEEE 1588-2008.
>>>>=20
>>>> NEW:
>>>>=20
>>>>  IEEE 1588-2008 is a time protocol that provides high precision =
time
>>>>  synchronization as fine as nano-seconds.
>>>>=20
>>>>  IEEE 1588-2008 itself provides an information model in its
>>> normative
>>>>  specifications for the data sets (IEEE 1588-2008 clause 8).
>>>>  Standard information models (e.g. [RFC8173], [IEEE8021AS]) have
>>> been
>>>>  previously defined as MIBs focused on the retrieval of state data
>>> using
>>>>  SNMP [RFC1157].
>>>>=20
>>>>  YANG [RFC6020] is a data modeling language used to model
>>> configuration
>>>>  and state data manipulated by network management protocols like
>>> NETCONF
>>>>  [RFC6241].
>>>>=20
>>>> 2. Can we refer to the system as simply PTP rather than IEEE
>>> 1588(-2008)?
>>>> [YJ] Advice from IEEE 1588 is, we need to use "1588-2008" as much=20=

>>>> as
>>> possible to help clarify that the scope of this YANG is limited to =
the published 1588 standard.
>>>>=20
>>>>=20
>>>> 3. There is insufficient spacing here to separate the terms from=20
>>>> their
>>> definitions:
>>>> OLD
>>>>=20
>>>>  PTP dataset  Structured attributes of clocks (an OC, BC or TC) =
used
>>>>  for PTP protocol decisions and for providing values for PTP =
message
>>>>  fields, see Section 8 of [IEEE1588].
>>>>=20
>>>>  PTP instance A PTP implementation in the device (i.e., an OC or =
BC)
>>>>  represented by a specific PTP dataset.
>>>>=20
>>>> NEW
>>>>=20
>>>>  PTP dataset
>>>>    Structured attributes of clocks (an OC, BC or TC) used
>>>>    for PTP protocol decisions and for providing values for PTP
>>> message
>>>>    fields, see Section 8 of [IEEE1588].
>>>>=20
>>>>  PTP instance
>>>>    A PTP implementation in the device (i.e., an OC or BC)
>>>>    represented by a specific PTP dataset.
>>>> [YJ] OK.
>>>>=20
>>>> 4. There's a singular/plural mismatch here:
>>>>=20
>>>>  module. Query and configuration of device wide or port specific
>>>>  configuration information and clock data set is described for this
>>>>  version.
>>>> [YJ] Good, we will change 'is' to 'are'.
>>>>=20
>>>> and here:
>>>>=20
>>>>  Query and configuration of clock information include:
>>>>=20
>>>>=20
>>>> 5. The choice of uint16 as instance-number limits implementations=20=

>>>> to
>>> 65536 distinct instances.
>>>>  While I have a hard time imagining a system with more than 65536
>>> PTP instances, I would prefer to avoid imposing arbitrary limits.
>>>>  I would recommend changing instance-number to a string (and
>>> renaming it to instance-name or just name).
>>>> [YJ] The 1588-2008 supports multiple instances of PTP, but it is
>>> ambiguous in its organization of those PTP instances, especially =
with regard to management.
>>>> In the 1588 new revision, there is an explicit list of PTP=20
>>>> instances,
>>> and that list is indexed using a number (not name). Thus to align =
with the new revision, we need to keep it instance-number.
>>>> If 65536 limit is a concern, how about change it to uint32, any
>>> concerns?
>>>>=20
>>>>=20
>>>> 6. I still recommend removing -ds from the YANG element names that
>>> still include it. It doesn't appear to add any value.
>>>> [YJ] Rodney's opinion: the value of using 'ds' is that the 1588
>>> document on which this YANG model is based uses "DefaultDS" as a =
term.
>>> PTP experts even say "default dee ess" verbally when referring to =
this data. If we changed this to just "default", PTP experts might =
assume that we are referring to something entirely new to YANG. Thus, to =
align with 1588-2008, the same set of terminologies are used.
>>>>=20
>>>> 7. What;s the relevance of injection attacks relevant to this YANG
>>> module?
>>>> [YJ] This is a general statement which is applicable to this YANG
>>> module and other YANG modules as well.
>>>> Thanks again,
>>>> Yuanlong
>>>>=20
>>>> Alex
>>>>=20
>>>>=20
>>>> ________________________________________
>>>> From: netmod  on behalf of Jiangyuanlong
>>> 
>>>> Sent: Friday, 27 October 2017 3:21 p.m.
>>>> To: tictoc@ietf.org
>>>> Cc: Xian Liu; Xujinchun; netmod@ietf.org
>>>> Subject: [netmod] WG Last Call resolutions incorporated in
>>> draft-ietf-tictoc-1588v2-yang-06
>>>>=20
>>>> Dear all,
>>>>=20
>>>> Based on all the comments we received during the WG Last Call=20
>>>> process,
>>> we've updated the document to version 6.
>>>> We believe all the LC comments are resolved and the consensus is
>>> reflected in this new revision.
>>>> Many thanks to Martin, Tal, Opher, Alex, John and many others who=20=

>>>> had
>>> reviewed and commented on this draft.
>>>>=20
>>>> Cheers,
>>>> Yuanlong on behalf of all coauthors
>>>>=20
>>>> -----Original Message-----
>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>> Sent: Friday, October 27, 2017 9:48 AM
>>>> To: Xian Liu; Rodney Cummings; rodney.cummings@ni.com;=20
>>>> Jiangyuanlong;
>>> Xujinchun
>>>> Subject: New Version Notification for
>>> draft-ietf-tictoc-1588v2-yang-06.txt
>>>>=20
>>>>=20
>>>> A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
>>>> has been successfully submitted by Yuanlong Jiang and posted to the
>>> IETF repository.
>>>>=20
>>>> Name:           draft-ietf-tictoc-1588v2-yang
>>>> Revision:       06
>>>> Title:          YANG Data Model for IEEE 1588-2008
>>>> Document date:  2017-10-26
>>>> Group:          tictoc
>>>> Pages:          30
>>>> URL:
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_in=

>>> ternet-2Ddrafts_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06.tx&d=3DDwIF=

>>> gQ&c=3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbY=
hF
>>> t24DPjt3lJuupswWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMI=

>>> qStw&s=3DN0N5kBPcGMivXWwspHEOc-bP0mbYpkKu2IvM2Asyf_8&e=3D
>>> t
>>>> Status:
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet=

>>> f.org_doc_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang_&d=3DDwIFgQ&c=3DI_0Ywo=
Ky
>>> 7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuup=

>>> swWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3DaYlo=
vx
>>> _kTQtAiJAUMTJn8NCRZQIi_jEVNa-tC_5HFlk&e=3D
>>>> Htmlized:
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_=

>>> html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=3DDwIFgQ&c=3DI_0YwoK=
y7
>>> z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuups=

>>> wWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3Dj1aDj=
iU
>>> 7AeuEV-p20PNwNpvZPrGSbBiHLHta7q05pak&e=3D
>>>> Htmlized:
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet=

>>> f.org_doc_html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=3DDwIFgQ&c=

>>> =3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt2=
4D
>>> Pjt3lJuupswWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw=

>>> &s=3D7tYOv1M_EYHCPG1MiOq3BVl7vpB0w-LSiDYcQHM4ayM&e=3D
>>>> Diff:
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rf=

>>> cdiff-3Furl2-3Ddraft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=3DDwIFgQ&c=

>>> =3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt2=
4D
>>> Pjt3lJuupswWYdnboKbZ8k&m=3DoQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw=

>>> &s=3DZ12Xm_2k7cEAlV7lFQb_zw7A-D-HL77C-Kuy2BgyCHA&e=3D
>>>>=20
>>>> Abstract:
>>>>  This document defines a YANG data model for the configuration of
>>>>  IEEE 1588-2008 devices and clocks, and also retrieval of the
>>>>  configuration information, data set and running states of IEEE
>>>>  1588-2008 clocks.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at =
tools.ietf.org.
>>>>=20
>>>> The IETF Secretariat
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m=

>>>> ailman_listinfo_netmod&d=3DDwIFgQ&c=3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZ=
Zu
>>>> IPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=3DoQTuhx=
0E
>>>> _rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3DcUl0d0wDX9fIwjIEHlhcrfg17x7ph=

>>>> pI9QiF5PuXsYd4&e=3D
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m=

>>>> ailman_listinfo_netmod&d=3DDwIFgQ&c=3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZ=
Zu
>>>> IPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=3DoQTuhx=
0E
>>>> _rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=3DcUl0d0wDX9fIwjIEHlhcrfg17x7ph=

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


From nobody Wed Nov 22 23:14: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 7862812DDD0; Wed, 22 Nov 2017 23:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.327
X-Spam-Level: 
X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URG_BIZ=0.573] 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 2_5GgesFOvi5; Wed, 22 Nov 2017 23:14:06 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1A1129C64; Wed, 22 Nov 2017 23:14:04 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9E08DEC8; Thu, 23 Nov 2017 08:14:03 +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 Rf1cpuWSZOql; Thu, 23 Nov 2017 08:14:02 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Nov 2017 08:14:03 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85F0520123; Thu, 23 Nov 2017 08:14:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lGJE7s4a4vlY; Thu, 23 Nov 2017 08:13:59 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 791EB20121; Thu, 23 Nov 2017 08:13:58 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id F1829417D93D; Thu, 23 Nov 2017 08:12:29 +0100 (CET)
Date: Thu, 23 Nov 2017 08:12:29 +0100
From: Juergen Schoenwaelder 
To: Jiangyuanlong 
Cc: Bob kb8tq , Xian Liu , Xujinchun , Karen O'Donoghue , "netmod@ietf.org" , "tictoc@ietf.org" 
Message-ID: <20171123071229.i4opjdi2xi2yft25@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Jiangyuanlong , Bob kb8tq , Xian Liu , Xujinchun , Karen O'Donoghue , "netmod@ietf.org" , "tictoc@ietf.org" 
References: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>  <01992158370DC941ABFFAB7233E2346046348DAB@dggeml506-mbx.china.huawei.com> <354261BF-322C-46AE-8B0D-573065A7C62B@n1k.org> <20171122145112.koipskvauriwpepq@elstar.local> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB652B15@dggeml507-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB652B15@dggeml507-mbx.china.huawei.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] [TICTOC] Using instance-number or instance-name issue - RE: 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: Thu, 23 Nov 2017 07:14:10 -0000

I have no opinion in this specific context. That said, I generally
prefer names over numbers in configuration items.

I agree that using a plain YANG string can lead to surprises and
potential security issues if people do not expect that the identifier
can contain almost arbitrary characters. In LMAP, I started to use an
idententifier type but then at the end there was no clear opinion what
the appropriate restrictions would be and hence we ended up with a
hint to implementors in the security considerations:

   The data model uses a number of identifiers that are set by the
   Controller.  Implementors may find these identifiers useful for the
   identification of resources, e.g., to identify objects in a file
   system providing temporary storage.  Since the identifiers used by
   the YANG data model may allow characters that may be given special
   interpretation in a specific context, implementations must ensure
   that identifiers are properly mapped into safe identifiers.

I think it would be useful to have a data type (i.e.,
config-identifier) that is commonly used to name configuration
items. But it is unclear to me how to define such a type. The
yang-identifier defined in RFC 6991 is likely too restrictive if you
look at it from an internationalization point of view.

/js

On Thu, Nov 23, 2017 at 02:17:33AM +0000, Jiangyuanlong wrote:
> Juergen & Bob, 
> 
> Can I assume you are in support of using instance-number in this case? ^&^
> But seriously, maybe it makes sense to restrict the valid characters of a string, especially when it is used as a key.
> Otherwise, we need to note this risk in "Security considerations" of a RFC (actually it can become a kind of DoS attack). 
> 
> Thanks,
> Yuanlong
> 
> -----Original Message-----
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, November 22, 2017 10:51 PM
> To: Bob kb8tq
> Cc: Xian Liu; Xujinchun; Karen O'Donoghue; netmod@ietf.org; tictoc@ietf.org
> Subject: Re: [TICTOC] [netmod] Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
> 
> According to RFC 7950, section 9.4, YANG strings are Unicode and ISO/IEC 10646 characters, including tab, carriage return, and line feed but excluding the other C0 control characters, the surrogate blocks, and the noncharacters. Of course, handling Unicode correctly can still be a lot of fun and systems that do not get this right might still crash or lockup.
> 
> /js
> 
> On Wed, Nov 22, 2017 at 08:16:22AM -0500, Bob kb8tq wrote:
> > Hi
> > 
> > If you change to “instance name” be very clear on the character set(s) 
> > allowed. I have seen some really bad side effects when unexpected 
> > character sets show up in ID fields. Software tries to parse it for presentation on a screen or into a log. The result is a crash or lockup.
> > 
> > Bob
> > 
> > > On Nov 21, 2017, at 10:18 PM, Xujinchun  wrote:
> > > 
> > > Hi Rodney,
> > > 
> > > In my opinion, instance-name or instance-number does not matter if the number of instances are small. But if the instances may grow into hundreds or more in scale, then string should not be a choice.
> > > 
> > > We know how awkward it is to store and sort out a key of string compared with an integer.
> > > 
> > > Thanks
> > > 
> > > Jinchun XU
> > > 
> > > -----邮件原件-----
> > > 发件人: Rodney Cummings [mailto:rodney.cummings@ni.com]
> > > 发送时间: 2017年11月22日 1:56
> > > 收件人: Jiangyuanlong; tictoc@ietf.org; Alex Campbell; Karen O'Donoghue
> > > 抄送: Xian Liu; Xujinchun; netmod@ietf.org
> > > 主题: RE: Using instance-number or instance-name issue - RE: WG Last 
> > > Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
> > > 
> > > Hi Yuanlong,
> > > 
> > > I have no concerns with instance-number, as that is what the upcoming 1588 revision outlines for management.
> > > 
> > > I also have no strong objections against changing instance-number to instance-name. If we do that, I think it would be best to make the same change in the upcoming 1588 revision. I asked the 1588 working group for opinion, but I haven't heard back on that.
> > > 
> > > All things being equal, my preference is to go with instance-number.
> > > 
> > > Rodney
> > > 
> > > -----Original Message-----
> > > From: Jiangyuanlong [mailto:jiangyuanlong@huawei.com]
> > > Sent: Monday, November 20, 2017 7:34 AM
> > > To: tictoc@ietf.org; Alex Campbell ; Rodney Cummings ; Karen 
> > > O'Donoghue
> > > Cc: Xian Liu ; Xujinchun ; netmod@ietf.org
> > > Subject: Using instance-number or instance-name issue - RE: WG Last 
> > > Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
> > > 
> > > Hi all,
> > > 
> > > Item #5 below is the last open issue we discussed both in emails and in IEEE 1588 mailing list on draft-ietf-tictoc-1588v2-yang.  
> > > In a summary: in draft-ietf-tictoc-1588v2-yang, list instance-list has a key of "instance-number", but there were discussions whether to use instance-name (a string) instead.
> > > 
> > > Currently, "instance-number" in draft-ietf-tictoc-1588v2-yang-06 aligns well with the texts in the new revision of IEEE 1588 (D1.2/2017): 
> > >   "The instanceList is indexed using a number that is unique per PTP Instance within the PTP Node, applicable to the 
> > >   management context only (i.e. not used in PTP messages). The domainNumber of the PTP Instance must not be used as the index 
> > >   to instanceList, since it is possible for a PTP Node to contain multiple PTP Instances using the same domainNumber."
> > > 
> > > The main requirement of instanceList in IEEE 1588 is the uniqueness of its index, and the "key" statement of YANG serves this purpose very well.
> > > 
> > > That is, when instance-number is used as a key, a PTP Node with multiple PTP Instances cannot use the same instance-number value for these PTP Instances (just according to YANG semantics).
> > > 
> > > Using instance-name (string) can also guarantee the uniqueness of the index of a list, but compared with an integer, a string is usually more complex to process and store. If instance-name is modeled as an arbitrary length of string, there is even a risk of buffer-overflow attack.
> > > 
> > > Furthermore, it should be noted that draft-ietf-tictoc-1588v2-yang is targeted at IEEE 1588-2008, for which most products today only have a single PTP instance, and not have a name for this instance, it seems quite weird to introduce a name for this instance.
> > > 
> > > Therefore, I would suggest we keep on using instance-number as a key. But as 65536 limit is a concern, I further suggest to change its type to uint32.
> > > 
> > > Any comments or concerns on this suggestion to move forward?
> > > 
> > > Thanks,
> > > Yuanlong
> > > 
> > > ----- Original Message -----
> > > From: "Jiangyuanlong" 
> > > To: "Alex Campbell" ; 
> > > Cc: "Xian Liu" ; "Xujinchun"
> > > ; 
> > > Sent: Tuesday, November 07, 2017 7:53 AM
> > > Subject: Re: [netmod] WG Last Call resolutions incorporated in
> > > draft-ietf-tictoc-1588v2-yang-06
> > > 
> > > 
> > >> Hi Alex,
> > >> 
> > >> Sorry for a late reply as I spent the last week for an urgent 
> > >> business
> > > trip.
> > >> Please see my comments in line with [YJ]
> > >> 
> > >> Thanks,
> > >> Yuanlong
> > >> 
> > >> -----Original Message-----
> > >> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
> > >> Sent: Monday, October 30, 2017 10:15 AM
> > >> To: Jiangyuanlong; tictoc@ietf.org
> > >> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> > >> Subject: Re: WG Last Call resolutions incorporated in
> > > draft-ietf-tictoc-1588v2-yang-06
> > >> 
> > >> Hi,
> > >> I've reviewed this latest draft and have some more comments.
> > >> 
> > >> 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.
> > >>   For example, there is no need to elaborate on YANG data types here.
> > > It is also not here to sell YANG.
> > >> 
> > >> [YJ] Yes, we are trying to give some introductory information for 
> > >> an
> > > outsider who may not be familiar with PTP or YANG, and explain why a YANG for PTP is needed. The juicy part of this document is its YANG module, and people can skip all the other texts if they are familiar with PTP and YANG.
> > >> Besides, these texts have been contributed by multiple sources and
> > > undergone several rounds of reviews, thus I will wait for a clear message from the TICTOC chairs to introduce any big changes at this last call stage.
> > >> 
> > >> 
> > >> OLD:
> > >> 
> > >>   As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
> > >>   supported in the carrier networks, industrial networks, automotive
> > >>   networks, and many other applications. It can provide high
> > >>   precision time synchronization as fine as nano-seconds. The
> > >>   protocol depends on a Precision Time Protocol (PTP) engine to
> > >>   decide its own state automatically, and a PTP transportation layer
> > >>   to carry the PTP timing and various quality messages. The
> > >>   configuration parameters and state data sets of IEEE 1588-2008 are
> > >>   numerous.
> > >> 
> > >>   According to the concepts described in [RFC3444], IEEE 1588-2008
> > >>   itself provides an information model in its normative
> > >>   specifications for the data sets (in IEEE 1588-2008 clause 8). Some
> > >>   standardization organizations including the IETF have specified
> > >>   data models in MIBs (Management Information Bases) for IEEE 1588-
> > >>   2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
> > >>   typically focused on retrieval of state data using the Simple
> > >>   Network Management Protocol (SNMP), furthermore, configuration of
> > >>   PTP data sets is not considered in [RFC8173].
> > >> 
> > >>   Some service providers and applications require that the management
> > >>   of the IEEE 1588-2008 synchronization network be flexible and more
> > >>   Internet-based (typically overlaid on their transport networks).
> > >>   Software Defined Network (SDN) is another driving factor, which
> > >>   demands an improved configuration capability of synchronization
> > >>   networks.
> > >> 
> > >>   YANG [RFC6020] is a data modeling language used to model
> > >>   configuration and state data manipulated by network management
> > >>   protocols like the Network Configuration Protocol (NETCONF)
> > >>   [RFC6241]. A small set of built-in data types are defined in
> > >>   [RFC6020], and a collection of common data types are further
> > >>   defined in [RFC6991]. Advantages of YANG include Internet based
> > >>   configuration capability, validation, rollback and so on. All of
> > >>   these characteristics make it attractive to become another
> > >>   candidate modeling language for IEEE 1588-2008.
> > >> 
> > >> NEW:
> > >> 
> > >>   IEEE 1588-2008 is a time protocol that provides high precision time
> > >>   synchronization as fine as nano-seconds.
> > >> 
> > >>   IEEE 1588-2008 itself provides an information model in its
> > > normative
> > >>   specifications for the data sets (IEEE 1588-2008 clause 8).
> > >>   Standard information models (e.g. [RFC8173], [IEEE8021AS]) have
> > > been
> > >>   previously defined as MIBs focused on the retrieval of state data
> > > using
> > >>   SNMP [RFC1157].
> > >> 
> > >>   YANG [RFC6020] is a data modeling language used to model
> > > configuration
> > >>   and state data manipulated by network management protocols like
> > > NETCONF
> > >>   [RFC6241].
> > >> 
> > >> 2. Can we refer to the system as simply PTP rather than IEEE
> > > 1588(-2008)?
> > >> [YJ] Advice from IEEE 1588 is, we need to use "1588-2008" as much 
> > >> as
> > > possible to help clarify that the scope of this YANG is limited to the published 1588 standard.
> > >> 
> > >> 
> > >> 3. There is insufficient spacing here to separate the terms from 
> > >> their
> > > definitions:
> > >> OLD
> > >> 
> > >>   PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
> > >>   for PTP protocol decisions and for providing values for PTP message
> > >>   fields, see Section 8 of [IEEE1588].
> > >> 
> > >>   PTP instance A PTP implementation in the device (i.e., an OC or BC)
> > >>   represented by a specific PTP dataset.
> > >> 
> > >> NEW
> > >> 
> > >>   PTP dataset
> > >>     Structured attributes of clocks (an OC, BC or TC) used
> > >>     for PTP protocol decisions and for providing values for PTP
> > > message
> > >>     fields, see Section 8 of [IEEE1588].
> > >> 
> > >>   PTP instance
> > >>     A PTP implementation in the device (i.e., an OC or BC)
> > >>     represented by a specific PTP dataset.
> > >> [YJ] OK.
> > >> 
> > >> 4. There's a singular/plural mismatch here:
> > >> 
> > >>   module. Query and configuration of device wide or port specific
> > >>   configuration information and clock data set is described for this
> > >>   version.
> > >> [YJ] Good, we will change 'is' to 'are'.
> > >> 
> > >> and here:
> > >> 
> > >>   Query and configuration of clock information include:
> > >> 
> > >> 
> > >> 5. The choice of uint16 as instance-number limits implementations 
> > >> to
> > > 65536 distinct instances.
> > >>   While I have a hard time imagining a system with more than 65536
> > > PTP instances, I would prefer to avoid imposing arbitrary limits.
> > >>   I would recommend changing instance-number to a string (and
> > > renaming it to instance-name or just name).
> > >> [YJ] The 1588-2008 supports multiple instances of PTP, but it is
> > > ambiguous in its organization of those PTP instances, especially with regard to management.
> > >> In the 1588 new revision, there is an explicit list of PTP 
> > >> instances,
> > > and that list is indexed using a number (not name). Thus to align with the new revision, we need to keep it instance-number.
> > >> If 65536 limit is a concern, how about change it to uint32, any
> > > concerns?
> > >> 
> > >> 
> > >> 6. I still recommend removing -ds from the YANG element names that
> > > still include it. It doesn't appear to add any value.
> > >> [YJ] Rodney's opinion: the value of using 'ds' is that the 1588
> > > document on which this YANG model is based uses "DefaultDS" as a term.
> > > PTP experts even say "default dee ess" verbally when referring to this data. If we changed this to just "default", PTP experts might assume that we are referring to something entirely new to YANG. Thus, to align with 1588-2008, the same set of terminologies are used.
> > >> 
> > >> 7. What;s the relevance of injection attacks relevant to this YANG
> > > module?
> > >> [YJ] This is a general statement which is applicable to this YANG
> > > module and other YANG modules as well.
> > >> Thanks again,
> > >> Yuanlong
> > >> 
> > >> Alex
> > >> 
> > >> 
> > >> ________________________________________
> > >> From: netmod  on behalf of Jiangyuanlong
> > > 
> > >> Sent: Friday, 27 October 2017 3:21 p.m.
> > >> To: tictoc@ietf.org
> > >> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> > >> Subject: [netmod] WG Last Call resolutions incorporated in
> > > draft-ietf-tictoc-1588v2-yang-06
> > >> 
> > >> Dear all,
> > >> 
> > >> Based on all the comments we received during the WG Last Call 
> > >> process,
> > > we've updated the document to version 6.
> > >> We believe all the LC comments are resolved and the consensus is
> > > reflected in this new revision.
> > >> Many thanks to Martin, Tal, Opher, Alex, John and many others who 
> > >> had
> > > reviewed and commented on this draft.
> > >> 
> > >> Cheers,
> > >> Yuanlong on behalf of all coauthors
> > >> 
> > >> -----Original Message-----
> > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > >> Sent: Friday, October 27, 2017 9:48 AM
> > >> To: Xian Liu; Rodney Cummings; rodney.cummings@ni.com; 
> > >> Jiangyuanlong;
> > > Xujinchun
> > >> Subject: New Version Notification for
> > > draft-ietf-tictoc-1588v2-yang-06.txt
> > >> 
> > >> 
> > >> A new version of I-D, draft-ietf-tictoc-1588v2-yang-06.txt
> > >> has been successfully submitted by Yuanlong Jiang and posted to the
> > > IETF repository.
> > >> 
> > >> Name:           draft-ietf-tictoc-1588v2-yang
> > >> Revision:       06
> > >> Title:          YANG Data Model for IEEE 1588-2008
> > >> Document date:  2017-10-26
> > >> Group:          tictoc
> > >> Pages:          30
> > >> URL:
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_in
> > > ternet-2Ddrafts_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06.tx&d=DwIF
> > > gQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhF
> > > t24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMI
> > > qStw&s=N0N5kBPcGMivXWwspHEOc-bP0mbYpkKu2IvM2Asyf_8&e=
> > > t
> > >> Status:
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet
> > > f.org_doc_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang_&d=DwIFgQ&c=I_0YwoKy
> > > 7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuup
> > > swWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=aYlovx
> > > _kTQtAiJAUMTJn8NCRZQIi_jEVNa-tC_5HFlk&e=
> > >> Htmlized:
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_
> > > html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c=I_0YwoKy7
> > > z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuups
> > > wWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=j1aDjiU
> > > 7AeuEV-p20PNwNpvZPrGSbBiHLHta7q05pak&e=
> > >> Htmlized:
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet
> > > f.org_doc_html_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c
> > > =I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24D
> > > Pjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw
> > > &s=7tYOv1M_EYHCPG1MiOq3BVl7vpB0w-LSiDYcQHM4ayM&e=
> > >> Diff:
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rf
> > > cdiff-3Furl2-3Ddraft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D06&d=DwIFgQ&c
> > > =I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24D
> > > Pjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E_rtyk18e89Fir82kLxurUC4yXciXZMIqStw
> > > &s=Z12Xm_2k7cEAlV7lFQb_zw7A-D-HL77C-Kuy2BgyCHA&e=
> > >> 
> > >> Abstract:
> > >>   This document defines a YANG data model for the configuration of
> > >>   IEEE 1588-2008 devices and clocks, and also retrieval of the
> > >>   configuration information, data set and running states of IEEE
> > >>   1588-2008 clocks.
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 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
> > >> 
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
> > >> ailman_listinfo_netmod&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZu
> > >> IPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E
> > >> _rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=cUl0d0wDX9fIwjIEHlhcrfg17x7ph
> > >> pI9QiF5PuXsYd4&e=
> > >> 
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
> > >> ailman_listinfo_netmod&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZu
> > >> IPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=oQTuhx0E
> > >> _rtyk18e89Fir82kLxurUC4yXciXZMIqStw&s=cUl0d0wDX9fIwjIEHlhcrfg17x7ph
> > >> pI9QiF5PuXsYd4&e=
> > > 
> > > _______________________________________________
> > > TICTOC mailing list
> > > TICTOC@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tictoc
> > 
> > _______________________________________________
> > 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         
> 
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc

-- 
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 Nov 24 18:05: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 9342B129469; Fri, 24 Nov 2017 18:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.648
X-Spam-Level: 
X-Spam-Status: No, score=-3.648 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, URG_BIZ=0.573] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y-21i0DUBIK; Fri, 24 Nov 2017 18:05:39 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B3B126C22; Fri, 24 Nov 2017 18:05:38 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 484B9202F389A; Sat, 25 Nov 2017 02:05:35 +0000 (GMT)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 25 Nov 2017 02:05:35 +0000
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.47]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0361.001; Sat, 25 Nov 2017 10:05:27 +0800
From: Jiangyuanlong 
To: Juergen Schoenwaelder 
CC: Bob kb8tq , Xian Liu , Xujinchun , Karen O'Donoghue , "netmod@ietf.org" , "tictoc@ietf.org" 
Thread-Topic: [TICTOC] [netmod] Using instance-number or instance-name issue - RE: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Thread-Index: AQHTY6GZvGtCTd+lTU6e3ETiT9N5kaMhNnRQ///RBICAA0ojgA==
Date: Sat, 25 Nov 2017 02:05:27 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB653808@dggeml507-mbx.china.huawei.com>
References: <000f01d35987$2a945ea0$4001a8c0@gateway.2wire.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB648A77@dggeml507-mbx.china.huawei.com>  <01992158370DC941ABFFAB7233E2346046348DAB@dggeml506-mbx.china.huawei.com> <354261BF-322C-46AE-8B0D-573065A7C62B@n1k.org> <20171122145112.koipskvauriwpepq@elstar.local> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB652B15@dggeml507-mbx.china.huawei.com> <20171123071229.i4opjdi2xi2yft25@elstar.local>
In-Reply-To: <20171123071229.i4opjdi2xi2yft25@elstar.local>
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
Archived-At: 
Subject: Re: [netmod] [TICTOC] Using instance-number or instance-name issue - RE: 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: Sat, 25 Nov 2017 02:05:41 -0000

R29vZCBwcmFjdGljZS4gSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBjb25zaWRlciBZQU5HIGlu
dGVybmF0aW9uYWxpemF0aW9uIGFzIGEgd2hvbGUsIHBlcmhhcHMgaW4gYSBvcGVuIHNvdXJjZSBw
cm9qZWN0ICwgb3IgZGVmaW5lIGEgWUFORyBtb2R1bGUgdG8gc3VwcG9ydCBpbnRlcm5hdGlvbmFs
aXphdGlvbiwgdGhlbiBhbnkgWUFORyBtb2R1bGUgY2FuIGltcG9ydCB0aGlzIGludGVybmF0aW9u
YWxpemF0aW9uLXN1cHBvcnQgbW9kdWxlIGlmIG5lZWRlZC4NCg0KQmFjayB0byB0aGUgaXNzdWUg
b2YgaW5zdGFuY2UtbnVtYmVyIG9yIGluc3RhbmNlLW5hbWUsIEkgYmVsaWV2ZSB0aGUgb3JpZ2lu
YWwgY29tbWVudGVyJ3MgbWFpbiBjb25jZXJuICh0aGF0IGlzLCB1aW50MTYgbWF5IGJlIHRvbyBs
aW1pdGVkKSBoYXMgYmVlbiByZXNvbHZlZCBieSB1c2luZyBhbiBpbnN0YW5jZS1udW1iZXIgb2Yg
dHlwZSB1aW50MzIsIHNvIHdlIHdpbGwgZ28gd2l0aCBpbnN0YW5jZS1udW1iZXIuDQoNCkNoZWVy
cywNCll1YW5sb25nDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEp1ZXJn
ZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0
eS5kZV0gDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjMsIDIwMTcgMzoxMiBQTQ0KVG86IEpp
YW5neXVhbmxvbmcNCkNjOiBCb2Iga2I4dHE7IFhpYW4gTGl1OyBYdWppbmNodW47IEthcmVuIE8n
RG9ub2dodWU7IG5ldG1vZEBpZXRmLm9yZzsgdGljdG9jQGlldGYub3JnDQpTdWJqZWN0OiBSZTog
W1RJQ1RPQ10gW25ldG1vZF0gVXNpbmcgaW5zdGFuY2UtbnVtYmVyIG9yIGluc3RhbmNlLW5hbWUg
aXNzdWUgLSBSRTogV0cgTGFzdCBDYWxsIHJlc29sdXRpb25zIGluY29ycG9yYXRlZCBpbiBkcmFm
dC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNg0KDQpJIGhhdmUgbm8gb3BpbmlvbiBpbiB0aGlz
IHNwZWNpZmljIGNvbnRleHQuIFRoYXQgc2FpZCwgSSBnZW5lcmFsbHkgcHJlZmVyIG5hbWVzIG92
ZXIgbnVtYmVycyBpbiBjb25maWd1cmF0aW9uIGl0ZW1zLg0KDQpJIGFncmVlIHRoYXQgdXNpbmcg
YSBwbGFpbiBZQU5HIHN0cmluZyBjYW4gbGVhZCB0byBzdXJwcmlzZXMgYW5kIHBvdGVudGlhbCBz
ZWN1cml0eSBpc3N1ZXMgaWYgcGVvcGxlIGRvIG5vdCBleHBlY3QgdGhhdCB0aGUgaWRlbnRpZmll
ciBjYW4gY29udGFpbiBhbG1vc3QgYXJiaXRyYXJ5IGNoYXJhY3RlcnMuIEluIExNQVAsIEkgc3Rh
cnRlZCB0byB1c2UgYW4gaWRlbnRlbnRpZmllciB0eXBlIGJ1dCB0aGVuIGF0IHRoZSBlbmQgdGhl
cmUgd2FzIG5vIGNsZWFyIG9waW5pb24gd2hhdCB0aGUgYXBwcm9wcmlhdGUgcmVzdHJpY3Rpb25z
IHdvdWxkIGJlIGFuZCBoZW5jZSB3ZSBlbmRlZCB1cCB3aXRoIGEgaGludCB0byBpbXBsZW1lbnRv
cnMgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOg0KDQogICBUaGUgZGF0YSBtb2RlbCB1
c2VzIGEgbnVtYmVyIG9mIGlkZW50aWZpZXJzIHRoYXQgYXJlIHNldCBieSB0aGUNCiAgIENvbnRy
b2xsZXIuICBJbXBsZW1lbnRvcnMgbWF5IGZpbmQgdGhlc2UgaWRlbnRpZmllcnMgdXNlZnVsIGZv
ciB0aGUNCiAgIGlkZW50aWZpY2F0aW9uIG9mIHJlc291cmNlcywgZS5nLiwgdG8gaWRlbnRpZnkg
b2JqZWN0cyBpbiBhIGZpbGUNCiAgIHN5c3RlbSBwcm92aWRpbmcgdGVtcG9yYXJ5IHN0b3JhZ2Uu
ICBTaW5jZSB0aGUgaWRlbnRpZmllcnMgdXNlZCBieQ0KICAgdGhlIFlBTkcgZGF0YSBtb2RlbCBt
YXkgYWxsb3cgY2hhcmFjdGVycyB0aGF0IG1heSBiZSBnaXZlbiBzcGVjaWFsDQogICBpbnRlcnBy
ZXRhdGlvbiBpbiBhIHNwZWNpZmljIGNvbnRleHQsIGltcGxlbWVudGF0aW9ucyBtdXN0IGVuc3Vy
ZQ0KICAgdGhhdCBpZGVudGlmaWVycyBhcmUgcHJvcGVybHkgbWFwcGVkIGludG8gc2FmZSBpZGVu
dGlmaWVycy4NCg0KSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBhIGRhdGEgdHlw
ZSAoaS5lLiwNCmNvbmZpZy1pZGVudGlmaWVyKSB0aGF0IGlzIGNvbW1vbmx5IHVzZWQgdG8gbmFt
ZSBjb25maWd1cmF0aW9uIGl0ZW1zLiBCdXQgaXQgaXMgdW5jbGVhciB0byBtZSBob3cgdG8gZGVm
aW5lIHN1Y2ggYSB0eXBlLiBUaGUgeWFuZy1pZGVudGlmaWVyIGRlZmluZWQgaW4gUkZDIDY5OTEg
aXMgbGlrZWx5IHRvbyByZXN0cmljdGl2ZSBpZiB5b3UgbG9vayBhdCBpdCBmcm9tIGFuIGludGVy
bmF0aW9uYWxpemF0aW9uIHBvaW50IG9mIHZpZXcuDQoNCi9qcw0KDQpPbiBUaHUsIE5vdiAyMywg
MjAxNyBhdCAwMjoxNzozM0FNICswMDAwLCBKaWFuZ3l1YW5sb25nIHdyb3RlOg0KPiBKdWVyZ2Vu
ICYgQm9iLA0KPiANCj4gQ2FuIEkgYXNzdW1lIHlvdSBhcmUgaW4gc3VwcG9ydCBvZiB1c2luZyBp
bnN0YW5jZS1udW1iZXIgaW4gdGhpcyBjYXNlPyANCj4gXiZeIEJ1dCBzZXJpb3VzbHksIG1heWJl
IGl0IG1ha2VzIHNlbnNlIHRvIHJlc3RyaWN0IHRoZSB2YWxpZCBjaGFyYWN0ZXJzIG9mIGEgc3Ry
aW5nLCBlc3BlY2lhbGx5IHdoZW4gaXQgaXMgdXNlZCBhcyBhIGtleS4NCj4gT3RoZXJ3aXNlLCB3
ZSBuZWVkIHRvIG5vdGUgdGhpcyByaXNrIGluICJTZWN1cml0eSBjb25zaWRlcmF0aW9ucyIgb2Yg
YSBSRkMgKGFjdHVhbGx5IGl0IGNhbiBiZWNvbWUgYSBraW5kIG9mIERvUyBhdHRhY2spLiANCj4g
DQo+IFRoYW5rcywNCj4gWXVhbmxvbmcNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+IEZyb206IFRJQ1RPQyBbbWFpbHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgSnVlcmdlbiANCj4gU2Nob2Vud2FlbGRlcg0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVt
YmVyIDIyLCAyMDE3IDEwOjUxIFBNDQo+IFRvOiBCb2Iga2I4dHENCj4gQ2M6IFhpYW4gTGl1OyBY
dWppbmNodW47IEthcmVuIE8nRG9ub2dodWU7IG5ldG1vZEBpZXRmLm9yZzsgDQo+IHRpY3RvY0Bp
ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1RJQ1RPQ10gW25ldG1vZF0gVXNpbmcgaW5zdGFuY2Ut
bnVtYmVyIG9yIGluc3RhbmNlLW5hbWUgDQo+IGlzc3VlIC0gUkU6IFdHIExhc3QgQ2FsbCByZXNv
bHV0aW9ucyBpbmNvcnBvcmF0ZWQgaW4gDQo+IGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5n
LTA2DQo+IA0KPiBBY2NvcmRpbmcgdG8gUkZDIDc5NTAsIHNlY3Rpb24gOS40LCBZQU5HIHN0cmlu
Z3MgYXJlIFVuaWNvZGUgYW5kIElTTy9JRUMgMTA2NDYgY2hhcmFjdGVycywgaW5jbHVkaW5nIHRh
YiwgY2FycmlhZ2UgcmV0dXJuLCBhbmQgbGluZSBmZWVkIGJ1dCBleGNsdWRpbmcgdGhlIG90aGVy
IEMwIGNvbnRyb2wgY2hhcmFjdGVycywgdGhlIHN1cnJvZ2F0ZSBibG9ja3MsIGFuZCB0aGUgbm9u
Y2hhcmFjdGVycy4gT2YgY291cnNlLCBoYW5kbGluZyBVbmljb2RlIGNvcnJlY3RseSBjYW4gc3Rp
bGwgYmUgYSBsb3Qgb2YgZnVuIGFuZCBzeXN0ZW1zIHRoYXQgZG8gbm90IGdldCB0aGlzIHJpZ2h0
IG1pZ2h0IHN0aWxsIGNyYXNoIG9yIGxvY2t1cC4NCj4gDQo+IC9qcw0KPiANCj4gT24gV2VkLCBO
b3YgMjIsIDIwMTcgYXQgMDg6MTY6MjJBTSAtMDUwMCwgQm9iIGtiOHRxIHdyb3RlOg0KPiA+IEhp
DQo+ID4gDQo+ID4gSWYgeW91IGNoYW5nZSB0byDigJxpbnN0YW5jZSBuYW1l4oCdIGJlIHZlcnkg
Y2xlYXIgb24gdGhlIGNoYXJhY3RlciANCj4gPiBzZXQocykgYWxsb3dlZC4gSSBoYXZlIHNlZW4g
c29tZSByZWFsbHkgYmFkIHNpZGUgZWZmZWN0cyB3aGVuIA0KPiA+IHVuZXhwZWN0ZWQgY2hhcmFj
dGVyIHNldHMgc2hvdyB1cCBpbiBJRCBmaWVsZHMuIFNvZnR3YXJlIHRyaWVzIHRvIHBhcnNlIGl0
IGZvciBwcmVzZW50YXRpb24gb24gYSBzY3JlZW4gb3IgaW50byBhIGxvZy4gVGhlIHJlc3VsdCBp
cyBhIGNyYXNoIG9yIGxvY2t1cC4NCj4gPiANCj4gPiBCb2INCj4gPiANCj4gPiA+IE9uIE5vdiAy
MSwgMjAxNywgYXQgMTA6MTggUE0sIFh1amluY2h1biA8eHVqaW5jaHVuQGh1YXdlaS5jb20+IHdy
b3RlOg0KPiA+ID4gDQo+ID4gPiBIaSBSb2RuZXksDQo+ID4gPiANCj4gPiA+IEluIG15IG9waW5p
b24sIGluc3RhbmNlLW5hbWUgb3IgaW5zdGFuY2UtbnVtYmVyIGRvZXMgbm90IG1hdHRlciBpZiB0
aGUgbnVtYmVyIG9mIGluc3RhbmNlcyBhcmUgc21hbGwuIEJ1dCBpZiB0aGUgaW5zdGFuY2VzIG1h
eSBncm93IGludG8gaHVuZHJlZHMgb3IgbW9yZSBpbiBzY2FsZSwgdGhlbiBzdHJpbmcgc2hvdWxk
IG5vdCBiZSBhIGNob2ljZS4NCj4gPiA+IA0KPiA+ID4gV2Uga25vdyBob3cgYXdrd2FyZCBpdCBp
cyB0byBzdG9yZSBhbmQgc29ydCBvdXQgYSBrZXkgb2Ygc3RyaW5nIGNvbXBhcmVkIHdpdGggYW4g
aW50ZWdlci4NCj4gPiA+IA0KPiA+ID4gVGhhbmtzDQo+ID4gPiANCj4gPiA+IEppbmNodW4gWFUN
Cj4gPiA+IA0KPiA+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+ID4g5Y+R5Lu25Lq6OiBS
b2RuZXkgQ3VtbWluZ3MgW21haWx0bzpyb2RuZXkuY3VtbWluZ3NAbmkuY29tXQ0KPiA+ID4g5Y+R
6YCB5pe26Ze0OiAyMDE35bm0MTHmnIgyMuaXpSAxOjU2DQo+ID4gPiDmlLbku7bkuro6IEppYW5n
eXVhbmxvbmc7IHRpY3RvY0BpZXRmLm9yZzsgQWxleCBDYW1wYmVsbDsgS2FyZW4gDQo+ID4gPiBP
J0Rvbm9naHVlDQo+ID4gPiDmioTpgIE6IFhpYW4gTGl1OyBYdWppbmNodW47IG5ldG1vZEBpZXRm
Lm9yZw0KPiA+ID4g5Li76aKYOiBSRTogVXNpbmcgaW5zdGFuY2UtbnVtYmVyIG9yIGluc3RhbmNl
LW5hbWUgaXNzdWUgLSBSRTogV0cgTGFzdCANCj4gPiA+IENhbGwgcmVzb2x1dGlvbnMgaW5jb3Jw
b3JhdGVkIGluIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA2DQo+ID4gPiANCj4gPiA+
IEhpIFl1YW5sb25nLA0KPiA+ID4gDQo+ID4gPiBJIGhhdmUgbm8gY29uY2VybnMgd2l0aCBpbnN0
YW5jZS1udW1iZXIsIGFzIHRoYXQgaXMgd2hhdCB0aGUgdXBjb21pbmcgMTU4OCByZXZpc2lvbiBv
dXRsaW5lcyBmb3IgbWFuYWdlbWVudC4NCj4gPiA+IA0KPiA+ID4gSSBhbHNvIGhhdmUgbm8gc3Ry
b25nIG9iamVjdGlvbnMgYWdhaW5zdCBjaGFuZ2luZyBpbnN0YW5jZS1udW1iZXIgdG8gaW5zdGFu
Y2UtbmFtZS4gSWYgd2UgZG8gdGhhdCwgSSB0aGluayBpdCB3b3VsZCBiZSBiZXN0IHRvIG1ha2Ug
dGhlIHNhbWUgY2hhbmdlIGluIHRoZSB1cGNvbWluZyAxNTg4IHJldmlzaW9uLiBJIGFza2VkIHRo
ZSAxNTg4IHdvcmtpbmcgZ3JvdXAgZm9yIG9waW5pb24sIGJ1dCBJIGhhdmVuJ3QgaGVhcmQgYmFj
ayBvbiB0aGF0Lg0KPiA+ID4gDQo+ID4gPiBBbGwgdGhpbmdzIGJlaW5nIGVxdWFsLCBteSBwcmVm
ZXJlbmNlIGlzIHRvIGdvIHdpdGggaW5zdGFuY2UtbnVtYmVyLg0KPiA+ID4gDQo+ID4gPiBSb2Ru
ZXkNCj4gPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206
IEppYW5neXVhbmxvbmcgW21haWx0bzpqaWFuZ3l1YW5sb25nQGh1YXdlaS5jb21dDQo+ID4gPiBT
ZW50OiBNb25kYXksIE5vdmVtYmVyIDIwLCAyMDE3IDc6MzQgQU0NCj4gPiA+IFRvOiB0aWN0b2NA
aWV0Zi5vcmc7IEFsZXggQ2FtcGJlbGwgOyBSb2RuZXkgQ3VtbWluZ3MgOyBLYXJlbiANCj4gPiA+
IE8nRG9ub2dodWUNCj4gPiA+IENjOiBYaWFuIExpdSA7IFh1amluY2h1biA7IG5ldG1vZEBpZXRm
Lm9yZw0KPiA+ID4gU3ViamVjdDogVXNpbmcgaW5zdGFuY2UtbnVtYmVyIG9yIGluc3RhbmNlLW5h
bWUgaXNzdWUgLSBSRTogV0cgDQo+ID4gPiBMYXN0IENhbGwgcmVzb2x1dGlvbnMgaW5jb3Jwb3Jh
dGVkIGluIA0KPiA+ID4gZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDYNCj4gPiA+IA0K
PiA+ID4gSGkgYWxsLA0KPiA+ID4gDQo+ID4gPiBJdGVtICM1IGJlbG93IGlzIHRoZSBsYXN0IG9w
ZW4gaXNzdWUgd2UgZGlzY3Vzc2VkIGJvdGggaW4gZW1haWxzIGFuZCBpbiBJRUVFIDE1ODggbWFp
bGluZyBsaXN0IG9uIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLiAgDQo+ID4gPiBJbiBh
IHN1bW1hcnk6IGluIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLCBsaXN0IGluc3RhbmNl
LWxpc3QgaGFzIGEga2V5IG9mICJpbnN0YW5jZS1udW1iZXIiLCBidXQgdGhlcmUgd2VyZSBkaXNj
dXNzaW9ucyB3aGV0aGVyIHRvIHVzZSBpbnN0YW5jZS1uYW1lIChhIHN0cmluZykgaW5zdGVhZC4N
Cj4gPiA+IA0KPiA+ID4gQ3VycmVudGx5LCAiaW5zdGFuY2UtbnVtYmVyIiBpbiBkcmFmdC1pZXRm
LXRpY3RvYy0xNTg4djIteWFuZy0wNiBhbGlnbnMgd2VsbCB3aXRoIHRoZSB0ZXh0cyBpbiB0aGUg
bmV3IHJldmlzaW9uIG9mIElFRUUgMTU4OCAoRDEuMi8yMDE3KTogDQo+ID4gPiAgICJUaGUgaW5z
dGFuY2VMaXN0IGlzIGluZGV4ZWQgdXNpbmcgYSBudW1iZXIgdGhhdCBpcyB1bmlxdWUgcGVyIFBU
UCBJbnN0YW5jZSB3aXRoaW4gdGhlIFBUUCBOb2RlLCBhcHBsaWNhYmxlIHRvIHRoZSANCj4gPiA+
ICAgbWFuYWdlbWVudCBjb250ZXh0IG9ubHkgKGkuZS4gbm90IHVzZWQgaW4gUFRQIG1lc3NhZ2Vz
KS4gVGhlIGRvbWFpbk51bWJlciBvZiB0aGUgUFRQIEluc3RhbmNlIG11c3Qgbm90IGJlIHVzZWQg
YXMgdGhlIGluZGV4IA0KPiA+ID4gICB0byBpbnN0YW5jZUxpc3QsIHNpbmNlIGl0IGlzIHBvc3Np
YmxlIGZvciBhIFBUUCBOb2RlIHRvIGNvbnRhaW4gbXVsdGlwbGUgUFRQIEluc3RhbmNlcyB1c2lu
ZyB0aGUgc2FtZSBkb21haW5OdW1iZXIuIg0KPiA+ID4gDQo+ID4gPiBUaGUgbWFpbiByZXF1aXJl
bWVudCBvZiBpbnN0YW5jZUxpc3QgaW4gSUVFRSAxNTg4IGlzIHRoZSB1bmlxdWVuZXNzIG9mIGl0
cyBpbmRleCwgYW5kIHRoZSAia2V5IiBzdGF0ZW1lbnQgb2YgWUFORyBzZXJ2ZXMgdGhpcyBwdXJw
b3NlIHZlcnkgd2VsbC4NCj4gPiA+IA0KPiA+ID4gVGhhdCBpcywgd2hlbiBpbnN0YW5jZS1udW1i
ZXIgaXMgdXNlZCBhcyBhIGtleSwgYSBQVFAgTm9kZSB3aXRoIG11bHRpcGxlIFBUUCBJbnN0YW5j
ZXMgY2Fubm90IHVzZSB0aGUgc2FtZSBpbnN0YW5jZS1udW1iZXIgdmFsdWUgZm9yIHRoZXNlIFBU
UCBJbnN0YW5jZXMgKGp1c3QgYWNjb3JkaW5nIHRvIFlBTkcgc2VtYW50aWNzKS4NCj4gPiA+IA0K
PiA+ID4gVXNpbmcgaW5zdGFuY2UtbmFtZSAoc3RyaW5nKSBjYW4gYWxzbyBndWFyYW50ZWUgdGhl
IHVuaXF1ZW5lc3Mgb2YgdGhlIGluZGV4IG9mIGEgbGlzdCwgYnV0IGNvbXBhcmVkIHdpdGggYW4g
aW50ZWdlciwgYSBzdHJpbmcgaXMgdXN1YWxseSBtb3JlIGNvbXBsZXggdG8gcHJvY2VzcyBhbmQg
c3RvcmUuIElmIGluc3RhbmNlLW5hbWUgaXMgbW9kZWxlZCBhcyBhbiBhcmJpdHJhcnkgbGVuZ3Ro
IG9mIHN0cmluZywgdGhlcmUgaXMgZXZlbiBhIHJpc2sgb2YgYnVmZmVyLW92ZXJmbG93IGF0dGFj
ay4NCj4gPiA+IA0KPiA+ID4gRnVydGhlcm1vcmUsIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGRy
YWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nIGlzIHRhcmdldGVkIGF0IElFRUUgMTU4OC0yMDA4
LCBmb3Igd2hpY2ggbW9zdCBwcm9kdWN0cyB0b2RheSBvbmx5IGhhdmUgYSBzaW5nbGUgUFRQIGlu
c3RhbmNlLCBhbmQgbm90IGhhdmUgYSBuYW1lIGZvciB0aGlzIGluc3RhbmNlLCBpdCBzZWVtcyBx
dWl0ZSB3ZWlyZCB0byBpbnRyb2R1Y2UgYSBuYW1lIGZvciB0aGlzIGluc3RhbmNlLg0KPiA+ID4g
DQo+ID4gPiBUaGVyZWZvcmUsIEkgd291bGQgc3VnZ2VzdCB3ZSBrZWVwIG9uIHVzaW5nIGluc3Rh
bmNlLW51bWJlciBhcyBhIGtleS4gQnV0IGFzIDY1NTM2IGxpbWl0IGlzIGEgY29uY2VybiwgSSBm
dXJ0aGVyIHN1Z2dlc3QgdG8gY2hhbmdlIGl0cyB0eXBlIHRvIHVpbnQzMi4NCj4gPiA+IA0KPiA+
ID4gQW55IGNvbW1lbnRzIG9yIGNvbmNlcm5zIG9uIHRoaXMgc3VnZ2VzdGlvbiB0byBtb3ZlIGZv
cndhcmQ/DQo+ID4gPiANCj4gPiA+IFRoYW5rcywNCj4gPiA+IFl1YW5sb25nDQo+ID4gPiANCj4g
PiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+IEZyb206ICJKaWFuZ3l1YW5s
b25nIiA8amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tPg0KPiA+ID4gVG86ICJBbGV4IENhbXBiZWxs
IiA8QWxleC5DYW1wYmVsbEBBdmlhdG5ldC5jb20+OyANCj4gPiA+IDx0aWN0b2NAaWV0Zi5vcmc+
DQo+ID4gPiBDYzogIlhpYW4gTGl1IiA8bGVuZS5saXV4aWFuQGZveG1haWwuY29tPjsgIlh1amlu
Y2h1biINCj4gPiA+IDx4dWppbmNodW5AaHVhd2VpLmNvbT47IDxuZXRtb2RAaWV0Zi5vcmc+DQo+
ID4gPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAwNywgMjAxNyA3OjUzIEFNDQo+ID4gPiBTdWJq
ZWN0OiBSZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsIHJlc29sdXRpb25zIGluY29ycG9yYXRlZCBp
bg0KPiA+ID4gZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDYNCj4gPiA+IA0KPiA+ID4g
DQo+ID4gPj4gSGkgQWxleCwNCj4gPiA+PiANCj4gPiA+PiBTb3JyeSBmb3IgYSBsYXRlIHJlcGx5
IGFzIEkgc3BlbnQgdGhlIGxhc3Qgd2VlayBmb3IgYW4gdXJnZW50IA0KPiA+ID4+IGJ1c2luZXNz
DQo+ID4gPiB0cmlwLg0KPiA+ID4+IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW4gbGluZSB3aXRo
IFtZSl0NCj4gPiA+PiANCj4gPiA+PiBUaGFua3MsDQo+ID4gPj4gWXVhbmxvbmcNCj4gPiA+PiAN
Cj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IEFsZXggQ2Ft
cGJlbGwgW21haWx0bzpBbGV4LkNhbXBiZWxsQEF2aWF0bmV0LmNvbV0NCj4gPiA+PiBTZW50OiBN
b25kYXksIE9jdG9iZXIgMzAsIDIwMTcgMTA6MTUgQU0NCj4gPiA+PiBUbzogSmlhbmd5dWFubG9u
ZzsgdGljdG9jQGlldGYub3JnDQo+ID4gPj4gQ2M6IFhpYW4gTGl1OyBYdWppbmNodW47IG5ldG1v
ZEBpZXRmLm9yZw0KPiA+ID4+IFN1YmplY3Q6IFJlOiBXRyBMYXN0IENhbGwgcmVzb2x1dGlvbnMg
aW5jb3Jwb3JhdGVkIGluDQo+ID4gPiBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNg0K
PiA+ID4+IA0KPiA+ID4+IEhpLA0KPiA+ID4+IEkndmUgcmV2aWV3ZWQgdGhpcyBsYXRlc3QgZHJh
ZnQgYW5kIGhhdmUgc29tZSBtb3JlIGNvbW1lbnRzLg0KPiA+ID4+IA0KPiA+ID4+IDEuIEkgZmlu
ZCB0aGUgaW50cm9kdWN0aW9uIHRvIGJlIHVubmVjZXNzYXJpbHkgd29yZHk7IGl0IGZlZWxzIA0K
PiA+ID4+IGxpa2UgaXQNCj4gPiA+IHdhcyB3cml0dGVuIHdpdGggYSB2aWV3IG9mIG5vdCBtaXNz
aW5nIGFueSBpbmZvcm1hdGlvbiBvdXQsIHJhdGhlciB0aGFuIHRyeWluZyB0byBrZWVwIGl0IGNv
bmNpc2UuDQo+ID4gPj4gICBGb3IgZXhhbXBsZSwgdGhlcmUgaXMgbm8gbmVlZCB0byBlbGFib3Jh
dGUgb24gWUFORyBkYXRhIHR5cGVzIGhlcmUuDQo+ID4gPiBJdCBpcyBhbHNvIG5vdCBoZXJlIHRv
IHNlbGwgWUFORy4NCj4gPiA+PiANCj4gPiA+PiBbWUpdIFllcywgd2UgYXJlIHRyeWluZyB0byBn
aXZlIHNvbWUgaW50cm9kdWN0b3J5IGluZm9ybWF0aW9uIGZvciANCj4gPiA+PiBhbg0KPiA+ID4g
b3V0c2lkZXIgd2hvIG1heSBub3QgYmUgZmFtaWxpYXIgd2l0aCBQVFAgb3IgWUFORywgYW5kIGV4
cGxhaW4gd2h5IGEgWUFORyBmb3IgUFRQIGlzIG5lZWRlZC4gVGhlIGp1aWN5IHBhcnQgb2YgdGhp
cyBkb2N1bWVudCBpcyBpdHMgWUFORyBtb2R1bGUsIGFuZCBwZW9wbGUgY2FuIHNraXAgYWxsIHRo
ZSBvdGhlciB0ZXh0cyBpZiB0aGV5IGFyZSBmYW1pbGlhciB3aXRoIFBUUCBhbmQgWUFORy4NCj4g
PiA+PiBCZXNpZGVzLCB0aGVzZSB0ZXh0cyBoYXZlIGJlZW4gY29udHJpYnV0ZWQgYnkgbXVsdGlw
bGUgc291cmNlcyANCj4gPiA+PiBhbmQNCj4gPiA+IHVuZGVyZ29uZSBzZXZlcmFsIHJvdW5kcyBv
ZiByZXZpZXdzLCB0aHVzIEkgd2lsbCB3YWl0IGZvciBhIGNsZWFyIG1lc3NhZ2UgZnJvbSB0aGUg
VElDVE9DIGNoYWlycyB0byBpbnRyb2R1Y2UgYW55IGJpZyBjaGFuZ2VzIGF0IHRoaXMgbGFzdCBj
YWxsIHN0YWdlLg0KPiA+ID4+IA0KPiA+ID4+IA0KPiA+ID4+IE9MRDoNCj4gPiA+PiANCj4gPiA+
PiAgIEFzIGEgc3luY2hyb25pemF0aW9uIHByb3RvY29sLCBJRUVFIDE1ODgtMjAwOCBbSUVFRTE1
ODhdIGlzIHdpZGVseQ0KPiA+ID4+ICAgc3VwcG9ydGVkIGluIHRoZSBjYXJyaWVyIG5ldHdvcmtz
LCBpbmR1c3RyaWFsIG5ldHdvcmtzLCBhdXRvbW90aXZlDQo+ID4gPj4gICBuZXR3b3JrcywgYW5k
IG1hbnkgb3RoZXIgYXBwbGljYXRpb25zLiBJdCBjYW4gcHJvdmlkZSBoaWdoDQo+ID4gPj4gICBw
cmVjaXNpb24gdGltZSBzeW5jaHJvbml6YXRpb24gYXMgZmluZSBhcyBuYW5vLXNlY29uZHMuIFRo
ZQ0KPiA+ID4+ICAgcHJvdG9jb2wgZGVwZW5kcyBvbiBhIFByZWNpc2lvbiBUaW1lIFByb3RvY29s
IChQVFApIGVuZ2luZSB0bw0KPiA+ID4+ICAgZGVjaWRlIGl0cyBvd24gc3RhdGUgYXV0b21hdGlj
YWxseSwgYW5kIGEgUFRQIHRyYW5zcG9ydGF0aW9uIGxheWVyDQo+ID4gPj4gICB0byBjYXJyeSB0
aGUgUFRQIHRpbWluZyBhbmQgdmFyaW91cyBxdWFsaXR5IG1lc3NhZ2VzLiBUaGUNCj4gPiA+PiAg
IGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBhbmQgc3RhdGUgZGF0YSBzZXRzIG9mIElFRUUgMTU4
OC0yMDA4IGFyZQ0KPiA+ID4+ICAgbnVtZXJvdXMuDQo+ID4gPj4gDQo+ID4gPj4gICBBY2NvcmRp
bmcgdG8gdGhlIGNvbmNlcHRzIGRlc2NyaWJlZCBpbiBbUkZDMzQ0NF0sIElFRUUgMTU4OC0yMDA4
DQo+ID4gPj4gICBpdHNlbGYgcHJvdmlkZXMgYW4gaW5mb3JtYXRpb24gbW9kZWwgaW4gaXRzIG5v
cm1hdGl2ZQ0KPiA+ID4+ICAgc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBkYXRhIHNldHMgKGluIElF
RUUgMTU4OC0yMDA4IGNsYXVzZSA4KS4gU29tZQ0KPiA+ID4+ICAgc3RhbmRhcmRpemF0aW9uIG9y
Z2FuaXphdGlvbnMgaW5jbHVkaW5nIHRoZSBJRVRGIGhhdmUgc3BlY2lmaWVkDQo+ID4gPj4gICBk
YXRhIG1vZGVscyBpbiBNSUJzIChNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2VzKSBmb3IgSUVF
RSAxNTg4LQ0KPiA+ID4+ICAgMjAwOCBkYXRhIHNldHMgKGUuZy4gW1JGQzgxNzNdLCBbSUVFRTgw
MjFBU10pLiBUaGVzZSBNSUJzIGFyZQ0KPiA+ID4+ICAgdHlwaWNhbGx5IGZvY3VzZWQgb24gcmV0
cmlldmFsIG9mIHN0YXRlIGRhdGEgdXNpbmcgdGhlIFNpbXBsZQ0KPiA+ID4+ICAgTmV0d29yayBN
YW5hZ2VtZW50IFByb3RvY29sIChTTk1QKSwgZnVydGhlcm1vcmUsIGNvbmZpZ3VyYXRpb24gb2YN
Cj4gPiA+PiAgIFBUUCBkYXRhIHNldHMgaXMgbm90IGNvbnNpZGVyZWQgaW4gW1JGQzgxNzNdLg0K
PiA+ID4+IA0KPiA+ID4+ICAgU29tZSBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgYXBwbGljYXRpb25z
IHJlcXVpcmUgdGhhdCB0aGUgbWFuYWdlbWVudA0KPiA+ID4+ICAgb2YgdGhlIElFRUUgMTU4OC0y
MDA4IHN5bmNocm9uaXphdGlvbiBuZXR3b3JrIGJlIGZsZXhpYmxlIGFuZCBtb3JlDQo+ID4gPj4g
ICBJbnRlcm5ldC1iYXNlZCAodHlwaWNhbGx5IG92ZXJsYWlkIG9uIHRoZWlyIHRyYW5zcG9ydCBu
ZXR3b3JrcykuDQo+ID4gPj4gICBTb2Z0d2FyZSBEZWZpbmVkIE5ldHdvcmsgKFNETikgaXMgYW5v
dGhlciBkcml2aW5nIGZhY3Rvciwgd2hpY2gNCj4gPiA+PiAgIGRlbWFuZHMgYW4gaW1wcm92ZWQg
Y29uZmlndXJhdGlvbiBjYXBhYmlsaXR5IG9mIHN5bmNocm9uaXphdGlvbg0KPiA+ID4+ICAgbmV0
d29ya3MuDQo+ID4gPj4gDQo+ID4gPj4gICBZQU5HIFtSRkM2MDIwXSBpcyBhIGRhdGEgbW9kZWxp
bmcgbGFuZ3VhZ2UgdXNlZCB0byBtb2RlbA0KPiA+ID4+ICAgY29uZmlndXJhdGlvbiBhbmQgc3Rh
dGUgZGF0YSBtYW5pcHVsYXRlZCBieSBuZXR3b3JrIG1hbmFnZW1lbnQNCj4gPiA+PiAgIHByb3Rv
Y29scyBsaWtlIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpDQo+
ID4gPj4gICBbUkZDNjI0MV0uIEEgc21hbGwgc2V0IG9mIGJ1aWx0LWluIGRhdGEgdHlwZXMgYXJl
IGRlZmluZWQgaW4NCj4gPiA+PiAgIFtSRkM2MDIwXSwgYW5kIGEgY29sbGVjdGlvbiBvZiBjb21t
b24gZGF0YSB0eXBlcyBhcmUgZnVydGhlcg0KPiA+ID4+ICAgZGVmaW5lZCBpbiBbUkZDNjk5MV0u
IEFkdmFudGFnZXMgb2YgWUFORyBpbmNsdWRlIEludGVybmV0IGJhc2VkDQo+ID4gPj4gICBjb25m
aWd1cmF0aW9uIGNhcGFiaWxpdHksIHZhbGlkYXRpb24sIHJvbGxiYWNrIGFuZCBzbyBvbi4gQWxs
IG9mDQo+ID4gPj4gICB0aGVzZSBjaGFyYWN0ZXJpc3RpY3MgbWFrZSBpdCBhdHRyYWN0aXZlIHRv
IGJlY29tZSBhbm90aGVyDQo+ID4gPj4gICBjYW5kaWRhdGUgbW9kZWxpbmcgbGFuZ3VhZ2UgZm9y
IElFRUUgMTU4OC0yMDA4Lg0KPiA+ID4+IA0KPiA+ID4+IE5FVzoNCj4gPiA+PiANCj4gPiA+PiAg
IElFRUUgMTU4OC0yMDA4IGlzIGEgdGltZSBwcm90b2NvbCB0aGF0IHByb3ZpZGVzIGhpZ2ggcHJl
Y2lzaW9uIHRpbWUNCj4gPiA+PiAgIHN5bmNocm9uaXphdGlvbiBhcyBmaW5lIGFzIG5hbm8tc2Vj
b25kcy4NCj4gPiA+PiANCj4gPiA+PiAgIElFRUUgMTU4OC0yMDA4IGl0c2VsZiBwcm92aWRlcyBh
biBpbmZvcm1hdGlvbiBtb2RlbCBpbiBpdHMNCj4gPiA+IG5vcm1hdGl2ZQ0KPiA+ID4+ICAgc3Bl
Y2lmaWNhdGlvbnMgZm9yIHRoZSBkYXRhIHNldHMgKElFRUUgMTU4OC0yMDA4IGNsYXVzZSA4KS4N
Cj4gPiA+PiAgIFN0YW5kYXJkIGluZm9ybWF0aW9uIG1vZGVscyAoZS5nLiBbUkZDODE3M10sIFtJ
RUVFODAyMUFTXSkgaGF2ZQ0KPiA+ID4gYmVlbg0KPiA+ID4+ICAgcHJldmlvdXNseSBkZWZpbmVk
IGFzIE1JQnMgZm9jdXNlZCBvbiB0aGUgcmV0cmlldmFsIG9mIHN0YXRlIA0KPiA+ID4+IGRhdGEN
Cj4gPiA+IHVzaW5nDQo+ID4gPj4gICBTTk1QIFtSRkMxMTU3XS4NCj4gPiA+PiANCj4gPiA+PiAg
IFlBTkcgW1JGQzYwMjBdIGlzIGEgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSB1c2VkIHRvIG1vZGVs
DQo+ID4gPiBjb25maWd1cmF0aW9uDQo+ID4gPj4gICBhbmQgc3RhdGUgZGF0YSBtYW5pcHVsYXRl
ZCBieSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGxpa2UNCj4gPiA+IE5FVENPTkYNCj4g
PiA+PiAgIFtSRkM2MjQxXS4NCj4gPiA+PiANCj4gPiA+PiAyLiBDYW4gd2UgcmVmZXIgdG8gdGhl
IHN5c3RlbSBhcyBzaW1wbHkgUFRQIHJhdGhlciB0aGFuIElFRUUNCj4gPiA+IDE1ODgoLTIwMDgp
Pw0KPiA+ID4+IFtZSl0gQWR2aWNlIGZyb20gSUVFRSAxNTg4IGlzLCB3ZSBuZWVkIHRvIHVzZSAi
MTU4OC0yMDA4IiBhcyBtdWNoIA0KPiA+ID4+IGFzDQo+ID4gPiBwb3NzaWJsZSB0byBoZWxwIGNs
YXJpZnkgdGhhdCB0aGUgc2NvcGUgb2YgdGhpcyBZQU5HIGlzIGxpbWl0ZWQgdG8gdGhlIHB1Ymxp
c2hlZCAxNTg4IHN0YW5kYXJkLg0KPiA+ID4+IA0KPiA+ID4+IA0KPiA+ID4+IDMuIFRoZXJlIGlz
IGluc3VmZmljaWVudCBzcGFjaW5nIGhlcmUgdG8gc2VwYXJhdGUgdGhlIHRlcm1zIGZyb20gDQo+
ID4gPj4gdGhlaXINCj4gPiA+IGRlZmluaXRpb25zOg0KPiA+ID4+IE9MRA0KPiA+ID4+IA0KPiA+
ID4+ICAgUFRQIGRhdGFzZXQgIFN0cnVjdHVyZWQgYXR0cmlidXRlcyBvZiBjbG9ja3MgKGFuIE9D
LCBCQyBvciBUQykgdXNlZA0KPiA+ID4+ICAgZm9yIFBUUCBwcm90b2NvbCBkZWNpc2lvbnMgYW5k
IGZvciBwcm92aWRpbmcgdmFsdWVzIGZvciBQVFAgbWVzc2FnZQ0KPiA+ID4+ICAgZmllbGRzLCBz
ZWUgU2VjdGlvbiA4IG9mIFtJRUVFMTU4OF0uDQo+ID4gPj4gDQo+ID4gPj4gICBQVFAgaW5zdGFu
Y2UgQSBQVFAgaW1wbGVtZW50YXRpb24gaW4gdGhlIGRldmljZSAoaS5lLiwgYW4gT0Mgb3IgQkMp
DQo+ID4gPj4gICByZXByZXNlbnRlZCBieSBhIHNwZWNpZmljIFBUUCBkYXRhc2V0Lg0KPiA+ID4+
IA0KPiA+ID4+IE5FVw0KPiA+ID4+IA0KPiA+ID4+ICAgUFRQIGRhdGFzZXQNCj4gPiA+PiAgICAg
U3RydWN0dXJlZCBhdHRyaWJ1dGVzIG9mIGNsb2NrcyAoYW4gT0MsIEJDIG9yIFRDKSB1c2VkDQo+
ID4gPj4gICAgIGZvciBQVFAgcHJvdG9jb2wgZGVjaXNpb25zIGFuZCBmb3IgcHJvdmlkaW5nIHZh
bHVlcyBmb3IgUFRQDQo+ID4gPiBtZXNzYWdlDQo+ID4gPj4gICAgIGZpZWxkcywgc2VlIFNlY3Rp
b24gOCBvZiBbSUVFRTE1ODhdLg0KPiA+ID4+IA0KPiA+ID4+ICAgUFRQIGluc3RhbmNlDQo+ID4g
Pj4gICAgIEEgUFRQIGltcGxlbWVudGF0aW9uIGluIHRoZSBkZXZpY2UgKGkuZS4sIGFuIE9DIG9y
IEJDKQ0KPiA+ID4+ICAgICByZXByZXNlbnRlZCBieSBhIHNwZWNpZmljIFBUUCBkYXRhc2V0Lg0K
PiA+ID4+IFtZSl0gT0suDQo+ID4gPj4gDQo+ID4gPj4gNC4gVGhlcmUncyBhIHNpbmd1bGFyL3Bs
dXJhbCBtaXNtYXRjaCBoZXJlOg0KPiA+ID4+IA0KPiA+ID4+ICAgbW9kdWxlLiBRdWVyeSBhbmQg
Y29uZmlndXJhdGlvbiBvZiBkZXZpY2Ugd2lkZSBvciBwb3J0IHNwZWNpZmljDQo+ID4gPj4gICBj
b25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGFuZCBjbG9jayBkYXRhIHNldCBpcyBkZXNjcmliZWQg
Zm9yIHRoaXMNCj4gPiA+PiAgIHZlcnNpb24uDQo+ID4gPj4gW1lKXSBHb29kLCB3ZSB3aWxsIGNo
YW5nZSAnaXMnIHRvICdhcmUnLg0KPiA+ID4+IA0KPiA+ID4+IGFuZCBoZXJlOg0KPiA+ID4+IA0K
PiA+ID4+ICAgUXVlcnkgYW5kIGNvbmZpZ3VyYXRpb24gb2YgY2xvY2sgaW5mb3JtYXRpb24gaW5j
bHVkZToNCj4gPiA+PiANCj4gPiA+PiANCj4gPiA+PiA1LiBUaGUgY2hvaWNlIG9mIHVpbnQxNiBh
cyBpbnN0YW5jZS1udW1iZXIgbGltaXRzIGltcGxlbWVudGF0aW9ucyANCj4gPiA+PiB0bw0KPiA+
ID4gNjU1MzYgZGlzdGluY3QgaW5zdGFuY2VzLg0KPiA+ID4+ICAgV2hpbGUgSSBoYXZlIGEgaGFy
ZCB0aW1lIGltYWdpbmluZyBhIHN5c3RlbSB3aXRoIG1vcmUgdGhhbiANCj4gPiA+PiA2NTUzNg0K
PiA+ID4gUFRQIGluc3RhbmNlcywgSSB3b3VsZCBwcmVmZXIgdG8gYXZvaWQgaW1wb3NpbmcgYXJi
aXRyYXJ5IGxpbWl0cy4NCj4gPiA+PiAgIEkgd291bGQgcmVjb21tZW5kIGNoYW5naW5nIGluc3Rh
bmNlLW51bWJlciB0byBhIHN0cmluZyAoYW5kDQo+ID4gPiByZW5hbWluZyBpdCB0byBpbnN0YW5j
ZS1uYW1lIG9yIGp1c3QgbmFtZSkuDQo+ID4gPj4gW1lKXSBUaGUgMTU4OC0yMDA4IHN1cHBvcnRz
IG11bHRpcGxlIGluc3RhbmNlcyBvZiBQVFAsIGJ1dCBpdCBpcw0KPiA+ID4gYW1iaWd1b3VzIGlu
IGl0cyBvcmdhbml6YXRpb24gb2YgdGhvc2UgUFRQIGluc3RhbmNlcywgZXNwZWNpYWxseSB3aXRo
IHJlZ2FyZCB0byBtYW5hZ2VtZW50Lg0KPiA+ID4+IEluIHRoZSAxNTg4IG5ldyByZXZpc2lvbiwg
dGhlcmUgaXMgYW4gZXhwbGljaXQgbGlzdCBvZiBQVFAgDQo+ID4gPj4gaW5zdGFuY2VzLA0KPiA+
ID4gYW5kIHRoYXQgbGlzdCBpcyBpbmRleGVkIHVzaW5nIGEgbnVtYmVyIChub3QgbmFtZSkuIFRo
dXMgdG8gYWxpZ24gd2l0aCB0aGUgbmV3IHJldmlzaW9uLCB3ZSBuZWVkIHRvIGtlZXAgaXQgaW5z
dGFuY2UtbnVtYmVyLg0KPiA+ID4+IElmIDY1NTM2IGxpbWl0IGlzIGEgY29uY2VybiwgaG93IGFi
b3V0IGNoYW5nZSBpdCB0byB1aW50MzIsIGFueQ0KPiA+ID4gY29uY2VybnM/DQo+ID4gPj4gDQo+
ID4gPj4gDQo+ID4gPj4gNi4gSSBzdGlsbCByZWNvbW1lbmQgcmVtb3ZpbmcgLWRzIGZyb20gdGhl
IFlBTkcgZWxlbWVudCBuYW1lcyANCj4gPiA+PiB0aGF0DQo+ID4gPiBzdGlsbCBpbmNsdWRlIGl0
LiBJdCBkb2Vzbid0IGFwcGVhciB0byBhZGQgYW55IHZhbHVlLg0KPiA+ID4+IFtZSl0gUm9kbmV5
J3Mgb3BpbmlvbjogdGhlIHZhbHVlIG9mIHVzaW5nICdkcycgaXMgdGhhdCB0aGUgMTU4OA0KPiA+
ID4gZG9jdW1lbnQgb24gd2hpY2ggdGhpcyBZQU5HIG1vZGVsIGlzIGJhc2VkIHVzZXMgIkRlZmF1
bHREUyIgYXMgYSB0ZXJtLg0KPiA+ID4gUFRQIGV4cGVydHMgZXZlbiBzYXkgImRlZmF1bHQgZGVl
IGVzcyIgdmVyYmFsbHkgd2hlbiByZWZlcnJpbmcgdG8gdGhpcyBkYXRhLiBJZiB3ZSBjaGFuZ2Vk
IHRoaXMgdG8ganVzdCAiZGVmYXVsdCIsIFBUUCBleHBlcnRzIG1pZ2h0IGFzc3VtZSB0aGF0IHdl
IGFyZSByZWZlcnJpbmcgdG8gc29tZXRoaW5nIGVudGlyZWx5IG5ldyB0byBZQU5HLiBUaHVzLCB0
byBhbGlnbiB3aXRoIDE1ODgtMjAwOCwgdGhlIHNhbWUgc2V0IG9mIHRlcm1pbm9sb2dpZXMgYXJl
IHVzZWQuDQo+ID4gPj4gDQo+ID4gPj4gNy4gV2hhdDtzIHRoZSByZWxldmFuY2Ugb2YgaW5qZWN0
aW9uIGF0dGFja3MgcmVsZXZhbnQgdG8gdGhpcyANCj4gPiA+PiBZQU5HDQo+ID4gPiBtb2R1bGU/
DQo+ID4gPj4gW1lKXSBUaGlzIGlzIGEgZ2VuZXJhbCBzdGF0ZW1lbnQgd2hpY2ggaXMgYXBwbGlj
YWJsZSB0byB0aGlzIFlBTkcNCj4gPiA+IG1vZHVsZSBhbmQgb3RoZXIgWUFORyBtb2R1bGVzIGFz
IHdlbGwuDQo+ID4gPj4gVGhhbmtzIGFnYWluLA0KPiA+ID4+IFl1YW5sb25nDQo+ID4gPj4gDQo+
ID4gPj4gQWxleA0KPiA+ID4+IA0KPiA+ID4+IA0KPiA+ID4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gPiA+PiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSmlhbmd5dWFubG9uZw0KPiA+ID4gPGppYW5neXVhbmxv
bmdAaHVhd2VpLmNvbT4NCj4gPiA+PiBTZW50OiBGcmlkYXksIDI3IE9jdG9iZXIgMjAxNyAzOjIx
IHAubS4NCj4gPiA+PiBUbzogdGljdG9jQGlldGYub3JnDQo+ID4gPj4gQ2M6IFhpYW4gTGl1OyBY
dWppbmNodW47IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4+IFN1YmplY3Q6IFtuZXRtb2RdIFdHIExh
c3QgQ2FsbCByZXNvbHV0aW9ucyBpbmNvcnBvcmF0ZWQgaW4NCj4gPiA+IGRyYWZ0LWlldGYtdGlj
dG9jLTE1ODh2Mi15YW5nLTA2DQo+ID4gPj4gDQo+ID4gPj4gRGVhciBhbGwsDQo+ID4gPj4gDQo+
ID4gPj4gQmFzZWQgb24gYWxsIHRoZSBjb21tZW50cyB3ZSByZWNlaXZlZCBkdXJpbmcgdGhlIFdH
IExhc3QgQ2FsbCANCj4gPiA+PiBwcm9jZXNzLA0KPiA+ID4gd2UndmUgdXBkYXRlZCB0aGUgZG9j
dW1lbnQgdG8gdmVyc2lvbiA2Lg0KPiA+ID4+IFdlIGJlbGlldmUgYWxsIHRoZSBMQyBjb21tZW50
cyBhcmUgcmVzb2x2ZWQgYW5kIHRoZSBjb25zZW5zdXMgaXMNCj4gPiA+IHJlZmxlY3RlZCBpbiB0
aGlzIG5ldyByZXZpc2lvbi4NCj4gPiA+PiBNYW55IHRoYW5rcyB0byBNYXJ0aW4sIFRhbCwgT3Bo
ZXIsIEFsZXgsIEpvaG4gYW5kIG1hbnkgb3RoZXJzIHdobyANCj4gPiA+PiBoYWQNCj4gPiA+IHJl
dmlld2VkIGFuZCBjb21tZW50ZWQgb24gdGhpcyBkcmFmdC4NCj4gPiA+PiANCj4gPiA+PiBDaGVl
cnMsDQo+ID4gPj4gWXVhbmxvbmcgb24gYmVoYWxmIG9mIGFsbCBjb2F1dGhvcnMNCj4gPiA+PiAN
Cj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IGludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiA+
PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjcsIDIwMTcgOTo0OCBBTQ0KPiA+ID4+IFRvOiBYaWFu
IExpdTsgUm9kbmV5IEN1bW1pbmdzOyByb2RuZXkuY3VtbWluZ3NAbmkuY29tOyANCj4gPiA+PiBK
aWFuZ3l1YW5sb25nOw0KPiA+ID4gWHVqaW5jaHVuDQo+ID4gPj4gU3ViamVjdDogTmV3IFZlcnNp
b24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ID4gZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmct
MDYudHh0DQo+ID4gPj4gDQo+ID4gPj4gDQo+ID4gPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy
YWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA2LnR4dA0KPiA+ID4+IGhhcyBiZWVuIHN1Y2Nl
c3NmdWxseSBzdWJtaXR0ZWQgYnkgWXVhbmxvbmcgSmlhbmcgYW5kIHBvc3RlZCB0byANCj4gPiA+
PiB0aGUNCj4gPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPiA+PiANCj4gPiA+PiBOYW1lOiAgICAg
ICAgICAgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcNCj4gPiA+PiBSZXZpc2lvbjogICAg
ICAgMDYNCj4gPiA+PiBUaXRsZTogICAgICAgICAgWUFORyBEYXRhIE1vZGVsIGZvciBJRUVFIDE1
ODgtMjAwOA0KPiA+ID4+IERvY3VtZW50IGRhdGU6ICAyMDE3LTEwLTI2DQo+ID4gPj4gR3JvdXA6
ICAgICAgICAgIHRpY3RvYw0KPiA+ID4+IFBhZ2VzOiAgICAgICAgICAzMA0KPiA+ID4+IFVSTDoN
Cj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fd3d3LmlldGYub3JnXw0KPiA+ID4gaW4gDQo+ID4gPiB0ZXJuZXQtMkRkcmFmdHNfZHJhZnQt
MkRpZXRmLTJEdGljdG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA2LnR4JmQ9RHcNCj4gPiA+IElGIA0K
PiA+ID4gZ1EmYz1JXzBZd29LeTd6NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1NqaXhBJnI9
V0E3MXNmMm83RHc3Q2JZDQo+ID4gPiBoRiANCj4gPiA+IHQyNERQanQzbEp1dXBzd1dZZG5ib0ti
WjhrJm09b1FUdWh4MEVfcnR5azE4ZTg5RmlyODJrTHh1clVDNHlYY2lYWg0KPiA+ID4gTUkgcVN0
dyZzPU4wTjVrQlBjR01pdlhXd3NwSEVPYy1iUDBtYllwa0t1Mkl2TTJBc3lmXzgmZT0NCj4gPiA+
IHQNCj4gPiA+PiBTdGF0dXM6DQo+ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmkNCj4gPiA+IGV0IA0KPiA+ID4gZi5v
cmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRHRpY3RvYy0yRDE1ODh2Mi0yRHlhbmdfJmQ9RHdJRmdRJmM9
SV8wWXdvDQo+ID4gPiBLeSANCj4gPiA+IDd6NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1Nq
aXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjREUGp0M2xKdQ0KPiA+ID4gdXAgDQo+ID4gPiBzd1dZ
ZG5ib0tiWjhrJm09b1FUdWh4MEVfcnR5azE4ZTg5RmlyODJrTHh1clVDNHlYY2lYWk1JcVN0dyZz
PWFZbG8NCj4gPiA+IHZ4IF9rVFF0QWlKQVVNVEpuOE5DUlpRSWlfakVWTmEtdENfNUhGbGsmZT0N
Cj4gPiA+PiBIdG1saXplZDoNCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcg0KPiA+ID4gZ18NCj4gPiA+IGh0bWxf
ZHJhZnQtMkRpZXRmLTJEdGljdG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA2JmQ9RHdJRmdRJmM9SV8w
WXdvSw0KPiA+ID4geTcgDQo+ID4gPiB6NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1NqaXhB
JnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjREUGp0M2xKdXUNCj4gPiA+IHBzIA0KPiA+ID4gd1dZZG5i
b0tiWjhrJm09b1FUdWh4MEVfcnR5azE4ZTg5RmlyODJrTHh1clVDNHlYY2lYWk1JcVN0dyZzPWox
YURqDQo+ID4gPiBpVSA3QWV1RVYtcDIwUE53TnB2WlByR1NiQmlITEh0YTdxMDVwYWsmZT0NCj4g
PiA+PiBIdG1saXplZDoNCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaQ0KPiA+ID4gZXQgDQo+ID4gPiBmLm9yZ19k
b2NfaHRtbF9kcmFmdC0yRGlldGYtMkR0aWN0b2MtMkQxNTg4djItMkR5YW5nLTJEMDYmZD1Ed0lG
Z1ENCj4gPiA+ICZjIA0KPiA+ID4gPUlfMFl3b0t5N3o1TE1UVmR5TzZZQ2lFMnV6STFqalpadUlQ
ZWxjU2ppeEEmcj1XQTcxc2YybzdEdzdDYlloRnQyDQo+ID4gPiA0RCANCj4gPiA+IFBqdDNsSnV1
cHN3V1lkbmJvS2JaOGsmbT1vUVR1aHgwRV9ydHlrMThlODlGaXI4MmtMeHVyVUM0eVhjaVhaTUlx
Uw0KPiA+ID4gdHcgJnM9N3RZT3YxTV9FWUhDUEcxTWlPcTNCVmw3dnBCMHctTFNpRFljUUhNNGF5
TSZlPQ0KPiA+ID4+IERpZmY6DQo+ID4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ18NCj4gPiA+IHJmIA0KPiA+ID4gY2Rp
ZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJEdGljdG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA2JmQ9
RHdJRmdRDQo+ID4gPiAmYyANCj4gPiA+ID1JXzBZd29LeTd6NUxNVFZkeU82WUNpRTJ1ekkxampa
WnVJUGVsY1NqaXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0Mg0KPiA+ID4gNEQgDQo+ID4gPiBQanQz
bEp1dXBzd1dZZG5ib0tiWjhrJm09b1FUdWh4MEVfcnR5azE4ZTg5RmlyODJrTHh1clVDNHlYY2lY
Wk1JcVMNCj4gPiA+IHR3ICZzPVoxMlhtXzJrN2NFQWxWN2xGUWJfenc3QS1ELUhMNzdDLUt1eTJC
Z3lDSEEmZT0NCj4gPiA+PiANCj4gPiA+PiBBYnN0cmFjdDoNCj4gPiA+PiAgIFRoaXMgZG9jdW1l
bnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3IgdGhlIGNvbmZpZ3VyYXRpb24gb2YNCj4g
PiA+PiAgIElFRUUgMTU4OC0yMDA4IGRldmljZXMgYW5kIGNsb2NrcywgYW5kIGFsc28gcmV0cmll
dmFsIG9mIHRoZQ0KPiA+ID4+ICAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiwgZGF0YSBzZXQg
YW5kIHJ1bm5pbmcgc3RhdGVzIG9mIElFRUUNCj4gPiA+PiAgIDE1ODgtMjAwOCBjbG9ja3MuDQo+
ID4gPj4gDQo+ID4gPj4gDQo+ID4gPj4gDQo+ID4gPj4gDQo+ID4gPj4gUGxlYXNlIG5vdGUgdGhh
dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiA+
IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls
YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPiA+PiANCj4gPiA+PiBUaGUgSUVURiBTZWNyZXRh
cmlhdA0KPiA+ID4+IA0KPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+ID4gPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4+IG5ldG1vZEBp
ZXRmLm9yZw0KPiA+ID4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fd3d3LmlldGYub3JnDQo+ID4gPj4gX20gDQo+ID4gPj4gYWlsbWFuX2xpc3Rp
bmZvX25ldG1vZCZkPUR3SUZnUSZjPUlfMFl3b0t5N3o1TE1UVmR5TzZZQ2lFMnV6STFqaloNCj4g
PiA+PiBadSANCj4gPiA+PiBJUGVsY1NqaXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjREUGp0M2xK
dXVwc3dXWWRuYm9LYlo4ayZtPW9RVHVoeA0KPiA+ID4+IDBFIA0KPiA+ID4+IF9ydHlrMThlODlG
aXI4MmtMeHVyVUM0eVhjaVhaTUlxU3R3JnM9Y1VsMGQwd0RYOWZJd2pJRUhsaGNyZmcxN3g3DQo+
ID4gPj4gcGgNCj4gPiA+PiBwSTlRaUY1UHVYc1lkNCZlPQ0KPiA+ID4+IA0KPiA+ID4+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPiA+ID4+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4+IGh0dHBzOi8vdXJs
ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnDQo+
ID4gPj4gX20gDQo+ID4gPj4gYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUZnUSZjPUlfMFl3
b0t5N3o1TE1UVmR5TzZZQ2lFMnV6STFqaloNCj4gPiA+PiBadSANCj4gPiA+PiBJUGVsY1NqaXhB
JnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjREUGp0M2xKdXVwc3dXWWRuYm9LYlo4ayZtPW9RVHVoeA0K
PiA+ID4+IDBFIA0KPiA+ID4+IF9ydHlrMThlODlGaXI4MmtMeHVyVUM0eVhjaVhaTUlxU3R3JnM9
Y1VsMGQwd0RYOWZJd2pJRUhsaGNyZmcxN3g3DQo+ID4gPj4gcGgNCj4gPiA+PiBwSTlRaUY1UHVY
c1lkNCZlPQ0KPiA+ID4gDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+ID4gVElDVE9DIG1haWxpbmcgbGlzdA0KPiA+ID4gVElDVE9DQGll
dGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpY3Rv
Yw0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiAtLSANCj4g
SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4g
Z0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwg
Mjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAg
IDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4gDQo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRJQ1RPQyBtYWlsaW5nIGxpc3QN
Cj4gVElDVE9DQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vdGljdG9jDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMg
VW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg
Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIw
MCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K


From nobody Mon Nov 27 05:18: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 CCB63127A91 for ; Mon, 27 Nov 2017 05:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=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 xG7BSdYADxeB for ; Mon, 27 Nov 2017 05:17:58 -0800 (PST)
Received: from smtp.dev.terastrm.net (smtp.dev.terastrm.net [IPv6:2003:1f0b:ffde::101]) by ietfa.amsl.com (Postfix) with ESMTP id BAFF3126C25 for ; Mon, 27 Nov 2017 05:17:58 -0800 (PST)
Received: from lingloi.dev.terastrm.net (unknown [IPv6:2003:1b3b:ffde:1::5]) by smtp.dev.terastrm.net (Postfix) with ESMTPSA id 0B3363A029A; Mon, 27 Nov 2017 13:17:55 +0000 (UTC)
References: <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net> <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com> <20171122.093904.670536605936490886.mbj@tail-f.com> 
User-agent: mu4e 0.9.18; emacs 25.1.1
From: Kristian Larsson 
To: Robert Wilton 
Cc: Martin Bjorklund , mjethanandani@gmail.com, jhaas@juniper.net, agarwaso@cisco.com, netmod@ietf.org, kll@spritelink.net
In-reply-to: 
Date: Mon, 27 Nov 2017 14:17:55 +0100
Message-ID: <87y3mr3loc.fsf@dev.terastrm.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] IETF 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, 27 Nov 2017 13:18:01 -0000

Robert Wilton  writes:

> Thinking about this some more. I'm not sure what it means for the "ACL 
> Type" to be "any-acl". It seems that the "match any packet" should be a 
> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a 
> type of ACL.

Yes, I agree as so far that any-acl makes no sense as an acl-type. The
way I understood acl-type, and the way that vendors have told me it will
be used, is to say "this is an IPv4 ACL" and then on an attachment point
you can specify that only ACLs of acl-type ipv4-acl can be attached to
the interface. That makes perfect sense. I do not see how any-acl can
map into this.

I agree that any-acl is logically a type of ACE but we don't have an
ace-type and the exact same information can IMHO already be conveyed
WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
need a feature for it.

>From what I can tell the any-acl container in the ACE should be used to
explicitly signify a match on "any". Think of IOS style ipv4 acl:
  permit ip any any

We have to provide a source and destination so this would be a rather
explicit mapping of that. However, our structure in this YANG model is
just completely different than an IOS command so I don't see why we
should try and mimic IOS in the YANg model.

Not specifying a destination IP address means we match on any
destination IP address. The same is true for any other field we can
match on. Not setting a match implies we don't try to match on that
field, thus we allow "any" value. I think the logical continuation of
this is that for an ACE with no matches defined at all, we match any
packet. I think we can update the text to better explain this.



> Otherwise if the ACL type is "any-acl" then this only allows two types 
> of ACLs to be defined, neither of which seem to be particularly useful:
> (1) An ACL that matches all traffic and permits it, i.e. the same as 
> having no ACL at all.
> (2) An ACL that matches all traffic and drops.
>
> So I think perhaps the answer here is to define neither ACL type 
> "any-acl" nor leaf "any". The presumption could be that any ACE that is 
> configured to match no fields implicitly matches all packets (because 
> all non specified fields are treated as wildcards), and then applies the 
> permit/deny rule associated with the ACE. This logic can apply to all 
> ACL types.

Yes yes yes :)

   Kristian.


From nobody Mon Nov 27 07:00: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 0D86D128796 for ; Mon, 27 Nov 2017 07:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 SUejrfHHipoa for ; Mon, 27 Nov 2017 07:00:40 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280A5124F57 for ; Mon, 27 Nov 2017 07:00:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3470; q=dns/txt; s=iport; t=1511794840; x=1513004440; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/uQMyKohskeQyv7ZbC1MqUjT1IZvRVh2D0WDGOjPFn4=; b=GFeAXox60VLV2QOzxp1Pek8ci41BFmTr3/CawgCESOF3daS4b/KTQebo vuGQGZwpkfF0NCAsMEimx45wMSK9SG2wKwAc8JoY/5M56eGj1gPBKo+Ua aluzDbfEEX07DlAbYusaFT56SBfLXJQOg3sCWanfV/J8QxjqSGZYDq4Ai s=;
X-IronPort-AV: E=Sophos;i="5.44,465,1505779200";  d="scan'208";a="504084"
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; 27 Nov 2017 15:00:38 +0000
Received: from [10.63.23.82] (dhcp-ensft1-uk-vla370-10-63-23-82.cisco.com [10.63.23.82]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vARF0c9V023746; Mon, 27 Nov 2017 15:00:38 GMT
To: Kristian Larsson 
Cc: Martin Bjorklund , mjethanandani@gmail.com, jhaas@juniper.net, agarwaso@cisco.com, netmod@ietf.org, kll@spritelink.net
References: <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net> <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com> <20171122.093904.670536605936490886.mbj@tail-f.com>  <87y3mr3loc.fsf@dev.terastrm.net>
From: Robert Wilton 
Message-ID: 
Date: Mon, 27 Nov 2017 15:00:38 +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: <87y3mr3loc.fsf@dev.terastrm.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] IETF 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, 27 Nov 2017 15:00:42 -0000

On 27/11/2017 13:17, Kristian Larsson wrote:
> Robert Wilton  writes:
>
>> Thinking about this some more. I'm not sure what it means for the "ACL
>> Type" to be "any-acl". It seems that the "match any packet" should be a
>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a
>> type of ACL.
> Yes, I agree as so far that any-acl makes no sense as an acl-type. The
> way I understood acl-type, and the way that vendors have told me it will
> be used, is to say "this is an IPv4 ACL" and then on an attachment point
> you can specify that only ACLs of acl-type ipv4-acl can be attached to
> the interface. That makes perfect sense. I do not see how any-acl can
> map into this.
>
> I agree that any-acl is logically a type of ACE but we don't have an
> ace-type and the exact same information can IMHO already be conveyed
> WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
> need a feature for it.
>
> >From what I can tell the any-acl container in the ACE should be used to
> explicitly signify a match on "any". Think of IOS style ipv4 acl:
>    permit ip any any
>
> We have to provide a source and destination so this would be a rather
> explicit mapping of that. However, our structure in this YANG model is
> just completely different than an IOS command so I don't see why we
> should try and mimic IOS in the YANg model.
>
> Not specifying a destination IP address means we match on any
> destination IP address. The same is true for any other field we can
> match on. Not setting a match implies we don't try to match on that
> field, thus we allow "any" value. I think the logical continuation of
> this is that for an ACE with no matches defined at all, we match any
> packet. I think we can update the text to better explain this.

>
>
>
>> Otherwise if the ACL type is "any-acl" then this only allows two types
>> of ACLs to be defined, neither of which seem to be particularly useful:
>> (1) An ACL that matches all traffic and permits it, i.e. the same as
>> having no ACL at all.
>> (2) An ACL that matches all traffic and drops.
>>
>> So I think perhaps the answer here is to define neither ACL type
>> "any-acl" nor leaf "any". The presumption could be that any ACE that is
>> configured to match no fields implicitly matches all packets (because
>> all non specified fields are treated as wildcards), and then applies the
>> permit/deny rule associated with the ACE. This logic can apply to all
>> ACL types.
> Yes yes yes :)
Another area of the current model that I'm not quite convinced about is 
about the L4 matches (UDP, TCP, ICMP).

Currently the model assumes that if a device can support matching on say 
UDP fields that they can apply to any type of ACL.  However, I think 
that it is plausible that the UCP, TCP and ICMP fields might only apply 
to IP ACLs and not Ethernet ACLs.

Hence, I was wondering if there should be "acl match type" identity 
defined for the "l4" field matches?

This would then cause there to be twice as many ACL types identities and 
features defined, e.g.

eth,
ipv4,
ipv6,
l4
eth-l4,
eth-ipv4,
eth-ipv4-l4,
eth-ipv6,
eth-ipv6-l4,
eth-ipv4-ipv6,
eth-ipv4-ipv6-l4
ipv4
ipv4-l4
ipv6
ipv6-l4,
ipv4-ipv6
ipv4-ipv6-l4

So, trading off my ACL type combinations for more expressiveness as to 
what can actually be supported.

Thanks,
Rob


>
>     Kristian.
> .
>


From nobody Mon Nov 27 09: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 0279F128D19 for ; Mon, 27 Nov 2017 09:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql4RJh0l8poe for ; Mon, 27 Nov 2017 09:47:21 -0800 (PST)
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 88B2F126557 for ; Mon, 27 Nov 2017 09:47:21 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id r68so11532486pfe.10 for ; Mon, 27 Nov 2017 09:47:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=T3F0a/MWxKTtm9vuKOp9x/vE2WkonRWs7M1hKqEKrD0=; b=Z/eygYnvnuaegTyrchJrZe5eoheGZjL+/zcQhXalG/cnQtZEM26KV5abE04SzGpxb7 GwJaAAHPOiBvtgcCRiH7PjssXvldXmya1TqqQmqMz4SSX1MMqv1vIEB5ZIqhC/Sh8yW5 bLgdkLftW117amOgQm2NHAEYqSgFOdod85M5zYnlkKsJ8HGzgbeUg145vk/YvLsyikmT 5H0DL475yLfQOIRAW9c1FRnv0QabBFghBTFOVOsMFgigKObO1VqbmCueLz9A1EG8WM4x qzrTVxTaUVKnEifXg7QBaPQmvlt64QKrzqz2VSjB4aftA+QP1C/nJESpqJfVYLOsHAE4 aGgw==
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=T3F0a/MWxKTtm9vuKOp9x/vE2WkonRWs7M1hKqEKrD0=; b=SDyXK01YkKHXdazEgMS5Ee4Zot8QpKHWWGyQ3ayOLBpcth2CRg49RkNuPojy4XKAJ9 RZFtbdA4JpeAqhuIufr/Lib7JFYfjqevqZ0n8UkI7l6OhaRT0/YUyvKB4pRxoMmHufu9 VnKgORTWjZuy5gVgFxkAL1VY23Dy662nOP+M1KK4Irq4nDE5yXtAdWgDNlEIH+j+jzEH w8B+0ElxqXP/CfI1E5SEasUKwNFwRuopgiPsPvCvHDayBW2gx8kH1iQu3si07cxZpUte FKS/x8yFVoLVoPV7Zo2rYaIiwE07U3usaLTt6fHuIAIAiTdtR+Avz7hKz1qCQ1Y6j2tv 2NKw==
X-Gm-Message-State: AJaThX5hCRoYv8/QB2SngEDiwGJD85rXsUsjk857NFJq+njM/dyJWFP3 Ej3R3v2PXSF4jKiPdT+hlO6xoRLs
X-Google-Smtp-Source: AGs4zMYN2/GqfDohuWpShoStBt9/LMRUiregyLbxG7GB0q6WquMbHeqxlFS6l/mCqSe4K+8SUlEreQ==
X-Received: by 10.101.93.134 with SMTP id f6mr37321958pgt.89.1511804840523; Mon, 27 Nov 2017 09:47:20 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:c9c7:4c2b:674a:1f86]) by smtp.gmail.com with ESMTPSA id u68sm49117388pfu.154.2017.11.27.09.47.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Nov 2017 09:47:19 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C9822A9A-6C16-4BB1-A56A-BFCAF2D73760"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <87y3mr3loc.fsf@dev.terastrm.net>
Date: Mon, 27 Nov 2017 09:47:16 -0800
Cc: Robert Wilton , Martin Bjorklund , Jeffrey Haas , "Sonal Agarwal (agarwaso)" , Kristian Larsson , Kristian Larsson 
Message-Id: 
References: <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net> <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com> <20171122.093904.670536605936490886.mbj@tail-f.com>  <87y3mr3loc.fsf@dev.terastrm.net>
To: NetMod WG 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] IETF 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, 27 Nov 2017 17:47:23 -0000

--Apple-Mail=_C9822A9A-6C16-4BB1-A56A-BFCAF2D73760
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

An updated version of the model has been posted as part of the PR here =
.

The particular change removes any-acl from the model, expands on eth (to =
ethernet), removes acl- prefix for things like acl-type and acl-name. =
Please review.

> On Nov 27, 2017, at 5:17 AM, Kristian Larsson  =
wrote:
>=20
>=20
> Robert Wilton  writes:
>=20
>> Thinking about this some more. I'm not sure what it means for the =
"ACL=20
>> Type" to be "any-acl". It seems that the "match any packet" should be =
a=20
>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a=20=

>> type of ACL.
>=20
> Yes, I agree as so far that any-acl makes no sense as an acl-type. The
> way I understood acl-type, and the way that vendors have told me it =
will
> be used, is to say "this is an IPv4 ACL" and then on an attachment =
point
> you can specify that only ACLs of acl-type ipv4-acl can be attached to
> the interface. That makes perfect sense. I do not see how any-acl can
> map into this.
>=20
> I agree that any-acl is logically a type of ACE but we don't have an
> ace-type and the exact same information can IMHO already be conveyed
> WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
> need a feature for it.
>=20
> =46rom what I can tell the any-acl container in the ACE should be used =
to
> explicitly signify a match on "any". Think of IOS style ipv4 acl:
>  permit ip any any
>=20
> We have to provide a source and destination so this would be a rather
> explicit mapping of that. However, our structure in this YANG model is
> just completely different than an IOS command so I don't see why we
> should try and mimic IOS in the YANg model.
>=20
> Not specifying a destination IP address means we match on any
> destination IP address. The same is true for any other field we can
> match on. Not setting a match implies we don't try to match on that
> field, thus we allow "any" value. I think the logical continuation of
> this is that for an ACE with no matches defined at all, we match any
> packet. I think we can update the text to better explain this.
>=20
>=20
>=20
>> Otherwise if the ACL type is "any-acl" then this only allows two =
types=20
>> of ACLs to be defined, neither of which seem to be particularly =
useful:
>> (1) An ACL that matches all traffic and permits it, i.e. the same as=20=

>> having no ACL at all.
>> (2) An ACL that matches all traffic and drops.
>>=20
>> So I think perhaps the answer here is to define neither ACL type=20
>> "any-acl" nor leaf "any". The presumption could be that any ACE that =
is=20
>> configured to match no fields implicitly matches all packets (because=20=

>> all non specified fields are treated as wildcards), and then applies =
the=20
>> permit/deny rule associated with the ACE. This logic can apply to all=20=

>> ACL types.
>=20
> Yes yes yes :)
>=20
>   Kristian.

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_C9822A9A-6C16-4BB1-A56A-BFCAF2D73760
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

An updated version of the model has been posted as part of =
the PR here.

The particular change removes any-acl =
from the model, expands on eth (to ethernet), removes acl- prefix for =
things like acl-type and acl-name. Please review.

On Nov 27, 2017, at 5:17 AM, Kristian Larsson <kll@dev.terastrm.net> wrote:


Robert Wilton <rwilton@cisco.com> writes:

Thinking about this some =
more. I'm not sure what it means for the "ACL 
Type" to be =
"any-acl". It seems that the "match any packet" should be a 
type of ACE, e.g. perhaps as the last entry of an ACL, rather =
than a 
type of ACL.

Yes, I agree as so far that any-acl makes no sense as an =
acl-type. The
way I understood acl-type, and the way that =
vendors have told me it will
be used, is to say "this is =
an IPv4 ACL" and then on an attachment point
you can =
specify that only ACLs of acl-type ipv4-acl can be attached to
the interface. That makes perfect sense. I do not see how =
any-acl can
map into this.

I =
agree that any-acl is logically a type of ACE but we don't have an
ace-type and the exact same information can IMHO already be =
conveyed
WITHOUT the any-acl type and thus it has no =
reason to exist. Nor do we
need a feature for it.

=46rom what I can tell the any-acl container =
in the ACE should be used to
explicitly signify a match on =
"any". Think of IOS style ipv4 acl:
  permit ip any =
any

We have to provide a source and =
destination so this would be a rather
explicit mapping of =
that. However, our structure in this YANG model is
just =
completely different than an IOS command so I don't see why we
should try and mimic IOS in the YANg model.

Not specifying a destination IP address means we match on =
any
destination IP address. The same is true for any other =
field we can
match on. Not setting a match implies we =
don't try to match on that
field, thus we allow "any" =
value. I think the logical continuation of
this is that =
for an ACE with no matches defined at all, we match any
packet. I think we can update the text to better explain =
this.



Otherwise if the ACL =
type is "any-acl" then this only allows two types 
of ACLs =
to be defined, neither of which seem to be particularly useful:
(1) An ACL that matches all traffic and permits it, i.e. the =
same as 
having no ACL at all.
(2) An ACL =
that matches all traffic and drops.

So I =
think perhaps the answer here is to define neither ACL type 
"any-acl" nor leaf "any". The presumption could be that any =
ACE that is 
configured to match no fields implicitly =
matches all packets (because 
all non specified fields are =
treated as wildcards), and then applies the 
permit/deny =
rule associated with the ACE. This logic can apply to all 
ACL types.

Yes yes =
yes :)

   Kristian.



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_C9822A9A-6C16-4BB1-A56A-BFCAF2D73760--


From nobody Mon Nov 27 13:59: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 BA699124D6C for ; Mon, 27 Nov 2017 13:59:12 -0800 (PST)
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 jWM13XsXyveG for ; Mon, 27 Nov 2017 13:59:11 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF7D1200C5 for ; Mon, 27 Nov 2017 13:59:11 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 3DDC21E17C1 for ; Mon, 27 Nov 2017 14:59:11 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id f9z81w0042SSUrH019zBwb; Mon, 27 Nov 2017 14:59:11 -0700
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=sC3jslCIGhcA:10 a=imFlxykSS6GNyt6sfbMA: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:To:Sender:Reply-To:Cc: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=tW9kML1zSq0O2AusEgh17oR2Sz8jTns6nxd7IXHR9Tk=; b=xxhGoirxkYxQPkT5vcUKiJqzuH 55my0rYCkLYQA2gC+8v59dUP7J245h1WHllLKF6pKpGazT/GVX1hjLmepMS2lS0hzA0Mdltel8ke7 tfOL7sn8JaB1OmibAPSRerEw+;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:39522 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eJRQh-002rfm-Rv; Mon, 27 Nov 2017 14:59:07 -0700
To: draft-bierman-netmod-yang-data-ext@ietf.org, NetMod WG 
From: Lou Berger 
Message-ID: 
Date: Mon, 27 Nov 2017 16:59:08 -0500
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
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: 1eJRQh-002rfm-Rv
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]:39522
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] comment on draft-bierman-netmod-yang-data-ext
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Nov 2017 21:59:13 -0000

Hi,

    I was looking at how yd:yang-data (this draft) relates to
rc:yang-data (rfc8040).  The document seems to imply that this draft's
extension is a replacement in one place (see abstract) , is supplemental
in another (sec 1, plus augment-yang-data example) and perhaps
orthogonal in a final (that rc:yang-data is still used/referenced at
all).  I think the document should be clear as to it's objective with
respect to  rc:yang-data. 

As rc:yang-data is currently defined in a protocol specific way, I (with
any/all hats) would prefer to see a definition of yang-data that would
work for any protocol that encodes and transports yang.  I also
generally think that having two definitions for basically the same
mechanism isn't beneficial to implementors of IETF RFCs, so this leads
me to suggest that if this document becomes a WG document it should
deprecate rc:yang-data.

Lou



From nobody Mon Nov 27 16:34: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 40EDD129417; Mon, 27 Nov 2017 16:34:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 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, 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 FJIrfKk5UqrW; Mon, 27 Nov 2017 16:34:25 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24757128AA1; Mon, 27 Nov 2017 16:34:25 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0B1CB9ED4CA6F; Tue, 28 Nov 2017 00:34: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.361.1; Tue, 28 Nov 2017 00:34:22 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML701-CHM.china.huawei.com ([169.254.3.207]) with mapi id 14.03.0361.001;  Mon, 27 Nov 2017 16:34:15 -0800
From: Alexander Clemm 
To: Mahesh Jethanandani , netconf 
CC: Jeff Tantsura , Yingzhen Qu , Lou Berger , "netmod@ietf.org" 
Thread-Topic: [Netconf] Summary and AIs from IETF-100 meeting
Thread-Index: AQHTZ9dUHhA1I7Z67kivQ2HOm7SmNqMo7B7Q
Date: Tue, 28 Nov 2017 00:34:15 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EACED10@sjceml521-mbx.china.huawei.com>
References: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com>
In-Reply-To: <4686C139-D0B5-4308-A1B5-2689992B8265@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.217.14]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACED10sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Netconf] Summary and AIs from IETF-100 meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Nov 2017 00:34:27 -0000

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

Hi,

One other action / question concerns WG adoption of draft-clemm-netconf-nmd=
a-diff-01 =
(Discrepancy detection between NMDA datastores).
The draft received considerable support when the question was asked in the =
room, but one question that was asked concerns whether this should be in Ne=
tconf or perhaps in Netmod instead.  Hence, cc'ing Lou and netmod.

The reason we put this into Netconf concerns the fact that this really defi=
nes an RPC, i.e. operations to facilitate interacting with NMDA-compliant s=
ervers.  It complements the RESTCONF and NETCONF operations, and the NMDA-e=
xtensions to those are also placed in the Netconf WG.  This seemed like ano=
ther natural extension.  The draft does not really define a traditional YAN=
G data model per se that would be used to manage something, therefore it si=
mply did not occur to us to place it into Netmod, although I can see how on=
e might make a case for that as well.

So, from our (coauthors) perspective, for the stated reasons, perhaps sligh=
t preference for Netconf, but really either one (Netconf or Netmod) is fine=
.  One thing we would not want to do is slow this effort down; since this w=
as presented in Netconf, not in Netmod, if we were moved into Netmod it wou=
ld hopefully not mean having to go back to square 1.

Thoughts?
--- Alex


From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethana=
ndani
Sent: Monday, November 27, 2017 3:27 PM
To: netconf 
Subject: [Netconf] Summary and AIs from IETF-100 meeting

Dear NETCONF WG,

Below is the NETCONF WG session summary and AIs that were taken from the IE=
TF 100 meeting.

This e-mail verifies the discussion that took place in the room. Barring an=
y strong objection, the AIs identified in this summary will be acted upon.

The NETCONF session took place on Thursday, November 16, 2017, between 15:5=
0-17:50 Singapore Time.

The final notes from the meeting (once posted) will be available at:
https://datatracker.ietf.org/doc/minutes-99-netconf/


  *   rfc6536bis received comments in IESG review. Some last minute updates=
 are being provided to address those comments, and once approved will allow=
 the document to go towards publication. AI for authors to post updated dra=
ft before Benoit submits it for publication.
  *   NMDA drafts (YANG Library, NETCONF and RESTCONF) need updates to supp=
ort features like licensing, and semantic versioning. It also needs to addr=
ess some bugs. Authors believe the document should be ready for WGLC by end=
 of this year. AI for authors to provide updated draft before the three set=
 of drafts are submitted for LC.
  *   Zerotouch draft went through LC. It received comments during that per=
iod, which the author will address. Author believes that once the document =
is ready, it can be forwarded for publication, currently planned for Decemb=
er. AI for author to provide updated draft.
  *   Keystore draft needs to be updated for issues raised in WGLC and disc=
ussion on the mailing list. AI for author(s) to provide updated drafts befo=
re LC can be re-initiated.
  *   SSH/TLS NETCONF/RESTCONF Client Server Models also needs updates base=
d on changes in the Keystore draft.  AI for author(s) to provide updated dr=
afts before LC will be re-initated.
  *   YANG Push, Subscribed notifications and NETCONF notification drafts n=
eed updates based on discussion in the meeting and on the list. There are s=
till outstanding questions on whether NETCONF notifications draft is needed=
 or its contents can be folded into subscribed-notifications draft.  All th=
ese issues need to be discussed and resolved on the mailing list. Co-chairs=
 will initiate WGLC once the issues are resolved. AI for authors to close o=
n open issues and post updated draft.
  *   Notification Message Headers and Bundles and Restconf notifications -=
 These two drafts will be considered for WGLC later. No AI.
  *   UDP Pub Channel draft needs more discussion on the mailing list. A mi=
lestone will be added to the NETCONF WG milestones. No other AI planned at =
this time.
Cheers

Mahesh (and Kent)


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











Hi,


 


One other action / question concerns =
WG adoption of
draft-clemm-netconf-nmda-diff-01<=
/span> (Discrepancy detection between NMDA datastores). 



The draft received considerable support when the qu=
estion was asked in the room, but one question that was asked concerns whet=
her this should be in Netconf or perhaps in Netmod
 instead.  Hence, cc’ing Lou and netmod.  


 


The reason we put this into Netconf concerns the fa=
ct that this really defines an RPC, i.e. operations to facilitate interacti=
ng with NMDA-compliant servers.  It complements
 the RESTCONF and NETCONF operations, and the NMDA-extensions to those are =
also placed in the Netconf WG.  This seemed like another natural exten=
sion.  The draft does not really define a traditional YANG data model =
per se that would be used to manage something,
 therefore it simply did not occur to us to place it into Netmod, although =
I can see how one might make a case for that as well. 



 


So, from our (coauthors) perspective, for the state=
d reasons, perhaps slight preference for Netconf, but really either one (Ne=
tconf or Netmod) is fine.  One thing we would
 not want to do is slow this effort down; since this was presented in Netco=
nf, not in Netmod, if we were moved into Netmod it would hopefully not mean=
 having to go back to square 1. 



 


Thoughts?


--- Alex


 


 








From: Netconf [mailto:netconf-bounce=
s@ietf.org]
On Behalf Of Mahesh Jethanandani

Sent: Monday, November 27, 2017 3:27 PM

To: netconf <netconf@ietf.org>

Subject: [Netconf] Summary and AIs from IETF-100 meeting<=
/span>






 




Dear NETCONF WG,




 




Below is the NETCONF WG session summary and AIs that=
 were taken from the IETF 100 meeting.




 




This e-mail verifies the discussion that took place =
in the room. Barring any strong objection, the AIs identified in this summa=
ry will be acted upon.




 




The NETCONF session took place on Thursday, November=
 16, 2017, between 15:50-17:50 Singapore Time.




 




The final notes from the meeting (once posted) will =
be available at:





 


    

  • rfc6536bis receiv=
ed comments in IESG review. Some last minute updates are being provided to =
address those comments, and once approved will allow the document to go tow=
ards publication. AI for authors to
 post updated draft before Benoit submits it for publication.
  • NMDA drafts (YA=
NG Library, NETCONF and RESTCONF) need updates to support features like lic=
ensing, and semantic versioning. It also needs to address some bugs. Author=
s believe the document should be ready
 for WGLC by end of this year. AI for authors to provide updated draft befo=
re the three set of drafts are submitted for LC.
  • Zerotouch draft went throu=
gh LC. It received comments during that period, which the author will addre=
ss. Author believes that once the document is ready, it can be forwarded fo=
r publication, currently planned
 for December. AI for author to provide updated draft.
  • Keystore draft needs t=
o be updated for issues raised in WGLC and discussion on the mailing list. =
AI for author(s) to provide updated drafts before LC can be re-initiated.
  • SSH=
/TLS NETCONF/RESTCONF Client Server Models also needs updates based on chan=
ges in the Keystore draft.  AI for author(s) to provide updated drafts=
 before LC will be re-initated. 
  • YANG Push, Subscribed notifications and=
 NETCONF notification drafts need updates based on discussion in the meetin=
g and on the list. There are still outstanding questions on whether NETCONF=
 notifications
 draft is needed or its contents can be folded into subscribed-notification=
s draft.  All these issues need to be discussed and resolved on the ma=
iling list. Co-chairs will initiate WGLC once the issues are resolved. AI f=
or authors to close on open issues and
 post updated draft. 
  • Notification Message Headers and Bundles and Restc=
onf notifications - These two drafts will be considered for WGLC later. No =
AI.
  • Cheers
    





 








Mahesh (and Kent)






 








--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EACED10sjceml521mbxchi_--


From nobody Mon Nov 27 22:37: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 5BD8A12711B; Mon, 27 Nov 2017 22:37:16 -0800 (PST)
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 7Yj-9rxXblTz; Mon, 27 Nov 2017 22:37:15 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1B01200E5; Mon, 27 Nov 2017 22:37:14 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DB38949DE0B4E; Tue, 28 Nov 2017 06:37:11 +0000 (GMT)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 28 Nov 2017 06:37:13 +0000
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.47]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 14:37:08 +0800
From: Jiangyuanlong 
To: "tictoc@ietf.org" , "netmod@ietf.org" 
Thread-Topic: I-D Action: draft-ietf-tictoc-1588v2-yang-07.txt
Thread-Index: AQHTaBNQFzY2XQz9k0ya6oncrDjgdQ==
Date: Tue, 28 Nov 2017 06:37:08 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB65C509@dggeml507-mbx.china.huawei.com>
References: <151185035711.13451.15517049816245497403@ietfa.amsl.com>
In-Reply-To: <151185035711.13451.15517049816245497403@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-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] FWD: I-D Action: draft-ietf-tictoc-1588v2-yang-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, 28 Nov 2017 06:37:16 -0000

Hi all,

Based on all the comments we received after the WG Last Call, another revis=
ion of this draft is uploaded.
Thanks a lot for all those discussions.

Regards,
Yuanlong

-----Original Message-----
From: TICTOC +AFs-mailto:tictoc-bounces+AEA-ietf.org+AF0- On Behalf Of inte=
rnet-drafts+AEA-ietf.org
Sent: Tuesday, November 28, 2017 2:26 PM
To: i-d-announce+AEA-ietf.org
Cc: tictoc+AEA-ietf.org
Subject: +AFs-TICTOC+AF0- I-D Action: draft-ietf-tictoc-1588v2-yang-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Timing over IP Connection and Transfer of =
Clock WG of the IETF.

        Title           : YANG Data Model for IEEE 1588-2008
        Authors         : Yuanlong Jiang
                          Xian Liu
                          Jinchun Xu
                          Rodney Cummings
	Filename        : draft-ietf-tictoc-1588v2-yang-07.txt
	Pages           : 29
	Date            : 2017-11-27

Abstract:
   This document defines a YANG data model for the configuration of
   IEEE 1588-2008 devices and clocks, and also retrieval of the
   configuration information, data set and running states of IEEE
   1588-2008 clocks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-07
https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2+AD0-draft-ietf-tictoc-1588v2-yang-07


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.

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

+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF=
8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
TICTOC mailing list
TICTOC+AEA-ietf.org
https://www.ietf.org/mailman/listinfo/tictoc


From nobody Tue Nov 28 01:54: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 3C8351277BB; Tue, 28 Nov 2017 01:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn8FP8AcCKQd; Tue, 28 Nov 2017 01:54:36 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE420128BB6; Tue, 28 Nov 2017 01:54:35 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 0B4BD1AE0336; Tue, 28 Nov 2017 10:54:33 +0100 (CET)
Date: Tue, 28 Nov 2017 10:53:13 +0100 (CET)
Message-Id: <20171128.105313.1322848757325572415.mbj@tail-f.com>
To: lberger@labn.net
Cc: draft-bierman-netmod-yang-data-ext@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=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] comment on draft-bierman-netmod-yang-data-ext
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Nov 2017 09:54:37 -0000

Hi,

Lou Berger  wrote:
> Hi,
> =

> =A0=A0=A0 I was looking at how yd:yang-data (this draft) relates to
> rc:yang-data (rfc8040).=A0 The document seems to imply that this draf=
t's
> extension is a replacement in one place (see abstract) , is supplemen=
tal
> in another (sec 1, plus augment-yang-data example) and perhaps
> orthogonal in a final (that rc:yang-data is still used/referenced at
> all).=A0 I think the document should be clear as to it's objective wi=
th
> respect to=A0 rc:yang-data.

Agreed.  It is intended to replace rc:yang-data.  I have fixed the
example that used rc:yang-data.  Do you think we need any changes to
section 1 to clarify this?

> As rc:yang-data is currently defined in a protocol specific way, I (w=
ith
> any/all hats) would prefer to see a definition of yang-data that woul=
d
> work for any protocol that encodes and transports yang.=A0 I also
> generally think that having two definitions for basically the same
> mechanism isn't beneficial to implementors of IETF RFCs, so this lead=
s
> me to suggest that if this document becomes a WG document it should
> deprecate rc:yang-data.

I assume this would formally mean that this document would "Update"
RFC 8040, and then in the document have text that explains that
rc:yang-data is deprecated?  Or do you suggest that we actually do a
8040bis that formally marks the rc:yang-data extension as
"deprecated", and instead uses yd:yang-data?


/martin


From nobody Tue Nov 28 02:18: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 28E85126B6E for ; Tue, 28 Nov 2017 02:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ol1t6ZUBaiEP for ; Tue, 28 Nov 2017 02:18:37 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84597124319 for ; Tue, 28 Nov 2017 02:18:37 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 654EF1AE0336; Tue, 28 Nov 2017 11:18:36 +0100 (CET)
Date: Tue, 28 Nov 2017 11:17:15 +0100 (CET)
Message-Id: <20171128.111715.2283575031970124402.mbj@tail-f.com>
To: mjethanandani@gmail.com
Cc: netmod@ietf.org, rwilton@cisco.com, jhaas@juniper.net, agarwaso@cisco.com, kll@spritelink.net, kll@dev.terastrm.net
From: Martin Bjorklund 
In-Reply-To: 
References:  <87y3mr3loc.fsf@dev.terastrm.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] IETF 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, 28 Nov 2017 10:18:39 -0000

Mahesh Jethanandani  wrote:
> An updated version of the model has been posted as part of the PR here
> .
> 
> The particular change removes any-acl from the model, expands on eth
> (to ethernet), removes acl- prefix for things like acl-type and
> acl-name. Please review.

I think 99% of the changes in this PR look good.  The one
exception is the typedef that used to be called "acl-type".  I think
it should still be called "acl-type".  "type" is too broad.  NOTE,
this is just the typedef; the leaf /access-lists/acl/type should keep
its name ("type").


/martin



> 
> > On Nov 27, 2017, at 5:17 AM, Kristian Larsson 
> > wrote:
> > 
> > 
> > Robert Wilton  writes:
> > 
> >> Thinking about this some more. I'm not sure what it means for the "ACL
> >> Type" to be "any-acl". It seems that the "match any packet" should be
> >> a
> >> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a 
> >> type of ACL.
> > 
> > Yes, I agree as so far that any-acl makes no sense as an acl-type. The
> > way I understood acl-type, and the way that vendors have told me it
> > will
> > be used, is to say "this is an IPv4 ACL" and then on an attachment
> > point
> > you can specify that only ACLs of acl-type ipv4-acl can be attached to
> > the interface. That makes perfect sense. I do not see how any-acl can
> > map into this.
> > 
> > I agree that any-acl is logically a type of ACE but we don't have an
> > ace-type and the exact same information can IMHO already be conveyed
> > WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
> > need a feature for it.
> > 
> > From what I can tell the any-acl container in the ACE should be used
> > to
> > explicitly signify a match on "any". Think of IOS style ipv4 acl:
> >  permit ip any any
> > 
> > We have to provide a source and destination so this would be a rather
> > explicit mapping of that. However, our structure in this YANG model is
> > just completely different than an IOS command so I don't see why we
> > should try and mimic IOS in the YANg model.
> > 
> > Not specifying a destination IP address means we match on any
> > destination IP address. The same is true for any other field we can
> > match on. Not setting a match implies we don't try to match on that
> > field, thus we allow "any" value. I think the logical continuation of
> > this is that for an ACE with no matches defined at all, we match any
> > packet. I think we can update the text to better explain this.
> > 
> > 
> > 
> >> Otherwise if the ACL type is "any-acl" then this only allows two types
> >> of ACLs to be defined, neither of which seem to be particularly
> >> useful:
> >> (1) An ACL that matches all traffic and permits it, i.e. the same as 
> >> having no ACL at all.
> >> (2) An ACL that matches all traffic and drops.
> >> 
> >> So I think perhaps the answer here is to define neither ACL type 
> >> "any-acl" nor leaf "any". The presumption could be that any ACE that
> >> is
> >> configured to match no fields implicitly matches all packets (because 
> >> all non specified fields are treated as wildcards), and then applies
> >> the
> >> permit/deny rule associated with the ACE. This logic can apply to all 
> >> ACL types.
> > 
> > Yes yes yes :)
> > 
> >   Kristian.
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 


From nobody Tue Nov 28 03:29: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 D77EE127078 for ; Tue, 28 Nov 2017 03:29:40 -0800 (PST)
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, 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=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 zWQLEj05IgKR for ; Tue, 28 Nov 2017 03:29:39 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40122.outbound.protection.outlook.com [40.107.4.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 96CA21200F3 for ; Tue, 28 Nov 2017 03:29:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UK70E9v2hGcVNf9Zty265OMFdUVYy5Jp1fdGY8aw1ag=; b=PohEBpxhsf0dO1uJAeS9Jww7Z6smSMJV8PMf5Nd95Zy8Xyn/iTE+MsnEB1JDV7m08kEVJbSJvW1hKpau5YOA09U5oRNxvGNSkv3iKtXSVg9qJnffny69Y5GQQF4FOsLI/sehm7cjY896GBQlvARuoYg8Hd1EwmJLWSk6SatjdQU=
Received: from VI1PR07MB3069.eurprd07.prod.outlook.com (10.175.242.143) by VI1PR07MB3071.eurprd07.prod.outlook.com (10.175.242.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Tue, 28 Nov 2017 11:29:36 +0000
Received: from VI1PR07MB3069.eurprd07.prod.outlook.com ([fe80::288c:aecd:ef7f:2627]) by VI1PR07MB3069.eurprd07.prod.outlook.com ([fe80::288c:aecd:ef7f:2627%13]) with mapi id 15.20.0282.002; Tue, 28 Nov 2017 11:29:36 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" 
To: "netmod@ietf.org" 
Thread-Topic: Notications in interface model
Thread-Index: AdNiyXW4eQUrjwP+TRmbZEinuN+pWw==
Date: Tue, 28 Nov 2017 11:29:36 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.245.212.27]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3071; 6:GH7jLzWjVqDXIbuJ8oczEapfJDFYVW4Swf9fTtu96jEHeqs7AZv2Ly/Ean8TA4wTcyOO1TCsoh5PWEoUZRcqmQ13wndazVyK8bDO0kdXksE5vOJjIJ6oTloC3UOH4+guKink3u6gVCgKqAGQ43674nOMTirqyr8DNma46I29Kdk4snMw0vf1hrLJJzIUqmT1ZwYHCvfbFK+7qAVR9FRbJp2SqeoyYL38vF8hw/JrUqsAEuIbAUbH+6vsLxlutXbqT2bT45z1fwz/+CBOu7GsfWezWlt9XgiSFPpSb6z9c+qAxoQUlPTbIwjQGCtioyJgwJ1xjiV/f4WZ4gGZuLIloMGvbuHPEBDUHwa9nLkE4RI=; 5:+QGnokWrvBXsC5cPKeZ5FM/37/p94MQY9mN6hHdll0dxsO0arPaViyRLbOP7wB80wf50iFt84+LZQNOqmVgyYhL8SRnwtBAf9VPAVjRmFnETIjM/RP3NHTqsxGjshmPMSN7UZ+54ZuvmWWqoKqkBIlbSbhsHgkvYU/DfCBM+dBY=; 24:Q5q4tn61zAOFENtG8c7fvqs81Jgh6C8m+esrbSFx0OPoKs13EPylQPEgWoQ68c8Yc4MpPfLufEl+Hz6tzGftwD0IlMGgAQknh8X7tY+zv88=; 7:Epu5ozHcnHNfHWoQyD1vH5L9Y537k39tqNnMdxsGUwSrPZChgoJM8qObNbP9duUHg+TK0OaTXfqDpY8+B7K2GskCUKiJggB76L/ZuT7zQ2mvZdfn6KOcYwWBoXx2TU6p6Ynd9RaD98pntBhO6jQH9tF+D6yEQ5OZ71/YV/HNkaWxknxpTimrFQCIyHm1958arb5IGviswM1d1Yleb3EeZ4GGNM2uBKPSgpDTkf/OLztF6iR14TX1Ci50YZpLoqmU
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 17ee104e-1e2e-43f3-00e1-08d536534e16
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258)(49563074); SRVR:VI1PR07MB3071; 
x-ms-traffictypediagnostic: VI1PR07MB3071:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231022)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:VI1PR07MB3071; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3071; 
x-forefront-prvs: 0505147DDB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(366004)(376002)(39860400002)(199003)(189002)(99936001)(6116002)(5660300001)(50986999)(14454004)(5250100002)(54356999)(478600001)(3280700002)(6916009)(33656002)(9326002)(6436002)(6506006)(5640700003)(55016002)(2906002)(25786009)(97736004)(101416001)(7696005)(99286004)(3660700001)(81166006)(102836003)(2900100001)(74316002)(8676002)(3846002)(81156014)(1730700003)(68736007)(86362001)(189998001)(54896002)(9686003)(6306002)(53936002)(8936002)(316002)(106356001)(2501003)(2351001)(105586002)(5630700001)(3480700004)(66066001)(7736002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3071; H:VI1PR07MB3069.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/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00AD_01D36844.8C3D0370"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 17ee104e-1e2e-43f3-00e1-08d536534e16
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 11:29:36.1432 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3071
Archived-At: 
Subject: [netmod] Notications in interface 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, 28 Nov 2017 11:29:41 -0000

------=_NextPart_000_00AD_01D36844.8C3D0370
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00AE_01D36844.8C3D0370"


------=_NextPart_001_00AE_01D36844.8C3D0370
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello,

 

In the interfaces module we notice support of if-mib feature indicating
whether the IF-MIB is supported or not.  Part of this feature is a flag to
indicate whether an SNMP link-up/down trap has to be generated or not.
Looking at the YANG model itself we notice that it does not foresee any
similar capability.  We were wondering whether it has been discussed as part
of the YANG model definition for interfaces to define a general status
change notification in case an interface goes down or comes up and whether
the generation of such a notification can be enabled or disabled?

 

Regards, Bart Bogaert

 

 


------=_NextPart_001_00AE_01D36844.8C3D0370
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hello,
 
In the interfaces module we notice support of if-mib =
feature indicating whether the IF-MIB is supported or not.  Part of =
this feature is a flag to indicate whether an SNMP link-up/down trap has =
to be generated or not.  Looking at the YANG model itself we notice =
that it does not foresee any similar capability.  We were wondering =
whether it has been discussed as part of the YANG model definition for =
interfaces to define a general status change notification in case an =
interface goes down or comes up and whether the generation of such a =
notification can be enabled or disabled?
 
Regards, Bart =
Bogaert
 
 

------=_NextPart_001_00AE_01D36844.8C3D0370--

------=_NextPart_000_00AD_01D36844.8C3D0370
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw
ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT
8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx
HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0
MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0
QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm
cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK
AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7
GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI
gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn
wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9
xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG
CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI
KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA
MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w
HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt
tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r
aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov
L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH
MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ
HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K
eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ
hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE
7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/
PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA
AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT
LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO
b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET
MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk
ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ
88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY
IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo
+lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5
JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB
JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL
6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD
VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br
aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE
MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h
bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45
qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv
ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F
cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6
eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m
NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f
n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO
5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g
MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs
cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74
4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE
CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT
Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0
MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp
YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg
Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB
0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht
KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM
uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA
J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi
nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN
YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F
c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt
9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH
9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr
BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB
FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB
AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI
/fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn
FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos
2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR
x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz
iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P
/jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO
0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L
ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT
MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj
ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew
MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMjgxMTI5MzRaMCMGCSqGSIb3DQEJBDEWBBTkrTWk
WIinlUrclgL8/SbmwdmirzCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t
MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW
Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ
AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS
BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9
xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl
AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG
SIb3DQEBAQUABIIBABi64wXM5s1/c2NYv+Vi/CT8Rakr856Nwb+UQHNeXvot6IhdpTZOaNpKlk8B
dwmTdh0wHCHQWNPejZjLmdvAnXLcqAsFTtGbe6F3l47vogEpF858+Ke7UwcyFpVuc5n2Fl6RUj9D
woLUZ+eZyzJe1uiljO03UOwWeetPP5Fw4R6ozcAVcePrvEm9bdFcRD6kYAd6OB9O9cYNU/QmZzFo
M54MMuHIgwevx0G/7VnDTf/87XHWzJtJAUqSsTj/MhGCaBpsz+v/O6+PfFWe893NLoScrrvhGxM2
MWIhtH7+Q4dHj1kQZmYTxo0+NA0zGmR/xfZEsdAE+lvRRGQqC/SolIQAAAAAAAA=

------=_NextPart_000_00AD_01D36844.8C3D0370--


From nobody Tue Nov 28 04:00: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 1AA2B126D3F for ; Tue, 28 Nov 2017 04:00:15 -0800 (PST)
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=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 siP6wKnBTvbR for ; Tue, 28 Nov 2017 04:00:13 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3563126C2F for ; Tue, 28 Nov 2017 04:00:13 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 0D3011AB359 for ; Tue, 28 Nov 2017 05:00:11 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id fQ061w02T2SSUrH01Q0A8c; Tue, 28 Nov 2017 05:00:11 -0700
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=sC3jslCIGhcA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=AqeI_lbacKu6uIOxffkA:9 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle: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-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=upLYVbimDUG7MiI4J569+Ep+cmiM76DLTxx2wLxuvgs=; b=MTDuUp+mie2EiCbfrOQsSTXWlN da4REYlvg4poAiH14eHiAWOGmpXqNSlrNgdCpvk08JyJtuBmhXbjqYvvTkX9yodz4Q3uIkKjejSHC D8jImONQAFSnp15lqzCinp27K;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:39595 helo=[11.4.0.163]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eJeYY-001CEq-C9; Tue, 28 Nov 2017 05:00:06 -0700
From: Lou Berger 
To: Martin Bjorklund 
CC: , 
Date: Tue, 28 Nov 2017 07:00:03 -0500
Message-ID: <160027f91b8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20171128.105313.1322848757325572415.mbj@tail-f.com>
References:  <20171128.105313.1322848757325572415.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: 1eJeYY-001CEq-C9
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]:39595
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] comment on draft-bierman-netmod-yang-data-ext
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Nov 2017 12:00:15 -0000

Hi Martin,

See below.


On November 28, 2017 4:55:17 AM Martin Bjorklund  wrote:

> Hi,
>
> Lou Berger  wrote:
>> Hi,
>>
>>     I was looking at how yd:yang-data (this draft) relates to
>> rc:yang-data (rfc8040).  The document seems to imply that this draft's
>> extension is a replacement in one place (see abstract) , is supplemental
>> in another (sec 1, plus augment-yang-data example) and perhaps
>> orthogonal in a final (that rc:yang-data is still used/referenced at
>> all).  I think the document should be clear as to it's objective with
>> respect to  rc:yang-data.
>
> Agreed.  It is intended to replace rc:yang-data.  I have fixed the
> example that used rc:yang-data.  Do you think we need any changes to
> section 1 to clarify this?
>

Only that it should also reflect how the update/deprecation discussed below 
is handled.

>> As rc:yang-data is currently defined in a protocol specific way, I (with
>> any/all hats) would prefer to see a definition of yang-data that would
>> work for any protocol that encodes and transports yang.  I also
>> generally think that having two definitions for basically the same
>> mechanism isn't beneficial to implementors of IETF RFCs, so this leads
>> me to suggest that if this document becomes a WG document it should
>> deprecate rc:yang-data.
>
> I assume this would formally mean that this document would "Update"
> RFC 8040,

Yes, this looks right. although it is a bit subject to how the next point 
is addressed

> and then in the document have text that explains that
> rc:yang-data is deprecated?  Or do you suggest that we actually do a
> 8040bis that formally marks the rc:yang-data extension as
> "deprecated", and instead uses yd:yang-data?
>

This is one option. Another is to just update the rc module with 
rc:yang-data as deprecated.

At this point, since the document is still an individual draft, I suggest 
that the authors propose their preference and that the working group weigh 
in during the acceptance and normal WG processing.

Thanks,

Lou

>
> /martin
>



From nobody Tue Nov 28 11:01: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 A011B1270A0; Tue, 28 Nov 2017 11:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14gwpCfB35CK; Tue, 28 Nov 2017 11:01:13 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A25126557; Tue, 28 Nov 2017 11:01:13 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vASIxVB3023456; Tue, 28 Nov 2017 11:01:13 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=DTzpoSNL0tnA1mwTBlBUdKzFRsdSM+cNRyRtOiJ5Xrc=; b=yxNAz6R/oxsefpNYePZYwW32gO0m8nTAgnZCBQ0Qi9Ngqxne4FklRhYw6/7o7iRs+FFe MBIkIrncXcyAnVRUIcvadigIrT400PHaCEMq9oocukJt3UvjAVASUAdXDxCO+uz1NQKL hWVbIkBNqR14TxRjVZwJgnRXxjBcN+t2pPAUdd/UNKmX4v62EBX6NyIsUsLtXbTmSIkS 0g13DscDlHT1FfwpVLZblvfcL43MfMul3q0skXIbANvHl28Ns47UI5erA08KNFhbTTW9 w4L/PUr4MRAuR7cm3SxQlE5Pi3sD0WtN4P0em6wVxUXbred/Q2Pu1y/Ocet+lXZ3OJnu NA== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0055.outbound.protection.outlook.com [216.32.180.55]) by mx0a-00273201.pphosted.com with ESMTP id 2ehdhx007n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Nov 2017 11:01:11 -0800
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.282.3; Tue, 28 Nov 2017 19:01:10 +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.0282.004; Tue, 28 Nov 2017 19:01:10 +0000
From: Kent Watsen 
To: Lou Berger , Martin Bjorklund 
CC: "draft-bierman-netmod-yang-data-ext@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] comment on draft-bierman-netmod-yang-data-ext
Thread-Index: AQHTZ8r67MT+Ws8/z0S8Z2StvrCXRKMpjdOAgAAjb4CAACHXAA==
Date: Tue, 28 Nov 2017 19:01:10 +0000
Message-ID: <07BCAEEA-86FD-4F91-A786-70ACF2A236D9@juniper.net>
References:  <20171128.105313.1322848757325572415.mbj@tail-f.com> <160027f91b8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <160027f91b8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:RM661kEBcHTGUym5KcxxcsC42y2VKARxcYlOJlSSprdyRABL52W89hTHTxbUWLzDB4yd1U+CpoKd6Qq18HiNpERpwB+b8wHriqAPdGTbp26OYQ9oozBwfQkyyHkRkT4v8R3M+KGpaUF5GNy+ZNY4JIuJOHDkU11s8owRHyWm3BbPMl2fJdQi+jpDGCGLpQ/tf+odF6Hud7fvSRmDvFl+vvA4d7NZgJl3iJgsfud28OWEVs3NStNrXdeX6G/voPDDc1zEfPL4Lg0kEmAcHGjTa/xiBkB5EPoFy3eg+EeEw7KshWVrZ90qavQ4/9SegqSUy3eFk2GQJRxFrYarCDd1rPzcGjvGmOBj158L3hzlumw=; 5:YHJttIDNmNHBc6qX3GCd4OgonR2Y7cK10tkYp8FfRVLkFHVnPMzT21tJ1tw0o5mJd4U/u+m+slidNnAPlztmncIYr0VZtM2aBIekyyJF52Gxytwzm1J5y+xwqycgm7S0gy+KKesUvAEPKd4nB1AqLhw1HPLuw8+sSbcdxO1HQFQ=; 24:x/MpN63TxsY8k7DVqBdzBKBrBYku2DBjqfGsFH74Q0rKBhA+G44L0UjYdwX3a5Wm8b0yYHqD9+tM50kVDAS+VSii4Z/sEvl6RKduLRjz9KA=; 7:iP66YKAh27gogiiJSiKZtF7jNkGo8xK4VQQYDOYxbF35ZCYeF5kIA4kqS4ujy2RofVqLZ3uZnTK5UJkIfjeMGRpmssYrvffDiw/VYUfBmszzHnLQxYcakbvDMBuuFRmYDULexzUo6eOTpCMmUql8TmdB7bfS4Vpk6KnevtVXeOhV6R8mFRA09tKdSb0M4uYN0VTsne0B3W+cSoM9Bm5jDc31PuR4cNQvhUKRcXSOhndfwcKOAkKJ59Nyyx/C0huy
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: a36b1161-d2f6-49fc-b970-08d536926363
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:BLUPR05MB276; 
x-ms-traffictypediagnostic: BLUPR05MB276:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011); SRVR:BLUPR05MB276; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB276; 
x-forefront-prvs: 0505147DDB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(366004)(346002)(199003)(24454002)(189002)(3660700001)(106356001)(102836003)(105586002)(6116002)(3846002)(83506002)(3280700002)(81166006)(81156014)(2900100001)(14454004)(7736002)(66066001)(478600001)(6246003)(189998001)(2950100002)(54356999)(99286004)(33656002)(76176999)(50986999)(8676002)(101416001)(305945005)(36756003)(229853002)(25786009)(68736007)(6512007)(6436002)(82746002)(77096006)(6486002)(6506006)(54906003)(110136005)(58126008)(53936002)(4326008)(2906002)(316002)(5660300001)(83716003)(86362001)(230783001)(97736004)(8936002); 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)
x-microsoft-antispam-message-info: juak3PsI9+qJhqVfTf3m5zOEoD2KXDn5t4mQnuQ+hx6lxNqss1/s1E4r8lb6y1hCrFGvUWJVynyXdvSwjFXylQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <2DF0E4B218D3CF4FA2939E9BB8209F48@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: a36b1161-d2f6-49fc-b970-08d536926363
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 19:01:10.2460 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB276
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-28_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711280255
Archived-At: 
Subject: Re: [netmod] comment on draft-bierman-netmod-yang-data-ext
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Nov 2017 19:01:16 -0000

DQpBcyBhbiBhdXRob3IsIEkgcHJlZmVyIGhhdmluZyB0aGlzIGRyYWZ0ICh5YW5nLWRhdGEtZXh0
KSAqdXBkYXRlKiBSRkMgODA0MCB3aXRoIHRleHQgdGhhdCBleHBsYWlucyB0aGF0IHRoZSByYzp5
YW5nLWRhdGEgaXMgZGVwcmVjYXRlZCBhbmQgdGhhdCBtb2R1bGVzIHNob3VsZCB1c2UgdGhlIG5l
dyB5YW5nLWRhdGEgZGVmaW5pdGlvbiBpbnN0ZWFkLiAgDQoNCkFzIE5FVENPTkYgY28tY2hhaXIs
IEkgaW1hZ2luZSB0aGF0IHNvbWUgZnV0dXJlIHJmYzgwNDBiaXMgd2lsbCByZW1vdmUgdGhlIHJj
OnlhbmctZGF0YSBkZWZpbml0aW9uLCBidXQgSSBkb24ndCB0aGluayBpdCBpcyB1cmdlbnQgdG8g
ZG8gbm93Lg0KDQpLZW50DQoNCg0KLS0NCg0KSGkgTWFydGluLA0KDQpTZWUgYmVsb3cuDQoNCg0K
T24gTm92ZW1iZXIgMjgsIDIwMTcgNDo1NToxNyBBTSBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFp
bC1mLmNvbT4gd3JvdGU6DQoNCj4gSGksDQo+DQo+IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5u
ZXQ+IHdyb3RlOg0KPj4gSGksDQo+Pg0KPj4gICAgIEkgd2FzIGxvb2tpbmcgYXQgaG93IHlkOnlh
bmctZGF0YSAodGhpcyBkcmFmdCkgcmVsYXRlcyB0bw0KPj4gcmM6eWFuZy1kYXRhIChyZmM4MDQw
KS4gIFRoZSBkb2N1bWVudCBzZWVtcyB0byBpbXBseSB0aGF0IHRoaXMgZHJhZnQncw0KPj4gZXh0
ZW5zaW9uIGlzIGEgcmVwbGFjZW1lbnQgaW4gb25lIHBsYWNlIChzZWUgYWJzdHJhY3QpICwgaXMg
c3VwcGxlbWVudGFsDQo+PiBpbiBhbm90aGVyIChzZWMgMSwgcGx1cyBhdWdtZW50LXlhbmctZGF0
YSBleGFtcGxlKSBhbmQgcGVyaGFwcw0KPj4gb3J0aG9nb25hbCBpbiBhIGZpbmFsICh0aGF0IHJj
OnlhbmctZGF0YSBpcyBzdGlsbCB1c2VkL3JlZmVyZW5jZWQgYXQNCj4+IGFsbCkuICBJIHRoaW5r
IHRoZSBkb2N1bWVudCBzaG91bGQgYmUgY2xlYXIgYXMgdG8gaXQncyBvYmplY3RpdmUgd2l0aA0K
Pj4gcmVzcGVjdCB0byAgcmM6eWFuZy1kYXRhLg0KPg0KPiBBZ3JlZWQuICBJdCBpcyBpbnRlbmRl
ZCB0byByZXBsYWNlIHJjOnlhbmctZGF0YS4gIEkgaGF2ZSBmaXhlZCB0aGUNCj4gZXhhbXBsZSB0
aGF0IHVzZWQgcmM6eWFuZy1kYXRhLiAgRG8geW91IHRoaW5rIHdlIG5lZWQgYW55IGNoYW5nZXMg
dG8NCj4gc2VjdGlvbiAxIHRvIGNsYXJpZnkgdGhpcz8NCj4NCg0KT25seSB0aGF0IGl0IHNob3Vs
ZCBhbHNvIHJlZmxlY3QgaG93IHRoZSB1cGRhdGUvZGVwcmVjYXRpb24gZGlzY3Vzc2VkIGJlbG93
IA0KaXMgaGFuZGxlZC4NCg0KPj4gQXMgcmM6eWFuZy1kYXRhIGlzIGN1cnJlbnRseSBkZWZpbmVk
IGluIGEgcHJvdG9jb2wgc3BlY2lmaWMgd2F5LCBJICh3aXRoDQo+PiBhbnkvYWxsIGhhdHMpIHdv
dWxkIHByZWZlciB0byBzZWUgYSBkZWZpbml0aW9uIG9mIHlhbmctZGF0YSB0aGF0IHdvdWxkDQo+
PiB3b3JrIGZvciBhbnkgcHJvdG9jb2wgdGhhdCBlbmNvZGVzIGFuZCB0cmFuc3BvcnRzIHlhbmcu
ICBJIGFsc28NCj4+IGdlbmVyYWxseSB0aGluayB0aGF0IGhhdmluZyB0d28gZGVmaW5pdGlvbnMg
Zm9yIGJhc2ljYWxseSB0aGUgc2FtZQ0KPj4gbWVjaGFuaXNtIGlzbid0IGJlbmVmaWNpYWwgdG8g
aW1wbGVtZW50b3JzIG9mIElFVEYgUkZDcywgc28gdGhpcyBsZWFkcw0KPj4gbWUgdG8gc3VnZ2Vz
dCB0aGF0IGlmIHRoaXMgZG9jdW1lbnQgYmVjb21lcyBhIFdHIGRvY3VtZW50IGl0IHNob3VsZA0K
Pj4gZGVwcmVjYXRlIHJjOnlhbmctZGF0YS4NCj4NCj4gSSBhc3N1bWUgdGhpcyB3b3VsZCBmb3Jt
YWxseSBtZWFuIHRoYXQgdGhpcyBkb2N1bWVudCB3b3VsZCAiVXBkYXRlIg0KPiBSRkMgODA0MCwN
Cg0KWWVzLCB0aGlzIGxvb2tzIHJpZ2h0LiBhbHRob3VnaCBpdCBpcyBhIGJpdCBzdWJqZWN0IHRv
IGhvdyB0aGUgbmV4dCBwb2ludCANCmlzIGFkZHJlc3NlZA0KDQo+IGFuZCB0aGVuIGluIHRoZSBk
b2N1bWVudCBoYXZlIHRleHQgdGhhdCBleHBsYWlucyB0aGF0DQo+IHJjOnlhbmctZGF0YSBpcyBk
ZXByZWNhdGVkPyAgT3IgZG8geW91IHN1Z2dlc3QgdGhhdCB3ZSBhY3R1YWxseSBkbyBhDQo+IDgw
NDBiaXMgdGhhdCBmb3JtYWxseSBtYXJrcyB0aGUgcmM6eWFuZy1kYXRhIGV4dGVuc2lvbiBhcw0K
PiAiZGVwcmVjYXRlZCIsIGFuZCBpbnN0ZWFkIHVzZXMgeWQ6eWFuZy1kYXRhPw0KPg0KDQpUaGlz
IGlzIG9uZSBvcHRpb24uIEFub3RoZXIgaXMgdG8ganVzdCB1cGRhdGUgdGhlIHJjIG1vZHVsZSB3
aXRoIA0KcmM6eWFuZy1kYXRhIGFzIGRlcHJlY2F0ZWQuDQoNCkF0IHRoaXMgcG9pbnQsIHNpbmNl
IHRoZSBkb2N1bWVudCBpcyBzdGlsbCBhbiBpbmRpdmlkdWFsIGRyYWZ0LCBJIHN1Z2dlc3QgDQp0
aGF0IHRoZSBhdXRob3JzIHByb3Bvc2UgdGhlaXIgcHJlZmVyZW5jZSBhbmQgdGhhdCB0aGUgd29y
a2luZyBncm91cCB3ZWlnaCANCmluIGR1cmluZyB0aGUgYWNjZXB0YW5jZSBhbmQgbm9ybWFsIFdH
IHByb2Nlc3NpbmcuDQoNClRoYW5rcywNCg0KTG91DQoNCj4NCj4gL21hcnRpbg0KPg0KDQoNCg0K
DQo=


From nobody Tue Nov 28 11:06: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 594CB128D2E for ; Tue, 28 Nov 2017 11:06:45 -0800 (PST)
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 1sjhdohACbwG for ; Tue, 28 Nov 2017 11:06:44 -0800 (PST)
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 149AA128D16 for ; Tue, 28 Nov 2017 11:06:44 -0800 (PST)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id EABB01E074F for ; Tue, 28 Nov 2017 12:06:42 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id fX6f1w00S2SSUrH01X6iXQ; Tue, 28 Nov 2017 12:06:42 -0700
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=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA: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:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YC5Qp95XOQVyrlklaQhaTsRKvEnm9RljdtEdz+Wc1GI=; b=hGWdrX6OZ9fgbUdTIy+6vZVtG/ S+NlLhvtvs+UNhvfdfAYoZBxxc0J7tvv8PBUyVxnLkG7sU6ju7XggYlGlYPPd9GkiU184i2bJs6DN YJ9FdM6m9ESXgwogUDrLI6eKg;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:54004 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eJlDL-002l2Z-3J; Tue, 28 Nov 2017 12:06:39 -0700
From: Lou Berger 
To: Andy Bierman , Martin Bjorklund , Jie Dong , Dan Romascanu 
Cc: NetMod WG Chairs , NetMod WG 
Message-ID: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
Date: Tue, 28 Nov 2017 14:06:37 -0500
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
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: 1eJlDL-002l2Z-3J
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]:54004
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Regarding IPR on draft-ietf-netmod-entity-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: Tue, 28 Nov 2017 19:06:45 -0000

Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

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

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

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

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

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

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

Thank you,
NetMod WG Chairs

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



From nobody Tue Nov 28 11:21: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 F1DA9126CF9; Tue, 28 Nov 2017 11:20:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAI5zh6vpZ5O; Tue, 28 Nov 2017 11:20:57 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 1E1851200CF; Tue, 28 Nov 2017 11:20:53 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id u42so1287166qte.7; Tue, 28 Nov 2017 11:20:53 -0800 (PST)
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=1Bkz3q4fNtRjFmFN8z5aJTfIkjo7h4AWJSf54iZ15kM=; b=Ka+3Lsn4UMU71DZMRV/f0yP91RAJyqVOqcWdsIpcm/OhulWzifTwwiN8ZQX9cz+UMS 6I+G1LqM7zyj4wNgs7Eps8e05CGsptjxs7FrF2AHMIi4SMqU0qjSH0TgcQXjFQX4FtPJ jw0mBwU5SJ8X0O8q0hwJt1pW6M8oOtwWuqgrRdNVrKgJcsef2j+8nt8vnhoW3OPZRlBQ EF3RC2V/njwV6KqJX1cjdl0Pk1g0eEdMFwd9T5qYkcXzF8CNoOk/58SXZ0ouybWLyNpq 6FpDIOLjHNmwa/fYIuNiDvPPBaQcFvGycySqhuJXisDsutxSBmsjVRMY9k4KSVWlJze9 hEWA==
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=1Bkz3q4fNtRjFmFN8z5aJTfIkjo7h4AWJSf54iZ15kM=; b=VRmjA8Mlr9YBMGUmnTJ16nGeVY6xIbSWfOEHvUdR/LeRT0PnG7I03/iFZdKSesZW8b SRVkGs5bwvfIbLUCt4jkmNWnR6Wtow5SuMQsgxcKTVbGAAPALl9clwfoSQeFA1q8gZSD 6dixu0J0dO5p4SP3IhjV9AU+bEpXJ2/+L/O4W/4EJjkyrb197r4iSDy6xxPAyBkXZdAz dS7b9jOEUVKXNcPF8FTMlOOgQLHhHb8MteylW2PUObsqDzA8+ALmfmF1mJGwB/L8DwUW F8GLLXwu4jB7x7X5ZX/Ip4CthyF7GnRFWOwDRaMZrAytqJROwiMN7nEW++XPJ73ESGcs dxzA==
X-Gm-Message-State: AJaThX6aJbv47yrEWpufCPbQXuS+nDpqjqA7WrkYRBoPksEKeSfE6v+q RLWt79Cyl2qIPS9bGIkX0PVHMpFa0dqfRREXkqo=
X-Google-Smtp-Source: AGs4zMa5mApt4bUiDM9ic9Vea5j/n00uYWKcTfc+xIpV/N+7ynpwL+aGvs+cyiepfqfZc57c4i+v7xVGZhyazPyCS/s=
X-Received: by 10.200.15.2 with SMTP id e2mr381024qtk.69.1511896852240; Tue, 28 Nov 2017 11:20:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.106.166 with HTTP; Tue, 28 Nov 2017 11:20:51 -0800 (PST)
In-Reply-To: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
References: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
From: Dan Romascanu 
Date: Tue, 28 Nov 2017 21:20:51 +0200
Message-ID: 
To: Lou Berger 
Cc: Andy Bierman , Martin Bjorklund , Jie Dong ,  NetMod WG Chairs , NetMod WG 
Content-Type: multipart/alternative; boundary="94eb2c0399b4d09d51055f0feafa"
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-entity-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: Tue, 28 Nov 2017 19:20:59 -0000

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

No, I'm not aware of any IPR that applies to this draft.

Regards,

Dan


On Tue, Nov 28, 2017 at 9:06 PM, Lou Berger  wrote:

> Authors, Contributors, WG,
>
> As part of the preparation for WG Last Call:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> NetMod WG Chairs
>
> PS Please include all listed in the headers of this message in your
> response.
>
>
>

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


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

Regards,

Dan


On Tue, Nov 28, 2017 at 9:0=
6 PM, Lou Berger <lberger@labn.net> wrote:
Authors, Contributors, WG,



As part of the preparation for WG Last Call:



Are you aware of any IPR that applies to drafts identified above?



Please state either:



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

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo=
t;

or

"No, the IPR has not been disclosed"



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

appropriate.



If you are listed as a document author or contributor please answer the

above by responding to this email regardless of whether or not you are

aware of any relevant IPR. This document will not advance to the next

stage until a response has been received from each author and listed

contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S<=
br>
TO LINES.



If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under

the IETF IPR rules which encourages you to notify the IETF if you are

aware of IPR of others on an IETF contribution, or to refrain from

participating in any contribution or discussion related to your

undisclosed IPR. For more information, please see the RFCs listed above

and

http://trac.tools.ietf.org/=
group/iesg/trac/wiki/IntellectualProperty.



Thank you,

NetMod WG Chairs



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

response.









--94eb2c0399b4d09d51055f0feafa--


From nobody Tue Nov 28 11:29: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 2BE82126BF6; Tue, 28 Nov 2017 11:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnXR6E5XkbrQ; Tue, 28 Nov 2017 11:29:07 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A102126D0C; Tue, 28 Nov 2017 11:29:06 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vASJSco4014601; Tue, 28 Nov 2017 11:29:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=xfngle+UJsLoIeq9i2lb5c2ksG8baEx/LhzjYI3nzG4=; b=B9QQKQfA1GpZNEpYtawKImPG0eOglIXkbiNzKuUCYZct1V7QInkC+oiEyeH98kLvDBS6 1FQAp53Utii2Tr04l/INPIKz3WGDbJ9iZoH2u/IJ9v+Owyqa3itGF9ijZDioet57MeIq /q+NPY97Zy1u9NvY6/eVAjGJk8IOMMOTOopg85nnr91xKTpUPimMT2I/VSMS9NEOrn9q ZduUKjWa7lR4CXQGzi1udQYKCVdSppHTW6DH1cTsGQ3TIVXBkoJ3s+ozFs3bIe4G1zMO HC4l9x9o9moqjnj8ilBMaLRi065Ds1NhdZZo08R29L9K5XzX100iL7+Oc+AvXFgclEPM CA== 
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0024.outbound.protection.outlook.com [216.32.180.24]) by mx0a-00273201.pphosted.com with ESMTP id 2ehdhx01wc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Nov 2017 11:29:06 -0800
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.282.3; Tue, 28 Nov 2017 19:29: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.0282.004; Tue, 28 Nov 2017 19:29:04 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7223bis-00
Thread-Index: AQHTaH8mwis2iZPDB0aqvQnmsEUf+w==
Date: Tue, 28 Nov 2017 19:29:04 +0000
Message-ID: <10B5698A-BC7B-432E-A931-9069FA7BB03C@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.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:YH40p8x/z/DSrApJaPje/znjQazWXRLw+lsbGIix7/4COkA7GvC3NBQwdZwG4mbPneJ+UWY+8J+oEknwNmH6G1c4n9bChj3X19rDM4UxHGx8nQLo9dln0D6fn3AHsZrmpEDkEEUiU+AyXbX2RakJf6jyV6CrxV5GV6wwg36uvcOmoGqN7GI9BnomkiJcAzbH2jknLHFcMsH9/nBevzWQPYJRRDDjPIBc8BDeW3OngQMVyj7roSLgvA4c/Rs07KWI4UAQXj2Rt5ihKcdEPCPTRF6L9ZW9hqX3lzfmZBy47/dp4D1MlulxTSFJKi02WKG47Myh8FN8BDVXPODkyl0+UQ==; 5:MF8itYLWSDempyEo7umdJcrNNk5h5VbM8DEUoB3TPXREBWMxHU4OTxxZ2IaFRf/0hA3Ko4di8pVc8OfpbwSwJYjtiWyWfRVeVVHRc6rvtlP8IqU4MMCLtJzwl1WNterog7Jc1Hc8hjJNroIEDd2lBF+mi/Sy6zHzJ4qN5NqjiG0=; 24:SrRYJrKSArFxSQdDs/gP+a3ID9kAbiew1X6l7EhWCKRx6DZUp2iflyiIUqdMcLkf+JbAQzl2yoe54ye0egQF+qNQIAlxVWR9PcUhT3X/69o=; 7:8WlkhE3VMHxrD9AKAL2r4uiNGx1CLoFNcEddmJBWBjRzQZUG+b2qEP0Xk8G8O3yyaIGHRCTwxSEfzCnNDIeM8I7WVwG33JtF2HXIvjzuaNtCrKt9UewDoSkcfbd6E5FnrspcC9KeFtqNH5N3JcoqDBNbfTzS1dpef8Q6hy2Qjxkem1/3HDn3SlozD8OLFHkKgyCDQAqiCtqXR97iEwqKOT5/qjCD3nolXd6yq2oJmKYWFDtCFT5sXglsvKXQTh1v
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 92ca0ae2-371f-4391-eda3-08d53696491f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:BLUPR05MB275; 
x-ms-traffictypediagnostic: BLUPR05MB275:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231022)(3002001)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB275; 
x-forefront-prvs: 0505147DDB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(366004)(199003)(189002)(2501003)(66066001)(82746002)(97736004)(36756003)(316002)(2351001)(77096006)(230783001)(83716003)(6486002)(6506006)(106356001)(2900100001)(2906002)(6436002)(105586002)(33656002)(3660700001)(58126008)(189998001)(3280700002)(5640700003)(6306002)(8676002)(7736002)(305945005)(83506002)(25786009)(3846002)(8936002)(53936002)(6512007)(6116002)(450100002)(6916009)(86362001)(101416001)(4326008)(81166006)(99286004)(1730700003)(14454004)(966005)(5660300001)(54356999)(50986999)(81156014)(68736007)(478600001)(102836003); 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)
x-microsoft-antispam-message-info: DV5IlkvDxlXeaaYVA4Np82BWs+EkJnY1bz7zCIA6BXJQ05fMPVujNKjWixyAEcTywZ9U1sfk3BopOxEXbAa1mA==
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: 92ca0ae2-371f-4391-eda3-08d53696491f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 19:29:04.1679 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-28_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711280261
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-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: Tue, 28 Nov 2017 19:29:09 -0000

QWxsLA0KDQpUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u
DQpkcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAwLg0KDQpQbGVhc2UgcmVjYWxsIHRoYXQg
dGhpcyB1cGRhdGUncyBpbnRlbnRpb24gaXMgdG8gDQptb2RpZnkgdGhlIFlBTkcgbW9kdWxlIHRv
IGJlIGluIGxpbmUgd2l0aCB0aGUgTk1EQQ0KZ3VpZGVsaW5lcyBbMV0uICBSZXZpZXdpbmcgdGhl
IGRpZmYgYmV0d2VlbiB0aGUgdHdvDQpkcmFmdHMgWzJdIHNob3VsZCByZXZlYWwganVzdCB0aGlz
Lg0KDQpUaGUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBvbiBEZWNlbWJlciAxMi4NClBs
ZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3QuDQoNClBv
c2l0aXZlIGNvbW1lbnRzLCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50DQphbmQg
YmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24iLCBhcmUgd2VsY29tZSENClRoaXMg
aXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KDQpbMV0gaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRzZHQtbm1kYS1ndWlkZWxpbmVzLTAxDQpbMl0g
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtcmZj
NzIyM2Jpcy0wMC50eHQNCg0KVGhhbmsgeW91LA0KTmV0bW9kIENoYWlycw0KDQoNCg==


From nobody Tue Nov 28 11:43: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 7F929126C83; Tue, 28 Nov 2017 11:43:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1mfdBXh1Y2A; Tue, 28 Nov 2017 11:43:27 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E95E1200CF; Tue, 28 Nov 2017 11:43:27 -0800 (PST)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vASJdDV5010158; Tue, 28 Nov 2017 11:43:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=5/qOgIes+sINge6GH1WGx8aYC58Gh2LS3u31NrW55HQ=; b=u46sTbYFCRWgWprQGHl+s3mcu3ZY262lfGG/rg53yC6XcwtQMNXld0ncWt/Dz4w8iDhK nS8iyi6HsuFnMdbUdrg0i+kHNEtgI/E69ursl1j6NdKI2fep6+AyHOlTo3QUZ6QGCWWo eRiv+MIoyfUKnCDtQK/lWvkJ+SGEy4x+6xPO9JHifWglBy3BNTijaDmDvvUe+8MuVB5c NLiVY97TFWDaRvxO4iUyQNvsaqJqryepnKEgexY4yMEjXiGPZmYhnBw7h4ZHSofQUHY+ niJm60gqsMZAI5kS6LqHoGO4YhTDfQU4lGo4EHqHywwP8Tw51c1rwjPOeiP8YWIqiw6E ug== 
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0024.outbound.protection.outlook.com [207.46.163.24]) by mx0b-00273201.pphosted.com with ESMTP id 2ehdw2r1nj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Nov 2017 11:43:26 -0800
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.282.3; Tue, 28 Nov 2017 19:43:25 +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.0282.004; Tue, 28 Nov 2017 19:43:25 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7277bis-00
Thread-Index: AQHTaH8uQPbcvjqNt0+Zr1pndKQN96Mp3X4A
Date: Tue, 28 Nov 2017 19:43:24 +0000
Message-ID: 
References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net>
In-Reply-To: <296363B7-40FF-4FAC-94F9-A7655CD0D111@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.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:b03MzzA94P24y9DzrOqIykm5S99a4CSvoPae69y85Ddpz/OphBa65EkhXrAnTZu3cjdL6iQR1XSIet+pdZouAZKbX4Mftg0z+6hjXlgjYfKxgVFa5g5q03Rzid6BYf1SAb5rikJEtzHDiH6FzbWDutIVnkfx4wDvmIu4BuY1dmTJGx8N3bowRQBI2FwPzMsqRqzwnBXHZdjIgTZemYDA2rZYttEteZxItyjfkegfyOnPIuA6Y1HYJAJmjqur0i9st6hO9gR6l0HC8pkROE+db8oRVRqqXik00J9UPpVstyMabrsb+gWXPkBALlq0q0n0TONU2+rjEV6kaFzNxD5xyg==; 5:LNz/1fDjDiZr16HqVUbu6v8tjYfR+OfqM/Q+YapIcD97ru5n3OyjnhmvQOsmwjTa+1wk8OkEznuq4gX1cz0oWXhoU2fSeeP3ru4PD2051IkVp6c8ogIHh0GR0KM3/N9cKlkCDT63pxW3LgnFADWMawJJQnY4GrQVCNVlb9xj1oI=; 24:8M0ZUKEmRK9vWx4tXSJUp52OKaovdqZoi9Oxvdkdim1r+0FO8IdnIkVonz/0/tqZ1rN6enA7g6KrbMeLtjrnb1suNzHVn7cWHWK43yGxY20=; 7:T5c79XEhyb3T3IHp9IKoAQ/XMUGFNooTONZFouM5gv7J0bgdHUF1LVEp22ZSlH9RLVDjPZY9RD+n+eAlaGqter+d9VON3MDyY/m/w5oqxpiM6KPjaO463h1tPnWZKGmLSd9MLRQVm4tG6kZGzxnTnalXL1bwsd5OK5btL+PQW4SQeJ+UcIHdkQQN6KA1AYjM+IuvyVKgjhh1K4Qo54m/HxraU6zWDzvz8E+ofc48KU3juOM8FFtYyDlgkrBsh42R
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 57c88f79-0f4d-4c11-61e0-08d536984a2a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:BLUPR05MB273; 
x-ms-traffictypediagnostic: BLUPR05MB273:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(3231022)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB273; 
x-forefront-prvs: 0505147DDB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(366004)(39860400002)(199003)(189002)(86362001)(1730700003)(2900100001)(53936002)(58126008)(189998001)(33656002)(6512007)(101416001)(77096006)(478600001)(5660300001)(230783001)(66066001)(81166006)(81156014)(6306002)(8676002)(3846002)(2501003)(316002)(83716003)(102836003)(6116002)(105586002)(3280700002)(106356001)(2950100002)(6916009)(8936002)(6436002)(36756003)(3660700001)(14454004)(83506002)(54356999)(450100002)(6506006)(76176999)(7736002)(50986999)(25786009)(5640700003)(966005)(99286004)(6486002)(4326008)(2906002)(2351001)(97736004)(305945005)(68736007)(82746002); 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)
x-microsoft-antispam-message-info: JuQDN6cvr3Px3ERU7E8XExqgn9I8FySPLwkmxlBB4jRmwC4UK7SQnwE/G92Lx1LHv2cADdo4eMU6XsBy/cHKNA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <8B4903F562E83A4E9AD83604DF469D1C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 57c88f79-0f4d-4c11-61e0-08d536984a2a
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 19:43:24.8763 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-28_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711280263
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-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: Tue, 28 Nov 2017 19:43:29 -0000

W3Jlc2VuZGluZ10NCg0KDQpBbGwsDQoNClRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBn
cm91cCBsYXN0IGNhbGwgb24NCmRyYWZ0LWlldGYtbmV0bW9kLXJmYzcyNzdiaXMtMDAuICANCg0K
UGxlYXNlIHJlY2FsbCB0aGF0IHRoaXMgdXBkYXRlJ3MgaW50ZW50aW9uIGlzIHRvIA0KbW9kaWZ5
IHRoZSBZQU5HIG1vZHVsZSB0byBiZSBpbiBsaW5lIHdpdGggdGhlIE5NREENCmd1aWRlbGluZXMg
WzFdLiAgUmV2aWV3aW5nIHRoZSBkaWZmIGJldHdlZW4gdGhlIHR3bw0KZHJhZnRzIFsyXSBzaG91
bGQgcmV2ZWFsIGp1c3QgdGhpcy4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMg
b24gRGVjZW1iZXIgMTIuDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBuZXRtb2Qg
bWFpbGluZyBsaXN0Lg0KDQpQb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQg
dGhpcyBkb2N1bWVudA0KYW5kIGJlbGlldmUgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwg
YXJlIHdlbGNvbWUhDQpUaGlzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0
aG9ycy4NCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kc2R0LW5tZGEt
Z3VpZGVsaW5lcy0wMQ0KWzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy
YWZ0LWlldGYtbmV0bW9kLXJmYzcyNzdiaXMtMDAudHh0DQoNClRoYW5rIHlvdSwNCk5ldG1vZCBD
aGFpcnMNCg0KDQoNCg==


From nobody Tue Nov 28 12:11: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 A477D126BFD; Tue, 28 Nov 2017 12:11:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001,  URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM-FH1WM46NW; Tue, 28 Nov 2017 12:11:07 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F131204DA; Tue, 28 Nov 2017 12:11:06 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vASJSYJt014581; Tue, 28 Nov 2017 11:29:18 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=RbJdRye2uw0OsLpPp8EsMOUbHImaM/mDW9gOcYYzS20=; b=bf+OStIU7SzJtFjP8CP2YIPivnQtolnc5Yd/jK19bN2F9PcGyVPLK0stb8yTkV/2eFfp 38kD9QrxZIfDhgJku5Xqoh5s2g9fTQn3S/cmSZb5Vc8mbcBCBqJmRHUKBRt/AL3iuX6B GPk7GMA5g+2erxpmGK4YFJ8E22m50n3PGCA++eQ6FoHOs+sImu2f/BWXpOiNmarLxS5D z8D078+6ENFcAL+JP7XwZj+Neh/s8B5QfDNDh1oul4I0HrQ31e+DrELXVrlCN6DZy2G6 Mp/8NIOySKAlgVC1EcTI5L+qawyZAyYJ14lNq+hbr3jc7lt7Lc/MTEqccdwUXtHLsG1v zA== 
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0017.outbound.protection.outlook.com [216.32.180.17]) by mx0a-00273201.pphosted.com with ESMTP id 2ehdhx01x3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Nov 2017 11:29:18 -0800
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.282.3; Tue, 28 Nov 2017 19:29:17 +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.0282.004; Tue, 28 Nov 2017 19:29:17 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7277bis-00
Thread-Index: AQHTaH8uQPbcvjqNt0+Zr1pndKQN9w==
Date: Tue, 28 Nov 2017 19:29:17 +0000
Message-ID: <296363B7-40FF-4FAC-94F9-A7655CD0D111@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.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:6QFFgdl/RBFt5WVkE0ZKYU9WR6PfiJJcqBHvLMx7OgChTpcPYlUbBeknGYGCabKEmu+6ak00VK102YBGwTEETCXYlAuQ/lz18ftwFUC9rOKaKdwlvIWnpD1/1WPCcSfjOLuRUq070k0DW0N++31Hrxq/sSKJXMSzBIVWPnoYsJJbcKo/9DwE8pFv4AJmCDLsS6cnvbrsmot0M4FhcOAqD/rNgIYO1b/vtuQbalIJebcEP0n1XdWzjllm4EwABxGhrAQEMxoulriq9zlC6k7si7mdvncahC/qnmRG8bY7OY0WTe0XTrmQxwaC8rPq9aLLBpdxpAfz/4YJ3Eaq4h/zkQ==; 5:2WkZX6T0CWfzo2BjD145zj9MAAIVLeDNdBa+G5Q2FQFi0lKZtq49T50bkPB9nLbzIGj1T32Fd8chHnPEsA5adVnKBfQveIXagt4kQv2pJ6As/SQCIb1Eqwm2bUAJTJ5dMP1HiDb7NbPUKL7Irxv8DBziEwglzdLqrlUeDenjups=; 24:TWdigpiEHNxY2f5lRs95nfr6ha+KQmwkUCDjeqaiPowehZvgT20rqOOmbbnbK3fTDkdB1/5dDvcyRhbBr2aU7i3GK4Wh/2QflkpVnidaO4A=; 7:GI+S5C4eI7kqGPf0vfO5A7kXnLKRrxDZ9UJxw1QzV6Ac9fD2338GAoHPoANkdZ0MJklAfMEDKtLRFUyCHb6iT8dg8KiBJ60UQ4ZUJpOFCp6XqX6F0wCjmBErmLnJk+lDoBqGeerSVm76CFJxUVNS4YLDO00uGXYj0z7uN69burckDkA3LLrF8rcxfombdYJke2q2oOiCWIsKdh6YJXDDQtT5/gwxkdW/DxO43qNdG/YlL6eg2pTCpXsmLNJAY5z3
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: be98cb51-95ba-4115-ee63-08d5369650e1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:BLUPR05MB275; 
x-ms-traffictypediagnostic: BLUPR05MB275:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231022)(3002001)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB275; 
x-forefront-prvs: 0505147DDB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(366004)(199003)(189002)(2501003)(66066001)(82746002)(97736004)(36756003)(316002)(2351001)(77096006)(230783001)(83716003)(6486002)(6506006)(106356001)(2900100001)(2906002)(6436002)(105586002)(33656002)(3660700001)(58126008)(189998001)(3280700002)(5640700003)(6306002)(8676002)(7736002)(305945005)(83506002)(25786009)(3846002)(8936002)(53936002)(6512007)(6116002)(450100002)(6916009)(86362001)(101416001)(4326008)(81166006)(99286004)(1730700003)(14454004)(966005)(5660300001)(54356999)(50986999)(81156014)(68736007)(478600001)(102836003); 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)
x-microsoft-antispam-message-info: dCgMpUpS2/IR5RTlTFE6Rq83zz9B1eqclB+r3vIR4PsJyxSrAvEFNvuNICYuR4zGNPblPSPjvVBQcnOgXVnNeQ==
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: be98cb51-95ba-4115-ee63-08d5369650e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 19:29:17.0427 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB275
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-28_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711280261
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-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: Tue, 28 Nov 2017 20:11:09 -0000

QWxsLA0KDQpUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u
DQpkcmFmdC1pZXRmLW5ldG1vZC1yZmM3Mjc3YmlzLTAwLiAgDQoNClBsZWFzZSByZWNhbGwgdGhh
dCB0aGlzIHVwZGF0ZSdzIGludGVudGlvbiBpcyB0byANCm1vZGlmeSB0aGUgWUFORyBtb2R1bGUg
dG8gYmUgaW4gbGluZSB3aXRoIHRoZSBOTURBDQpndWlkZWxpbmVzIFsxXS4gIFJldmlld2luZyB0
aGUgZGlmZiBiZXR3ZWVuIHRoZSB0d28NCmRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0IHRo
aXMuDQoNClRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIG9uIERlY2VtYmVyIDEyLg0K
UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCg0K
UG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQNCmFu
ZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KVGhp
cyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuDQoNClsxXSBodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMtMDENClsy
XSBodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1y
ZmM3Mjc3YmlzLTAwLnR4dA0KDQpUaGFuayB5b3UsDQpOZXRtb2QgQ2hhaXJzDQoNCg==


From nobody Tue Nov 28 13:28: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 DEF51124205 for ; Tue, 28 Nov 2017 13:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5EFCPRoEAou for ; Tue, 28 Nov 2017 13:28:48 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067051275C5 for ; Tue, 28 Nov 2017 13:28:48 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id f18so1460741lfg.8 for ; Tue, 28 Nov 2017 13:28:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t+CuQFjEkRIAx81+/Jbuo4q8yaTI34Fmmtv5yO7O5jU=; b=xQ0PfaN47nxsB8Rh9BEisyDODajpLKE1CnsSU7rNkvzN4hhBXiX3zRCSgZoX9BRUgq WQ/9VBrl/sNJG10Zpq0HwmZ99iF9PpVkcD1dexQH0bmLlAc471xNaW0ewQ1whk51grLc kiBr7NHA6YuRrEqpZ0GPrDLV3ngAjSw6WEQLeoTS2yzoGuiICrOI+jbPX/1y/sy/s8Ii Vtc6V9tVr9Ibu6dziXoE3ZMhlUlPw8i6LpZCtiPY1t2deXxx8bbUEljNrRJnSe8k1s11 +64XsWsoMEthPV1pWZo9uo6JHw7ZfcBlxVxTyuzI7oe26bi6I03LvhnR9KUgJAUfZfQj VW2Q==
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=t+CuQFjEkRIAx81+/Jbuo4q8yaTI34Fmmtv5yO7O5jU=; b=qQfs+OPnebEhDxvuNPLUsibZHYOXjROCjSfmprdXz65GAHg7w3UZBqlq3HSh12BJgX Mn8sOIpKGbIPthKuUf4RZMBmJCtahtwEMV/WzgtIoK2hkE8lazdmtFdxgbkH9leC6/+j l6xQvtCfx2UOrT/eldh3e1woj9A3AMVNX2rSv2BxWbCLhvwf46n2TO0loi4luQVCcoe5 BxkP3yHrb+VsLs4QVPtcpLm/sEhb6U3fqlhv4DrYhR7tctBvJlReSjMhrTv/8uJ7CLBj Vh2cNQ415sUvIXYlL56j5tSnBPHuE3Z3xOJ6HIQhcYqS6jf8JKmrVfc725VmXKA6tJL2 KVaQ==
X-Gm-Message-State: AJaThX66u6U7071S19qcjorfrQgF4V3yxQKr763aU8yT3gISzyyNAJY9 9ht+pCv5m8Dn74dR+dEhFjxW2TUNr9x+hgzwcveIww==
X-Google-Smtp-Source: AGs4zMZ1Q7IkwctcEqc2W4uY1bBKZxi9c3aVQ3DyWZFjXyNPqC+FfKvoKrQCHTd2d5SdytwLscqyvzqsOhEj9cdq+tE=
X-Received: by 10.46.17.153 with SMTP id 25mr268801ljr.36.1511904526307; Tue, 28 Nov 2017 13:28:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Tue, 28 Nov 2017 13:28:45 -0800 (PST)
In-Reply-To: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
References: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
From: Andy Bierman 
Date: Tue, 28 Nov 2017 13:28:45 -0800
Message-ID: 
To: Lou Berger 
Cc: Martin Bjorklund , Jie Dong ,  Dan Romascanu , NetMod WG Chairs ,  NetMod WG 
Content-Type: multipart/alternative; boundary="94eb2c1a615e39a957055f11b43c"
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-entity-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: Tue, 28 Nov 2017 21:28:50 -0000

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

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


Andy


On Tue, Nov 28, 2017 at 11:06 AM, Lou Berger  wrote:

> Authors, Contributors, WG,
>
> As part of the preparation for WG Last Call:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> NetMod WG Chairs
>
> PS Please include all listed in the headers of this message in your
> response.
>
>
>

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


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


<=
/div>
Andy

On Tue, Nov 28, 2017 at 11:06 AM, Lou Berger <=
span dir=3D"ltr"><=
lberger@labn.net> wrote:
Au=
thors, Contributors, WG,



As part of the preparation for WG Last Call:



Are you aware of any IPR that applies to drafts identified above?



Please state either:



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

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo=
t;

or

"No, the IPR has not been disclosed"



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

appropriate.



If you are listed as a document author or contributor please answer the

above by responding to this email regardless of whether or not you are

aware of any relevant IPR. This document will not advance to the next

stage until a response has been received from each author and listed

contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S<=
br>
TO LINES.



If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under

the IETF IPR rules which encourages you to notify the IETF if you are

aware of IPR of others on an IETF contribution, or to refrain from

participating in any contribution or discussion related to your

undisclosed IPR. For more information, please see the RFCs listed above

and

http://trac.tools.ietf.org/=
group/iesg/trac/wiki/IntellectualProperty.



Thank you,

NetMod WG Chairs



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

response.









--94eb2c1a615e39a957055f11b43c--


From nobody Tue Nov 28 17:15: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 093CA1292F5; Tue, 28 Nov 2017 17:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XEFKUM5lOrFl; Tue, 28 Nov 2017 17:15:12 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AE8120724; Tue, 28 Nov 2017 17:15:12 -0800 (PST)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 20C00A1E61CA0; Wed, 29 Nov 2017 01:15:09 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 29 Nov 2017 01:15:10 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 09:15:04 +0800
From: "Dongjie (Jimmy)" 
To: Lou Berger , Andy Bierman , "Martin Bjorklund" , Dan Romascanu 
CC: NetMod WG Chairs , NetMod WG 
Thread-Topic: Regarding IPR on draft-ietf-netmod-entity-05
Thread-Index: AQHTaHwMB+RPQ8WuVkqDN54f/gOChaMqjXZA
Date: Wed, 29 Nov 2017 01:15:03 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927981742BA@NKGEML515-MBX.china.huawei.com>
References: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
In-Reply-To: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.130.151.75]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-entity-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 01:15:14 -0000

Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N
Cg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
RnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+IFNlbnQ6IFdlZG5l
c2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMzowNyBBTQ0KPiBUbzogQW5keSBCaWVybWFuIDxhbmR5
QHl1bWF3b3Jrcy5jb20+OyBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT47DQo+IERv
bmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT47IERhbiBSb21hc2NhbnUNCj4gPGRy
b21hc2NhQGdtYWlsLmNvbT4NCj4gQ2M6IE5ldE1vZCBXRyBDaGFpcnMgPG5ldG1vZC1jaGFpcnNA
aWV0Zi5vcmc+OyBOZXRNb2QgV0cNCj4gPG5ldG1vZEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmVn
YXJkaW5nIElQUiBvbiBkcmFmdC1pZXRmLW5ldG1vZC1lbnRpdHktMDUNCj4gDQo+IEF1dGhvcnMs
IENvbnRyaWJ1dG9ycywgV0csDQo+IA0KPiBBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3Ig
V0cgTGFzdCBDYWxsOg0KPiANCj4gQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll
cyB0byBkcmFmdHMgaWRlbnRpZmllZCBhYm92ZT8NCj4gDQo+IFBsZWFzZSBzdGF0ZSBlaXRoZXI6
DQo+IA0KPiAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp
cyBkcmFmdCINCj4gb3INCj4gIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8g
dGhpcyBkcmFmdCINCj4gDQo+IElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4g
Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzNjY5LA0KPiA1Mzc4IGFu
ZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0KPiANCj4gSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxl
YXNlIHN0YXRlIGVpdGhlcjoNCj4gDQo+ICJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2Vk
IGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCj4gb3INCj4gIk5vLCB0aGUgSVBS
IGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQo+IA0KPiBJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2Ug
cHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4NCj4g
DQo+IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9y
IHBsZWFzZSBhbnN3ZXIgdGhlIGFib3ZlIGJ5DQo+IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCBy
ZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55DQo+IHJlbGV2
YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdl
IHVudGlsIGEgcmVzcG9uc2UNCj4gaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBh
bmQgbGlzdGVkIGNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMNCj4gVE8gQUxMIE9GIFlP
VSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MgVE8gTElORVMuDQo+IA0KPiBJZiB5b3UgYXJlIG9u
IHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0
ZWQgYXMgYW4NCj4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIg
b2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzDQo+IHdoaWNoIGVuY291cmFnZXMg
eW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMg
b24gYW4NCj4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0
aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbg0KPiByZWxhdGVkIHRvIHlvdXIg
dW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZD
cyBsaXN0ZWQNCj4gYWJvdmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2ll
c2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KPiANCj4gVGhhbmsgeW91LA0KPiBO
ZXRNb2QgV0cgQ2hhaXJzDQo+IA0KPiBQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRo
ZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KPiANCg0K


From nobody Tue Nov 28 23:55: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 8F7EE126D05; Tue, 28 Nov 2017 23:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V27GjtUbV55m; Tue, 28 Nov 2017 23:55:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B97D5126BF7; Tue, 28 Nov 2017 23:55:30 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id E180F1AE0144; Wed, 29 Nov 2017 08:55:28 +0100 (CET)
Date: Wed, 29 Nov 2017 08:54:08 +0100 (CET)
Message-Id: <20171129.085408.998770645089282194.mbj@tail-f.com>
To: lberger@labn.net
Cc: andy@yumaworks.com, jie.dong@huawei.com, dromasca@gmail.com, netmod-chairs@ietf.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
References: <56c5dbed-0fcd-516d-cdb0-e38180e390c8@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-entity-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 07:55:32 -0000

Lou Berger  wrote:
> Authors, Contributors, WG,
> 
> As part of the preparation for WG Last Call:
> 
> Are you aware of any IPR that applies to drafts identified above?

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


/martin


> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 


From nobody Wed Nov 29 07:58:11 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 6A0B91287A5; Wed, 29 Nov 2017 07:58:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197108937.7980.17137235624205271108@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 07:58:09 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-07.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, 29 Nov 2017 15:58:09 -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-07.txt
	Pages           : 38
	Date            : 2017-11-29

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-07
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-07


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

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


From nobody Wed Nov 29 09:27: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 61056127B60 for ; Wed, 29 Nov 2017 09:27:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6ilj-Hb994wK for ; Wed, 29 Nov 2017 09:27:07 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 39E9E1271DF for ; Wed, 29 Nov 2017 09:27:07 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id D6F07140607 for ; Wed, 29 Nov 2017 10:27:03 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id ftT01w0032SSUrH01tT3Kz; Wed, 29 Nov 2017 10:27:03 -0700
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=sC3jslCIGhcA:10 a=48vgC7mUAAAA:8 a=ydlOUqo9ZVRb99kjdIcA: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: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=d7FcfNZVjrdMtKwzfyZJ8BJxtGTSWhdZGDvzkE3xq+o=; b=xLDRH/WFIvDkCzXI8xqw9FW6J7 p2L/OYxKM+L9yj1fadLvhn+cx2qJvCcIu3IMBDxGY3x+JQypfoTKQJB1OXBdc926iGt6KHveIB6pw WX2l2b2nCfbBourO9EMqUoGc/;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47990 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eK68R-002vEh-R7; Wed, 29 Nov 2017 10:26:59 -0700
To: NetMod WG 
Cc: NetMod WG Chairs 
From: Lou Berger 
Message-ID: <8568e55c-29c6-272e-dd9f-7d1b150edba6@labn.net>
Date: Wed, 29 Nov 2017 12:26:59 -0500
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
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: 1eK68R-002vEh-R7
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]:47990
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 17:27:09 -0000

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc8022bis-01.

Please recall that this update's intention is to 
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

The working group last call ends on December 13.
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.

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2] https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=rfc8022.txt&url2=draft-ietf-netmod-rfc8022bis-01.txt

Thank you,
Netmod Chairs


From nobody Wed Nov 29 09:36: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 B5E14120726 for ; Wed, 29 Nov 2017 09:36:00 -0800 (PST)
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 M0dmh5MBC3yb for ; Wed, 29 Nov 2017 09:35:59 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83521271DF for ; Wed, 29 Nov 2017 09:35:59 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 7A6BA216008 for ; Wed, 29 Nov 2017 10:35:59 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id ftbv1w00t2SSUrH01tbz2d; Wed, 29 Nov 2017 10:35:59 -0700
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=sC3jslCIGhcA:10 a=ydlOUqo9ZVRb99kjdIcA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fgJxN3b1VHWXjb666vfYHgNDD6bpW06FCDeOowaP6Gw=; b=wWhXRa1B70+YRQxXr9MNIIY5gJ cq95wiUAmGmnf5eUFAkCXDuifUHUP8B/cWPwVHtIWZ3dC01sxExk9+TsFrP+CXqUmW/74CDYvzYar lBoVRvrcdwfaG3wZllpnb/P4H;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:48542 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eK6H5-002x5w-Nv; Wed, 29 Nov 2017 10:35:55 -0700
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
Message-ID: 
Date: Wed, 29 Nov 2017 12:35:55 -0500
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
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: 1eK6H5-002x5w-Nv
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]:48542
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-netmod-entity-05
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 17:36:01 -0000

All,

This starts a two-week working group last call on
draft-ietf-netmod-entity-05.

The working group last call ends on December 13.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Netmod Chairs


From nobody Wed Nov 29 12:11: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 36643128D19 for ; Wed, 29 Nov 2017 12:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTRjEmNPzuPQ for ; Wed, 29 Nov 2017 12:11:32 -0800 (PST)
Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 D7FC3128C9C for ; Wed, 29 Nov 2017 12:11:31 -0800 (PST)
Received: by mail-pl0-x22f.google.com with SMTP id i6so2741494plt.13 for ; Wed, 29 Nov 2017 12:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=jHSF5DFy2vJaezZtzH/j5xdgNTO4jodl3rwXFnrxQq4=; b=hM/CN/jermEDxPUUTlcx03P9dmsUaIPoxY1i4lVclWGjq1XYPAh/ZokSJERwmNNMib wX7/yN/i+arEc/yzXg7JSfhkrP8yTBh3CynGd80Rjxc48aDKGr8vim/wduFWLctBqUnC 2RPZ92dMf2Os9Z8UhhXC/tOXQ5oNIJ7M2f5Emq68InI01RjX28WXD9DXX/6VnFmc56z4 TGT75Gbeb0LbPd7Uwd+70FFslHj1Y/MlzADrDzZo/kiJyUMFcXAZrEWCv3OZV7RfmWHD CyenMAgKSTlupwRHlpU9a6a4LhX3JpLGp35UpN+6NsNjBRhHT4QzRsbsQO3sTnZNlCyK 3rbg==
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=jHSF5DFy2vJaezZtzH/j5xdgNTO4jodl3rwXFnrxQq4=; b=IuzmNhQC28tyMG3uyslem49AxORVdv3mVxXbfuc4IFJ8kP9sDLJZNYjaWAv7SM50I6 hz9BW0+3S+IaKRsFyy3lB6/vQ79oN43K2px7hJXVu133iYvhd3i1x0nTTJsbpWdiqYC3 CfJQELmC9As+ujjTiPzNOqD5g8UoPIw71jtxsKCxBgf2PL9CdsWTlZ1rzc7V++KnlMWH FHnStFFvyFJqqR0dES979JTPAY1xwjWlLtRQacqVGK5ZimP+FWPj8zU6vMRpGcKqaQfr ZIQZYDq9o7yF9FWMja/xY+7i5yMMxHSNUej4EEmK5mnT1yjt14N7ghcxTlsvldBfcBrP E+Gw==
X-Gm-Message-State: AJaThX4PJJ0SJU4P8elhRLzzSr3JOe9UL023GVVH/q3+EOGjelj2lGaN Aokg6DqJuQjGB5DIHxvJFgdSdyXU
X-Google-Smtp-Source: AGs4zMY1CrXUsYvktVFNsb9Ot2b32tzA8emRRYeVFQPz94fyhiZkmd9sB765uweQeVD5Vpk3OVzhXQ==
X-Received: by 10.84.131.35 with SMTP id 32mr50748pld.347.1511986291052; Wed, 29 Nov 2017 12:11:31 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:64e3:eccb:ea65:7763]) by smtp.gmail.com with ESMTPSA id x22sm4806491pfa.169.2017.11.29.12.11.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Nov 2017 12:11:30 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_01DE3777-7819-42F6-BB11-FE7CB34D0EBE"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <20171128.111715.2283575031970124402.mbj@tail-f.com>
Date: Wed, 29 Nov 2017 12:11:17 -0800
Cc: Robert Wilton , Jeffrey Haas , Sonal Agarwal , Kristian Larsson , Kristian Larsson , Martin Bjorklund 
Message-Id: 
References:  <87y3mr3loc.fsf@dev.terastrm.net>  <20171128.111715.2283575031970124402.mbj@tail-f.com>
To: NetMod WG 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] IETF 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: Wed, 29 Nov 2017 20:11:35 -0000

--Apple-Mail=_01DE3777-7819-42F6-BB11-FE7CB34D0EBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The updated commit here =
 takes care of restoring =E2=80=9Ctype" to =
"acl-type", fixes some indentation issues, adds a choice for =E2=80=9Cl3" =
where either =E2=80=9Cipv4" or =E2=80=9Cipv6" can be selected, and a =
similar choice at =E2=80=9Cl4" that allows either =E2=80=9Ctcp", =E2=80=9C=
udp" or =E2=80=9Cicmp" to be selected, and removes changes for =
=E2=80=9Cglobal" attachment point. Will add the last item as a separate =
commit.

Unless I hear objections, I will roll the pr/18 changes into the master =
branch in 48 hours.

> On Nov 28, 2017, at 2:17 AM, Martin Bjorklund  wrote:
>=20
> Mahesh Jethanandani  wrote:
>> An updated version of the model has been posted as part of the PR =
here
>> =
.
>>=20
>> The particular change removes any-acl from the model, expands on eth
>> (to ethernet), removes acl- prefix for things like acl-type and
>> acl-name. Please review.
>=20
> I think 99% of the changes in this PR look good.  The one
> exception is the typedef that used to be called "acl-type".  I think
> it should still be called "acl-type".  "type" is too broad.  NOTE,
> this is just the typedef; the leaf /access-lists/acl/type should keep
> its name ("type").
>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>>> On Nov 27, 2017, at 5:17 AM, Kristian Larsson 
>>> wrote:
>>>=20
>>>=20
>>> Robert Wilton  writes:
>>>=20
>>>> Thinking about this some more. I'm not sure what it means for the =
"ACL
>>>> Type" to be "any-acl". It seems that the "match any packet" should =
be
>>>> a
>>>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than =
a=20
>>>> type of ACL.
>>>=20
>>> Yes, I agree as so far that any-acl makes no sense as an acl-type. =
The
>>> way I understood acl-type, and the way that vendors have told me it
>>> will
>>> be used, is to say "this is an IPv4 ACL" and then on an attachment
>>> point
>>> you can specify that only ACLs of acl-type ipv4-acl can be attached =
to
>>> the interface. That makes perfect sense. I do not see how any-acl =
can
>>> map into this.
>>>=20
>>> I agree that any-acl is logically a type of ACE but we don't have an
>>> ace-type and the exact same information can IMHO already be conveyed
>>> WITHOUT the any-acl type and thus it has no reason to exist. Nor do =
we
>>> need a feature for it.
>>>=20
>>> =46rom what I can tell the any-acl container in the ACE should be =
used
>>> to
>>> explicitly signify a match on "any". Think of IOS style ipv4 acl:
>>> permit ip any any
>>>=20
>>> We have to provide a source and destination so this would be a =
rather
>>> explicit mapping of that. However, our structure in this YANG model =
is
>>> just completely different than an IOS command so I don't see why we
>>> should try and mimic IOS in the YANg model.
>>>=20
>>> Not specifying a destination IP address means we match on any
>>> destination IP address. The same is true for any other field we can
>>> match on. Not setting a match implies we don't try to match on that
>>> field, thus we allow "any" value. I think the logical continuation =
of
>>> this is that for an ACE with no matches defined at all, we match any
>>> packet. I think we can update the text to better explain this.
>>>=20
>>>=20
>>>=20
>>>> Otherwise if the ACL type is "any-acl" then this only allows two =
types
>>>> of ACLs to be defined, neither of which seem to be particularly
>>>> useful:
>>>> (1) An ACL that matches all traffic and permits it, i.e. the same =
as=20
>>>> having no ACL at all.
>>>> (2) An ACL that matches all traffic and drops.
>>>>=20
>>>> So I think perhaps the answer here is to define neither ACL type=20
>>>> "any-acl" nor leaf "any". The presumption could be that any ACE =
that
>>>> is
>>>> configured to match no fields implicitly matches all packets =
(because=20
>>>> all non specified fields are treated as wildcards), and then =
applies
>>>> the
>>>> permit/deny rule associated with the ACE. This logic can apply to =
all=20
>>>> ACL types.
>>>=20
>>> Yes yes yes :)
>>>=20
>>>  Kristian.
>>=20
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>=20

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_01DE3777-7819-42F6-BB11-FE7CB34D0EBE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The updated commit here takes care of =
restoring =E2=80=9Ctype" to "acl-type", fixes some indentation issues, =
adds a choice for =E2=80=9Cl3" where either =E2=80=9Cipv4" or =E2=80=9Cipv=
6" can be selected, and a similar choice at =E2=80=9Cl4" that allows =
either =E2=80=9Ctcp", =E2=80=9Cudp" or =E2=80=9Cicmp" to be selected, =
and removes changes for =E2=80=9Cglobal" attachment point. Will add the =
last item as a separate commit.

Unless I hear objections, I will roll the pr/18 changes into =
the master branch in 48 hours.

On =
Nov 28, 2017, at 2:17 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:

Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
An updated version of =
the model has been posted as part of the PR here
<https://github.com/netmod-wg/acl-model/commit/2477cd400cce6d399=
33c908ad97da27ff759588b>.

The =
particular change removes any-acl from the model, expands on eth
(to ethernet), removes acl- prefix for things like acl-type =
and
acl-name. Please review.

I think 99% of the changes in this PR look good.  The =
one
exception is the typedef that used to be called =
"acl-type".  I think
it should still be called =
"acl-type".  "type" is too broad.  NOTE,
this is =
just the typedef; the leaf /access-lists/acl/type should keep
its name ("type").


/martin




On Nov 27, 2017, at 5:17 AM, Kristian Larsson =
<kll@dev.terastrm.net>
wrote:


Robert Wilton <rwilton@cisco.com> =
writes:

Thinking about this some more. I'm not sure what it means for =
the "ACL
Type" to be "any-acl". It seems that the "match =
any packet" should be
a
type of ACE, e.g. =
perhaps as the last entry of an ACL, rather than a 
type =
of ACL.

Yes, I agree as so far =
that any-acl makes no sense as an acl-type. The
way I =
understood acl-type, and the way that vendors have told me it
will
be used, is to say "this is an IPv4 ACL" =
and then on an attachment
point
you can =
specify that only ACLs of acl-type ipv4-acl can be attached to
the interface. That makes perfect sense. I do not see how =
any-acl can
map into this.

I =
agree that any-acl is logically a type of ACE but we don't have an
ace-type and the exact same information can IMHO already be =
conveyed
WITHOUT the any-acl type and thus it has no =
reason to exist. Nor do we
need a feature for it.

=46rom what I can tell the any-acl container =
in the ACE should be used
to
explicitly =
signify a match on "any". Think of IOS style ipv4 acl:
 =
permit ip any any

We have to provide a =
source and destination so this would be a rather
explicit =
mapping of that. However, our structure in this YANG model is
just completely different than an IOS command so I don't see =
why we
should try and mimic IOS in the YANg model.

Not specifying a destination IP address means =
we match on any
destination IP address. The same is true =
for any other field we can
match on. Not setting a match =
implies we don't try to match on that
field, thus we allow =
"any" value. I think the logical continuation of
this is =
that for an ACE with no matches defined at all, we match any
packet. I think we can update the text to better explain =
this.



Otherwise if the ACL =
type is "any-acl" then this only allows two types
of ACLs =
to be defined, neither of which seem to be particularly
useful:
(1) An ACL that matches all traffic and =
permits it, i.e. the same as 
having no ACL at all.
(2) An ACL that matches all traffic and drops.

So I think perhaps the answer here is to =
define neither ACL type 
"any-acl" nor leaf "any". The =
presumption could be that any ACE that
is
configured to match no fields implicitly matches all packets =
(because 
all non specified fields are treated as =
wildcards), and then applies
the
permit/deny =
rule associated with the ACE. This logic can apply to all 
ACL types.

Yes yes =
yes :)

  Kristian.

Mahesh Jethanandani
mjethanandani@gmail.com




Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_01DE3777-7819-42F6-BB11-FE7CB34D0EBE--


From nobody Wed Nov 29 16:20: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 4F3F31286B1 for ; Wed, 29 Nov 2017 16:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwH_SKetIUwY for ; Wed, 29 Nov 2017 16:19:56 -0800 (PST)
Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::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 C423312878D for ; Wed, 29 Nov 2017 16:19:54 -0800 (PST)
Received: by mail-pl0-x229.google.com with SMTP id f6so3132595pln.12 for ; Wed, 29 Nov 2017 16:19:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Hi9oOLQGzOvLKo6koRdNFuUWISWJ+SU9UZXlZ5o59AM=; b=VHYL/Aa1tFq1W2FGvM4JS1pcMN71nKlmz2cCcRt8uIzxt5xFCeQMUYKM1iITSs5Rg1 LX+eXp6ETe/FdctL24hna022KWphznA07EUwKo8QrS0fKQtDPTbbaxcVWSS1Ne80yhQt wQ6IxqBZMSV2MrpGgzcjXrrMTctd9Uv7BKW0BvL7PkYDS41rGAyrYvA07f9sqXZdmj6K A4fmHLD9Xm3NzIfGkIE72yRj/nonBCrCGG6AhllZBWkO/zK8EZ0iUiwALXRGvr+PmvB5 fvwXblaclU0ylKwY0eqP5LrTXAJuah4C4rb6eAfUqzkxbifwBgX71EmJpU6zwj3Esb+K /Ezg==
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=Hi9oOLQGzOvLKo6koRdNFuUWISWJ+SU9UZXlZ5o59AM=; b=ZgKlRGiobqQCuiwrGfatzs3pE31WM+uYHL8nMowRtCFpMiDBceVAmSyrhfLrJPSCrI uIzfaNzL+l2C31Na70oydK2s/5LHg+POqoXhrJP1a/Z9eAYwsvQanMkkx9PVs+ouoyFf q5tswKfUW/FTovvjsn7L0tJks4WaesGq0iXwmyKmQf+9vURGOS7tyd0s+QhHTh/EyU6j g0x2jtv5wbvxTjnxjlLca7oFkVNdlnx6IVu6tpyGZG6rAdDD8rlgaHLpzTiTuPmDNcT/ d9SOukNXbQ6GH9p0LEozjLZXRD3rofCpmzlGI97T8tYDMF9ypF6X4Mv8bcmr5BQrJVoL khAg==
X-Gm-Message-State: AJaThX486R09p12+rSj14rCs5ip10GgkwiCGUzd3Ht3rFvKS0Wy/CAOo hXc74ASgqzJ3QGViiffL7CNbQJWR
X-Google-Smtp-Source: AGs4zMap37WIOtHqQG31XrqhIq5tUcjp3DA6AMsTRx+8LGmQwcjEclV6sbkJsJlIqJsi4ITMkJNaCw==
X-Received: by 10.84.128.47 with SMTP id 44mr635915pla.287.1512001194283; Wed, 29 Nov 2017 16:19:54 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:64e3:eccb:ea65:7763]) by smtp.gmail.com with ESMTPSA id n19sm4405884pgf.65.2017.11.29.16.19.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Nov 2017 16:19:51 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2BE08EF8-52D5-43E0-9C7D-42132B930567"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Wed, 29 Nov 2017 16:19:45 -0800
Cc: NetMod WG , Robert Wilton , Jeffrey Haas , Kristian Larsson , Kristian Larsson , Martin Bjorklund 
Message-Id: <3C87EF5F-2E1F-4C74-B8FA-28E380AD4C80@gmail.com>
References:  <87y3mr3loc.fsf@dev.terastrm.net>  <20171128.111715.2283575031970124402.mbj@tail-f.com>  
To: "Sonal Agarwal (agarwaso)" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] IETF 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, 30 Nov 2017 00:19:59 -0000

--Apple-Mail=_2BE08EF8-52D5-43E0-9C7D-42132B930567
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

For now.

Kristian and I discussed this, and agreed that we will pull it in in a =
new pull request.

> On Nov 29, 2017, at 4:08 PM, Sonal Agarwal (agarwaso) =
 wrote:
>=20
> Are you removing the definition  of =E2=80=9Cglobal=E2=80=9D ACL?
>=20
> -
> leaf global {
> -
> if-feature global-attachment;
> -
> type
> empty;
> -
> description
> -
> "ACL rule is global";
> - }
>=20
> The remaining changes look fine to me.
>=20
> Thanks,
> ---
> Sonal Agarwal
>=20
> From: Mahesh Jethanandani >
> Date: Wednesday, November 29, 2017 at 12:11 PM
> To: NetMod WG >
> Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" =
>, Jeffrey Haas =
>, Cisco Employee =
>, Kristian Larsson =
>, Kristian Larsson =
>, Martin Bjorklund =
>
> Subject: Re: [netmod] IETF ACL model
>=20
> The updated commit here =
 takes care of restoring =E2=80=9Ctype" to =
"acl-type", fixes some indentation issues, adds a choice for =E2=80=9Cl3" =
where either =E2=80=9Cipv4" or =E2=80=9Cipv6" can be selected, and a =
similar choice at =E2=80=9Cl4" that allows either =E2=80=9Ctcp", =E2=80=9C=
udp" or =E2=80=9Cicmp" to be selected, and removes changes for =
=E2=80=9Cglobal" attachment point. Will add the last item as a separate =
commit.
>=20
> Unless I hear objections, I will roll the pr/18 changes into the =
master branch in 48 hours.
>=20
>> On Nov 28, 2017, at 2:17 AM, Martin Bjorklund > wrote:
>>=20
>> Mahesh Jethanandani > wrote:
>>> An updated version of the model has been posted as part of the PR =
here
>>> =
>.
>>>=20
>>> The particular change removes any-acl from the model, expands on eth
>>> (to ethernet), removes acl- prefix for things like acl-type and
>>> acl-name. Please review.
>>=20
>> I think 99% of the changes in this PR look good.  The one
>> exception is the typedef that used to be called "acl-type".  I think
>> it should still be called "acl-type".  "type" is too broad.  NOTE,
>> this is just the typedef; the leaf /access-lists/acl/type should keep
>> its name ("type").
>>=20
>>=20
>> /martin
>>=20
>>=20
>>=20
>>>=20
>>>> On Nov 27, 2017, at 5:17 AM, Kristian Larsson >
>>>> wrote:
>>>>=20
>>>>=20
>>>> Robert Wilton > =
writes:
>>>>=20
>>>>> Thinking about this some more. I'm not sure what it means for the =
"ACL
>>>>> Type" to be "any-acl". It seems that the "match any packet" should =
be
>>>>> a
>>>>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than =
a=20
>>>>> type of ACL.
>>>>=20
>>>> Yes, I agree as so far that any-acl makes no sense as an acl-type. =
The
>>>> way I understood acl-type, and the way that vendors have told me it
>>>> will
>>>> be used, is to say "this is an IPv4 ACL" and then on an attachment
>>>> point
>>>> you can specify that only ACLs of acl-type ipv4-acl can be attached =
to
>>>> the interface. That makes perfect sense. I do not see how any-acl =
can
>>>> map into this.
>>>>=20
>>>> I agree that any-acl is logically a type of ACE but we don't have =
an
>>>> ace-type and the exact same information can IMHO already be =
conveyed
>>>> WITHOUT the any-acl type and thus it has no reason to exist. Nor do =
we
>>>> need a feature for it.
>>>>=20
>>>> =46rom what I can tell the any-acl container in the ACE should be =
used
>>>> to
>>>> explicitly signify a match on "any". Think of IOS style ipv4 acl:
>>>> permit ip any any
>>>>=20
>>>> We have to provide a source and destination so this would be a =
rather
>>>> explicit mapping of that. However, our structure in this YANG model =
is
>>>> just completely different than an IOS command so I don't see why we
>>>> should try and mimic IOS in the YANg model.
>>>>=20
>>>> Not specifying a destination IP address means we match on any
>>>> destination IP address. The same is true for any other field we can
>>>> match on. Not setting a match implies we don't try to match on that
>>>> field, thus we allow "any" value. I think the logical continuation =
of
>>>> this is that for an ACE with no matches defined at all, we match =
any
>>>> packet. I think we can update the text to better explain this.
>>>>=20
>>>>=20
>>>>=20
>>>>> Otherwise if the ACL type is "any-acl" then this only allows two =
types
>>>>> of ACLs to be defined, neither of which seem to be particularly
>>>>> useful:
>>>>> (1) An ACL that matches all traffic and permits it, i.e. the same =
as=20
>>>>> having no ACL at all.
>>>>> (2) An ACL that matches all traffic and drops.
>>>>>=20
>>>>> So I think perhaps the answer here is to define neither ACL type=20=

>>>>> "any-acl" nor leaf "any". The presumption could be that any ACE =
that
>>>>> is
>>>>> configured to match no fields implicitly matches all packets =
(because=20
>>>>> all non specified fields are treated as wildcards), and then =
applies
>>>>> the
>>>>> permit/deny rule associated with the ACE. This logic can apply to =
all=20
>>>>> ACL types.
>>>>=20
>>>> Yes yes yes :)
>>>>=20
>>>>  Kristian.
>>>=20
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com 
>>>=20
>=20
> Mahesh Jethanandani
> mjethanandani@gmail.com 

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_2BE08EF8-52D5-43E0-9C7D-42132B930567
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

For now.

Kristian and I discussed this, and agreed that we will pull =
it in in a new pull request.

On =
Nov 29, 2017, at 4:08 PM, Sonal Agarwal (agarwaso) <agarwaso@cisco.com> =
wrote:










Are you removing the definition  of =E2=80=9Cglobal=E2=
=80=9D ACL?














-
leaf global {









-
if-feature global-attachment;









-
type
empty;









-
description









-
"ACL rule is global";









- }
















The =
remaining changes look fine to me.







Thanks,


---


Sonal =
Agarwal













From: Mahesh =
Jethanandani <mjethanandani@gmail.com>

Date: Wednesday, =
November 29, 2017 at 12:11 PM

To: NetMod WG <netmod@ietf.org>

Cc: "Robert Wilton -X =
(rwilton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, =
Jeffrey Haas <jhaas@juniper.net>, Cisco Employee <agarwaso@cisco.com>,
 Kristian Larsson <kll@spritelink.net>, Kristian Larsson <kll@dev.terastrm.net>, Martin Bjorklund <mbj@tail-f.com>

Subject: Re: [netmod] =
IETF ACL model












The updated commit here takes care of =
restoring =E2=80=9Ctype" to "acl-type", fixes some indentation issues, =
adds a choice for =E2=80=9Cl3" where either =E2=80=9Cipv4"
 or =E2=80=9Cipv6" can be selected, and a similar choice at =E2=80=9Cl4" =
that allows either =E2=80=9Ctcp", =E2=80=9Cudp" or =E2=80=9Cicmp" to be =
selected, and removes changes for =E2=80=9Cglobal" attachment point. =
Will add the last item as a separate commit.






Unless I hear objections, I will roll the pr/18 changes =
into the master branch in 48 hours.









On Nov 28, 2017, at 2:17 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:






Mahesh Jethanandani <mjethanandani@gmail.com> wrote:


An updated version of the model has =
been posted as part of the PR here

<https://github.com/netmod-wg/acl-model/commit/2477cd400cce6d399=
33c908ad97da27ff759588b>.



The particular change removes any-acl from the model, expands on eth

(to ethernet), removes acl- prefix for things like acl-type and

acl-name. Please review.





I think 99% of the changes in this PR look good.  The one

exception is the typedef that used to be called "acl-type".  I =
think

it should still be called "acl-type".  "type" is too broad. =
 NOTE,

this is just the typedef; the leaf /access-lists/acl/type should keep

its name ("type").





/martin











On Nov 27, 2017, at 5:17 AM, =
Kristian Larsson <kll@dev.terastrm.net>

wrote:





Robert Wilton <rwilton@cisco.com> writes:




Thinking about this some more. I'm =
not sure what it means for the "ACL

Type" to be "any-acl". It seems that the "match any packet" should be

a

type of ACE, e.g. perhaps as the last entry of an ACL, rather than a 

type of ACL.





Yes, I agree as so far that any-acl makes no sense as an acl-type. =
The

way I understood acl-type, and the way that vendors have told me it

will

be used, is to say "this is an IPv4 ACL" and then on an attachment

point

you can specify that only ACLs of acl-type ipv4-acl can be attached =
to

the interface. That makes perfect sense. I do not see how any-acl can

map into this.



I agree that any-acl is logically a type of ACE but we don't have an

ace-type and the exact same information can IMHO already be conveyed

WITHOUT the any-acl type and thus it has no reason to exist. Nor do =
we

need a feature for it.



=46rom what I can tell the any-acl container in the ACE should be =
used

to

explicitly signify a match on "any". Think of IOS style ipv4 acl:

permit ip any any



We have to provide a source and destination so this would be a rather

explicit mapping of that. However, our structure in this YANG model =
is

just completely different than an IOS command so I don't see why we

should try and mimic IOS in the YANg model.



Not specifying a destination IP address means we match on any

destination IP address. The same is true for any other field we can

match on. Not setting a match implies we don't try to match on that

field, thus we allow "any" value. I think the logical continuation of

this is that for an ACE with no matches defined at all, we match any

packet. I think we can update the text to better explain this.








Otherwise if the ACL type is =
"any-acl" then this only allows two types

of ACLs to be defined, neither of which seem to be particularly

useful:

(1) An ACL that matches all traffic and permits it, i.e. the same as 

having no ACL at all.

(2) An ACL that matches all traffic and drops.



So I think perhaps the answer here is to define neither ACL type 

"any-acl" nor leaf "any". The presumption could be that any ACE that

is

configured to match no fields implicitly matches all packets (because =


all non specified fields are treated as wildcards), and then applies

the

permit/deny rule associated with the ACE. This logic can apply to all =


ACL types.





Yes yes yes :)



 Kristian.





Mahesh Jethanandani

mjethanandani@gmail.com


















Mahesh Jethanandani


mjethanandani@gmail.com





















Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_2BE08EF8-52D5-43E0-9C7D-42132B930567--


From nobody Wed Nov 29 16:41: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 47F251286B1; Wed, 29 Nov 2017 16:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 iGhX4jB05eLW; Wed, 29 Nov 2017 16:41:07 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9BE124B0A; Wed, 29 Nov 2017 16:41:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1504; q=dns/txt; s=iport; t=1512002467; x=1513212067; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wS7Mg3OU3dZTnvTR0xr+o6GI6tjJs1Q75r/rrmpPhHA=; b=TchOdhgSQRXBduMIrzrH/grKU3uNUiWjT2BqK01sQUocVFI0TEthaEZ+ yD0ZPz5EG/ttu5uqKtKtZhzipLgBM32ImLzmnGDaD8y8AW6yYl57AKvBs 7IhFTz+owVVaVlwC3YHI9dmQAhx8IdOEqeq/X2mUGqdK8vCK9WCclXYDG 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAAB4Uh9a/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4nB4N4iiCOcZhxghEKGAuESU8chHs/GAEBAQEBAQEBAWs?= =?us-ascii?q?ohSACAQMBASEROgsSAQgODAImAgQlCxUSBAENBYoiEKczgieKZQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgQ+CMoIJgz+DK4MyGIFWgxWCYwWiTQKHco0aghaGD4s?= =?us-ascii?q?sijmCQIkcAhEZAYE5AR85gVFvFTqCKYRVdwGIYoEUAQEB?=
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200"; d="scan'208";a="108685801"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 00:41:06 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAU0f6bw008616 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 00:41: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; Wed, 29 Nov 2017 19:41:05 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 29 Nov 2017 19:41:05 -0500
From: "Acee Lindem (acee)" 
To: Kent Watsen , "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00
Thread-Index: AQHTaXPneeSJFessbkKv8jheAbNEdA==
Date: Thu, 30 Nov 2017 00:41:05 +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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-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: Thu, 30 Nov 2017 00:41:09 -0000

SSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgc3VwcG9ydCBwdWJsaWNhdGlvbi4NClRoYW5r
cywNCkFjZWUgDQoNCg0KT24gMTEvMjgvMTcsIDI6MjkgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9m
IEtlbnQgV2F0c2VuIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBrd2F0
c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkFsbCwNCj4NCj5UaGlzIHN0YXJ0cyBhIHR3by13
ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzIy
M2Jpcy0wMC4NCj4NCj5QbGVhc2UgcmVjYWxsIHRoYXQgdGhpcyB1cGRhdGUncyBpbnRlbnRpb24g
aXMgdG8NCj5tb2RpZnkgdGhlIFlBTkcgbW9kdWxlIHRvIGJlIGluIGxpbmUgd2l0aCB0aGUgTk1E
QQ0KPmd1aWRlbGluZXMgWzFdLiAgUmV2aWV3aW5nIHRoZSBkaWZmIGJldHdlZW4gdGhlIHR3bw0K
PmRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0IHRoaXMuDQo+DQo+VGhlIHdvcmtpbmcgZ3Jv
dXAgbGFzdCBjYWxsIGVuZHMgb24gRGVjZW1iZXIgMTIuDQo+UGxlYXNlIHNlbmQgeW91ciBjb21t
ZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCj4NCj5Qb3NpdGl2ZSBjb21tZW50cywg
ZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudA0KPmFuZCBiZWxpZXZlIGl0IGlzIHJl
YWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KPlRoaXMgaXMgdXNlZnVsIGFuZCBp
bXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KPg0KPlsxXSBodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMtMDENCj5bMl0gDQo+aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzIyM2Jpcy0w
MC50eHQNCj4NCj5UaGFuayB5b3UsDQo+TmV0bW9kIENoYWlycw0KPg0KPg0KPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlz
dA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0bW9kDQoNCg==


From nobody Wed Nov 29 18:17: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 EAE381289B5; Wed, 29 Nov 2017 18:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Rva_SBmJYzR3; Wed, 29 Nov 2017 18:17:37 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8031287A0; Wed, 29 Nov 2017 18:17:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1536; q=dns/txt; s=iport; t=1512008257; x=1513217857; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5rgLGWqKoVoqkVzsDLBf13NLEE1la5bO5AT1Yp80b0o=; b=U9r/0G4HN69F+GxGa8+hcog3IEE8pcI21xpTjQPiAnveFXnVcGvDQarE Y3QzO/uMYzQQFG+LnTGzp1ZOHStECq6woX5jAIbiyAp8U/f8Zizoy+UEP pQkqw8PGlywR4+K9owQHt7xAZMEIpCcRytXdyp/mgW89DFM2TnfwasbCG k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAADAaR9a/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4nB4N4iiCOcZhxghEKGAuESU8chHs/GAEBAQEBAQEBAWs?= =?us-ascii?q?ohSACAQMBASEROgsSAQgODAImAgQlCxUSBAENBYoiEKcWgieKZAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgQ+CMoIJgz+DK4MyGIFWgxWCYwWiTQKHco0aghaGD4s?= =?us-ascii?q?sijmCQIkcAhEZAYE5AR85gVFvFTqCKYRVdwGIYoEUAQEB?=
X-IronPort-AV: E=Sophos;i="5.45,339,1508803200"; d="scan'208";a="38200561"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 02:17:36 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAU2Ha2N005834 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 02:17:36 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, 29 Nov 2017 21:17:35 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 29 Nov 2017 21:17:35 -0500
From: "Acee Lindem (acee)" 
To: Kent Watsen , "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" 
Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00
Thread-Index: AQHTaYFiSitRVtWa5kmwd58FDuHqug==
Date: Thu, 30 Nov 2017 02:17:35 +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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-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: Thu, 30 Nov 2017 02:17:39 -0000

SSBoYXZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgc3VwcG9ydCBwdWJsaWNhdGlvbi4NClRo
YW5rcywNCkFjZWUgDQoNCk9uIDExLzI4LzE3LCAyOjQzIFBNLCAibmV0bW9kIG9uIGJlaGFsZiBv
ZiBLZW50IFdhdHNlbiINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dh
dHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5bcmVzZW5kaW5nXQ0KPg0KPg0KPkFsbCwNCj4N
Cj5UaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQo+ZHJh
ZnQtaWV0Zi1uZXRtb2QtcmZjNzI3N2Jpcy0wMC4NCj4NCj5QbGVhc2UgcmVjYWxsIHRoYXQgdGhp
cyB1cGRhdGUncyBpbnRlbnRpb24gaXMgdG8NCj5tb2RpZnkgdGhlIFlBTkcgbW9kdWxlIHRvIGJl
IGluIGxpbmUgd2l0aCB0aGUgTk1EQQ0KPmd1aWRlbGluZXMgWzFdLiAgUmV2aWV3aW5nIHRoZSBk
aWZmIGJldHdlZW4gdGhlIHR3bw0KPmRyYWZ0cyBbMl0gc2hvdWxkIHJldmVhbCBqdXN0IHRoaXMu
DQo+DQo+VGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gRGVjZW1iZXIgMTIuDQo+
UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCj4N
Cj5Qb3NpdGl2ZSBjb21tZW50cywgZS5nLiwgIkkndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudA0K
PmFuZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0K
PlRoaXMgaXMgdXNlZnVsIGFuZCBpbXBvcnRhbnQsIGV2ZW4gZnJvbSBhdXRob3JzLg0KPg0KPlsx
XSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMt
MDENCj5bMl0gDQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0
Zi1uZXRtb2QtcmZjNzI3N2Jpcy0wMC50eHQNCj4NCj5UaGFuayB5b3UsDQo+TmV0bW9kIENoYWly
cw0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Thu Nov 30 00:10: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 E78C31279E5 for ; Thu, 30 Nov 2017 00:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbyHttbgXziZ for ; Thu, 30 Nov 2017 00:10:45 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 17AB6126DFB for ; Thu, 30 Nov 2017 00:10:45 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 3E50D1AE01AA for ; Thu, 30 Nov 2017 09:10:44 +0100 (CET)
Date: Thu, 30 Nov 2017 09:09:23 +0100 (CET)
Message-Id: <20171130.090923.2174365350167325836.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] 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: Thu, 30 Nov 2017 08:10:47 -0000

Hi,

I have posted a new version of the NMDA draft,
draft-ietf-netmod-revised-datastores-07.  With this version, we
believe that all WGLC and post-WGLC comments have been addressed.  See
below for the first set of changes between 04 and 05.

The changes from 05 to 07 are:

  o added a definition of "datastore schema" to the terminology
    section, and use that term in the document.

  o clarified that the datastore schema for  MUST be a
    superset of the config datastores (except node omission).

  o specified that actions and rpc are invoked in the context of
    operational


/martin



Robert Wilton  wrote:
> Hi,
> =

> I've just posted an updated version of the NMDA datastores draft
> (draft-ietf-netmod-revised-datastores-05.txt).=A0 The authors believe=

> that this should address all of the issues raised during the WG LC.=A0=

> 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.=A0 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.=A0 Please may I also ask that if you raised an issue that y=
ou
> 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 large=
r
> 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
> =

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


From nobody Thu Nov 30 00:30: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 03977126D45 for ; Thu, 30 Nov 2017 00:30:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=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 TjDuaF38V55q for ; Thu, 30 Nov 2017 00:30:54 -0800 (PST)
Received: from smtp.dev.terastrm.net (smtp.dev.terastrm.net [IPv6:2003:1f0b:ffde::101]) by ietfa.amsl.com (Postfix) with ESMTP id B03221200C5 for ; Thu, 30 Nov 2017 00:30:53 -0800 (PST)
Received: from lingloi.dev.terastrm.net (unknown [IPv6:2003:1b3b:ffde:1::5]) by smtp.dev.terastrm.net (Postfix) with ESMTPSA id 66C703A0077; Thu, 30 Nov 2017 08:30:52 +0000 (UTC)
References:  <87y3mr3loc.fsf@dev.terastrm.net>  <20171128.111715.2283575031970124402.mbj@tail-f.com>   <3C87EF5F-2E1F-4C74-B8FA-28E380AD4C80@gmail.com>
User-agent: mu4e 0.9.18; emacs 25.1.1
From: Kristian Larsson 
To: Mahesh Jethanandani 
Cc: "Sonal Agarwal \(agarwaso\)" , NetMod WG , Robert Wilton , Jeffrey Haas , Kristian Larsson , Martin Bjorklund 
In-reply-to: <3C87EF5F-2E1F-4C74-B8FA-28E380AD4C80@gmail.com>
Date: Thu, 30 Nov 2017 09:30:51 +0100
Message-ID: <87374w2mo4.fsf@dev.terastrm.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] IETF 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, 30 Nov 2017 08:30:56 -0000

Right, it's not about the concept as such, I think we've agreed that
having a global attachment point is fine. It's just that we need to
polish the actual implementation and seeing how it be good to merge the
current PR I suggested we put the global attachment point in a separate
PR. Eases the workflow :)

   kll

Mahesh Jethanandani  writes:

> For now.
>
> Kristian and I discussed this, and agreed that we will pull it in in a new pull request.
>
>> On Nov 29, 2017, at 4:08 PM, Sonal Agarwal (agarwaso)  wrote:
>> 
>> Are you removing the definition  of “global” ACL?
>> 
>> -
>> leaf global {
>> -
>> if-feature global-attachment;
>> -
>> type
>> empty;
>> -
>> description
>> -
>> "ACL rule is global";
>> - }
>> 
>> The remaining changes look fine to me.
>> 
>> Thanks,
>> ---
>> Sonal Agarwal
>> 
>> From: Mahesh Jethanandani >
>> Date: Wednesday, November 29, 2017 at 12:11 PM
>> To: NetMod WG >
>> Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" >, Jeffrey Haas >, Cisco Employee >, Kristian Larsson >, Kristian Larsson >, Martin Bjorklund >
>> Subject: Re: [netmod] IETF ACL model
>> 
>> The updated commit here  takes care of restoring “type" to "acl-type", fixes some indentation issues, adds a choice for “l3" where either “ipv4" or “ipv6" can be selected, and a similar choice at “l4" that allows either “tcp", “udp" or “icmp" to be selected, and removes changes for “global" attachment point. Will add the last item as a separate commit.
>> 
>> Unless I hear objections, I will roll the pr/18 changes into the master branch in 48 hours.
>> 
>>> On Nov 28, 2017, at 2:17 AM, Martin Bjorklund > wrote:
>>> 
>>> Mahesh Jethanandani > wrote:
>>>> An updated version of the model has been posted as part of the PR here
>>>> >.
>>>> 
>>>> The particular change removes any-acl from the model, expands on eth
>>>> (to ethernet), removes acl- prefix for things like acl-type and
>>>> acl-name. Please review.
>>> 
>>> I think 99% of the changes in this PR look good.  The one
>>> exception is the typedef that used to be called "acl-type".  I think
>>> it should still be called "acl-type".  "type" is too broad.  NOTE,
>>> this is just the typedef; the leaf /access-lists/acl/type should keep
>>> its name ("type").
>>> 
>>> 
>>> /martin
>>> 
>>> 
>>> 
>>>> 
>>>>> On Nov 27, 2017, at 5:17 AM, Kristian Larsson >
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> Robert Wilton > writes:
>>>>> 
>>>>>> Thinking about this some more. I'm not sure what it means for the "ACL
>>>>>> Type" to be "any-acl". It seems that the "match any packet" should be
>>>>>> a
>>>>>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a 
>>>>>> type of ACL.
>>>>> 
>>>>> Yes, I agree as so far that any-acl makes no sense as an acl-type. The
>>>>> way I understood acl-type, and the way that vendors have told me it
>>>>> will
>>>>> be used, is to say "this is an IPv4 ACL" and then on an attachment
>>>>> point
>>>>> you can specify that only ACLs of acl-type ipv4-acl can be attached to
>>>>> the interface. That makes perfect sense. I do not see how any-acl can
>>>>> map into this.
>>>>> 
>>>>> I agree that any-acl is logically a type of ACE but we don't have an
>>>>> ace-type and the exact same information can IMHO already be conveyed
>>>>> WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
>>>>> need a feature for it.
>>>>> 
>>>>> From what I can tell the any-acl container in the ACE should be used
>>>>> to
>>>>> explicitly signify a match on "any". Think of IOS style ipv4 acl:
>>>>> permit ip any any
>>>>> 
>>>>> We have to provide a source and destination so this would be a rather
>>>>> explicit mapping of that. However, our structure in this YANG model is
>>>>> just completely different than an IOS command so I don't see why we
>>>>> should try and mimic IOS in the YANg model.
>>>>> 
>>>>> Not specifying a destination IP address means we match on any
>>>>> destination IP address. The same is true for any other field we can
>>>>> match on. Not setting a match implies we don't try to match on that
>>>>> field, thus we allow "any" value. I think the logical continuation of
>>>>> this is that for an ACE with no matches defined at all, we match any
>>>>> packet. I think we can update the text to better explain this.
>>>>> 
>>>>> 
>>>>> 
>>>>>> Otherwise if the ACL type is "any-acl" then this only allows two types
>>>>>> of ACLs to be defined, neither of which seem to be particularly
>>>>>> useful:
>>>>>> (1) An ACL that matches all traffic and permits it, i.e. the same as 
>>>>>> having no ACL at all.
>>>>>> (2) An ACL that matches all traffic and drops.
>>>>>> 
>>>>>> So I think perhaps the answer here is to define neither ACL type 
>>>>>> "any-acl" nor leaf "any". The presumption could be that any ACE that
>>>>>> is
>>>>>> configured to match no fields implicitly matches all packets (because 
>>>>>> all non specified fields are treated as wildcards), and then applies
>>>>>> the
>>>>>> permit/deny rule associated with the ACE. This logic can apply to all 
>>>>>> ACL types.
>>>>> 
>>>>> Yes yes yes :)
>>>>> 
>>>>>  Kristian.
>>>> 
>>>> Mahesh Jethanandani
>>>> mjethanandani@gmail.com 
>>>> 
>> 
>> Mahesh Jethanandani
>> mjethanandani@gmail.com 
>
> Mahesh Jethanandani
> mjethanandani@gmail.com


From nobody Thu Nov 30 01:00: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 CEE50124217 for ; Thu, 30 Nov 2017 01:00:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=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 wiXfumv3pLd5 for ; Thu, 30 Nov 2017 01:00:43 -0800 (PST)
Received: from smtp.dev.terastrm.net (smtp.dev.terastrm.net [IPv6:2003:1f0b:ffde::101]) by ietfa.amsl.com (Postfix) with ESMTP id 18CEB1200C5 for ; Thu, 30 Nov 2017 01:00:43 -0800 (PST)
Received: from lingloi.dev.terastrm.net (unknown [IPv6:2003:1b3b:ffde:1::5]) by smtp.dev.terastrm.net (Postfix) with ESMTPSA id 845143A0303; Thu, 30 Nov 2017 09:00:41 +0000 (UTC)
References: <98e29a71-f6dd-7b42-7c8c-f704ba5b8826@spritelink.net> <1354F18F-43E6-43D5-BFAA-C26BCF47AC56@juniper.net> <5D85F296-FB9F-4BA6-B395-B8CD80ED6864@gmail.com> <20171122.093904.670536605936490886.mbj@tail-f.com>  <87y3mr3loc.fsf@dev.terastrm.net> 
User-agent: mu4e 0.9.18; emacs 25.1.1
From: Kristian Larsson 
To: Robert Wilton 
Cc: Martin Bjorklund , mjethanandani@gmail.com, jhaas@juniper.net, agarwaso@cisco.com, netmod@ietf.org, kll@spritelink.net
In-reply-to: 
Date: Thu, 30 Nov 2017 10:00:40 +0100
Message-ID: <871skg2laf.fsf@dev.terastrm.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] IETF 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, 30 Nov 2017 09:00:50 -0000

Robert Wilton  writes:

> On 27/11/2017 13:17, Kristian Larsson wrote:
>> Robert Wilton  writes:
>>
>>> Thinking about this some more. I'm not sure what it means for the "ACL
>>> Type" to be "any-acl". It seems that the "match any packet" should be a
>>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a
>>> type of ACL.
>> Yes, I agree as so far that any-acl makes no sense as an acl-type. The
>> way I understood acl-type, and the way that vendors have told me it will
>> be used, is to say "this is an IPv4 ACL" and then on an attachment point
>> you can specify that only ACLs of acl-type ipv4-acl can be attached to
>> the interface. That makes perfect sense. I do not see how any-acl can
>> map into this.
>>
>> I agree that any-acl is logically a type of ACE but we don't have an
>> ace-type and the exact same information can IMHO already be conveyed
>> WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
>> need a feature for it.
>>
>> >From what I can tell the any-acl container in the ACE should be used to
>> explicitly signify a match on "any". Think of IOS style ipv4 acl:
>>    permit ip any any
>>
>> We have to provide a source and destination so this would be a rather
>> explicit mapping of that. However, our structure in this YANG model is
>> just completely different than an IOS command so I don't see why we
>> should try and mimic IOS in the YANg model.
>>
>> Not specifying a destination IP address means we match on any
>> destination IP address. The same is true for any other field we can
>> match on. Not setting a match implies we don't try to match on that
>> field, thus we allow "any" value. I think the logical continuation of
>> this is that for an ACE with no matches defined at all, we match any
>> packet. I think we can update the text to better explain this.
>
>>
>>
>>
>>> Otherwise if the ACL type is "any-acl" then this only allows two types
>>> of ACLs to be defined, neither of which seem to be particularly useful:
>>> (1) An ACL that matches all traffic and permits it, i.e. the same as
>>> having no ACL at all.
>>> (2) An ACL that matches all traffic and drops.
>>>
>>> So I think perhaps the answer here is to define neither ACL type
>>> "any-acl" nor leaf "any". The presumption could be that any ACE that is
>>> configured to match no fields implicitly matches all packets (because
>>> all non specified fields are treated as wildcards), and then applies the
>>> permit/deny rule associated with the ACE. This logic can apply to all
>>> ACL types.
>> Yes yes yes :)
> Another area of the current model that I'm not quite convinced about is 
> about the L4 matches (UDP, TCP, ICMP).
>
> Currently the model assumes that if a device can support matching on say 
> UDP fields that they can apply to any type of ACL. However, I think 
> that it is plausible that the UCP, TCP and ICMP fields might only apply 
> to IP ACLs and not Ethernet ACLs.

Indeed, I agree with you. It's IMHO not just plausible but probable.
I think the model is a compromise between reality and perfectly
expressed constraints.

As I've alluded to I think the matches you can use are really not a
condition of the device but of the attachment point. Depending on where
you attach the ACL you will have different capabilities. Accurately
modeling this however, is very difficult and so the use of YANG features
limiting the ACLs themselves (and not what ACL can be attached
somewhere) to convey roughly what things are supported by the device is
a reasonable approximation.

For example, if we have two types of attachment points and one supports
matching on everything whereas the other does not, naturally our YANG
feature set must be the superset of the features supported by the two
attachment points or we could not even define those matches in the ACLs.
Trying to attach an ACL that matches on things that this attachment
point doesn't support will result in a run-time error. Similarly, the
match conditions supported is likely different based on what type of
linecard we have installed, which is AFAIK impossible to express in a
YANG model. We cannot condition this on the type of line card, since
that is state data and we can't do constraints from config to state.

I bet a bunch of the potential match conditions on IP header fields are
not supported by most devices today (think cheap commodity chips). Or
being able to match on TCP and a given port but not on TCP-flags...
there are lots of cases. The question is which ones are important and
"large" enough to distinguish through different acl-types.

Would it be reasonable to put L4 in the acl-type as well? Yes, I think
so, although I'll admit I don't feel strongly about it :)

   kll


> Hence, I was wondering if there should be "acl match type" identity 
> defined for the "l4" field matches?
>
> This would then cause there to be twice as many ACL types identities and 
> features defined, e.g.
>
> eth,
> ipv4,
> ipv6,
> l4
> eth-l4,
> eth-ipv4,
> eth-ipv4-l4,
> eth-ipv6,
> eth-ipv6-l4,
> eth-ipv4-ipv6,
> eth-ipv4-ipv6-l4
> ipv4
> ipv4-l4
> ipv6
> ipv6-l4,
> ipv4-ipv6
> ipv4-ipv6-l4
>
> So, trading off my ACL type combinations for more expressiveness as to 
> what can actually be supported.
>
> Thanks,
> Rob
>
>
>>
>>     Kristian.
>> .
>>


From nobody Thu Nov 30 08:04:15 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 6B5E6127B31; Thu, 30 Nov 2017 08:04:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151205784738.4898.13136810616634690057@ietfa.amsl.com>
Date: Thu, 30 Nov 2017 08:04:07 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc8022bis-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: Thu, 30 Nov 2017 16:04: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-02.txt
	Pages           : 72
	Date            : 2017-11-30

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-02
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-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 Thu Nov 30 19:47: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 C9E93124BFA for ; Thu, 30 Nov 2017 19:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 INxmytkCm4zC for ; Thu, 30 Nov 2017 19:47:22 -0800 (PST)
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 C84731241F5 for ; Thu, 30 Nov 2017 19:47:22 -0800 (PST)
From: Alex Campbell 
To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" 
Thread-Topic: Notications in interface model
Thread-Index: AdNiyXW4eQUrjwP+TRmbZEinuN+pWwHjWIsu
Date: Fri, 1 Dec 2017 03:47:20 +0000
Message-ID: <1512100040970.60458@Aviatnet.com>
References: 
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: multipart/alternative; boundary="_000_151210004097060458Aviatnetcom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Notications in interface 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: Fri, 01 Dec 2017 03:47:24 -0000

--_000_151210004097060458Aviatnetcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

That is a good question.

In retrospect that seems like an obvious omission from the standard YANG.

I'm not aware of any other YANG that adds such a notification.



________________________________
From: netmod  on behalf of Bogaert, Bart (Nokia - =
BE/Antwerp) 
Sent: Wednesday, 29 November 2017 12:29 a.m.
To: netmod@ietf.org
Subject: [netmod] Notications in interface model

Hello,

In the interfaces module we notice support of if-mib feature indicating whe=
ther the IF-MIB is supported or not.  Part of this feature is a flag to ind=
icate whether an SNMP link-up/down trap has to be generated or not.  Lookin=
g at the YANG model itself we notice that it does not foresee any similar c=
apability.  We were wondering whether it has been discussed as part of the =
YANG model definition for interfaces to define a general status change noti=
fication in case an interface goes down or comes up and whether the generat=
ion of such a notification can be enabled or disabled?

Regards, Bart Bogaert



--_000_151210004097060458Aviatnetcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








That is a good question.


In retrospect that seems like an obvious omission from the standard YANG=
.


I'm not aware of any other YANG that adds such a notification.




 








From: netmod <netmod-bo=
unces@ietf.org> on behalf of Bogaert, Bart (Nokia - BE/Antwerp) <bart=
.bogaert@nokia.com>

Sent: Wednesday, 29 November 2017 12:29 a.m.

To: netmod@ietf.org

Subject: [netmod] Notications in interface model

 








Hello,


 


In the interfaces module we not=
ice support of if-mib feature indicating whether the IF-MIB is supported or=
 not.  Part of this feature is a flag to indicate whether an SNMP link=
-up/down trap has to be generated or not. 
 Looking at the YANG model itself we notice that it does not foresee any si=
milar capability.  We were wondering whether it has been discussed as =
part of the YANG model definition for interfaces to define a general status=
 change notification in case an interface
 goes down or comes up and whether the generation of such a notification ca=
n be enabled or disabled?


 


Regards, Bart Bogaert

 


 










--_000_151210004097060458Aviatnetcom_--


From nobody Thu Nov 30 20: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 5786C1270B4; Thu, 30 Nov 2017 20:00:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 VKVsQrIapo5S; Thu, 30 Nov 2017 20:00:56 -0800 (PST)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2461241F5; Thu, 30 Nov 2017 20:00:55 -0800 (PST)
From: Alex Campbell 
To: Kent Watsen , "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7277bis-00
Thread-Index: AQHTaH8uQPbcvjqNt0+Zr1pndKQN96Mt3ffc
Date: Fri, 1 Dec 2017 04:00:54 +0000
Message-ID: <1512100854315.71747@Aviatnet.com>
References: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net>
In-Reply-To: <296363B7-40FF-4FAC-94F9-A7655CD0D111@juniper.net>
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.9]
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-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, 01 Dec 2017 04:00:57 -0000

Hi,=0A=
=0A=
I noticed the table in section 3 has been mangled - it has extra blank line=
s, entries in the wrong side of the table, and a missing pipe in the bottom=
 right corner.=0A=
=0A=
Apart from that this draft looks good to me.=0A=
________________________________________=0A=
From: netmod  on behalf of Kent Watsen =0A=
Sent: Wednesday, 29 November 2017 8:29 a.m.=0A=
To: netmod@ietf.org=0A=
Cc: netmod-chairs@ietf.org=0A=
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00=0A=
=0A=
All,=0A=
=0A=
This starts a two-week working group last call on=0A=
draft-ietf-netmod-rfc7277bis-00.=0A=
=0A=
Please recall that this update's intention is to=0A=
modify the YANG module to be in line with the NMDA=0A=
guidelines [1].  Reviewing the diff between the two=0A=
drafts [2] should reveal just this.=0A=
=0A=
The working group last call ends on December 12.=0A=
Please send your comments to the netmod mailing list.=0A=
=0A=
Positive comments, e.g., "I've reviewed this document=0A=
and believe it is ready for publication", are welcome!=0A=
This is useful and important, even from authors.=0A=
=0A=
[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01=0A=
[2] https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7277bis-00.t=
xt=0A=
=0A=
Thank you,=0A=
Netmod Chairs=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Thu Nov 30 20:12: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 5B29E1274D2; Thu, 30 Nov 2017 20:12:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qkbHxNTFjJpM; Thu, 30 Nov 2017 20:12:42 -0800 (PST)
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 2E3E2124BFA; Thu, 30 Nov 2017 20:12:42 -0800 (PST)
From: Alex Campbell 
To: Kent Watsen , "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-rfc7223bis-00
Thread-Index: AQHTaH8mwis2iZPDB0aqvQnmsEUf+6Mt4+Ch
Date: Fri, 1 Dec 2017 04:12:41 +0000
Message-ID: <1512101561233.63872@Aviatnet.com>
References: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net>
In-Reply-To: <10B5698A-BC7B-432E-A931-9069FA7BB03C@juniper.net>
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.9]
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-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, 01 Dec 2017 04:12:43 -0000

On page 37, "duplex" is mistyped as "duplexx".=0A=
=0A=
Other than this minor error, I believe this draft is ready for publication.=
=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of Kent Watsen =0A=
Sent: Wednesday, 29 November 2017 8:29 a.m.=0A=
To: netmod@ietf.org=0A=
Cc: netmod-chairs@ietf.org=0A=
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00=0A=
=0A=
All,=0A=
=0A=
This starts a two-week working group last call on=0A=
draft-ietf-netmod-rfc7223bis-00.=0A=
=0A=
Please recall that this update's intention is to=0A=
modify the YANG module to be in line with the NMDA=0A=
guidelines [1].  Reviewing the diff between the two=0A=
drafts [2] should reveal just this.=0A=
=0A=
The working group last call ends on December 12.=0A=
Please send your comments to the netmod mailing list.=0A=
=0A=
Positive comments, e.g., "I've reviewed this document=0A=
and believe it is ready for publication", are welcome!=0A=
This is useful and important, even from authors.=0A=
=0A=
[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01=0A=
[2] https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc7223bis-00.t=
xt=0A=
=0A=
Thank you,=0A=
Netmod Chairs=0A=
=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=