From nobody Wed Apr 1 04:52:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A41A898F for ; Wed, 1 Apr 2015 04:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsH_C23HHnt1 for ; Wed, 1 Apr 2015 04:52:48 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 817251A8963 for ; Wed, 1 Apr 2015 04:52:48 -0700 (PDT) Received: from [10.148.226.151] (unknown [10.148.226.151]) by mail.tail-f.com (Postfix) with ESMTPSA id 88BAD1280457; Wed, 1 Apr 2015 13:52:47 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_645424A2-0313-4622-BCB3-983277AD03D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Jan Lindblad In-Reply-To: <201503311950.t2VJoipw097939@idle.juniper.net> Date: Wed, 1 Apr 2015 13:51:16 +0200 Message-Id: <0557C57C-5036-43F1-81A1-E182C13D5572@tail-f.com> References: <201503311950.t2VJoipw097939@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:52:50 -0000 --Apple-Mail=_645424A2-0313-4622-BCB3-983277AD03D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> Another mechanism that's been used quite often for 'implementation >> constants', like max values that vary between implementations or >> over time, is to have a section of the model containing such = constants >> as config true values, but with access control rules effectively >> preventing any operator from ever changing them. Like this: >=20 > Relying on immutable configuration feels like a hack, not a BCP. >=20 > If we want box-specific constants, we should call them out as > a first-class construct. I can certainly see their value, > but they aren't config and shouldn't masquerade as such. A first-class construct, great! I=E2=80=99m all for it. Do we have that = on the Y-list? What would the construct look like? /jan --Apple-Mail=_645424A2-0313-4622-BCB3-983277AD03D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVG9u0AAoJEBSCnbqufIis/dsH/icLSoNLL7tVDIIsFkPB3CLU vfaX7FvTK564bTb/acL/fiFbuqidFOWPy16GYAd1JIzVDAeJz9cB4ZoWC2aN1jTv l/aREnWyA2EMa/LFFkBLXqzLFYKlggxfB+Or5XisNvu9R015wriS+WokM4EWRgYj p9tSBjK4pdHTs2BmBKR1JzUKmHd6jR/IBr+f7dqArlb4IIuMXkzCSZ3g+bMl584q fCZu+k4CVnINr+0w09aJYB2S7AoVUB4SkzZxc1PWg7FD8tbadwp11SIH/CWpGgOs GY1VygUhZusbj/gYTb7L+MZ4ICOc3tRkQTdvQHF1PanJAKMsG9QWKgmLakaq+UI= =Wc1A -----END PGP SIGNATURE----- --Apple-Mail=_645424A2-0313-4622-BCB3-983277AD03D0-- From nobody Wed Apr 1 05:41:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6192C1A8ABA for ; Wed, 1 Apr 2015 05:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5BRCQCWiQre for ; Wed, 1 Apr 2015 05:40:55 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 770811A8A97 for ; Wed, 1 Apr 2015 05:40:55 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 3CE121CC0045; Wed, 1 Apr 2015 14:40:53 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer , Andy Bierman In-Reply-To: <201503311941.t2VJf45r097817@idle.juniper.net> References: <201503311941.t2VJf45r097817@idle.juniper.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 01 Apr 2015 14:40:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 12:40:58 -0000 Phil Shafer writes: > Andy Bierman writes: >>This does not introduce any new YANG statements that are confusing to read. >>I totally disagree that this makes the module unreadable. >>I think it makes the changes to typedefs and groupings very easy >>to see and understand over time. These new names will match the >>protocol names that are introducing a new version >>(eg. ssh-parms, ssh2-parms, http1.1-parms, http2.0-parms) > > I don't think things are nearly that simple. We're at version 17 > of draft-ietf-netmod-routing-cfg and it's not even finished. That's > up to 17 versions of each grouping/typedef threading together in > the style Lada gave, which means the "last call" readers don't get > the nice concise readable document we've been promising them. > > It won't take long for authors to realise that non-global grouping > don't suffer this fate and to shift their BCP to not using our > global groupings/typedefs facilities. > > That said, a module is publishing an API, a binding contract that > shouldn't randomly change. If we accept that groupings and typedefs > are part of that API, then importers should able to depend on their > not changing. Right, this is the point I've been trying to make. If we want YANG authors to use standard modules with typedefs/groupings, they should be easy to read and understand. Being forced to inspect x different versions and figure out which is the right one to use doesn't seem very user-friendly. > > On the other hand, if there groupings aren't flexible, what happens > when you have a bug? Can you not change it because other users > might be relying on the broken behaviour? > > It's really a whole rainbox of ugly, eh? Yes, but still: the priority ranking readers - writers - software developers can give us some guidelines. In my experience from programming and schema languages, systems that require the writer of an importing module to be more explicit about his intentions work generally better than those that try to be clever. Lada > > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 1 06:02:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5734E1A8AF4 for ; Wed, 1 Apr 2015 06:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGNZfXrdU1MF for ; Wed, 1 Apr 2015 06:02:32 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 67CC61A8A6B for ; Wed, 1 Apr 2015 06:02:25 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 6F54F1CC0045; Wed, 1 Apr 2015 15:02:25 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Phil Shafer In-Reply-To: References: <201503311941.t2VJf45r097817@idle.juniper.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 01 Apr 2015 15:02:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 13:02:34 -0000 Andy Bierman writes: > On Tue, Mar 31, 2015 at 12:41 PM, Phil Shafer wrote: >> Andy Bierman writes: >>>This does not introduce any new YANG statements that are confusing to read. >>>I totally disagree that this makes the module unreadable. >>>I think it makes the changes to typedefs and groupings very easy >>>to see and understand over time. These new names will match the >>>protocol names that are introducing a new version >>>(eg. ssh-parms, ssh2-parms, http1.1-parms, http2.0-parms) >> >> I don't think things are nearly that simple. We're at version 17 >> of draft-ietf-netmod-routing-cfg and it's not even finished. That's > > > The change rules do not apply to Internet Drafts. Never did. > They only apply to published RFCs. So if you can find > 17 versions of any MIB or YANG definition across 17 RFCs, > then let me know. > >> up to 17 versions of each grouping/typedef threading together in >> the style Lada gave, which means the "last call" readers don't get >> the nice concise readable document we've been promising them. >> >> It won't take long for authors to realise that non-global grouping >> don't suffer this fate and to shift their BCP to not using our >> global groupings/typedefs facilities. >> > > > The new names are not needed in Internet Drafts. Well, RFC 6020 states the update rules for module revisions and these are bumped in subsequent revisions of an I-D (which is IMO a good thing). Perhaps it might make sense to have a module-level statement like "status experimental;" But even then, promoting an I-D to RFC doesn't mean the contents are perfect. The routing draft was close to becoming an RFC last year - would it change anything on its quality if that had happened? Routing protocol modules are far from being done, and work has just begun on multicast routing. I think it is quite likely it might have some impact on the routing module. And I really don't like the idea of having "grouping route-content" and "grouping route-content-2" in the same module. Lada > The change rules do not apply. People break the change rules > in sec. 10 of RFC 6020 all the time during development > of a YANG module. We only care about published modules. > > >> That said, a module is publishing an API, a binding contract that >> shouldn't randomly change. If we accept that groupings and typedefs >> are part of that API, then importers should able to depend on their >> not changing. >> >> On the other hand, if there groupings aren't flexible, what happens >> when you have a bug? Can you not change it because other users >> might be relying on the broken behaviour? >> > > As I said before, the rigid change rules do not apply to bugs. > If the intent from the start was that the foo-range be 1..20, > but it got published as 1..10 by mistake, then changing it to 1..20 > without a name change is OK because the intent was 1 .. 20 > from the start. We have done this several times with patterns > in IETF typedefs. > > >> It's really a whole rainbox of ugly, eh? >> > > No, because you are wrong about how the change rules work. > > >> Thanks, >> Phil > > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 1 06:21:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54381A90C2 for ; Wed, 1 Apr 2015 06:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl7g3dVDYkgZ for ; Wed, 1 Apr 2015 06:21:43 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BFE1A1A9081 for ; Wed, 1 Apr 2015 06:21:42 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 9FDF31CC0045; Wed, 1 Apr 2015 15:21:42 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201503311945.t2VJjedR097868@idle.juniper.net> References: <201503311945.t2VJjedR097868@idle.juniper.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 01 Apr 2015 15:21:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 13:21:44 -0000 Phil Shafer writes: > Ladislav Lhotka writes: >>BTW, does RFC 6020 forbid importing different revisions of the same >>module using different prefixes? If not, it might solve this issue. > > Sure but if that's the solution, we're in big trouble ;^) > > One of the things I learned looking back at the JUNOS DDL files > while we were working on YANG was that whatever facilities you > provide, people will use them in ways you never intended; often > ways you never conceived of, and sometimes ways that turn your > stomach. But the BCP for how to handle problems like this shouldn't > involve multiple imports. Hopefully it won't be needed that often to use typedefs/grouping from different revisions in the same module. But if it is needed, this solution doesn't look that ugly to me: import ietf-inet-types { revision-date 2013-07-17; prefix inet; } import ietf-inet-types { revision-date 2010-09-24; prefix inet6021; } The intent is clear, confusion not likely, and no extra syntax is needed. Lada > > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 1 07:27:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1A61AC3CD for ; Wed, 1 Apr 2015 07:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaTAz3TPb7TW for ; Wed, 1 Apr 2015 07:27:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B7E1AC3C4 for ; Wed, 1 Apr 2015 07:27:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 46FED1202 for ; Wed, 1 Apr 2015 16:27:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5I9S6htMv5s5 for ; Wed, 1 Apr 2015 16:27:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 16:27:32 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 821712002C for ; Wed, 1 Apr 2015 16:27:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wtBPCrkHwinm; Wed, 1 Apr 2015 16:27:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64F3C2002B; Wed, 1 Apr 2015 16:27:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 293EC32A5758; Wed, 1 Apr 2015 16:27:27 +0200 (CEST) Date: Wed, 1 Apr 2015 16:27:27 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150401142727.GA75021@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:27:36 -0000 Hi, this I-D has been presented at IETF 92 and there was support to adopt this work as WG work item. The abstract of the document says: This document defines a YANG extension statement that allows for defining the syntax of metadata annotions in YANG modules. The document also specifies the XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. This is a call to verify this on the mailing list. Given the support this saw at IETF 92, I will read silence as support. People who see an issue with adopting this document should send an email with an explanation to the WG and/or the WG chairs by April 10th. /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 Apr 1 07:41:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8051AC44C for ; Wed, 1 Apr 2015 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrYd0cxwDOVa for ; Wed, 1 Apr 2015 07:41:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99001AC44B for ; Wed, 1 Apr 2015 07:41:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9CC561202 for ; Wed, 1 Apr 2015 16:41:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pwpyrqz2vqqy for ; Wed, 1 Apr 2015 16:41:08 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 16:41:23 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02FB52002B for ; Wed, 1 Apr 2015 16:41:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id v4H-W8At9tGR; Wed, 1 Apr 2015 16:41:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DF2A20013; Wed, 1 Apr 2015 16:41:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D5D5E32A5825; Wed, 1 Apr 2015 16:41:19 +0200 (CEST) Date: Wed, 1 Apr 2015 16:41:19 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150401144119.GA75145@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] VRFY :12: initialized-by system X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:41:26 -0000 Hi, Martin proposed to move this issue to DEAD instead of implementing Y12-01 since it became clear that the proposed new statement only covers part of the problem. Please speak up by Friday 2015-04-10 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /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 Apr 1 07:43:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AD11ACC82 for ; Wed, 1 Apr 2015 07:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSeHDRIF66z4 for ; Wed, 1 Apr 2015 07:42:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA221AC400 for ; Wed, 1 Apr 2015 07:42:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A2BCFF5A for ; Wed, 1 Apr 2015 16:42:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5wYRaFEjwkkU for ; Wed, 1 Apr 2015 16:42:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 16:42:52 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC6CF20013 for ; Wed, 1 Apr 2015 16:42:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pjrJkOpmWq_x; Wed, 1 Apr 2015 16:42:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FF0D2002B; Wed, 1 Apr 2015 16:42:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2964232A584F; Wed, 1 Apr 2015 16:42:48 +0200 (CEST) Date: Wed, 1 Apr 2015 16:42:48 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150401144248.GB75145@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:43:06 -0000 Hi, following the discussions at IETF 92 and previous virtual interim meetings and the mailing list, the proposal is to adopt Y34-05. Please speak up by Friday 2015-04-10 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /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 Apr 1 07:49:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8EB1ACCF4 for ; Wed, 1 Apr 2015 07:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpm2Czd5TdOY for ; Wed, 1 Apr 2015 07:49:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD9B1ACC91 for ; Wed, 1 Apr 2015 07:49:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BF6DBF64 for ; Wed, 1 Apr 2015 16:49:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id iob5lRTU5qDM for ; Wed, 1 Apr 2015 16:48:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 16:49:00 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D940B20013 for ; Wed, 1 Apr 2015 16:48:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RNmAquuxq-AN; Wed, 1 Apr 2015 16:48:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 158562002C; Wed, 1 Apr 2015 16:48:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E742932A587F; Wed, 1 Apr 2015 16:48:58 +0200 (CEST) Date: Wed, 1 Apr 2015 16:48:58 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150401144858.GC75145@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] VRFY :Y26: allow mandatory nodes in augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:49:03 -0000 Hi, the opinion after discussion of this issue at the IETF 92 meeting was leaning towards adoption of Y26-02, hence the proposal is to adopt Y26-02. Please speak up by Friday 2015-04-10 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /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 Apr 1 07:54:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05D21ACD44 for ; Wed, 1 Apr 2015 07:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9xpSEH2fyBh for ; Wed, 1 Apr 2015 07:53:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479341ACD54 for ; Wed, 1 Apr 2015 07:53:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1AE5511E8 for ; Wed, 1 Apr 2015 16:53:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sHC2lY-jXV1y for ; Wed, 1 Apr 2015 16:53:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 16:53:36 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59D9020013 for ; Wed, 1 Apr 2015 16:53:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 41quNX-a2eqH; Wed, 1 Apr 2015 16:53:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87F5C2002C; Wed, 1 Apr 2015 16:53:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8CF3432A58C9; Wed, 1 Apr 2015 16:53:34 +0200 (CEST) Date: Wed, 1 Apr 2015 16:53:34 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150401145334.GD75145@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] VRFY :Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:54:05 -0000 Hi, this issue was discussed at the IETF 92 meeting and a small team met to look at the encoding. This team made a very minor change of solution Y36-03 and the proposal is now to adopt Y36-03. Please speak up by Friday 2015-04-10 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /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 Apr 1 07:59:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65451ACD52 for ; Wed, 1 Apr 2015 07:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT3Q9TvhXY7Z for ; Wed, 1 Apr 2015 07:59:49 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B971ACD45 for ; Wed, 1 Apr 2015 07:59:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 338191007 for ; Wed, 1 Apr 2015 16:59:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 81-Coe6w_uVa for ; Wed, 1 Apr 2015 16:59:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 1 Apr 2015 16:59:47 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7795120013 for ; Wed, 1 Apr 2015 16:59:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q2Wwvcjsx13a; Wed, 1 Apr 2015 16:59:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F315A2002C; Wed, 1 Apr 2015 16:59:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BF95832A58F8; Wed, 1 Apr 2015 16:59:45 +0200 (CEST) Date: Wed, 1 Apr 2015 16:59:45 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150401145945.GE75145@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] VRFY :57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:59:54 -0000 Hi, this issue was discussed at the IETF 92 meeting and several people raised concerns that the solution causes significant changes (moving towards identifying elements by position/value) and the value of doing this is relatively small. See the meeting minutes for more details. The proposal is now to move Y57 to DEAD. Please speak up by Friday 2015-04-10 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /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 Apr 1 08:21:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58C51ACDB0 for ; Wed, 1 Apr 2015 08:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW2aDDGp9utZ for ; Wed, 1 Apr 2015 08:21:14 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 6AAD51ACDA6 for ; Wed, 1 Apr 2015 08:21:14 -0700 (PDT) Received: by lagg8 with SMTP id g8so39379155lag.1 for ; Wed, 01 Apr 2015 08:21:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vhp6w9BIoO7ikoAHyrO/p2q8mwenq7Q6zd6BGIIAuP4=; b=U+bsWKkvFQl1209i4ErXG+Kq/yXU1KVdNZZpodKqTKvAkyiOvsfcLJU31pDjMrCuvi HMscT4SH9HscdtV1XNm44S6e0y4k5zDoBaGjipc+hIU1KnZ0v3mAwgPhgKQe87xI9uqO z+vhfZebm6jLMurjv+KXdQ1VAXUpHWUWgiQ1WpQBAuNVbBI/dC89BCWeipvUALiWOeMm 3m7A8wklaF6M1SQElRHjL6hBIQ1AC5wjVky3SQsfXwsI+crgifGmV3k7DEuOG+xp/wcP XzMwxCRN519X7eWIDypmoiLBzQY2DxAz73TUVdgEkSSkNVdC0CL2rPyVYiIFcrQwCMk3 XU7A== X-Gm-Message-State: ALoCoQnH3pZ3cQXkvLbN+9H1yXB2YtaFjytTAG0Bh5KDfhd3JtDjp8mNXtmcDt5947LCvGFBVRaR MIME-Version: 1.0 X-Received: by 10.152.1.194 with SMTP id 2mr36354644lao.38.1427901672941; Wed, 01 Apr 2015 08:21:12 -0700 (PDT) Received: by 10.112.98.168 with HTTP; Wed, 1 Apr 2015 08:21:12 -0700 (PDT) In-Reply-To: References: <201503311941.t2VJf45r097817@idle.juniper.net> Date: Wed, 1 Apr 2015 08:21:12 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:21:22 -0000 Hi, Repetition is the key to learning I guess. All the churn in Internet Drafts DOES NOT MATTER! The change control only applies to RFC PUBLICATION. The ietf-routing module is an example of the review process working correctly, because it is not an RFC. It did not "almost" become an RFC. It it still a work-in-progress, The revision gets updates in I-Ds but the change control rules get ignored. Perhaps a YANG 1.1 stmt will make that more clear, but it is not very important. Andy On Wed, Apr 1, 2015 at 6:02 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> On Tue, Mar 31, 2015 at 12:41 PM, Phil Shafer wrote: >>> Andy Bierman writes: >>>>This does not introduce any new YANG statements that are confusing to read. >>>>I totally disagree that this makes the module unreadable. >>>>I think it makes the changes to typedefs and groupings very easy >>>>to see and understand over time. These new names will match the >>>>protocol names that are introducing a new version >>>>(eg. ssh-parms, ssh2-parms, http1.1-parms, http2.0-parms) >>> >>> I don't think things are nearly that simple. We're at version 17 >>> of draft-ietf-netmod-routing-cfg and it's not even finished. That's >> >> >> The change rules do not apply to Internet Drafts. Never did. >> They only apply to published RFCs. So if you can find >> 17 versions of any MIB or YANG definition across 17 RFCs, >> then let me know. >> >>> up to 17 versions of each grouping/typedef threading together in >>> the style Lada gave, which means the "last call" readers don't get >>> the nice concise readable document we've been promising them. >>> >>> It won't take long for authors to realise that non-global grouping >>> don't suffer this fate and to shift their BCP to not using our >>> global groupings/typedefs facilities. >>> >> >> >> The new names are not needed in Internet Drafts. > > Well, RFC 6020 states the update rules for module revisions and these > are bumped in subsequent revisions of an I-D (which is IMO a good > thing). > > Perhaps it might make sense to have a module-level statement like > "status experimental;" > > But even then, promoting an I-D to RFC doesn't mean the contents are > perfect. The routing draft was close to becoming an RFC last year - > would it change anything on its quality if that had happened? > Routing protocol modules are far from being done, and work has just > begun on multicast routing. I think it is quite likely it might have > some impact on the routing module. And I really don't like the idea of > having "grouping route-content" and "grouping route-content-2" in the > same module. > > Lada > >> The change rules do not apply. People break the change rules >> in sec. 10 of RFC 6020 all the time during development >> of a YANG module. We only care about published modules. >> >> >>> That said, a module is publishing an API, a binding contract that >>> shouldn't randomly change. If we accept that groupings and typedefs >>> are part of that API, then importers should able to depend on their >>> not changing. >>> >>> On the other hand, if there groupings aren't flexible, what happens >>> when you have a bug? Can you not change it because other users >>> might be relying on the broken behaviour? >>> >> >> As I said before, the rigid change rules do not apply to bugs. >> If the intent from the start was that the foo-range be 1..20, >> but it got published as 1..10 by mistake, then changing it to 1..20 >> without a name change is OK because the intent was 1 .. 20 >> from the start. We have done this several times with patterns >> in IETF typedefs. >> >> >>> It's really a whole rainbox of ugly, eh? >>> >> >> No, because you are wrong about how the change rules work. >> >> >>> Thanks, >>> Phil >> >> >> Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Wed Apr 1 08:51:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EA11ACDAC for ; Wed, 1 Apr 2015 08:51:50 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUpUv96Xl2Rj for ; Wed, 1 Apr 2015 08:51:49 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 E602C1ACE62 for ; Wed, 1 Apr 2015 08:51:48 -0700 (PDT) Received: by pactp5 with SMTP id tp5so55747681pac.1 for ; Wed, 01 Apr 2015 08:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=demzR+hA0kLuDVhJ93fOzClCOvpJriedk9YbwWbw97k=; b=zF6xFXIAK+k9+rVNhGhQ/GwluAsitd08zmZJU+MTPQKgxi1U4qWiOFWfsomE/PC/mn CtCOdqkukhb5eZqvhm5bX1/6jE61IHiOy7ox8xjRcEkf6o7Lv0quIc55XwWYv/SQrZJQ uP7y1XToAQvIMCK7HLRx4eLgPYW0npbzEOEtXjv4gIMfzh13sT5Heypqm1s/kaLOMVe6 rms0W1YrdeMFke5LuKxDnHQkx/XvUxIOVtnJXSLRR7pZi5E1jOsL3XTtK5IOJDUMKXu1 KQ36vsNGyuPUTqcPTgmEChwsMtOemnD9V5t8K1mXHTTpcOM8nUwIiLkcxnxRhvLd3K3F YVDg== X-Received: by 10.70.103.74 with SMTP id fu10mr10373978pdb.2.1427903508380; Wed, 01 Apr 2015 08:51:48 -0700 (PDT) Received: from ?IPv6:2602:306:cf77:f4c0:b844:b74f:6e06:ca53? ([2602:306:cf77:f4c0:b844:b74f:6e06:ca53]) by mx.google.com with ESMTPSA id z10sm2535123pas.18.2015.04.01.08.51.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Apr 2015 08:51:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_26855F5F-6451-4344-B65A-D87209A902D9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Mahesh Jethanandani In-Reply-To: <20150401144119.GA75145@elstar.local> Date: Wed, 1 Apr 2015 08:51:45 -0700 Message-Id: References: <20150401144119.GA75145@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :12: initialized-by system X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:51:50 -0000 --Apple-Mail=_26855F5F-6451-4344-B65A-D87209A902D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Juergen/Martin, The solution mentions a similar issue with passwd of type crypt-hash. = Not clear what that issue was. On a slightly different note, if a configuration wanted to set a = password, but did not want it displayed on a , or displayed with = =E2=80=98******=E2=80=99, is there a way to specify that today? > On Apr 1, 2015, at 7:41 AM, Juergen Schoenwaelder = wrote: >=20 > Hi, >=20 > Martin proposed to move this issue to DEAD instead of implementing > Y12-01 since it became clear that the proposed new statement only > covers part of the problem. Please speak up by Friday 2015-04-10 if > you disagree with this proposal. >=20 > For more details, see the issues list and the virtual interim meeting > minutes available here: >=20 > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_26855F5F-6451-4344-B65A-D87209A902D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Juergen/Martin,

The solution mentions a similar issue with passwd of type = crypt-hash. Not clear what that issue was.

On a slightly different note, if a = configuration wanted to set a password, but did not want it displayed on = a <get>, or displayed with =E2=80=98******=E2=80=99, is there a = way to specify that today?

On = Apr 1, 2015, at 7:41 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

Hi,

Martin proposed to move this issue to DEAD instead of = implementing
Y12-01 since it became clear that the = proposed new statement only
covers part of the problem. = Please speak up by Friday 2015-04-10 if
you disagree with = this proposal.

For more details, see the = issues list and the virtual interim meeting
minutes = available here:

    http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/js

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

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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_26855F5F-6451-4344-B65A-D87209A902D9-- From nobody Wed Apr 1 08:58:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBE81ACE25 for ; Wed, 1 Apr 2015 08:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V5f-Pux1qGH for ; Wed, 1 Apr 2015 08:58:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C561ACE23 for ; Wed, 1 Apr 2015 08:58:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4D8C01202; Wed, 1 Apr 2015 17:58:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GQGTiR7xTo2Z; Wed, 1 Apr 2015 17:58:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Apr 2015 17:58:38 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AA152002B; Wed, 1 Apr 2015 17:58:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u6U_SuEWhGLL; Wed, 1 Apr 2015 17:58:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8B9320013; Wed, 1 Apr 2015 17:58:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C398832A5A28; Wed, 1 Apr 2015 17:58:34 +0200 (CEST) Date: Wed, 1 Apr 2015 17:58:34 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150401155834.GA75531@elstar.local> Mail-Followup-To: Mahesh Jethanandani , netmod@ietf.org References: <20150401144119.GA75145@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :12: initialized-by system X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:58:42 -0000 I am not sure, are you agreeing with declaring Y12 DEAD or not? /js On Wed, Apr 01, 2015 at 08:51:45AM -0700, Mahesh Jethanandani wrote: > Juergen/Martin, > > The solution mentions a similar issue with passwd of type crypt-hash. Not clear what that issue was. > > On a slightly different note, if a configuration wanted to set a password, but did not want it displayed on a , or displayed with ‘******’, is there a way to specify that today? > > > On Apr 1, 2015, at 7:41 AM, Juergen Schoenwaelder wrote: > > > > Hi, > > > > Martin proposed to move this issue to DEAD instead of implementing > > Y12-01 since it became clear that the proposed new statement only > > covers part of the problem. Please speak up by Friday 2015-04-10 if > > you disagree with this proposal. > > > > For more details, see the issues list and the virtual interim meeting > > minutes available here: > > > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > > > > /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 > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > -- 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 Apr 1 11:21:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809761A1C03 for ; Wed, 1 Apr 2015 11:21:45 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLMPoJO2M9op for ; Wed, 1 Apr 2015 11:21:43 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 078FE1A1B22 for ; Wed, 1 Apr 2015 11:21:43 -0700 (PDT) Received: by obvd1 with SMTP id d1so93003823obv.0 for ; Wed, 01 Apr 2015 11:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=KdPGU0f4kchmvSPT6Lz+NVuMeg4r+1+712pfVjMa3hQ=; b=h0g6EW53KBWCCxigRLwi6AtardPiiMfzoJplqozeOQskq/GYRRRWsLNL9Cn8Z4gFC7 QQzPBky5GXeZS8xr9YB6wJmBNp97/7vcjk9bQpFVNkIpkUczfbn7fFJ4ekHYCAx2Yqd3 fn6eaQqCmX3Gk4ZhVosATXz7VpSDJWjqdd+wsNM2vHAd+9an+eByBopjILRLbvyoI1XY m05KUniJ7Ak8xqLGQ34cUkpkTWmXAJpO628wuSsQjzmbUs3VwEWUKJYHHPHxhInV/wHH iLcGvckARSYqzV8y6Z/07pejC8sn63oNfisdP4aWjVyuC6o2Cx9kR2yu4AbbreiyWXX0 s4Cg== X-Received: by 10.60.34.193 with SMTP id b1mr42106444oej.19.1427912502438; Wed, 01 Apr 2015 11:21:42 -0700 (PDT) MIME-Version: 1.0 References: <20150401144119.GA75145@elstar.local> <20150401155834.GA75531@elstar.local> In-Reply-To: <20150401155834.GA75531@elstar.local> From: Mahesh Jethanandani Date: Wed, 01 Apr 2015 18:21:42 +0000 Message-ID: To: Juergen Schoenwaelder Content-Type: multipart/alternative; boundary=089e01160c047a71af0512adc91c Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :12: initialized-by system X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:21:45 -0000 --089e01160c047a71af0512adc91c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am agreeing that Y12 can be declared dead, if a clear solution cannot be provided. But I did want to say that having the capability would be nice. E.g. MTU set on a interface could be learnt from the system rather than having the user specify it. I was also seeking clarification on what was the similarity with passwd of type crypt-hash. The system will set a value for passwd?? On Apr 1, 2015, at 8:58 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: I am not sure, are you agreeing with declaring Y12 DEAD or not? /js On Wed, Apr 01, 2015 at 08:51:45AM -0700, Mahesh Jethanandani wrote: Juergen/Martin, The solution mentions a similar issue with passwd of type crypt-hash. Not clear what that issue was. On a slightly different note, if a configuration wanted to set a password, but did not want it displayed on a , or displayed with =E2=80=98******= =E2=80=99, is there a way to specify that today? On Apr 1, 2015, at 7:41 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: Hi, Martin proposed to move this issue to DEAD instead of implementing Y12-01 since it became clear that the proposed new statement only covers part of the problem. Please speak up by Friday 2015-04-10 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /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 Mahesh Jethanandani mjethanandani@gmail.com --=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 --089e01160c047a71af0512adc91c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am agre= eing that Y12 can be declared dead, if a clear solution cannot be provided.= But I did want to say that having the capability would be nice. E.g. MTU s= et on a interface could be learnt from the system rather than having the us= er specify it.

I was also seeking clarification on what = was the similarity with passwd of type crypt-hash. The system will set a va= lue for passwd??

On A= pr 1, 2015, at 8:58 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de> wrote:

I am not sure, are you agreeing wit= h declaring Y12 DEAD or not?

/js

On Wed, Apr 01, 2015 at 08:5= 1:45AM -0700, Mahesh Jethanandani wrote:
Juerg= en/Martin,

The solution mentions a similar issue with passwd of type= crypt-hash. Not clear what that issue was.

On a slightly different = note, if a configuration wanted to set a password, but did not want it disp= layed on a <get>, or displayed with =E2=80=98******=E2=80=99, is ther= e a way to specify that today?

On Apr 1, 2= 015, at 7:41 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university= .de> wrote:

Hi,

Martin proposed to move this issue to = DEAD instead of implementing
Y12-01 since it became clear that the propo= sed new statement only
covers part of the problem. Please speak up by Fr= iday 2015-04-10 if
you disagree with this proposal.

For more deta= ils, see the issues list and the virtual interim meeting
minutes availab= le here:

=C2=A0=C2=A0=C2=A0http://svn.tools.ietf.org/svn/wg/ne= tmod/yang-1.1/

/js

--
Juergen Schoenwaelder =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Jacobs University Bremen= gGmbH
Phone: +49 421 200 3587 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Campus Ring 1 | 28759 Bremen | Germany
Fax: =C2=A0=C2=A0+49 421 200 3103 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0<http://www.jacobs-university.de/>

____= ___________________________________________
netmod mailing list
netmod@ietf.org
http= s://www.ietf.org/mailman/listinfo/netmod

Mahesh Jet= hanandani
m= jethanandani@gmail.com






--
J= uergen Schoenwaelder =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Campus Ring 1 | 28759= Bremen | Germany
Fax: =C2=A0=C2=A0+49 421 200 3103 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<http://www.jacobs-univer= sity.de/>

Mahesh Jethanandani





--089e01160c047a71af0512adc91c-- From nobody Wed Apr 1 11:55:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4CB1A8A3A for ; Wed, 1 Apr 2015 11:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DR_J1_2Uj6E for ; Wed, 1 Apr 2015 11:55:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 71F2B1A88A1 for ; Wed, 1 Apr 2015 11:55:32 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E3351280477; Wed, 1 Apr 2015 20:55:31 +0200 (CEST) Date: Wed, 01 Apr 2015 20:55:49 +0200 (CEST) Message-Id: <20150401.205549.1630889583041998252.mbj@tail-f.com> To: mjethanandani@gmail.com From: Martin Bjorklund In-Reply-To: References: <20150401155834.GA75531@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :12: initialized-by system X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 18:55:41 -0000 Hi, Mahesh Jethanandani wrote: > I am agreeing that Y12 can be declared dead, if a clear solution cannot be > provided. But I did want to say that having the capability would be nice. > E.g. MTU set on a interface could be learnt from the system rather than > having the user specify it. This use case (MTU) should likely not be modelled w/ initialized-by system; the way it would be done is that if the user doesn't configure it, the system uses some value operationally - but it does not modify the configuration with this value, which initialized-by system would indicate. > I was also seeking clarification on what was the similarity with passwd of > type crypt-hash. The system will set a value for passwd?? If the user sends a clear text value for crypt-hash, the server will calculate the hash and store the hased value in the configuration. This is similar to initialized-by system in that the server doesn't store exactly what the user provided. /martin From nobody Wed Apr 1 14:04:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A611A92E3 for ; Wed, 1 Apr 2015 14:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw5fwFbqmKNk for ; Wed, 1 Apr 2015 14:03:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3969C1A913F for ; Wed, 1 Apr 2015 14:03:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B3770124E; Wed, 1 Apr 2015 23:03:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ppeEN1Gl8Eqh; Wed, 1 Apr 2015 23:03:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Apr 2015 23:03:57 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 089F02002B; Wed, 1 Apr 2015 23:03:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9DtGb73gXRV4; Wed, 1 Apr 2015 23:03:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F6E420013; Wed, 1 Apr 2015 23:03:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C40E032A5CA0; Wed, 1 Apr 2015 23:03:54 +0200 (CEST) Date: Wed, 1 Apr 2015 23:03:54 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150401210354.GA76225@elstar.local> Mail-Followup-To: Martin Bjorklund , mjethanandani@gmail.com, netmod@ietf.org References: <20150401155834.GA75531@elstar.local> <20150401.205549.1630889583041998252.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401.205549.1630889583041998252.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :12: initialized-by system X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:04:01 -0000 On Wed, Apr 01, 2015 at 08:55:49PM +0200, Martin Bjorklund wrote: > Hi, > > Mahesh Jethanandani wrote: > > I am agreeing that Y12 can be declared dead, if a clear solution cannot be > > provided. But I did want to say that having the capability would be nice. > > E.g. MTU set on a interface could be learnt from the system rather than > > having the user specify it. > > This use case (MTU) should likely not be modelled w/ initialized-by > system; the way it would be done is that if the user doesn't configure > it, the system uses some value operationally - but it does not modify > the configuration with this value, which initialized-by system would > indicate. Exactly, this example has nothing to do with Y12. > > I was also seeking clarification on what was the similarity with passwd of > > type crypt-hash. The system will set a value for passwd?? > > If the user sends a clear text value for crypt-hash, the server will > calculate the hash and store the hased value in the configuration. > This is similar to initialized-by system in that the server doesn't > store exactly what the user provided. Yes. The details are in the crypt-hash typedef defined in RFC 7317. /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 Apr 1 20:54:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B61B2A6B for ; Wed, 1 Apr 2015 20:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrozVTH_JGEo for ; Wed, 1 Apr 2015 20:54:36 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 00CC41B2A68 for ; Wed, 1 Apr 2015 20:54:35 -0700 (PDT) Received: by lboc7 with SMTP id c7so50569152lbo.1 for ; Wed, 01 Apr 2015 20:54:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XoZdv/zhCL4b5YF6DH4Fe0uQAn6Ta6K9K+RkcPewhaM=; b=FHapT3mAh9cfn1Ky68+O6AkXuVNd7kTUl5rlQ6QXqHw+TTmYSMBN5iyuJkgpQHp7ld K99FjCWGQvNnAqkjoe1tashJiMV3kUklTu0mZFjBN63deJLIm5b82oCVIbbAib/VO2jk 8VPMLuLZX3aYdt8c203mHArhH+KKw+VEQks7XZhcf3dvS12gSa/CTOcLQldM6eC0il4E ZqVsxBIlciVwgYDcAIXESLVuh7wbV4bJI44KOkDv7JdNUXrkfdDBiw7O1eLYbTBVDadw jdGj57e/m3hbVGhrAjXYIr9jqyFKCT+fMHJG7nnxQGI8SjKw0I8YwJ9cI8y1fU02WXm0 I/6A== X-Gm-Message-State: ALoCoQl7x+nYayslryAoXGavYoSRbA3OrXF0IlO+p9UXy8dUvjSCbrVbkkx2e09KVzR3Jd/HVBgb MIME-Version: 1.0 X-Received: by 10.152.37.40 with SMTP id v8mr38986228laj.123.1427946874453; Wed, 01 Apr 2015 20:54:34 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 1 Apr 2015 20:54:34 -0700 (PDT) In-Reply-To: <201503311931.t2VJVB6f097667@idle.juniper.net> References: <201503311931.t2VJVB6f097667@idle.juniper.net> Date: Wed, 1 Apr 2015 20:54:34 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:54:38 -0000 On Tue, Mar 31, 2015 at 12:31 PM, Phil Shafer wrote: > Andy Bierman writes: >>I am curious -- if import-by-revision is such a great way to manage >>external dependencies, then why aren't there any programming languages >>that work this way? > > Most systems have to construct a versioning mechanism after the > fact, via installation tools or library systems. There are > approximately one zillion means of doing this, mainly consed up > from the depths of the installation system programmers' minds. To > my mind, the sheer volume of version-based installation tools (and > the number of times they fail) infers that no one's got it right > yet. > So are you saying that humans reading and writing YANG modules will do a better job of managing a rats nest of complex dependencies better than tools? We will end up so one cannot even read a YANG module without complex tools. With the current proposal, an import without revision is tied to a revision picked by the server, known only in the advertisement. The typedef and grouping drift does not go away at all. So what does this proposal really fix that just doing nothing doesn't fix as well? I would prefer a simple and deterministic approach: * if a server has multiple revisions of any protocol-accessible objects, then the most recent revision of these revisions is the one that is advertised. * the revision used for augment is determined by the augmented module, not the augmenting module(s). > In YANG we're attempting to address this internally. Doesn't mean > we're wrong, just that we know we can't depend on an external > technology to do this for us in a portable, interoperable way. > Lacking an "install" phase, we can't really count on apt-get, yum, > pip, gem, ninite, yast, pkg, brew, dpkg, port, fink, pacman, ipkg, > etc [1] to do the work for us. > > Thanks, > Phil Andy > > [1] Okay, that's off the top of my head. I stopped before I reached > to wikipedia: > http://en.wikipedia.org/wiki/List_of_software_package_management_systems > > [2] Yes, there's really a "petget", the installer for "Puppy Linux". > Gag me with a chew toy! > > [3] No, I really have no clue how to spell the past tense of "cons". From nobody Thu Apr 2 05:42:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6871A8A3E for ; Thu, 2 Apr 2015 05:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOnMmZH5qWwc for ; Thu, 2 Apr 2015 05:41:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5618A1A8A39 for ; Thu, 2 Apr 2015 05:41:55 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 1D12F1280A55 for ; Thu, 2 Apr 2015 14:41:54 +0200 (CEST) Date: Thu, 02 Apr 2015 14:42:31 +0200 (CEST) Message-Id: <20150402.144231.1437388601493142848.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 12:42:00 -0000 Hi, I have reviewd this document and have some comments: o typedef severity should have a reference to RFC 5424. o Given that the standard defines a fixed set of 24 facilities, it seems odd that the facilities are modelled as identities, and not as an enumeration. Using identities gives the impression that this is an extensible set of values. o Why do we have these: feature file-logging-structured-data feature remote-logging-structured-data I would assume that if the device supports structured data, it would do so regardless of logging method? I.e., a single feature "structured-data" would be enough? But is this (structured data) typically configurable in implementations, and if it is, it is configurable per "action" like this? o I do not understand what the global-logging-action does. The description says: Global logging represents the ability to perform global log message suppression. Does this mean that the global level *suppresses* matching messages? The text talks about "group level suppression", but the model has "global logging action". This is a bit confusing. So what does this configuration mean: Does it means that no messages are suppressed, or that all messages are suppressed? o The usage of the in-memory log buffer is a bit unclear. I think the spec needs to explain how this log buffer is supposed to be used. Perhaps we should also provide a mechanism to read this buffer? I.e., provide a config false list of buffered messages? o It is important to remember that the names of choices and cases are not visible in the instantiated data. Thus, when you have nice descriptive names for the choices and cases, and these names convey some meaning, this meaning is lost when you just look at instance data. For example, this instance: warning does not convey the meaning of the chosen case, which is called "logging-facility-all". I.e., from the instance data above you cannot tell that we're actually matching on all facilities. I think you said you are changing this grouping a bit, and if so I will have a look in the next revision. o For the remote logging, it seems only UDP is supported. I think the data model should follow the recommendation in section 3 in draft-schoenw-netmod-yang-pattern-00 so that multiple transports can be supported. Maybe this model should support the TLS and DTLS transports? o For remote logging, I think the "vrf-name" leaf should be removed. It is not clear how this maps to the routing work, and it can always be augmented later, or a vendor can do a proprietary augmentation. o For remote logging is it a good idea to have "source-interface"? If so, should we have this in all our models for outgoing connections? o leaf file-name is supposed to refer to a local file. If inet:uri is supposed to be used, it should state that this MUST be with scheme "file" (i.e., on the form "file:..."). But is inet:uri the correct type to use? o leaf file-number has a default of 1. Isn't this a bit small for a file archive? o leaf file-size has a default of 262144. Why this number? o leaf file-permission has the teo values "world-readable" and "no-world-readable". This seems a bit restrictive for some kinds of systems, and it is also underspecified (what exactly does "no-world-readable" mean?). Maybe it is better to leave this out? o I think some nodes can get better names. Maybe: syslog / log-actions / global console buffer file remote terminal This allows for future nodes (non-actions) directly underneath "syslog", and it removes the "-logging-action" suffix everywhere. I also suggest you remove the containers "logging-advanced-level-processing" and "logging-match-processing" and just move their leafs up one level: global / logging-level-scope /... select-message-severity pattern-match Some other suggestions: OLD: logging-files NEW: log-file (note singluar) OLD: file-name NEW: name (remove redundant prefix) OLD: file-logging-strucured-data NEW: structured-data (remove redundant prefix) OLD: file-logging-archive NEW: file-archive OLD: file-number NEW: number-of-files OLD: file-size NEW: max-file-size OLD: remote-logging-structured-data NEW: structured-data (remove redundant prefix) o I don't understand how the leaf "select-message-severity" is supposed to be used. o I think container syslog-sign should have: reference "RFC 5848: Signed Syslog Messages"; (Yes I know this is also defined on the top-level, but it is nice to have the reference available when it is used.) BTW this is the style the RFC editor prefers, so you may want to change the current top-level reference to: reference "RFC 5424: The Syslog Protocol RFC 5848: Signed Syslog Messages"; o I don't know anything about signed syslog messages, but are these config params all that are needed? /martin From nobody Thu Apr 2 05:46:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3AB1A8A17 for ; Thu, 2 Apr 2015 05:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRafPMR5CELs for ; Thu, 2 Apr 2015 05:46:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C976C1A8A07 for ; Thu, 2 Apr 2015 05:46:32 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 1761D1280A55 for ; Thu, 2 Apr 2015 14:46:32 +0200 (CEST) Date: Thu, 02 Apr 2015 14:47:00 +0200 (CEST) Message-Id: <20150402.144700.2146034574780260287.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] New 6087bis issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 12:46:34 -0000 Hi, Here's a list of some things that maybe should be added to 6087bis. Some of them are stylistic; I don't know if we should add those or not. 3.6 References The RFC Editor prefers the style: reference "RFC : "; reference "RFC <NNNN>: <very long title that spans more than one line>"; I think we should document this. 4.1 Update this wrt. example modules. Should they be marked with CODE at all? 5.1. Module Naming Conventions Add: IETF modules SHOULD (MUST?) start with "ietf-". Example modules SHOULD start with "example-" or "ex-". 5.2. Identifiers Add: avoid unnecessary prefixes on names. BAD: list interface { ... leaf interface-name { ... } leaf interface-type { ... } } GOOD: list interface { ... leaf name { ... } leaf type { ... } } use-hypened-names 5.8 Namespace Assignments OLD: The following examples of non-Standards-Track modules are only suggestions. There are no guidelines for this type of URN in this document: http://example.com/ns/example-interfaces http://example.com/ns/example-system NEW: There are no guidelines for non-Standards-Track modules. Example modules SHOULD use RFC 6963 style URNs: urn:example:<module-name> Or 2606-style http://example.com/... /martin From nobody Thu Apr 2 06:52:49 2015 Return-Path: <balazs.lengyel@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670FE1A8FD6 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 06:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02uwwldo0_yv for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 06:52:46 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653011A9031 for <netmod@ietf.org>; Thu, 2 Apr 2015 06:52:46 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-6b-551d49acf71b Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.F2.01716.CA94D155; Thu, 2 Apr 2015 15:52:44 +0200 (CEST) Received: from [159.107.197.226] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.210.2; Thu, 2 Apr 2015 15:52:43 +0200 Message-ID: <551D49AB.70902@ericsson.com> Date: Thu, 2 Apr 2015 15:52:43 +0200 From: Balazs Lengyel <balazs.lengyel@ericsson.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Bjorklund <mbj@tail-f.com>, <netmod@ietf.org> References: <20150402.144700.2146034574780260287.mbj@tail-f.com> In-Reply-To: <20150402.144700.2146034574780260287.mbj@tail-f.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvje4aT9lQg5e3FSy6u5+xW8y/2Mjq wOSxZMlPJo+NvxazBDBFcdmkpOZklqUW6dslcGW873zNUtAtWrFx8lGmBsZJ/F2MnBwSAiYS +xd3skDYYhIX7q1n62Lk4hASOMoo8f9lJ5SzhlHi36OzzF2MHBy8ApoSDZu4QBpYBFQktlzf BtbMJmAkMbX/PJgtKhAl0fOnmw3E5hUQlDg58wkLSKuIgIXE2bUuIGFhAT+JPdcusILYQgIO Eu0bljCBlHAKOEq8fmIGYjIL2Es82FoGUsEsIC+x/e0cZohqDYmHF/6yTmAUmIVk/iyEjllI OhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzHg1t+6+5gXP3a8RCjAAejEg/vg1sy oUKsiWXFlbmHGKU5WJTEee2MD4UICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCxy0NRV+q+6 YlJg0I6Y3I2X1AxyDM8uD3ResjXowPPH4qkvtPitJJLSXy7+18sXfOO5FNPMzFPK2ms3i00L idy3SDmozkbrlU713zOXFj88Layac0VjpW9K+sO42O/HdgZ7K8SVN5w5ZtGn/m7btDp51hM7 MpsvL15xba7W0wcrLMpbiu88mqzEUpyRaKjFXFScCACx2/Y7KAIAAA== Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/dP6VZ2QSK9-Dut3Vj2ITGvckS88> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 13:52:48 -0000 Hello, As indicated by operators in Dallas and as experienced by Ericsson as well, it is sometimes not easy to find the status data for a given bit of configuration (interface, route, etc.). Often the state and configuration are handled in parallel subtrees with the same structure. However this is not part of the guidelines. Also counters are often separated from state data again without a clear guideline to connect statistics with the config. I believe 6087 should provide guidelines how to find state and staistics information for a give piece of configuration. E.g. how do find the number of outgoing packets for an interface? regards Balazs On 2015-04-02 14:47, Martin Bjorklund wrote: > Hi, > > Here's a list of some things that maybe should be added to 6087bis. > Some of them are stylistic; I don't know if we should add those or > not. > > > > 3.6 References > > The RFC Editor prefers the style: > > reference > "RFC <NNNN>: <title>"; > > reference > "RFC <NNNN>: <very long title that spans > more than one line>"; > > > I think we should document this. > > > 4.1 > > Update this wrt. example modules. Should they be marked with CODE at > all? > > > 5.1. Module Naming Conventions > > > Add: IETF modules SHOULD (MUST?) start with "ietf-". > > Example modules SHOULD start with "example-" or "ex-". > > > 5.2. Identifiers > > Add: avoid unnecessary prefixes on names. > > BAD: > > list interface { > ... > leaf interface-name { ... } > leaf interface-type { ... } > } > > GOOD: > > list interface { > ... > leaf name { ... } > leaf type { ... } > } > > > use-hypened-names > > > > 5.8 Namespace Assignments > > OLD: > > The following examples of non-Standards-Track modules are only > suggestions. There are no guidelines for this type of URN in this > document: > > http://example.com/ns/example-interfaces > > http://example.com/ns/example-system > > NEW: > > There are no guidelines for non-Standards-Track modules. > > Example modules SHOULD use RFC 6963 style URNs: > > urn:example:<module-name> > > Or 2606-style > > http://example.com/... > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Apr 2 07:29:17 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0771A916D for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 07:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IAfP6GiDQ09 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 07:29:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD991ACEB3 for <netmod@ietf.org>; Thu, 2 Apr 2015 07:29:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 143751124; Thu, 2 Apr 2015 16:29:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mRMTJX1H7oBU; Thu, 2 Apr 2015 16:28:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Apr 2015 16:29:10 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 738D020013; Thu, 2 Apr 2015 16:29:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sbmP_srUafJr; Thu, 2 Apr 2015 16:29:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9135B2002B; Thu, 2 Apr 2015 16:29:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 36A0E32A6D48; Thu, 2 Apr 2015 16:29:07 +0200 (CEST) Date: Thu, 2 Apr 2015 16:29:06 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Balazs Lengyel <balazs.lengyel@ericsson.com> Message-ID: <20150402142904.GA79132@elstar.local> Mail-Followup-To: Balazs Lengyel <balazs.lengyel@ericsson.com>, Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org References: <20150402.144700.2146034574780260287.mbj@tail-f.com> <551D49AB.70902@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551D49AB.70902@ericsson.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/KPlI_Ns64IRcqN9iGlmYzBZHVVE> Cc: netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 14:29:16 -0000 On Thu, Apr 02, 2015 at 03:52:43PM +0200, Balazs Lengyel wrote: > Hello, > As indicated by operators in Dallas and as experienced by Ericsson as > well, it is sometimes not easy to find the status data for a given bit > of configuration (interface, route, etc.). Often the state and > configuration are handled in parallel subtrees with the same structure. > However this is not part of the guidelines. Also counters are often > separated from state data again without a clear guideline to connect > statistics with the config. > I believe 6087 should provide guidelines how to find state and staistics > information for a give piece of configuration. E.g. how do find the > number of outgoing packets for an interface? It is hard to believe this is a problem without knowing that data models for which this is a problem. Since you mention interfaces, I am even more confused what the problem is. RFC 7223 has a rather clear structure - is it really difficult to find the proper counter there? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 2 07:49:49 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B024E1B2D1C for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 07:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG0Ksrjdw0OE for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 07:49:43 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 3F30A1A9138 for <netmod@ietf.org>; Thu, 2 Apr 2015 07:49:38 -0700 (PDT) Received: by lagg8 with SMTP id g8so61945939lag.1 for <netmod@ietf.org>; Thu, 02 Apr 2015 07:49:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Gllj8TWe6ILZWiIDWuWyWal6JM4o0AHYf8xK8mOYKJY=; b=XctoUmFUILR6UHDtInzJZN873bnc/X4Jr8IL1CkmdxyxhSDboa4zRTfWxGMOCfqAsm JRUyQRl+7YEY3JEVpE01iMOjJJUzUYFESRDu591HqFcZyryYuLTg7/NMmsMLbMhnODfJ Yjfk24BATx8OJqrDl2yZJlRnB6kmgHAoj8yDRYPSgyGyx2zO++g1iqx9hqpfroGRM+40 yo/wcLUoNsR8s6PS9xr1eLTHxnss9qlzhFa/FwQqMCDqE0zpgi3f6PkNxLdk19mOxDMu SiU2l/HETNaSUQFkGNXXC5wDumEdL1ekyY90NRV8pu0NqKARGQFrysAXgxU/YYJvuGao Tvew== X-Gm-Message-State: ALoCoQmz1qYl5WQ2Sjzki5rRUEwNmu9njZi1q1B6vQEsX9ibJbtW8n2tFEHZuXh/fBhSyUCqt+Hd MIME-Version: 1.0 X-Received: by 10.112.205.103 with SMTP id lf7mr40167493lbc.37.1427986176653; Thu, 02 Apr 2015 07:49:36 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Apr 2015 07:49:36 -0700 (PDT) In-Reply-To: <551D49AB.70902@ericsson.com> References: <20150402.144700.2146034574780260287.mbj@tail-f.com> <551D49AB.70902@ericsson.com> Date: Thu, 2 Apr 2015 07:49:36 -0700 Message-ID: <CABCOCHR1gwgGN4P-rJriZ7Z48Bcd_1kJdqtf+bqa-nDFwc9mOA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Balazs Lengyel <balazs.lengyel@ericsson.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/OTWI_N8C80NIidJpedNKbQ4EagM> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 14:49:48 -0000 Hi, You need to read the description-stmts of the relevant data nodes to find out where other related data nodes can be found. IMO the sibling config/state approach should only be used if the state can exist without the config. If I have an ACL or some filter that may be nested within lists with lots of keys, then it is extremely wasteful to replicate all the scaffolding and keys, just to store a couple counters for that ACL. It is much better to just put the counters in the ACL entry. But many times the set of interesting objects related to some config is far more complicated than that, so the description-stmt is the only place to document this information. Andy On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote: > Hello, > As indicated by operators in Dallas and as experienced by Ericsson as well, > it is sometimes not easy to find the status data for a given bit of > configuration (interface, route, etc.). Often the state and configuration > are handled in parallel subtrees with the same structure. However this is > not part of the guidelines. Also counters are often separated from state > data again without a clear guideline to connect statistics with the config. > I believe 6087 should provide guidelines how to find state and staistics > information for a give piece of configuration. E.g. how do find the number > of outgoing packets for an interface? > regards Balazs > > On 2015-04-02 14:47, Martin Bjorklund wrote: >> >> Hi, >> >> Here's a list of some things that maybe should be added to 6087bis. >> Some of them are stylistic; I don't know if we should add those or >> not. >> >> >> >> 3.6 References >> >> The RFC Editor prefers the style: >> >> reference >> "RFC <NNNN>: <title>"; >> >> reference >> "RFC <NNNN>: <very long title that spans >> more than one line>"; >> >> >> I think we should document this. >> >> >> 4.1 >> >> Update this wrt. example modules. Should they be marked with CODE at >> all? >> >> >> 5.1. Module Naming Conventions >> >> >> Add: IETF modules SHOULD (MUST?) start with "ietf-". >> >> Example modules SHOULD start with "example-" or "ex-". >> >> >> 5.2. Identifiers >> >> Add: avoid unnecessary prefixes on names. >> >> BAD: >> >> list interface { >> ... >> leaf interface-name { ... } >> leaf interface-type { ... } >> } >> >> GOOD: >> >> list interface { >> ... >> leaf name { ... } >> leaf type { ... } >> } >> >> >> use-hypened-names >> >> >> >> 5.8 Namespace Assignments >> >> OLD: >> >> The following examples of non-Standards-Track modules are only >> suggestions. There are no guidelines for this type of URN in this >> document: >> >> http://example.com/ns/example-interfaces >> >> http://example.com/ns/example-system >> >> NEW: >> >> There are no guidelines for non-Standards-Track modules. >> >> Example modules SHOULD use RFC 6963 style URNs: >> >> urn:example:<module-name> >> >> Or 2606-style >> >> http://example.com/... >> >> >> >> /martin >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 2 07:58:45 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6096C1B2B14 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 07:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msKaUUzGOEvp for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 07:58:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2431A912A for <netmod@ietf.org>; Thu, 2 Apr 2015 07:58:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D0131253; Thu, 2 Apr 2015 16:58:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3dZ6LefDmmSi; Thu, 2 Apr 2015 16:58:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Apr 2015 16:58:41 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C178F2002B; Thu, 2 Apr 2015 16:58:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EIqqJ5qvMRbc; Thu, 2 Apr 2015 16:58:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3D7220013; Thu, 2 Apr 2015 16:58:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F1D0832A6E45; Thu, 2 Apr 2015 16:58:38 +0200 (CEST) Date: Thu, 2 Apr 2015 16:58:38 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150402145838.GA79268@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Phil Shafer <phil@juniper.net>, Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org> References: <201503311941.t2VJf45r097817@idle.juniper.net> <m2384khvhn.fsf@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <m2384khvhn.fsf@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/gp172GDtJXx89ODnELAvaVnDIV8> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 14:58:44 -0000 On Wed, Apr 01, 2015 at 02:40:52PM +0200, Ladislav Lhotka wrote: > > Right, this is the point I've been trying to make. If we want YANG > authors to use standard modules with typedefs/groupings, they should be > easy to read and understand. Being forced to inspect x different > versions and figure out which is the right one to use doesn't seem very > user-friendly. > This is actually simply. If foo.2 replaces foo.1, you mark foo.1 as obsolete and tools will tell you that you use something that is marked obsolete. In some cases, using what is obsolete is what you want, in other cases you go and see whether the new definition foo.2 works for you. > In my experience from programming and schema languages, systems that > require the writer of an importing module to be more explicit about his > intentions work generally better than those that try to be clever. Exactly. This is why you write uses foo.1 or uses foo.2 instead of just uses foo and have magic applied that figures out what foo stands for. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 2 08:10:45 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C031B2CF5 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 08:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUX95SBORPx5 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 08:10:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510041B2D01 for <netmod@ietf.org>; Thu, 2 Apr 2015 08:10:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1EB581288; Thu, 2 Apr 2015 17:10:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FKtm7mkmlE8p; Thu, 2 Apr 2015 17:10:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Apr 2015 17:10:31 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50A782002C; Thu, 2 Apr 2015 17:10:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id E4e5K0dfXt0w; Thu, 2 Apr 2015 17:10:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 111A22002B; Thu, 2 Apr 2015 17:10:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E29A132A6E92; Thu, 2 Apr 2015 17:10:29 +0200 (CEST) Date: Thu, 2 Apr 2015 17:10:29 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Phil Shafer <phil@juniper.net> Message-ID: <20150402151029.GB79268@elstar.local> Mail-Followup-To: Phil Shafer <phil@juniper.net>, Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org> References: <20150331072754.GB70057@elstar.local> <201503311954.t2VJs6nd098003@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201503311954.t2VJs6nd098003@idle.juniper.net> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Pyc6ZoYVlxfItIoCToMO1M0Omxs> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 15:10:44 -0000 On Tue, Mar 31, 2015 at 03:54:06PM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >The only variation to consider is to be less strict for enums and > >bits, that is allow additions since enums and bits are often used for > >(controlled) extensions. In other words, to learn the actual value set > >supported by an implementation, one has to ask the implementation > >(similar to identities). (This is what SMIv2 allowed, you can add > >named numbers to BITS and enumerated INTEGER types, but no other > >changes to types are allowed.) > > I'm confused; how does one ask the implementation for the list > of supported identities? > There was such a proposal somewhere. Andy might recall. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 2 08:13:29 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B671A9308 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 08:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeamEPOGt_hG for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 08:13:27 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257871B2CC9 for <netmod@ietf.org>; Thu, 2 Apr 2015 08:13:25 -0700 (PDT) Received: by lbdc10 with SMTP id c10so61512356lbd.2 for <netmod@ietf.org>; Thu, 02 Apr 2015 08:13:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yQuou3orBPCC6mE0R8PjzdVtWdzRe2IdJzdijaD/BIE=; b=WlPdY+SGOHpEW+TDYDY42sCM3su8EEMOKW+naJoLPUO+jdAzQ5K7ggomeYwvKMKb+I jdC/bKENn5QAcwyhBHz+jvasn3YckdvVkpIn1wzEPfEp02OPHX2bbxAvGrevMQBoJcYo o2laiurM7FmjUBD4KlLWhr/H/a0/mMBdtYMs5bwm5eJuVPD9xfKFWdd2C8G4UfNf6oRr 6G1OQG0DF2/UTGzUNAxA0f+p8M+rOVAKtMTYe7t8DQalmaGeaKmCX+oVVGQNKiFElr0g /LcYm/D0Wnkb2FS91BVjckL3HIhQ19ftJWVBwYqZTZSCEFc4YVZ4b4lO6eYrMH/koxCB 1wpA== X-Gm-Message-State: ALoCoQlX1Vw8kFhSnMXR5kfD/isv1aUcfy0lD+RmSO7R6JVpW8H8mSvRui7Zd8wnD7jOB6+3H6n3 MIME-Version: 1.0 X-Received: by 10.112.51.138 with SMTP id k10mr40966000lbo.82.1427987603566; Thu, 02 Apr 2015 08:13:23 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Apr 2015 08:13:23 -0700 (PDT) In-Reply-To: <20150402151029.GB79268@elstar.local> References: <20150331072754.GB70057@elstar.local> <201503311954.t2VJs6nd098003@idle.juniper.net> <20150402151029.GB79268@elstar.local> Date: Thu, 2 Apr 2015 08:13:23 -0700 Message-ID: <CABCOCHS3cvavB2jk7erC4C6TwZEAV-KUC_ZPY1UpuUrsHk=QuQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Phil Shafer <phil@juniper.net>, Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/HSqlpnhVTytyWLInROrEfGNsQgo> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 15:13:28 -0000 On Thu, Apr 2, 2015 at 8:10 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Mar 31, 2015 at 03:54:06PM -0400, Phil Shafer wrote: >> Juergen Schoenwaelder writes: >> >The only variation to consider is to be less strict for enums and >> >bits, that is allow additions since enums and bits are often used for >> >(controlled) extensions. In other words, to learn the actual value set >> >supported by an implementation, one has to ask the implementation >> >(similar to identities). (This is what SMIv2 allowed, you can add >> >named numbers to BITS and enumerated INTEGER types, but no other >> >changes to types are allowed.) >> >> I'm confused; how does one ask the implementation for the list >> of supported identities? >> > > There was such a proposal somewhere. Andy might recall. > An RPC called <et-supported-identities> I think. But the YANG Conformance draft expired. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 2 08:18:32 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BA21A9087 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 08:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHWGHMjILvjP for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 08:18:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DBC1AC420 for <netmod@ietf.org>; Thu, 2 Apr 2015 08:18:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BB7EC128F; Thu, 2 Apr 2015 17:18:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id b0AXxCS9k1xl; Thu, 2 Apr 2015 17:17:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Apr 2015 17:18:20 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D97972002B; Thu, 2 Apr 2015 17:18:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q2Y3Ufy3mnCo; Thu, 2 Apr 2015 17:18:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B016520013; Thu, 2 Apr 2015 17:18:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 951A732A6ECF; Thu, 2 Apr 2015 17:18:18 +0200 (CEST) Date: Thu, 2 Apr 2015 17:18:18 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Martin Bjorklund <mbj@tail-f.com> Message-ID: <20150402151818.GC79268@elstar.local> Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com, lhotka@nic.cz, netmod@ietf.org References: <20150331082904.GA70321@elstar.local> <20150331.132300.1653483257526034966.mbj@tail-f.com> <20150331115454.GA71187@elstar.local> <20150331.225217.1507585769954761751.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150331.225217.1507585769954761751.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/6jmQjNZx5JGvemZROElmNcI5AIU> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 15:18:23 -0000 On Tue, Mar 31, 2015 at 10:52:17PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > > > So you are saying typedef drift is not an issue anymore? Or are you > > saying typedef drift is an issue for all types except identityref and > > you just do not like enums and bits be treated differently? > > The latter, but it is not so much that I don't like it, rather that I > do not understand why it can work for enums and bits, but not for > other types. > > Also, I think that with the proposed solution, there is no ambiguity > anymore, even if import without revision is used. > Perhaps I am concerned that we break RFC 6643 but then perhaps this is what we need to do. /js PS: There is another subtle thing. Suppose I take a MIB module and I translate it to YANG 1.0. Suppose I change the result from YANG 1.0 to YANG 1.1. Next, the MIB module is updated and I translate the updated MIB module again to YANG 1.0 and I do the conversion of the result to YANG 1.1. Now I have two YANG 1.1 modules that may break the update rules between them even though each individual step was correct. -- 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/> From nobody Thu Apr 2 08:26:20 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8731ACC82 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 08:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY9R4ggr0YQ4 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 08:26:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 91C431ACCD9 for <netmod@ietf.org>; Thu, 2 Apr 2015 08:26:17 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 76F971280A55; Thu, 2 Apr 2015 17:26:16 +0200 (CEST) Date: Thu, 02 Apr 2015 17:26:44 +0200 (CEST) Message-Id: <20150402.172644.1573138958816238377.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150402151818.GC79268@elstar.local> References: <20150331115454.GA71187@elstar.local> <20150331.225217.1507585769954761751.mbj@tail-f.com> <20150402151818.GC79268@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/odpawwuMNkzaQGBQ4VAwWxOLF-o> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 15:26:19 -0000 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Mar 31, 2015 at 10:52:17PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > > > > > So you are saying typedef drift is not an issue anymore? Or are you > > > saying typedef drift is an issue for all types except identityref and > > > you just do not like enums and bits be treated differently? > > > > The latter, but it is not so much that I don't like it, rather that I > > do not understand why it can work for enums and bits, but not for > > other types. > > > > Also, I think that with the proposed solution, there is no ambiguity > > anymore, even if import without revision is used. > > > > Perhaps I am concerned that we break RFC 6643 but then perhaps this is > what we need to do. > > /js > > PS: There is another subtle thing. Suppose I take a MIB module and I > translate it to YANG 1.0. Suppose I change the result from YANG > 1.0 to YANG 1.1. Next, the MIB module is updated and I translate > the updated MIB module again to YANG 1.0 and I do the conversion > of the result to YANG 1.1. Now I have two YANG 1.1 modules that > may break the update rules between them even though each > individual step was correct. Note that with my proposed solution this is not an issue. It is only a problem if we adopt Y45-02. /martin From nobody Thu Apr 2 09:17:08 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12ED1B2D30 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 09:17:06 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE01xGTBYl4l for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 09:17:03 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id E070C1B2D40 for <netmod@ietf.org>; Thu, 2 Apr 2015 09:17:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MSks1cx9aypCTtxS6kLJa5cnQ+2/+3MplvTGmrHwFyNYxsMsk51fL8NO2vZvUy2a; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Ydhni-00036S-6u for netmod@ietf.org; Thu, 02 Apr 2015 12:17:02 -0400 Received: from 76.254.55.210 by webmail.earthlink.net with HTTP; Thu, 2 Apr 2015 12:17:01 -0400 Message-ID: <24790336.1427991422289.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 09:17:01 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: "netmod@ietf.org" <netmod@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537ca9ee1f4a8972e0a1eeb31ae3857a166350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/QfJ8nljQUaR3AZSeUPvhmHXobO4> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 16:17:07 -0000 Hi - >From: Andy Bierman <andy@yumaworks.com> >Sent: Mar 31, 2015 7:14 AM >To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] Y45 again ... >Extending typedefs and groupings actually works, and implementing >only 1 revision actually works, but only if the server implements >the advertised definitions consistently. How do you envision this approach working with a system containing, for example, a mix of old and new line cards, or managed applications from multiple vendors, where the underlying resources corresponing to some usages of a typedef only support the value set defined by the old definition, while other instances support the full range defined by the newer one? Randy From nobody Thu Apr 2 10:01:06 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454831ACE44 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rntSszriXO1M for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:01:04 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 6D3A91ACE0C for <netmod@ietf.org>; Thu, 2 Apr 2015 10:01:04 -0700 (PDT) Received: by lboc7 with SMTP id c7so63769825lbo.1 for <netmod@ietf.org>; Thu, 02 Apr 2015 10:01:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DWupxoRFpbOATj+ff4vIlO7eRsM8fvL2nvQamus1H80=; b=AcTt6VQ1zD3hj2HyLer9mRbuLkYF3ql+H8bAO4NCsX9y+jdMR1wW+uFjlSvIwiKjKV OeUY+PvWgV5A4SrgHy21RZDDHb+MU6EGyNZ2MBIVvX9TUCE/dugQN47gHRmN5c6wS0iX 4ueVh+2mCqrn7b40Mu/vbHzGnlgA6bPFVCN9AfnEFIk4r+xxiM7ismJUrfsfIliHI7pM afVIT3w3FQb/jCauruIOhlxI2L62AAmImUp02+e0AN2eKXF1ejCnUQaRYMujo+owTL0D MZrIcbY5HwSMQBqEE0mExdEzRF5o2c+jmffMk5p15sLDXCsdaiaFcavWjiDCgVfdrTjV mHSA== X-Gm-Message-State: ALoCoQmA8u4s6P9aRhownFL8UCMz2Gg3sbFEtLcSdCFT/NQKjqujG5G65L2shkBocpoH6/IQJpSf MIME-Version: 1.0 X-Received: by 10.152.30.8 with SMTP id o8mr14779833lah.37.1427994062872; Thu, 02 Apr 2015 10:01:02 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Apr 2015 10:01:02 -0700 (PDT) In-Reply-To: <24790336.1427991422289.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <24790336.1427991422289.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 10:01:02 -0700 Message-ID: <CABCOCHTFiQfEF_9W4k=EZrryC2m8uwh2Vz0uKZh_HHeApwKBPA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/YaxmknKLbZCC4cDDx28unGmcfO8> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 17:01:06 -0000 On Thu, Apr 2, 2015 at 9:17 AM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > >>From: Andy Bierman <andy@yumaworks.com> >>Sent: Mar 31, 2015 7:14 AM >>To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org> >>Subject: Re: [netmod] Y45 again > ... >>Extending typedefs and groupings actually works, and implementing >>only 1 revision actually works, but only if the server implements >>the advertised definitions consistently. > > How do you envision this approach working with a system > containing, for example, a mix of old and new line cards, > or managed applications from multiple vendors, where > the underlying resources corresponing to some usages of > a typedef only support the value set defined by the old > definition, while other instances support the full range > defined by the newer one? > It would not work -- but nothing being proposed actually solves this problem. You cannot have line card 1 implement one revision of a module and line card 2 implement a different version. SNMP does not support that. NETCONF/RESTCONF do not support that. > Randy Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 2 10:07:07 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A29E1ACEBF for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:07:06 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgg0agFRM0M4 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:06:58 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id C14B21ACEBD for <netmod@ietf.org>; Thu, 2 Apr 2015 10:06:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Cc4/sQ0q65rLLm/E0kS0e7aLsVvnI0/ow+mX86ayNWGkw0RbvhJmu5LO39m/qAkl; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Ydia2-0005mJ-Cd for netmod@ietf.org; Thu, 02 Apr 2015 13:06:58 -0400 Received: from 76.254.55.210 by webmail.earthlink.net with HTTP; Thu, 2 Apr 2015 13:06:58 -0400 Message-ID: <28485929.1427994418335.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 10:06:58 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: "netmod@ietf.org" <netmod@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f891153742a163963095407095c66fcbbd3aa159350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/mcDdtId9zIfYWfGu_SP-AEDOnpg> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 17:07:06 -0000 Hi - >From: Andy Bierman <andy@yumaworks.com> >Sent: Apr 2, 2015 10:01 AM >To: Randy Presuhn <randy_presuhn@mindspring.com> >Cc: "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] Y45 again > >On Thu, Apr 2, 2015 at 9:17 AM, Randy Presuhn ><randy_presuhn@mindspring.com> wrote: >> Hi - >> >>>From: Andy Bierman <andy@yumaworks.com> >>>Sent: Mar 31, 2015 7:14 AM >>>To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org> >>>Subject: Re: [netmod] Y45 again >> ... >>>Extending typedefs and groupings actually works, and implementing >>>only 1 revision actually works, but only if the server implements >>>the advertised definitions consistently. >> >> How do you envision this approach working with a system >> containing, for example, a mix of old and new line cards, >> or managed applications from multiple vendors, where >> the underlying resources corresponing to some usages of >> a typedef only support the value set defined by the old >> definition, while other instances support the full range >> defined by the newer one? >> > >It would not work -- but nothing being proposed actually solves this problem. >You cannot have line card 1 implement one revision of a module >and line card 2 implement a different version. SNMP >does not support that. NETCONF/RESTCONF do not support that. Actually, it works just fine with SNMP, due to the SMI versioning rules. This is an example of a case where subagent technology is particularly helpful. Randy From nobody Thu Apr 2 10:41:08 2015 Return-Path: <aashaikh@google.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1B11B2D6F for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEwfSZGXYSbu for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:41:05 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60911B2D66 for <netmod@ietf.org>; Thu, 2 Apr 2015 10:41:04 -0700 (PDT) Received: by obvd1 with SMTP id d1so140447613obv.0 for <netmod@ietf.org>; Thu, 02 Apr 2015 10:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6MIaKgoQz95rZb7af9Br7HNWJ9mzGnVjmo6IDGhYIK8=; b=ASxbLwClD/7E45ISunwTRg9CB0gYt7cdt/2ksEfeWr0crxAwO2CynurrhWMwPNb6EF Dz/OhjuIE1roDCZav3yeyfH55S3+poZGGsDCLYq895/h51BIS6aprpON/eEQcBhgEvNT PaS3ylCQYGcJ4t4ODOL09Ox4+XHtnC20m22bnrRZjuUWBw1Hx6hJTZiQG5R4nEG8w9O3 dKbSKOqYq+jYD5dzKHyiortNOJ2BNT3stP6V10PVYwzsIq+BC+0eybkiAHFH/TWhTc06 ruQMubkn06sH0xvUi2zXdHA8AVVanPLWxjlCh/dBOec5Q/LYXChXLxLayZLyh8H2HzCj gGfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6MIaKgoQz95rZb7af9Br7HNWJ9mzGnVjmo6IDGhYIK8=; b=Hki8b78fQQOFcY5ncPcvDFaHoohjppm7HyvZuSjAsYhQXHPrg1owVO32EOjcxbvbaq NBW7AJV0tkWF57wq2GdtG2xBa0yspUhsgkYyHxBU/xLYZ5TazUP3jclBXeq75Q5/RZx2 A79r7crBq7Ccq15si9gPxu5GJbWq85iiYwsEoHYaHjZtI9cuUqTOw8dFMWo01YPTW0gG oJnyTmy67i0GYxppdbt/rwyY2VLqCubGn7yzDgLtiwsMnIV4uzQZQPx0gzftXbPTLbIl VcWviOl9ZjxruBckPvHphRKt8xFkzIOpXBjWhWgqq7EhzASBnlLG6K33lP0YAfUbhkJU gg9A== X-Gm-Message-State: ALoCoQkp4Vfmd0n3ZD14RzMcgGxrKQyBfV3xpp0DFpDepcIahL8YTR7yII/vgMXJDDNHNOvRmIV4 MIME-Version: 1.0 X-Received: by 10.60.123.40 with SMTP id lx8mr18512760oeb.15.1427996464159; Thu, 02 Apr 2015 10:41:04 -0700 (PDT) Received: by 10.182.73.137 with HTTP; Thu, 2 Apr 2015 10:41:04 -0700 (PDT) In-Reply-To: <CABCOCHR1gwgGN4P-rJriZ7Z48Bcd_1kJdqtf+bqa-nDFwc9mOA@mail.gmail.com> References: <20150402.144700.2146034574780260287.mbj@tail-f.com> <551D49AB.70902@ericsson.com> <CABCOCHR1gwgGN4P-rJriZ7Z48Bcd_1kJdqtf+bqa-nDFwc9mOA@mail.gmail.com> Date: Thu, 2 Apr 2015 10:41:04 -0700 Message-ID: <CAJK7ZqKxjgbB1Ao8YnX-6EDGQx461qgBK4M9T1Xva7K2xLq-kQ@mail.gmail.com> From: Anees Shaikh <aashaikh@google.com> To: Andy Bierman <andy@yumaworks.com> Content-Type: multipart/alternative; boundary=047d7b5d3774fcccc60512c15541 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/n9gbFeKG7RO0i8-ml-0r_GYeXr8> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 17:41:07 -0000 --047d7b5d3774fcccc60512c15541 Content-Type: text/plain; charset=UTF-8 We've laid out why this is a problem (even for existing RFC models) in draft-openconfig-netmod-opstate-00 and summarized during the presentation in Dallas. The problem is exacerbated when trying to compose multiple models into a coherent whole -- clearly it's not possible to manage a service or device with an interfaces model alone. Reading the description statements to learn where different types of data is stored is not a solution IMO -- we need to think how this will be use programmatically by users. And we made the deliberate tradeoff to introduce some extra work in building a consistent model for the benefit of a simple programming construct to set and retrieve the data. thanks. -- Anees On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> wrote: > Hi, > > You need to read the description-stmts of the relevant data nodes > to find out where other related data nodes can be found. > IMO the sibling config/state approach should only > be used if the state can exist without the config. > > If I have an ACL or some filter that may be nested within lists > with lots of keys, then it is extremely wasteful to replicate > all the scaffolding and keys, just to store a couple counters > for that ACL. It is much better to just put the counters in the ACL > entry. > > But many times the set of interesting objects related to some > config is far more complicated than that, so the description-stmt > is the only place to document this information. > > > Andy > > > On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel > <balazs.lengyel@ericsson.com> wrote: > > Hello, > > As indicated by operators in Dallas and as experienced by Ericsson as > well, > > it is sometimes not easy to find the status data for a given bit of > > configuration (interface, route, etc.). Often the state and configuration > > are handled in parallel subtrees with the same structure. However this is > > not part of the guidelines. Also counters are often separated from state > > data again without a clear guideline to connect statistics with the > config. > > I believe 6087 should provide guidelines how to find state and staistics > > information for a give piece of configuration. E.g. how do find the > number > > of outgoing packets for an interface? > > regards Balazs > > > > On 2015-04-02 14:47, Martin Bjorklund wrote: > >> > >> Hi, > >> > >> Here's a list of some things that maybe should be added to 6087bis. > >> Some of them are stylistic; I don't know if we should add those or > >> not. > >> > >> > >> > >> 3.6 References > >> > >> The RFC Editor prefers the style: > >> > >> reference > >> "RFC <NNNN>: <title>"; > >> > >> reference > >> "RFC <NNNN>: <very long title that spans > >> more than one line>"; > >> > >> > >> I think we should document this. > >> > >> > >> 4.1 > >> > >> Update this wrt. example modules. Should they be marked with CODE at > >> all? > >> > >> > >> 5.1. Module Naming Conventions > >> > >> > >> Add: IETF modules SHOULD (MUST?) start with "ietf-". > >> > >> Example modules SHOULD start with "example-" or "ex-". > >> > >> > >> 5.2. Identifiers > >> > >> Add: avoid unnecessary prefixes on names. > >> > >> BAD: > >> > >> list interface { > >> ... > >> leaf interface-name { ... } > >> leaf interface-type { ... } > >> } > >> > >> GOOD: > >> > >> list interface { > >> ... > >> leaf name { ... } > >> leaf type { ... } > >> } > >> > >> > >> use-hypened-names > >> > >> > >> > >> 5.8 Namespace Assignments > >> > >> OLD: > >> > >> The following examples of non-Standards-Track modules are only > >> suggestions. There are no guidelines for this type of URN in this > >> document: > >> > >> http://example.com/ns/example-interfaces > >> > >> http://example.com/ns/example-system > >> > >> NEW: > >> > >> There are no guidelines for non-Standards-Track modules. > >> > >> Example modules SHOULD use RFC 6963 style URNs: > >> > >> urn:example:<module-name> > >> > >> Or 2606-style > >> > >> http://example.com/... > >> > >> > >> > >> /martin > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > Senior Specialist > > ECN: 831 7320 > > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.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 > --047d7b5d3774fcccc60512c15541 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">We've laid out why this is a problem (even for existin= g RFC models) in=C2=A0<span style=3D"color:rgb(0,0,0);font-size:13px;line-h= eight:1.2em">draft-openconfig-netmod-opstate-00 and summarized during the p= resentation in Dallas.=C2=A0 The problem is exacerbated when trying to comp= ose multiple models into a coherent whole -- clearly it's not possible = to manage a service or device with an interfaces model alone.</span><div><s= pan style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em"><br></span>= </div><div><span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em= ">Reading the description statements to learn where different types of data= is stored is not a solution IMO -- we need to think how this will be use p= rogrammatically by users.=C2=A0 And we made the deliberate tradeoff to intr= oduce some extra work in building a consistent model for the benefit of a s= imple programming construct to set and retrieve the data.</span></div><div>= <span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em"><br></spa= n></div><div><span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2= em">thanks.</span></div><div><span style=3D"color:rgb(0,0,0);font-size:13px= ;line-height:1.2em">-- Anees</span></div></div><div class=3D"gmail_extra"><= br><div class=3D"gmail_quote">On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman = <span dir=3D"ltr"><<a href=3D"mailto:andy@yumaworks.com" target=3D"_blan= k">andy@yumaworks.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x">Hi,<br> <br> You need to read the description-stmts of the relevant data nodes<br> to find out where other related data nodes can be found.<br> IMO the sibling config/state approach should only<br> be used if the state can exist without the config.<br> <br> If I have an ACL or some filter that may be nested within lists<br> with lots of keys, then it is extremely wasteful to replicate<br> all the scaffolding and keys, just to store a couple counters<br> for that ACL.=C2=A0 It is much better to just put the counters in the ACL<b= r> entry.<br> <br> But many times the set of interesting objects related to some<br> config is far more complicated than that, so the description-stmt<br> is the only place to document this information.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> Andy<br> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel<br> <<a href=3D"mailto:balazs.lengyel@ericsson.com">balazs.lengyel@ericsson.= com</a>> wrote:<br> > Hello,<br> > As indicated by operators in Dallas and as experienced by Ericsson as = well,<br> > it is sometimes not easy to find the status data for a given bit of<br= > > configuration (interface, route, etc.). Often the state and configurat= ion<br> > are handled in parallel subtrees with the same structure. However this= is<br> > not part of the guidelines. Also counters are often separated from sta= te<br> > data again without a clear guideline to connect statistics with the co= nfig.<br> > I believe 6087 should provide guidelines how to find state and staisti= cs<br> > information for a give piece of configuration. E.g. how do find the nu= mber<br> > of outgoing packets for an interface?<br> > regards Balazs<br> ><br> > On 2015-04-02 14:47, Martin Bjorklund wrote:<br> >><br> >> Hi,<br> >><br> >> Here's a list of some things that maybe should be added to 608= 7bis.<br> >> Some of them are stylistic; I don't know if we should add thos= e or<br> >> not.<br> >><br> >><br> >><br> >> 3.6=C2=A0 References<br> >><br> >>=C2=A0 =C2=A0 The RFC Editor prefers the style:<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 reference<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "RFC <NNNN>: <title>&q= uot;;<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 reference<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "RFC <NNNN>: <very long t= itle that spans<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 more than one line>";<br= > >><br> >><br> >>=C2=A0 =C2=A0 I think we should document this.<br> >><br> >><br> >> 4.1<br> >><br> >>=C2=A0 =C2=A0Update this wrt. example modules.=C2=A0 Should they be= marked with CODE at<br> >>=C2=A0 =C2=A0all?<br> >><br> >><br> >> 5.1.=C2=A0 Module Naming Conventions<br> >><br> >><br> >>=C2=A0 =C2=A0 Add: IETF modules SHOULD (MUST?) start with "iet= f-".<br> >><br> >>=C2=A0 =C2=A0 Example modules SHOULD start with "example-"= ; or "ex-".<br> >><br> >><br> >> 5.2.=C2=A0 Identifiers<br> >><br> >>=C2=A0 =C2=A0 Add: avoid unnecessary prefixes on names.<br> >><br> >>=C2=A0 =C2=A0 BAD:<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 list interface {<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf interface-name { ... }<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf interface-type { ... }<br> >>=C2=A0 =C2=A0 =C2=A0 }<br> >><br> >>=C2=A0 =C2=A0 GOOD:<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 list interface {<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { ... }<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf type { ... }<br> >>=C2=A0 =C2=A0 =C2=A0 }<br> >><br> >><br> >>=C2=A0 =C2=A0 use-hypened-names<br> >><br> >><br> >><br> >> 5.8=C2=A0 Namespace Assignments<br> >><br> >>=C2=A0 =C2=A0 OLD:<br> >><br> >>=C2=A0 =C2=A0 =C2=A0The following examples of non-Standards-Track m= odules are only<br> >>=C2=A0 =C2=A0 =C2=A0suggestions.=C2=A0 There are no guidelines for = this type of URN in this<br> >>=C2=A0 =C2=A0 =C2=A0document:<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://example.com/ns/= example-interfaces" target=3D"_blank">http://example.com/ns/example-interfa= ces</a><br> >><br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://example.com/ns/= example-system" target=3D"_blank">http://example.com/ns/example-system</a><= br> >><br> >>=C2=A0 =C2=A0 NEW:<br> >><br> >>=C2=A0 =C2=A0 =C2=A0There are no guidelines for non-Standards-Track= modules.<br> >><br> >>=C2=A0 =C2=A0 =C2=A0Example modules SHOULD use RFC 6963 style URNs:= <br> >><br> >>=C2=A0 =C2=A0 =C2=A0 urn:example:<module-name><br> >><br> >>=C2=A0 =C2=A0 =C2=A0Or 2606-style<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 <a href=3D"http://example.com/." target=3D"_bl= ank">http://example.com/.</a>..<br> >><br> >><br> >><br> >> /martin<br> >><br> >> _______________________________________________<br> >> netmod mailing list<br> >> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D= "_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br> >><br> >><br> ><br> > --<br> > 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.<br> > Senior Specialist<br> > ECN: 831 7320<br> > Mobile: <a href=3D"tel:%2B36-70-330-7909" value=3D"+36703307909">+36-7= 0-330-7909</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: <a hr= ef=3D"mailto:Balazs.Lengyel@ericsson.com">Balazs.Lengyel@ericsson.com</a><b= r> ><br> > _______________________________________________<br> > netmod mailing list<br> > <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_bl= ank">https://www.ietf.org/mailman/listinfo/netmod</a><br> <br> _______________________________________________<br> netmod mailing list<br> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">= https://www.ietf.org/mailman/listinfo/netmod</a><br> </div></div></blockquote></div><br></div> --047d7b5d3774fcccc60512c15541-- From nobody Thu Apr 2 10:49:05 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD34D1B2DA3 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oRS9Y8360E9 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:49:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7EF1B2DA2 for <netmod@ietf.org>; Thu, 2 Apr 2015 10:49:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0F226129B; Thu, 2 Apr 2015 19:49:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id d8khSpuoKgaa; Thu, 2 Apr 2015 19:48:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Apr 2015 19:48:58 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6C442002B; Thu, 2 Apr 2015 19:48:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 68ElFoBHlUJ7; Thu, 2 Apr 2015 19:48:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 781CA20013; Thu, 2 Apr 2015 19:48:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 73A7332A728D; Thu, 2 Apr 2015 19:48:54 +0200 (CEST) Date: Thu, 2 Apr 2015 19:48:53 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Anees Shaikh <aashaikh@google.com> Message-ID: <20150402174853.GA79932@elstar.local> Mail-Followup-To: Anees Shaikh <aashaikh@google.com>, Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org> References: <20150402.144700.2146034574780260287.mbj@tail-f.com> <551D49AB.70902@ericsson.com> <CABCOCHR1gwgGN4P-rJriZ7Z48Bcd_1kJdqtf+bqa-nDFwc9mOA@mail.gmail.com> <CAJK7ZqKxjgbB1Ao8YnX-6EDGQx461qgBK4M9T1Xva7K2xLq-kQ@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAJK7ZqKxjgbB1Ao8YnX-6EDGQx461qgBK4M9T1Xva7K2xLq-kQ@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/l2cXFvjMfPXzeNOG-WjljM6A7N8> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 17:49:05 -0000 Hi, if you mean section 2.5, then I am not yet convinced I understand the severity of the problem. Does the interface model present a problem? If so, why? If not, what are the IETF models that demonstrate the problem? The second paragraph seems to be talking about multiple devices that implement different data models. Well, that problem we can't solve other than standardizing viable models and pushing vendors to implement them. Or am I reading the wrong section? /js On Thu, Apr 02, 2015 at 10:41:04AM -0700, Anees Shaikh wrote: > We've laid out why this is a problem (even for existing RFC models) in > draft-openconfig-netmod-opstate-00 > and summarized during the presentation in Dallas. The problem is > exacerbated when trying to compose multiple models into a coherent whole -- > clearly it's not possible to manage a service or device with an interfaces > model alone. > > Reading the description statements to learn where different types of data > is stored is not a solution IMO -- we need to think how this will be use > programmatically by users. And we made the deliberate tradeoff to > introduce some extra work in building a consistent model for the benefit of > a simple programming construct to set and retrieve the data. > > thanks. > -- Anees > > On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> wrote: > > > Hi, > > > > You need to read the description-stmts of the relevant data nodes > > to find out where other related data nodes can be found. > > IMO the sibling config/state approach should only > > be used if the state can exist without the config. > > > > If I have an ACL or some filter that may be nested within lists > > with lots of keys, then it is extremely wasteful to replicate > > all the scaffolding and keys, just to store a couple counters > > for that ACL. It is much better to just put the counters in the ACL > > entry. > > > > But many times the set of interesting objects related to some > > config is far more complicated than that, so the description-stmt > > is the only place to document this information. > > > > > > Andy > > > > > > On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel > > <balazs.lengyel@ericsson.com> wrote: > > > Hello, > > > As indicated by operators in Dallas and as experienced by Ericsson as > > well, > > > it is sometimes not easy to find the status data for a given bit of > > > configuration (interface, route, etc.). Often the state and configuration > > > are handled in parallel subtrees with the same structure. However this is > > > not part of the guidelines. Also counters are often separated from state > > > data again without a clear guideline to connect statistics with the > > config. > > > I believe 6087 should provide guidelines how to find state and staistics > > > information for a give piece of configuration. E.g. how do find the > > number > > > of outgoing packets for an interface? > > > regards Balazs > > > > > > On 2015-04-02 14:47, Martin Bjorklund wrote: > > >> > > >> Hi, > > >> > > >> Here's a list of some things that maybe should be added to 6087bis. > > >> Some of them are stylistic; I don't know if we should add those or > > >> not. > > >> > > >> > > >> > > >> 3.6 References > > >> > > >> The RFC Editor prefers the style: > > >> > > >> reference > > >> "RFC <NNNN>: <title>"; > > >> > > >> reference > > >> "RFC <NNNN>: <very long title that spans > > >> more than one line>"; > > >> > > >> > > >> I think we should document this. > > >> > > >> > > >> 4.1 > > >> > > >> Update this wrt. example modules. Should they be marked with CODE at > > >> all? > > >> > > >> > > >> 5.1. Module Naming Conventions > > >> > > >> > > >> Add: IETF modules SHOULD (MUST?) start with "ietf-". > > >> > > >> Example modules SHOULD start with "example-" or "ex-". > > >> > > >> > > >> 5.2. Identifiers > > >> > > >> Add: avoid unnecessary prefixes on names. > > >> > > >> BAD: > > >> > > >> list interface { > > >> ... > > >> leaf interface-name { ... } > > >> leaf interface-type { ... } > > >> } > > >> > > >> GOOD: > > >> > > >> list interface { > > >> ... > > >> leaf name { ... } > > >> leaf type { ... } > > >> } > > >> > > >> > > >> use-hypened-names > > >> > > >> > > >> > > >> 5.8 Namespace Assignments > > >> > > >> OLD: > > >> > > >> The following examples of non-Standards-Track modules are only > > >> suggestions. There are no guidelines for this type of URN in this > > >> document: > > >> > > >> http://example.com/ns/example-interfaces > > >> > > >> http://example.com/ns/example-system > > >> > > >> NEW: > > >> > > >> There are no guidelines for non-Standards-Track modules. > > >> > > >> Example modules SHOULD use RFC 6963 style URNs: > > >> > > >> urn:example:<module-name> > > >> > > >> Or 2606-style > > >> > > >> http://example.com/... > > >> > > >> > > >> > > >> /martin > > >> > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > >> > > >> > > > > > > -- > > > Balazs Lengyel Ericsson Hungary Ltd. > > > Senior Specialist > > > ECN: 831 7320 > > > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.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 <http://www.jacobs-university.de/> From nobody Thu Apr 2 10:49:23 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31231B2DA2 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2Cq_Wu8I00H for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 10:49:20 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61FC1B2DA3 for <netmod@ietf.org>; Thu, 2 Apr 2015 10:49:19 -0700 (PDT) Received: by lahf3 with SMTP id f3so64847398lah.2 for <netmod@ietf.org>; Thu, 02 Apr 2015 10:49:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q7azx6jekJmMiPI3t5EaV8hkZC6WxvW1dvzQ32c+wl0=; b=iszJfc7/Q3JdJR5jPGuJ2wvLByCto8MzsulbDnEoNP1YpFmNwIWn1gxTUhWiLrSgPz HKpSlDLTqGAX7dKJrwS8psGcvCDuaJLrSs3PJn4Sh+yx4qu6yCcZJmoXNBoCBaEL0mWo q3sHwVONm23/uCk/pogLuFggw3B9G+mvYryz2o89pFGf3Vm85q7hcexLO+I204NAxNmD lmsfSE+WQJtBAnz5LryZCW0cdSZ7a/mHAM9OaIwJSfZgqMJ0gDPLZHmykHWhcRVXjfNK MeBa27C5NPNssilRhWNTn8Und43eZKgiB2/7+sWHMM5xdUkZJJu5rnOlClhlYJROQpuv jXZA== X-Gm-Message-State: ALoCoQkqjtG0trQ2VFml91isoaoTapAQ7JNvheLjqwztu31Pxd9T9a56fs74aNlsqET5YxX39hw5 MIME-Version: 1.0 X-Received: by 10.112.56.42 with SMTP id x10mr1915720lbp.123.1427996958311; Thu, 02 Apr 2015 10:49:18 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Apr 2015 10:49:18 -0700 (PDT) In-Reply-To: <CAJK7ZqKxjgbB1Ao8YnX-6EDGQx461qgBK4M9T1Xva7K2xLq-kQ@mail.gmail.com> References: <20150402.144700.2146034574780260287.mbj@tail-f.com> <551D49AB.70902@ericsson.com> <CABCOCHR1gwgGN4P-rJriZ7Z48Bcd_1kJdqtf+bqa-nDFwc9mOA@mail.gmail.com> <CAJK7ZqKxjgbB1Ao8YnX-6EDGQx461qgBK4M9T1Xva7K2xLq-kQ@mail.gmail.com> Date: Thu, 2 Apr 2015 10:49:18 -0700 Message-ID: <CABCOCHSpexh-9Y-6ajjsfn0hmo961d5fMFoV0ZH=CQyQWKGdgg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Anees Shaikh <aashaikh@google.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Nodv8uQZ0ALEulRZRr3peS6sxjk> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 17:49:23 -0000 On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh@google.com> wrote: > We've laid out why this is a problem (even for existing RFC models) in > draft-openconfig-netmod-opstate-00 and summarized during the presentation in > Dallas. The problem is exacerbated when trying to compose multiple models > into a coherent whole -- clearly it's not possible to manage a service or > device with an interfaces model alone. > > Reading the description statements to learn where different types of data is > stored is not a solution IMO -- we need to think how this will be use > programmatically by users. And we made the deliberate tradeoff to introduce > some extra work in building a consistent model for the benefit of a simple > programming construct to set and retrieve the data. > I disagree. Many times the relationship between a config knob setting and operational state is not simple. There may be all kinds of overlap and dynamic conditions that change the set of interesting objects at the moment. Forcing a certain structure between config and operational nodes will not work as a general solution. You should develop some YANG extensions if you think the problem can be solved without description-stmts. > thanks. > -- Anees Andy > > On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> wrote: >> >> Hi, >> >> You need to read the description-stmts of the relevant data nodes >> to find out where other related data nodes can be found. >> IMO the sibling config/state approach should only >> be used if the state can exist without the config. >> >> If I have an ACL or some filter that may be nested within lists >> with lots of keys, then it is extremely wasteful to replicate >> all the scaffolding and keys, just to store a couple counters >> for that ACL. It is much better to just put the counters in the ACL >> entry. >> >> But many times the set of interesting objects related to some >> config is far more complicated than that, so the description-stmt >> is the only place to document this information. >> >> >> Andy >> >> >> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel >> <balazs.lengyel@ericsson.com> wrote: >> > Hello, >> > As indicated by operators in Dallas and as experienced by Ericsson as >> > well, >> > it is sometimes not easy to find the status data for a given bit of >> > configuration (interface, route, etc.). Often the state and >> > configuration >> > are handled in parallel subtrees with the same structure. However this >> > is >> > not part of the guidelines. Also counters are often separated from state >> > data again without a clear guideline to connect statistics with the >> > config. >> > I believe 6087 should provide guidelines how to find state and staistics >> > information for a give piece of configuration. E.g. how do find the >> > number >> > of outgoing packets for an interface? >> > regards Balazs >> > >> > On 2015-04-02 14:47, Martin Bjorklund wrote: >> >> >> >> Hi, >> >> >> >> Here's a list of some things that maybe should be added to 6087bis. >> >> Some of them are stylistic; I don't know if we should add those or >> >> not. >> >> >> >> >> >> >> >> 3.6 References >> >> >> >> The RFC Editor prefers the style: >> >> >> >> reference >> >> "RFC <NNNN>: <title>"; >> >> >> >> reference >> >> "RFC <NNNN>: <very long title that spans >> >> more than one line>"; >> >> >> >> >> >> I think we should document this. >> >> >> >> >> >> 4.1 >> >> >> >> Update this wrt. example modules. Should they be marked with CODE at >> >> all? >> >> >> >> >> >> 5.1. Module Naming Conventions >> >> >> >> >> >> Add: IETF modules SHOULD (MUST?) start with "ietf-". >> >> >> >> Example modules SHOULD start with "example-" or "ex-". >> >> >> >> >> >> 5.2. Identifiers >> >> >> >> Add: avoid unnecessary prefixes on names. >> >> >> >> BAD: >> >> >> >> list interface { >> >> ... >> >> leaf interface-name { ... } >> >> leaf interface-type { ... } >> >> } >> >> >> >> GOOD: >> >> >> >> list interface { >> >> ... >> >> leaf name { ... } >> >> leaf type { ... } >> >> } >> >> >> >> >> >> use-hypened-names >> >> >> >> >> >> >> >> 5.8 Namespace Assignments >> >> >> >> OLD: >> >> >> >> The following examples of non-Standards-Track modules are only >> >> suggestions. There are no guidelines for this type of URN in this >> >> document: >> >> >> >> http://example.com/ns/example-interfaces >> >> >> >> http://example.com/ns/example-system >> >> >> >> NEW: >> >> >> >> There are no guidelines for non-Standards-Track modules. >> >> >> >> Example modules SHOULD use RFC 6963 style URNs: >> >> >> >> urn:example:<module-name> >> >> >> >> Or 2606-style >> >> >> >> http://example.com/... >> >> >> >> >> >> >> >> /martin >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> > >> > -- >> > Balazs Lengyel Ericsson Hungary Ltd. >> > Senior Specialist >> > ECN: 831 7320 >> > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.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 Apr 2 11:03:05 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4108E1B2D33 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:03:03 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBcuSfxPgEpj for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:03:01 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id CF3B81A002D for <netmod@ietf.org>; Thu, 2 Apr 2015 11:03:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FFMDYRrKJYM7K8tT02vHAiEnR5xylkr2FUXGvUh3hvivh/aYEwqd/mA+miZ9E1C6; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1YdjSF-0002YP-P7 for netmod@ietf.org; Thu, 02 Apr 2015 14:02:59 -0400 Received: from 76.254.55.210 by webmail.earthlink.net with HTTP; Thu, 2 Apr 2015 14:02:56 -0400 Message-ID: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 11:02:56 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: "netmod@ietf.org" <netmod@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115372fb5365b5a3650d7abac4983ea954694350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/5hyaF6NTPatGN7q96oU2H-vmlkI> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 18:03:03 -0000 Hi - I think what they're really asking for is an automated way to identify the bits and pieces that correspond to a particular aspect of a managed thingie. This has already happened with "config true". Module structure is a really lousy mechanism for identifying aspects; a given bit of information may participate in more than one aspect. So I'm agreeing with Andy that structure is a lousy tool for the job. However, the job is an important one. Structure is not the solution. Look for another tool. Randy -----Original Message----- >From: Andy Bierman <andy@yumaworks.com> >Sent: Apr 2, 2015 10:49 AM >To: Anees Shaikh <aashaikh@google.com> >Cc: "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics > >On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh@google.com> wrote: >> We've laid out why this is a problem (even for existing RFC models) in >> draft-openconfig-netmod-opstate-00 and summarized during the presentation in >> Dallas. The problem is exacerbated when trying to compose multiple models >> into a coherent whole -- clearly it's not possible to manage a service or >> device with an interfaces model alone. >> >> Reading the description statements to learn where different types of data is >> stored is not a solution IMO -- we need to think how this will be use >> programmatically by users. And we made the deliberate tradeoff to introduce >> some extra work in building a consistent model for the benefit of a simple >> programming construct to set and retrieve the data. >> > >I disagree. >Many times the relationship between a config knob setting >and operational state is not simple. There may be all kinds of >overlap and dynamic conditions that change the set of >interesting objects at the moment. Forcing a certain structure >between config and operational nodes will not work as a general solution. >You should develop some YANG extensions if you think the >problem can be solved without description-stmts. > > > > >> thanks. >> -- Anees > >Andy > >> >> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> wrote: >>> >>> Hi, >>> >>> You need to read the description-stmts of the relevant data nodes >>> to find out where other related data nodes can be found. >>> IMO the sibling config/state approach should only >>> be used if the state can exist without the config. >>> >>> If I have an ACL or some filter that may be nested within lists >>> with lots of keys, then it is extremely wasteful to replicate >>> all the scaffolding and keys, just to store a couple counters >>> for that ACL. It is much better to just put the counters in the ACL >>> entry. >>> >>> But many times the set of interesting objects related to some >>> config is far more complicated than that, so the description-stmt >>> is the only place to document this information. >>> >>> >>> Andy >>> >>> >>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel >>> <balazs.lengyel@ericsson.com> wrote: >>> > Hello, >>> > As indicated by operators in Dallas and as experienced by Ericsson as >>> > well, >>> > it is sometimes not easy to find the status data for a given bit of >>> > configuration (interface, route, etc.). Often the state and >>> > configuration >>> > are handled in parallel subtrees with the same structure. However this >>> > is >>> > not part of the guidelines. Also counters are often separated from state >>> > data again without a clear guideline to connect statistics with the >>> > config. >>> > I believe 6087 should provide guidelines how to find state and staistics >>> > information for a give piece of configuration. E.g. how do find the >>> > number >>> > of outgoing packets for an interface? >>> > regards Balazs >>> > >>> > On 2015-04-02 14:47, Martin Bjorklund wrote: >>> >> >>> >> Hi, >>> >> >>> >> Here's a list of some things that maybe should be added to 6087bis. >>> >> Some of them are stylistic; I don't know if we should add those or >>> >> not. >>> >> >>> >> >>> >> >>> >> 3.6 References >>> >> >>> >> The RFC Editor prefers the style: >>> >> >>> >> reference >>> >> "RFC <NNNN>: <title>"; >>> >> >>> >> reference >>> >> "RFC <NNNN>: <very long title that spans >>> >> more than one line>"; >>> >> >>> >> >>> >> I think we should document this. >>> >> >>> >> >>> >> 4.1 >>> >> >>> >> Update this wrt. example modules. Should they be marked with CODE at >>> >> all? >>> >> >>> >> >>> >> 5.1. Module Naming Conventions >>> >> >>> >> >>> >> Add: IETF modules SHOULD (MUST?) start with "ietf-". >>> >> >>> >> Example modules SHOULD start with "example-" or "ex-". >>> >> >>> >> >>> >> 5.2. Identifiers >>> >> >>> >> Add: avoid unnecessary prefixes on names. >>> >> >>> >> BAD: >>> >> >>> >> list interface { >>> >> ... >>> >> leaf interface-name { ... } >>> >> leaf interface-type { ... } >>> >> } >>> >> >>> >> GOOD: >>> >> >>> >> list interface { >>> >> ... >>> >> leaf name { ... } >>> >> leaf type { ... } >>> >> } >>> >> >>> >> >>> >> use-hypened-names >>> >> >>> >> >>> >> >>> >> 5.8 Namespace Assignments >>> >> >>> >> OLD: >>> >> >>> >> The following examples of non-Standards-Track modules are only >>> >> suggestions. There are no guidelines for this type of URN in this >>> >> document: >>> >> >>> >> http://example.com/ns/example-interfaces >>> >> >>> >> http://example.com/ns/example-system >>> >> >>> >> NEW: >>> >> >>> >> There are no guidelines for non-Standards-Track modules. >>> >> >>> >> Example modules SHOULD use RFC 6963 style URNs: >>> >> >>> >> urn:example:<module-name> >>> >> >>> >> Or 2606-style >>> >> >>> >> http://example.com/... >>> >> >>> >> >>> >> >>> >> /martin >>> >> >>> >> _______________________________________________ >>> >> netmod mailing list >>> >> netmod@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/netmod >>> >> >>> >> >>> > >>> > -- >>> > Balazs Lengyel Ericsson Hungary Ltd. >>> > Senior Specialist >>> > ECN: 831 7320 >>> > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.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 From nobody Thu Apr 2 11:07:55 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2F51A0030 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCkvAV4B5fap for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:07:50 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7543B1A0039 for <netmod@ietf.org>; Thu, 2 Apr 2015 11:07:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 49D23129A for <netmod@ietf.org>; Thu, 2 Apr 2015 20:07:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ILwuS46b_2RM for <netmod@ietf.org>; Thu, 2 Apr 2015 20:07:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Thu, 2 Apr 2015 20:07:48 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E2982002C for <netmod@ietf.org>; Thu, 2 Apr 2015 20:07:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n2e15U__2ORS; Thu, 2 Apr 2015 20:07:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F8772002B; Thu, 2 Apr 2015 20:07:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9553C32A72E3; Thu, 2 Apr 2015 20:07:45 +0200 (CEST) Date: Thu, 2 Apr 2015 20:07:45 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: netmod@ietf.org Message-ID: <20150402180745.GA80006@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ROgQN_dFZP1eMfZiKV9_0DIIr_g> Subject: [netmod] ietf 92 meeting minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 18:07:53 -0000 Hi, the IETF 92 meeting minutes can be found here: https://www.ietf.org/proceedings/92/minutes/minutes-92-netmod Please let me know if something needs to be corrected. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 2 11:43:30 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ED61A0404 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYDK43cbQip9 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:43:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5426D1A1A34 for <netmod@ietf.org>; Thu, 2 Apr 2015 11:43:09 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 47E701280B2C; Thu, 2 Apr 2015 20:43:08 +0200 (CEST) Date: Thu, 02 Apr 2015 20:43:37 +0200 (CEST) Message-Id: <20150402.204337.2126314818225756752.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <28485929.1427994418335.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <28485929.1427994418335.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/yEKG-p3x9BZcetED0x_kHRRvs4g> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 18:43:28 -0000 Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > > >From: Andy Bierman <andy@yumaworks.com> > >Sent: Apr 2, 2015 10:01 AM > >To: Randy Presuhn <randy_presuhn@mindspring.com> > >Cc: "netmod@ietf.org" <netmod@ietf.org> > >Subject: Re: [netmod] Y45 again > > > >On Thu, Apr 2, 2015 at 9:17 AM, Randy Presuhn > ><randy_presuhn@mindspring.com> wrote: > >> Hi - > >> > >>>From: Andy Bierman <andy@yumaworks.com> > >>>Sent: Mar 31, 2015 7:14 AM > >>>To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org> > >>>Subject: Re: [netmod] Y45 again > >> ... > >>>Extending typedefs and groupings actually works, and implementing > >>>only 1 revision actually works, but only if the server implements > >>>the advertised definitions consistently. > >> > >> How do you envision this approach working with a system > >> containing, for example, a mix of old and new line cards, > >> or managed applications from multiple vendors, where > >> the underlying resources corresponing to some usages of > >> a typedef only support the value set defined by the old > >> definition, while other instances support the full range > >> defined by the newer one? > >> > > > >It would not work -- but nothing being proposed actually solves this problem. > >You cannot have line card 1 implement one revision of a module > >and line card 2 implement a different version. SNMP > >does not support that. NETCONF/RESTCONF do not support that. > > Actually, it works just fine with SNMP, due to the SMI > versioning rules. This is an example of a case where > subagent technology is particularly helpful. Right. But it also means that a SNMP manager has no idea what values an SNMP agent supports for a particular instance of a particular object (well it has *some* idea). The only reason we are having such problems with Y45 is that we have created a requirement on ourselves that a client should be able to determine what the server supports from what it advertises. /martin From nobody Thu Apr 2 11:56:30 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D481A1AB6 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:56:28 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0qn1EzalnIa for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:56:24 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 78FB41A1A98 for <netmod@ietf.org>; Thu, 2 Apr 2015 11:56:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YYPb0R4wxtK4BIafFqELPnbS0t0WJDGA4+0LhkQLO+Wx6n9BLzTpnFiJ63aI/Ijq; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1YdkHv-0002kO-3b; Thu, 02 Apr 2015 14:56:23 -0400 Received: from 76.254.55.210 by webmail.earthlink.net with HTTP; Thu, 2 Apr 2015 14:56:22 -0400 Message-ID: <16839048.1428000983133.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 11:56:22 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: Martin Bjorklund <mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115379eba7ff9261d86fccb038cb8284ed83d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Vx70OJqQFIZWRH4yp9d96azZ8N0> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 18:56:28 -0000 Hi - >From: Martin Bjorklund <mbj@tail-f.com> >Sent: Apr 2, 2015 11:43 AM >To: randy_presuhn@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] Y45 again > >Randy Presuhn <randy_presuhn@mindspring.com> wrote: >> Hi - >> >> >From: Andy Bierman <andy@yumaworks.com> >> >Sent: Apr 2, 2015 10:01 AM >> >To: Randy Presuhn <randy_presuhn@mindspring.com> >> >Cc: "netmod@ietf.org" <netmod@ietf.org> >> >Subject: Re: [netmod] Y45 again >> > >> >On Thu, Apr 2, 2015 at 9:17 AM, Randy Presuhn >> ><randy_presuhn@mindspring.com> wrote: >> >> Hi - >> >> >> >>>From: Andy Bierman <andy@yumaworks.com> >> >>>Sent: Mar 31, 2015 7:14 AM >> >>>To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org> >> >>>Subject: Re: [netmod] Y45 again >> >> ... >> >>>Extending typedefs and groupings actually works, and implementing >> >>>only 1 revision actually works, but only if the server implements >> >>>the advertised definitions consistently. >> >> >> >> How do you envision this approach working with a system >> >> containing, for example, a mix of old and new line cards, >> >> or managed applications from multiple vendors, where >> >> the underlying resources corresponing to some usages of >> >> a typedef only support the value set defined by the old >> >> definition, while other instances support the full range >> >> defined by the newer one? >> >> >> > >> >It would not work -- but nothing being proposed actually solves this problem. >> >You cannot have line card 1 implement one revision of a module >> >and line card 2 implement a different version. SNMP >> >does not support that. NETCONF/RESTCONF do not support that. >> >> Actually, it works just fine with SNMP, due to the SMI >> versioning rules. This is an example of a case where >> subagent technology is particularly helpful. > >Right. But it also means that a SNMP manager has no idea what values >an SNMP agent supports for a particular instance of a particular object >(well it has *some* idea). The only reason we are having such >problems with Y45 is that we have created a requirement on ourselves >that a client should be able to determine what the server supports >from what it advertises. I think there's a little more to it than that. The transaction model also makes not knowing exactly what configuration a given instance is capable of supporting a much bigger deal in the Netconf world than it is in the SNMP world. Randy From nobody Thu Apr 2 11:59:31 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1FA1A1A2C for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNLOB16XK-Ih for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 11:59:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 40E051A1A6C for <netmod@ietf.org>; Thu, 2 Apr 2015 11:59:23 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 8A71C1280A55; Thu, 2 Apr 2015 20:59:22 +0200 (CEST) Date: Thu, 02 Apr 2015 21:00:01 +0200 (CEST) Message-Id: <20150402.210001.1501506627501349817.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <16839048.1428000983133.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <16839048.1428000983133.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/XGTFby106dgTsXodHsVkbhbcg0Q> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 18:59:29 -0000 Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > > >From: Martin Bjorklund <mbj@tail-f.com> > >Sent: Apr 2, 2015 11:43 AM > >To: randy_presuhn@mindspring.com > >Cc: netmod@ietf.org > >Subject: Re: [netmod] Y45 again > > > >Randy Presuhn <randy_presuhn@mindspring.com> wrote: > >> Hi - > >> > >> >From: Andy Bierman <andy@yumaworks.com> > >> >Sent: Apr 2, 2015 10:01 AM > >> >To: Randy Presuhn <randy_presuhn@mindspring.com> > >> >Cc: "netmod@ietf.org" <netmod@ietf.org> > >> >Subject: Re: [netmod] Y45 again > >> > > >> >On Thu, Apr 2, 2015 at 9:17 AM, Randy Presuhn > >> ><randy_presuhn@mindspring.com> wrote: > >> >> Hi - > >> >> > >> >>>From: Andy Bierman <andy@yumaworks.com> > >> >>>Sent: Mar 31, 2015 7:14 AM > >> >>>To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org> > >> >>>Subject: Re: [netmod] Y45 again > >> >> ... > >> >>>Extending typedefs and groupings actually works, and implementing > >> >>>only 1 revision actually works, but only if the server implements > >> >>>the advertised definitions consistently. > >> >> > >> >> How do you envision this approach working with a system > >> >> containing, for example, a mix of old and new line cards, > >> >> or managed applications from multiple vendors, where > >> >> the underlying resources corresponing to some usages of > >> >> a typedef only support the value set defined by the old > >> >> definition, while other instances support the full range > >> >> defined by the newer one? > >> >> > >> > > >> >It would not work -- but nothing being proposed actually solves this problem. > >> >You cannot have line card 1 implement one revision of a module > >> >and line card 2 implement a different version. SNMP > >> >does not support that. NETCONF/RESTCONF do not support that. > >> > >> Actually, it works just fine with SNMP, due to the SMI > >> versioning rules. This is an example of a case where > >> subagent technology is particularly helpful. > > > >Right. But it also means that a SNMP manager has no idea what values > >an SNMP agent supports for a particular instance of a particular object > >(well it has *some* idea). The only reason we are having such > >problems with Y45 is that we have created a requirement on ourselves > >that a client should be able to determine what the server supports > >from what it advertises. > > I think there's a little more to it than that. > The transaction model also makes not knowing exactly > what configuration a given instance is capable > of supporting a much bigger deal in the Netconf world > than it is in the SNMP world. Can you elaborate? /martin From nobody Thu Apr 2 12:01:15 2015 Return-Path: <aashaikh@google.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EF11A1B1D for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 12:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsboZXPTfHb5 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 12:01:09 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61021B2E17 for <netmod@ietf.org>; Thu, 2 Apr 2015 12:00:53 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so58181872obb.2 for <netmod@ietf.org>; Thu, 02 Apr 2015 12:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JM/ZoPRIxPD343BrN7j3Z4yfPqGZNBDPLS1xNkvxD/k=; b=VYilm64saEKCl4h5oYBBqmCZKF5WOWkJy61GBVGmlnCsFakUpkWSWQYcOXBpi9VEqy +cAkt986qes0qEH4LMQbmgxxJf5rZm3oLikFsOPsqmGTWfjZgHlce5QqetCEf6u1hHiD rGxV3ayPpKLDZMHaqHawMUI2t0U5hlJ2zdl8lykxN3I8dJgnXSIBWw/0FK8IaRkcRLWS WvnVjenHoSwzNxjfFPjcd84zDZ+h7Cx6i4M8yzpQN7+qYGVr8TAZxVIASjhck2JqYOjb 2e7FVJlApojpGH6ywZt8PII3BEFVUCbCn4bV45PeKzczplUmgRHA+DCaatFdE9TIO1kG u1gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JM/ZoPRIxPD343BrN7j3Z4yfPqGZNBDPLS1xNkvxD/k=; b=Wz+rZclBveSMjqqj9Mi5EW4SUg4Js+mHYIA74QhhduoERe4uv3oHvRfJ0AN5Z4pVbD ydkiCTATyl0pOHzHiHR+9aoQrkzI74G/uWcqgTFkLmMmsuKx9wSiSoSZ1GKz235CgjGX E1eeBkEVhJZo8OzMOYx4yQU67J8Xn5o4G7FRBZhDF/7wvG26vugQgRTEATL7Dd4daJHL HTZoJj37Jg7tAIVSYwhLlwtL2eITODVwRWSkNgMloE0nPrOXRH2Oqdr/zTKn+LOmtZT4 cxA0Z+oTa/gA25QcDarrXmWbrQ4UISPVRQG+8SQqYaRslsA2pj6fSNSPurXyIH1q/zSn M3Cg== X-Gm-Message-State: ALoCoQk8vg82h1iKvng6TPFYrpAzPU+mM9mBJv6vW9rHPB/7Bd8p6TLA5LQo41vrrlmSg4FsVMVN MIME-Version: 1.0 X-Received: by 10.60.123.40 with SMTP id lx8mr18900978oeb.15.1428001253204; Thu, 02 Apr 2015 12:00:53 -0700 (PDT) Received: by 10.182.73.137 with HTTP; Thu, 2 Apr 2015 12:00:53 -0700 (PDT) In-Reply-To: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 12:00:53 -0700 Message-ID: <CAJK7ZqKak=yGe4AFye0gpJwXfTDWCAuEJ_mXmNURZe2F96BO8g@mail.gmail.com> From: Anees Shaikh <aashaikh@google.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: multipart/alternative; boundary=047d7b5d37746fcd640512c273dd Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/TKgHm_7dJcITLZ2U551wSExeSsA> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 19:01:13 -0000 --047d7b5d37746fcd640512c273dd Content-Type: text/plain; charset=UTF-8 I'm not sure what identifying aspects mean -- I'm talking about the problem of finding corresponding data in a model (and more importantly, a composed model) in a consistent way. It doesn't solve the issue of semantics relationship of config and state knobs (except for the convention on intended vs. actual config that we explain in the document). And it's not that we need an automated way, we need a schema that lends itself to a simple programming model / convention (maybe you meant the same thing). "Config true" doesn't help with this , it only labels a piece of data as rw or ro. And neither does anunstructured text description embedded in the schema document. The alternative is to maintain an external mapping for every data item (since the locations in the schema can be arbitrary when putting models together). This was not pursued because it doesn't scale and is not easy to maintain. (Juergen, in section 2.5 we are not talking about devices that support different models -- we are talking about a device for which multiple models are needed to fully manage all aspects -- again, I can't turn up a device with just an interfaces model. sorry if it wasn't clear from the example). thanks. -- Anees On Thu, Apr 2, 2015 at 11:02 AM, Randy Presuhn <randy_presuhn@mindspring.com > wrote: > Hi - > > I think what they're really asking for is an automated way > to identify the bits and pieces that correspond to a particular > aspect of a managed thingie. This has already happened with > "config true". Module structure is a really lousy mechanism > for identifying aspects; a given bit of information may > participate in more than one aspect. So I'm agreeing with > Andy that structure is a lousy tool for the job. > > However, the job is an important one. Structure is not the > solution. Look for another tool. > > Randy > > -----Original Message----- > >From: Andy Bierman <andy@yumaworks.com> > >Sent: Apr 2, 2015 10:49 AM > >To: Anees Shaikh <aashaikh@google.com> > >Cc: "netmod@ietf.org" <netmod@ietf.org> > >Subject: Re: [netmod] New 6087bis issues - connect config - state - > statistics > > > >On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh@google.com> > wrote: > >> We've laid out why this is a problem (even for existing RFC models) in > >> draft-openconfig-netmod-opstate-00 and summarized during the > presentation in > >> Dallas. The problem is exacerbated when trying to compose multiple > models > >> into a coherent whole -- clearly it's not possible to manage a service > or > >> device with an interfaces model alone. > >> > >> Reading the description statements to learn where different types of > data is > >> stored is not a solution IMO -- we need to think how this will be use > >> programmatically by users. And we made the deliberate tradeoff to > introduce > >> some extra work in building a consistent model for the benefit of a > simple > >> programming construct to set and retrieve the data. > >> > > > >I disagree. > >Many times the relationship between a config knob setting > >and operational state is not simple. There may be all kinds of > >overlap and dynamic conditions that change the set of > >interesting objects at the moment. Forcing a certain structure > >between config and operational nodes will not work as a general solution. > >You should develop some YANG extensions if you think the > >problem can be solved without description-stmts. > > > > > > > > > >> thanks. > >> -- Anees > > > >Andy > > > >> > >> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> > wrote: > >>> > >>> Hi, > >>> > >>> You need to read the description-stmts of the relevant data nodes > >>> to find out where other related data nodes can be found. > >>> IMO the sibling config/state approach should only > >>> be used if the state can exist without the config. > >>> > >>> If I have an ACL or some filter that may be nested within lists > >>> with lots of keys, then it is extremely wasteful to replicate > >>> all the scaffolding and keys, just to store a couple counters > >>> for that ACL. It is much better to just put the counters in the ACL > >>> entry. > >>> > >>> But many times the set of interesting objects related to some > >>> config is far more complicated than that, so the description-stmt > >>> is the only place to document this information. > >>> > >>> > >>> Andy > >>> > >>> > >>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel > >>> <balazs.lengyel@ericsson.com> wrote: > >>> > Hello, > >>> > As indicated by operators in Dallas and as experienced by Ericsson as > >>> > well, > >>> > it is sometimes not easy to find the status data for a given bit of > >>> > configuration (interface, route, etc.). Often the state and > >>> > configuration > >>> > are handled in parallel subtrees with the same structure. However > this > >>> > is > >>> > not part of the guidelines. Also counters are often separated from > state > >>> > data again without a clear guideline to connect statistics with the > >>> > config. > >>> > I believe 6087 should provide guidelines how to find state and > staistics > >>> > information for a give piece of configuration. E.g. how do find the > >>> > number > >>> > of outgoing packets for an interface? > >>> > regards Balazs > >>> > > >>> > On 2015-04-02 14:47, Martin Bjorklund wrote: > >>> >> > >>> >> Hi, > >>> >> > >>> >> Here's a list of some things that maybe should be added to 6087bis. > >>> >> Some of them are stylistic; I don't know if we should add those or > >>> >> not. > >>> >> > >>> >> > >>> >> > >>> >> 3.6 References > >>> >> > >>> >> The RFC Editor prefers the style: > >>> >> > >>> >> reference > >>> >> "RFC <NNNN>: <title>"; > >>> >> > >>> >> reference > >>> >> "RFC <NNNN>: <very long title that spans > >>> >> more than one line>"; > >>> >> > >>> >> > >>> >> I think we should document this. > >>> >> > >>> >> > >>> >> 4.1 > >>> >> > >>> >> Update this wrt. example modules. Should they be marked with > CODE at > >>> >> all? > >>> >> > >>> >> > >>> >> 5.1. Module Naming Conventions > >>> >> > >>> >> > >>> >> Add: IETF modules SHOULD (MUST?) start with "ietf-". > >>> >> > >>> >> Example modules SHOULD start with "example-" or "ex-". > >>> >> > >>> >> > >>> >> 5.2. Identifiers > >>> >> > >>> >> Add: avoid unnecessary prefixes on names. > >>> >> > >>> >> BAD: > >>> >> > >>> >> list interface { > >>> >> ... > >>> >> leaf interface-name { ... } > >>> >> leaf interface-type { ... } > >>> >> } > >>> >> > >>> >> GOOD: > >>> >> > >>> >> list interface { > >>> >> ... > >>> >> leaf name { ... } > >>> >> leaf type { ... } > >>> >> } > >>> >> > >>> >> > >>> >> use-hypened-names > >>> >> > >>> >> > >>> >> > >>> >> 5.8 Namespace Assignments > >>> >> > >>> >> OLD: > >>> >> > >>> >> The following examples of non-Standards-Track modules are only > >>> >> suggestions. There are no guidelines for this type of URN in > this > >>> >> document: > >>> >> > >>> >> http://example.com/ns/example-interfaces > >>> >> > >>> >> http://example.com/ns/example-system > >>> >> > >>> >> NEW: > >>> >> > >>> >> There are no guidelines for non-Standards-Track modules. > >>> >> > >>> >> Example modules SHOULD use RFC 6963 style URNs: > >>> >> > >>> >> urn:example:<module-name> > >>> >> > >>> >> Or 2606-style > >>> >> > >>> >> http://example.com/... > >>> >> > >>> >> > >>> >> > >>> >> /martin > >>> >> > >>> >> _______________________________________________ > >>> >> netmod mailing list > >>> >> netmod@ietf.org > >>> >> https://www.ietf.org/mailman/listinfo/netmod > >>> >> > >>> >> > >>> > > >>> > -- > >>> > Balazs Lengyel Ericsson Hungary Ltd. > >>> > Senior Specialist > >>> > ECN: 831 7320 > >>> > Mobile: +36-70-330-7909 email: > Balazs.Lengyel@ericsson.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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b5d37746fcd640512c273dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I'm not sure what identifying aspects mean -- I'm = talking about the problem of finding corresponding data in a model (and mor= e importantly, a composed model) in a consistent way.=C2=A0 It doesn't = solve the issue of semantics relationship of config and state knobs (except= for the convention on intended vs. actual config that we explain in the do= cument).=C2=A0 And it's not that we need an automated way, we need a sc= hema that lends itself to a simple programming model / convention =C2=A0(ma= ybe you meant the same thing).<div><br></div><div>"Config true" d= oesn't help with this , it only labels a piece of data as rw or ro.=C2= =A0 And neither does anunstructured text description embedded in the schema= document.=C2=A0 The alternative is to maintain an external mapping for eve= ry data item (since the locations in the schema can be arbitrary when putti= ng models together).=C2=A0 This was not pursued because it doesn't scal= e and is not easy to maintain.</div><div><br></div><div>(Juergen, in sectio= n 2.5 we are not talking about devices that support different models -- we = are talking about a device for which multiple models are needed to fully ma= nage all aspects -- again, I can't turn up a device with just an interf= aces model. =C2=A0sorry if it wasn't clear from the example).<br><div><= br></div><div>thanks.</div><div>-- Anees</div></div></div><div class=3D"gma= il_extra"><br><div class=3D"gmail_quote">On Thu, Apr 2, 2015 at 11:02 AM, R= andy Presuhn <span dir=3D"ltr"><<a href=3D"mailto:randy_presuhn@mindspri= ng.com" target=3D"_blank">randy_presuhn@mindspring.com</a>></span> wrote= :<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex">Hi -<br> <br> I think what they're really asking for is an automated way<br> to identify the bits and pieces that correspond to a particular<br> aspect of a managed thingie.=C2=A0 This has already happened with<br> "config true".=C2=A0 Module structure is a really lousy mechanism= <br> for identifying aspects; a given bit of information may<br> participate in more than one aspect.=C2=A0 So I'm agreeing with<br> Andy that structure is a lousy tool for the job.<br> <br> However, the job is an important one.=C2=A0 Structure is not the<br> solution.=C2=A0 Look for another tool.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Randy<br> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> -----Original Message-----<br> >From: Andy Bierman <<a href=3D"mailto:andy@yumaworks.com">andy@yumaw= orks.com</a>><br> >Sent: Apr 2, 2015 10:49 AM<br> >To: Anees Shaikh <<a href=3D"mailto:aashaikh@google.com">aashaikh@go= ogle.com</a>><br> >Cc: "<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a>" = <<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a>><br> >Subject: Re: [netmod] New 6087bis issues - connect config - state -=C2= =A0 =C2=A0 statistics<br> ><br> >On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <<a href=3D"mailto:aas= haikh@google.com">aashaikh@google.com</a>> wrote:<br> >> We've laid out why this is a problem (even for existing RFC mo= dels) in<br> >> draft-openconfig-netmod-opstate-00 and summarized during the prese= ntation in<br> >> Dallas.=C2=A0 The problem is exacerbated when trying to compose mu= ltiple models<br> >> into a coherent whole -- clearly it's not possible to manage a= service or<br> >> device with an interfaces model alone.<br> >><br> >> Reading the description statements to learn where different types = of data is<br> >> stored is not a solution IMO -- we need to think how this will be = use<br> >> programmatically by users.=C2=A0 And we made the deliberate tradeo= ff to introduce<br> >> some extra work in building a consistent model for the benefit of = a simple<br> >> programming construct to set and retrieve the data.<br> >><br> ><br> >I disagree.<br> >Many times the relationship between a config knob setting<br> >and operational state is not simple.=C2=A0 There may be all kinds of<br= > >overlap and dynamic conditions that change the set of<br> >interesting objects at the moment.=C2=A0 Forcing a certain structure<br= > >between config and operational nodes will not work as a general solutio= n.<br> >You should develop some YANG extensions if you think the<br> >problem can be solved without description-stmts.<br> ><br> ><br> ><br> ><br> >> thanks.<br> >> -- Anees<br> ><br> >Andy<br> ><br> >><br> >> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <<a href=3D"mailto= :andy@yumaworks.com">andy@yumaworks.com</a>> wrote:<br> >>><br> >>> Hi,<br> >>><br> >>> You need to read the description-stmts of the relevant data no= des<br> >>> to find out where other related data nodes can be found.<br> >>> IMO the sibling config/state approach should only<br> >>> be used if the state can exist without the config.<br> >>><br> >>> If I have an ACL or some filter that may be nested within list= s<br> >>> with lots of keys, then it is extremely wasteful to replicate<= br> >>> all the scaffolding and keys, just to store a couple counters<= br> >>> for that ACL.=C2=A0 It is much better to just put the counters= in the ACL<br> >>> entry.<br> >>><br> >>> But many times the set of interesting objects related to some<= br> >>> config is far more complicated than that, so the description-s= tmt<br> >>> is the only place to document this information.<br> >>><br> >>><br> >>> Andy<br> >>><br> >>><br> >>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel<br> >>> <<a href=3D"mailto:balazs.lengyel@ericsson.com">balazs.leng= yel@ericsson.com</a>> wrote:<br> >>> > Hello,<br> >>> > As indicated by operators in Dallas and as experienced by= Ericsson as<br> >>> > well,<br> >>> > it is sometimes not easy to find the status data for a gi= ven bit of<br> >>> > configuration (interface, route, etc.). Often the state a= nd<br> >>> > configuration<br> >>> > are handled in parallel subtrees with the same structure.= However this<br> >>> > is<br> >>> > not part of the guidelines. Also counters are often separ= ated from state<br> >>> > data again without a clear guideline to connect statistic= s with the<br> >>> > config.<br> >>> > I believe 6087 should provide guidelines how to find stat= e and staistics<br> >>> > information for a give piece of configuration. E.g. how d= o find the<br> >>> > number<br> >>> > of outgoing packets for an interface?<br> >>> > regards Balazs<br> >>> ><br> >>> > On 2015-04-02 14:47, Martin Bjorklund wrote:<br> >>> >><br> >>> >> Hi,<br> >>> >><br> >>> >> Here's a list of some things that maybe should be= added to 6087bis.<br> >>> >> Some of them are stylistic; I don't know if we sh= ould add those or<br> >>> >> not.<br> >>> >><br> >>> >><br> >>> >><br> >>> >> 3.6=C2=A0 References<br> >>> >><br> >>> >>=C2=A0 =C2=A0 The RFC Editor prefers the style:<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0 reference<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "RFC <NNNN>: &l= t;title>";<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0 reference<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "RFC <NNNN>: &l= t;very long title that spans<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 more than one line&= gt;";<br> >>> >><br> >>> >><br> >>> >>=C2=A0 =C2=A0 I think we should document this.<br> >>> >><br> >>> >><br> >>> >> 4.1<br> >>> >><br> >>> >>=C2=A0 =C2=A0Update this wrt. example modules.=C2=A0 S= hould they be marked with CODE at<br> >>> >>=C2=A0 =C2=A0all?<br> >>> >><br> >>> >><br> >>> >> 5.1.=C2=A0 Module Naming Conventions<br> >>> >><br> >>> >><br> >>> >>=C2=A0 =C2=A0 Add: IETF modules SHOULD (MUST?) start w= ith "ietf-".<br> >>> >><br> >>> >>=C2=A0 =C2=A0 Example modules SHOULD start with "= example-" or "ex-".<br> >>> >><br> >>> >><br> >>> >> 5.2.=C2=A0 Identifiers<br> >>> >><br> >>> >>=C2=A0 =C2=A0 Add: avoid unnecessary prefixes on names= .<br> >>> >><br> >>> >>=C2=A0 =C2=A0 BAD:<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0 list interface {<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf interface-name { ... = }<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf interface-type { ... = }<br> >>> >>=C2=A0 =C2=A0 =C2=A0 }<br> >>> >><br> >>> >>=C2=A0 =C2=A0 GOOD:<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0 list interface {<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { ... }<br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf type { ... }<br> >>> >>=C2=A0 =C2=A0 =C2=A0 }<br> >>> >><br> >>> >><br> >>> >>=C2=A0 =C2=A0 use-hypened-names<br> >>> >><br> >>> >><br> >>> >><br> >>> >> 5.8=C2=A0 Namespace Assignments<br> >>> >><br> >>> >>=C2=A0 =C2=A0 OLD:<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0The following examples of non-Stan= dards-Track modules are only<br> >>> >>=C2=A0 =C2=A0 =C2=A0suggestions.=C2=A0 There are no gu= idelines for this type of URN in this<br> >>> >>=C2=A0 =C2=A0 =C2=A0document:<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://ex= ample.com/ns/example-interfaces" target=3D"_blank">http://example.com/ns/ex= ample-interfaces</a><br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://ex= ample.com/ns/example-system" target=3D"_blank">http://example.com/ns/exampl= e-system</a><br> >>> >><br> >>> >>=C2=A0 =C2=A0 NEW:<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0There are no guidelines for non-St= andards-Track modules.<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0Example modules SHOULD use RFC 696= 3 style URNs:<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0 urn:example:<module-name><b= r> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0Or 2606-style<br> >>> >><br> >>> >>=C2=A0 =C2=A0 =C2=A0 <a href=3D"http://example.com/." = target=3D"_blank">http://example.com/.</a>..<br> >>> >><br> >>> >><br> >>> >><br> >>> >> /martin<br> >>> >><br> >>> >> _______________________________________________<br> >>> >> netmod mailing list<br> >>> >> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a= ><br> >>> >> <a href=3D"https://www.ietf.org/mailman/listinfo/netm= od" target=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br> >>> >><br> >>> >><br> >>> ><br> >>> > --<br> >>> > 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.<br> >>> > Senior Specialist<br> >>> > ECN: 831 7320<br> >>> > Mobile: <a href=3D"tel:%2B36-70-330-7909" value=3D"+36703= 307909">+36-70-330-7909</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= email: <a href=3D"mailto:Balazs.Lengyel@ericsson.com">Balazs.Lengyel@erics= son.com</a><br> >>> ><br> >>> > _______________________________________________<br> >>> > netmod mailing list<br> >>> > <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br= > >>> > <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br> >>><br> >>> _______________________________________________<br> >>> netmod mailing list<br> >>> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> >>> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" targe= t=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br> >><br> >><br> ><br> >_______________________________________________<br> >netmod mailing list<br> ><a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/netmod</a><br> <br> _______________________________________________<br> netmod mailing list<br> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">= https://www.ietf.org/mailman/listinfo/netmod</a><br> </div></div></blockquote></div><br></div> --047d7b5d37746fcd640512c273dd-- From nobody Thu Apr 2 12:27:58 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F011A0033 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 12:27:56 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3mYKuLurvH4 for <netmod@ietfa.amsl.com>; Thu, 2 Apr 2015 12:27:52 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id B1B141A000A for <netmod@ietf.org>; Thu, 2 Apr 2015 12:27:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LcTNqgWEYQqDHACS7ApF1L7WJzSDs9KBDMkBXXE39tqvmdMFPZA9Y8PdW9U90/cW; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1YdkmN-0002Dr-NS for netmod@ietf.org; Thu, 02 Apr 2015 15:27:51 -0400 Received: from 76.254.55.210 by webmail.earthlink.net with HTTP; Thu, 2 Apr 2015 15:27:51 -0400 Message-ID: <28977236.1428002871819.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 12:27:51 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537fa7c969dc2a0c521ad71f01b15d3a90d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/87QdBvLQsxFcLrf-f_jzHXa8vMY> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2015 19:27:56 -0000 Hi - >From: Martin Bjorklund <mbj@tail-f.com> >Sent: Apr 2, 2015 12:00 PM >To: randy_presuhn@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] Y45 again ... >> >Right. But it also means that a SNMP manager has no idea what values >> >an SNMP agent supports for a particular instance of a particular object >> >(well it has *some* idea). The only reason we are having such >> >problems with Y45 is that we have created a requirement on ourselves >> >that a client should be able to determine what the server supports >> >from what it advertises. >> >> I think there's a little more to it than that. >> The transaction model also makes not knowing exactly >> what configuration a given instance is capable >> of supporting a much bigger deal in the Netconf world >> than it is in the SNMP world. > >Can you elaborate? SNMP does configuration in little spurts. With each PDU, one knows whether the change was accepted or not, and recovery strategies have to be formulated at a microscopic level. With Netconf, the good thing is that you can deliver an entire configuration for validation. That's the bad thing, too. If parts of the managed resource are constrained in ways beyond what is explicit in the model (we can think of the presences of some less-capable versions as being an example of that) and we can't find out about that limitation until a new configuration is validated, we will have invested a lot more effort before we learn that we have to fall back on "plan B". One would hope that easy-to-implement microscopic recovery strategies would be possible, but I suspect that watching them in action on the wire would be pretty ugly. Randy From nobody Fri Apr 3 01:26:27 2015 Return-Path: <balazs.lengyel@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FFD1A040C for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 01:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2A3F558AKsv for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 01:26:22 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6B61A03A5 for <netmod@ietf.org>; Fri, 3 Apr 2015 01:26:21 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-30-551e4eab9461 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8A.18.19337.BAE4E155; Fri, 3 Apr 2015 10:26:19 +0200 (CEST) Received: from [159.107.197.187] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Fri, 3 Apr 2015 10:26:18 +0200 Message-ID: <551E4EAA.8090703@ericsson.com> Date: Fri, 3 Apr 2015 10:26:18 +0200 From: Balazs Lengyel <balazs.lengyel@ericsson.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> References: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> In-Reply-To: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvje5qP7lQg9PntSzmX2xktbi/8Ai7 A5PHkiU/mTx+bOhhD2CK4rJJSc3JLEst0rdL4Mp4sn8+S8EJx4q3u7rZGxgvGncxcnJICJhI HGg9xQ5hi0lcuLeerYuRi0NI4CijxJGFXYwQzhpGifbGYywgVbwC2hLzpu0H62ARUJFYcLwF zGYTMJKY2n8erEZUIEqi5083G0S9oMTJmU/A4iIC4RJb9u4HiwsL+EnsuXaBFcQWAoo/+b8I rIZTIEJi6YEHQDUcHMwC9hIPtpaBhJkF5CW2v53DDFGuIfHwwl/WCYwCs5BsmIXQMQtJxwJG 5lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgUF5cMtv1R2Ml984HmIU4GBU4uF9cEsmVIg1 say4MvcQozQHi5I4r53xoRAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjPFbtpkFybJdcHtr e/T9PbFPUnF+Sl6mmT0CW7d5zY/qjz5379HHS/m/1oenrbeQ/5Jy3uLqqz5ff5Po7cGGF+vK Wa6nLls7V8PrkPaJBZdMNBz3i9Yb3M6a+n8Gy3WHtq0XNb7kH7174GNP8x71+nDmLSbpBvwu 6VuXqzx4fOO8qfatyiuvLJVYijMSDbWYi4oTARk3hNYrAgAA Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/KrCqF6aMepJE_Jb8YuQtSZQRIA4> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 08:26:25 -0000 Hello, I think the problem is real, needs solving, so just some ideas: - put state, statistics and config in the same container/list, but enhance Netconf/restconf to be able to <get> just config, just state, just counters or some combinations of all this. As I remember the main reason to put state and config in separate branches was the need to be able to read them separately. At that time I tought it a mistake that we use module structure instead of extending netconf. As Andy stated: "structure is a lousy tool". Still in RFC6087bis we have: "The separation of configuration data and operational state SHOULD be considered carefully. It is often useful to define separate top- level containers for configuration and non-configuration data." This uses the structure as a tool. :-) or - a new YANG statement that links together two lists indicating that one is the config part while the other is the state regards Balazs P.S. IETF was always asking for operator input. Now we got it, will we do something about it? On 2015-04-02 20:02, Randy Presuhn wrote: > Hi - > > I think what they're really asking for is an automated way > to identify the bits and pieces that correspond to a particular > aspect of a managed thingie. This has already happened with > "config true". Module structure is a really lousy mechanism > for identifying aspects; a given bit of information may > participate in more than one aspect. So I'm agreeing with > Andy that structure is a lousy tool for the job. > > However, the job is an important one. Structure is not the > solution. Look for another tool. > > Randy > > -----Original Message----- >> From: Andy Bierman <andy@yumaworks.com> >> Sent: Apr 2, 2015 10:49 AM >> To: Anees Shaikh <aashaikh@google.com> >> Cc: "netmod@ietf.org" <netmod@ietf.org> >> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics >> >> On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh@google.com> wrote: >>> We've laid out why this is a problem (even for existing RFC models) in >>> draft-openconfig-netmod-opstate-00 and summarized during the presentation in >>> Dallas. The problem is exacerbated when trying to compose multiple models >>> into a coherent whole -- clearly it's not possible to manage a service or >>> device with an interfaces model alone. >>> >>> Reading the description statements to learn where different types of data is >>> stored is not a solution IMO -- we need to think how this will be use >>> programmatically by users. And we made the deliberate tradeoff to introduce >>> some extra work in building a consistent model for the benefit of a simple >>> programming construct to set and retrieve the data. >>> >> I disagree. >> Many times the relationship between a config knob setting >> and operational state is not simple. There may be all kinds of >> overlap and dynamic conditions that change the set of >> interesting objects at the moment. Forcing a certain structure >> between config and operational nodes will not work as a general solution. >> You should develop some YANG extensions if you think the >> problem can be solved without description-stmts. >> >> >> >> >>> thanks. >>> -- Anees >> Andy >> >>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> wrote: >>>> Hi, >>>> >>>> You need to read the description-stmts of the relevant data nodes >>>> to find out where other related data nodes can be found. >>>> IMO the sibling config/state approach should only >>>> be used if the state can exist without the config. >>>> >>>> If I have an ACL or some filter that may be nested within lists >>>> with lots of keys, then it is extremely wasteful to replicate >>>> all the scaffolding and keys, just to store a couple counters >>>> for that ACL. It is much better to just put the counters in the ACL >>>> entry. >>>> >>>> But many times the set of interesting objects related to some >>>> config is far more complicated than that, so the description-stmt >>>> is the only place to document this information. >>>> >>>> >>>> Andy >>>> >>>> >>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel >>>> <balazs.lengyel@ericsson.com> wrote: >>>>> Hello, >>>>> As indicated by operators in Dallas and as experienced by Ericsson as >>>>> well, >>>>> it is sometimes not easy to find the status data for a given bit of >>>>> configuration (interface, route, etc.). Often the state and >>>>> configuration >>>>> are handled in parallel subtrees with the same structure. However this >>>>> is >>>>> not part of the guidelines. Also counters are often separated from state >>>>> data again without a clear guideline to connect statistics with the >>>>> config. >>>>> I believe 6087 should provide guidelines how to find state and staistics >>>>> information for a give piece of configuration. E.g. how do find the >>>>> number >>>>> of outgoing packets for an interface? >>>>> regards Balazs >>>>> >>>>> On 2015-04-02 14:47, Martin Bjorklund wrote: >>>>>> Hi, >>>>>> >>>>>> Here's a list of some things that maybe should be added to 6087bis. >>>>>> Some of them are stylistic; I don't know if we should add those or >>>>>> not. >>>>>> >>>>>> >>>>>> >>>>>> 3.6 References >>>>>> >>>>>> The RFC Editor prefers the style: >>>>>> >>>>>> reference >>>>>> "RFC <NNNN>: <title>"; >>>>>> >>>>>> reference >>>>>> "RFC <NNNN>: <very long title that spans >>>>>> more than one line>"; >>>>>> >>>>>> >>>>>> I think we should document this. >>>>>> >>>>>> >>>>>> 4.1 >>>>>> >>>>>> Update this wrt. example modules. Should they be marked with CODE at >>>>>> all? >>>>>> >>>>>> >>>>>> 5.1. Module Naming Conventions >>>>>> >>>>>> >>>>>> Add: IETF modules SHOULD (MUST?) start with "ietf-". >>>>>> >>>>>> Example modules SHOULD start with "example-" or "ex-". >>>>>> >>>>>> >>>>>> 5.2. Identifiers >>>>>> >>>>>> Add: avoid unnecessary prefixes on names. >>>>>> >>>>>> BAD: >>>>>> >>>>>> list interface { >>>>>> ... >>>>>> leaf interface-name { ... } >>>>>> leaf interface-type { ... } >>>>>> } >>>>>> >>>>>> GOOD: >>>>>> >>>>>> list interface { >>>>>> ... >>>>>> leaf name { ... } >>>>>> leaf type { ... } >>>>>> } >>>>>> >>>>>> >>>>>> use-hypened-names >>>>>> >>>>>> >>>>>> >>>>>> 5.8 Namespace Assignments >>>>>> >>>>>> OLD: >>>>>> >>>>>> The following examples of non-Standards-Track modules are only >>>>>> suggestions. There are no guidelines for this type of URN in this >>>>>> document: >>>>>> >>>>>> http://example.com/ns/example-interfaces >>>>>> >>>>>> http://example.com/ns/example-system >>>>>> >>>>>> NEW: >>>>>> >>>>>> There are no guidelines for non-Standards-Track modules. >>>>>> >>>>>> Example modules SHOULD use RFC 6963 style URNs: >>>>>> >>>>>> urn:example:<module-name> >>>>>> >>>>>> Or 2606-style >>>>>> >>>>>> http://example.com/... >>>>>> >>>>>> >>>>>> >>>>>> /martin >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>>>> >>>>> -- >>>>> Balazs Lengyel Ericsson Hungary Ltd. >>>>> Senior Specialist >>>>> ECN: 831 7320 >>>>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Fri Apr 3 02:14:49 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CE41A1B80 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 02:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEtvpzBrmcmq for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 02:14:45 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8B21A1B85 for <netmod@ietf.org>; Fri, 3 Apr 2015 02:14:43 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so59574895lbb.0 for <netmod@ietf.org>; Fri, 03 Apr 2015 02:14:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PGRe+a6I9w8YVh20jlSm2HXbAMj+KV5am0sCern7X6w=; b=Ohi0f2FKwuMni6GD1N1DLjpSNzeXnSYc3gGEeP59w0GXn3ywJghR5i87xgUITV0dcl SsUwZDoDzLIOjN1colLeZ0ntmG9uB9boRIPF2GDvDsITclpYOLXvkaDWcHLEYtLXYfQ5 4eetnvmvLxRTPPpk71JXvjc3ANsgE9QXL4B4ddsVOaYKNby2UrAjzaUIeH/8n7/VE2/3 4xv8REvxFQ1896EnlhXAPrkC2LDlY8FRgF1Ew6LQ9RQc9a3AYrhraL1MGc74CBZT1Ib0 JQ9+uk2dbiBHVnLDC8kLgy8x1L16ZoZvUVgiuiVmesixMuVaYWnMDyi/QNmd0oUgnCBJ la/A== X-Gm-Message-State: ALoCoQmat4oQQKa04dahWXsF+kuyAOcn+JYYQNFapM70EunI2bVJjDWH5cx9FW1J+HRzLR+USLC4 MIME-Version: 1.0 X-Received: by 10.112.77.234 with SMTP id v10mr1313164lbw.119.1428052482432; Fri, 03 Apr 2015 02:14:42 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Apr 2015 02:14:42 -0700 (PDT) In-Reply-To: <551E4EAA.8090703@ericsson.com> References: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <551E4EAA.8090703@ericsson.com> Date: Fri, 3 Apr 2015 02:14:42 -0700 Message-ID: <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Balazs Lengyel <balazs.lengyel@ericsson.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Yi05MsGohhc1Ks0_yjivmYGoxmo> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 09:14:48 -0000 On Fri, Apr 3, 2015 at 1:26 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote: > Hello, > I think the problem is real, needs solving, so just some ideas: > - put state, statistics and config in the same container/list, but enhance > Netconf/restconf to be able to <get> just config, just state, just counters > or some combinations of all this. As I remember the main reason to put state > and config in separate branches was the need to be able to read them > separately. At that time I tought it a mistake that we use module structure > instead of extending netconf. As Andy stated: "structure is a lousy tool". > Still in RFC6087bis we have: > "The separation of configuration data and operational state SHOULD be > considered carefully. It is often useful to define separate top- > level containers for configuration and non-configuration data." > This uses the structure as a tool. :-) > RESTCONF already has the 'content' query parameter that allows config, operational, or both. This is good enough. It is trivial for you to add your own content filters to the RPC operations (if you want to prove that standards for more classifications are needed) Andy > or > - a new YANG statement that links together two lists indicating that one is > the config part while the other is the state Prove this works as an extension first. IMO it is easy to come up with simplistic solutions for trivial test-cases. Create a general solution first, prove that it helps, then ask the IETF to standardize it. > regards Balazs Andy > > P.S. IETF was always asking for operator input. Now we got it, will we do > something about it? > > On 2015-04-02 20:02, Randy Presuhn wrote: >> >> Hi - >> >> I think what they're really asking for is an automated way >> to identify the bits and pieces that correspond to a particular >> aspect of a managed thingie. This has already happened with >> "config true". Module structure is a really lousy mechanism >> for identifying aspects; a given bit of information may >> participate in more than one aspect. So I'm agreeing with >> Andy that structure is a lousy tool for the job. >> >> However, the job is an important one. Structure is not the >> solution. Look for another tool. >> >> Randy >> >> -----Original Message----- >>> >>> From: Andy Bierman <andy@yumaworks.com> >>> Sent: Apr 2, 2015 10:49 AM >>> To: Anees Shaikh <aashaikh@google.com> >>> Cc: "netmod@ietf.org" <netmod@ietf.org> >>> Subject: Re: [netmod] New 6087bis issues - connect config - state - >>> statistics >>> >>> On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh@google.com> >>> wrote: >>>> >>>> We've laid out why this is a problem (even for existing RFC models) in >>>> draft-openconfig-netmod-opstate-00 and summarized during the >>>> presentation in >>>> Dallas. The problem is exacerbated when trying to compose multiple >>>> models >>>> into a coherent whole -- clearly it's not possible to manage a service >>>> or >>>> device with an interfaces model alone. >>>> >>>> Reading the description statements to learn where different types of >>>> data is >>>> stored is not a solution IMO -- we need to think how this will be use >>>> programmatically by users. And we made the deliberate tradeoff to >>>> introduce >>>> some extra work in building a consistent model for the benefit of a >>>> simple >>>> programming construct to set and retrieve the data. >>>> >>> I disagree. >>> Many times the relationship between a config knob setting >>> and operational state is not simple. There may be all kinds of >>> overlap and dynamic conditions that change the set of >>> interesting objects at the moment. Forcing a certain structure >>> between config and operational nodes will not work as a general solution. >>> You should develop some YANG extensions if you think the >>> problem can be solved without description-stmts. >>> >>> >>> >>> >>>> thanks. >>>> -- Anees >>> >>> Andy >>> >>>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> You need to read the description-stmts of the relevant data nodes >>>>> to find out where other related data nodes can be found. >>>>> IMO the sibling config/state approach should only >>>>> be used if the state can exist without the config. >>>>> >>>>> If I have an ACL or some filter that may be nested within lists >>>>> with lots of keys, then it is extremely wasteful to replicate >>>>> all the scaffolding and keys, just to store a couple counters >>>>> for that ACL. It is much better to just put the counters in the ACL >>>>> entry. >>>>> >>>>> But many times the set of interesting objects related to some >>>>> config is far more complicated than that, so the description-stmt >>>>> is the only place to document this information. >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel >>>>> <balazs.lengyel@ericsson.com> wrote: >>>>>> >>>>>> Hello, >>>>>> As indicated by operators in Dallas and as experienced by Ericsson as >>>>>> well, >>>>>> it is sometimes not easy to find the status data for a given bit of >>>>>> configuration (interface, route, etc.). Often the state and >>>>>> configuration >>>>>> are handled in parallel subtrees with the same structure. However this >>>>>> is >>>>>> not part of the guidelines. Also counters are often separated from >>>>>> state >>>>>> data again without a clear guideline to connect statistics with the >>>>>> config. >>>>>> I believe 6087 should provide guidelines how to find state and >>>>>> staistics >>>>>> information for a give piece of configuration. E.g. how do find the >>>>>> number >>>>>> of outgoing packets for an interface? >>>>>> regards Balazs >>>>>> >>>>>> On 2015-04-02 14:47, Martin Bjorklund wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Here's a list of some things that maybe should be added to 6087bis. >>>>>>> Some of them are stylistic; I don't know if we should add those or >>>>>>> not. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 3.6 References >>>>>>> >>>>>>> The RFC Editor prefers the style: >>>>>>> >>>>>>> reference >>>>>>> "RFC <NNNN>: <title>"; >>>>>>> >>>>>>> reference >>>>>>> "RFC <NNNN>: <very long title that spans >>>>>>> more than one line>"; >>>>>>> >>>>>>> >>>>>>> I think we should document this. >>>>>>> >>>>>>> >>>>>>> 4.1 >>>>>>> >>>>>>> Update this wrt. example modules. Should they be marked with CODE >>>>>>> at >>>>>>> all? >>>>>>> >>>>>>> >>>>>>> 5.1. Module Naming Conventions >>>>>>> >>>>>>> >>>>>>> Add: IETF modules SHOULD (MUST?) start with "ietf-". >>>>>>> >>>>>>> Example modules SHOULD start with "example-" or "ex-". >>>>>>> >>>>>>> >>>>>>> 5.2. Identifiers >>>>>>> >>>>>>> Add: avoid unnecessary prefixes on names. >>>>>>> >>>>>>> BAD: >>>>>>> >>>>>>> list interface { >>>>>>> ... >>>>>>> leaf interface-name { ... } >>>>>>> leaf interface-type { ... } >>>>>>> } >>>>>>> >>>>>>> GOOD: >>>>>>> >>>>>>> list interface { >>>>>>> ... >>>>>>> leaf name { ... } >>>>>>> leaf type { ... } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> use-hypened-names >>>>>>> >>>>>>> >>>>>>> >>>>>>> 5.8 Namespace Assignments >>>>>>> >>>>>>> OLD: >>>>>>> >>>>>>> The following examples of non-Standards-Track modules are only >>>>>>> suggestions. There are no guidelines for this type of URN in >>>>>>> this >>>>>>> document: >>>>>>> >>>>>>> http://example.com/ns/example-interfaces >>>>>>> >>>>>>> http://example.com/ns/example-system >>>>>>> >>>>>>> NEW: >>>>>>> >>>>>>> There are no guidelines for non-Standards-Track modules. >>>>>>> >>>>>>> Example modules SHOULD use RFC 6963 style URNs: >>>>>>> >>>>>>> urn:example:<module-name> >>>>>>> >>>>>>> Or 2606-style >>>>>>> >>>>>>> http://example.com/... >>>>>>> >>>>>>> >>>>>>> >>>>>>> /martin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>> >>>>>>> >>>>>> -- >>>>>> Balazs Lengyel Ericsson Hungary Ltd. >>>>>> Senior Specialist >>>>>> ECN: 831 7320 >>>>>> Mobile: +36-70-330-7909 email: >>>>>> Balazs.Lengyel@ericsson.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 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 3 03:56:19 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03DA1A87A5 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 03:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: 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-La5hbkHRSp for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 03:56:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499761A879B for <netmod@ietf.org>; Fri, 3 Apr 2015 03:56:17 -0700 (PDT) Received: from [IPv6:2a02:908:f313:2000:9d7e:d9bb:2ad7:df53] (unknown [IPv6:2a02:908:f313:2000:9d7e:d9bb:2ad7:df53]) by mail.nic.cz (Postfix) with ESMTPSA id 76E5713FE14; Fri, 3 Apr 2015 12:56:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1428058575; bh=5/1qexhFrEW6W6IWdGbIkzj+Vd0Ueg8sNCxb9DIHZXc=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NOB0BGhfzCoCBBqocMAVUIAu05fwKiZrGCHutLEMuuP77+d6hFODlLU2s2zsNbKtp WqVnh0axceOS1jCJaunqkKFVK+z395L5oS13x7dGzuanjrsr0S+AyrD8OosIdvtF6B u5dTEbPNwzGmKheyhOwbNQZlCHE/wNO1p/erJvj4= Message-ID: <551E71CE.3040802@nic.cz> Date: Fri, 03 Apr 2015 12:56:14 +0200 From: Ladislav Lhotka <lhotka@nic.cz> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Phil Shafer <phil@juniper.net>, Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org> References: <201503311941.t2VJf45r097817@idle.juniper.net> <m2384khvhn.fsf@nic.cz> <20150402145838.GA79268@elstar.local> In-Reply-To: <20150402145838.GA79268@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/liVydJV6I6YmyyHgiPdb0Me-jLo> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 10:56:19 -0000 On 04/02/2015 04:58 PM, Juergen Schoenwaelder wrote: > On Wed, Apr 01, 2015 at 02:40:52PM +0200, Ladislav Lhotka wrote: >> Right, this is the point I've been trying to make. If we want YANG >> authors to use standard modules with typedefs/groupings, they should be >> easy to read and understand. Being forced to inspect x different >> versions and figure out which is the right one to use doesn't seem very >> user-friendly. >> > This is actually simply. If foo.2 replaces foo.1, you mark foo.1 as > obsolete and tools will tell you that you use something that is marked > obsolete. In some cases, using what is obsolete is what you want, in > other cases you go and see whether the new definition foo.2 works for > you. My main concern here is *human* readability. Inexperienced module authors need to scan existing modules to find typedefs and groupings that might be potentially useful to them. Cluttered modules won't work very well in this respect. I believe most authors of new modules should be fine with the most recent revisions, and there is no need to expose them to all the history. Lada > >> In my experience from programming and schema languages, systems that >> require the writer of an importing module to be more explicit about his >> intentions work generally better than those that try to be clever. > Exactly. This is why you write uses foo.1 or uses foo.2 instead of > just uses foo and have magic applied that figures out what foo stands > for. ;-) > > /js > From nobody Fri Apr 3 08:52:12 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EFB1ABD3C for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 08:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du7cabQc9NeG for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 08:52:06 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 276B31AC3B9 for <netmod@ietf.org>; Fri, 3 Apr 2015 08:52:06 -0700 (PDT) Received: by lboc7 with SMTP id c7so81124159lbo.1 for <netmod@ietf.org>; Fri, 03 Apr 2015 08:52:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U8AS9QOYB4kZ4TX1NXkE1SuBUdMI4sigNFfPwk6ASEA=; b=ZAh6Q8UQ58DXzgFrOFrZ/N/vgtxoOXPzFVA8QaXf0AT5avdSL5YmZF9eherYvNPrMQ +waTd074CVnsTM9BmArl+tSswD1hgMS6KW+89VAZ51D5881o4lKBrPVo1QQSN5gskBPG FZxMZcJ3J9zq9pgA6fVF9/4gSB5gbmk3C+CcovqhBzdzDaKUkw5/QDFNyy3whgcH0nif t4Lf+oLnAm03mEWR9WjqP/nBAz5kGHGQjO0lBR5+XIYHov62OcNX7MXlbbqbOLRYxTse wbTLqpyBl8mtt74HNocrXQYSKkPdiNWtHPCmDHPdIcSaXZOKrwLCl8uDlelY8OzdT+yM EY/A== X-Gm-Message-State: ALoCoQmGuic+e1qNIBewMQSZzcyzIQ3vaksNZCKNMtZ4UBKJKs1SucZpgwBX3CJeYuw9MVuvMkh3 MIME-Version: 1.0 X-Received: by 10.112.141.202 with SMTP id rq10mr2700506lbb.88.1428076324660; Fri, 03 Apr 2015 08:52:04 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Apr 2015 08:52:04 -0700 (PDT) In-Reply-To: <551E71CE.3040802@nic.cz> References: <201503311941.t2VJf45r097817@idle.juniper.net> <m2384khvhn.fsf@nic.cz> <20150402145838.GA79268@elstar.local> <551E71CE.3040802@nic.cz> Date: Fri, 3 Apr 2015 08:52:04 -0700 Message-ID: <CABCOCHT_EnfuyJS4LqU2LD17ujhNxW5s-L_hxBdfSkf4mPm-bA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/bOrlFWI62QQNNrTDJTuWKvJnJvE> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 15:52:11 -0000 On Fri, Apr 3, 2015 at 3:56 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > On 04/02/2015 04:58 PM, Juergen Schoenwaelder wrote: >> >> On Wed, Apr 01, 2015 at 02:40:52PM +0200, Ladislav Lhotka wrote: >>> >>> Right, this is the point I've been trying to make. If we want YANG >>> authors to use standard modules with typedefs/groupings, they should be >>> easy to read and understand. Being forced to inspect x different >>> versions and figure out which is the right one to use doesn't seem very >>> user-friendly. >>> >> This is actually simply. If foo.2 replaces foo.1, you mark foo.1 as >> obsolete and tools will tell you that you use something that is marked >> obsolete. In some cases, using what is obsolete is what you want, in >> other cases you go and see whether the new definition foo.2 works for >> you. > > > My main concern here is *human* readability. Inexperienced module authors > need to scan existing modules to find typedefs and groupings that might be > potentially useful to them. Cluttered modules won't work very well in this > respect. > > I believe most authors of new modules should be fine with the most recent > revisions, and there is no need to expose them to all the history. > I am also concerned about readability. My main concern is that readers will be forced to open and compare several revisions of each module, and it will be extremely difficult to determine what a given revision of each module actually contains. IMO foo-type.1 foo-type.2 is much easier to detect as different, rather than examining the dependency chain to see that the foo-type is really different every place it is used. The various typedefs and groupings will not be that different by direct import. Instead 2nd or 3rd layer imports will be different, hiding the subtle changes. > Lada > Andy >> >>> In my experience from programming and schema languages, systems that >>> require the writer of an importing module to be more explicit about his >>> intentions work generally better than those that try to be clever. >> >> Exactly. This is why you write uses foo.1 or uses foo.2 instead of >> just uses foo and have magic applied that figures out what foo stands >> for. ;-) >> >> /js >> > From nobody Fri Apr 3 11:43:46 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9691ACF18 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4XgUmrNGRIl for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 11:43:44 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id C9BD51ACF17 for <netmod@ietf.org>; Fri, 3 Apr 2015 11:43:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HOleQ01ohFrIDEWgdl9fb2jCKJC1F12HIOiHBM+CDYyE/of2CTyol/wcEmWdY2A3; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Ye6ZC-00040u-Se for netmod@ietf.org; Fri, 03 Apr 2015 14:43:42 -0400 Received: from 76.254.48.21 by webmail.earthlink.net with HTTP; Fri, 3 Apr 2015 14:43:42 -0400 Message-ID: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Fri, 3 Apr 2015 11:43:42 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: "netmod@ietf.org" <netmod@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115370d996b4db114e5d4c99a97c8e182e367350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.41 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/dXZpOLYhNGJ8trXC7J480TPAGec> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 18:43:45 -0000 Hi - >From: Andy Bierman <andy@yumaworks.com> >Sent: Apr 3, 2015 2:14 AM ... >Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics ... >RESTCONF already has the 'content' query parameter that allows >config, operational, or both. This is good enough. >It is trivial for you to add your own content filters to >the RPC operations (if you want to prove that standards >for more classifications are needed) I think you're setting a really low bar for "good enough," but recognize that this is a judgement call. As the number of aspects of interest grows, it becomes more important that the models should have information allowing their bits and pieces to be marked in some way so that aspect-oriented operations become practical. I'm not suggesting that the route of the GDMO "PACKAGE" construct is necessarily the way to go, but the need to be able to factor definitions in this way has been recognized, if not necessarily exploited, since at least the 1980's. Getting back to the start of this thread, there's an underlying question of whether there should be some set of standardized aspects, e.g. "statistics" or "performance", built into the modeling environment (as config and operational, for example) or whether the modeling language should provide a facility for identifying new aspects, some of which might potentially eventually be enshrined in standards-track specifications. Randy From nobody Fri Apr 3 12:08:04 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A84B1B29E1 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ct6gDKoykS3 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 12:08:02 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 EB1CB1B2A23 for <netmod@ietf.org>; Fri, 3 Apr 2015 12:07:55 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so83929253lbb.3 for <netmod@ietf.org>; Fri, 03 Apr 2015 12:07:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=P0SMM3AM/C5rK0vmMXAXoroP8VRhk49QtNYm/WUlqFo=; b=j01KUoHGsB3sz4cxC8haJC6FnbW0sfNR7E3PRrGS+83TjtNjHojOBnaccfMBu7rCk1 24Aw5CjnSRmPLAeg341sonM/F1NSMnqLForgNO7yJFJz1ew1VzU9uhZoW7bwI1/kgbz3 lQT+qB55X1Lr6m1gGjRSjT9Rk0WJFMlvbfRYSxK8hiHo0MxrJjJPptIcMH0JV/BnvZdJ hwXEnYlehb97WiuAefy4aPhRCe20jU+EOobebTG/3OWOHt4nR6sIzZFyewAzK1RaaeUt TEsZHPtc8sieYFhWBbqoZ3KHAiuTIf5X8TfsZvUPrIXP+f4tFLKimKnuwTsjf8hoTlyG 452A== X-Gm-Message-State: ALoCoQk0kmiepB3kUFuXgsQgpk9ytEABXJKYszXv8mjM9ZxrnwvfokftV5MXehkOwiDv1XiX0GLk MIME-Version: 1.0 X-Received: by 10.112.205.103 with SMTP id lf7mr3237443lbc.37.1428088074256; Fri, 03 Apr 2015 12:07:54 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Apr 2015 12:07:54 -0700 (PDT) In-Reply-To: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Fri, 3 Apr 2015 12:07:54 -0700 Message-ID: <CABCOCHRowN5=OYmygbmgS5rRr45As3xeentvyp-Jowq_PkwLpg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/vnbfK5L3yp1dVeQPAGoF-84hpsc> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 19:08:03 -0000 On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > >>From: Andy Bierman <andy@yumaworks.com> >>Sent: Apr 3, 2015 2:14 AM > ... >>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics > ... >>RESTCONF already has the 'content' query parameter that allows >>config, operational, or both. This is good enough. >>It is trivial for you to add your own content filters to >>the RPC operations (if you want to prove that standards >>for more classifications are needed) > > I think you're setting a really low bar for "good enough," > but recognize that this is a judgement call. I really don't want YANG Doctors in long debates whether a particular leaf is operational state, a performance counter, a fault counter, or some combination of everything. I agree the complete lack of a classification system makes it difficult to construct a high-level view of multiple YANG modules, but this is something that vendors and SDOs may figure out over time. We could add statements like "related-to /some/path;" then we could have a different sub-statement for each type of relation. container interfaces { related-to /if:interfaces-state { ... } ... } I don't know that this will be any better than description-stmts. It would certainly be a lot of effort to add new statements. > > As the number of aspects of interest grows, it becomes more > important that the models should have information allowing > their bits and pieces to be marked in some way so that > aspect-oriented operations become practical. I'm not > suggesting that the route of the GDMO "PACKAGE" construct > is necessarily the way to go, but the need to be able to > factor definitions in this way has been recognized, if > not necessarily exploited, since at least the 1980's. > > Getting back to the start of this thread, there's an underlying > question of whether there should be some set of standardized > aspects, e.g. "statistics" or "performance", built into the > modeling environment (as config and operational, for example) > or whether the modeling language should provide a facility for > identifying new aspects, some of which might potentially > eventually be enshrined in standards-track specifications. > I had classification statements in the YANG conformance draft but was told to take them out because we did not need to add any meta-data to modules (objects or conformance) that gave some classification related to FCAPS. We did not need any functional classifications like 'routing, access-control, logging'. > Randy Andy From nobody Fri Apr 3 15:08:07 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78711A1B0C for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 15:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyQSeBnbTD-d for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 15:08:04 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 EC4DE1A1AF0 for <netmod@ietf.org>; Fri, 3 Apr 2015 15:08:03 -0700 (PDT) Received: by lajy8 with SMTP id y8so86582247laj.0 for <netmod@ietf.org>; Fri, 03 Apr 2015 15:08:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nq6R9FWLy+jchwlaJ6ddeg9D3mEpVB/ElIE+IAtjFMA=; b=Ty4oTUEYEP8ijUz4Ib7NE6PxcOO2FA1SpVo4rr8P07y7AG3PueKy6+iL3662YnGHHc Vx95BDDvWDLpin8QJi9ayVu7lAQVgQfwwykihMlqfvDG6Um1DalaFexHoL9ESLLGvDWb asmI022HV5UNEzSggwZ5ZzqjcuQ513BSNnaUFcs/DRPQAV/8OZflRykc/mPeeSsGstBI rTiRxXlt1bITvCM3pdtXTN1dL72g0ShVMlBHfW/JZRmyjw/MyvAbh0O9ec+H79xyzMVD mP4BTmx3XoCJcr0yJtGIH1bsMh7uKMIPdg5e2L6Q7Vfnii76wEziU3Shs694qdla1okj zCMA== X-Gm-Message-State: ALoCoQlVqMsJz2VFlI19NVtiUSX+8qkYWROUCxX4QwsYd7J5fupa+2KbPLGL6Q4uckWoncG3pekX MIME-Version: 1.0 X-Received: by 10.152.42.141 with SMTP id o13mr3824554lal.33.1428098882445; Fri, 03 Apr 2015 15:08:02 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Apr 2015 15:08:02 -0700 (PDT) In-Reply-To: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Fri, 3 Apr 2015 15:08:02 -0700 Message-ID: <CABCOCHRv0tiHdKRbLRkm3p3cF7H1He89B+m2J7aA=_ht2nVBAQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/7BfvStpxgrMkbQIC2nsQtRcz9tk> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 22:08:06 -0000 On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > >>From: Andy Bierman <andy@yumaworks.com> >>Sent: Apr 3, 2015 2:14 AM > ... >>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics > ... >>RESTCONF already has the 'content' query parameter that allows >>config, operational, or both. This is good enough. >>It is trivial for you to add your own content filters to >>the RPC operations (if you want to prove that standards >>for more classifications are needed) > > I think you're setting a really low bar for "good enough," > but recognize that this is a judgement call. > > As the number of aspects of interest grows, it becomes more > important that the models should have information allowing > their bits and pieces to be marked in some way so that > aspect-oriented operations become practical. I'm not > suggesting that the route of the GDMO "PACKAGE" construct > is necessarily the way to go, but the need to be able to > factor definitions in this way has been recognized, if > not necessarily exploited, since at least the 1980's. > > Getting back to the start of this thread, there's an underlying > question of whether there should be some set of standardized > aspects, e.g. "statistics" or "performance", built into the > modeling environment (as config and operational, for example) > or whether the modeling language should provide a facility for > identifying new aspects, some of which might potentially > eventually be enshrined in standards-track specifications. > How are client tools expected to use the extra classifications? Do we expect operators and programmers to pick out the interesting child nodes for a given list or container, or do we expect applications to automatically select based on this extra classification? Do we expect ETags for separate types of operational state to be maintained? Caching data, pushing data, retrieval filters all need to be designed together to be efficient and useful. > Randy Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 3 15:54:01 2015 Return-Path: <rjs@rob.sh> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A681A701A for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 15:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUTGUMTBAiCD for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 15:53:51 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB4F1A7018 for <netmod@ietf.org>; Fri, 3 Apr 2015 15:53:49 -0700 (PDT) Received: from [216.3.101.62] (helo=piccolo.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1YeAT8-00053Q-Vy; Fri, 03 Apr 2015 23:53:43 +0100 Date: Fri, 3 Apr 2015 15:53:36 -0700 From: Rob Shakir <rjs@rob.sh> To: Andy Bierman <andy@yumaworks.com>, Balazs Lengyel <balazs.lengyel@ericsson.com> Message-ID: <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> In-Reply-To: <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> References: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <551E4EAA.8090703@ericsson.com> <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> X-Mailer: Airmail Beta (298) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="551f19f0_737b8ddc_2d41" Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/AA0HdgD_mK4X9P-gMzLvHxZADLk> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "=?utf-8?Q?netmod=40ietf.org?=" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 22:54:00 -0000 --551f19f0_737b8ddc_2d41 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Andy, Your arguments here are too abstract for me =E2=80=94 sorry. I struggle t= o understand really what you are proposing as an alternative approach. Let=E2=80=99s talk about a specific example (which I appreciate that you = might think is overly simplistic =E2=80=94 but my requirement here is to = have usable models that we can interact with, not just YANG models for th= e sake of YANG models) =E2=80=94 configuring a BGP peer in a network wher= e there are multiple configuration writers. If I want to perform the oper= ation of: * Configure a new peer on a network element. * Determine whether the configuration that is active in the system is the= one that I wrote (rather than another system=E2=80=99s intention). * Retrieve operational counters that correspond to the peer. Primarily, I push some configuration to neighbor=5Bpeer-address=3D172.0.2= .1=5D/config/=7Bpeer-as,description=7D =C2=A0=E2=80=94 =C2=A0I can immedi= ately get the actual active configuration by pulling the corresponding =E2= =80=98state=E2=80=99 container. Since I have duplicates that tell me the = =E2=80=98active=E2=80=99 configuration as well as what was pushed, then I= know whether my config that I tried to apply was the one that was accept= ed, rather than another writer=E2=80=99s. Indeed, I can write a generic method that does this verification given a = certain path (always check that the =E2=80=98state=E2=80=99 container nex= t to the =E2=80=98config=E2=80=99 one matches) - so I don=E2=80=99t need = to have any kind of mapping that says /device/routing-protocols/bgp/state= /neighbor=E2=80=A6 is the corresponding place for state for a neighbour c= onfigured at /device/routing-protocols/bgp/config/neighbor=E2=80=A6. for = each leaf =5BNote: the problem with splits =E2=80=9Chigher in the tree=E2= =80=9D like this is that it is not clear where the state container starts= =E2=80=94 is it at routing-protocols/state or bgp/state=3F=5D I then want to check that the peer came up - and get any counters related= to it - I can do this by just pulling the =E2=80=98operational: true=E2=80= =99 parameters from the state container - which lets me make a targeted q= uery for the thing that I am actually interested in - and only receive th= e data that the actual network element has derived - rather than duplicat= ing things on the wire. This is quite a typical workflow where we need to be able to easily relat= e intended state (config), active state (running configuration parameters= ), and derived state to one another to verify a change on the network. The proposal that is in draft-openconfig-netmod-opstate-00, seems to me t= o be relatively simple solution that fits requirements quite neatly =E2=80= =94 and as of yet, I don=E2=80=99t think we have found a case where it do= es not work. Multiple folks are starting to write code to interact with t= hese models - so this will be a good test of whether it works as we expec= t. I don=E2=80=99t see the need for a mapping dictionary between config and = state nodes - and find the idea that the mapping is included in human-rea= dable prose somewhat bizarre, when we are talking about programmatic inte= raction. Can you outline a case where you don=E2=80=99t think that the approach wo= rks please=3F I=E2=80=99d really love to see some alternative proposals -= since we had a lot of discussion on this topic over the last few months = with a bunch of different folks - and if we=E2=80=99ve missed some better= way of doing this, or some flaw in our approach, then I=E2=80=99d be kee= n to iterate it=21 r. On 3 April 2015 at 02:14:58, Andy Bierman (andy=40yumaworks.com) wrote: On =46ri, Apr 3, 2015 at 1:26 AM, Balazs Lengyel =20 <balazs.lengyel=40ericsson.com> wrote: =20 > Hello, =20 > I think the problem is real, needs solving, so just some ideas: =20 > - put state, statistics and config in the same container/list, but enha= nce =20 > Netconf/restconf to be able to <get> just config, just state, just coun= ters =20 > or some combinations of all this. As I remember the main reason to put = state =20 > and config in separate branches was the need to be able to read them =20 > separately. At that time I tought it a mistake that we use module struc= ture =20 > instead of extending netconf. As Andy stated: =22structure is a lousy t= ool=22. =20 > Still in R=46C6087bis we have: =20 > =22The separation of configuration data and operational state SHOULD be= =20 > considered carefully. It is often useful to define separate top- =20 > level containers for configuration and non-configuration data.=22 =20 > This uses the structure as a tool. :-) =20 > =20 RESTCON=46 already has the 'content' query parameter that allows =20 config, operational, or both. This is good enough. =20 It is trivial for you to add your own content filters to =20 the RPC operations (if you want to prove that standards =20 for more classifications are needed) =20 Andy =20 > or =20 > - a new YANG statement that links together two lists indicating that on= e is =20 > the config part while the other is the state =20 Prove this works as an extension first. =20 IMO it is easy to come up with simplistic solutions for =20 trivial test-cases. Create a general solution first, =20 prove that it helps, then ask the IET=46 to standardize it. =20 > regards Balazs =20 Andy =20 > =20 > P.S. IET=46 was always asking for operator input. Now we got it, will w= e do =20 > something about it=3F =20 > =20 > On 2015-04-02 20:02, Randy Presuhn wrote: =20 >> =20 >> Hi - =20 >> =20 >> I think what they're really asking for is an automated way =20 >> to identify the bits and pieces that correspond to a particular =20 >> aspect of a managed thingie. This has already happened with =20 >> =22config true=22. Module structure is a really lousy mechanism =20 >> for identifying aspects; a given bit of information may =20 >> participate in more than one aspect. So I'm agreeing with =20 >> Andy that structure is a lousy tool for the job. =20 >> =20 >> However, the job is an important one. Structure is not the =20 >> solution. Look for another tool. =20 >> =20 >> Randy =20 >> =20 >> -----Original Message----- =20 >>> =20 >>> =46rom: Andy Bierman <andy=40yumaworks.com> =20 >>> Sent: Apr 2, 2015 10:49 AM =20 >>> To: Anees Shaikh <aashaikh=40google.com> =20 >>> Cc: =22netmod=40ietf.org=22 <netmod=40ietf.org> =20 >>> Subject: Re: =5Bnetmod=5D New 6087bis issues - connect config - state= - =20 >>> statistics =20 >>> =20 >>> On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh=40google.com>= =20 >>> wrote: =20 >>>> =20 >>>> We've laid out why this is a problem (even for existing R=46C models= ) in =20 >>>> draft-openconfig-netmod-opstate-00 and summarized during the =20 >>>> presentation in =20 >>>> Dallas. The problem is exacerbated when trying to compose multiple =20 >>>> models =20 >>>> into a coherent whole -- clearly it's not possible to manage a servi= ce =20 >>>> or =20 >>>> device with an interfaces model alone. =20 >>>> =20 >>>> Reading the description statements to learn where different types of= =20 >>>> data is =20 >>>> stored is not a solution IMO -- we need to think how this will be us= e =20 >>>> programmatically by users. And we made the deliberate tradeoff to =20 >>>> introduce =20 >>>> some extra work in building a consistent model for the benefit of a = =20 >>>> simple =20 >>>> programming construct to set and retrieve the data. =20 >>>> =20 >>> I disagree. =20 >>> Many times the relationship between a config knob setting =20 >>> and operational state is not simple. There may be all kinds of =20 >>> overlap and dynamic conditions that change the set of =20 >>> interesting objects at the moment. =46orcing a certain structure =20 >>> between config and operational nodes will not work as a general solut= ion. =20 >>> You should develop some YANG extensions if you think the =20 >>> problem can be solved without description-stmts. =20 >>> =20 >>> =20 >>> =20 >>> =20 >>>> thanks. =20 >>>> -- Anees =20 >>> =20 >>> Andy =20 >>> =20 >>>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy=40yumaworks.com> = wrote: =20 >>>>> =20 >>>>> Hi, =20 >>>>> =20 >>>>> You need to read the description-stmts of the relevant data nodes =20 >>>>> to find out where other related data nodes can be found. =20 >>>>> IMO the sibling config/state approach should only =20 >>>>> be used if the state can exist without the config. =20 >>>>> =20 >>>>> If I have an ACL or some filter that may be nested within lists =20 >>>>> with lots of keys, then it is extremely wasteful to replicate =20 >>>>> all the scaffolding and keys, just to store a couple counters =20 >>>>> for that ACL. It is much better to just put the counters in the ACL= =20 >>>>> entry. =20 >>>>> =20 >>>>> But many times the set of interesting objects related to some =20 >>>>> config is far more complicated than that, so the description-stmt =20 >>>>> is the only place to document this information. =20 >>>>> =20 >>>>> =20 >>>>> Andy =20 >>>>> =20 >>>>> =20 >>>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel =20 >>>>> <balazs.lengyel=40ericsson.com> wrote: =20 >>>>>> =20 >>>>>> Hello, =20 >>>>>> As indicated by operators in Dallas and as experienced by Ericsson= as =20 >>>>>> well, =20 >>>>>> it is sometimes not easy to find the status data for a given bit o= f =20 >>>>>> configuration (interface, route, etc.). Often the state and =20 >>>>>> configuration =20 >>>>>> are handled in parallel subtrees with the same structure. However = this =20 >>>>>> is =20 >>>>>> not part of the guidelines. Also counters are often separated from= =20 >>>>>> state =20 >>>>>> data again without a clear guideline to connect statistics with th= e =20 >>>>>> config. =20 >>>>>> I believe 6087 should provide guidelines how to find state and =20 >>>>>> staistics =20 >>>>>> information for a give piece of configuration. E.g. how do find th= e =20 >>>>>> number =20 >>>>>> of outgoing packets for an interface=3F =20 >>>>>> regards Balazs =20 >>>>>> =20 >>>>>> On 2015-04-02 14:47, Martin Bjorklund wrote: =20 >>>>>>> =20 >>>>>>> Hi, =20 >>>>>>> =20 >>>>>>> Here's a list of some things that maybe should be added to 6087bi= s. =20 >>>>>>> Some of them are stylistic; I don't know if we should add those o= r =20 >>>>>>> not. =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> 3.6 References =20 >>>>>>> =20 >>>>>>> The R=46C Editor prefers the style: =20 >>>>>>> =20 >>>>>>> reference =20 >>>>>>> =22R=46C <NNNN>: <title>=22; =20 >>>>>>> =20 >>>>>>> reference =20 >>>>>>> =22R=46C <NNNN>: <very long title that spans =20 >>>>>>> more than one line>=22; =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> I think we should document this. =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> 4.1 =20 >>>>>>> =20 >>>>>>> Update this wrt. example modules. Should they be marked with CODE= =20 >>>>>>> at =20 >>>>>>> all=3F =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> 5.1. Module Naming Conventions =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> Add: IET=46 modules SHOULD (MUST=3F) start with =22ietf-=22. =20 >>>>>>> =20 >>>>>>> Example modules SHOULD start with =22example-=22 or =22ex-=22. =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> 5.2. Identifiers =20 >>>>>>> =20 >>>>>>> Add: avoid unnecessary prefixes on names. =20 >>>>>>> =20 >>>>>>> BAD: =20 >>>>>>> =20 >>>>>>> list interface =7B =20 >>>>>>> ... =20 >>>>>>> leaf interface-name =7B ... =7D =20 >>>>>>> leaf interface-type =7B ... =7D =20 >>>>>>> =7D =20 >>>>>>> =20 >>>>>>> GOOD: =20 >>>>>>> =20 >>>>>>> list interface =7B =20 >>>>>>> ... =20 >>>>>>> leaf name =7B ... =7D =20 >>>>>>> leaf type =7B ... =7D =20 >>>>>>> =7D =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> use-hypened-names =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> 5.8 Namespace Assignments =20 >>>>>>> =20 >>>>>>> OLD: =20 >>>>>>> =20 >>>>>>> The following examples of non-Standards-Track modules are only =20 >>>>>>> suggestions. There are no guidelines for this type of URN in =20 >>>>>>> this =20 >>>>>>> document: =20 >>>>>>> =20 >>>>>>> http://example.com/ns/example-interfaces =20 >>>>>>> =20 >>>>>>> http://example.com/ns/example-system =20 >>>>>>> =20 >>>>>>> NEW: =20 >>>>>>> =20 >>>>>>> There are no guidelines for non-Standards-Track modules. =20 >>>>>>> =20 >>>>>>> Example modules SHOULD use R=46C 6963 style URNs: =20 >>>>>>> =20 >>>>>>> urn:example:<module-name> =20 >>>>>>> =20 >>>>>>> Or 2606-style =20 >>>>>>> =20 >>>>>>> http://example.com/... =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> /martin =20 >>>>>>> =20 >>>>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =20 >>>>>>> netmod mailing list =20 >>>>>>> netmod=40ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/netmod =20 >>>>>>> =20 >>>>>>> =20 >>>>>> -- =20 >>>>>> Balazs Lengyel Ericsson Hungary Ltd. =20 >>>>>> Senior Specialist =20 >>>>>> ECN: 831 7320 =20 >>>>>> Mobile: +36-70-330-7909 email: =20 >>>>>> Balazs.Lengyel=40ericsson.com =20 >>>>>> =20 >>>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =20 >>>>>> netmod mailing list =20 >>>>>> netmod=40ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/netmod =20 >>>>> =20 >>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F = =20 >>>>> netmod mailing list =20 >>>>> netmod=40ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/netmod =20 >>>> =20 >>>> =20 >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F = =20 >>> netmod mailing list =20 >>> netmod=40ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/netmod =20 >> =20 >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 >> netmod mailing list =20 >> netmod=40ietf.org =20 >> https://www.ietf.org/mailman/listinfo/netmod =20 >> =20 > =20 > -- =20 > Balazs Lengyel Ericsson Hungary Ltd. =20 > Senior Specialist =20 > ECN: 831 7320 =20 > Mobile: +36-70-330-7909 email: Balazs.Lengyel=40ericsson.com =20 > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 > netmod mailing list =20 > netmod=40ietf.org =20 > https://www.ietf.org/mailman/listinfo/netmod =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 netmod mailing list =20 netmod=40ietf.org =20 https://www.ietf.org/mailman/listinfo/netmod =20 --551f19f0_737b8ddc_2d41 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</= style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s= pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r= gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>Andy,</div><div id=3D=22= bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13= px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><br></div>= <div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial= ;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22= >Your arguments here are too abstract for me =E2=80=94 sorry. I struggle = to understand really what you are proposing as an alternative approach.</= div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,A= rial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: au= to;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-famil= y:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; li= ne-height: auto;=22>Let=E2=80=99s talk about a specific example (which I = appreciate that you might think is overly simplistic =E2=80=94 but my req= uirement here is to have usable models that we can interact with, not jus= t YANG models for the sake of YANG models) =E2=80=94 configuring a BGP pe= er in a network where there are multiple configuration writers. If I want= to perform the operation of:</div><div id=3D=22bloop=5Fcustomfont=22 sty= le=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0= ); margin: 0px; line-height: auto;=22><br></div><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r= gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>* Configure a new peer= on a network element.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22= font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margi= n: 0px; line-height: auto;=22>* Determine whether the configuration that = is active in the system is the one that I wrote (rather than another syst= em=E2=80=99s intention).</div><div id=3D=22bloop=5Fcustomfont=22 style=3D= =22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); ma= rgin: 0px; line-height: auto;=22>* Retrieve operational counters that cor= respond to the peer.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22f= ont-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin= : 0px; line-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22= style=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0= ,1.0); margin: 0px; line-height: auto;=22>Primarily, I push some configur= ation to neighbor=5Bpeer-address=3D172.0.2.1=5D/config/=7Bpeer-as,descrip= tion=7D  =E2=80=94  I can immediately get the actual active con= figuration by pulling the corresponding =E2=80=98state=E2=80=99 container= . Since I have duplicates that tell me the =E2=80=98active=E2=80=99 confi= guration as well as what was pushed, then I know whether my config that I= tried to apply was the one that was accepted, rather than another writer= =E2=80=99s.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-famil= y:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; li= ne-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D= =22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); ma= rgin: 0px; line-height: auto;=22>Indeed, I can write a generic method tha= t does this verification given a certain path (always check that the =E2=80= =98state=E2=80=99 container next to the =E2=80=98config=E2=80=99 one matc= hes) - so I don=E2=80=99t need to have any kind of mapping that says /dev= ice/routing-protocols/bgp/state/neighbor=E2=80=A6 is the corresponding pl= ace for state for a neighbour configured at /device/routing-protocols/bgp= /config/neighbor=E2=80=A6. for each leaf =5BNote: the problem with splits= =E2=80=9Chigher in the tree=E2=80=9D like this is that it is not clear w= here the state container starts =E2=80=94 is it at routing-protocols/stat= e or bgp/state=3F=5D</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22f= ont-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin= : 0px; line-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22= style=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0= ,1.0); margin: 0px; line-height: auto;=22>I then want to check that the p= eer came up - and get any counters related to it - I can do this by just = pulling the =E2=80=98operational: true=E2=80=99 parameters from the state= container - which lets me make a targeted query for the thing that I am = actually interested in - and only receive the data that the actual networ= k element has derived - rather than duplicating things on the wire.</div>= <div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial= ;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22= ><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helv= etica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-hei= ght: auto;=22>This is quite a typical workflow where we need to be able t= o easily relate intended state (config), active state (running configurat= ion parameters), and derived state to one another to verify a change on t= he network.</div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-famil= y:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; li= ne-height: auto;=22><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D= =22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); ma= rgin: 0px; line-height: auto;=22>The proposal that is in draft-openconfig= -netmod-opstate-00, seems to me to be relatively simple solution that fit= s requirements quite neatly =E2=80=94 and as of yet, I don=E2=80=99t thin= k we have found a case where it does not work. Multiple folks are startin= g to write code to interact with these models - so this will be a good te= st of whether it works as we expect.</div><div id=3D=22bloop=5Fcustomfont= =22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,= 0,0,1.0); margin: 0px; line-height: auto;=22><br></div><div id=3D=22bloop= =5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; c= olor: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>I don=E2=80=99t= see the need for a mapping dictionary between config and state nodes - a= nd find the idea that the mapping is included in human-readable prose som= ewhat bizarre, when we are talking about programmatic interaction.</div><= div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;= font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22= ><br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helv= etica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-hei= ght: auto;=22>Can you outline a case where you don=E2=80=99t think that t= he approach works please=3F I=E2=80=99d really love to see some alternati= ve proposals - since we had a lot of discussion on this topic over the la= st few months with a bunch of different folks - and if we=E2=80=99ve miss= ed some better way of doing this, or some flaw in our approach, then I=E2= =80=99d be keen to iterate it=21</div><div id=3D=22bloop=5Fcustomfont=22 = style=3D=22font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,= 1.0); margin: 0px; line-height: auto;=22><br></div><div id=3D=22bloop=5Fc= ustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color= : rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>r.</div> <div id=3D= =22bloop=5Fsign=5F1428099773589266176=22 class=3D=22bloop=5Fsign=22></div= > <br><p class=3D=22airmail=5Fon=22 style=3D=22color:=23000;=22>On 3 Apri= l 2015 at 02:14:58, Andy Bierman (<a href=3D=22mailto:andy=40yumaworks.co= m=22>andy=40yumaworks.com</a>) wrote:</p> <blockquote type=3D=22cite=22 c= lass=3D=22clean=5Fbq=22><span><div><div></div><div>On =46ri, Apr 3, 2015 = at 1:26 AM, Balazs Lengyel <br><balazs.lengyel=40ericsson.com> wrote: <br>> Hello, <br>> I think the problem is real, needs solving, so just some ideas: <br>> - put state, statistics and config in the same container/list, b= ut enhance <br>> Netconf/restconf to be able to <get> just config, just sta= te, just counters <br>> or some combinations of all this. As I remember the main reason = to put state <br>> and config in separate branches was the need to be able to read = them <br>> separately. At that time I tought it a mistake that we use modul= e structure <br>> instead of extending netconf. As Andy stated: =22structure is a = lousy tool=22. <br>> Still in R=46C6087bis we have: <br>> =22The separation of configuration data and operational state SH= OULD be <br>> considered carefully. It is often useful to define separate = top- <br>> level containers for configuration and non-configuration data= .=22 <br>> This uses the structure as a tool. :-) <br>> <br> <br> <br>RESTCON=46 already has the 'content' query parameter that allows <br>config, operational, or both. This is good enough. <br>It is trivial for you to add your own content filters to <br>the RPC operations (if you want to prove that standards <br>for more classifications are needed) <br> <br> <br>Andy <br> <br>> or <br>> - a new YANG statement that links together two lists indicating = that one is <br>> the config part while the other is the state <br> <br>Prove this works as an extension first. <br>IMO it is easy to come up with simplistic solutions for <br>trivial test-cases. Create a general solution first, <br>prove that it helps, then ask the IET=46 to standardize it. <br> <br> <br>> regards Balazs <br> <br>Andy <br> <br>> <br>> P.S. IET=46 was always asking for operator input. Now we got it,= will we do <br>> something about it=3F <br>> <br>> On 2015-04-02 20:02, Randy Presuhn wrote: <br>>> <br>>> Hi - <br>>> <br>>> I think what they're really asking for is an automated way <br>>> to identify the bits and pieces that correspond to a particu= lar <br>>> aspect of a managed thingie. This has already happened with= <br>>> =22config true=22. Module structure is a really lousy mecha= nism <br>>> for identifying aspects; a given bit of information may <br>>> participate in more than one aspect. So I'm agreeing with <br>>> Andy that structure is a lousy tool for the job. <br>>> <br>>> However, the job is an important one. Structure is not the <br>>> solution. Look for another tool. <br>>> <br>>> Randy <br>>> <br>>> -----Original Message----- <br>>>> <br>>>> =46rom: Andy Bierman <andy=40yumaworks.com> <br>>>> Sent: Apr 2, 2015 10:49 AM <br>>>> To: Anees Shaikh <aashaikh=40google.com> <br>>>> Cc: =22netmod=40ietf.org=22 <netmod=40ietf.org> <br>>>> Subject: Re: =5Bnetmod=5D New 6087bis issues - connect c= onfig - state - <br>>>> statistics <br>>>> <br>>>> On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashai= kh=40google.com> <br>>>> wrote: <br>>>>> <br>>>>> We've laid out why this is a problem (even for exist= ing R=46C models) in <br>>>>> draft-openconfig-netmod-opstate-00 and summarized du= ring the <br>>>>> presentation in <br>>>>> Dallas. The problem is exacerbated when trying to c= ompose multiple <br>>>>> models <br>>>>> into a coherent whole -- clearly it's not possible t= o manage a service <br>>>>> or <br>>>>> device with an interfaces model alone. <br>>>>> <br>>>>> Reading the description statements to learn where di= fferent types of <br>>>>> data is <br>>>>> stored is not a solution IMO -- we need to think how= this will be use <br>>>>> programmatically by users. And we made the delibera= te tradeoff to <br>>>>> introduce <br>>>>> some extra work in building a consistent model for t= he benefit of a <br>>>>> simple <br>>>>> programming construct to set and retrieve the data. <br>>>>> <br>>>> I disagree. <br>>>> Many times the relationship between a config knob settin= g <br>>>> and operational state is not simple. There may be all k= inds of <br>>>> overlap and dynamic conditions that change the set of <br>>>> interesting objects at the moment. =46orcing a certain = structure <br>>>> between config and operational nodes will not work as a = general solution. <br>>>> You should develop some YANG extensions if you think the= <br>>>> problem can be solved without description-stmts. <br>>>> <br>>>> <br>>>> <br>>>> <br>>>>> thanks. <br>>>>> -- Anees <br>>>> <br>>>> Andy <br>>>> <br>>>>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <and= y=40yumaworks.com> wrote: <br>>>>>> <br>>>>>> Hi, <br>>>>>> <br>>>>>> You need to read the description-stmts of the re= levant data nodes <br>>>>>> to find out where other related data nodes can b= e found. <br>>>>>> IMO the sibling config/state approach should onl= y <br>>>>>> be used if the state can exist without the confi= g. <br>>>>>> <br>>>>>> If I have an ACL or some filter that may be nest= ed within lists <br>>>>>> with lots of keys, then it is extremely wasteful= to replicate <br>>>>>> all the scaffolding and keys, just to store a co= uple counters <br>>>>>> for that ACL. It is much better to just put the= counters in the ACL <br>>>>>> entry. <br>>>>>> <br>>>>>> But many times the set of interesting objects re= lated to some <br>>>>>> config is far more complicated than that, so the= description-stmt <br>>>>>> is the only place to document this information. <br>>>>>> <br>>>>>> <br>>>>>> Andy <br>>>>>> <br>>>>>> <br>>>>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel <br>>>>>> <balazs.lengyel=40ericsson.com> wrote: <br>>>>>>> <br>>>>>>> Hello, <br>>>>>>> As indicated by operators in Dallas and as e= xperienced by Ericsson as <br>>>>>>> well, <br>>>>>>> it is sometimes not easy to find the status = data for a given bit of <br>>>>>>> configuration (interface, route, etc.). Ofte= n the state and <br>>>>>>> configuration <br>>>>>>> are handled in parallel subtrees with the sa= me structure. However this <br>>>>>>> is <br>>>>>>> not part of the guidelines. Also counters ar= e often separated from <br>>>>>>> state <br>>>>>>> data again without a clear guideline to conn= ect statistics with the <br>>>>>>> config. <br>>>>>>> I believe 6087 should provide guidelines how= to find state and <br>>>>>>> staistics <br>>>>>>> information for a give piece of configuratio= n. E.g. how do find the <br>>>>>>> number <br>>>>>>> of outgoing packets for an interface=3F <br>>>>>>> regards Balazs <br>>>>>>> <br>>>>>>> On 2015-04-02 14:47, Martin Bjorklund wrote:= <br>>>>>>>> <br>>>>>>>> Hi, <br>>>>>>>> <br>>>>>>>> Here's a list of some things that maybe = should be added to 6087bis. <br>>>>>>>> Some of them are stylistic; I don't know= if we should add those or <br>>>>>>>> not. <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> 3.6 References <br>>>>>>>> <br>>>>>>>> The R=46C Editor prefers the style: <br>>>>>>>> <br>>>>>>>> reference <br>>>>>>>> =22R=46C <NNNN>: <title= >=22; <br>>>>>>>> <br>>>>>>>> reference <br>>>>>>>> =22R=46C <NNNN>: <very = long title that spans <br>>>>>>>> more than one line>=22; <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> I think we should document this. <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> 4.1 <br>>>>>>>> <br>>>>>>>> Update this wrt. example modules. Sh= ould they be marked with CODE <br>>>>>>>> at <br>>>>>>>> all=3F <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> 5.1. Module Naming Conventions <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> Add: IET=46 modules SHOULD (MUST=3F)= start with =22ietf-=22. <br>>>>>>>> <br>>>>>>>> Example modules SHOULD start with =22= example-=22 or =22ex-=22. <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> 5.2. Identifiers <br>>>>>>>> <br>>>>>>>> Add: avoid unnecessary prefixes on n= ames. <br>>>>>>>> <br>>>>>>>> BAD: <br>>>>>>>> <br>>>>>>>> list interface =7B <br>>>>>>>> ... <br>>>>>>>> leaf interface-name =7B ... =7D <br>>>>>>>> leaf interface-type =7B ... =7D <br>>>>>>>> =7D <br>>>>>>>> <br>>>>>>>> GOOD: <br>>>>>>>> <br>>>>>>>> list interface =7B <br>>>>>>>> ... <br>>>>>>>> leaf name =7B ... =7D <br>>>>>>>> leaf type =7B ... =7D <br>>>>>>>> =7D <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> use-hypened-names <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> 5.8 Namespace Assignments <br>>>>>>>> <br>>>>>>>> OLD: <br>>>>>>>> <br>>>>>>>> The following examples of non-Stand= ards-Track modules are only <br>>>>>>>> suggestions. There are no guidelin= es for this type of URN in <br>>>>>>>> this <br>>>>>>>> document: <br>>>>>>>> <br>>>>>>>> http://example.com/ns/example-i= nterfaces <br>>>>>>>> <br>>>>>>>> http://example.com/ns/example-s= ystem <br>>>>>>>> <br>>>>>>>> NEW: <br>>>>>>>> <br>>>>>>>> There are no guidelines for non-Sta= ndards-Track modules. <br>>>>>>>> <br>>>>>>>> Example modules SHOULD use R=46C 69= 63 style URNs: <br>>>>>>>> <br>>>>>>>> urn:example:<module-name> <br>>>>>>>> <br>>>>>>>> Or 2606-style <br>>>>>>>> <br>>>>>>>> http://example.com/... <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> <br>>>>>>>> /martin <br>>>>>>>> <br>>>>>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F <br>>>>>>>> netmod mailing list <br>>>>>>>> netmod=40ietf.org <br>>>>>>>> https://www.ietf.org/mailman/listinfo/ne= tmod <br>>>>>>>> <br>>>>>>>> <br>>>>>>> -- <br>>>>>>> Balazs Lengyel Ericsso= n Hungary Ltd. <br>>>>>>> Senior Specialist <br>>>>>>> ECN: 831 7320 <br>>>>>>> Mobile: +36-70-330-7909 email: <br>>>>>>> Balazs.Lengyel=40ericsson.com <br>>>>>>> <br>>>>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F <br>>>>>>> netmod mailing list <br>>>>>>> netmod=40ietf.org <br>>>>>>> https://www.ietf.org/mailman/listinfo/netmod= <br>>>>>> <br>>>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F <br>>>>>> netmod mailing list <br>>>>>> netmod=40ietf.org <br>>>>>> https://www.ietf.org/mailman/listinfo/netmod <br>>>>> <br>>>>> <br>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F <br>>>> netmod mailing list <br>>>> netmod=40ietf.org <br>>>> https://www.ietf.org/mailman/listinfo/netmod <br>>> <br>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F <br>>> netmod mailing list <br>>> netmod=40ietf.org <br>>> https://www.ietf.org/mailman/listinfo/netmod <br>>> <br>> <br>> -- <br>> Balazs Lengyel Ericsson Hungary Ltd. <br>> Senior Specialist <br>> ECN: 831 7320 <br>> Mobile: +36-70-330-7909 email: Balazs.Lengyel=40eri= csson.com <br>> <br>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= <br>> netmod mailing list <br>> netmod=40ietf.org <br>> https://www.ietf.org/mailman/listinfo/netmod <br> <br>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F <br>netmod mailing list <br>netmod=40ietf.org <br>https://www.ietf.org/mailman/listinfo/netmod <br></div></div></span></blockquote></body></html> --551f19f0_737b8ddc_2d41-- From nobody Fri Apr 3 16:12:27 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868A71A8735 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 16:12:26 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpHn0lBx9Lrt for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 16:12:24 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id A566D1A896B for <netmod@ietf.org>; Fri, 3 Apr 2015 16:12:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pe5F8l7x0NfM6boMj2QATVPH5yP59iyzXtFdXE5heRpy9/IPAUQhNdfn7zA0FSNc; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1YeAlD-0003cb-T9 for netmod@ietf.org; Fri, 03 Apr 2015 19:12:23 -0400 Received: from 76.254.48.21 by webmail.earthlink.net with HTTP; Fri, 3 Apr 2015 19:12:23 -0400 Message-ID: <7890344.1428102743927.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Date: Fri, 3 Apr 2015 16:12:23 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: "netmod@ietf.org" <netmod@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537f2b54ac284669060b841c6dacc88431e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.34 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/vUiXMGFFlfk0FYxBHoD9B5lHJ34> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 23:12:26 -0000 Hi - >From: Andy Bierman <andy@yumaworks.com> >Sent: Apr 3, 2015 3:08 PM >To: Randy Presuhn <randy_presuhn@mindspring.com> >Cc: "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics > >On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn ><randy_presuhn@mindspring.com> wrote: >> Hi - >> >>>From: Andy Bierman <andy@yumaworks.com> >>>Sent: Apr 3, 2015 2:14 AM >> ... >>>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics >> ... >>>RESTCONF already has the 'content' query parameter that allows >>>config, operational, or both. This is good enough. >>>It is trivial for you to add your own content filters to >>>the RPC operations (if you want to prove that standards >>>for more classifications are needed) >> >> I think you're setting a really low bar for "good enough," >> but recognize that this is a judgement call. > > >> >> As the number of aspects of interest grows, it becomes more >> important that the models should have information allowing >> their bits and pieces to be marked in some way so that >> aspect-oriented operations become practical. I'm not >> suggesting that the route of the GDMO "PACKAGE" construct >> is necessarily the way to go, but the need to be able to >> factor definitions in this way has been recognized, if >> not necessarily exploited, since at least the 1980's. >> >> Getting back to the start of this thread, there's an underlying >> question of whether there should be some set of standardized >> aspects, e.g. "statistics" or "performance", built into the >> modeling environment (as config and operational, for example) >> or whether the modeling language should provide a facility for >> identifying new aspects, some of which might potentially >> eventually be enshrined in standards-track specifications. >> > >How are client tools expected to use the extra classifications? They wouldn't have to. >Do we expect operators and programmers to pick out >the interesting child nodes for a given list or container, >or do we expect applications to automatically select based >on this extra classification? I think one would see both, but obviously there's going to be a point of diminishing returns to doing this sort of thing. Of course it'd be helpful for the folks who believe they might need something like this to spell out just what they plan to do with it. >Do we expect ETags for separate types of operational state to >be maintained? Caching data, pushing data, retrieval filters >all need to be designed together to be efficient and useful. Why do you say "separate" types? If they were really separate, a "structural" solution would probably be workable. But the uses of the various bits and pieces of information overlap, so a given piece of data might fall into multiple classifications. Randy From nobody Fri Apr 3 16:28:58 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4AE1A905D for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 16:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYBBwX6j_D3d for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 16:28:53 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (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 3D0D41A9050 for <netmod@ietf.org>; Fri, 3 Apr 2015 16:28:53 -0700 (PDT) Received: by lboc7 with SMTP id c7so86301272lbo.1 for <netmod@ietf.org>; Fri, 03 Apr 2015 16:28:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=llgA2RbhNFMujKll80R27O//45T8cp1lOP5SMlogGsU=; b=EUjqP35u+60bK8ma2ZbQ4OW8vJGmtdHK+ZQNrhEz03weFTJ58Ud84zx2NbzMREEcfw BPKuclvGGiU6YsVp3zGwXKD2ASVs66MXVyy2M5m7pLrZWdtQ3Ze+f/ZBNBrqDn45xrTL sxfTckwRqq6ONjEkOrF28qVdOwD+9eLjW+sTEEAK/XzDSDKVfsQY2ZbgQekRUlMHNwmq awCC1cjPbxDLXhhomCIKFCtT3ez2Jzhq+/7CO6QBVNqDMNT2NEM8g9QDsjtg7hdLmuKI xE9GduGI2xo+RRS7RsotmKAQeYeTmCf44S3J7JGYZ5OGKeI8DBQXdpcoHEe/yBzCuNNA HLnQ== X-Gm-Message-State: ALoCoQmd1MqDPnT8A7Mg8MEZFvp4sIfsNkfrRHL7iX24kDsnaZoqAz/PvKJysDE/ZaKAknvAmDQS MIME-Version: 1.0 X-Received: by 10.152.42.141 with SMTP id o13mr4018701lal.33.1428103731769; Fri, 03 Apr 2015 16:28:51 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Apr 2015 16:28:51 -0700 (PDT) In-Reply-To: <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> References: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <551E4EAA.8090703@ericsson.com> <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> Date: Fri, 3 Apr 2015 16:28:51 -0700 Message-ID: <CABCOCHTXknYKHVbj4XCRJ2eu5MZoUF848SF3-K1BFhxjYVFDjw@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Rob Shakir <rjs@rob.sh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/OiFFPRJyJvHu1fQJLPJcBlGnySI> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 23:28:56 -0000 On Fri, Apr 3, 2015 at 3:53 PM, Rob Shakir <rjs@rob.sh> wrote: > Andy, > > Your arguments here are too abstract for me =E2=80=94 sorry. I struggle t= o > understand really what you are proposing as an alternative approach. > > Let=E2=80=99s talk about a specific example (which I appreciate that you = might think > is overly simplistic =E2=80=94 but my requirement here is to have usable = models that > we can interact with, not just YANG models for the sake of YANG models) = =E2=80=94 > configuring a BGP peer in a network where there are multiple configuratio= n > writers. If I want to perform the operation of: > > * Configure a new peer on a network element. > * Determine whether the configuration that is active in the system is the > one that I wrote (rather than another system=E2=80=99s intention). > * Retrieve operational counters that correspond to the peer. > > Primarily, I push some configuration to > neighbor[peer-address=3D172.0.2.1]/config/{peer-as,description} =E2=80= =94 I can > immediately get the actual active configuration by pulling the correspond= ing > =E2=80=98state=E2=80=99 container. Since I have duplicates that tell me t= he =E2=80=98active=E2=80=99 > configuration as well as what was pushed, then I know whether my config t= hat > I tried to apply was the one that was accepted, rather than another > writer=E2=80=99s. > > Indeed, I can write a generic method that does this verification given a > certain path (always check that the =E2=80=98state=E2=80=99 container nex= t to the =E2=80=98config=E2=80=99 > one matches) - so I don=E2=80=99t need to have any kind of mapping that s= ays > /device/routing-protocols/bgp/state/neighbor=E2=80=A6 is the correspondin= g place for > state for a neighbour configured at > /device/routing-protocols/bgp/config/neighbor=E2=80=A6. for each leaf [No= te: the > problem with splits =E2=80=9Chigher in the tree=E2=80=9D like this is tha= t it is not clear > where the state container starts =E2=80=94 is it at routing-protocols/sta= te or > bgp/state?] > > I then want to check that the peer came up - and get any counters related= to > it - I can do this by just pulling the =E2=80=98operational: true=E2=80= =99 parameters from > the state container - which lets me make a targeted query for the thing t= hat > I am actually interested in - and only receive the data that the actual > network element has derived - rather than duplicating things on the wire. > > This is quite a typical workflow where we need to be able to easily relat= e > intended state (config), active state (running configuration parameters), > and derived state to one another to verify a change on the network. > > The proposal that is in draft-openconfig-netmod-opstate-00, seems to me t= o > be relatively simple solution that fits requirements quite neatly =E2=80= =94 and as > of yet, I don=E2=80=99t think we have found a case where it does not work= . Multiple > folks are starting to write code to interact with these models - so this > will be a good test of whether it works as we expect. > > I don=E2=80=99t see the need for a mapping dictionary between config and = state nodes > - and find the idea that the mapping is included in human-readable prose > somewhat bizarre, when we are talking about programmatic interaction. > > Can you outline a case where you don=E2=80=99t think that the approach wo= rks please? > I=E2=80=99d really love to see some alternative proposals - since we had = a lot of > discussion on this topic over the last few months with a bunch of differe= nt > folks - and if we=E2=80=99ve missed some better way of doing this, or som= e flaw in > our approach, then I=E2=80=99d be keen to iterate it! > I do not see any interesting solutions in your draft. I am strongly opposed to allowing config=3Dtrue child nodes of config=3Dfalse data nodes. This is too complicated to implement. Each data model designer can decide how to split up config and state in a way that makes the most sense for that data model. There is no rigid formula that will work all the time. The argument that the operator or designer must understand each data model they use to fully utilize it is not very compelling. Yes -- that's right. Generic tools will only do so much, and to really use a YANG module, even the description-stmts must be read. If you have specific changes to the routing modules to organize them better then that's fine, but I do not see any general solution in the draft that should be followed. > r. Andy > > On 3 April 2015 at 02:14:58, Andy Bierman (andy@yumaworks.com) wrote: > > On Fri, Apr 3, 2015 at 1:26 AM, Balazs Lengyel > <balazs.lengyel@ericsson.com> wrote: >> Hello, >> I think the problem is real, needs solving, so just some ideas: >> - put state, statistics and config in the same container/list, but enhan= ce >> Netconf/restconf to be able to <get> just config, just state, just >> counters >> or some combinations of all this. As I remember the main reason to put >> state >> and config in separate branches was the need to be able to read them >> separately. At that time I tought it a mistake that we use module >> structure >> instead of extending netconf. As Andy stated: "structure is a lousy tool= ". >> Still in RFC6087bis we have: >> "The separation of configuration data and operational state SHOULD be >> considered carefully. It is often useful to define separate top- >> level containers for configuration and non-configuration data." >> This uses the structure as a tool. :-) >> > > > RESTCONF already has the 'content' query parameter that allows > config, operational, or both. This is good enough. > It is trivial for you to add your own content filters to > the RPC operations (if you want to prove that standards > for more classifications are needed) > > > Andy > >> or >> - a new YANG statement that links together two lists indicating that one >> is >> the config part while the other is the state > > Prove this works as an extension first. > IMO it is easy to come up with simplistic solutions for > trivial test-cases. Create a general solution first, > prove that it helps, then ask the IETF to standardize it. > > >> regards Balazs > > Andy > >> >> P.S. IETF was always asking for operator input. Now we got it, will we d= o >> something about it? >> >> On 2015-04-02 20:02, Randy Presuhn wrote: >>> >>> Hi - >>> >>> I think what they're really asking for is an automated way >>> to identify the bits and pieces that correspond to a particular >>> aspect of a managed thingie. This has already happened with >>> "config true". Module structure is a really lousy mechanism >>> for identifying aspects; a given bit of information may >>> participate in more than one aspect. So I'm agreeing with >>> Andy that structure is a lousy tool for the job. >>> >>> However, the job is an important one. Structure is not the >>> solution. Look for another tool. >>> >>> Randy >>> >>> -----Original Message----- >>>> >>>> From: Andy Bierman <andy@yumaworks.com> >>>> Sent: Apr 2, 2015 10:49 AM >>>> To: Anees Shaikh <aashaikh@google.com> >>>> Cc: "netmod@ietf.org" <netmod@ietf.org> >>>> Subject: Re: [netmod] New 6087bis issues - connect config - state - >>>> statistics >>>> >>>> On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh@google.com> >>>> wrote: >>>>> >>>>> We've laid out why this is a problem (even for existing RFC models) i= n >>>>> draft-openconfig-netmod-opstate-00 and summarized during the >>>>> presentation in >>>>> Dallas. The problem is exacerbated when trying to compose multiple >>>>> models >>>>> into a coherent whole -- clearly it's not possible to manage a servic= e >>>>> or >>>>> device with an interfaces model alone. >>>>> >>>>> Reading the description statements to learn where different types of >>>>> data is >>>>> stored is not a solution IMO -- we need to think how this will be use >>>>> programmatically by users. And we made the deliberate tradeoff to >>>>> introduce >>>>> some extra work in building a consistent model for the benefit of a >>>>> simple >>>>> programming construct to set and retrieve the data. >>>>> >>>> I disagree. >>>> Many times the relationship between a config knob setting >>>> and operational state is not simple. There may be all kinds of >>>> overlap and dynamic conditions that change the set of >>>> interesting objects at the moment. Forcing a certain structure >>>> between config and operational nodes will not work as a general >>>> solution. >>>> You should develop some YANG extensions if you think the >>>> problem can be solved without description-stmts. >>>> >>>> >>>> >>>> >>>>> thanks. >>>>> -- Anees >>>> >>>> Andy >>>> >>>>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> You need to read the description-stmts of the relevant data nodes >>>>>> to find out where other related data nodes can be found. >>>>>> IMO the sibling config/state approach should only >>>>>> be used if the state can exist without the config. >>>>>> >>>>>> If I have an ACL or some filter that may be nested within lists >>>>>> with lots of keys, then it is extremely wasteful to replicate >>>>>> all the scaffolding and keys, just to store a couple counters >>>>>> for that ACL. It is much better to just put the counters in the ACL >>>>>> entry. >>>>>> >>>>>> But many times the set of interesting objects related to some >>>>>> config is far more complicated than that, so the description-stmt >>>>>> is the only place to document this information. >>>>>> >>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel >>>>>> <balazs.lengyel@ericsson.com> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> As indicated by operators in Dallas and as experienced by Ericsson = as >>>>>>> well, >>>>>>> it is sometimes not easy to find the status data for a given bit of >>>>>>> configuration (interface, route, etc.). Often the state and >>>>>>> configuration >>>>>>> are handled in parallel subtrees with the same structure. However >>>>>>> this >>>>>>> is >>>>>>> not part of the guidelines. Also counters are often separated from >>>>>>> state >>>>>>> data again without a clear guideline to connect statistics with the >>>>>>> config. >>>>>>> I believe 6087 should provide guidelines how to find state and >>>>>>> staistics >>>>>>> information for a give piece of configuration. E.g. how do find the >>>>>>> number >>>>>>> of outgoing packets for an interface? >>>>>>> regards Balazs >>>>>>> >>>>>>> On 2015-04-02 14:47, Martin Bjorklund wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here's a list of some things that maybe should be added to 6087bis= . >>>>>>>> Some of them are stylistic; I don't know if we should add those or >>>>>>>> not. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3.6 References >>>>>>>> >>>>>>>> The RFC Editor prefers the style: >>>>>>>> >>>>>>>> reference >>>>>>>> "RFC <NNNN>: <title>"; >>>>>>>> >>>>>>>> reference >>>>>>>> "RFC <NNNN>: <very long title that spans >>>>>>>> more than one line>"; >>>>>>>> >>>>>>>> >>>>>>>> I think we should document this. >>>>>>>> >>>>>>>> >>>>>>>> 4.1 >>>>>>>> >>>>>>>> Update this wrt. example modules. Should they be marked with CODE >>>>>>>> at >>>>>>>> all? >>>>>>>> >>>>>>>> >>>>>>>> 5.1. Module Naming Conventions >>>>>>>> >>>>>>>> >>>>>>>> Add: IETF modules SHOULD (MUST?) start with "ietf-". >>>>>>>> >>>>>>>> Example modules SHOULD start with "example-" or "ex-". >>>>>>>> >>>>>>>> >>>>>>>> 5.2. Identifiers >>>>>>>> >>>>>>>> Add: avoid unnecessary prefixes on names. >>>>>>>> >>>>>>>> BAD: >>>>>>>> >>>>>>>> list interface { >>>>>>>> ... >>>>>>>> leaf interface-name { ... } >>>>>>>> leaf interface-type { ... } >>>>>>>> } >>>>>>>> >>>>>>>> GOOD: >>>>>>>> >>>>>>>> list interface { >>>>>>>> ... >>>>>>>> leaf name { ... } >>>>>>>> leaf type { ... } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> use-hypened-names >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 5.8 Namespace Assignments >>>>>>>> >>>>>>>> OLD: >>>>>>>> >>>>>>>> The following examples of non-Standards-Track modules are only >>>>>>>> suggestions. There are no guidelines for this type of URN in >>>>>>>> this >>>>>>>> document: >>>>>>>> >>>>>>>> http://example.com/ns/example-interfaces >>>>>>>> >>>>>>>> http://example.com/ns/example-system >>>>>>>> >>>>>>>> NEW: >>>>>>>> >>>>>>>> There are no guidelines for non-Standards-Track modules. >>>>>>>> >>>>>>>> Example modules SHOULD use RFC 6963 style URNs: >>>>>>>> >>>>>>>> urn:example:<module-name> >>>>>>>> >>>>>>>> Or 2606-style >>>>>>>> >>>>>>>> http://example.com/... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /martin >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Balazs Lengyel Ericsson Hungary Ltd. >>>>>>> Senior Specialist >>>>>>> ECN: 831 7320 >>>>>>> Mobile: +36-70-330-7909 email: >>>>>>> Balazs.Lengyel@ericsson.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 >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.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 Fri Apr 3 18:17:11 2015 Return-Path: <aashaikh@google.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD49A1A1A14 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 18:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: 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-LlM158JDAJ for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 18:17:06 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86ED1A1A06 for <netmod@ietf.org>; Fri, 3 Apr 2015 18:17:05 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so181759513obb.1 for <netmod@ietf.org>; Fri, 03 Apr 2015 18:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TKKjApXCg6GZKCdpsR1wANxZxkuv9OycWnB7WLUWjeU=; b=EzuGMOFgsOl5G0bWNWZ5sFPFDLYHhbbHTAMU7iLdLR8hrNoW3ZvHqP7XphJpop5NAu hzH+k43+2SHqROSC8cECPN1+bMpO3c77klLpemsUTCQWnyKje02OKs1+Zqj5MwPtAtLn AwF0XlAUp2JugB5Fof+1XVpA3tVFuJiBM5fAzDD9oyytFQrW/Z9DnpUW4ABUFkwHMbof BqenwVwltUDbqxhmOPCMXo9MpcMVSjcw0dURglXxtjfXS8i2iRBUjlj094j34QFC0eOC 86pVDORjpxoFlWAvd3iYTCERZYS02DQVf+hMdeUkdUD3QtOBm/wqFhd50Ie+7mx6bGQy Dlag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TKKjApXCg6GZKCdpsR1wANxZxkuv9OycWnB7WLUWjeU=; b=CwUTf2Nh7+QIt0b/iH8egN7PaGpVE8NNSUI4R7YaWsIh4M9/aUQtq/ApN75/46ikfd oYtd9jLCwgniWIQcQVLnpIHydlZcFat+afggkS363h6AHtuITssFkVO9KDU7fdhRPewt JE0fDYyabPMoitcnnSI2b30yz6wUYHuJ3QRsGn/8BUa+8p3AXUEn8YXWfGascP7fOWMF shuB+o2+hvqrhtXyJG9n6krG8OyL0hLENm4RerBFYnjVPHic1vEFJ5HvpkwyvIsWXgwD 52EHfYpJNMU5nUeqAyd9Bekxd92upLaLI2qPi1v8GqSkE4dKCA4cmR8b9Ca8NFR5kt4N UcSg== X-Gm-Message-State: ALoCoQnEQzeMSdcPlEjt7EgC8HC2b14wlNk4hvkllRdVfbMTENbOCOwGL8xd2CX2puoceXFboDHs MIME-Version: 1.0 X-Received: by 10.60.63.99 with SMTP id f3mr5961449oes.9.1428110225255; Fri, 03 Apr 2015 18:17:05 -0700 (PDT) Received: by 10.182.73.137 with HTTP; Fri, 3 Apr 2015 18:17:05 -0700 (PDT) In-Reply-To: <CABCOCHTXknYKHVbj4XCRJ2eu5MZoUF848SF3-K1BFhxjYVFDjw@mail.gmail.com> References: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <551E4EAA.8090703@ericsson.com> <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> <CABCOCHTXknYKHVbj4XCRJ2eu5MZoUF848SF3-K1BFhxjYVFDjw@mail.gmail.com> Date: Fri, 3 Apr 2015 18:17:05 -0700 Message-ID: <CAJK7Zq+g6s1-BeajrK8SUM2Yx=4cZHMXN-wtnxvJ+XdTYUOr-Q@mail.gmail.com> From: Anees Shaikh <aashaikh@google.com> To: Andy Bierman <andy@yumaworks.com> Content-Type: multipart/alternative; boundary=001a11c2578aad5f820512dbd20f Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/lPGeAmK9UvwQUaUOgKQq_NL5Iw8> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 01:17:10 -0000 --001a11c2578aad5f820512dbd20f Content-Type: text/plain; charset=UTF-8 <snip> > I do not see any interesting solutions in your draft. > I am strongly opposed to allowing config=true child nodes > of config=false data nodes. This is too complicated to implement. > Since we don't actually do this in our solution (though we mentioned it in the draft as a way to further simplify the structure), I'm wondering if you've looked at the draft at all to understand the problem. Rob also just laid out a detailed example of the problem. > > Each data model designer can decide how to split up > config and state in a way that makes the most sense for > that data model. There is no rigid formula that will work all the time. > Please be specific about situations in which this proposal does not work -- we are honestly interested to understand the limitations. If I understand you correctly, your proposal is to let modelers create arbitrary constructions of configuration and operational state and let the users of the models just figure it out. > > The argument that the operator or designer must understand each data model > they use to fully utilize it is not very compelling. Yes -- that's right. > Generic tools will only do so much, and to really use a YANG module, > even the description-stmts must be read. > That's not the argument at all -- obviously the API of any system (in this case, the model) has to be understood to be used, including reading the documentation of each API call (description-stmts). Rather, the argument here is that making the API much easier to use and useful in more situations, is worthwhile even if it makes the initial implementation of the backend slightly more difficult. thanks. -- Anees > > r. > > Andy > > > > > > On 3 April 2015 at 02:14:58, Andy Bierman (andy@yumaworks.com) wrote: > > > > On Fri, Apr 3, 2015 at 1:26 AM, Balazs Lengyel > > <balazs.lengyel@ericsson.com> wrote: > >> Hello, > >> I think the problem is real, needs solving, so just some ideas: > >> - put state, statistics and config in the same container/list, but > enhance > >> Netconf/restconf to be able to <get> just config, just state, just > >> counters > >> or some combinations of all this. As I remember the main reason to put > >> state > >> and config in separate branches was the need to be able to read them > >> separately. At that time I tought it a mistake that we use module > >> structure > >> instead of extending netconf. As Andy stated: "structure is a lousy > tool". > >> Still in RFC6087bis we have: > >> "The separation of configuration data and operational state SHOULD be > >> considered carefully. It is often useful to define separate top- > >> level containers for configuration and non-configuration data." > >> This uses the structure as a tool. :-) > >> > > > > > > RESTCONF already has the 'content' query parameter that allows > > config, operational, or both. This is good enough. > > It is trivial for you to add your own content filters to > > the RPC operations (if you want to prove that standards > > for more classifications are needed) > > > > > > Andy > > > >> or > >> - a new YANG statement that links together two lists indicating that one > >> is > >> the config part while the other is the state > > > > Prove this works as an extension first. > > IMO it is easy to come up with simplistic solutions for > > trivial test-cases. Create a general solution first, > > prove that it helps, then ask the IETF to standardize it. > > > > > >> regards Balazs > > > > Andy > > > >> > >> P.S. IETF was always asking for operator input. Now we got it, will we > do > >> something about it? > >> > >> On 2015-04-02 20:02, Randy Presuhn wrote: > >>> > >>> Hi - > >>> > >>> I think what they're really asking for is an automated way > >>> to identify the bits and pieces that correspond to a particular > >>> aspect of a managed thingie. This has already happened with > >>> "config true". Module structure is a really lousy mechanism > >>> for identifying aspects; a given bit of information may > >>> participate in more than one aspect. So I'm agreeing with > >>> Andy that structure is a lousy tool for the job. > >>> > >>> However, the job is an important one. Structure is not the > >>> solution. Look for another tool. > >>> > >>> Randy > >>> > >>> -----Original Message----- > >>>> > >>>> From: Andy Bierman <andy@yumaworks.com> > >>>> Sent: Apr 2, 2015 10:49 AM > >>>> To: Anees Shaikh <aashaikh@google.com> > >>>> Cc: "netmod@ietf.org" <netmod@ietf.org> > >>>> Subject: Re: [netmod] New 6087bis issues - connect config - state - > >>>> statistics > >>>> > >>>> On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh@google.com> > >>>> wrote: > >>>>> > >>>>> We've laid out why this is a problem (even for existing RFC models) > in > >>>>> draft-openconfig-netmod-opstate-00 and summarized during the > >>>>> presentation in > >>>>> Dallas. The problem is exacerbated when trying to compose multiple > >>>>> models > >>>>> into a coherent whole -- clearly it's not possible to manage a > service > >>>>> or > >>>>> device with an interfaces model alone. > >>>>> > >>>>> Reading the description statements to learn where different types of > >>>>> data is > >>>>> stored is not a solution IMO -- we need to think how this will be use > >>>>> programmatically by users. And we made the deliberate tradeoff to > >>>>> introduce > >>>>> some extra work in building a consistent model for the benefit of a > >>>>> simple > >>>>> programming construct to set and retrieve the data. > >>>>> > >>>> I disagree. > >>>> Many times the relationship between a config knob setting > >>>> and operational state is not simple. There may be all kinds of > >>>> overlap and dynamic conditions that change the set of > >>>> interesting objects at the moment. Forcing a certain structure > >>>> between config and operational nodes will not work as a general > >>>> solution. > >>>> You should develop some YANG extensions if you think the > >>>> problem can be solved without description-stmts. > >>>> > >>>> > >>>> > >>>> > >>>>> thanks. > >>>>> -- Anees > >>>> > >>>> Andy > >>>> > >>>>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> > >>>>> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> You need to read the description-stmts of the relevant data nodes > >>>>>> to find out where other related data nodes can be found. > >>>>>> IMO the sibling config/state approach should only > >>>>>> be used if the state can exist without the config. > >>>>>> > >>>>>> If I have an ACL or some filter that may be nested within lists > >>>>>> with lots of keys, then it is extremely wasteful to replicate > >>>>>> all the scaffolding and keys, just to store a couple counters > >>>>>> for that ACL. It is much better to just put the counters in the ACL > >>>>>> entry. > >>>>>> > >>>>>> But many times the set of interesting objects related to some > >>>>>> config is far more complicated than that, so the description-stmt > >>>>>> is the only place to document this information. > >>>>>> > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> > >>>>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel > >>>>>> <balazs.lengyel@ericsson.com> wrote: > >>>>>>> > >>>>>>> Hello, > >>>>>>> As indicated by operators in Dallas and as experienced by Ericsson > as > >>>>>>> well, > >>>>>>> it is sometimes not easy to find the status data for a given bit of > >>>>>>> configuration (interface, route, etc.). Often the state and > >>>>>>> configuration > >>>>>>> are handled in parallel subtrees with the same structure. However > >>>>>>> this > >>>>>>> is > >>>>>>> not part of the guidelines. Also counters are often separated from > >>>>>>> state > >>>>>>> data again without a clear guideline to connect statistics with the > >>>>>>> config. > >>>>>>> I believe 6087 should provide guidelines how to find state and > >>>>>>> staistics > >>>>>>> information for a give piece of configuration. E.g. how do find the > >>>>>>> number > >>>>>>> of outgoing packets for an interface? > >>>>>>> regards Balazs > >>>>>>> > >>>>>>> On 2015-04-02 14:47, Martin Bjorklund wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Here's a list of some things that maybe should be added to > 6087bis. > >>>>>>>> Some of them are stylistic; I don't know if we should add those or > >>>>>>>> not. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 3.6 References > >>>>>>>> > >>>>>>>> The RFC Editor prefers the style: > >>>>>>>> > >>>>>>>> reference > >>>>>>>> "RFC <NNNN>: <title>"; > >>>>>>>> > >>>>>>>> reference > >>>>>>>> "RFC <NNNN>: <very long title that spans > >>>>>>>> more than one line>"; > >>>>>>>> > >>>>>>>> > >>>>>>>> I think we should document this. > >>>>>>>> > >>>>>>>> > >>>>>>>> 4.1 > >>>>>>>> > >>>>>>>> Update this wrt. example modules. Should they be marked with CODE > >>>>>>>> at > >>>>>>>> all? > >>>>>>>> > >>>>>>>> > >>>>>>>> 5.1. Module Naming Conventions > >>>>>>>> > >>>>>>>> > >>>>>>>> Add: IETF modules SHOULD (MUST?) start with "ietf-". > >>>>>>>> > >>>>>>>> Example modules SHOULD start with "example-" or "ex-". > >>>>>>>> > >>>>>>>> > >>>>>>>> 5.2. Identifiers > >>>>>>>> > >>>>>>>> Add: avoid unnecessary prefixes on names. > >>>>>>>> > >>>>>>>> BAD: > >>>>>>>> > >>>>>>>> list interface { > >>>>>>>> ... > >>>>>>>> leaf interface-name { ... } > >>>>>>>> leaf interface-type { ... } > >>>>>>>> } > >>>>>>>> > >>>>>>>> GOOD: > >>>>>>>> > >>>>>>>> list interface { > >>>>>>>> ... > >>>>>>>> leaf name { ... } > >>>>>>>> leaf type { ... } > >>>>>>>> } > >>>>>>>> > >>>>>>>> > >>>>>>>> use-hypened-names > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 5.8 Namespace Assignments > >>>>>>>> > >>>>>>>> OLD: > >>>>>>>> > >>>>>>>> The following examples of non-Standards-Track modules are only > >>>>>>>> suggestions. There are no guidelines for this type of URN in > >>>>>>>> this > >>>>>>>> document: > >>>>>>>> > >>>>>>>> http://example.com/ns/example-interfaces > >>>>>>>> > >>>>>>>> http://example.com/ns/example-system > >>>>>>>> > >>>>>>>> NEW: > >>>>>>>> > >>>>>>>> There are no guidelines for non-Standards-Track modules. > >>>>>>>> > >>>>>>>> Example modules SHOULD use RFC 6963 style URNs: > >>>>>>>> > >>>>>>>> urn:example:<module-name> > >>>>>>>> > >>>>>>>> Or 2606-style > >>>>>>>> > >>>>>>>> http://example.com/... > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> /martin > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> netmod mailing list > >>>>>>>> netmod@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>>>>> > >>>>>>>> > >>>>>>> -- > >>>>>>> Balazs Lengyel Ericsson Hungary Ltd. > >>>>>>> Senior Specialist > >>>>>>> ECN: 831 7320 > >>>>>>> Mobile: +36-70-330-7909 email: > >>>>>>> Balazs.Lengyel@ericsson.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 > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> > >> -- > >> Balazs Lengyel Ericsson Hungary Ltd. > >> Senior Specialist > >> ECN: 831 7320 > >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.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 > --001a11c2578aad5f820512dbd20f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><snip><div><div class=3D"gmail_extra"><div class=3D"= gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"= HOEnZb"><div class=3D"h5"> </div></div>I do not see any interesting solutions in your draft.<br> I am strongly opposed to allowing config=3Dtrue child nodes<br> of config=3Dfalse data nodes.=C2=A0 This is too complicated to implement.<b= r></blockquote><div><br></div><div>Since we don't actually do this in o= ur solution (though we mentioned it in the draft as a way to further simpli= fy the structure), I'm wondering if you've looked at the draft at a= ll to understand the problem. =C2=A0 Rob also just laid out a detailed exam= ple of the problem.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Each data model designer can decide how to split up<br> config and state in a way that makes the most sense for<br> that data model. There is no rigid formula that will work all the time.<br>= </blockquote><div><br></div><div>Please be specific about situations in whi= ch this proposal does not work -- we are honestly interested to understand = the limitations.=C2=A0 If I understand you correctly, your proposal is to l= et modelers create arbitrary constructions of configuration and operational= state and let the users of the models just figure it out.</div><div>=C2=A0= </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> <br> The argument that the operator or designer must understand each data model<= br> they use to fully utilize it is not very compelling.=C2=A0 Yes -- that'= s right.<br> Generic tools will only do so much, and to really use a YANG module,<br> even the description-stmts must be read.<br></blockquote><div><br></div><di= v>That's not the argument at all -- obviously the API of any system (in= this case, the model) has to be understood to be used, including reading t= he documentation of each API call (description-stmts).=C2=A0 Rather, the ar= gument here is that making the API much easier to use and useful in more si= tuations, is worthwhile even if it makes the initial implementation of the = backend slightly more difficult.</div><div><br></div><div>thanks.</div><div= >-- Anees</div><div><br></div><div><br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= > <br> > r.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Andy<br> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> ><br> > On 3 April 2015 at 02:14:58, Andy Bierman (<a href=3D"mailto:andy@yuma= works.com">andy@yumaworks.com</a>) wrote:<br> ><br> > On Fri, Apr 3, 2015 at 1:26 AM, Balazs Lengyel<br> > <<a href=3D"mailto:balazs.lengyel@ericsson.com">balazs.lengyel@eric= sson.com</a>> wrote:<br> >> Hello,<br> >> I think the problem is real, needs solving, so just some ideas:<br= > >> - put state, statistics and config in the same container/list, but= enhance<br> >> Netconf/restconf to be able to <get> just config, just state= , just<br> >> counters<br> >> or some combinations of all this. As I remember the main reason to= put<br> >> state<br> >> and config in separate branches was the need to be able to read th= em<br> >> separately. At that time I tought it a mistake that we use module<= br> >> structure<br> >> instead of extending netconf. As Andy stated: "structure is a= lousy tool".<br> >> Still in RFC6087bis we have:<br> >> "The separation of configuration data and operational state S= HOULD be<br> >> considered carefully. It is often useful to define separate top-<b= r> >> level containers for configuration and non-configuration data.&quo= t;<br> >> This uses the structure as a tool. :-)<br> >><br> ><br> ><br> > RESTCONF already has the 'content' query parameter that allows= <br> > config, operational, or both. This is good enough.<br> > It is trivial for you to add your own content filters to<br> > the RPC operations (if you want to prove that standards<br> > for more classifications are needed)<br> ><br> ><br> > Andy<br> ><br> >> or<br> >> - a new YANG statement that links together two lists indicating th= at one<br> >> is<br> >> the config part while the other is the state<br> ><br> > Prove this works as an extension first.<br> > IMO it is easy to come up with simplistic solutions for<br> > trivial test-cases. Create a general solution first,<br> > prove that it helps, then ask the IETF to standardize it.<br> ><br> ><br> >> regards Balazs<br> ><br> > Andy<br> ><br> >><br> >> P.S. IETF was always asking for operator input. Now we got it, wil= l we do<br> >> something about it?<br> >><br> >> On 2015-04-02 20:02, Randy Presuhn wrote:<br> >>><br> >>> Hi -<br> >>><br> >>> I think what they're really asking for is an automated way= <br> >>> to identify the bits and pieces that correspond to a particula= r<br> >>> aspect of a managed thingie. This has already happened with<br= > >>> "config true". Module structure is a really lousy me= chanism<br> >>> for identifying aspects; a given bit of information may<br> >>> participate in more than one aspect. So I'm agreeing with<= br> >>> Andy that structure is a lousy tool for the job.<br> >>><br> >>> However, the job is an important one. Structure is not the<br> >>> solution. Look for another tool.<br> >>><br> >>> Randy<br> >>><br> >>> -----Original Message-----<br> >>>><br> >>>> From: Andy Bierman <<a href=3D"mailto:andy@yumaworks.co= m">andy@yumaworks.com</a>><br> >>>> Sent: Apr 2, 2015 10:49 AM<br> >>>> To: Anees Shaikh <<a href=3D"mailto:aashaikh@google.com= ">aashaikh@google.com</a>><br> >>>> Cc: "<a href=3D"mailto:netmod@ietf.org">netmod@ietf.o= rg</a>" <<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a>>= <br> >>>> Subject: Re: [netmod] New 6087bis issues - connect config = - state -<br> >>>> statistics<br> >>>><br> >>>> On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <<a href= =3D"mailto:aashaikh@google.com">aashaikh@google.com</a>><br> >>>> wrote:<br> >>>>><br> >>>>> We've laid out why this is a problem (even for exi= sting RFC models) in<br> >>>>> draft-openconfig-netmod-opstate-00 and summarized duri= ng the<br> >>>>> presentation in<br> >>>>> Dallas. The problem is exacerbated when trying to comp= ose multiple<br> >>>>> models<br> >>>>> into a coherent whole -- clearly it's not possible= to manage a service<br> >>>>> or<br> >>>>> device with an interfaces model alone.<br> >>>>><br> >>>>> Reading the description statements to learn where diff= erent types of<br> >>>>> data is<br> >>>>> stored is not a solution IMO -- we need to think how t= his will be use<br> >>>>> programmatically by users. And we made the deliberate = tradeoff to<br> >>>>> introduce<br> >>>>> some extra work in building a consistent model for the= benefit of a<br> >>>>> simple<br> >>>>> programming construct to set and retrieve the data.<br= > >>>>><br> >>>> I disagree.<br> >>>> Many times the relationship between a config knob setting<= br> >>>> and operational state is not simple. There may be all kind= s of<br> >>>> overlap and dynamic conditions that change the set of<br> >>>> interesting objects at the moment. Forcing a certain struc= ture<br> >>>> between config and operational nodes will not work as a ge= neral<br> >>>> solution.<br> >>>> You should develop some YANG extensions if you think the<b= r> >>>> problem can be solved without description-stmts.<br> >>>><br> >>>><br> >>>><br> >>>><br> >>>>> thanks.<br> >>>>> -- Anees<br> >>>><br> >>>> Andy<br> >>>><br> >>>>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <<a hr= ef=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>><br> >>>>> wrote:<br> >>>>>><br> >>>>>> Hi,<br> >>>>>><br> >>>>>> You need to read the description-stmts of the rele= vant data nodes<br> >>>>>> to find out where other related data nodes can be = found.<br> >>>>>> IMO the sibling config/state approach should only<= br> >>>>>> be used if the state can exist without the config.= <br> >>>>>><br> >>>>>> If I have an ACL or some filter that may be nested= within lists<br> >>>>>> with lots of keys, then it is extremely wasteful t= o replicate<br> >>>>>> all the scaffolding and keys, just to store a coup= le counters<br> >>>>>> for that ACL. It is much better to just put the co= unters in the ACL<br> >>>>>> entry.<br> >>>>>><br> >>>>>> But many times the set of interesting objects rela= ted to some<br> >>>>>> config is far more complicated than that, so the d= escription-stmt<br> >>>>>> is the only place to document this information.<br= > >>>>>><br> >>>>>><br> >>>>>> Andy<br> >>>>>><br> >>>>>><br> >>>>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel<br> >>>>>> <<a href=3D"mailto:balazs.lengyel@ericsson.com"= >balazs.lengyel@ericsson.com</a>> wrote:<br> >>>>>>><br> >>>>>>> Hello,<br> >>>>>>> As indicated by operators in Dallas and as exp= erienced by Ericsson as<br> >>>>>>> well,<br> >>>>>>> it is sometimes not easy to find the status da= ta for a given bit of<br> >>>>>>> configuration (interface, route, etc.). Often = the state and<br> >>>>>>> configuration<br> >>>>>>> are handled in parallel subtrees with the same= structure. However<br> >>>>>>> this<br> >>>>>>> is<br> >>>>>>> not part of the guidelines. Also counters are = often separated from<br> >>>>>>> state<br> >>>>>>> data again without a clear guideline to connec= t statistics with the<br> >>>>>>> config.<br> >>>>>>> I believe 6087 should provide guidelines how t= o find state and<br> >>>>>>> staistics<br> >>>>>>> information for a give piece of configuration.= E.g. how do find the<br> >>>>>>> number<br> >>>>>>> of outgoing packets for an interface?<br> >>>>>>> regards Balazs<br> >>>>>>><br> >>>>>>> On 2015-04-02 14:47, Martin Bjorklund wrote:<b= r> >>>>>>>><br> >>>>>>>> Hi,<br> >>>>>>>><br> >>>>>>>> Here's a list of some things that mayb= e should be added to 6087bis.<br> >>>>>>>> Some of them are stylistic; I don't kn= ow if we should add those or<br> >>>>>>>> not.<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> 3.6 References<br> >>>>>>>><br> >>>>>>>> The RFC Editor prefers the style:<br> >>>>>>>><br> >>>>>>>> reference<br> >>>>>>>> "RFC <NNNN>: <title>"= ;;<br> >>>>>>>><br> >>>>>>>> reference<br> >>>>>>>> "RFC <NNNN>: <very long titl= e that spans<br> >>>>>>>> more than one line>";<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> I think we should document this.<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> 4.1<br> >>>>>>>><br> >>>>>>>> Update this wrt. example modules. Should t= hey be marked with CODE<br> >>>>>>>> at<br> >>>>>>>> all?<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> 5.1. Module Naming Conventions<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> Add: IETF modules SHOULD (MUST?) start wit= h "ietf-".<br> >>>>>>>><br> >>>>>>>> Example modules SHOULD start with "ex= ample-" or "ex-".<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> 5.2. Identifiers<br> >>>>>>>><br> >>>>>>>> Add: avoid unnecessary prefixes on names.<= br> >>>>>>>><br> >>>>>>>> BAD:<br> >>>>>>>><br> >>>>>>>> list interface {<br> >>>>>>>> ...<br> >>>>>>>> leaf interface-name { ... }<br> >>>>>>>> leaf interface-type { ... }<br> >>>>>>>> }<br> >>>>>>>><br> >>>>>>>> GOOD:<br> >>>>>>>><br> >>>>>>>> list interface {<br> >>>>>>>> ...<br> >>>>>>>> leaf name { ... }<br> >>>>>>>> leaf type { ... }<br> >>>>>>>> }<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> use-hypened-names<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> 5.8 Namespace Assignments<br> >>>>>>>><br> >>>>>>>> OLD:<br> >>>>>>>><br> >>>>>>>> The following examples of non-Standards-Tr= ack modules are only<br> >>>>>>>> suggestions. There are no guidelines for t= his type of URN in<br> >>>>>>>> this<br> >>>>>>>> document:<br> >>>>>>>><br> >>>>>>>> <a href=3D"http://example.com/ns/example-i= nterfaces" target=3D"_blank">http://example.com/ns/example-interfaces</a><b= r> >>>>>>>><br> >>>>>>>> <a href=3D"http://example.com/ns/example-s= ystem" target=3D"_blank">http://example.com/ns/example-system</a><br> >>>>>>>><br> >>>>>>>> NEW:<br> >>>>>>>><br> >>>>>>>> There are no guidelines for non-Standards-= Track modules.<br> >>>>>>>><br> >>>>>>>> Example modules SHOULD use RFC 6963 style = URNs:<br> >>>>>>>><br> >>>>>>>> urn:example:<module-name><br> >>>>>>>><br> >>>>>>>> Or 2606-style<br> >>>>>>>><br> >>>>>>>> <a href=3D"http://example.com/." target=3D= "_blank">http://example.com/.</a>..<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>><br> >>>>>>>> /martin<br> >>>>>>>><br> >>>>>>>> __________________________________________= _____<br> >>>>>>>> netmod mailing list<br> >>>>>>>> <a href=3D"mailto:netmod@ietf.org">netmod@= ietf.org</a><br> >>>>>>>> <a href=3D"https://www.ietf.org/mailman/li= stinfo/netmod" target=3D"_blank">https://www.ietf.org/mailman/listinfo/netm= od</a><br> >>>>>>>><br> >>>>>>>><br> >>>>>>> --<br> >>>>>>> Balazs Lengyel Ericsson Hungary Ltd.<br> >>>>>>> Senior Specialist<br> >>>>>>> ECN: 831 7320<br> >>>>>>> Mobile: <a href=3D"tel:%2B36-70-330-7909" valu= e=3D"+36703307909">+36-70-330-7909</a> email:<br> >>>>>>> <a href=3D"mailto:Balazs.Lengyel@ericsson.com"= >Balazs.Lengyel@ericsson.com</a><br> >>>>>>><br> >>>>>>> ______________________________________________= _<br> >>>>>>> netmod mailing list<br> >>>>>>> <a href=3D"mailto:netmod@ietf.org">netmod@ietf= .org</a><br> >>>>>>> <a href=3D"https://www.ietf.org/mailman/listin= fo/netmod" target=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</= a><br> >>>>>><br> >>>>>> _______________________________________________<br= > >>>>>> netmod mailing list<br> >>>>>> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org= </a><br> >>>>>> <a href=3D"https://www.ietf.org/mailman/listinfo/n= etmod" target=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><b= r> >>>>><br> >>>>><br> >>>> _______________________________________________<br> >>>> netmod mailing list<br> >>>> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> >>>> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br> >>><br> >>> _______________________________________________<br> >>> netmod mailing list<br> >>> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> >>> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" targe= t=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br> >>><br> >><br> >> --<br> >> Balazs Lengyel Ericsson Hungary Ltd.<br> >> Senior Specialist<br> >> ECN: 831 7320<br> >> Mobile: <a href=3D"tel:%2B36-70-330-7909" value=3D"+36703307909">+= 36-70-330-7909</a> email: <a href=3D"mailto:Balazs.Lengyel@ericsson.com">Ba= lazs.Lengyel@ericsson.com</a><br> >><br> >> _______________________________________________<br> >> netmod mailing list<br> >> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> >> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D= "_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br> ><br> > _______________________________________________<br> > netmod mailing list<br> > <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_bl= ank">https://www.ietf.org/mailman/listinfo/netmod</a><br> </div></div></blockquote></div><br></div></div></div> --001a11c2578aad5f820512dbd20f-- From nobody Fri Apr 3 18:39:21 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07361A3BA4 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 18:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6aV5DQTi96u for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 18:39:18 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3E31A6EE0 for <netmod@ietf.org>; Fri, 3 Apr 2015 18:39:14 -0700 (PDT) Received: by lagv1 with SMTP id v1so12379097lag.3 for <netmod@ietf.org>; Fri, 03 Apr 2015 18:39:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BuEA/GQG8MhDVrqtGYIFRc2zDbri9jK7VReQh5hR+bI=; b=Pji4l2BM7mWhZj0Hp0yC6guv4Nm25TrsyPqoMYGYykWZyax0qqPaYF2WGR+TtafF/g naBdRJWNoxEhGsq3njWCRAHbb7505LF5+P8e/YBjEWpW0eY4Y9HXi5E4SSrcMysUy5ke zKp+bNxykCUU3zBZMne63hqlvpNzb04lIMwh+1FBwAEEit/wOF45cVakf+g5peXZnPvR iRV79krpu2DhJ0gaRFaY3LbSLlzAs5sLBcs9swIYmCbUDg+80XBHebrWy92cxz5mDh0T xnzhAGH3DTGR9p2pb6RRG/3Zs0Suxa8ByPef9yf16A1qjQov0Rme91TiOAKVZ2E4J0HX kFOg== X-Gm-Message-State: ALoCoQlSbdjI+ZUGCU89SqUsxV12lkr/KGr2UakWhVnMhEOVEBYeaMUgliPnUUvSFcSbFaGFeJmQ MIME-Version: 1.0 X-Received: by 10.112.51.138 with SMTP id k10mr4271138lbo.82.1428111552920; Fri, 03 Apr 2015 18:39:12 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Apr 2015 18:39:12 -0700 (PDT) In-Reply-To: <CAJK7Zq+g6s1-BeajrK8SUM2Yx=4cZHMXN-wtnxvJ+XdTYUOr-Q@mail.gmail.com> References: <26796498.1427997776219.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <551E4EAA.8090703@ericsson.com> <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> <CABCOCHTXknYKHVbj4XCRJ2eu5MZoUF848SF3-K1BFhxjYVFDjw@mail.gmail.com> <CAJK7Zq+g6s1-BeajrK8SUM2Yx=4cZHMXN-wtnxvJ+XdTYUOr-Q@mail.gmail.com> Date: Fri, 3 Apr 2015 18:39:12 -0700 Message-ID: <CABCOCHQBZ_Tb=-BSn1n-jfc6HDqt-VBSi+0AnU6Odt3yRjxLQA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Anees Shaikh <aashaikh@google.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/xhg8bAN0pjf_Q9bm8ZozyfwM2As> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 01:39:20 -0000 On Fri, Apr 3, 2015 at 6:17 PM, Anees Shaikh <aashaikh@google.com> wrote: > <snip> > >> >> I do not see any interesting solutions in your draft. >> I am strongly opposed to allowing config=true child nodes >> of config=false data nodes. This is too complicated to implement. > > > Since we don't actually do this in our solution (though we mentioned it in > the draft as a way to further simplify the structure), I'm wondering if > you've looked at the draft at all to understand the problem. Rob also just > laid out a detailed example of the problem. > >> >> >> Each data model designer can decide how to split up >> config and state in a way that makes the most sense for >> that data model. There is no rigid formula that will work all the time. > > > Please be specific about situations in which this proposal does not work -- > we are honestly interested to understand the limitations. If I understand > you correctly, your proposal is to let modelers create arbitrary > constructions of configuration and operational state and let the users of > the models just figure it out. > It's hard to find specific solutions in your draft. You do mention config inside operational data as part of the solution. Your example shows the interfaces table re-done so the operational state inside the config. The the config is repeated inside the operational state. The interfaces-state container was designed that way so system-known interfaces could be populated in the operational state, even if these interfaces were not configured by the operator. Moving the state inside the config breaks this design because the server would have to populate the configured interfaces in order to create any child nodes. Sometimes operational state inside config is the right choice -- sometimes it isn't. Sometimes the operational value can be different than the configured value, but usually not, so replicating the config as operational state is not usually required. I don't think YANG modules should have any extra complexity or cruft just so they all look kind of the same. If the extra containers and duplicated config are needed for a given data model, then fine. That is something domain experts need to decide for each YANG module. Andy >> >> >> The argument that the operator or designer must understand each data model >> they use to fully utilize it is not very compelling. Yes -- that's right. >> Generic tools will only do so much, and to really use a YANG module, >> even the description-stmts must be read. > > > That's not the argument at all -- obviously the API of any system (in this > case, the model) has to be understood to be used, including reading the > documentation of each API call (description-stmts). Rather, the argument > here is that making the API much easier to use and useful in more > situations, is worthwhile even if it makes the initial implementation of the > backend slightly more difficult. > > thanks. > -- Anees > > >> >> > r. >> >> Andy >> >> >> > >> > On 3 April 2015 at 02:14:58, Andy Bierman (andy@yumaworks.com) wrote: >> > >> > On Fri, Apr 3, 2015 at 1:26 AM, Balazs Lengyel >> > <balazs.lengyel@ericsson.com> wrote: >> >> Hello, >> >> I think the problem is real, needs solving, so just some ideas: >> >> - put state, statistics and config in the same container/list, but >> >> enhance >> >> Netconf/restconf to be able to <get> just config, just state, just >> >> counters >> >> or some combinations of all this. As I remember the main reason to put >> >> state >> >> and config in separate branches was the need to be able to read them >> >> separately. At that time I tought it a mistake that we use module >> >> structure >> >> instead of extending netconf. As Andy stated: "structure is a lousy >> >> tool". >> >> Still in RFC6087bis we have: >> >> "The separation of configuration data and operational state SHOULD be >> >> considered carefully. It is often useful to define separate top- >> >> level containers for configuration and non-configuration data." >> >> This uses the structure as a tool. :-) >> >> >> > >> > >> > RESTCONF already has the 'content' query parameter that allows >> > config, operational, or both. This is good enough. >> > It is trivial for you to add your own content filters to >> > the RPC operations (if you want to prove that standards >> > for more classifications are needed) >> > >> > >> > Andy >> > >> >> or >> >> - a new YANG statement that links together two lists indicating that >> >> one >> >> is >> >> the config part while the other is the state >> > >> > Prove this works as an extension first. >> > IMO it is easy to come up with simplistic solutions for >> > trivial test-cases. Create a general solution first, >> > prove that it helps, then ask the IETF to standardize it. >> > >> > >> >> regards Balazs >> > >> > Andy >> > >> >> >> >> P.S. IETF was always asking for operator input. Now we got it, will we >> >> do >> >> something about it? >> >> >> >> On 2015-04-02 20:02, Randy Presuhn wrote: >> >>> >> >>> Hi - >> >>> >> >>> I think what they're really asking for is an automated way >> >>> to identify the bits and pieces that correspond to a particular >> >>> aspect of a managed thingie. This has already happened with >> >>> "config true". Module structure is a really lousy mechanism >> >>> for identifying aspects; a given bit of information may >> >>> participate in more than one aspect. So I'm agreeing with >> >>> Andy that structure is a lousy tool for the job. >> >>> >> >>> However, the job is an important one. Structure is not the >> >>> solution. Look for another tool. >> >>> >> >>> Randy >> >>> >> >>> -----Original Message----- >> >>>> >> >>>> From: Andy Bierman <andy@yumaworks.com> >> >>>> Sent: Apr 2, 2015 10:49 AM >> >>>> To: Anees Shaikh <aashaikh@google.com> >> >>>> Cc: "netmod@ietf.org" <netmod@ietf.org> >> >>>> Subject: Re: [netmod] New 6087bis issues - connect config - state - >> >>>> statistics >> >>>> >> >>>> On Thu, Apr 2, 2015 at 10:41 AM, Anees Shaikh <aashaikh@google.com> >> >>>> wrote: >> >>>>> >> >>>>> We've laid out why this is a problem (even for existing RFC models) >> >>>>> in >> >>>>> draft-openconfig-netmod-opstate-00 and summarized during the >> >>>>> presentation in >> >>>>> Dallas. The problem is exacerbated when trying to compose multiple >> >>>>> models >> >>>>> into a coherent whole -- clearly it's not possible to manage a >> >>>>> service >> >>>>> or >> >>>>> device with an interfaces model alone. >> >>>>> >> >>>>> Reading the description statements to learn where different types of >> >>>>> data is >> >>>>> stored is not a solution IMO -- we need to think how this will be >> >>>>> use >> >>>>> programmatically by users. And we made the deliberate tradeoff to >> >>>>> introduce >> >>>>> some extra work in building a consistent model for the benefit of a >> >>>>> simple >> >>>>> programming construct to set and retrieve the data. >> >>>>> >> >>>> I disagree. >> >>>> Many times the relationship between a config knob setting >> >>>> and operational state is not simple. There may be all kinds of >> >>>> overlap and dynamic conditions that change the set of >> >>>> interesting objects at the moment. Forcing a certain structure >> >>>> between config and operational nodes will not work as a general >> >>>> solution. >> >>>> You should develop some YANG extensions if you think the >> >>>> problem can be solved without description-stmts. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>> thanks. >> >>>>> -- Anees >> >>>> >> >>>> Andy >> >>>> >> >>>>> On Thu, Apr 2, 2015 at 7:49 AM, Andy Bierman <andy@yumaworks.com> >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> You need to read the description-stmts of the relevant data nodes >> >>>>>> to find out where other related data nodes can be found. >> >>>>>> IMO the sibling config/state approach should only >> >>>>>> be used if the state can exist without the config. >> >>>>>> >> >>>>>> If I have an ACL or some filter that may be nested within lists >> >>>>>> with lots of keys, then it is extremely wasteful to replicate >> >>>>>> all the scaffolding and keys, just to store a couple counters >> >>>>>> for that ACL. It is much better to just put the counters in the ACL >> >>>>>> entry. >> >>>>>> >> >>>>>> But many times the set of interesting objects related to some >> >>>>>> config is far more complicated than that, so the description-stmt >> >>>>>> is the only place to document this information. >> >>>>>> >> >>>>>> >> >>>>>> Andy >> >>>>>> >> >>>>>> >> >>>>>> On Thu, Apr 2, 2015 at 6:52 AM, Balazs Lengyel >> >>>>>> <balazs.lengyel@ericsson.com> wrote: >> >>>>>>> >> >>>>>>> Hello, >> >>>>>>> As indicated by operators in Dallas and as experienced by Ericsson >> >>>>>>> as >> >>>>>>> well, >> >>>>>>> it is sometimes not easy to find the status data for a given bit >> >>>>>>> of >> >>>>>>> configuration (interface, route, etc.). Often the state and >> >>>>>>> configuration >> >>>>>>> are handled in parallel subtrees with the same structure. However >> >>>>>>> this >> >>>>>>> is >> >>>>>>> not part of the guidelines. Also counters are often separated from >> >>>>>>> state >> >>>>>>> data again without a clear guideline to connect statistics with >> >>>>>>> the >> >>>>>>> config. >> >>>>>>> I believe 6087 should provide guidelines how to find state and >> >>>>>>> staistics >> >>>>>>> information for a give piece of configuration. E.g. how do find >> >>>>>>> the >> >>>>>>> number >> >>>>>>> of outgoing packets for an interface? >> >>>>>>> regards Balazs >> >>>>>>> >> >>>>>>> On 2015-04-02 14:47, Martin Bjorklund wrote: >> >>>>>>>> >> >>>>>>>> Hi, >> >>>>>>>> >> >>>>>>>> Here's a list of some things that maybe should be added to >> >>>>>>>> 6087bis. >> >>>>>>>> Some of them are stylistic; I don't know if we should add those >> >>>>>>>> or >> >>>>>>>> not. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 3.6 References >> >>>>>>>> >> >>>>>>>> The RFC Editor prefers the style: >> >>>>>>>> >> >>>>>>>> reference >> >>>>>>>> "RFC <NNNN>: <title>"; >> >>>>>>>> >> >>>>>>>> reference >> >>>>>>>> "RFC <NNNN>: <very long title that spans >> >>>>>>>> more than one line>"; >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> I think we should document this. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 4.1 >> >>>>>>>> >> >>>>>>>> Update this wrt. example modules. Should they be marked with CODE >> >>>>>>>> at >> >>>>>>>> all? >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 5.1. Module Naming Conventions >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Add: IETF modules SHOULD (MUST?) start with "ietf-". >> >>>>>>>> >> >>>>>>>> Example modules SHOULD start with "example-" or "ex-". >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 5.2. Identifiers >> >>>>>>>> >> >>>>>>>> Add: avoid unnecessary prefixes on names. >> >>>>>>>> >> >>>>>>>> BAD: >> >>>>>>>> >> >>>>>>>> list interface { >> >>>>>>>> ... >> >>>>>>>> leaf interface-name { ... } >> >>>>>>>> leaf interface-type { ... } >> >>>>>>>> } >> >>>>>>>> >> >>>>>>>> GOOD: >> >>>>>>>> >> >>>>>>>> list interface { >> >>>>>>>> ... >> >>>>>>>> leaf name { ... } >> >>>>>>>> leaf type { ... } >> >>>>>>>> } >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> use-hypened-names >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 5.8 Namespace Assignments >> >>>>>>>> >> >>>>>>>> OLD: >> >>>>>>>> >> >>>>>>>> The following examples of non-Standards-Track modules are only >> >>>>>>>> suggestions. There are no guidelines for this type of URN in >> >>>>>>>> this >> >>>>>>>> document: >> >>>>>>>> >> >>>>>>>> http://example.com/ns/example-interfaces >> >>>>>>>> >> >>>>>>>> http://example.com/ns/example-system >> >>>>>>>> >> >>>>>>>> NEW: >> >>>>>>>> >> >>>>>>>> There are no guidelines for non-Standards-Track modules. >> >>>>>>>> >> >>>>>>>> Example modules SHOULD use RFC 6963 style URNs: >> >>>>>>>> >> >>>>>>>> urn:example:<module-name> >> >>>>>>>> >> >>>>>>>> Or 2606-style >> >>>>>>>> >> >>>>>>>> http://example.com/... >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> /martin >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> netmod mailing list >> >>>>>>>> netmod@ietf.org >> >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >> >>>>>>>> >> >>>>>>>> >> >>>>>>> -- >> >>>>>>> Balazs Lengyel Ericsson Hungary Ltd. >> >>>>>>> Senior Specialist >> >>>>>>> ECN: 831 7320 >> >>>>>>> Mobile: +36-70-330-7909 email: >> >>>>>>> Balazs.Lengyel@ericsson.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 >> >>> >> >>> _______________________________________________ >> >>> netmod mailing list >> >>> netmod@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/netmod >> >>> >> >> >> >> -- >> >> Balazs Lengyel Ericsson Hungary Ltd. >> >> Senior Specialist >> >> ECN: 831 7320 >> >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.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 Fri Apr 3 19:55:11 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B29A1A891F for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 19:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNyFEyUkyMy8 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 19:55:08 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994271A8911 for <netmod@ietf.org>; Fri, 3 Apr 2015 19:55:07 -0700 (PDT) Received: by lahf3 with SMTP id f3so88308035lah.2 for <netmod@ietf.org>; Fri, 03 Apr 2015 19:55:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DCTtZjIwRZM5z7+iN+KveA9wq9Pw4NtyoE+eqqsMcHc=; b=YgacxQvGxiKXaMY5uwPBmOmVYWeVnzu+fdmxxZ1ODPEzOhfqFlko6+0L1JbSgGnSXP o5bTytbiMkA+7kXyktNFZV0YKRFnTTNSR3UsSK4pQHEhjhYN7ESwrn1dVpG6buyuiw9T rRqH4yNnq9SpHJwlPvcujc8yINABd9Zc12k2GPw4QtJCeCFRhoQunfGe7I6BzDp4ll7y lMBZJfvstOH2v2g3Lm6mQuvHDg46dnn4Ltp+SJ95bxFTc7EHDvVuiQHh+eENE51X4PZz tq2mRWUukzf/AF49nAmarYMYuf9zPuwwdphRbNisTlTHhH7Ftp3eNnA3DFvzsYHlYZmv fotQ== X-Gm-Message-State: ALoCoQnEnCOE1KYC7M+5JyKQY1ZE/wcI+Z8KlFgnulr9QcDcjCRxJsSyiqHjrLhAV7MbQ/ci8bZr MIME-Version: 1.0 X-Received: by 10.152.30.8 with SMTP id o8mr4366950lah.37.1428116106161; Fri, 03 Apr 2015 19:55:06 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 3 Apr 2015 19:55:05 -0700 (PDT) In-Reply-To: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Fri, 3 Apr 2015 19:55:05 -0700 Message-ID: <CABCOCHTXJaeCJbvR+xwoK6bOXrouQRbT-hHu3QaSa0B7E09SOA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/7Z-3t4sSKdNWqK8N7jpS4FWO510> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 02:55:09 -0000 On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > >>From: Andy Bierman <andy@yumaworks.com> >>Sent: Apr 3, 2015 2:14 AM > ... >>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics > ... >>RESTCONF already has the 'content' query parameter that allows >>config, operational, or both. This is good enough. >>It is trivial for you to add your own content filters to >>the RPC operations (if you want to prove that standards >>for more classifications are needed) > > I think you're setting a really low bar for "good enough," > but recognize that this is a judgement call. > There have been proposals to the NETCONF WG several times to address the operational state issue in the NETCONF protocol. There was the <get2> operation in NETCONF-EX that added many new retrieval options. Martin proposed a <get-operational> RPC that could solve this problem. Phil suggested a new operational datastore at the IETF meeting instead of replicating datastore contents. Do you have a definition of "statistics" that everyone will understand so we can add some new YANG statement to pick between different kinds of config=false nodes? Andy > As the number of aspects of interest grows, it becomes more > important that the models should have information allowing > their bits and pieces to be marked in some way so that > aspect-oriented operations become practical. I'm not > suggesting that the route of the GDMO "PACKAGE" construct > is necessarily the way to go, but the need to be able to > factor definitions in this way has been recognized, if > not necessarily exploited, since at least the 1980's. > > Getting back to the start of this thread, there's an underlying > question of whether there should be some set of standardized > aspects, e.g. "statistics" or "performance", built into the > modeling environment (as config and operational, for example) > or whether the modeling language should provide a facility for > identifying new aspects, some of which might potentially > eventually be enshrined in standards-track specifications. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 3 20:21:50 2015 Return-Path: <jason.sterne@alcatel-lucent.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0881A8935 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 20:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl3QP_EReoT8 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 20:21:47 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 4E3F51A8934 for <netmod@ietf.org>; Fri, 3 Apr 2015 20:21:47 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id A5AB9104041AA; Sat, 4 Apr 2015 03:21:44 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t343LhHq018734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Apr 2015 23:21:44 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 3 Apr 2015 23:21:43 -0400 From: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thread-Topic: buffer/file-size (was "Some feedback on syslog-model-03") Thread-Index: AdBoJCTmg08BM4oORk6SCdlQt/jxCQAKHwAAAXLjtfA= Date: Sat, 4 Apr 2015 03:21:43 +0000 Message-ID: <A125E53CE190A749957C19483DC79F9F5C9E7579@US70TWXCHMBA11.zam.alcatel-lucent.com> References: <A125E53CE190A749957C19483DC79F9F5C9E2CE4@US70TWXCHMBA11.zam.alcatel-lucent.com> <20150327011232.GB70967@elstar.local> In-Reply-To: <20150327011232.GB70967@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/_i_pE8L_S8pT9QHnhSUu5YFq2Yk> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: [netmod] buffer/file-size (was "Some feedback on syslog-model-03") X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 03:21:49 -0000 OK - how about something like the following for buffer-size ('type' itself = can't have if-feature). I didn't put it as a 'choice' (i.e. mutually exclu= sive) in case some implementations allow both limits. feature buffer-size-bytes { description "This feature indicates that local memory logging buffers=20 are limited in size using a limit expressed in bytes."; } feature buffer-size-messages { description "This feature indicates that local memory logging buffers=20 are limited in size using a limit expressed in number of messages."; } leaf buffer-size-bytes { if-feature buffer-limit-bytes type uint64; units "bytes"; description "This leaf configures the amount of memory (in bytes) that=20 will be dedicated to the local memory logging buffer."; } leaf buffer-size-messages { if-feature buffer-limit-messages type uint64; units "log messages"; description "This leaf configures the amount number of log messages that=20 Can be stored in the loocal memory logging buffer."; } We probably don't need to say "The default value varies by implementation."= in the description field because if we don't put a default in the model (a= nd I don't think we should) then the default isn't specified and will be as= sumed to vary IMO. For file logging we should probably also capture the two fundamental approa= ches: size vs time. How about this ? feature file-limit-size { // <-- replaces the current file-logging-archive= -config description "This feature indicates that file logging resources=20 are managed using size and number limits."; } feature file-limit-duration { description "This feature indicates that file logging resources=20 are managed using time based limits."; } container file-logging-action { ... // drop the file-logging-archive container leaf file-number { if-feature file-limit-size; ... (from current draft v03) } leaf file-size { if-feature file-limit-size; ... (from current draft v03) } leaf rollover { if-feature file-limit-duration type uint32; units "minutes"; description "This leaf specifies the length of time that log events should be written to a specific log file. Log events that arrive after the rollover period cause the current log file to be clo= sed=20 and a new log file to be opened."; } leaf retention { if-feature file-limit-duration type uint16; units "hours"; description "This leaf specifies the length of time that completed/closed log event files should be stored in the file system before=20 they are deleted."; } =20 I'd recommend we drop the file-permission leaf and leave that to vendor spe= cific augmentation. Authorization in network element file systems is too va= ried across implementations and I'm not sure that many actually configure i= t directly as part of the syslog config. Regards, Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, March 26, 2015 9:13 PM To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] Some feedback on syslog-model-03 On Fri, Mar 27, 2015 at 12:22:44AM +0000, Sterne, Jason (Jason) wrote: >=20 > ----------------------------------------------- > C) max sizes/numbers for logs > ----------------------------------------------- > There are a few places where a size is configured (buffer-size, file-size= ). Implementations will vary on what units are used in a way that isn't rea= lly directly convertible (e.g. bytes vs # of log messages). >=20 > For file logging some implementations use a retention time rather than=20 > a size limit or file number limit so I'm glad to see an if-feature=20 > around this (or remote it and let the vendor augment for that) >=20 > It is probably more common to have a size for the memory buffers so that = is probably OK to leave in. >=20 > Whatever sizes remain in the model: > - remove any default values > - explain in the description that "This leaf specifies the maximum xyz si= ze. The units are not specified in this model and varies by implementation= (e.g. bytes vs number of log messages)." > Assuming that the number of widely used differences is small, I think this = should be modeled properly and features may be used to announce which of th= e options is supported. This way, I can write a robust network management a= pplication that does not simply configure 42 and then hopes something meani= ngful will happen. An API contract needs to be tight to be useful. /js --=20 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/> From nobody Fri Apr 3 20:45:54 2015 Return-Path: <jason.sterne@alcatel-lucent.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEB01A894A for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 20:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VNxteWN0VTb for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 20:45:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194391A8949 for <netmod@ietf.org>; Fri, 3 Apr 2015 20:45:52 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 996DE70826C7B; Sat, 4 Apr 2015 03:45:48 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t343jlDI017462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Apr 2015 23:45:48 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 3 Apr 2015 23:45:47 -0400 From: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> To: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Thread-Index: AQHQbUJtPtnCcK57vk2HBZSygy44Lp08MoKg Date: Sat, 4 Apr 2015 03:45:46 +0000 Message-ID: <A125E53CE190A749957C19483DC79F9F5C9E75AA@US70TWXCHMBA11.zam.alcatel-lucent.com> References: <20150402.144231.1437388601493142848.mbj@tail-f.com> In-Reply-To: <20150402.144231.1437388601493142848.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/7lLwrAa1qXV4iycuONAL3b_Lcds> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 03:45:54 -0000 A few comments below marked with [>>JTS] -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Thursday, April 02, 2015 8:43 AM To: netmod@ietf.org Subject: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Hi, I have reviewd this document and have some comments: =20 o typedef severity should have a reference to RFC 5424. o Given that the standard defines a fixed set of 24 facilities, it seems odd that the facilities are modelled as identities, and not as an enumeration. Using identities gives the impression that this is an extensible set of values. [>>JTS] I'd prefer to see this stay as an extensible set of identities. Th= e RFC says "Facility and Severity values are not normative but often used."= . A number of implementations use both the facility names in the RFC as we= ll as proprietary facility names. o Why do we have these: feature file-logging-structured-data feature remote-logging-structured-data I would assume that if the device supports structured data, it would do so regardless of logging method? I.e., a single feature "structured-data" would be enough? But is this (structured data) typically configurable in implementations, and if it is, it is configurable per "action" like this? o I do not understand what the global-logging-action does. The description says: Global logging represents the ability to perform global log message suppression. Does this mean that the global level *suppresses* matching messages? The text talks about "group level suppression", but the model has "global logging action". This is a bit confusing. So what does this configuration mean: <global-logging-action> <none/> </global-logging-action> Does it means that no messages are suppressed, or that all messages are suppressed? o The usage of the in-memory log buffer is a bit unclear. I think the spec needs to explain how this log buffer is supposed to be used. Perhaps we should also provide a mechanism to read this buffer? I.e., provide a config false list of buffered messages? o It is important to remember that the names of choices and cases are not visible in the instantiated data. Thus, when you have nice descriptive names for the choices and cases, and these names convey some meaning, this meaning is lost when you just look at instance data. For example, this instance: <console-logging-action> <severity>warning</severity> </console-logging-action> does not convey the meaning of the chosen case, which is called "logging-facility-all". I.e., from the instance data above you cannot tell that we're actually matching on all facilities. I think you said you are changing this grouping a bit, and if so I will have a look in the next revision. o For the remote logging, it seems only UDP is supported. I think the data model should follow the recommendation in section 3 in draft-schoenw-netmod-yang-pattern-00 so that multiple transports can be supported. Maybe this model should support the TLS and DTLS transports? o For remote logging, I think the "vrf-name" leaf should be removed. It is not clear how this maps to the routing work, and it can always be augmented later, or a vendor can do a proprietary augmentation. o For remote logging is it a good idea to have "source-interface"? If so, should we have this in all our models for outgoing connections? o leaf file-name is supposed to refer to a local file. If inet:uri is supposed to be used, it should state that this MUST be with scheme "file" (i.e., on the form "file:..."). But is inet:uri the correct type to use? o leaf file-number has a default of 1. Isn't this a bit small for a file archive? o leaf file-size has a default of 262144. Why this number? [>>JTS] In my recent comments ("Some feedback on syslog-model-03") I recomm= ended we remove the default from the model and let systems vary on that. o leaf file-permission has the teo values "world-readable" and "no-world-readable". This seems a bit restrictive for some kinds of systems, and it is also underspecified (what exactly does "no-world-readable" mean?). Maybe it is better to leave this out? [>>JTS] I agree - leave this out. Leave that to vendor specific augmentati= on. Authorization in network element file systems is too varied across impl= ementations and I'm not sure that many actually configure it directly as pa= rt of the syslog config. o I think some nodes can get better names. Maybe: syslog / log-actions / global console buffer file remote terminal This allows for future nodes (non-actions) directly underneath "syslog", and it removes the "-logging-action" suffix everywhere. [>>JTS] I like this general idea although I don't think 'global' belongs wi= th the other items. The other items could be in a container called "log-dis= tributors" to match the figure in the draft or perhaps "log-destinations" (= which I somewhat prefer personally). I also suggest you remove the containers "logging-advanced-level-processing" and "logging-match-processing" and just move their leafs up one level: global / logging-level-scope /... select-message-severity pattern-match Some other suggestions: OLD: logging-files NEW: log-file (note singluar) OLD: file-name NEW: name (remove redundant prefix) OLD: file-logging-strucured-data NEW: structured-data (remove redundant prefix) OLD: file-logging-archive NEW: file-archive OLD: file-number NEW: number-of-files OLD: file-size NEW: max-file-size OLD: remote-logging-structured-data NEW: structured-data (remove redundant prefix) o I don't understand how the leaf "select-message-severity" is supposed to be used. o I think container syslog-sign should have: reference "RFC 5848: Signed Syslog Messages"; (Yes I know this is also defined on the top-level, but it is nice to have the reference available when it is used.) BTW this is the style the RFC editor prefers, so you may want to change the current top-level reference to: reference "RFC 5424: The Syslog Protocol RFC 5848: Signed Syslog Messages"; o I don't know anything about signed syslog messages, but are these config params all that are needed? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 3 23:48:50 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C401AD0A6 for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 23:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeQ8zIlNH_wH for <netmod@ietfa.amsl.com>; Fri, 3 Apr 2015 23:48:48 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id E10011AD0AC for <netmod@ietf.org>; Fri, 3 Apr 2015 23:48:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DLHIcP6i9DPBj6WM76gnuXVv1rCvgdR2sUoaNW/TU01EXq4ya4NPDVjaLneB3Yjw; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1YeHss-0000pU-TB for netmod@ietf.org; Sat, 04 Apr 2015 02:48:46 -0400 Received: from 76.254.48.21 by webmail.earthlink.net with HTTP; Sat, 4 Apr 2015 02:48:46 -0400 Message-ID: <5396501.1428130126839.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Fri, 3 Apr 2015 23:48:46 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: "netmod@ietf.org" <netmod@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f891153746da98ade19f05ea5143d2322f1005a0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.41 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/cGnxgTULEEX1jqT2KswkJzj8RRU> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 06:48:49 -0000 Hi - >From: Andy Bierman <andy@yumaworks.com> >Sent: Apr 3, 2015 7:55 PM >To: Randy Presuhn <randy_presuhn@mindspring.com> >Cc: "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics > >On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn ><randy_presuhn@mindspring.com> wrote: >> Hi - >> >>>From: Andy Bierman <andy@yumaworks.com> >>>Sent: Apr 3, 2015 2:14 AM >> ... >>>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics >> ... >>>RESTCONF already has the 'content' query parameter that allows >>>config, operational, or both. This is good enough. >>>It is trivial for you to add your own content filters to >>>the RPC operations (if you want to prove that standards >>>for more classifications are needed) >> >> I think you're setting a really low bar for "good enough," >> but recognize that this is a judgement call. >> > > >There have been proposals to the NETCONF WG >several times to address the operational state issue >in the NETCONF protocol. > >There was the <get2> operation in NETCONF-EX that >added many new retrieval options. >Martin proposed a <get-operational> RPC that could >solve this problem. Phil suggested a new operational >datastore at the IETF meeting instead of replicating datastore >contents. > >Do you have a definition of "statistics" that everyone will >understand so we can add some new YANG statement >to pick between different kinds of config=false nodes? You've just made the case for *not* building specific categories into the modeling language itself. The amount of angst suffered in the process of figuring out "config false" shows how hard it is even for the easy cases. I'm pessismistic about the possibility that such categories could be defined or standardized in the Yang world with sufficient precision to be useful. There have been a couple of different lines of argumentation in this thread, but at their core they're all about the extent to which the semantics of management information are represented in machine-intelligible form, and the extent to which common semantics / semantic relationships can be exploited without requiring the services of an expensive human expert. It's a trade-off. Putting those machine-intelligible semantics into definitions of management information is expensive and error-prone. Relying on humans to code those semantics into management applications is expensive and error-prone. Pick your poison. :-) I'm not going to argue that this would be the right thing to do with Yang. I'm just sticking with the observation that the current toolbox seems to have an excellent selection of hammers and not much else. :-) Randy From nobody Sat Apr 4 01:06:42 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA31F1B2A6F for <netmod@ietfa.amsl.com>; Sat, 4 Apr 2015 01:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRyztnHVZVqW for <netmod@ietfa.amsl.com>; Sat, 4 Apr 2015 01:06:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740111B2A6C for <netmod@ietf.org>; Sat, 4 Apr 2015 01:06:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B9AB693E; Sat, 4 Apr 2015 10:06:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mAjoSv76yXEW; Sat, 4 Apr 2015 10:06:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 4 Apr 2015 10:06:36 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0E912002B; Sat, 4 Apr 2015 10:06:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zNYSS67m0DTq; Sat, 4 Apr 2015 10:06:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6DB720031; Sat, 4 Apr 2015 10:06:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 950CB32A8102; Sat, 4 Apr 2015 10:06:33 +0200 (CEST) Date: Sat, 4 Apr 2015 10:06:33 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> Message-ID: <20150404080633.GA84190@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <20150402.144231.1437388601493142848.mbj@tail-f.com> <A125E53CE190A749957C19483DC79F9F5C9E75AA@US70TWXCHMBA11.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <A125E53CE190A749957C19483DC79F9F5C9E75AA@US70TWXCHMBA11.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/lm_c0JSORewaaBW7-awPZUOL2TM> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 08:06:40 -0000 On Sat, Apr 04, 2015 at 03:45:46AM +0000, Sterne, Jason (Jason) wrote: > o Given that the standard defines a fixed set of 24 facilities, it > seems odd that the facilities are modelled as identities, and not > as an enumeration. Using identities gives the impression that this > is an extensible set of values. > > [>>JTS] I'd prefer to see this stay as an extensible set of identities. The RFC says "Facility and Severity values are not normative but often used.". A number of implementations use both the facility names in the RFC as well as proprietary facility names. > My understanding of RFC 5424 section 6.2.1 is that the PRI field has a fixed size and it is used to encode the faciltity and the priority. Since both of them are fixed in size, I think it makes a lot of sense to enumerate the possible values to achieve interoperability. I agree with Martin that making them identities leads to wrong expectations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Sat Apr 4 02:45:47 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5761B2A8D for <netmod@ietfa.amsl.com>; Sat, 4 Apr 2015 02:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPoOE4FzsrYJ for <netmod@ietfa.amsl.com>; Sat, 4 Apr 2015 02:45:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id ECB151A1BEE for <netmod@ietf.org>; Sat, 4 Apr 2015 02:45:44 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id E13361280052; Sat, 4 Apr 2015 11:45:43 +0200 (CEST) Date: Sat, 04 Apr 2015 11:46:29 +0200 (CEST) Message-Id: <20150404.114629.1072741641912398272.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> References: <551E4EAA.8090703@ericsson.com> <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Nz9A8vT6LalVDAppsWr8Ppk5KLg> Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 09:45:46 -0000 Hi, I have three problems with your proposal (as described in draft-openconfig-netmod-opstate-00) 1. Duplication of config schema In order to support "asynchronous" management systems, you rely on a convention that leads to duplication of all config data nodes. I think this is error prone (what happens if some model doesn't follow this convention?) and unnecessarily results in big and complex data models. Another solution would be to introduce a new "datastore" and a new RPC operation: <get-intended-config>, which would use the same config true schema as the normal config, but return whatever your solution with the duplicated nodes would return. This solution works regardless of conventions, keeps the data model small and focused, and would be optional to implement, so that a server that is "synchronous" would not have to implement this. Also, I do not understand the term "intended config" for the data that copied into the operational state. I would think that the intended config is what the operator wanted, i.e., the config part of the schema. 2. config true nodes under config false nodes. As Andy pointed out, this is not legal in YANG. It is unclear what it would mean. What happens with the config that is there if the state node disappears? 3. The convention of having a node called "config" (in the config...) in order to correlate the config to state. As has been said by others already, this is probably a bit too simplistic. (and again error prone b/c it is just a convention) The relation between the configuration and how it impacts the operational state can be much more complex than this. For example, all state that is affected by disabling an interface might not be visible under the interface's "state" container. /martin From nobody Sat Apr 4 07:50:36 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97191B2BA7 for <netmod@ietfa.amsl.com>; Sat, 4 Apr 2015 07:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEag1dkCWeWW for <netmod@ietfa.amsl.com>; Sat, 4 Apr 2015 07:50:30 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 A86A21B2BA4 for <netmod@ietf.org>; Sat, 4 Apr 2015 07:50:29 -0700 (PDT) Received: by lagv1 with SMTP id v1so18704395lag.3 for <netmod@ietf.org>; Sat, 04 Apr 2015 07:50:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AZqW7pQI8hjHiwdNKT3v3gVY/G/vQvNMX7clEsaO2GM=; b=GLClRmd9l82nK58ycLwxnjEJKVkCfAOxVw0jEvYIiMMZcqsLLJlTkLIqLs+VJp5vIA ShnhhQpampA0ijIYuGQYRTkf9wypzAldOWOs9KlMSIU1g/rl+wLv5DxtTEOKuSLoTz6N VE/4w9mpUa/Q387P85cC403Jb9xY8TvXzANh4lt90udpVOuYYrfWIz9ZYY9Zx4x3bMGn vT+cs3fe+l/h6jtvqGolS1UHg85tI7l84lzzTWRJxerj/2RBxikFfLsRXR3pfqxp3t4V YJRNxlEzdAbBXhZnRzlIEqGzajUvnGoLhnMyVLql0tyqD+cv4JAAru9nc/+VcLAAA8Cm B4lQ== X-Gm-Message-State: ALoCoQm70lS9POJNxV2J8Ry8a69KpIuDrvT4BWpic39PgRJnsECphUI3rGo2m7Z2oyz1IqwLixQX MIME-Version: 1.0 X-Received: by 10.152.87.46 with SMTP id u14mr6306829laz.82.1428159027876; Sat, 04 Apr 2015 07:50:27 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 4 Apr 2015 07:50:27 -0700 (PDT) In-Reply-To: <20150404.114629.1072741641912398272.mbj@tail-f.com> References: <551E4EAA.8090703@ericsson.com> <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> <20150404.114629.1072741641912398272.mbj@tail-f.com> Date: Sat, 4 Apr 2015 07:50:27 -0700 Message-ID: <CABCOCHQSPDfehQJKny2F2+zT45sggkk+U-tPPYxTVh_eWLnhzg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/TFt_lTIsx55rfulg5BZ-VY_iDjI> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 04 Apr 2015 14:50:33 -0000 Hi, https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 Your draft expired in 2013 but I think we should take another look and solve this problem in the protocols, not the data models. As an analogy, why don't we replicate the startup config in the data model? It is possible for the next-reboot value to be different than the configured value, just like the operational value can be different than the configured value. But we never do that because there is a conceptual 'startup' datastore to retrieve that information. We need a conceptual 'operational' datastore, so replicated config in the data model can be avoided. Andy On Sat, Apr 4, 2015 at 2:46 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Hi, > > I have three problems with your proposal (as described in > draft-openconfig-netmod-opstate-00) > > 1. Duplication of config schema > > In order to support "asynchronous" management systems, you rely on a > convention that leads to duplication of all config data nodes. I > think this is error prone (what happens if some model doesn't follow > this convention?) and unnecessarily results in big and complex data > models. > > Another solution would be to introduce a new "datastore" and a new > RPC operation: <get-intended-config>, which would use the same > config true schema as the normal config, but return whatever your > solution with the duplicated nodes would return. > > This solution works regardless of conventions, keeps the data model > small and focused, and would be optional to implement, so that a > server that is "synchronous" would not have to implement this. > > Also, I do not understand the term "intended config" for the data > that copied into the operational state. I would think that the > intended config is what the operator wanted, i.e., the config part > of the schema. > > > 2. config true nodes under config false nodes. > > As Andy pointed out, this is not legal in YANG. It is unclear what > it would mean. What happens with the config that is there if the > state node disappears? > > > 3. The convention of having a node called "config" (in the config...) > in order to correlate the config to state. As has been said by > others already, this is probably a bit too simplistic. (and again > error prone b/c it is just a convention) The relation between the > configuration and how it impacts the operational state can be much > more complex than this. For example, all state that is affected by > disabling an interface might not be visible under the interface's > "state" container. > > > /martin > > > > > From nobody Mon Apr 6 01:58:08 2015 Return-Path: <aashaikh@google.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47741A1BF3 for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 01:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCl5yW7VjKLN for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 01:58:05 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 DD37D1A1B3E for <netmod@ietf.org>; Mon, 6 Apr 2015 01:58:04 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so32226726obb.2 for <netmod@ietf.org>; Mon, 06 Apr 2015 01:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4y0agk7lq06lIqna1M3vXl5brSdRTTrjZgUyaGn1kiM=; b=J+MmR760mWsAP3xyw9tQ+oWUxOJJGhjGImXcwQYxBrWxC+FrUMpM6BEEKH0A0kKfgy vAZktk74iwaKtvBc994gwlTCryqFLe2huvKn9Ft4XBNChGW8jmqRmGCL9qL2lrhrZi8P A376/x40MzWSBBOgCmZevruvE1XRP+cis669KUrs51XRiQQH2rQOEt2joK140hJbwJU8 0+xxHfJfLIuypBcAeZuCmMJxsnpwV42Jbmw30wWSsvm7OmixUFYRVVFD+563LXwGn9Vu mB/OJiH3Of3QfWD/L4IAd08+B4DLcwjVnTQbGWFicrHX7hf5Fo9GTXSjZ5KfHXvXF0Fi Sh7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4y0agk7lq06lIqna1M3vXl5brSdRTTrjZgUyaGn1kiM=; b=CRweffqyYBraKQHCn9XeJlu6Ol0iigUEF/g8JrQ1aDDGT3eEjCMCiODfg/5VP61tKE AMXY5n7zw4nw55TddL2wsCOd5g8uCsZQtuHaO3GHhGXDcfoK+UV+Ko6k8TBs5tHQNv5b yhsDCHp6M6UNCG70xyjnhAuW7wfvbls1YrXpWklwnPxAnBOybZsWE1FGpGz+3WKU3eyX wiMCNZhWpvtMRDbH0Yw73UgkkZAdHbId1KR9ziyxYLY6OEdr9yBmgMbD+gCJ11XMHmRa C2g33H7evbqYmjcSsBpG1VBDZkxpXtiw3r4LbJmPbgHLibRS1qCKdf4uNmhBnBxG4AaL dD7Q== X-Gm-Message-State: ALoCoQnRXq572FGdUyG8UVItKVnyOB0pJL1Qgoi3Nh5iMH7KdoDSl3ebr+M65N1rrra987D1YN5u MIME-Version: 1.0 X-Received: by 10.60.123.40 with SMTP id lx8mr17373706oeb.15.1428310684254; Mon, 06 Apr 2015 01:58:04 -0700 (PDT) Received: by 10.182.73.137 with HTTP; Mon, 6 Apr 2015 01:58:04 -0700 (PDT) In-Reply-To: <CABCOCHTXJaeCJbvR+xwoK6bOXrouQRbT-hHu3QaSa0B7E09SOA@mail.gmail.com> References: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <CABCOCHTXJaeCJbvR+xwoK6bOXrouQRbT-hHu3QaSa0B7E09SOA@mail.gmail.com> Date: Mon, 6 Apr 2015 01:58:04 -0700 Message-ID: <CAJK7ZqJAoDkR+9QpJJ+kZeQTnowG=U0-iGWz+8NQntvr53B07A@mail.gmail.com> From: Anees Shaikh <aashaikh@google.com> To: Andy Bierman <andy@yumaworks.com> Content-Type: multipart/alternative; boundary=047d7b5d3774f6edc605130a7e82 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/JxvPtyQnYJNG2k5EwHyEdHq4pYA> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Apr 2015 08:58:07 -0000 --047d7b5d3774f6edc605130a7e82 Content-Type: text/plain; charset=UTF-8 The suggestions in Martin's earlier draft actually don't address all of the requirements, and are closely tied to NETCONF datastore semantics (it was also not pursued). Mapping to something like RESTCONF, for example, would either require new request headers or new URL constructs, the latter not being much different than our proposal. We spent a good deal of time working through use cases that leverage datastores but dismissed it at the end. That said. we can think through this again with others. Regarding the definition of statistics, there is some discussion in the draft -- we consider three types of state data: i) statistics / counters, ii) element- or protocol-generated state (e.g., #prefixes received on a BGP session), iii) current, actual configuration (that may differ from intended configuration). We also proposed an additional tag (operational: true) that would mark only (i) and (ii) so that synchronous systems would not have to retrieve redundant data on a <get> call. This could be generalized further if one cares about also distinguishing (i) and (ii). thanks. -- Anees On Fri, Apr 3, 2015 at 7:55 PM, Andy Bierman <andy@yumaworks.com> wrote: > On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn > <randy_presuhn@mindspring.com> wrote: > > Hi - > > > >>From: Andy Bierman <andy@yumaworks.com> > >>Sent: Apr 3, 2015 2:14 AM > > ... > >>Subject: Re: [netmod] New 6087bis issues - connect config - state - > statistics > > ... > >>RESTCONF already has the 'content' query parameter that allows > >>config, operational, or both. This is good enough. > >>It is trivial for you to add your own content filters to > >>the RPC operations (if you want to prove that standards > >>for more classifications are needed) > > > > I think you're setting a really low bar for "good enough," > > but recognize that this is a judgement call. > > > > > There have been proposals to the NETCONF WG > several times to address the operational state issue > in the NETCONF protocol. > > There was the <get2> operation in NETCONF-EX that > added many new retrieval options. > Martin proposed a <get-operational> RPC that could > solve this problem. Phil suggested a new operational > datastore at the IETF meeting instead of replicating datastore > contents. > > Do you have a definition of "statistics" that everyone will > understand so we can add some new YANG statement > to pick between different kinds of config=false nodes? > > > > Andy > > > > As the number of aspects of interest grows, it becomes more > > important that the models should have information allowing > > their bits and pieces to be marked in some way so that > > aspect-oriented operations become practical. I'm not > > suggesting that the route of the GDMO "PACKAGE" construct > > is necessarily the way to go, but the need to be able to > > factor definitions in this way has been recognized, if > > not necessarily exploited, since at least the 1980's. > > > > Getting back to the start of this thread, there's an underlying > > question of whether there should be some set of standardized > > aspects, e.g. "statistics" or "performance", built into the > > modeling environment (as config and operational, for example) > > or whether the modeling language should provide a facility for > > identifying new aspects, some of which might potentially > > eventually be enshrined in standards-track specifications. > > > > Randy > > > > _______________________________________________ > > 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 > --047d7b5d3774f6edc605130a7e82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The suggestions in Martin's earlier draft actually don= 't address all of the requirements, and are closely tied to NETCONF dat= astore semantics (it was also not pursued).=C2=A0 Mapping to something like= RESTCONF, for example, would either require new request headers or new URL= constructs, the latter not being much different than our proposal.=C2=A0 W= e spent a good deal of time working through use cases that leverage datasto= res but dismissed it at the end.=C2=A0 That said. we can think through this= again with others.<div><br></div><div>Regarding the definition of statisti= cs, there is some discussion in the draft -- we consider three types of sta= te data: i) statistics / counters, ii) element- or protocol-generated state= (e.g., #prefixes received on a BGP session), iii) current, actual configur= ation (that may differ from intended configuration).</div><div><br></div><d= iv>We also proposed an additional tag (operational: true) that would mark o= nly (i) and (ii) so that synchronous systems would not have to retrieve red= undant data on a <get> call.=C2=A0 This could be generalized further = if one cares about also distinguishing (i) and (ii).</div><div><br></div><d= iv>thanks.</div><div>-- Anees<br><div class=3D"gmail_extra"><br><div class= =3D"gmail_quote">On Fri, Apr 3, 2015 at 7:55 PM, Andy Bierman <span dir=3D"= ltr"><<a href=3D"mailto:andy@yumaworks.com" target=3D"_blank">andy@yumaw= orks.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl= ass=3D"">On Fri, Apr 3, 2015 at 11:43 AM, Randy Presuhn<br> <<a href=3D"mailto:randy_presuhn@mindspring.com">randy_presuhn@mindsprin= g.com</a>> wrote:<br> </span><span class=3D"">> Hi -<br> ><br> >>From: Andy Bierman <<a href=3D"mailto:andy@yumaworks.com">andy@y= umaworks.com</a>><br> >>Sent: Apr 3, 2015 2:14 AM<br> > ...<br> >>Subject: Re: [netmod] New 6087bis issues - connect config - state -= statistics<br> > ...<br> >>RESTCONF already has the 'content' query parameter that all= ows<br> >>config, operational, or both.=C2=A0 This is good enough.<br> >>It is trivial for you to add your own content filters to<br> >>the RPC operations (if you want to prove that standards<br> >>for more classifications are needed)<br> ><br> > I think you're setting a really low bar for "good enough,&quo= t;<br> > but recognize that this is a judgement call.<br> ><br> <br> <br> </span>There have been proposals to the NETCONF WG<br> several times to address the operational state issue<br> in the NETCONF protocol.<br> <br> There was the <get2> operation in NETCONF-EX that<br> added many new retrieval options.<br> Martin proposed a <get-operational> RPC that could<br> solve this problem. Phil suggested a new operational<br> datastore at the IETF meeting instead of replicating datastore<br> contents.<br> <br> Do you have a definition of "statistics" that everyone will<br> understand so we can add some new YANG statement<br> to pick between different kinds of config=3Dfalse nodes?<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> <br> Andy<br> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> > As the number of aspects of interest grows, it becomes more<br> > important that the models should have information allowing<br> > their bits and pieces to be marked in some way so that<br> > aspect-oriented operations become practical.=C2=A0 I'm not<br> > suggesting that the route of the GDMO "PACKAGE" construct<br= > > is necessarily the way to go, but the need to be able to<br> > factor definitions in this way has been recognized, if<br> > not necessarily exploited, since at least the 1980's.<br> ><br> > Getting back to the start of this thread, there's an underlying<br= > > question of whether there should be some set of standardized<br> > aspects, e.g. "statistics" or "performance", built= into the<br> > modeling environment (as config and operational, for example)<br> > or whether the modeling language should provide a facility for<br> > identifying new aspects, some of which might potentially<br> > eventually be enshrined in standards-track specifications.<br> ><br> > Randy<br> ><br> > _______________________________________________<br> > netmod mailing list<br> > <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_bl= ank">https://www.ietf.org/mailman/listinfo/netmod</a><br> <br> _______________________________________________<br> netmod mailing list<br> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">= https://www.ietf.org/mailman/listinfo/netmod</a><br> </div></div></blockquote></div><br></div></div></div> --047d7b5d3774f6edc605130a7e82-- From nobody Mon Apr 6 02:24:33 2015 Return-Path: <aashaikh@google.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEF91A1A28 for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 02:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77pYdgDAOqL7 for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 02:24:30 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 4AFC41A0276 for <netmod@ietf.org>; Mon, 6 Apr 2015 02:24:30 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so32863381obb.1 for <netmod@ietf.org>; Mon, 06 Apr 2015 02:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pCrWMz7xB1bRdji4FZrN6pSzESLMBGwJbd8M/Ij3iXk=; b=Y0kYhsDPUxnMqxfWi6D489STLAN8ejsQTLR9Fq7Kc5NrNFRFKZsnmkdB5fse5MgZvq wuILGd/Ha/9ik/fjJHgjr2hI9K5eSNSWjkmxPx7dXWF2G8tQDmzsmYUsQ03og9/+Vrp2 EUymCJnhBHxlml9oIg9l16BBJkh1VZu/JJcepBrMCHz5l5Dh8/EdVbe2hpUE17huyJCI hiWheGD3gcTJctwjAQAESHd/VXK9cmJqi0mVPqMhKFg3zn/LEeyNr5b9Nb7BGlTAy02q F/S9M5TNlplcwcC+hwk0byiXF3u4Nd9G6aK+gt/LVaQg0xmu2uY9aP0f+qIQZirHolDm GcBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pCrWMz7xB1bRdji4FZrN6pSzESLMBGwJbd8M/Ij3iXk=; b=G5pzVYlVdR20YTjN6fiQymftcrdaK5UDyPdxbBvLlW2mz1EQJlTocejm8+9IYIT6Qa O438nlsUy9tS1djSU05ZHLWEIb565Cb5d82nV+M6Iig0VnYmEdc9Zfb0D2TmSXZ0h5Am OLxnYejOLHhCRhI8dT8fG35/LdtoaaiUTbt1XYZ8NEUGCOSiml4IUJjEOeJ/fuI30B0d PAQYP/5keV9dw1nGnWb8+YCsPrvWqSUob72FbGmQH3GV1ribRv/GmLy5Gs5tIlUs7rAC VWiU0uVRqD22ijoWjzCzIvcuCjmYcZbD0XP6sjrxEB8zbqBPOOky74q5uFb59yRnOGJQ 4xxw== X-Gm-Message-State: ALoCoQnJloIOAKye1h0kqhJ3qq53RDpGm9Nob9uS4XFgPK7hgGo7778lMck/UcCmGbZr3pYuqZMz MIME-Version: 1.0 X-Received: by 10.183.24.168 with SMTP id ij8mr17621011obd.15.1428312269545; Mon, 06 Apr 2015 02:24:29 -0700 (PDT) Received: by 10.182.73.137 with HTTP; Mon, 6 Apr 2015 02:24:29 -0700 (PDT) In-Reply-To: <20150404.114629.1072741641912398272.mbj@tail-f.com> References: <551E4EAA.8090703@ericsson.com> <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> <20150404.114629.1072741641912398272.mbj@tail-f.com> Date: Mon, 6 Apr 2015 02:24:29 -0700 Message-ID: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> From: Anees Shaikh <aashaikh@google.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: multipart/alternative; boundary=001a1134a2b0748cf605130addd4 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/mzLiIafjTmumu3D6aT9AyaWEH7I> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, NETMOD Working Group <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Apr 2015 09:24:32 -0000 --001a1134a2b0748cf605130addd4 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 4, 2015 at 2:46 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Hi, > > I have three problems with your proposal (as described in > draft-openconfig-netmod-opstate-00) > > 1. Duplication of config schema > > In order to support "asynchronous" management systems, you rely on a > convention that leads to duplication of all config data nodes. I > think this is error prone (what happens if some model doesn't follow > this convention?) and unnecessarily results in big and complex data > models. > this convention is actually very easy to check in a model, e.g. could be made part of YANG compilation. As we said in our presentation, there is some additional complexity in writing the model, but the tradeoff is that it makes using it much easier (and I don't think it is that difficult to grok the model, look at the -jstree output). > > Another solution would be to introduce a new "datastore" and a new > RPC operation: <get-intended-config>, which would use the same > config true schema as the normal config, but return whatever your > solution with the duplicated nodes would return. > > This solution works regardless of conventions, keeps the data model > small and focused, and would be optional to implement, so that a > server that is "synchronous" would not have to implement this. > possibly this could work, but there will be issues if one is not using NETCONF as I mentioned in the earlier response to Andy's mail. I hope the answer is not that I can't use YANG for modeling config and state data unless I am using NETCONF. But as we discussed at the Dallas meeting, we can think through datastore solutions in parallel. For a server that is synchronous we proposed to tag the non-config related operational data in the model to distinguish it from the duplicated config nodes. This makes it optional for a user to get that data if it's redundant (and a server may choose not to support those nodes in the model). > > Also, I do not understand the term "intended config" for the data > that copied into the operational state. I would think that the > intended config is what the operator wanted, i.e., the config part > of the schema. > yes, this could be clearer -- the duplicate data is perhaps better called actual config, but it's there to check against the intended config. > > 2. config true nodes under config false nodes. > > As Andy pointed out, this is not legal in YANG. It is unclear what > it would mean. What happens with the config that is there if the > state node disappears? > Our proposal does not violate YANG rules -- config (config: true) and state (config: false) containers live only under config: true nodes. We would perhaps like to do things a bit more simply, but are working within the constraints of what we have in YANG. I assume you mean, for example, if a linecard is removed, the corresponding interface state would disappear? The config for those interfaces should also be deleted in that case. > > 3. The convention of having a node called "config" (in the config...) > in order to correlate the config to state. As has been said by > others already, this is probably a bit too simplistic. (and again > error prone b/c it is just a convention) The relation between the > configuration and how it impacts the operational state can be much > more complex than this. For example, all state that is affected by > disabling an interface might not be visible under the interface's > "state" container. > As I mentioned earlier, I don't entirely agree this convention has to be error prone, it's simple to check. And when doing something like disabling an interface, certainly state in several paths in the model might be affected (e.g., under the Ethernet portion, the aggregate portion, the VLAN portion, etc.). If I need to see the change in those parts of the interface state, I'd need to query those paths. thanks. -- Anees > > > /martin > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134a2b0748cf605130addd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Sat, Apr 4, 2015 at 2:46 AM, Martin Bjorklund <span dir=3D"ltr"><= <a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com</a>><= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l= eft-style:solid;padding-left:1ex">Hi,<br> <br> I have three problems with your proposal (as described in<br> draft-openconfig-netmod-opstate-00)<br> <br> 1.=C2=A0 Duplication of config schema<br> <br> =C2=A0 In order to support "asynchronous" management systems, you= rely on a<br> =C2=A0 convention that leads to duplication of all config data nodes.=C2=A0= I<br> =C2=A0 think this is error prone (what happens if some model doesn't fo= llow<br> =C2=A0 this convention?) and unnecessarily results in big and complex data<= br> =C2=A0 models.<br></blockquote><div><br></div><div>this convention is actua= lly very easy to check in a model, e.g. could be made part of YANG compilat= ion.=C2=A0 As we said in our presentation, there is some additional complex= ity in writing the model, but the tradeoff is that it makes using it much e= asier (and I don't think it is that difficult to grok the model, look a= t the -jstree output).</div><div>=C2=A0</div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col= or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br> =C2=A0 Another solution would be to introduce a new "datastore" a= nd a new<br> =C2=A0 RPC operation: <get-intended-config>, which would use the same= <br> =C2=A0 config true schema as the normal config, but return whatever your<br= > =C2=A0 solution with the duplicated nodes would return.<br></blockquote><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd= ing-left:1ex"><br> =C2=A0 This solution works regardless of conventions, keeps the data model<= br> =C2=A0 small and focused, and would be optional to implement, so that a<br> =C2=A0 server that is "synchronous" would not have to implement t= his.<br></blockquote><div><br></div><div>possibly this could work, but ther= e will be issues if one is not using NETCONF as I mentioned in the earlier = response to Andy's mail.=C2=A0 I hope the answer is not that I can'= t use YANG for modeling config and state data unless I am using NETCONF. = =C2=A0 But as we discussed at the Dallas meeting, we can think through data= store solutions in parallel.</div><div><br></div><div>For a server that is = synchronous we proposed to tag the non-config related operational data in t= he model to distinguish it from the duplicated config nodes.=C2=A0 This mak= es it optional for a user to get that data if it's redundant (and a ser= ver may choose not to support those nodes in the model).</div><div>=C2=A0</= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol= id;padding-left:1ex"> <br> =C2=A0 Also, I do not understand the term "intended config" for t= he data<br> =C2=A0 that copied into the operational state.=C2=A0 I would think that the= <br> =C2=A0 intended config is what the operator wanted, i.e., the config part<b= r> =C2=A0 of the schema.<br></blockquote><div><br></div><div>yes, this could b= e clearer -- the duplicate data is perhaps better called actual config, but= it's there to check against the intended config.=C2=A0</div><div><br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so= lid;padding-left:1ex"> <br> <br> 2.=C2=A0 config true nodes under config false nodes.<br> <br> =C2=A0 As Andy pointed out, this is not legal in YANG.=C2=A0 It is unclear = what<br> =C2=A0 it would mean.=C2=A0 What happens with the config that is there if t= he<br> =C2=A0 state node disappears?<br></blockquote><div><br></div><div>Our propo= sal does not violate YANG rules -- config (config: true) and state (config:= false) containers live only under config: true nodes.=C2=A0 We would perha= ps like to do things a bit more simply, but are working within the constrai= nts of what we have in YANG.</div><div><br></div><div>I assume you mean, fo= r example, =C2=A0if a linecard is removed, the corresponding interface stat= e would disappear?=C2=A0 The config for those interfaces should also be del= eted in that case.</div><div><br></div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb= (204,204,204);border-left-style:solid;padding-left:1ex"> <br> <br> 3.=C2=A0 The convention of having a node called "config" (in the = config...)<br> =C2=A0 in order to correlate the config to state.=C2=A0 As has been said by= <br> =C2=A0 others already, this is probably a bit too simplistic.=C2=A0 (and ag= ain<br> =C2=A0 error prone b/c it is just a convention) The relation between the<br= > =C2=A0 configuration and how it impacts the operational state can be much<b= r> =C2=A0 more complex than this.=C2=A0 For example, all state that is affecte= d by<br> =C2=A0 disabling an interface might not be visible under the interface'= s<br> =C2=A0 "state" container.<br></blockquote><div>=C2=A0</div><div>A= s I mentioned earlier, I don't entirely agree this convention has to be= error prone, it's simple to check.=C2=A0 And when doing something like= disabling an interface, certainly state in several paths in the model migh= t be affected (e.g., under the Ethernet portion, the aggregate portion, the= VLAN portion, etc.). If I need to see the change in those parts of the int= erface state, I'd need to query those paths.</div><div><br></div><div>t= hanks.</div><div>-- Anees</div><div>=C2=A0</div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-= color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D""><div class=3D"h5"><br> <br> /martin<br> <br> <br> <br> <br> <br> <br> _______________________________________________<br> netmod mailing list<br> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">= https://www.ietf.org/mailman/listinfo/netmod</a><br> </div></div></blockquote></div><br></div></div> --001a1134a2b0748cf605130addd4-- From nobody Mon Apr 6 07:11:02 2015 Return-Path: <jason.sterne@alcatel-lucent.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4761A1B56 for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 07:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyig0B1JIqvr for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 07:10:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C301A0377 for <netmod@ietf.org>; Mon, 6 Apr 2015 07:10:58 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 6336516C52E45; Mon, 6 Apr 2015 14:10:53 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t36EAsdh003482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Apr 2015 10:10:55 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 6 Apr 2015 10:10:54 -0400 From: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thread-Topic: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Thread-Index: AQHQbUJtPtnCcK57vk2HBZSygy44Lp08MoKggACSjoCAA0WjYA== Date: Mon, 6 Apr 2015 14:10:54 +0000 Message-ID: <A125E53CE190A749957C19483DC79F9F5C9E7AF8@US70TWXCHMBA11.zam.alcatel-lucent.com> References: <20150402.144231.1437388601493142848.mbj@tail-f.com> <A125E53CE190A749957C19483DC79F9F5C9E75AA@US70TWXCHMBA11.zam.alcatel-lucent.com> <20150404080633.GA84190@elstar.local> In-Reply-To: <20150404080633.GA84190@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Dcgm4XD1ReS4n-Wha6R7lLZCeOo> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Apr 2015 14:11:00 -0000 Hi guys, I think we are mixing up the encoding of the syslog message format here (on= the wire / external to the box) with configuration of filtering for the 'd= istributors'. This syslog model isn't so much about trying to encode the s= yslog message formats (which is more the focus of the RFC) as it is about N= E configuration of the filtering & distribution of log events in a network = element (which isn't really the focus on the RFC). Many systems have proprietary log event flows/streams that they have modele= d as 'facilities' for internal NE configuration & filtering. They then gen= erally have configuration to remap or overwrite the internal proprietary fa= cilities with one of the standard values before sending to a syslog collect= or (that is the "leaf destination-facility"). I've seen that approach in at least Alcatel-Lucent SR OS and in JUNOS. I h= aven't looked at IOS or others but they may have it as well. I really think the applicability of this model will be much better if we al= low extensibility of the facilities (so they can be used in the selector/fi= lter).=20 Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Saturday, April 04, 2015 4:07 AM To: Sterne, Jason (Jason) Cc: Martin Bjorklund; netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt On Sat, Apr 04, 2015 at 03:45:46AM +0000, Sterne, Jason (Jason) wrote: > o Given that the standard defines a fixed set of 24 facilities, it > seems odd that the facilities are modelled as identities, and not > as an enumeration. Using identities gives the impression that this > is an extensible set of values. >=20 > [>>JTS] I'd prefer to see this stay as an extensible set of identities. = The RFC says "Facility and Severity values are not normative but often used= .". A number of implementations use both the facility names in the RFC as = well as proprietary facility names. > My understanding of RFC 5424 section 6.2.1 is that the PRI field has a fixe= d size and it is used to encode the faciltity and the priority. Since both of them are fixed in size, I think it makes a lot of sense to en= umerate the possible values to achieve interoperability. I agree with Marti= n that making them identities leads to wrong expectations. /js --=20 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/> From nobody Mon Apr 6 08:24:38 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F581A892C for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 08:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14Ap4gSJdKw0 for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 08:24:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C9F1A88D7 for <netmod@ietf.org>; Mon, 6 Apr 2015 08:24:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3F106948; Mon, 6 Apr 2015 17:24:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5fBVcMPmf4UX; Mon, 6 Apr 2015 17:24:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 6 Apr 2015 17:24:33 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2001C2002B; Mon, 6 Apr 2015 17:24:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NkHiQTmhEwnV; Mon, 6 Apr 2015 17:24:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A27F120013; Mon, 6 Apr 2015 17:24:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7780532A9106; Mon, 6 Apr 2015 17:24:21 +0200 (CEST) Date: Mon, 6 Apr 2015 17:24:21 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> Message-ID: <20150406152421.GB90144@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <20150402.144231.1437388601493142848.mbj@tail-f.com> <A125E53CE190A749957C19483DC79F9F5C9E75AA@US70TWXCHMBA11.zam.alcatel-lucent.com> <20150404080633.GA84190@elstar.local> <A125E53CE190A749957C19483DC79F9F5C9E7AF8@US70TWXCHMBA11.zam.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <A125E53CE190A749957C19483DC79F9F5C9E7AF8@US70TWXCHMBA11.zam.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/O7MzpCqZb7_0BCNg79Qb5bp7Mp0> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Apr 2015 15:24:37 -0000 If there are two levels and a mapping, then there are two levels and a mapping. An opaque identity where I am not sure what it refers to does not really help that much with interoperability I think. If this two-level approach is common, perhaps it is then better to expose the two levels and the mapping? /js On Mon, Apr 06, 2015 at 02:10:54PM +0000, Sterne, Jason (Jason) wrote: > Hi guys, > > I think we are mixing up the encoding of the syslog message format here (on the wire / external to the box) with configuration of filtering for the 'distributors'. This syslog model isn't so much about trying to encode the syslog message formats (which is more the focus of the RFC) as it is about NE configuration of the filtering & distribution of log events in a network element (which isn't really the focus on the RFC). > > Many systems have proprietary log event flows/streams that they have modeled as 'facilities' for internal NE configuration & filtering. They then generally have configuration to remap or overwrite the internal proprietary facilities with one of the standard values before sending to a syslog collector (that is the "leaf destination-facility"). > > I've seen that approach in at least Alcatel-Lucent SR OS and in JUNOS. I haven't looked at IOS or others but they may have it as well. > > I really think the applicability of this model will be much better if we allow extensibility of the facilities (so they can be used in the selector/filter). > > Jason > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Saturday, April 04, 2015 4:07 AM > To: Sterne, Jason (Jason) > Cc: Martin Bjorklund; netmod@ietf.org > Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt > > On Sat, Apr 04, 2015 at 03:45:46AM +0000, Sterne, Jason (Jason) wrote: > > > o Given that the standard defines a fixed set of 24 facilities, it > > seems odd that the facilities are modelled as identities, and not > > as an enumeration. Using identities gives the impression that this > > is an extensible set of values. > > > > [>>JTS] I'd prefer to see this stay as an extensible set of identities. The RFC says "Facility and Severity values are not normative but often used.". A number of implementations use both the facility names in the RFC as well as proprietary facility names. > > > > My understanding of RFC 5424 section 6.2.1 is that the PRI field has a fixed size and it is used to encode the faciltity and the priority. > Since both of them are fixed in size, I think it makes a lot of sense to enumerate the possible values to achieve interoperability. I agree with Martin that making them identities leads to wrong expectations. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- 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/> From nobody Mon Apr 6 11:10:49 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7FA1A906E for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 11:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGz7SMyHoD_x for <netmod@ietfa.amsl.com>; Mon, 6 Apr 2015 11:10:46 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id AE1C41A907B for <netmod@ietf.org>; Mon, 6 Apr 2015 11:10:45 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id A7ED11280943; Mon, 6 Apr 2015 20:10:44 +0200 (CEST) Date: Mon, 06 Apr 2015 20:10:34 +0200 (CEST) Message-Id: <20150406.201034.2144200870415437057.mbj@tail-f.com> To: aashaikh@google.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> References: <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> <20150404.114629.1072741641912398272.mbj@tail-f.com> <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/_vRs_h5YfOq3C6QOhuzmFhYlw_w> Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 06 Apr 2015 18:10:48 -0000 Anees Shaikh <aashaikh@google.com> wrote: > On Sat, Apr 4, 2015 at 2:46 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > > Hi, > > > > I have three problems with your proposal (as described in > > draft-openconfig-netmod-opstate-00) > > > > 1. Duplication of config schema > > > > In order to support "asynchronous" management systems, you rely on a > > convention that leads to duplication of all config data nodes. I > > think this is error prone (what happens if some model doesn't follow > > this convention?) and unnecessarily results in big and complex data > > models. > > > > this convention is actually very easy to check in a model, e.g. could be > made part of YANG compilation. Agreed, but that is not the point. The problem is that perfectly legal YANG modules (that don't follow the convention) cannot be used in systems that need the convention. > As we said in our presentation, there is > some additional complexity in writing the model, but the tradeoff is that > it makes using it much easier (and I don't think it is that difficult to > grok the model, look at the -jstree output). > > > > > > Another solution would be to introduce a new "datastore" and a new > > RPC operation: <get-intended-config>, which would use the same > > config true schema as the normal config, but return whatever your > > solution with the duplicated nodes would return. > > > > > This solution works regardless of conventions, keeps the data model > > small and focused, and would be optional to implement, so that a > > server that is "synchronous" would not have to implement this. > > > > possibly this could work, but there will be issues if one is not using > NETCONF as I mentioned in the earlier response to Andy's mail. I hope the > answer is not that I can't use YANG for modeling config and state data > unless I am using NETCONF. But as we discussed at the Dallas meeting, we > can think through datastore solutions in parallel. I don't you should view these datastores as being just of NETCONF. They could certainly be exposed over RESTCONF as well (and other protocols). > For a server that is synchronous we proposed to tag the non-config related > operational data in the model to distinguish it from the duplicated config > nodes. This makes it optional for a user to get that data if it's > redundant (and a server may choose not to support those nodes in the model). Then they should be marked with an if-feature. But I still do not prefer this solution... > > Also, I do not understand the term "intended config" for the data > > that copied into the operational state. I would think that the > > intended config is what the operator wanted, i.e., the config part > > of the schema. > > > > yes, this could be clearer -- the duplicate data is perhaps better called > actual config, but it's there to check against the intended config. > > > > > > 2. config true nodes under config false nodes. > > > > As Andy pointed out, this is not legal in YANG. It is unclear what > > it would mean. What happens with the config that is there if the > > state node disappears? > > > > Our proposal does not violate YANG rules -- config (config: true) and state > (config: false) containers live only under config: true nodes. Ok! > We would > perhaps like to do things a bit more simply, but are working within the > constraints of what we have in YANG. > > I assume you mean, for example, if a linecard is removed, the > corresponding interface state would disappear? The config for those > interfaces should also be deleted in that case. This would be an example of the server changing the user-specified configuration depening on operational events. I would strongly recommend against this. Also, it cannot be implemented on a system that faithfully implement NETCONF with its "lock" operation. (If user A has a lock on the config, noone is allowed to modifiy the config). > > 3. The convention of having a node called "config" (in the config...) > > in order to correlate the config to state. As has been said by > > others already, this is probably a bit too simplistic. (and again > > error prone b/c it is just a convention) The relation between the > > configuration and how it impacts the operational state can be much > > more complex than this. For example, all state that is affected by > > disabling an interface might not be visible under the interface's > > "state" container. > > > > As I mentioned earlier, I don't entirely agree this convention has to be > error prone, it's simple to check. See above - yes I agree it is easy to check. That's not the point. The problem is again that some perfectly legal YANG models cannot be used. > And when doing something like disabling > an interface, certainly state in several paths in the model might be > affected (e.g., under the Ethernet portion, the aggregate portion, the VLAN > portion, etc.). If I need to see the change in those parts of the interface > state, I'd need to query those paths. So why is it problematic to query /interfaces-state/interface if you want to check the operational state of an interface? /martin From nobody Tue Apr 7 01:05:04 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470561A079D for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 01:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or7dgZpfGOo3 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 01:05:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EFB671A03B3 for <netmod@ietf.org>; Tue, 7 Apr 2015 01:05:00 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3B0CB1CC009C; Tue, 7 Apr 2015 10:05:00 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: Andy Bierman <andy@yumaworks.com> In-Reply-To: <CABCOCHT_EnfuyJS4LqU2LD17ujhNxW5s-L_hxBdfSkf4mPm-bA@mail.gmail.com> References: <201503311941.t2VJf45r097817@idle.juniper.net> <m2384khvhn.fsf@nic.cz> <20150402145838.GA79268@elstar.local> <551E71CE.3040802@nic.cz> <CABCOCHT_EnfuyJS4LqU2LD17ujhNxW5s-L_hxBdfSkf4mPm-bA@mail.gmail.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 07 Apr 2015 10:04:56 +0200 Message-ID: <m2vbh8pdnb.fsf@birdie.labs.nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/3yBss0aOViuqs4_IcNWnQ5sASqw> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 again X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 08:05:03 -0000 Andy Bierman <andy@yumaworks.com> writes: > On Fri, Apr 3, 2015 at 3:56 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: >> >> On 04/02/2015 04:58 PM, Juergen Schoenwaelder wrote: >>> >>> On Wed, Apr 01, 2015 at 02:40:52PM +0200, Ladislav Lhotka wrote: >>>> >>>> Right, this is the point I've been trying to make. If we want YANG >>>> authors to use standard modules with typedefs/groupings, they should be >>>> easy to read and understand. Being forced to inspect x different >>>> versions and figure out which is the right one to use doesn't seem very >>>> user-friendly. >>>> >>> This is actually simply. If foo.2 replaces foo.1, you mark foo.1 as >>> obsolete and tools will tell you that you use something that is marked >>> obsolete. In some cases, using what is obsolete is what you want, in >>> other cases you go and see whether the new definition foo.2 works for >>> you. >> >> >> My main concern here is *human* readability. Inexperienced module authors >> need to scan existing modules to find typedefs and groupings that might be >> potentially useful to them. Cluttered modules won't work very well in this >> respect. >> >> I believe most authors of new modules should be fine with the most recent >> revisions, and there is no need to expose them to all the history. >> > > > I am also concerned about readability. > My main concern is that readers will be forced to open and compare > several revisions of each module, and it will be extremely difficult > to determine what a given revision of each module actually contains. Except for special cases, it should be sufficient to read the last revision of each module and use what's there. Note that nobody advocates changing typedefs and groupings in a haphazard fashion. Changes may be needed not only due to errors but also because of changed situation. Lada > > IMO foo-type.1 foo-type.2 is much easier to detect as different, > rather than examining the dependency chain to see that > the foo-type is really different every place it is used. > The various typedefs and groupings will not be that different > by direct import. Instead 2nd or 3rd layer imports will be different, > hiding the subtle changes. > > > >> Lada >> > > Andy > >>> >>>> In my experience from programming and schema languages, systems that >>>> require the writer of an importing module to be more explicit about his >>>> intentions work generally better than those that try to be clever. >>> >>> Exactly. This is why you write uses foo.1 or uses foo.2 instead of >>> just uses foo and have magic applied that figures out what foo stands >>> for. ;-) >>> >>> /js >>> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 7 03:58:26 2015 Return-Path: <rjs@rob.sh> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844541B341D for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 03:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRcR4ChipC5X for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 03:58:13 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4039B1B3423 for <netmod@ietf.org>; Tue, 7 Apr 2015 03:58:12 -0700 (PDT) Received: from [109.144.195.92] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1YfRCs-0003Jp-4k; Tue, 07 Apr 2015 11:58:10 +0100 Date: Tue, 7 Apr 2015 11:58:07 +0100 From: Rob Shakir <rjs@rob.sh> To: Randy Presuhn <randy_presuhn@mindspring.com>, "=?utf-8?Q?netmod=40ietf.org?=" <netmod@ietf.org> Message-ID: <etPan.5523b83f.1f16e9e8.855@corretto.local> In-Reply-To: <5396501.1428130126839.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> References: <5396501.1428130126839.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/yYpbdtBMG8rfIf_We_LPbj069_E> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 10:58:24 -0000 Hi Randy, On 4 April 2015 at 07:48:57, Randy Presuhn (randy=5Fpresuhn=40mindspring.= com) wrote: >=C2=A0 > It's a trade-off. Putting those machine-intelligible > semantics into definitions of management information is > expensive and error-prone. Relying on humans to code > those semantics into management applications is expensive > and error-prone. Pick your poison. :-) > =20 > I'm not going to argue that this would be the right thing > to do with Yang. I'm just sticking with the observation > that the current toolbox seems to have an excellent selection > of hammers and not much else. :-) These are both good points. Speaking as someone that has responsibility for 10+ IP networks within an= operator =E2=80=94 I expect to write more implementations *against* the = model than I expect to write versions of a model. I therefore prefer to m= ake things easier and consistent for the guys writing the consuming code,= and put the pain on the modeller at the time of model definition. At the moment, the prevailing opinion I am taking from this list is that = the proposal that we have put forward is =E2=80=98messy=E2=80=99 in terms= of modelling =E2=80=94 but as such, no real solutions to this that also = keep the consistency for folks writing consuming applications are being p= roposed. If taken here is to simply present a mish-mash of tools, and disapprove o= f them not being used in anything but a modelling-pure manner, then this = will end up having unintended consequences for the relevance of this comm= unity to solving real-world problems IMHO. A bit blunt, but it=E2=80=99s = how I see it. Cheers, r. From nobody Tue Apr 7 04:07:44 2015 Return-Path: <rjs@rob.sh> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8971B3430 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WewfK-SUepMv for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:07:41 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254941B3447 for <netmod@ietf.org>; Tue, 7 Apr 2015 04:07:39 -0700 (PDT) Received: from [109.144.195.92] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1YfRLy-0003NQ-73; Tue, 07 Apr 2015 12:07:34 +0100 Date: Tue, 7 Apr 2015 12:07:31 +0100 From: Rob Shakir <rjs@rob.sh> To: Martin Bjorklund <mbj@tail-f.com>, aashaikh@google.com Message-ID: <etPan.5523ba73.1190cde7.855@corretto.local> In-Reply-To: <20150406.201034.2144200870415437057.mbj@tail-f.com> References: <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> <20150404.114629.1072741641912398272.mbj@tail-f.com> <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/DdNmuh65jdZZNTwKYGjCRCozPQE> Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 11:07:43 -0000 Hi Martin, On 6 April 2015 at 19:11:18, Martin Bjorklund (mbj=40tail-f.com) wrote: > =20 > Agreed, but that is not the point. The problem is that perfectly > legal YANG modules (that don't follow the convention) cannot be used > in systems that need the convention. This is not true =E2=80=94 any system can support whichever subset of mod= ules it would like. If there is demand for the set that is supported to h= ave common conventions, then it is likely that these can be supported *al= ongside* any other modules that are required.=C2=A0 =46rom the consumer=E2=80=99s perspective - which I think is not being ta= ken into account here =E2=80=94 I would very much like to have some commo= n conventions, rather than work out the different way that each model has= decided to do things. Having to do this just moves the dimension in whic= h we have diversity from being based on the vendor today, to being based = on the model tomorrow. Either way, it=E2=80=99s diversity that adds compl= exity with zero benefit to consuming systems. =C2=A0 > I don't you should view these datastores as being just of NETCON=46. > They could certainly be exposed over RESTCON=46 as well (and other > protocols). But *are* they being defined for these protocols=3F If the answer is no, = then we can hardly rely on something that does not exist - when we can ma= ke a solution using today=E2=80=99s YANG work=21 r. From nobody Tue Apr 7 04:11:20 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E071B345D for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0_7jAmjP7ac for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:11:17 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 22D5E1B3457 for <netmod@ietf.org>; Tue, 7 Apr 2015 04:11:17 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id D6BE91CC01D9; Tue, 7 Apr 2015 13:11:17 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHQSPDfehQJKny2F2+zT45sggkk+U-tPPYxTVh_eWLnhzg@mail.gmail.com> References: <551E4EAA.8090703@ericsson.com> <CABCOCHQbeEWAMTX2fyZMcnVtDSK1BW==nddOy-hxLstJTjrJkg@mail.gmail.com> <etPan.551f19f0.7c3dbd3d.2d41@piccolo.local> <20150404.114629.1072741641912398272.mbj@tail-f.com> <CABCOCHQSPDfehQJKny2F2+zT45sggkk+U-tPPYxTVh_eWLnhzg@mail.gmail.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 07 Apr 2015 13:11:13 +0200 Message-ID: <m2oan0p50u.fsf@birdie.labs.nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/QaJvSyh0oto6abknqks75A9P-Zk> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 11:11:20 -0000 Andy Bierman <andy@yumaworks.com> writes: > Hi, > > https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > > Your draft expired in 2013 but I think we should take another look > and solve this problem in the protocols, not the data models. I'd support that. In fact, the only part of the YANG language that's really NETCONF-specific is the "config" statement. > > As an analogy, why don't we replicate the startup config in the data model? > It is possible for the next-reboot value to be different than the > configured value, just like the operational value can be different > than the configured value. The essential assumption is that "startup" has the same schema as "running". This needn't be the case for non-NETCONF management protocols. > > But we never do that because there is a conceptual 'startup' datastore > to retrieve that information. We need a conceptual 'operational' > datastore, so replicated config in the data model can be avoided. I would go even farther: the operational datastore should be of primary interest for data modelling because it is where all semantic constraints really matter, and also because it would be (I assume) common for all management protocols. It should then be a task for each management protocol (including NETCONF) to specify the workflow for accessing and modifying the operational datastore. This may also include schemas for protocol-specific datastore(s), if they are needed. Lada > > > > > Andy > > > > On Sat, Apr 4, 2015 at 2:46 AM, Martin Bjorklund <mbj@tail-f.com> wrote: >> Hi, >> >> I have three problems with your proposal (as described in >> draft-openconfig-netmod-opstate-00) >> >> 1. Duplication of config schema >> >> In order to support "asynchronous" management systems, you rely on a >> convention that leads to duplication of all config data nodes. I >> think this is error prone (what happens if some model doesn't follow >> this convention?) and unnecessarily results in big and complex data >> models. >> >> Another solution would be to introduce a new "datastore" and a new >> RPC operation: <get-intended-config>, which would use the same >> config true schema as the normal config, but return whatever your >> solution with the duplicated nodes would return. >> >> This solution works regardless of conventions, keeps the data model >> small and focused, and would be optional to implement, so that a >> server that is "synchronous" would not have to implement this. >> >> Also, I do not understand the term "intended config" for the data >> that copied into the operational state. I would think that the >> intended config is what the operator wanted, i.e., the config part >> of the schema. >> >> >> 2. config true nodes under config false nodes. >> >> As Andy pointed out, this is not legal in YANG. It is unclear what >> it would mean. What happens with the config that is there if the >> state node disappears? >> >> >> 3. The convention of having a node called "config" (in the config...) >> in order to correlate the config to state. As has been said by >> others already, this is probably a bit too simplistic. (and again >> error prone b/c it is just a convention) The relation between the >> configuration and how it impacts the operational state can be much >> more complex than this. For example, all state that is affected by >> disabling an interface might not be visible under the interface's >> "state" container. >> >> >> /martin >> >> >> >> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 7 04:34:27 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A1C1B34D7 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gw8bPHiF8Ra for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:34:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id AD2991B34D6 for <netmod@ietf.org>; Tue, 7 Apr 2015 04:34:24 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id A7ED912801AA; Tue, 7 Apr 2015 13:34:23 +0200 (CEST) Date: Tue, 07 Apr 2015 13:34:23 +0200 (CEST) Message-Id: <20150407.133423.2269546106879658417.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <etPan.5523ba73.1190cde7.855@corretto.local> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/OImomEKBKUqD4giA9tL_lGTcIcg> Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 11:34:26 -0000 Um9iIFNoYWtpciA8cmpzQHJvYi5zaD4gd3JvdGU6DQo+IEhpIE1hcnRpbiwNCj4gDQo+IE9uIDYg QXByaWwgMjAxNSBhdCAxOToxMToxOCwgTWFydGluIEJqb3JrbHVuZCAobWJqQHRhaWwtZi5jb20p IHdyb3RlOg0KPiA+ICANCj4gPiBBZ3JlZWQsIGJ1dCB0aGF0IGlzIG5vdCB0aGUgcG9pbnQuIFRo ZSBwcm9ibGVtIGlzIHRoYXQgcGVyZmVjdGx5DQo+ID4gbGVnYWwgWUFORyBtb2R1bGVzICh0aGF0 IGRvbid0IGZvbGxvdyB0aGUgY29udmVudGlvbikgY2Fubm90IGJlIHVzZWQNCj4gPiBpbiBzeXN0 ZW1zIHRoYXQgbmVlZCB0aGUgY29udmVudGlvbi4NCj4gDQo+IFRoaXMgaXMgbm90IHRydWUg4oCU IGFueSBzeXN0ZW0gY2FuIHN1cHBvcnQgd2hpY2hldmVyIHN1YnNldCBvZiBtb2R1bGVzDQo+IGl0 IHdvdWxkIGxpa2UuIElmIHRoZXJlIGlzIGRlbWFuZCBmb3IgdGhlIHNldCB0aGF0IGlzIHN1cHBv cnRlZCB0bw0KPiBoYXZlIGNvbW1vbiBjb252ZW50aW9ucywgdGhlbiBpdCBpcyBsaWtlbHkgdGhh dCB0aGVzZSBjYW4gYmUgc3VwcG9ydGVkDQo+ICphbG9uZ3NpZGUqIGFueSBvdGhlciBtb2R1bGVz IHRoYXQgYXJlIHJlcXVpcmVkLg0KPiANCj4gRnJvbSB0aGUgY29uc3VtZXLigJlzIHBlcnNwZWN0 aXZlIC0gd2hpY2ggSSB0aGluayBpcyBub3QgYmVpbmcgdGFrZW4NCj4gaW50byBhY2NvdW50IGhl cmUg4oCUIEkgd291bGQgdmVyeSBtdWNoIGxpa2UgdG8gaGF2ZSBzb21lIGNvbW1vbg0KPiBjb252 ZW50aW9ucywgcmF0aGVyIHRoYW4gd29yayBvdXQgdGhlIGRpZmZlcmVudCB3YXkgdGhhdCBlYWNo IG1vZGVsDQo+IGhhcyBkZWNpZGVkIHRvIGRvIHRoaW5ncy4NCg0KV2hlbiB5b3UgcmVseSBvbiBj b252ZW50aW9ucywgZGlmZmVyZW50IG1vZHVsZXMgbWF5IGhhdmUgZGlmZmVyZW50DQpjb252ZW50 aW9ucy4gIFRodXMsIGNvbnN1bWVycyBoYXZlIHRvIGFkYXB0IHRvIGFsbCBkaWZmZXJlbnQNCmNv bnZlbnRpb25zIHByZXNlbnQgaW4gdGhlIHN5c3RlbXMgdGhleSB3YW50IHRvIG1hbmFnZS4gIENv bXBhcmUgdGhpcw0Kd2l0aCBoYXZpbmcgYSBzZXBhcmF0ZSBkYXRhc3RvcmUgZm9yICJhY3R1YWwg Y29uZmlnIi4gIFdpdGggc3VjaCBhDQpkYXRhc3RvcmUsIHRoZSBjb25zdW1lciBjYW4gZ2V0IHRo ZSBpbnRlbmRlZCBhbmQgYWN0dWFsIGNvbmZpZyBpbg0KZXhhY3RseSB0aGUgc2FtZSB3YXkgYWNy b3NzIGltcGxlbWVudGF0aW9ucywgZm9yIGFsbCBkYXRhIG1vZGVscy4NCg0KV2h5IGlzIHRoaXMg aWRlYSBub3QgdGFraW5nIHRoZSBjb25zdW1lcidzIHBlcnNwZWN0aXZlIGludG8gYWNjb3VudD8N Cg0KPiBIYXZpbmcgdG8gZG8gdGhpcyBqdXN0IG1vdmVzIHRoZSBkaW1lbnNpb24NCj4gaW4gd2hp Y2ggd2UgaGF2ZSBkaXZlcnNpdHkgZnJvbSBiZWluZyBiYXNlZCBvbiB0aGUgdmVuZG9yIHRvZGF5 LCB0bw0KPiBiZWluZyBiYXNlZCBvbiB0aGUgbW9kZWwgdG9tb3Jyb3cuIEVpdGhlciB3YXksIGl0 4oCZcyBkaXZlcnNpdHkgdGhhdA0KPiBhZGRzIGNvbXBsZXhpdHkgd2l0aCB6ZXJvIGJlbmVmaXQg dG8gY29uc3VtaW5nIHN5c3RlbXMuDQo+IA0KPiDCoA0KPiA+IEkgZG9uJ3QgeW91IHNob3VsZCB2 aWV3IHRoZXNlIGRhdGFzdG9yZXMgYXMgYmVpbmcganVzdCBvZiBORVRDT05GLg0KPiA+IFRoZXkg Y291bGQgY2VydGFpbmx5IGJlIGV4cG9zZWQgb3ZlciBSRVNUQ09ORiBhcyB3ZWxsIChhbmQgb3Ro ZXINCj4gPiBwcm90b2NvbHMpLg0KPiANCj4gQnV0ICphcmUqIHRoZXkgYmVpbmcgZGVmaW5lZCBm b3IgdGhlc2UgcHJvdG9jb2xzPw0KDQpJZiB3ZSBkZWNpZGUgdGhhdCBhIG5ldyBkYXRhc3RvcmUg aXMgdGhlIHdheSBmb3J3YXJkLCB0aGVuIEkgZXhwZWN0DQp0aGlzIHRvIGJlIGRlZmluZWQgaW4g c3VjaCBhIHdheSB0aGF0IGl0IHdvcmtzIGZvciBib3RoIE5FVENPTkYgYW5kDQpSRVNUQ09ORi4N Cg0KDQovbWFydGluDQo= From nobody Tue Apr 7 04:40:10 2015 Return-Path: <jonathan@hansfords.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9FA1B34E5 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr_lEZFwtTGH for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:40:06 -0700 (PDT) Received: from webmail3.hi.local (www.outitgoes.com [79.170.40.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 4252F1B34BF for <netmod@ietf.org>; Tue, 7 Apr 2015 04:40:06 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail3.hi.local with esmtp (Exim 4.80.1) (envelope-from <jonathan@hansfords.net>) id 1YfRrL-0003mR-JS; Tue, 07 Apr 2015 12:39:59 +0100 Message-Id: <867b2f4cbb97bc57a0afe4b5e210d91b1df6e8d5@webmail.hansfords.net> From: "Jonathan Hansford" <jonathan@hansfords.net> To: "Rob Shakir" <rjs@rob.sh>, "Randy Presuhn" <randy_presuhn@mindspring.com>, netmod@ietf.org X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 10.0.1.196 in-reply-to: <etPan.5523b83f.1f16e9e8.855@corretto.local> Date: Tue, 07 Apr 2015 12:39:59 +0100 Content-Type: multipart/alternative; boundary="=_624efb61bb208d1cec2e7ef7fb8c09bc" MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/sNYWE7BqLByoW6WGFI-7QBBc3Tc> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 11:40:08 -0000 --=_624efb61bb208d1cec2e7ef7fb8c09bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =0A=0A=09I know it is an expired Internet-Draft, but=0A=C2=A0draft-bjork= lund-yang-requirements-00 states:=0A=0A=09YANG is designed to give prior= ity to data model readers. =C2=A0The=0Areaders and reviewers of data mod= els need insight into the=0Aorganization, constraints, and meaning of it= s elements...=0A=0A=09... YANG values the time and effort of the readers= of models above=0Athose of modules writers and YANG tool-chain develope= rs...=0A=0A=09... Above all, the users of NETCONF models (operators) wer= e given=0Ahighest priority in YANG's design.=0A=0A=09That would seem to= place the needs of operators above those of module=0Areaders or writers= , yet the recent threads from operators would seem=0Ato indicate that ha= s not been the case, either with the design of YANG=0Aor the modules wri= tten in YANG.=0A=0A----- Original Message -----=0AFrom: "Rob Shakir" =0A= To:"Randy Presuhn" , "netmod@ietf.org" =0ACc:=0ASent:Tue, 7 Apr 2015 11:= 58:07 +0100=0ASubject:Re: [netmod] New 6087bis issues - connect config -= state -=0Astatistics=0A=0A Hi Randy,=0A=0A On 4 April 2015 at 07:48:57,= Randy Presuhn=0A(randy_presuhn@mindspring.com) wrote:=0A >=C2=A0=0A > I= t's a trade-off. Putting those machine-intelligible=0A > semantics into= definitions of management information is=0A > expensive and error-prone= Relying on humans to code=0A > those semantics into management applica= tions is expensive=0A > and error-prone. Pick your poison. :-)=0A > =0A= > I'm not going to argue that this would be the right thing=0A > to do= with Yang. I'm just sticking with the observation=0A > that the current= toolbox seems to have an excellent selection=0A > of hammers and not mu= ch else. :-)=0A=0A These are both good points.=0A=0A Speaking as someone= that has responsibility for 10+ IP networks=0Awithin an operator =E2=80= =94 I expect to write more implementations=0A*against* the model than I= expect to write versions of a model. I=0Atherefore prefer to make thing= s easier and consistent for the guys=0Awriting the consuming code, and p= ut the pain on the modeller at the=0Atime of model definition.=0A=0A At= the moment, the prevailing opinion I am taking from this list is=0Athat= the proposal that we have put forward is =E2=80=98messy=E2=80=99 in ter= ms of=0Amodelling =E2=80=94 but as such, no real solutions to this that= also keep=0Athe consistency for folks writing consuming applications ar= e being=0Aproposed.=0A=0A If taken here is to simply present a mish-mash= of tools, and=0Adisapprove of them not being used in anything but a mod= elling-pure=0Amanner, then this will end up having unintended consequenc= es for the=0Arelevance of this community to solving real-world problems= IMHO. A bit=0Ablunt, but it=E2=80=99s how I see it. =0A Cheers,=0A r.= =0A=0A _______________________________________________=0A netmod mailing= list=0A netmod@ietf.org=0A https://www.ietf.org/mailman/listinfo/netmod= =0A --=_624efb61bb208d1cec2e7ef7fb8c09bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body style=3D"font-family: 'Helvetica Neue',Helvetica,Arial,sans-= serif; font-size: 12px;"><p>I know it is an expired Internet-Draft, but= =C2=A0draft-bjorklund-yang-requirements-00 states:</p><p></p><blockquot= e style=3D"margin:0 0 0 40px;border:none;padding:0px;"><p>YANG is design= ed to give priority to data model readers. =C2=A0The readers and reviewe= rs of data models need insight into the organization, constraints, and m= eaning of its elements...</p><p>... YANG values the time and effort of t= he readers of models above those of modules writers and YANG tool-chain= developers...</p></blockquote><p></p><blockquote style=3D"margin:0 0 0= 40px;border:none;padding:0px;"><p>... Above all, the users of NETCONF m= odels (operators) were given highest priority in YANG's design.</p></blo= ckquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px;"= ></blockquote><p>That would seem to place the needs of operators above t= hose of module readers or writers, yet the recent threads from operators= would seem to indicate that has not been the case, either with the desi= gn of YANG or the modules written in YANG.<br /><br /></p><blockquote><b= r />----- Original Message -----<br /><div style=3D"width:100%;backgroun= d:rgb(228,228,228);"><div style=3D"font-weight:bold;">From:</div> "Rob S= hakir" <rjs@rob.sh></div><br /><div style=3D"font-weight:bold;">To= :</div>"Randy Presuhn" <randy_presuhn@mindspring.com>, "netmod@iet= f.org" <netmod@ietf.org><br /><div style=3D"font-weight:bold;">Cc:= </div><br /><div style=3D"font-weight:bold;">Sent:</div>Tue, 7 Apr 2015= 11:58:07 +0100<br /><div style=3D"font-weight:bold;">Subject:</div>Re:= [netmod] New 6087bis issues - connect config - state - statistics<br />= <br /><br />=0AHi Randy,<br /><br />=0AOn 4 April 2015 at 07:48:57, Rand= y Presuhn (randy_presuhn@mindspring.com) wrote:<br />=0A>=C2=A0<br />= =0A> It's a trade-off. Putting those machine-intelligible<br />=0A>= ; semantics into definitions of management information is<br />=0A> e= xpensive and error-prone. Relying on humans to code<br />=0A> those s= emantics into management applications is expensive<br />=0A> and erro= r-prone. Pick your poison. :-)<br />=0A> <br />=0A> I'm not going= to argue that this would be the right thing<br />=0A> to do with Yan= g. I'm just sticking with the observation<br />=0A> that the current= toolbox seems to have an excellent selection<br />=0A> of hammers an= d not much else. :-)<br /><br />=0AThese are both good points.<br /><br= />=0ASpeaking as someone that has responsibility for 10+ IP networks wi= thin an operator =E2=80=94 I expect to write more implementations *again= st* the model than I expect to write versions of a model. I therefore pr= efer to make things easier and consistent for the guys writing the consu= ming code, and put the pain on the modeller at the time of model definit= ion.<br /><br />=0AAt the moment, the prevailing opinion I am taking fro= m this list is that the proposal that we have put forward is =E2=80=98me= ssy=E2=80=99 in terms of modelling =E2=80=94 but as such, no real soluti= ons to this that also keep the consistency for folks writing consuming a= pplications are being proposed.<br /><br />=0AIf taken here is to simply= present a mish-mash of tools, and disapprove of them not being used in= anything but a modelling-pure manner, then this will end up having unin= tended consequences for the relevance of this community to solving real-= world problems IMHO. A bit blunt, but it=E2=80=99s how I see it.</blockq= uote><blockquote>=0A<br />=0ACheers,<br />=0Ar.<br /><br />=0A__________= _____________________________________<br />=0Anetmod mailing list<br />= =0Anetmod@ietf.org<br />=0Ahttps://www.ietf.org/mailman/listinfo/netmod<= br /></blockquote></body></html> --=_624efb61bb208d1cec2e7ef7fb8c09bc-- From nobody Tue Apr 7 04:52:25 2015 Return-Path: <rjs@rob.sh> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5232A1A8767 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzf50ZH3kdoc for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 04:52:21 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5E01B346B for <netmod@ietf.org>; Tue, 7 Apr 2015 04:52:20 -0700 (PDT) Received: from [109.144.195.92] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1YfS3F-0003hO-59; Tue, 07 Apr 2015 12:52:17 +0100 Date: Tue, 7 Apr 2015 12:52:14 +0100 From: Rob Shakir <rjs@rob.sh> To: Martin Bjorklund <mbj@tail-f.com> Message-ID: <etPan.5523c4ee.66ef438d.855@corretto.local> In-Reply-To: <20150407.133423.2269546106879658417.mbj@tail-f.com> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/DxkTpmThzu_dd2g9CbyZKSrDXsQ> Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 11:52:24 -0000 On 7 April 2015 at 12:34:56, Martin Bjorklund (mbj=40tail-f.com) wrote: > =20 > When you rely on conventions, different modules may have different > conventions. Thus, consumers have to adapt to all different > conventions present in the systems they want to manage. Compare this > with having a separate datastore for =22actual config=22. With such a > datastore, the consumer can get the intended and actual config in > exactly the same way across implementations, for all data models. > =20 > Why is this idea not taking the consumer's perspective into account=3F I think it is =E2=80=94 and actually, it was the one that I originally fa= voured. :-) If you look at=C2=A0https://docs.google.com/viewer=3Fa=3Dv&pid=3Dsites&sr= cid=3DZGVmYXVsdGRvbW=46pbnxvcGVuY29uZmlnbmV0fGd4OjQ5ZjdlMmY4YmQxYWZhNTI=C2= =A0=5B0=5D slide 5, then we even documented this as one of the preferred = two solutions that we had. Essentially, the logical split (to me) is: a) outside of the path =E2=80=94 which is what you are proposing with dat= astores. we can then always just check the datastore in question to find = intended vs. actual vs. state. b) at the very end of the path =E2=80=94 which is the proposal that is be= ing made in draft-openconfig-netmod-opstate The problems we noted with this approach were: 1. To the audience reviewing it (and conversations with experts, includin= g yourself, I believe) the concept of datastores was very tightly coupled= with NETCON=46. It seemed that the lack of inclusion of datastore suppor= t (as far as I read) in RESTCON=46 indicated that even within the IET=46 = net=7Bconf,mod=7D-defined protocols, we cannot rely on support for datast= ores in the protocol. 2. Some approach allowing the augmentation of a model within an individua= l datastore would be required. This seems very similar to the operational= : true flag, that we proposed. However, if such an extension is not suppo= rted by a device then we do not have the advantage that we can still get = all of the different leaves (actual/intended/state) since they are duplic= ated. I understand that we are not making pretty YANG (and hey, I did a refacto= r of the BGP YANG model to support this approach, so I understand the mod= eller=E2=80=99s pain) - but quite frankly, we *HAVE* to prioritise actual= ly meeting the requirements that we abstracted this to. =5B1=5D Cheers, r. =5B0=5D: Apologies for the unwieldy Google Docs link, I uploaded the PD=46= at=C2=A0http://www.openconfig.net/file-cabinet/Modelling-Operational-Sta= te.pdf=3Fattredirects=3D0&d=3D1. =5B1=5D: Of course, I cannot claim that these requirements are complete *= for all operators*, but amongst the folks that talked about this - we tho= ught that these were a reasonable set of requirements. Indeed, we iterate= d them quite a lot based on feedback. From nobody Tue Apr 7 09:17:18 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7245A1B3791 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 09:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrjIIEKSXUMt for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 09:17:16 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (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 8EDD31A897D for <netmod@ietf.org>; Tue, 7 Apr 2015 09:17:16 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so43199216lbb.2 for <netmod@ietf.org>; Tue, 07 Apr 2015 09:17:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pnwRxpepCIIr+ClXsS9VTThZfvSR7U5GuMlCzN8TXQE=; b=hDkSwMvadrRQ6vEYYWlEKKftk1+U/DvWO7ucGPONy9Yt6NvhflnYFa/m+9iGzBDtLo 7ZAZ5gkIeIEcJZ4WWMVDuif8SXOJwIgKJPmkjeSijWkjGmq9rjQao+PVlW912O2hklsu DFIGa2IlPpGArUp5Elh9B92ar4F7XCCudygDSupMzMX4hm0LiUo0COAq5ye0G67CbuzF buoUOn1lu3joJzluRzrz0KKZyd5DA5EINxzdDMdBg/eUbdrQwpp/aqG0P8rQe2aV+Sgm tyeWFT7fdOaOxIMt1kcg2cApPefIuiPphHE1+P3uJYWX3k/JMGADvenkeHzZsaDowMtp UFaQ== X-Gm-Message-State: ALoCoQmNbaY6anED6W3GLdEkOmPmD04wOIZF65YxAqz4Kc0n8gDQYl6y+clHGDcFTEBvCyxgWl60 MIME-Version: 1.0 X-Received: by 10.112.133.225 with SMTP id pf1mr19139361lbb.33.1428423434980; Tue, 07 Apr 2015 09:17:14 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 7 Apr 2015 09:17:14 -0700 (PDT) In-Reply-To: <etPan.5523c4ee.66ef438d.855@corretto.local> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> <etPan.5523c4ee.66ef438d.855@corretto.local> Date: Tue, 7 Apr 2015 09:17:14 -0700 Message-ID: <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Rob Shakir <rjs@rob.sh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/0HgEt5pt15fHOGN9fEW3qOPcd4U> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 16:17:18 -0000 On Tue, Apr 7, 2015 at 4:52 AM, Rob Shakir <rjs@rob.sh> wrote: > > On 7 April 2015 at 12:34:56, Martin Bjorklund (mbj@tail-f.com) wrote: >> >> When you rely on conventions, different modules may have different >> conventions. Thus, consumers have to adapt to all different >> conventions present in the systems they want to manage. Compare this >> with having a separate datastore for "actual config". With such a >> datastore, the consumer can get the intended and actual config in >> exactly the same way across implementations, for all data models. >> >> Why is this idea not taking the consumer's perspective into account? > > I think it is =E2=80=94 and actually, it was the one that I originally fa= voured. :-) > > If you look at https://docs.google.com/viewer?a=3Dv&pid=3Dsites&srcid=3DZ= GVmYXVsdGRvbWFpbnxvcGVuY29uZmlnbmV0fGd4OjQ5ZjdlMmY4YmQxYWZhNTI [0] slide 5,= then we even documented this as one of the preferred two solutions that we= had. Essentially, the logical split (to me) is: > > a) outside of the path =E2=80=94 which is what you are proposing with dat= astores. we can then always just check the datastore in question to find in= tended vs. actual vs. state. > b) at the very end of the path =E2=80=94 which is the proposal that is be= ing made in draft-openconfig-netmod-opstate > > The problems we noted with this approach were: > > 1. To the audience reviewing it (and conversations with experts, includin= g yourself, I believe) the concept of datastores was very tightly coupled w= ith NETCONF. It seemed that the lack of inclusion of datastore support (as = far as I read) in RESTCONF indicated that even within the IETF net{conf,mod= }-defined protocols, we cannot rely on support for datastores in the protoc= ol. > This is wrong. Datastores are not tightly coupled to NETCONF. RESTCONF works with NETCONF without being a clone of NETCONF. You cannot rely on RESTCONF because it is still an I-D. This process argument is the weakest of all. > 2. Some approach allowing the augmentation of a model within an individua= l datastore would be required. This seems very similar to the operational: = true flag, that we proposed. However, if such an extension is not supported= by a device then we do not have the advantage that we can still get all of= the different leaves (actual/intended/state) since they are duplicated. Why is this needed? Your approach of duplicating the config tree under itself as operational da= ta does not support this approach. Duplicating data is expensive. IMO too expensive for the small amount of value it provides. There are 3 main concerns I have with replicating config as operational sta= te 1) makes modules much harder to read. I do not agree that modules will be easier to use, once they are much harder to read. 2) there is an assumption that all config can be over-ridden by operational state, Even in the minority of cases where this is true, just knowing the different value is not enough. Is it OK that the config and operational values differ? How did the operational value become different? Is this a temporary issue? What config knobs would change the operational value? None of these questions are answered by merely replicating config as state. 3) The YANG constraints are not designed to be relocated from config to sta= te. All of the YANG constraints still apply when moved, only they apply to the config=3Dfalse version, which may or may not be correct. IMO, the only tool being abused here is cut-and-paste YANG. An operational datastore or protocol operations to retrieve the operational values of config=3Dtrue nodes would not have these problems= . > > I understand that we are not making pretty YANG (and hey, I did a refacto= r of the BGP YANG model to support this approach, so I understand the model= ler=E2=80=99s pain) - but quite frankly, we *HAVE* to prioritise actually m= eeting the requirements that we abstracted this to. [1] > > Cheers, > r. > Andy > > [0]: Apologies for the unwieldy Google Docs link, I uploaded the PDF at h= ttp://www.openconfig.net/file-cabinet/Modelling-Operational-State.pdf?attre= directs=3D0&d=3D1. > > [1]: Of course, I cannot claim that these requirements are complete *for = all operators*, but amongst the folks that talked about this - we thought t= hat these were a reasonable set of requirements. Indeed, we iterated them q= uite a lot based on feedback. > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Apr 7 10:57:25 2015 Return-Path: <rjs@rob.sh> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2321B3935 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 10:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8bm_n5o2JdI for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 10:57:22 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DBE1A9008 for <netmod@ietf.org>; Tue, 7 Apr 2015 10:57:19 -0700 (PDT) Received: from [109.144.195.92] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1YfXkR-00076G-Si; Tue, 07 Apr 2015 18:57:15 +0100 Date: Tue, 7 Apr 2015 18:57:14 +0100 From: Rob Shakir <rjs@rob.sh> To: Andy Bierman <andy@yumaworks.com> Message-ID: <etPan.55241a7a.41a7c4c9.855@corretto.local> In-Reply-To: <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ADQ_WBZ2_xZMz7AXOLXNML9i7o4> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "=?utf-8?Q?netmod=40ietf.org?=" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 17:57:24 -0000 Hi Andy, On 7 April 2015 at 17:18:04, Andy Bierman (andy=40yumaworks.com) wrote: > =20 > This is wrong. Datastores are not tightly coupled to NETCON=46. > RESTCON=46 works with NETCON=46 without being a clone of NETCON=46. > You cannot rely on RESTCON=46 because it is still an I-D. > This process argument is the weakest of all. This isn=E2=80=99t a process argument - and I will freely admit that I am= not an expert in what the RESTCON=46 spec might say (although I did my b= est to study it). The key point here is whether we can expect =5Fall prot= ocols=5F via which we might want to interact with the data model that we = are expressing to support data stores.=C2=A0Some of the operators that we= re involved in the conversation suggested that their requirements for the= se protocols may include non-IET=46 defined technologies in the future. I am not religious about either approach - and I agree with you that dupl= ication can be expensive. One of the reasons that we asked for an 'operat= ional: true=E2=80=99 flag is to allow a hook for an RPC that can cut down= the expense of data retrieval where we have systems that we expect that = the config/X and state/X leaves are always identical (although we continu= e to discuss cases where even systems we expect to be synchronous may not= be able to guarantee this). =5B0=5D It feels rather like, right now, I am being told that the current proposa= l we put forward is wrong, but also not being offered another solution th= at meets the requirements. We did reach out to Martin to discuss his (exp= ired) draft =5B1=5D back in December - he counselled us that the approach= did not seem usable to him. I encourage you to do what we tried to - and document the alternative pro= posal in a draft - and ideally test it against real use-cases - so that t= he working group can objectively compare it to that in draft-openconfig-n= etmod-opstate-00. I am not sure we=E2=80=99re going to get much further i= n this email thread. r. =5B0=5D: With such an RPC hook, then in NETCON=46, we could do <get-confi= g> which will get us the config/X leaves, and <get-operational> which wil= l get only the state/Y leaves that do not have a corresponding config lea= f. =5B1=5D:=C2=A0https://tools.ietf.org/html/draft-bjorklund-netmod-operatio= nal-00=C2=A0 From nobody Tue Apr 7 11:27:15 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4FA1B38D2 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 11:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGBuC_y68bRc for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 11:27:12 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6800A1A6EF4 for <netmod@ietf.org>; Tue, 7 Apr 2015 11:27:08 -0700 (PDT) Received: by lagv1 with SMTP id v1so48803602lag.3 for <netmod@ietf.org>; Tue, 07 Apr 2015 11:27:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lC39h+dy3xXBGwGjnLbtqEHQZHzuQVdRZYM5u00QS+Y=; b=D7QnPsZOJ0970HyXw6zu/9FFbamfQWMR1TNm/fx7Py0jSrKYtYnUD+3Bp6hXA4Xxyx QCUVRfRywCJ298sZxm74suGATgOKP7XtFm86zieLjHegeUhHg6C3OgD9MvJBBn+OwNwb WzNY5tBKUY/c+U9ZlzCprcoemygSc9hXj4RtGaLY4vOuqdT1TXLw36qTQjN9FJ1lsPTK qU8xfEiexrFsnf1Dy2laYmkF4Yc/yoT0gdas7Yv5QTmSVOVDvPqpnaY/of6ijL71DACx FjpExdpx+SyjDwRwoC8ryP09QotatjckLlXoVL0q5ZNaUvlf3S8wxhsgpfgr9EQqFGDN eWIA== X-Gm-Message-State: ALoCoQmOg5G/4nUfGVnyp/+NAgSNQejedM0BFJ8XZBzcqsOhaKlQbCaq8Lf74Vl1V/lilH+mZqlR MIME-Version: 1.0 X-Received: by 10.113.4.105 with SMTP id cd9mr19549777lbd.38.1428431226954; Tue, 07 Apr 2015 11:27:06 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 7 Apr 2015 11:27:06 -0700 (PDT) In-Reply-To: <etPan.55241a7a.41a7c4c9.855@corretto.local> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> Date: Tue, 7 Apr 2015 11:27:06 -0700 Message-ID: <CABCOCHRwmCdfWJdx=phWT=p_0NjnRcLSO0qgkCSTbuay5qRdXg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Rob Shakir <rjs@rob.sh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/FU3-TdOaHEACJybcX7_D3X7pJQg> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 18:27:14 -0000 On Tue, Apr 7, 2015 at 10:57 AM, Rob Shakir <rjs@rob.sh> wrote: > Hi Andy, > > On 7 April 2015 at 17:18:04, Andy Bierman (andy@yumaworks.com) wrote: >> >> This is wrong. Datastores are not tightly coupled to NETCONF. >> RESTCONF works with NETCONF without being a clone of NETCONF. >> You cannot rely on RESTCONF because it is still an I-D. >> This process argument is the weakest of all. > > This isn=E2=80=99t a process argument - and I will freely admit that I am= not an expert in what the RESTCONF spec might say (although I did my best = to study it). The key point here is whether we can expect _all protocols_ v= ia which we might want to interact with the data model that we are expressi= ng to support data stores. Some of the operators that were involved in the = conversation suggested that their requirements for these protocols may incl= ude non-IETF defined technologies in the future. > > I am not religious about either approach - and I agree with you that dupl= ication can be expensive. One of the reasons that we asked for an 'operatio= nal: true=E2=80=99 flag is to allow a hook for an RPC that can cut down the= expense of data retrieval where we have systems that we expect that the co= nfig/X and state/X leaves are always identical (although we continue to dis= cuss cases where even systems we expect to be synchronous may not be able t= o guarantee this). [0] > > It feels rather like, right now, I am being told that the current proposa= l we put forward is wrong, but also not being offered another solution that= meets the requirements. We did reach out to Martin to discuss his (expired= ) draft [1] back in December - he counselled us that the approach did not s= eem usable to him. > > I encourage you to do what we tried to - and document the alternative pro= posal in a draft - and ideally test it against real use-cases - so that the= working group can objectively compare it to that in draft-openconfig-netmo= d-opstate-00. I am not sure we=E2=80=99re going to get much further in this= email thread. > This is not a new problem. Sometimes we have "admin-state" and "oper-state" objects when we know they are needed. There have been proposals to fix NETCONF to properly support operational state. So far, the NETCONF WG has not decided the problem is worth solving. Maybe your input will change that decision. The ietf-interfaces module was intentionally designed with separate interfa= ces and interfaces-state. Your example solution places the operational state of each interface under the config for the interface. This specific soluti= on was rejected by the NETMOD WG. I am not saying that the WG is right, but republishing RFC 7223 would require a lot of work, revisiting that deci= sion. IMO, without any sort of meta-data to indicate who/what/when/how the operational state is different than the configured value, the operator cann= ot do very much other than discover a configured leaf is not the same as the operational leaf. Duplicating the YANG duplicates all the YANG constraints. I have not seen any real modules where the configuration constraints were intended to be enforced in config=3Dfalse subtrees. YANG does not automatically relocate must-expressions, or allow the operator to decide which config=3Dfalse constraints to ignore. IMO this problem is harder to solve than just adding a <get-operational> command to the protocol(s). Andy > r. > > [0]: With such an RPC hook, then in NETCONF, we could do <get-config> whi= ch will get us the config/X leaves, and <get-operational> which will get on= ly the state/Y leaves that do not have a corresponding config leaf. > [1]: https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 From nobody Tue Apr 7 11:29:50 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD4E1B3A1D for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 11:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXnspgx42ih0 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 11:29:46 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0CA1B3A1F for <netmod@ietf.org>; Tue, 7 Apr 2015 11:29:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AS/KS+PENux1A34krYqR23Wa+i/UIynV8ET302RHJhxRNCg0d+fVZTfeoACV6olu; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1YfYFs-0003uw-IA for netmod@ietf.org; Tue, 07 Apr 2015 14:29:44 -0400 Received: from 99.101.141.36 by webmail.earthlink.net with HTTP; Tue, 7 Apr 2015 14:29:44 -0400 Message-ID: <2388671.1428431384540.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Tue, 7 Apr 2015 11:29:44 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537bad12d1d90faf9d6309d38fb3bd1b027350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.27 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/y5Jbw0mTv2f6GquxLQJy6zifVhA> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 18:29:48 -0000 Hi - I find this thread frustrating because it seems to me like a conversation about selecting the appropriate hammer for drilling a hole. To me, having a selection of datastores is just an elaboration on the tool of *structure* as though it were the sole organizing principle for management information. Perhaps this is a natural consequence of an XML-centric approach. Until/unless the Yang metamodel provides some mechanism for representing semantic commonalities beyond structural replication, ad hoc naming conventions, and cryptic natural language commentary, I think this discussion will continue to make it look as though the group's priorities were: 1) convenience of Yang language definers 2) enabling tool implementors to throw something together as quickly as possible 3) impose as few constraints on modelers as possible 4) hope that application developers can make it do something useful 5) let the users be grateful for whatever crumbs of information they can get. I know (or at least hope) that's not the group's intent. Perhaps I'm being unfair, but there seems to be a gaping chasm between the visions expressed at the IESG workshop oh-so-long-ago and what's on the table today. Randy From nobody Tue Apr 7 12:01:47 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AADF1A90A3 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 12:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQPwnfRNH65n for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 12:01:44 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 C52201B3AC9 for <netmod@ietf.org>; Tue, 7 Apr 2015 12:01:35 -0700 (PDT) Received: by lagv1 with SMTP id v1so49500258lag.3 for <netmod@ietf.org>; Tue, 07 Apr 2015 12:01:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fq7WH/U6sY+wGBxTGncldMgg8oxKZZglNPbLtNuWbbw=; b=cZnQFTyCSxzumGF1Slel0Ket0DTDu6EZuWzFx7zdg/D39cUa123xQbBQojSOaRvOV4 HTmSlv4u0tAClVurS+gDhIyslzx48LaqSbVoEMHSZumRJOxwjJ61iSITV92ajFPcfl5y uA2PxYVeNtYLQh8RkN9G/FHtPQb9PBFqOuu2C0s6fL0Zj87yWtdU7GC7AtAjV5/UjEWZ ZQQfskRiUROgFiysWEnXY5+lJpRW0ZczgldO3mOTONNjmRGpW5xPVoCAJV2+Ooz3kzlj 1K4Ypc1gWpY5EqRyorMGozSa3AQZsRiXmSbMiB8ZcKCvBMXbi/zG/T8qSZgdRwW+CUrT 3MCw== X-Gm-Message-State: ALoCoQk8x7bDOz/fU/vWBb6GWpIGNO0I9WRI+Z1pZPEC2lxaSrBE1p6pYdPOM0xgxhUBqfI4/CVx MIME-Version: 1.0 X-Received: by 10.152.87.46 with SMTP id u14mr19561160laz.82.1428433294138; Tue, 07 Apr 2015 12:01:34 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 7 Apr 2015 12:01:33 -0700 (PDT) In-Reply-To: <2388671.1428431384540.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> References: <2388671.1428431384540.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Tue, 7 Apr 2015 12:01:33 -0700 Message-ID: <CABCOCHRcMNaQYWppz+Ro1CAgpOz7a-zFA7o3TB35GR+53phLpg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/3x6HotvvCdPP0SSLNVtTvvtdkK8> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 19:01:46 -0000 Hi, Maybe it would help if we agreed on the problem that needs to be solved rather than dismissing solutions based on our own understanding of the priorities. Using the interfaces model as an example (as done in the draft)... 1) The NETMOD WG decided it was very important to be able to represent interfaces that were not configured. The openconfig solution does not allow this feature. Only configured interfaces would have an 'operational' subtree. The system discovered interfaces could not be represented. 2) Let's say I know that the mtu on 'eth0' is not the same as the configured value. What does that mean? What am I supposed to do about it? I do not agree that merely knowing the operational knob is not the same as the configured knob is enough information to be actionable. So please describe the problem in enough detail so we can decide if there is agreement on anything. We aren't drilling holes or smashing nails. Stick to the details of network management problems related to operational state. Andy On Tue, Apr 7, 2015 at 11:29 AM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > > I find this thread frustrating because it seems to me like > a conversation about selecting the appropriate hammer for > drilling a hole. > > To me, having a selection of datastores is just an elaboration > on the tool of *structure* as though it were the sole > organizing principle for management information. Perhaps > this is a natural consequence of an XML-centric approach. > > Until/unless the Yang metamodel provides some mechanism for > representing semantic commonalities beyond structural > replication, ad hoc naming conventions, and cryptic natural > language commentary, I think this discussion will continue > to make it look as though the group's priorities were: > 1) convenience of Yang language definers > 2) enabling tool implementors to throw something together > as quickly as possible > 3) impose as few constraints on modelers as possible > 4) hope that application developers can make it do something > useful > 5) let the users be grateful for whatever crumbs of information > they can get. > > I know (or at least hope) that's not the group's intent. > > Perhaps I'm being unfair, but there seems to be a gaping > chasm between the visions expressed at the IESG workshop > oh-so-long-ago and what's on the table today. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Apr 7 12:29:11 2015 Return-Path: <rjs@rob.sh> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D658E1B3B4B for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 12:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-vCK27ifaDL for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 12:28:58 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C630E1B3B47 for <netmod@ietf.org>; Tue, 7 Apr 2015 12:28:57 -0700 (PDT) Received: from [109.144.195.92] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1YfZB8-0007fi-PH; Tue, 07 Apr 2015 20:28:54 +0100 Date: Tue, 7 Apr 2015 20:28:53 +0100 From: Rob Shakir <rjs@rob.sh> To: Randy Presuhn <randy_presuhn@mindspring.com>, Andy Bierman <andy@yumaworks.com> Message-ID: <etPan.55242ff5.519b500d.855@corretto.local> In-Reply-To: <CABCOCHRcMNaQYWppz+Ro1CAgpOz7a-zFA7o3TB35GR+53phLpg@mail.gmail.com> References: <2388671.1428431384540.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <CABCOCHRcMNaQYWppz+Ro1CAgpOz7a-zFA7o3TB35GR+53phLpg@mail.gmail.com> X-Mailer: Airmail (286) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/2dM5qxA9xSFpUO7uJ8bhArZng2Y> Cc: "=?utf-8?Q?netmod=40ietf.org?=" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 19:29:10 -0000 On 7 April 2015 at 20:01:56, Andy Bierman (andy=40yumaworks.com) wrote: > > 1) The NETMOD WG decided it was very important to be able > to represent interfaces that were not configured. The openconfig =20 > solution does not allow this feature. Only configured interfaces =20 > would have an 'operational' subtree. The system discovered =20 > interfaces could not be represented. I don=E2=80=99t think this is true. Why can an interface not have interfa= ce=5Bname=3Dsome-interface=5D/config/X (which has a corresponding interfa= ce=5Bname=3Dsome-interface=5D/state/X) and interface=5Bname=3Dsome-interf= ace=5D/state/installed =3D false =3F The =E2=80=98state=E2=80=99 container does not exist underneath the confi= g container in draft-openconfig-netmod-opstate-00. r. From nobody Tue Apr 7 13:21:43 2015 Return-Path: <paul.doolan@coriant.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5901B3C06 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfhJnT0ILrq3 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:21:30 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0629.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3F11B3BFD for <netmod@ietf.org>; Tue, 7 Apr 2015 13:21:30 -0700 (PDT) Received: from AM2PR04MB0978.eurprd04.prod.outlook.com (25.162.34.140) by AM2PR04MB0753.eurprd04.prod.outlook.com (25.160.56.141) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 7 Apr 2015 20:21:13 +0000 Received: from Paul-Doolans-iMac.local (2601:6:8900:c42c:226:bbff:fe67:cade) by AM2PR04MB0978.eurprd04.prod.outlook.com (25.162.34.140) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 7 Apr 2015 20:21:10 +0000 Message-ID: <55243C22.50906@coriant.com> Date: Tue, 7 Apr 2015 16:20:50 -0400 From: Paul Doolan <paul.doolan@coriant.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Bierman <andy@yumaworks.com>, Rob Shakir <rjs@rob.sh> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> In-Reply-To: <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:6:8900:c42c:226:bbff:fe67:cade] X-ClientProxiedBy: DM2PR11CA0013.namprd11.prod.outlook.com (25.160.91.23) To AM2PR04MB0978.eurprd04.prod.outlook.com (25.162.34.140) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM2PR04MB0978; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM2PR04MB0753; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(479174004)(65956001)(23676002)(47776003)(87976001)(54356999)(65816999)(36756003)(50986999)(42186005)(122386002)(92566002)(2950100001)(50466002)(40100003)(77156002)(62966003)(46102003)(83506001)(93886004)(76176999)(86362001)(64126003)(33656002)(7059030)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR04MB0978; H:Paul-Doolans-iMac.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: <AM2PR04MB097810F8323443746B7BB90AF8FD0@AM2PR04MB0978.eurprd04.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AM2PR04MB0978; BCL:0; PCL:0; RULEID:; SRVR:AM2PR04MB0978; X-Forefront-PRVS: 0539EEBD11 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2015 20:21:10.7716 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR04MB0978 X-OriginatorOrg: coriant.com Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/t6TUdlaQeX8Zkme-EI72dm4y3Uo> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 20:21:41 -0000 Hello Andy, forgive me for picking one line in this complex discussion but I'm having a hard time reconciling this statement: On 4/7/15 12:17 PM, Andy Bierman wrote: > Datastores are not tightly coupled to NETCONF. With what I find in RFC6241: To account for these issues, the NETCONF protocol recognizes the difference between configuration data and state data and provides operations for each. The <get-config> operation retrieves configuration data only, while the <get> operation retrieves configuration and state data. Did you mispeak? Am I taking something out of context? Or am I making a mistake equating data with data-store? thanks, pd From nobody Tue Apr 7 13:25:14 2015 Return-Path: <balazs.lengyel@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543A71B3C12 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C6qd-bw6aOA for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:25:02 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6BA1B3C11 for <netmod@ietf.org>; Tue, 7 Apr 2015 13:25:01 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-c0-55243d1bb276 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.D4.28835.B1D34255; Tue, 7 Apr 2015 22:25:00 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.198]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Tue, 7 Apr 2015 22:24:59 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= <balazs.lengyel@ericsson.com> To: Andy Bierman <andy@yumaworks.com>, Randy Presuhn <randy_presuhn@mindspring.com> Thread-Topic: [netmod] New 6087bis issues - connect config - state - statistics Thread-Index: AQHQcWDRPZ9WgzqPpUCyZjXFEFX29J1Bxj6AgAA3wxA= Date: Tue, 7 Apr 2015 20:24:58 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11EC95E9B@ESESSMB103.ericsson.se> References: <2388671.1428431384540.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <CABCOCHRcMNaQYWppz+Ro1CAgpOz7a-zFA7o3TB35GR+53phLpg@mail.gmail.com> In-Reply-To: <CABCOCHRcMNaQYWppz+Ro1CAgpOz7a-zFA7o3TB35GR+53phLpg@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja6MrUqowao2FosHR2axW8y/2Mhq cX/hEXYHZo8lS34yefzY0MPu0dJ/kSWAOYrLJiU1J7MstUjfLoErY9e2RuaC39IVfzr6WRoY 54l1MXJySAiYSByZuYQJwhaTuHBvPRuILSRwlFFi+0m7LkYuIHsxo8TB3nYWkASbgKvEsU/f wWwRgVCJKT0XwZqZBdQl7px6DNYsLBAg0bVrLhNETaDE1jMnGCFsK4nd09+DxVkEVCRmL9nO DmLzCvhK7Jwxlxli2WxGic7Z55hBEpxAzX+2/QUbygh03fdTa6CWiUvcejIf6moBiSV7zjND 2KISLx//Y4WwlSQalzxhhajXk7gxdQobhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZ haRlASPLKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAqDq45bfVDsaDzx0PMQpwMCrx8CpY KYcKsSaWFVfmHmKU5mBREue1Mz4UIiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFReC5PlPm8 iqhPk297XOnnnHhOXC9lcvd/va3X2RP3Zzv5LXdbtfrYb9tj2i8ydb13GP3ba55581PTTb41 t6zULnR0dwZ+L6q7btZ1pcSucNlnayv2jGdRcnEhGZ9fV/zp3FMsqiqUsu+gBtO0h5pPFkts n6kstJpr+/mFd8O7Nt/7s/GC/uxJSizFGYmGWsxFxYkAFs//LosCAAA= Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/wOa4N-uX4EDmvVXciH4QHZC3m1U> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 20:25:13 -0000 Hello, Balazs has two use cases to solve: 1) I get an alarm about some managed object. Let's assume an instance ident= ifier points out the object. I want to be able to see both its configuratio= n and state data (all) belonging to that object to find out what is going o= n 2) I am collecting counters about an object. When the counters show strange= values, I want to see the configuration and state (e.g. operationalState) = data for that object Regards Balazs -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, 07 April, 2015 21:02 To: Randy Presuhn Cc: netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statist= ics Hi, Maybe it would help if we agreed on the problem that needs to be solved rat= her than dismissing solutions based on our own understanding of the priorit= ies. Using the interfaces model as an example (as done in the draft)... 1) The NETMOD WG decided it was very important to be able to represent interfaces that were not configured. The openconfig solution does not allow this feature. Only configured interfaces would have an 'operational' subtree. The system discovered interfaces could not be represented. 2) Let's say I know that the mtu on 'eth0' is not the same as the configured value. What does that mean? What am I supposed to do about it? I do not agree that merely knowing the operational knob is not the same as the configured knob is enough information to be actionable. So please describe the problem in enough detail so we can decide if there i= s agreement on anything. We aren't drilling holes or smashing nails. Stic= k to the details of network management problems related to operational stat= e. Andy On Tue, Apr 7, 2015 at 11:29 AM, Randy Presuhn <randy_presuhn@mindspring.co= m> wrote: > Hi - > > I find this thread frustrating because it seems to me like a=20 > conversation about selecting the appropriate hammer for drilling a=20 > hole. > > To me, having a selection of datastores is just an elaboration on the=20 > tool of *structure* as though it were the sole organizing principle=20 > for management information. Perhaps this is a natural consequence of=20 > an XML-centric approach. > > Until/unless the Yang metamodel provides some mechanism for=20 > representing semantic commonalities beyond structural replication, ad=20 > hoc naming conventions, and cryptic natural language commentary, I=20 > think this discussion will continue to make it look as though the=20 > group's priorities were: > 1) convenience of Yang language definers > 2) enabling tool implementors to throw something together > as quickly as possible > 3) impose as few constraints on modelers as possible > 4) hope that application developers can make it do something > useful > 5) let the users be grateful for whatever crumbs of information > they can get. > > I know (or at least hope) that's not the group's intent. > > Perhaps I'm being unfair, but there seems to be a gaping chasm between=20 > the visions expressed at the IESG workshop oh-so-long-ago and what's=20 > on the table today. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Apr 7 13:35:52 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66581B3C34 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGvEQCY-gH89 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:35:49 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 B6ABF1B3C35 for <netmod@ietf.org>; Tue, 7 Apr 2015 13:35:48 -0700 (PDT) Received: by lagv1 with SMTP id v1so51320995lag.3 for <netmod@ietf.org>; Tue, 07 Apr 2015 13:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wN3OBnUjHZnvZxOuDkEsCoQs1/7E/PixRdsucOoWBfU=; b=biCUjGQbvWXqbBEZ5FgZs4vu9MFhjuWzvlpJzlR0N3ApZ5o3Ydf+CXlKw4Qvc4Wemy FyS4leU8DgwLJuNlbEEJIiOssQaaU2O93WjNx/zl+uEjzsKYIUAYcm4re/LfSBgPZnGQ RqECddH3/3ya2mbjveL5Y+7D9KbGxJOXajNiiPa8y4GhJURPGQ7v/CBi8Su0mbg/4yPM zdOGVYAj5uz+gT41YmGO6Dyhq9Kw1OcPyWG/0Aq6ZyhjtDuj0hAbMG/H1nHQbAE7lOAt dF2QNEDfEGXounukabQaClawwe7jXNKSXpZJdo2q1E7cAcf4aBVPW+X2+FwTIjPUUp/F 2dHw== X-Gm-Message-State: ALoCoQmCRHppp5bWUaR7ccU8OG3QqIoVX1Arto2XIQPxskzIGZdxVb9c8+6kLWwwU9E5+0OygOws MIME-Version: 1.0 X-Received: by 10.112.141.202 with SMTP id rq10mr20074187lbb.88.1428438947123; Tue, 07 Apr 2015 13:35:47 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 7 Apr 2015 13:35:46 -0700 (PDT) In-Reply-To: <55243C22.50906@coriant.com> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <55243C22.50906@coriant.com> Date: Tue, 7 Apr 2015 13:35:46 -0700 Message-ID: <CABCOCHSYKW1ABiGgrz6hj3YuEWbByvRYRX2AKkjpX0CmUcBwVQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Paul Doolan <paul.doolan@coriant.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/DMGgDv38V74aPMTa9mDdELZLC1s> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 20:35:51 -0000 On Tue, Apr 7, 2015 at 1:20 PM, Paul Doolan <paul.doolan@coriant.com> wrote: > Hello Andy, > > forgive me for picking one line in this complex discussion but I'm having a > hard time reconciling this statement: > > On 4/7/15 12:17 PM, Andy Bierman wrote: >> >> Datastores are not tightly coupled to NETCONF. > > > With what I find in RFC6241: > > To account for these issues, the NETCONF protocol recognizes the > difference between configuration data and state data and provides > operations for each. The <get-config> operation retrieves > configuration data only, while the <get> operation retrieves > configuration and state data. > > Did you mispeak? Am I taking something out of context? Or am I making a > mistake equating data with data-store? > A new protocol like RESTCONF can define how NETCONF datastores work in that protocol. I2RS can do the same and even add a new ephemeral datastore. I know RFCs written before RESTCONF and I2RS were chartered only mention NETCONF, just as YANG 1.0 only mentions NETCONF. What is your concern exactly? NETCONF and RESTCONF do not limit the operations via YANG rpc-stmt that can be defined. Adding a new protocol operation does not require a new protocol version. > > thanks, > pd Andy From nobody Tue Apr 7 13:45:43 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE151B3C4E for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SxZoGcY9lIs for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:45:34 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 E77151B3C55 for <netmod@ietf.org>; Tue, 7 Apr 2015 13:45:33 -0700 (PDT) Received: by laat2 with SMTP id t2so44421915laa.1 for <netmod@ietf.org>; Tue, 07 Apr 2015 13:45:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mWkcU9PHD8R11lfKZ2TLBpAa/kyQuAyp06OmEjUVW9c=; b=leBULh+LtX+G4MUC2lX5kwK5SL4KL6zNAOg/Nj7xI1vXYua1J2OO2ceN9jqxuUVX1I 2rbeqbCYDRdk+b+YwQTJ7rwzEUAwf8H/9l1plSzrUZ9awuvWknUS+GzLieTPlNbWSm8x SXX/nUhwnbB9XUPHLDxUxPUuf7mD5IZrub/IFBf+pNXOLIqPSH2rP5vy9H5/cKTXcoKI P2ar8PZCAjHZzFZSR9VqrIuIwBccBdADUVg4iSljOQ+L5IjeolKpojg4UUdKnZ8Rl9FV weNqADRYdLeBf6gKc+M/gA4SezPDqm0SG+lgbVoNM6r9+ifwj6lyFidx7tBcbBdArCGx m/Dw== X-Gm-Message-State: ALoCoQltAjNqqo1DBIsK0w8XkkfgROZ+b6oqD7vyGKhJRe0dbM7CpDWFNPI+Bam2IG7vYrbwFbeI MIME-Version: 1.0 X-Received: by 10.152.234.169 with SMTP id uf9mr20116552lac.88.1428439532453; Tue, 07 Apr 2015 13:45:32 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 7 Apr 2015 13:45:32 -0700 (PDT) In-Reply-To: <971D4B790EC8B846BE223DD23AF72FF11EC95E9B@ESESSMB103.ericsson.se> References: <2388671.1428431384540.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <CABCOCHRcMNaQYWppz+Ro1CAgpOz7a-zFA7o3TB35GR+53phLpg@mail.gmail.com> <971D4B790EC8B846BE223DD23AF72FF11EC95E9B@ESESSMB103.ericsson.se> Date: Tue, 7 Apr 2015 13:45:32 -0700 Message-ID: <CABCOCHRP_W0EvH=6oZrE9W7Bf95Vi_6sT7y47o1Qp0zvP+pQNA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= <balazs.lengyel@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/nn8MjLzENdqvtwTNXihT8uP4zi0> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 20:45:39 -0000 On Tue, Apr 7, 2015 at 1:24 PM, Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote: > Hello, > Balazs has two use cases to solve: > 1) I get an alarm about some managed object. Let's assume an instance ide= ntifier points out the object. I want to be able to see both its configurat= ion and state data (all) belonging to that object to find out what is going= on What if the operational state applies to more than 1 config subtree? Do you want the operational state replicated under each config subtree? What if the operational state only applies to some of the associated configuration subtree(s)? How do you know (besides description-stmt) which operational subtrees are meaningful at any given moment? > 2) I am collecting counters about an object. When the counters show stran= ge values, I want to see the configuration and state (e.g. operationalState= ) data for that object What if there is not a 1:1 mapping between a config leaf and an operational leaf. How does NETCONF or YANG know the difference between a strange counter value and a normal counter value? Perhaps new extension statements that describe this complex mapping would be helpful. The root of the data (assuming there is only 1 of intere= st) is not that hard to map: container interfaces { oper:operational-path /if:interfaces-state; ... } IMO requiring all operational data to be rooted under its associated config data is too simplistic and not even required. A "operational-path" statement works just as well without all the cut-and-paste. > Regards Balazs > Andy > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, 07 April, 2015 21:02 > To: Randy Presuhn > Cc: netmod@ietf.org > Subject: Re: [netmod] New 6087bis issues - connect config - state - stati= stics > > Hi, > > Maybe it would help if we agreed on the problem that needs to be solved r= ather than dismissing solutions based on our own understanding of the prior= ities. > > Using the interfaces model as an example (as done in the draft)... > > 1) The NETMOD WG decided it was very important to be able > to represent interfaces that were not configured. The openconfig > solution does not allow this feature. Only configured interfaces > would have an 'operational' subtree. The system discovered > interfaces could not be represented. > > 2) Let's say I know that the mtu on 'eth0' is not the > same as the configured value. What does that mean? > What am I supposed to do about it? > I do not agree that merely knowing the operational knob is > not the same as the configured knob is enough information > to be actionable. > > So please describe the problem in enough detail so we can decide if there= is agreement on anything. We aren't drilling holes or smashing nails. St= ick to the details of network management problems related to operational st= ate. > > > Andy > > > On Tue, Apr 7, 2015 at 11:29 AM, Randy Presuhn <randy_presuhn@mindspring.= com> wrote: >> Hi - >> >> I find this thread frustrating because it seems to me like a >> conversation about selecting the appropriate hammer for drilling a >> hole. >> >> To me, having a selection of datastores is just an elaboration on the >> tool of *structure* as though it were the sole organizing principle >> for management information. Perhaps this is a natural consequence of >> an XML-centric approach. >> >> Until/unless the Yang metamodel provides some mechanism for >> representing semantic commonalities beyond structural replication, ad >> hoc naming conventions, and cryptic natural language commentary, I >> think this discussion will continue to make it look as though the >> group's priorities were: >> 1) convenience of Yang language definers >> 2) enabling tool implementors to throw something together >> as quickly as possible >> 3) impose as few constraints on modelers as possible >> 4) hope that application developers can make it do something >> useful >> 5) let the users be grateful for whatever crumbs of information >> they can get. >> >> I know (or at least hope) that's not the group's intent. >> >> Perhaps I'm being unfair, but there seems to be a gaping chasm between >> the visions expressed at the IESG workshop oh-so-long-ago and what's >> on the table today. >> >> Randy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Apr 7 13:47:53 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184F41A914C for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP4_czrASoTv for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:47:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.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 9B4EB1A9162 for <netmod@ietf.org>; Tue, 7 Apr 2015 13:47:50 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so2457584lbc.1 for <netmod@ietf.org>; Tue, 07 Apr 2015 13:47:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KOYUnzhNY5cNy9CYI+FVJdZA6uHN++T+pZbnC3t10os=; b=l38OjCYWzrfyn13iG8tA3YezejqFhxZzccw25HMAy1BIS3BTi6NR2ZV3ZIi3BQ7zmb va3tcqSMt9RTsYex20hHgmT0VFFvE8Tq18788ZtkHJQz8D/SLZ5DbTFKstQ8Fd/DfpJ2 hp33gulwPNZBq9UhqOlsYC+VzQz0iEfY6wAyc75scIDL33c9xFn6zO8uz8+kfMVFnwxc pLC2ysUpSyovq77u/ZvGtuj85BeqIE5OzFcOkbZR4E0d/KGnWGl87bxnbkNREmyt7h+X dO3luk+9HHYmyjl9ZiHUtggJs4f8rHbccEwsx7UrblBiU8N4wHuqge52TnpdYrPs2mbz RpEQ== X-Gm-Message-State: ALoCoQlVJATe0RvN5Dvi23ojmkQVhEsmA1PQQ8eAzKDEjLNbzpXMKKVN5yR08H/YrfKuvoybL3Aq MIME-Version: 1.0 X-Received: by 10.152.234.169 with SMTP id uf9mr20124034lac.88.1428439669165; Tue, 07 Apr 2015 13:47:49 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 7 Apr 2015 13:47:48 -0700 (PDT) In-Reply-To: <5524416A.9050806@coriant.com> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <55243C22.50906@coriant.com> <CABCOCHSYKW1ABiGgrz6hj3YuEWbByvRYRX2AKkjpX0CmUcBwVQ@mail.gmail.com> <5524416A.9050806@coriant.com> Date: Tue, 7 Apr 2015 13:47:48 -0700 Message-ID: <CABCOCHTAVka2ZP9mnaEx9MUR2tgAnsO3apO6-nRPPkGasrDgzA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Paul Doolan <paul.doolan@coriant.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/IXklsocXYut_o7FZNacaslDvPB8> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 20:47:53 -0000 On Tue, Apr 7, 2015 at 1:43 PM, Paul Doolan <paul.doolan@coriant.com> wrote: >> What is your concern exactly? > > > To ascertain whether the statement "Datastores are not tightly coupled to > NETCONF" is true or not. > > I did offer the option that I may have taken your remark out of context and > it appears from your response that I did i.e you were focussed on RESTCONF. > I note however that you refer to "NETCONF datastores". So, again, I slightly > confused, but going to assume that NETCONF and it's datastores are > (somewhat) tightly coupled. > There have been multiple drafts that proposed new NETCONF operations. RFC 6241 defines how <get> and <get-config> behave, but a new operation can be added in a new RFC with different behavior. > thanks, > pd Andy > > On 4/7/15 4:35 PM, Andy Bierman wrote: >> >> On Tue, Apr 7, 2015 at 1:20 PM, Paul Doolan <paul.doolan@coriant.com> >> wrote: >>> >>> Hello Andy, >>> >>> forgive me for picking one line in this complex discussion but I'm having >>> a >>> hard time reconciling this statement: >>> >>> On 4/7/15 12:17 PM, Andy Bierman wrote: >>>> >>>> Datastores are not tightly coupled to NETCONF. >>> >>> >>> With what I find in RFC6241: >>> >>> To account for these issues, the NETCONF protocol recognizes the >>> difference between configuration data and state data and provides >>> operations for each. The <get-config> operation retrieves >>> configuration data only, while the <get> operation retrieves >>> configuration and state data. >>> >>> Did you mispeak? Am I taking something out of context? Or am I making a >>> mistake equating data with data-store? >>> >> >> A new protocol like RESTCONF can define how NETCONF datastores >> work in that protocol. I2RS can do the same and even add a new >> ephemeral datastore. I know RFCs written before RESTCONF and I2RS >> were chartered only mention NETCONF, just as YANG 1.0 >> only mentions NETCONF. >> >> What is your concern exactly? >> NETCONF and RESTCONF do not limit the operations via YANG rpc-stmt >> that can be defined. Adding a new protocol operation does not require >> a new protocol version. >> >> >> >>> thanks, >>> pd >> >> >> Andy > > From nobody Tue Apr 7 13:48:44 2015 Return-Path: <paul.doolan@coriant.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1A1A9153 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cDeBp6NiVUZ for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 13:48:40 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0678.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::678]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B871B3C37 for <netmod@ietf.org>; Tue, 7 Apr 2015 13:48:39 -0700 (PDT) Received: from HE1PR04MB0987.eurprd04.prod.outlook.com (25.162.21.26) by HE1PR04MB0953.eurprd04.prod.outlook.com (25.162.24.12) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 7 Apr 2015 20:43:45 +0000 Received: from Paul-Doolans-iMac.local (2601:6:8900:c42c:226:bbff:fe67:cade) by HE1PR04MB0987.eurprd04.prod.outlook.com (25.162.21.26) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 7 Apr 2015 20:43:43 +0000 Message-ID: <5524416A.9050806@coriant.com> Date: Tue, 7 Apr 2015 16:43:22 -0400 From: Paul Doolan <paul.doolan@coriant.com> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Bierman <andy@yumaworks.com> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <55243C22.50906@coriant.com> <CABCOCHSYKW1ABiGgrz6hj3YuEWbByvRYRX2AKkjpX0CmUcBwVQ@mail.gmail.com> In-Reply-To: <CABCOCHSYKW1ABiGgrz6hj3YuEWbByvRYRX2AKkjpX0CmUcBwVQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:6:8900:c42c:226:bbff:fe67:cade] X-ClientProxiedBy: BN3PR09CA0033.namprd09.prod.outlook.com (25.160.111.171) To HE1PR04MB0987.eurprd04.prod.outlook.com (25.162.21.26) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB0987; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB0953; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(51704005)(479174004)(24454002)(377454003)(46102003)(110136001)(64126003)(65956001)(42186005)(50466002)(47776003)(36756003)(62966003)(77156002)(83506001)(87976001)(2950100001)(65816999)(50986999)(76176999)(33656002)(92566002)(19580395003)(80316001)(40100003)(93886004)(19580405001)(122386002)(23676002)(54356999)(86362001)(99136001)(7059030)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB0987; H:Paul-Doolans-iMac.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: <HE1PR04MB0987EDEB09629304B7DD5DFEF8FD0@HE1PR04MB0987.eurprd04.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:HE1PR04MB0987; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB0987; X-Forefront-PRVS: 0539EEBD11 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2015 20:43:43.1807 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB0987 X-OriginatorOrg: coriant.com Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/flbvhNQtGhZMmNAtx5QOD2jDZrE> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 20:48:42 -0000 >What is your concern exactly? To ascertain whether the statement "Datastores are not tightly coupled to NETCONF" is true or not. I did offer the option that I may have taken your remark out of context and it appears from your response that I did i.e you were focussed on RESTCONF. I note however that you refer to "NETCONF datastores". So, again, I slightly confused, but going to assume that NETCONF and it's datastores are (somewhat) tightly coupled. thanks, pd On 4/7/15 4:35 PM, Andy Bierman wrote: > On Tue, Apr 7, 2015 at 1:20 PM, Paul Doolan <paul.doolan@coriant.com> wrote: >> Hello Andy, >> >> forgive me for picking one line in this complex discussion but I'm having a >> hard time reconciling this statement: >> >> On 4/7/15 12:17 PM, Andy Bierman wrote: >>> Datastores are not tightly coupled to NETCONF. >> >> With what I find in RFC6241: >> >> To account for these issues, the NETCONF protocol recognizes the >> difference between configuration data and state data and provides >> operations for each. The <get-config> operation retrieves >> configuration data only, while the <get> operation retrieves >> configuration and state data. >> >> Did you mispeak? Am I taking something out of context? Or am I making a >> mistake equating data with data-store? >> > > A new protocol like RESTCONF can define how NETCONF datastores > work in that protocol. I2RS can do the same and even add a new > ephemeral datastore. I know RFCs written before RESTCONF and I2RS > were chartered only mention NETCONF, just as YANG 1.0 > only mentions NETCONF. > > What is your concern exactly? > NETCONF and RESTCONF do not limit the operations via YANG rpc-stmt > that can be defined. Adding a new protocol operation does not require > a new protocol version. > > > >> thanks, >> pd > > Andy From nobody Tue Apr 7 14:19:08 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A451A904F for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 14:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze2povcYxc-n for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 14:19:05 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 841741A9051 for <netmod@ietf.org>; Tue, 7 Apr 2015 14:19:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bOoREdHXT1KZDMMPpIs/9p3mS1cuv1Ce5BOCybzLNAyR4VsK5kazB138jNw8jR/0; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Yfatk-0000or-Ad for netmod@ietf.org; Tue, 07 Apr 2015 17:19:04 -0400 Received: from 99.101.141.36 by webmail.earthlink.net with HTTP; Tue, 7 Apr 2015 17:19:03 -0400 Message-ID: <171379.1428441544263.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Tue, 7 Apr 2015 14:19:03 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: "netmod@ietf.org" <netmod@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115377762bb6dcd9a494c82289143536e145a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.30 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9YjNJHSfBe9paf6puw3xoy8koPQ> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 21:19:07 -0000 Hi - >From: Andy Bierman >Sent: Apr 7, 2015 12:01 PM >To: Randy Presuhn >Cc: "netmod@ietf.org" >Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics > >Hi, > >Maybe it would help if we agreed on the problem that needs to be solved >rather than dismissing solutions based on our own understanding >of the priorities. > >Using the interfaces model as an example (as done in the >draft)... > > 1) The NETMOD WG decided it was very important to be able > to represent interfaces that were not configured. The openconfig > solution does not allow this feature. Only configured interfaces > would have an 'operational' subtree. The system discovered > interfaces could not be represented. I think being able to provision interfaces in advance of installation is important. I think that withdrawing a line card should not cause its configuration to disappear. I think that a line card replacing another "equivalent" card should have the configuration of the "old" card applied to it until/unless management says otherwise. I think its important for everything that is manageable to be visible (modulo access control) regardless of whether it is provisioned or discovered, and that should include both operational and non-operational information, to the extent that the information is available. I suspect we're probably in agreement on all of these. > 2) Let's say I know that the mtu on 'eth0' is not the > same as the configured value. What does that mean? > What am I supposed to do about it? > I do not agree that merely knowing the operational knob is > not the same as the configured knob is enough information > to be actionable. Agreed. That's why the configuration and operational knobs in such a situation are, at least to my mind, distinct pieces of management information with different semantics. I think treating them as though they were the "same thing" but in different data stores is asking for a world of hurt. There *is* a relationship; I think folks differ on how (or even whether) to represent that relationship in the information model, and the extent to which they believe management applications could make use of that knowledge. I think we're agreed that what's been done so far is a bit klunky at best. >So please describe the problem in enough detail so we >can decide if there is agreement on anything. We aren't drilling >holes or smashing nails. Stick to the details of network management >problems related to operational state. I think we're actually in violent agreement, though you and I are describing it in characteristically different ways. That's not new. :-) My point is that formulating it as a datastore problem (or as an extension to the corresponding model/protocol mechanisms) is really just another attempt at using structure to solve a problem which is just an instance of a class of problems which are fundamentally independent of models' structures. Sticking to "operational state" falls apart if one decides to slice and dice the information at finer levels of granularity, e.g. performance statistics, security statistics, throughput, alarm statuses, etc. If there's just one big bucket of "operational state", the datastore view is kinda plausible. If finer, potentially overlapping subcategorization are needed, the datastore view quickly becomes a mass of spaghetti. The question is whether application developers or users benefit enough from having that finer level of granularity represented in models to make it worth the modeling effort. You know my leanings on that point, but since I'm not implementing this stuff, I'm staying officially agnostic. It's a tough issue because rigorously specifying the semantic relationships almost certainly means someone's implementation would have to change in order to conform to the more fully/precisely specified semantics. Netconf / Netmod has tried very hard to be minimally constraining on vendors' implementation, so I think there's a built-in cultural bias against dealing with these problems. It's certainly the group's right to stick with this approach, but that also means that this class of problems will continue to accrete ad hoc solutions. It's conceivable that that's the right thing to do, even though I instinctually recoil from it. Randy From nobody Tue Apr 7 14:58:57 2015 Return-Path: <cwildes@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64051A92FD for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 14:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlJesJZD0X9p for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 14:58:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE661A92FC for <netmod@ietf.org>; Tue, 7 Apr 2015 14:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12990; q=dns/txt; s=iport; t=1428443933; x=1429653533; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sM3AR2LxWtSe1VE8gCWkManwWmxImxcOYrZPftzYET4=; b=Q5oafbqQkGqwjR8ZCfG3PBLWOickabCVj7HGkxoYBAVIX2fWRJWn0dGf Hso4BQbdkNvD1X17CyiiV0v32690XPE5EFD+XYWxjLpO6aZgJGO/U29t0 +hZQo5/lgNHugvdulywl8PTSn3l+xDoH+ooEvLlSPdPENZxW0PT5hGERY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3BQAsUiRV/5pdJa1cgwhSXAWDEMItCoUvTgIcgRRMAQEBAQEBfoQfAQEDAQEBASAROhsCAQgODAImAgICJQsVEAIEARIbiAcIDbVNlwsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhiQt/hDEYOoJoL4EWBY5jghGFYIQngR2DN4JjhiGDOYNKIoIDHIFQb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,540,1422921600"; d="scan'208";a="410331205" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 07 Apr 2015 21:58:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t37Lwpb3014436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 21:58:52 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.15]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 16:58:51 -0500 From: "Clyde Wildes (cwildes)" <cwildes@cisco.com> To: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Thread-Index: AQHQbUJudYHdDoBQEEyPBz3VYG8aJ51CAAMA Date: Tue, 7 Apr 2015 21:59:06 +0000 Message-ID: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> References: <20150402.144231.1437388601493142848.mbj@tail-f.com> In-Reply-To: <20150402.144231.1437388601493142848.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.157.242] Content-Type: text/plain; charset="utf-8" Content-ID: <C15CAD4583664945A8A5BBBFA2C78FCF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/EkDdyXGspPe_c6PGF6GcfKZMuTs> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 21:58:55 -0000 TWFydGluLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IQ0KDQpNeSByZXNwb25zZXMgYXJlIGlu bGluZS4uLg0KDQpPbiA0LzIvMTUsIDU6NDIgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRh aWwtZi5jb20+IHdyb3RlOg0KDQo+SGksDQo+DQo+SSBoYXZlIHJldmlld2QgdGhpcyBkb2N1bWVu dCBhbmQgaGF2ZSBzb21lIGNvbW1lbnRzOiAgICAgICAgDQo+DQo+DQo+byAgdHlwZWRlZiBzZXZl cml0eSBzaG91bGQgaGF2ZSBhIHJlZmVyZW5jZSB0byBSRkMgNTQyNC4NCg0KW2NseWRlXSBBZ3Jl ZWQgLSBJIHdpbGwgbWFrZSB0aGUgY2hhbmdlLg0KDQo+DQo+DQo+byAgR2l2ZW4gdGhhdCB0aGUg c3RhbmRhcmQgZGVmaW5lcyBhIGZpeGVkIHNldCBvZiAyNCBmYWNpbGl0aWVzLCBpdA0KPiAgIHNl ZW1zIG9kZCB0aGF0IHRoZSBmYWNpbGl0aWVzIGFyZSBtb2RlbGxlZCBhcyBpZGVudGl0aWVzLCBh bmQgbm90DQo+ICAgYXMgYW4gZW51bWVyYXRpb24uICBVc2luZyBpZGVudGl0aWVzIGdpdmVzIHRo ZSBpbXByZXNzaW9uIHRoYXQgdGhpcw0KPiAgIGlzIGFuIGV4dGVuc2libGUgc2V0IG9mIHZhbHVl cy4NCg0KW2NseWRlXSBBIG51bWJlciBvZiB2ZW5kb3JzIG5lZWQgdG8gYXVnbWVudCB0aGUgbGlz dCBvZiBmYWNpbGl0aWVzIC0gc29tZSB3aXRoIHNldmVyYWwgaHVuZHJlZCBhZGRpdGlvbmFsIGZh Y2lsaXRpZXMuIFBsZWFzZSBzdWdnZXN0IGFuIGFsdGVybmF0aXZlIGNvZGluZyB0aGF0IGNhbiBi ZSB1c2VkIHRvIGFkZCBmYWNpbGl0aWVzIHRocm91Z2ggYXVnbWVudGF0aW9uLiBJcyBpdCB0aGF0 IHdlIHNob3VsZCBoYXZlIHR3byBzZXBhcmF0ZSBmYWNpbGl0eSBmaWVsZHM6IFJGQyA1NDI0ICgw LTI0KSBhbmQgVmVuZG9yIFNwZWNpZmljIHN0YXJ0aW5nIGF0IDI0Pw0KDQo+DQo+byAgV2h5IGRv IHdlIGhhdmUgdGhlc2U6DQo+DQo+ICAgIGZlYXR1cmUgZmlsZS1sb2dnaW5nLXN0cnVjdHVyZWQt ZGF0YQ0KPg0KPiAgICBmZWF0dXJlIHJlbW90ZS1sb2dnaW5nLXN0cnVjdHVyZWQtZGF0YQ0KPg0K PiAgSSB3b3VsZCBhc3N1bWUgdGhhdCBpZiB0aGUgZGV2aWNlIHN1cHBvcnRzIHN0cnVjdHVyZWQg ZGF0YSwgaXQgd291bGQNCj4gIGRvIHNvIHJlZ2FyZGxlc3Mgb2YgbG9nZ2luZyBtZXRob2Q/ICBJ LmUuLCBhIHNpbmdsZSBmZWF0dXJlDQo+ICAic3RydWN0dXJlZC1kYXRhIiB3b3VsZCBiZSBlbm91 Z2g/DQo+DQo+ICBCdXQgaXMgdGhpcyAoc3RydWN0dXJlZCBkYXRhKSB0eXBpY2FsbHkgY29uZmln dXJhYmxlIGluDQo+ICBpbXBsZW1lbnRhdGlvbnMsIGFuZCBpZiBpdCBpcywgaXQgaXMgY29uZmln dXJhYmxlIHBlciAiYWN0aW9uIiBsaWtlDQo+ICB0aGlzPw0KDQpbY2x5ZGVdIFRoZSBoaXN0b3J5 IG9mIHRoaXMgaXMgdGhhdCB3ZSBhZ3JlZWQgdG8gc3VwcG9ydCBmaWxlLWxvZ2dpbmctc3RydWN0 dXJlZC1kYXRhIGFzIGEgZmVhdHVyZSAoY3VycmVudGx5IGltcGxlbWVudGVkIGJ5IEpVTk9TKSBz aW5jZSBpdCBpcyBjYWxsZWQgb3V0IGluIFJGQyA1NDI0LiBUaGVuIHNvbWVvbmUgKGF0IHRoZSBI YXdhaWkgbWVldGluZykgYXNrZWQsIGlmIHdlIHN1cHBvcnQgc3RydWN0dXJlZCBkYXRhIGZvciBm aWxlcywgd2h5IG5vdCBzdXBwb3J0IGZvciByZW1vdGUgbG9nZ2luZyB0b28/IEFsdGhvdWdoIEkg ZG8gbm90IGtub3cgb2YgYW55b25lIHdobyBoYXMgaW1wbGVtZW50ZWQgdGhpcywgSSBhZ3JlZWQg dG8gc3VwcG9ydCBpdCBmb3IgcmVtb3RlIGxvZ2dpbmcgYXMgYSBzZXBhcmF0ZSBmZWF0dXJlLiBX ZSBhcmUgdGFsa2luZyBhYm91dCB0d28gZGlmZmVyZW50IGZ1bmN0aW9uYWxpdGllcyBoZXJlLiBQ ZXJoYXBzIHRoZSBiZXN0IHNvbHV0aW9uIGlzIHRvIHJlbW92ZSByZW1vdGUtbG9nZ2luZyBzdHJ1 Y3R1cmVkIGRhdGEgYW5kIGxldCBpdCBiZSBzdXBwb3J0ZWQgdGhyb3VnaCBhdWdtZW50YXRpb24g c2hvdWxkIGFueW9uZSByZXF1aXJlIGl0IGluIHRoZSBmdXR1cmUuDQoNCj4NCj4NCj5vICBJIGRv IG5vdCB1bmRlcnN0YW5kIHdoYXQgdGhlIGdsb2JhbC1sb2dnaW5nLWFjdGlvbiBkb2VzLiAgVGhl DQo+ICAgZGVzY3JpcHRpb24gc2F5czoNCj4NCj4gICAgICAgICBHbG9iYWwgbG9nZ2luZyByZXBy ZXNlbnRzIHRoZSBhYmlsaXR5IHRvDQo+ICAgICAgICAgcGVyZm9ybSBnbG9iYWwgbG9nIG1lc3Nh Z2Ugc3VwcHJlc3Npb24uDQo+DQo+ICAgRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUgZ2xvYmFsIGxl dmVsICpzdXBwcmVzc2VzKiBtYXRjaGluZw0KPiAgIG1lc3NhZ2VzPw0KPg0KPiAgIFRoZSB0ZXh0 IHRhbGtzIGFib3V0ICJncm91cCBsZXZlbCBzdXBwcmVzc2lvbiIsIGJ1dCB0aGUgbW9kZWwgaGFz DQo+ICAgImdsb2JhbCBsb2dnaW5nIGFjdGlvbiIuICBUaGlzIGlzIGEgYml0IGNvbmZ1c2luZy4N Cj4NCj4gICBTbyB3aGF0IGRvZXMgdGhpcyBjb25maWd1cmF0aW9uIG1lYW46DQo+DQo+ICAgICA8 Z2xvYmFsLWxvZ2dpbmctYWN0aW9uPg0KPiAgICAgICA8bm9uZS8+DQo+ICAgICA8L2dsb2JhbC1s b2dnaW5nLWFjdGlvbj4NCj4NCj4gICBEb2VzIGl0IG1lYW5zIHRoYXQgbm8gbWVzc2FnZXMgYXJl IHN1cHByZXNzZWQsIG9yIHRoYXQgYWxsIG1lc3NhZ2VzDQo+ICAgYXJlIHN1cHByZXNzZWQ/DQoN CltjbHlkZV0gR2xvYmFsIGxvZ2dpbmcgaXMgYSBmaXJzdCBsZXZlbCBzdXBwcmVzc2lvbiBmaWx0 ZXIuIFBsZWFzZSBzZWUgdGhlIGRpYWdyYW0gaW4gdGhlIFJGQy4gR2l2ZW4gdGhhdCBvbmx5IGEg ZmV3IE5PUyBpbXBsZW1lbnQgaXQgd2UgY291bGQgcmVtb3ZlIGl0IGFuZCBsZWF2ZSBpdCBmb3Ig YXVnbWVudGF0aW9uIGZvciB0aG9zZSB2ZW5kb3JzIHRoYXQgaW1wbGVtZW50IGl0LiA8bm9uZS8+ IG1lYW5zIHRoYXQgbm8gZmFjaWxpdGllcyBwYXJ0aWNpcGF0ZSBpbiB0aGUgZmlsdGVyIGFuZCB0 aGVyZWZvcmUgdGhlIGZpbHRlciBpcyB0dXJuZWQgb2ZmLg0KDQo8bm9uZS8+IGlzIHVzZWZ1bCB3 aGVuIHlvdSB3YW50IHRvIHR1cm4gb2ZmIGFjdGlvbnMgdGhhdCBkZWZhdWx0IHRvIG9uIChzdWNo IGFzIHRoZSBjb25zb2xlKS4gDQoNCj4NCj4NCj5vICBUaGUgdXNhZ2Ugb2YgdGhlIGluLW1lbW9y eSBsb2cgYnVmZmVyIGlzIGEgYml0IHVuY2xlYXIuICBJIHRoaW5rIHRoZQ0KPiAgIHNwZWMgbmVl ZHMgdG8gZXhwbGFpbiBob3cgdGhpcyBsb2cgYnVmZmVyIGlzIHN1cHBvc2VkIHRvIGJlIHVzZWQu DQo+ICAgUGVyaGFwcyB3ZSBzaG91bGQgYWxzbyBwcm92aWRlIGEgbWVjaGFuaXNtIHRvIHJlYWQg dGhpcyBidWZmZXI/DQo+ICAgSS5lLiwgcHJvdmlkZSBhIGNvbmZpZyBmYWxzZSBsaXN0IG9mIGJ1 ZmZlcmVkIG1lc3NhZ2VzPw0KDQpbY2x5ZGVdIEluLW1lbW9yeSBsb2cgYnVmZmVycyBhcmUgY2ly Y3VsYXIgcXVldWVzIG9mIGxvZyBtZXNzYWdlcy4gTmV0d29yayBlbGVtZW50cyB0aGF0IGNhbiBl eHBlcmllbmNlIGxvZyBtZXNzYWdlIGV2ZW50IHN0b3JtcyB1c2UgaW4tbWVtb3J5IGJ1ZmZlcnMg dG8gYXZvaWQgbG9zcyBvZiBzeXNsb2cgbWVzc2FnZXMuDQoNCj4NCj4NCj5vICBJdCBpcyBpbXBv cnRhbnQgdG8gcmVtZW1iZXIgdGhhdCB0aGUgbmFtZXMgb2YgY2hvaWNlcyBhbmQgY2FzZXMgYXJl DQo+ICAgbm90IHZpc2libGUgaW4gdGhlIGluc3RhbnRpYXRlZCBkYXRhLiAgVGh1cywgd2hlbiB5 b3UgaGF2ZSBuaWNlDQo+ICAgZGVzY3JpcHRpdmUgbmFtZXMgZm9yIHRoZSBjaG9pY2VzIGFuZCBj YXNlcywgYW5kIHRoZXNlIG5hbWVzIGNvbnZleQ0KPiAgIHNvbWUgbWVhbmluZywgdGhpcyBtZWFu aW5nIGlzIGxvc3Qgd2hlbiB5b3UganVzdCBsb29rIGF0IGluc3RhbmNlDQo+ICAgZGF0YS4gIEZv ciBleGFtcGxlLCB0aGlzIGluc3RhbmNlOg0KPg0KPiAgICAgPGNvbnNvbGUtbG9nZ2luZy1hY3Rp b24+DQo+ICAgICAgIDxzZXZlcml0eT53YXJuaW5nPC9zZXZlcml0eT4NCj4gICAgIDwvY29uc29s ZS1sb2dnaW5nLWFjdGlvbj4NCj4NCj4gICBkb2VzIG5vdCBjb252ZXkgdGhlIG1lYW5pbmcgb2Yg dGhlIGNob3NlbiBjYXNlLCB3aGljaCBpcyBjYWxsZWQNCj4gICAibG9nZ2luZy1mYWNpbGl0eS1h bGwiLiAgSS5lLiwgZnJvbSB0aGUgaW5zdGFuY2UgZGF0YSBhYm92ZSB5b3UNCj4gICBjYW5ub3Qg dGVsbCB0aGF0IHdlJ3JlIGFjdHVhbGx5IG1hdGNoaW5nIG9uIGFsbCBmYWNpbGl0aWVzLg0KPg0K PiAgIEkgdGhpbmsgeW91IHNhaWQgeW91IGFyZSBjaGFuZ2luZyB0aGlzIGdyb3VwaW5nIGEgYml0 LCBhbmQgaWYgc28gSQ0KPiAgIHdpbGwgaGF2ZSBhIGxvb2sgaW4gdGhlIG5leHQgcmV2aXNpb24u DQoNCltjbHlkZV0gSSB3aWxsIGV4YW1pbmUgb3VyIHVzZSBvZiBjaG9pY2UvY2FzZSB3aXRoIGFu IGV5ZSB0byByZXdvcmRpbmcgZm9yIGNsYXJpdHkuDQoNCj4NCj4NCj5vICBGb3IgdGhlIHJlbW90 ZSBsb2dnaW5nLCBpdCBzZWVtcyBvbmx5IFVEUCBpcyBzdXBwb3J0ZWQuICBJIHRoaW5rDQo+ICAg dGhlIGRhdGEgbW9kZWwgc2hvdWxkIGZvbGxvdyB0aGUgcmVjb21tZW5kYXRpb24gaW4gc2VjdGlv biAzIGluDQo+ICAgZHJhZnQtc2Nob2Vudy1uZXRtb2QteWFuZy1wYXR0ZXJuLTAwIHNvIHRoYXQg bXVsdGlwbGUgdHJhbnNwb3J0cw0KPiAgIGNhbiBiZSBzdXBwb3J0ZWQuICBNYXliZSB0aGlzIG1v ZGVsIHNob3VsZCBzdXBwb3J0IHRoZSBUTFMgYW5kIERUTFMNCj4gICB0cmFuc3BvcnRzPw0KDQpb Y2x5ZGVdIEkgYWdyZWUgdG8gZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbiBpbiBzZWN0aW9uIDMg b2YgZHJhZnQtc2Nob2Vudy1uZXRtb2QteWFuZy1wYXR0ZXJuLTAwLg0KDQo+DQo+DQo+byAgRm9y IHJlbW90ZSBsb2dnaW5nLCBJIHRoaW5rIHRoZSAidnJmLW5hbWUiIGxlYWYgc2hvdWxkIGJlIHJl bW92ZWQuDQo+ICAgSXQgaXMgbm90IGNsZWFyIGhvdyB0aGlzIG1hcHMgdG8gdGhlIHJvdXRpbmcg d29yaywgYW5kIGl0IGNhbg0KPiAgIGFsd2F5cyBiZSBhdWdtZW50ZWQgbGF0ZXIsIG9yIGEgdmVu ZG9yIGNhbiBkbyBhIHByb3ByaWV0YXJ5DQo+ICAgYXVnbWVudGF0aW9uLg0KDQpbY2x5ZGV9IE11 bHRpcGxlIHZlbmRvcnMgYWRkIFZSRiBuYW1lIHRvIHRoZSBzZXJ2ZXIgY29ubmVjdGlvbiBzcGVj aWZpY2F0aW9uIHNvIHRoYXQgdGhlIGNvcnJlY3Qgcm91dGluZyB0YWJsZSBjYW4gYmUgdXNlZCB0 byBwcm92aWRlIGFjY2VzcyB0aGUgc2VydmVyLiBJIGFtIHN1cnByaXNlZCB0aGF0IFZSRiBpcyBu b3QgaW4geW91ciBiZXN0IHByYWN0aWNlIE91dGJvdW5kIENvbm5lY3Rpb24gcGF0dGVybi4NCg0K Pg0KPm8gIEZvciByZW1vdGUgbG9nZ2luZyBpcyBpdCBhIGdvb2QgaWRlYSB0byBoYXZlICJzb3Vy Y2UtaW50ZXJmYWNlIj8NCj4gICBJZiBzbywgc2hvdWxkIHdlIGhhdmUgdGhpcyBpbiBhbGwgb3Vy IG1vZGVscyBmb3Igb3V0Z29pbmcNCj4gICBjb25uZWN0aW9ucz8NCg0KW2NseWRlXSBzb3VyY2Ut aW50ZXJmYWNlIGlzIGltcGxlbWVudGVkIGJ5IG11bHRpcGxlIHZlbmRvcnMgdG8gZm9yY2UgbG9n IG1lc3NhZ2VzIHRvIGhhdmUgdGhlIHNhbWUgc291cmNlIGluZm9ybWF0aW9uIGluIG91dGdvaW5n IHN5c2xvZyBwYWNrZXRzLiBUaGlzIG1ha2VzIGl0IGVhc2llciBmb3IgdGhlIHJlbW90ZSBzZXJ2 ZXIgdG8gaW1wbGVtZW50IGZpcmV3YWxsIHByb3RlY3Rpb24uDQoNCj4NCj4NCj5vICBsZWFmIGZp bGUtbmFtZSBpcyBzdXBwb3NlZCB0byByZWZlciB0byBhIGxvY2FsIGZpbGUuICBJZiBpbmV0OnVy aQ0KPiAgIGlzIHN1cHBvc2VkIHRvIGJlIHVzZWQsIGl0IHNob3VsZCBzdGF0ZSB0aGF0IHRoaXMg TVVTVCBiZSB3aXRoDQo+ICAgc2NoZW1lICJmaWxlIiAgKGkuZS4sIG9uIHRoZSBmb3JtICJmaWxl Oi4uLiIpLiAgQnV0IGlzIGluZXQ6dXJpIHRoZQ0KPiAgIGNvcnJlY3QgdHlwZSB0byB1c2U/DQoN CltjbHlkZV0gSSB3aWxsIHVwZGF0ZSB0aGUgZGVzY3JpcHRpb24gdG8gaW5kaWNhdGUgdGhhdCB0 aGUgZmlsZSBzY2hlbWUgc2hvdWxkIGJlIHVzZWQuDQoNCj4NCj4NCj5vICBsZWFmIGZpbGUtbnVt YmVyIGhhcyBhIGRlZmF1bHQgb2YgMS4gIElzbid0IHRoaXMgYSBiaXQgc21hbGwgZm9yIGENCj4g ICBmaWxlIGFyY2hpdmU/DQoNCltjbHlkZV0gSSBjaG9zZSAxIChwZXJoYXBzIG5haXZlbHkpIGZv ciB0aG9zZSB2ZW5kb3JzIHRoYXQgZG8gbm90IGltcGxlbWVudCB0aGUgZmlsZS1udW1iZXIgY29u Y2VwdC4gSSB3aWxsIGJlIGhhcHB5IHRvIGNoYW5nZSB0byBhIGNvbnNlbnN1cyBudW1iZXIuDQoN Cj4NCj4NCj5vICBsZWFmIGZpbGUtc2l6ZSBoYXMgYSBkZWZhdWx0IG9mIDI2MjE0NC4gIFdoeSB0 aGlzIG51bWJlcj8NCg0KW2NseWRlXSBUaGVyZSB3YXMgYSBicmllZiBkaXNjdXNzaW9uIG9uIHRo ZSBsaXN0IGFuZCB0aGlzIHNlZW1lZCBsaWtlIGEgZ29vZCB0cmFkZW9mZi4NCg0KPg0KPg0KPm8g IGxlYWYgZmlsZS1wZXJtaXNzaW9uIGhhcyB0aGUgdGVvIHZhbHVlcyAid29ybGQtcmVhZGFibGUi IGFuZA0KPiAgICJuby13b3JsZC1yZWFkYWJsZSIuICBUaGlzIHNlZW1zIGEgYml0IHJlc3RyaWN0 aXZlIGZvciBzb21lIGtpbmRzDQo+ICAgb2Ygc3lzdGVtcywgYW5kIGl0IGlzIGFsc28gdW5kZXJz cGVjaWZpZWQgKHdoYXQgZXhhY3RseSBkb2VzDQo+ICAgIm5vLXdvcmxkLXJlYWRhYmxlIiBtZWFu PykuICBNYXliZSBpdCBpcyBiZXR0ZXIgdG8gbGVhdmUgdGhpcyBvdXQ/DQoNCltjbHlkZV0gTXVs dGlwbGUgdmVuZG9ycyBpbXBsZW1lbnQgYSBiaW5hcnkgc3dpdGNoIGZvciBzeXNsb2cgd29ybGQg cmVhZCBwcm90ZWN0aW9uOiBvbiBmb3IgYW55b25lOyBvZmYgZm9yIG5vLiBJZiB3ZSByZW1vdmUg dGhpcyBhbG1vc3QgZXZlcnkgdmVuZG9yIHdpbGwgaGF2ZSB0byBhZGQgaXQgYmFjayB0aHJvdWdo IGF1Z21lbnRhdGlvbi4gSXQncyBub3QgbWVhbnQgdG8gYmUgYSBnZW5lcmFsIFVuaXggZmlsZS1w ZXJtaXNzaW9uIG1hc2sgdmFsdWUuDQoNCj4NCj4NCj5vICBJIHRoaW5rIHNvbWUgbm9kZXMgY2Fu IGdldCBiZXR0ZXIgbmFtZXMuICBNYXliZToNCj4NCj4gICAgIHN5c2xvZyAvIGxvZy1hY3Rpb25z IC8gZ2xvYmFsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnNvbGUNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgYnVmZmVyDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg IGZpbGUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVtb3RlDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRlcm1pbmFsDQo+DQo+ICAgVGhpcyBhbGxvd3MgZm9yIGZ1dHVyZSBu b2RlcyAobm9uLWFjdGlvbnMpIGRpcmVjdGx5IHVuZGVybmVhdGgNCj4gICAic3lzbG9nIiwgYW5k IGl0IHJlbW92ZXMgdGhlICItbG9nZ2luZy1hY3Rpb24iIHN1ZmZpeCBldmVyeXdoZXJlLg0KDQpb Y2x5ZGVdIEkgd2lsbCBtYWtlIHRoaXMgY2hhbmdlLg0KDQo+DQo+ICAgSSBhbHNvIHN1Z2dlc3Qg eW91IHJlbW92ZSB0aGUgY29udGFpbmVycw0KPiAgICJsb2dnaW5nLWFkdmFuY2VkLWxldmVsLXBy b2Nlc3NpbmciIGFuZCAibG9nZ2luZy1tYXRjaC1wcm9jZXNzaW5nIg0KPiAgIGFuZCBqdXN0IG1v dmUgdGhlaXIgbGVhZnMgdXAgb25lIGxldmVsOg0KPg0KPiAgICAgIGdsb2JhbCAvIGxvZ2dpbmct bGV2ZWwtc2NvcGUgLy4uLg0KPiAgICAgICAgICAgICAgIHNlbGVjdC1tZXNzYWdlLXNldmVyaXR5 DQo+ICAgICAgICAgICAgICAgcGF0dGVybi1tYXRjaA0KDQpbY2x5ZGVdIEFncmVlZC4NCg0KPg0K PiAgIFNvbWUgb3RoZXIgc3VnZ2VzdGlvbnM6DQo+DQo+ICAgICBPTEQ6IGxvZ2dpbmctZmlsZXMN Cj4gICAgIE5FVzogbG9nLWZpbGUgICAobm90ZSBzaW5nbHVhcikNCj4NCj4gICAgIE9MRDogZmls ZS1uYW1lDQo+ICAgICBORVc6IG5hbWUgICAgICAgKHJlbW92ZSByZWR1bmRhbnQgcHJlZml4KQ0K Pg0KPiAgICAgT0xEOiBmaWxlLWxvZ2dpbmctc3RydWN1cmVkLWRhdGENCj4gICAgIE5FVzogc3Ry dWN0dXJlZC1kYXRhIChyZW1vdmUgcmVkdW5kYW50IHByZWZpeCkNCj4NCj4gICAgIE9MRDogZmls ZS1sb2dnaW5nLWFyY2hpdmUNCj4gICAgIE5FVzogZmlsZS1hcmNoaXZlDQo+DQo+ICAgICBPTEQ6 IGZpbGUtbnVtYmVyDQo+ICAgICBORVc6IG51bWJlci1vZi1maWxlcw0KPg0KPiAgICAgT0xEOiBm aWxlLXNpemUNCj4gICAgIE5FVzogbWF4LWZpbGUtc2l6ZQ0KPg0KPiAgICAgT0xEOiByZW1vdGUt bG9nZ2luZy1zdHJ1Y3R1cmVkLWRhdGENCj4gICAgIE5FVzogc3RydWN0dXJlZC1kYXRhIChyZW1v dmUgcmVkdW5kYW50IHByZWZpeCkNCg0KW2NseWRlXSBJIHdpbGwgbWFrZSB0aGVzZSBjaGFuZ2Vz Lg0KDQo+DQo+DQo+byAgSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGUgbGVhZiAic2VsZWN0LW1l c3NhZ2Utc2V2ZXJpdHkiIGlzDQo+ICAgc3VwcG9zZWQgdG8gYmUgdXNlZC4NCg0KSnVlcmdlbiBm ZWx0IHRoYXQgaXQgd2FzIGltcG9ydGFudCB0aGF0IHRoaXMgbW9kZWwgc3VwcG9ydCBMaW51eCBz eXNsb2cgc2VsZWN0b3IgcHJvY2Vzc2luZy4gTGludXggc3lzbG9nIGFkZHMgImVxdWFscyIgYW5k ICJub3QtZXF1YWxzIiBjb21wYXJpc29ucyB0byB0aGUgc3RhbmRhcmQgImVxdWFscy1vci1oaWdo ZXIiIHNldmVyaXR5IGNvbXBhcmlzb24uIFRoaXMgaXMgYSBmZWF0dXJlIGJlY2F1c2Ugbm90IGFs bCBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCB0aGlzLg0KDQo+DQo+DQo+byAgSSB0aGluayBjb250 YWluZXIgc3lzbG9nLXNpZ24gc2hvdWxkIGhhdmU6DQo+DQo+ICAgICByZWZlcmVuY2UNCj4gICAg ICAgIlJGQyA1ODQ4OiBTaWduZWQgU3lzbG9nIE1lc3NhZ2VzIjsNCj4NCj4gICAoWWVzIEkga25v dyB0aGlzIGlzIGFsc28gZGVmaW5lZCBvbiB0aGUgdG9wLWxldmVsLCBidXQgaXQgaXMgbmljZQ0K PiAgIHRvIGhhdmUgdGhlIHJlZmVyZW5jZSBhdmFpbGFibGUgd2hlbiBpdCBpcyB1c2VkLikNCj4N Cj4gICBCVFcgdGhpcyBpcyB0aGUgc3R5bGUgdGhlIFJGQyBlZGl0b3IgcHJlZmVycywgc28geW91 IG1heSB3YW50IHRvDQo+ICAgY2hhbmdlIHRoZSBjdXJyZW50IHRvcC1sZXZlbCByZWZlcmVuY2Ug dG86DQo+DQo+ICAgIHJlZmVyZW5jZQ0KPiAgICAgICJSRkMgNTQyNDogVGhlIFN5c2xvZyBQcm90 b2NvbA0KPiAgICAgICBSRkMgNTg0ODogU2lnbmVkIFN5c2xvZyBNZXNzYWdlcyI7DQoNCltjbHlk ZV0gQWdyZWVkLg0KDQo+DQo+DQo+byAgSSBkb24ndCBrbm93IGFueXRoaW5nIGFib3V0IHNpZ25l ZCBzeXNsb2cgbWVzc2FnZXMsIGJ1dCBhcmUgdGhlc2UNCj4gICBjb25maWcgcGFyYW1zIGFsbCB0 aGF0IGFyZSBuZWVkZWQ/DQoNCltjbHlkZV0gWWVzLCBBbGV4IENsZW1tIHByb3ZpZGVkIHRoZSBs aXN0IGZyb20gdGhlIFJGQy4NCg0KVGhhbmtzLA0KDQpDbHlkZQ0KDQo+DQo+DQo+DQo+L21hcnRp bg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Tue Apr 7 15:08:02 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F671AC3F0 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 15:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6HTa61MOtyn for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 15:07:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.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 BF5A71A92E3 for <netmod@ietf.org>; Tue, 7 Apr 2015 15:07:58 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so53460668lbb.0 for <netmod@ietf.org>; Tue, 07 Apr 2015 15:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xgP2nn7W6rFhSEHX8UoJ+RW2sDPDyaTht6tSQhLh9Zc=; b=Vhpm4FuSZ1KsXIkfOElt7C99b7Go3VXhYmnX14COw9gD2Uii+OhlfrctLur2RtKgav GWpTNIG0YLzzjyZPIB05SfmOT19njtaL41pM+nS+nYa9L7fL8ensM4+C2FrOaH1A+oH2 W807jVBpUnqh7RL37g/rP26fq0R/ZR5JeUYBuLj1g89PHMqSkGWo2fKna2VU75hqPrtF jC6eLkatzH7hmNblK7WuHaocBWTyQHlGjxWwerRfbtL3Tpu4HoEFoIB17FJMFo+plY0R 2pRwZCCjTXnwPNGxkxcXIpQxPfPpM7BKXAyE11OJUfmRh/bcXmLEdb5jJBeGFx1v7F03 dxkg== X-Gm-Message-State: ALoCoQlnsWGmuTJdqOwpvGikeVHOUs9anzUwhNs/0GRoaqVxcwrz7rtk137Jx49D6H+VgKCTHdQa MIME-Version: 1.0 X-Received: by 10.152.42.141 with SMTP id o13mr20448079lal.33.1428444477306; Tue, 07 Apr 2015 15:07:57 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 7 Apr 2015 15:07:57 -0700 (PDT) In-Reply-To: <etPan.55242ff5.519b500d.855@corretto.local> References: <2388671.1428431384540.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <CABCOCHRcMNaQYWppz+Ro1CAgpOz7a-zFA7o3TB35GR+53phLpg@mail.gmail.com> <etPan.55242ff5.519b500d.855@corretto.local> Date: Tue, 7 Apr 2015 15:07:57 -0700 Message-ID: <CABCOCHRcmJ42TgBdLGAcXNhNPCV3GaN=eg1oxGRY0w_COjyZYw@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Rob Shakir <rjs@rob.sh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/JfR-Uv7Q5lR6Et-EA5Z0DR00DH0> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 22:08:01 -0000 On Tue, Apr 7, 2015 at 12:28 PM, Rob Shakir <rjs@rob.sh> wrote: > > On 7 April 2015 at 20:01:56, Andy Bierman (andy@yumaworks.com) wrote: >> > 1) The NETMOD WG decided it was very important to be able >> to represent interfaces that were not configured. The openconfig >> solution does not allow this feature. Only configured interfaces >> would have an 'operational' subtree. The system discovered >> interfaces could not be represented. > > I don=E2=80=99t think this is true. Why can an interface not have interfa= ce[name=3Dsome-interface]/config/X (which has a corresponding interface[nam= e=3Dsome-interface]/state/X) and interface[name=3Dsome-interface]/state/ins= talled =3D false ? > > The =E2=80=98state=E2=80=99 container does not exist underneath the confi= g container in draft-openconfig-netmod-opstate-00. > grouping example-structure { description "top level grouping for the example container -- this is used to put the config and state subtrees in the appropriate location"; container example { description "top-level container for the example data"; container config { uses example-config; } container state { config false; uses example-config; uses example-state; } } } OK -- I see you are just adding 'config' and 'state' containers to everything, and defining the configuration in a grouping so it can be replicated in the 'state' container. If we expect the YANG configuration constraints to always apply to the config=3Dfalse copy, then this approach is mostly harmless. The config-stmt is usually enough for an application to tell which child nodes are config and which are not, so I'm not sure why we need NP containers called 'config' and 'state' everywhere. Does this structure get replicated at each level? In the example-jukebox module in RESTCONF, there is container jukebox { container library { list artist { list album { list song { ... } } } } } Is there supposed to be config and state containers inserted into the resource hierarchy at every level? container jukebox { container config { container library { container config { list artist { container config { list album { container config { list song { container config { ... } container state { ... } } } container state { } } } container state { ... } } container state { ... } } container state { ... } } container state { ... } } container state { ... } } Since these containers have no semantics (just names picked by convention), how does they fit as YANG data resources? What if there are no operational data nodes related each level of config? Should there be an empty 'state' containers? Doesn't the client application need to read and understand the data model to know the "real" config and operational nodes? If so, then relying on thi= s these NP containers is for the benefit of applications that do not know about the YANG data model? > r. Andy From nobody Tue Apr 7 15:13:18 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0091AC432 for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 15:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zpd0-CNWkNL for <netmod@ietfa.amsl.com>; Tue, 7 Apr 2015 15:13:14 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542771AC429 for <netmod@ietf.org>; Tue, 7 Apr 2015 15:13:14 -0700 (PDT) Received: by lagv1 with SMTP id v1so52876261lag.3 for <netmod@ietf.org>; Tue, 07 Apr 2015 15:13:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dikj6T4ED77M+LDX+eRecksEqDAb8NNzhm1Yp0QXVMc=; b=b99g5fG2GLxystKiEbsRlgVwSSNIuLA7/InjZMO+4XY/Zih9vXVc6jLOPqpqOlqLMS /nkMkhoRVFdJFUKriTuzeP77J2AupECV6XPCMY4GzYbfoXcNmnKKqfaKZ9OCM69KhoT/ 17Tq0G+oSPQAkXcAXLO9R3BueuhlhVIZw1qJ1I5MFK6xoxCKO5rRCVgFPVCa46vARu5Z MmJDDw83mlS0sh+7VMQAAx2PIvAqqSeQUp6WPdrn/uQN8Jc67Z0S75wvAa8+qQEEJF15 /CJjzNgp15FX/U/PBku3kIX6E1IisXcI+5xidzGO9QL6jvAMAA/9z9bY2aHza9mQRlNu 44Eg== X-Gm-Message-State: ALoCoQlZJLDLNKgkNEcA7apirNpZhn5Ukwb4TnMBcHzIFKm+3nPiuf7v+imku4kCAi4YRwJoXg5g MIME-Version: 1.0 X-Received: by 10.113.4.105 with SMTP id cd9mr20323838lbd.38.1428444792849; Tue, 07 Apr 2015 15:13:12 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 7 Apr 2015 15:13:12 -0700 (PDT) In-Reply-To: <171379.1428441544263.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> References: <171379.1428441544263.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Tue, 7 Apr 2015 15:13:12 -0700 Message-ID: <CABCOCHQ4TGhTFPNMsTYsKdYEheqL9ydBnrOwP23+c-pKYnWpvA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/3CUBURL_pUKSEKTgyfWDQmlWEj4> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 07 Apr 2015 22:13:17 -0000 On Tue, Apr 7, 2015 at 2:19 PM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > >>From: Andy Bierman >>Sent: Apr 7, 2015 12:01 PM >>To: Randy Presuhn >>Cc: "netmod@ietf.org" >>Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics >> >>Hi, >> >>Maybe it would help if we agreed on the problem that needs to be solved >>rather than dismissing solutions based on our own understanding >>of the priorities. >> >>Using the interfaces model as an example (as done in the >>draft)... >> >> 1) The NETMOD WG decided it was very important to be able >> to represent interfaces that were not configured. The openconfig >> solution does not allow this feature. Only configured interfaces >> would have an 'operational' subtree. The system discovered >> interfaces could not be represented. > > I think being able to provision interfaces in advance of installation > is important. > > I think that withdrawing a line card should not cause its configuration > to disappear. > > I think that a line card replacing another "equivalent" card > should have the configuration of the "old" card applied to > it until/unless management says otherwise. > > I think its important for everything that is manageable to > be visible (modulo access control) regardless of whether > it is provisioned or discovered, and that should include > both operational and non-operational information, to the > extent that the information is available. > > I suspect we're probably in agreement on all of these. > >> 2) Let's say I know that the mtu on 'eth0' is not the >> same as the configured value. What does that mean? >> What am I supposed to do about it? >> I do not agree that merely knowing the operational knob is >> not the same as the configured knob is enough information >> to be actionable. > > Agreed. That's why the configuration and operational knobs > in such a situation are, at least to my mind, distinct pieces > of management information with different semantics. I think > treating them as though they were the "same thing" but in > different data stores is asking for a world of hurt. > > There *is* a relationship; I think folks differ on how (or even > whether) to represent that relationship in the information > model, and the extent to which they believe management applications > could make use of that knowledge. > > I think we're agreed that what's been done so far is a bit > klunky at best. > >>So please describe the problem in enough detail so we >>can decide if there is agreement on anything. We aren't drilling >>holes or smashing nails. Stick to the details of network management >>problems related to operational state. > > I think we're actually in violent agreement, though you and I are > describing it in characteristically different ways. That's > not new. :-) My point is that formulating it as a datastore > problem (or as an extension to the corresponding model/protocol > mechanisms) is really just another attempt at using structure > to solve a problem which is just an instance of a class of > problems which are fundamentally independent of models' structures. > Datastores are conceptual API mechanisms. They may be implemented in the client and server in different ways, such as 1 data structure representing all datastores. They just represent some state in the device. But I agree that an operational datastore by itself would not solve the complex mapping problem. More machine-readable statements would help, assuming we could agree on the details. A new operation like <get-related-operational> would not be limited in returning the same data as named in the config. rpc get-related-operational { description 'Retrieve operational data related to the specified configuration data'; input { leaf target { mandatory true; type instance-identifier; } } output { anyxml data { description 'Represents a container with subtrees of operational data'; } } } An approach like this would punt the complexity to the server, but it does not require the YANG data modeler to be aware of all relevant operational state for all implementations. (An unsolvable problem). Andy > Sticking to "operational state" falls apart if one decides to > slice and dice the information at finer levels of granularity, > e.g. performance statistics, security statistics, throughput, > alarm statuses, etc. If there's just one big bucket of "operational > state", the datastore view is kinda plausible. If finer, potentially > overlapping subcategorization are needed, the datastore view > quickly becomes a mass of spaghetti. The question is whether > application developers or users benefit enough from > having that finer level of granularity represented in models > to make it worth the modeling effort. You know my leanings > on that point, but since I'm not implementing this stuff, I'm > staying officially agnostic. > > It's a tough issue because rigorously specifying the semantic > relationships almost certainly means someone's implementation > would have to change in order to conform to the more fully/precisely > specified semantics. Netconf / Netmod has tried very hard to be > minimally constraining on vendors' implementation, so I think > there's a built-in cultural bias against dealing with these > problems. It's certainly the group's right to stick with this > approach, but that also means that this class of problems will > continue to accrete ad hoc solutions. It's conceivable that > that's the right thing to do, even though I instinctually > recoil from it. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Apr 8 00:28:50 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB331B2A1F for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 00:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c1ffLYgjXPU for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 00:28:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC511A1BF1 for <netmod@ietf.org>; Wed, 8 Apr 2015 00:28:45 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 103C712801A6; Wed, 8 Apr 2015 09:28:44 +0200 (CEST) Date: Wed, 08 Apr 2015 09:28:43 +0200 (CEST) Message-Id: <20150408.092843.1733076946021346521.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <171379.1428441544263.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> References: <171379.1428441544263.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/5CZrvk7Dni2y0I0G2bOAiYynrvc> Cc: netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 07:28:49 -0000 Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > > >From: Andy Bierman > >Sent: Apr 7, 2015 12:01 PM > >To: Randy Presuhn > >Cc: "netmod@ietf.org" > >Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics > > > >Hi, > > > >Maybe it would help if we agreed on the problem that needs to be solved > >rather than dismissing solutions based on our own understanding > >of the priorities. > > > >Using the interfaces model as an example (as done in the > >draft)... > > > > 1) The NETMOD WG decided it was very important to be able > > to represent interfaces that were not configured. The openconfig > > solution does not allow this feature. Only configured interfaces > > would have an 'operational' subtree. The system discovered > > interfaces could not be represented. > > I think being able to provision interfaces in advance of installation > is important. > > I think that withdrawing a line card should not cause its configuration > to disappear. > > I think that a line card replacing another "equivalent" card > should have the configuration of the "old" card applied to > it until/unless management says otherwise. > > I think its important for everything that is manageable to > be visible (modulo access control) regardless of whether > it is provisioned or discovered, and that should include > both operational and non-operational information, to the > extent that the information is available. > > I suspect we're probably in agreement on all of these. Agreed. > > 2) Let's say I know that the mtu on 'eth0' is not the > > same as the configured value. What does that mean? > > What am I supposed to do about it? > > I do not agree that merely knowing the operational knob is > > not the same as the configured knob is enough information > > to be actionable. > > Agreed. That's why the configuration and operational knobs > in such a situation are, at least to my mind, distinct pieces > of management information with different semantics. I think > treating them as though they were the "same thing" but in > different data stores is asking for a world of hurt. I certainly agree, and this is why we ended up with the model we have in ietf-interfaces. Note that when I suggested to use a separate datastore, it was in order to solve *one specific* problem described in draft-openconfig-netmod-opstate-00. But it might be that I have misunderstood the problem description. They talk about "intended configuration" and "running configuration": o Where the application of a change is asynchronous - due to system operations, or a pre-requisite for another event to occur before the configuration value is applied (e.g., a protocol session restart) - then the intended configuration value may not determine whether the configuration has been committed to the running configuration; or whether the pre-requisite event has occurred. They also talk about asynchronous changes being a property of the implementation, rather than the modelled data (see section 2). And this is probably where there is some confusion. So instead of speculating further, could someone explain if sync/async is supposed to be a property of the implementation (in which case I beleive a separate datastore could be solution) or of the data (like in ietf-interfaces (where a separate datastore does not work)). > There *is* a relationship; I think folks differ on how (or even > whether) to represent that relationship in the information > model Right. So draft-openconfig-netmod-opstate-00 proposes that this relationship is defined by the data structure using naming conventions. Andy showed an alternative with an explicit statement. > and the extent to which they believe management applications > could make use of that knowledge. Yes, this is not entirely clear to me. I can certainly see how a human user could ask for "all related info" and process that data. But it is not clear how a program (nms/orchestrator/controller/...) can use this information, without knowing what it is looking for. /martin > I think we're agreed that what's been done so far is a bit > klunky at best. > > >So please describe the problem in enough detail so we > >can decide if there is agreement on anything. We aren't drilling > >holes or smashing nails. Stick to the details of network management > >problems related to operational state. > > I think we're actually in violent agreement, though you and I are > describing it in characteristically different ways. That's > not new. :-) My point is that formulating it as a datastore > problem (or as an extension to the corresponding model/protocol > mechanisms) is really just another attempt at using structure > to solve a problem which is just an instance of a class of > problems which are fundamentally independent of models' structures. > > Sticking to "operational state" falls apart if one decides to > slice and dice the information at finer levels of granularity, > e.g. performance statistics, security statistics, throughput, > alarm statuses, etc. If there's just one big bucket of "operational > state", the datastore view is kinda plausible. If finer, potentially > overlapping subcategorization are needed, the datastore view > quickly becomes a mass of spaghetti. The question is whether > application developers or users benefit enough from > having that finer level of granularity represented in models > to make it worth the modeling effort. You know my leanings > on that point, but since I'm not implementing this stuff, I'm > staying officially agnostic. > > It's a tough issue because rigorously specifying the semantic > relationships almost certainly means someone's implementation > would have to change in order to conform to the more fully/precisely > specified semantics. Netconf / Netmod has tried very hard to be > minimally constraining on vendors' implementation, so I think > there's a built-in cultural bias against dealing with these > problems. It's certainly the group's right to stick with this > approach, but that also means that this class of problems will > continue to accrete ad hoc solutions. It's conceivable that > that's the right thing to do, even though I instinctually > recoil from it. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Apr 8 02:05:02 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82711A1A6A for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 02:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgK-IY2uL4RO for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 02:04:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1914E1A1A38 for <netmod@ietf.org>; Wed, 8 Apr 2015 02:04:57 -0700 (PDT) Received: from localhost (unknown [172.29.2.201]) by trail.lhotka.name (Postfix) with ESMTPSA id 7F9351CC039A; Wed, 8 Apr 2015 11:04:57 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: Andy Bierman <andy@yumaworks.com>, Rob Shakir <rjs@rob.sh> In-Reply-To: <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> References: <CAJK7ZqLUrgoD41Nw22A3XYdOKbFDA231bSwQTLano2p42EEDkw@mail.gmail.com> <20150406.201034.2144200870415437057.mbj@tail-f.com> <etPan.5523ba73.1190cde7.855@corretto.local> <20150407.133423.2269546106879658417.mbj@tail-f.com> <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 08 Apr 2015 11:04:52 +0200 Message-ID: <m2oamz6le3.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/_77lyqcw9qt9AI7v4x02dXLpGro> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 09:05:01 -0000 Andy Bierman <andy@yumaworks.com> writes: > On Tue, Apr 7, 2015 at 4:52 AM, Rob Shakir <rjs@rob.sh> wrote: >> >> On 7 April 2015 at 12:34:56, Martin Bjorklund (mbj@tail-f.com) wrote: >>> >>> When you rely on conventions, different modules may have different >>> conventions. Thus, consumers have to adapt to all different >>> conventions present in the systems they want to manage. Compare this >>> with having a separate datastore for "actual config". With such a >>> datastore, the consumer can get the intended and actual config in >>> exactly the same way across implementations, for all data models. >>> >>> Why is this idea not taking the consumer's perspective into account? >> >> I think it is =E2=80=94 and actually, it was the one that I originally f= avoured. :-) >> >> If you look at https://docs.google.com/viewer?a=3Dv&pid=3Dsites&srcid=3D= ZGVmYXVsdGRvbWFpbnxvcGVuY29uZmlnbmV0fGd4OjQ5ZjdlMmY4YmQxYWZhNTI [0] slide 5= , then we even documented this as one of the preferred two solutions that w= e had. Essentially, the logical split (to me) is: >> >> a) outside of the path =E2=80=94 which is what you are proposing with da= tastores. we can then always just check the datastore in question to find i= ntended vs. actual vs. state. >> b) at the very end of the path =E2=80=94 which is the proposal that is b= eing made in draft-openconfig-netmod-opstate >> >> The problems we noted with this approach were: >> >> 1. To the audience reviewing it (and conversations with experts, includi= ng yourself, I believe) the concept of datastores was very tightly coupled = with NETCONF. It seemed that the lack of inclusion of datastore support (as= far as I read) in RESTCONF indicated that even within the IETF net{conf,mo= d}-defined protocols, we cannot rely on support for datastores in the proto= col. >> > > This is wrong. Datastores are not tightly coupled to NETCONF. I think they are, and not only due to the particular wording in RFC 6020. For instance, it is IMO incorrect to interpret config true/false simply as RW/RO. Sec. 7.19.1 in RFC 6020 makes it very clear that "config true" nodes are part of NETCONF configuration datastores. This in turn implies certain semantics, e.g. that the data can be locked, and RFC 6241 is also very clear about locking semantics: Additionally, the system will ensure that these locked configuration resources will not be modified by other non-NETCONF management operations such as SNMP and CLI. > RESTCONF works with NETCONF without being a clone of NETCONF. > You cannot rely on RESTCONF because it is still an I-D. > This process argument is the weakest of all. > > >> 2. Some approach allowing the augmentation of a model within an individu= al datastore would be required. This seems very similar to the operational:= true flag, that we proposed. However, if such an extension is not supporte= d by a device then we do not have the advantage that we can still get all o= f the different leaves (actual/intended/state) since they are duplicated. > > > Why is this needed? > Your approach of duplicating the config tree under itself as operational = data > does not support this approach. Duplicating data is expensive. > IMO too expensive for the small amount of value it provides. > > There are 3 main concerns I have with replicating config as operational s= tate > > 1) makes modules much harder to read. I do not agree that modules will be > easier to use, once they are much harder to read. > > 2) there is an assumption that all config can be over-ridden by operation= al > state, Even in the minority of cases where this is true, just knowing t= he > different value is not enough. Is it OK that the config and operational > values differ? How did the operational value become different? Is this > a temporary issue? What config knobs would change the operational value? > None of these questions are answered by merely replicating config as > state. Such questions are hard to answer because RFC 6241 is rather vague about the semantics of NETCONF datastores and their interaction with the rest of the system. I think the basic assumption was that the contents of running are what's used operationally. Perhaps this can be guaranteed on closed systems where all software is controlled by a single vendor - the user then isn't given access to the underlying operating system, and all configuration interfaces (CLI, SNMP) are built on top of the NETCONF datastores. However, on more open systems this assumption doesn't work. A trivial example: consider a server or router based on Linux/*BSD that uses NETCONF and implements the ietf-system module. Anytime, an admin can log in and use the "hostname" command so that the hostname that's actually used differs from the value in sys:hostname. That change is for sure ephemeral but is it also temporary - i.e., is something expected to happen before reboot? In fact, NETCONF clients are even unable to learn about the change because sys:hostname has no counterpart in state data. > > 3) The YANG constraints are not designed to be relocated from config to s= tate. > All of the YANG constraints still apply when moved, only they apply to > the config=3Dfalse version, which may or may not be correct. But it is the operational state where the constraints really matter. > > IMO, the only tool being abused here is cut-and-paste YANG. > An operational datastore or protocol operations to retrieve > the operational values of config=3Dtrue nodes would not have these > problems. I think a very good model for the operational datastore is the /proc filesystem. But we still have the problem that config data needn't always exactly mirror the state. Lada > >> >> I understand that we are not making pretty YANG (and hey, I did a refact= or of the BGP YANG model to support this approach, so I understand the mode= ller=E2=80=99s pain) - but quite frankly, we *HAVE* to prioritise actually = meeting the requirements that we abstracted this to. [1] >> >> Cheers, >> r. >> > > > Andy > >> >> [0]: Apologies for the unwieldy Google Docs link, I uploaded the PDF at = http://www.openconfig.net/file-cabinet/Modelling-Operational-State.pdf?attr= edirects=3D0&d=3D1. >> >> [1]: Of course, I cannot claim that these requirements are complete *for= all operators*, but amongst the folks that talked about this - we thought = that these were a reasonable set of requirements. Indeed, we iterated them = quite a lot based on feedback. >> >> _______________________________________________ >> 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, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 8 03:12:15 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B491B2F0D for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 03:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0ZKxs760_aL for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 03:12:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 414AA1B2F0B for <netmod@ietf.org>; Wed, 8 Apr 2015 03:12:11 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 34D4D1280AC6; Wed, 8 Apr 2015 12:12:10 +0200 (CEST) Date: Wed, 08 Apr 2015 12:12:09 +0200 (CEST) Message-Id: <20150408.121209.2229937792289064739.mbj@tail-f.com> To: cwildes@cisco.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> References: <20150402.144231.1437388601493142848.mbj@tail-f.com> <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/iKXkMx4nx2FngrkKzXCEcBWJDTA> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 10:12:13 -0000 Hi, "Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote: > On 4/2/15, 5:42 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > >o Given that the standard defines a fixed set of 24 facilities, it > > seems odd that the facilities are modelled as identities, and not > > as an enumeration. Using identities gives the impression that this > > is an extensible set of values. > > [clyde] A number of vendors need to augment the list of facilities - > some with several hundred additional facilities. How does this even work, given that the PRIVAL is encoded with 3 digits? It seems to me that the maximum possible facility value is 124. > Please suggest an > alternative coding that can be used to add facilities through > augmentation. Is it that we should have two separate facility fields: > RFC 5424 (0-24) and Vendor Specific starting at 24? One option could be to do: typedef facility { type union { type enumeration { enum kern { value 0; } ... enum local8 { value 23; } } type uint16 { range "24..124"; // or 0..999 } } } It is not clear to me if this is allowed by RFC 5424. It says that: Facility and Severity values are not normative but often used But then it also says: Facility values MUST be in the range of 0 to 23 inclusive So if we allow other facilities, shouldn't we also allow other serverities? Or should we allow them to configure prival 0..999? > >o Why do we have these: > > > > feature file-logging-structured-data > > > > feature remote-logging-structured-data > > > > I would assume that if the device supports structured data, it would > > do so regardless of logging method? I.e., a single feature > > "structured-data" would be enough? > > > > But is this (structured data) typically configurable in > > implementations, and if it is, it is configurable per "action" like > > this? > > [clyde] The history of this is that we agreed to support > file-logging-structured-data as a feature (currently implemented by > JUNOS) since it is called out in RFC 5424. Then someone (at the Hawaii > meeting) asked, if we support structured data for files, why not > support for remote logging too? Although I do not know of anyone who > has implemented this, I agreed to support it for remote logging as a > separate feature. We are talking about two different functionalities > here. Perhaps the best solution is to remove remote-logging structured > data and let it be supported through augmentation should anyone > require it in the future. Let me take one step back. What exactly does it mean to: log messages to a file in structured-data format as per RFC 5424 RFC 5424 defines the format of a syslog message, with the rule "SYSLOG-MSG". This message format contains structured data. So if you have not enabled structured data (with your model), what is the expected format of the message? Does it still contain the HEADER as defined in 5424, or just some message format (maybe as exaplained in RFC 3164)? > >o I do not understand what the global-logging-action does. The > > description says: > > > > Global logging represents the ability to > > perform global log message suppression. > > > > Does this mean that the global level *suppresses* matching > > messages? > > > > The text talks about "group level suppression", but the model has > > "global logging action". This is a bit confusing. > > > > So what does this configuration mean: > > > > <global-logging-action> > > <none/> > > </global-logging-action> > > > > Does it means that no messages are suppressed, or that all messages > > are suppressed? > > [clyde] Global logging is a first level suppression filter. Please see > the diagram in the RFC. Given that only a few NOS implement it we > could remove it and leave it for augmentation for those vendors that > implement it. <none/> means that no facilities participate in the > filter and therefore the filter is turned off. Ok. My point is that the text is unclear. But if you remove this that problem goes aways ;-) > <none/> is useful when you want to turn off actions that default to on > (such as the console). > > > > > > >o The usage of the in-memory log buffer is a bit unclear. I think the > > spec needs to explain how this log buffer is supposed to be used. > > Perhaps we should also provide a mechanism to read this buffer? > > I.e., provide a config false list of buffered messages? > > [clyde] In-memory log buffers are circular queues of log > messages. Network elements that can experience log message event > storms use in-memory buffers to avoid loss of syslog messages. This doesn't answer my question - how is the buffer supposed to be used? > >o For remote logging, I think the "vrf-name" leaf should be removed. > > It is not clear how this maps to the routing work, and it can > > always be augmented later, or a vendor can do a proprietary > > augmentation. > > [clyde} Multiple vendors add VRF name to the server connection > specification so that the correct routing table can be used to provide > access the server. I am surprised that VRF is not in your best > practice Outbound Connection pattern. The reason is that how to handle this is ongoing work in the routing config. When that work, we can/need to revisit this. But if we add something now, there's a risk that what we do do not fit into their work. > >o leaf file-number has a default of 1. Isn't this a bit small for a > > file archive? > > [clyde] I chose 1 (perhaps naively) for those vendors that do not > implement the file-number concept. I will be happy to change to a > consensus number. What happens when all files are full? I think the text needs to specify this. > >o I don't understand how the leaf "select-message-severity" is > > supposed to be used. > > Juergen felt that it was important that this model support Linux > syslog selector processing. Linux syslog adds "equals" and > "not-equals" comparisons to the standard "equals-or-higher" severity > comparison. This is a feature because not all implementations support > this. Fine, but my point is that the text needs to better explain (more specific) how it is supposed to work. For example it says: enum equals { description "This leaf specifies all messages for the specified severity."; } It says "This leaf", but probably mean "This value". What exactly is "the specified severity". /martin From nobody Wed Apr 8 04:34:39 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A1B1B3022 for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 04:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yop440HnZ3QU for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 04:34:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25EBC1B3019 for <netmod@ietf.org>; Wed, 8 Apr 2015 04:34:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8417AF6B; Wed, 8 Apr 2015 13:34:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hXYyVy2sj0ui; Wed, 8 Apr 2015 13:34:17 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Apr 2015 13:34:31 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94F722002C; Wed, 8 Apr 2015 13:34:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YwpyXRHvqMtK; Wed, 8 Apr 2015 13:34:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2801C20013; Wed, 8 Apr 2015 13:34:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0292D32BB372; Wed, 8 Apr 2015 13:34:29 +0200 (CEST) Date: Wed, 8 Apr 2015 13:34:29 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Martin Bjorklund <mbj@tail-f.com> Message-ID: <20150408113429.GA23505@elstar.local> Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, cwildes@cisco.com, netmod@ietf.org References: <20150402.144231.1437388601493142848.mbj@tail-f.com> <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150408.121209.2229937792289064739.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/2o_55RWm71Tn37UekPT9IGv79co> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 11:34:37 -0000 On Wed, Apr 08, 2015 at 12:12:09PM +0200, Martin Bjorklund wrote: > Hi, > > "Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote: > > On 4/2/15, 5:42 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > > >o Given that the standard defines a fixed set of 24 facilities, it > > > seems odd that the facilities are modelled as identities, and not > > > as an enumeration. Using identities gives the impression that this > > > is an extensible set of values. > > > > [clyde] A number of vendors need to augment the list of facilities - > > some with several hundred additional facilities. > > How does this even work, given that the PRIVAL is encoded with 3 > digits? It seems to me that the maximum possible facility value is > 124. RFC 5424 essentially says that PRI is limted to the range 0 .. 191 and that PRI = FACILITY * 8 + SEVERITY This limits SEVERITY to 0..8 and FACILITY to 0..23. If implementations have more facilities, then they need to map them to on of the 24 facility values the SYSLOG protocol supports (or they do not talk SYSLOG). > So if we allow other facilities, shouldn't we also allow other > serverities? Since there must be a mapping if this some other proprietary logging protocol is shipped over SYSLOG, I think it would make sense to expose the mapping of this prorietary protocol into the SYSLOG number space. (The SYSLOG specification is rather clear about the the limits, not only RFC 5424 but also RFC 3164.) Anyway, since we are talking of mapping proprietary logging protocols to SYSLOG, perhaps it makes sense to leave this mapping for vendor augmentations? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Wed Apr 8 04:51:53 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57981B3055 for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 04:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B2NcNVhlBes for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 04:51:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2976F1B3054 for <netmod@ietf.org>; Wed, 8 Apr 2015 04:51:50 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 13D651280A55; Wed, 8 Apr 2015 13:51:49 +0200 (CEST) Date: Wed, 08 Apr 2015 13:51:48 +0200 (CEST) Message-Id: <20150408.135148.1756819020106542320.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150408113429.GA23505@elstar.local> References: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> <20150408113429.GA23505@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/3WLG_6nCjHgl2--fSqq4kfH_Z14> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 11:51:51 -0000 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Apr 08, 2015 at 12:12:09PM +0200, Martin Bjorklund wrote: > > Hi, > > > > "Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote: > > > On 4/2/15, 5:42 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > > > >o Given that the standard defines a fixed set of 24 facilities, it > > > > seems odd that the facilities are modelled as identities, and not > > > > as an enumeration. Using identities gives the impression that this > > > > is an extensible set of values. > > > > > > [clyde] A number of vendors need to augment the list of facilities - > > > some with several hundred additional facilities. > > > > How does this even work, given that the PRIVAL is encoded with 3 > > digits? It seems to me that the maximum possible facility value is > > 124. > > RFC 5424 essentially says that PRI is limted to the range 0 .. 191 Aha, I didn't see the comment about the range. I think RFC 5424 is a bit unclear. It says: Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Facility values MUST be in the range of 0 to 23 inclusive. It says that the facility *values* are not normative, but then that the *values* are 0..23. Does it means that the *interpretation* of the values is non-normative? > This limits SEVERITY to 0..8 and FACILITY to 0..23. If implementations > have more facilities, then they need to map them to on of the 24 > facility values the SYSLOG protocol supports (or they do not talk > SYSLOG). Right, I have seen implementations use other names for (some of) the 24 facilities. But it was stated that some implementations have several hundreds of facilities. I do not understand how that works. /martin From nobody Wed Apr 8 05:05:25 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2187B1B306E for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 05:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR7Tg6t0BWD6 for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 05:05:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DAE1B3091 for <netmod@ietf.org>; Wed, 8 Apr 2015 05:05:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 52F941013; Wed, 8 Apr 2015 14:05:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Dudl-DdIpg4s; Wed, 8 Apr 2015 14:04:53 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Apr 2015 14:05:07 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83E5A2002B; Wed, 8 Apr 2015 14:05:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A9PwOGWk7_W3; Wed, 8 Apr 2015 14:05:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 856F220013; Wed, 8 Apr 2015 14:05:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7944A32BB44A; Wed, 8 Apr 2015 14:05:06 +0200 (CEST) Date: Wed, 8 Apr 2015 14:05:06 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Martin Bjorklund <mbj@tail-f.com> Message-ID: <20150408120506.GC23608@elstar.local> Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, cwildes@cisco.com, netmod@ietf.org References: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> <20150408113429.GA23505@elstar.local> <20150408.135148.1756819020106542320.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150408.135148.1756819020106542320.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/F5dTt-fTvCSTxqyHkw64-ZckDik> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 12:05:25 -0000 On Wed, Apr 08, 2015 at 01:51:48PM +0200, Martin Bjorklund wrote: > > > > RFC 5424 essentially says that PRI is limted to the range 0 .. 191 > > Aha, I didn't see the comment about the range. > > I think RFC 5424 is a bit unclear. It says: > > Facility and Severity values are not normative but often used. They > are described in the following tables for purely informational > purposes. Facility values MUST be in the range of 0 to 23 > inclusive. > > It says that the facility *values* are not normative, but then that > the *values* are 0..23. > > Does it means that the *interpretation* of the values is > non-normative? Yes, this is how I understand it. The interpretation listed is a common UNIX interpretation but there could be others. The numeric value space is however clearly fixed. > > This limits SEVERITY to 0..8 and FACILITY to 0..23. If implementations > > have more facilities, then they need to map them to on of the 24 > > facility values the SYSLOG protocol supports (or they do not talk > > SYSLOG). > > Right, I have seen implementations use other names for (some of) the > 24 facilities. But it was stated that some implementations have > several hundreds of facilities. I do not understand how that works. It can only work by mapping the larget set to a smaller set. For example, my local implementation might have a specific value for an NTP daemon and a different specific value for a cron daemon but once I send a SYSLOG message, both might map to the numeric code 3 commonly interpreted as "system daemons". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Wed Apr 8 05:27:02 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEB41B30BB for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 05:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7wO51qWS8_B for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 05:26:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 961E11B30B5 for <netmod@ietf.org>; Wed, 8 Apr 2015 05:26:59 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id C27141280A55; Wed, 8 Apr 2015 14:26:58 +0200 (CEST) Date: Wed, 08 Apr 2015 14:26:58 +0200 (CEST) Message-Id: <20150408.142658.537049303755832318.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150408120506.GC23608@elstar.local> References: <20150408113429.GA23505@elstar.local> <20150408.135148.1756819020106542320.mbj@tail-f.com> <20150408120506.GC23608@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/IZONcWYOLve63KqEnDwh4QwcaL0> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 12:27:01 -0000 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Apr 08, 2015 at 01:51:48PM +0200, Martin Bjorklund wrote: > > > This limits SEVERITY to 0..8 and FACILITY to 0..23. If implementations > > > have more facilities, then they need to map them to on of the 24 > > > facility values the SYSLOG protocol supports (or they do not talk > > > SYSLOG). > > > > Right, I have seen implementations use other names for (some of) the > > 24 facilities. But it was stated that some implementations have > > several hundreds of facilities. I do not understand how that works. > > It can only work by mapping the larget set to a smaller set. For > example, my local implementation might have a specific value for an > NTP daemon and a different specific value for a cron daemon but once I > send a SYSLOG message, both might map to the numeric code 3 commonly > interpreted as "system daemons". The question is if this is common enough so we should support it. If it is common and we use an enum as facility, then this syslog model is not as useful as it could be. Suppose an implementation has "many" (>>23) facilities. In this case it seems it would be useful to be able filter on the implementation-specific facility, rather than the standard facility. One way to handle this is actually to use identities, but let the vendor-specific identities be derived from the standard ones, for example: module my-module { ... identity ntp { base syslog:daemon; } identity cron { base syslog:daemon; } } This way you can filter on the very specific identity (or the standard), and the mapping to standard facilities is well defined. /martin From nobody Wed Apr 8 06:56:33 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD41A8790 for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 06:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVIhabarNTTs for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 06:56:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DB51A879F for <netmod@ietf.org>; Wed, 8 Apr 2015 06:56:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AD2698E4; Wed, 8 Apr 2015 15:56:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id j62lrE3wP70h; Wed, 8 Apr 2015 15:56:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Apr 2015 15:56:26 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BA9D2002B; Wed, 8 Apr 2015 15:56:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9p_OFOM0DNBb; Wed, 8 Apr 2015 15:56:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65B0020013; Wed, 8 Apr 2015 15:56:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B280032BB531; Wed, 8 Apr 2015 15:56:24 +0200 (CEST) Date: Wed, 8 Apr 2015 15:56:24 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Martin Bjorklund <mbj@tail-f.com> Message-ID: <20150408135624.GA23938@elstar.local> Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, cwildes@cisco.com, netmod@ietf.org References: <20150408113429.GA23505@elstar.local> <20150408.135148.1756819020106542320.mbj@tail-f.com> <20150408120506.GC23608@elstar.local> <20150408.142658.537049303755832318.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150408.142658.537049303755832318.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/bx5V1teafsyr-wIYBU3OHqF5kB0> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 13:56:32 -0000 On Wed, Apr 08, 2015 at 02:26:58PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > On Wed, Apr 08, 2015 at 01:51:48PM +0200, Martin Bjorklund wrote: > > > > > This limits SEVERITY to 0..8 and FACILITY to 0..23. If implementations > > > > have more facilities, then they need to map them to on of the 24 > > > > facility values the SYSLOG protocol supports (or they do not talk > > > > SYSLOG). > > > > > > Right, I have seen implementations use other names for (some of) the > > > 24 facilities. But it was stated that some implementations have > > > several hundreds of facilities. I do not understand how that works. > > > > It can only work by mapping the larget set to a smaller set. For > > example, my local implementation might have a specific value for an > > NTP daemon and a different specific value for a cron daemon but once I > > send a SYSLOG message, both might map to the numeric code 3 commonly > > interpreted as "system daemons". > > The question is if this is common enough so we should support it. > > If it is common and we use an enum as facility, then this syslog model > is not as useful as it could be. Suppose an implementation has "many" > (>>23) facilities. In this case it seems it would be useful to be > able filter on the implementation-specific facility, rather than the > standard facility. > > One way to handle this is actually to use identities, but let the > vendor-specific identities be derived from the standard ones, for > example: > > module my-module { > ... > > identity ntp { > base syslog:daemon; > } > > identity cron { > base syslog:daemon; > } > } > > This way you can filter on the very specific identity (or the > standard), and the mapping to standard facilities is well defined. > This is a good proposal. This requires good text to encourage vendors to actually derive identities this way - they might by default create their own hierarchy of identifies... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Wed Apr 8 07:06:09 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DB91AC3CB for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 07:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcTvjAkFID20 for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 07:06:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B3DF41A9236 for <netmod@ietf.org>; Wed, 8 Apr 2015 07:06:03 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id C04FE1280AC6; Wed, 8 Apr 2015 16:06:02 +0200 (CEST) Date: Wed, 08 Apr 2015 16:06:02 +0200 (CEST) Message-Id: <20150408.160602.2208597130537057736.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150408135624.GA23938@elstar.local> References: <20150408120506.GC23608@elstar.local> <20150408.142658.537049303755832318.mbj@tail-f.com> <20150408135624.GA23938@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/IMFEG19b7gI9RXlHqpf267chj1c> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 14:06:08 -0000 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Apr 08, 2015 at 02:26:58PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Apr 08, 2015 at 01:51:48PM +0200, Martin Bjorklund wrote: > > > > > > > This limits SEVERITY to 0..8 and FACILITY to 0..23. If implementations > > > > > have more facilities, then they need to map them to on of the 24 > > > > > facility values the SYSLOG protocol supports (or they do not talk > > > > > SYSLOG). > > > > > > > > Right, I have seen implementations use other names for (some of) the > > > > 24 facilities. But it was stated that some implementations have > > > > several hundreds of facilities. I do not understand how that works. > > > > > > It can only work by mapping the larget set to a smaller set. For > > > example, my local implementation might have a specific value for an > > > NTP daemon and a different specific value for a cron daemon but once I > > > send a SYSLOG message, both might map to the numeric code 3 commonly > > > interpreted as "system daemons". > > > > The question is if this is common enough so we should support it. > > > > If it is common and we use an enum as facility, then this syslog model > > is not as useful as it could be. Suppose an implementation has "many" > > (>>23) facilities. In this case it seems it would be useful to be > > able filter on the implementation-specific facility, rather than the > > standard facility. > > > > One way to handle this is actually to use identities, but let the > > vendor-specific identities be derived from the standard ones, for > > example: > > > > module my-module { > > ... > > > > identity ntp { > > base syslog:daemon; > > } > > > > identity cron { > > base syslog:daemon; > > } > > } > > > > This way you can filter on the very specific identity (or the > > standard), and the mapping to standard facilities is well defined. > > > > This is a good proposal. This requires good text to encourage vendors > to actually derive identities this way - they might by default create > their own hierarchy of identifies... Right; what we want to avoid is someone deriving directly from syslog:syslog-facility. We can probably simply say MUST NOT do this. So what happens if someone does it anyway? I think it just means that a 3rd party client will not understand what's going on... /martin From nobody Wed Apr 8 15:27:58 2015 Return-Path: <cwildes@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DD41A9075 for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 15:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VlrClg_9enm for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 15:27:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE051A9071 for <netmod@ietf.org>; Wed, 8 Apr 2015 15:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11082; q=dns/txt; s=iport; t=1428532074; x=1429741674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZAgprWcaeN+1HjI8sLHiTBP9FMlMvSESfTeJUv6ak8c=; b=cgimrm2973U99TCvIIXnwKf0TZ2hbt/tTBmkw8kL9T+7vVLcw8iM3L60 AXISAVNN3LcjdR+vqmZzsBlH5KMwB5INYJIUe+iaZLHb24YjvqnLp5sRs WTkXWZpX769H5n8CC8njumIVGWae8ZvPWAxVNHeTMDJ644J27WooQU/Vd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7BQB4qiVV/49dJa1cgwiBLgWDEMBgh08CHIEPOhIBAQEBAQEBfYQgAQEEIxFFEAIBCA4KAgImAgICMBUQAgQOBRuID7ZZllkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJC3+EMUsHgmgvgRYFkHSKB4EdgzeCY4lag0oig29vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,546,1422921600"; d="scan'208";a="139447160" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP; 08 Apr 2015 22:27:53 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t38MRr3N022671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Apr 2015 22:27:53 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.15]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 8 Apr 2015 17:27:53 -0500 From: "Clyde Wildes (cwildes)" <cwildes@cisco.com> To: Martin Bjorklund <mbj@tail-f.com> Thread-Topic: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Thread-Index: AQHQbUJudYHdDoBQEEyPBz3VYG8aJ51CAAMAgAFCO4CAAFg2AA== Date: Wed, 8 Apr 2015 22:28:03 +0000 Message-ID: <9E933BD9-E257-45F5-B055-CCA24BAA8F1F@cisco.com> References: <20150402.144231.1437388601493142848.mbj@tail-f.com> <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> In-Reply-To: <20150408.121209.2229937792289064739.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.157.242] Content-Type: text/plain; charset="utf-8" Content-ID: <D92EB20CD8B6204587CED2A5B0E96C99@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/uafezGWcts_vs3QXW9SFi_4jFsY> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 08 Apr 2015 22:27:57 -0000 SGkgTWFydGluLA0KDQpNeSByZXNwb25zZXMgaW5saW5lLi4uDQoNCg0KDQpPbiA0LzgvMTUsIDM6 MTIgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KDQo+SGks DQo+DQo+IkNseWRlIFdpbGRlcyAoY3dpbGRlcykiIDxjd2lsZGVzQGNpc2NvLmNvbT4gd3JvdGU6 DQo+PiBPbiA0LzIvMTUsIDU6NDIgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5j b20+IHdyb3RlOg0KPj4gPm8gIEdpdmVuIHRoYXQgdGhlIHN0YW5kYXJkIGRlZmluZXMgYSBmaXhl ZCBzZXQgb2YgMjQgZmFjaWxpdGllcywgaXQNCj4+ID4gICBzZWVtcyBvZGQgdGhhdCB0aGUgZmFj aWxpdGllcyBhcmUgbW9kZWxsZWQgYXMgaWRlbnRpdGllcywgYW5kIG5vdA0KPj4gPiAgIGFzIGFu IGVudW1lcmF0aW9uLiAgVXNpbmcgaWRlbnRpdGllcyBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0 IHRoaXMNCj4+ID4gICBpcyBhbiBleHRlbnNpYmxlIHNldCBvZiB2YWx1ZXMuDQo+PiANCj4+IFtj bHlkZV0gQSBudW1iZXIgb2YgdmVuZG9ycyBuZWVkIHRvIGF1Z21lbnQgdGhlIGxpc3Qgb2YgZmFj aWxpdGllcyAtDQo+PiBzb21lIHdpdGggc2V2ZXJhbCBodW5kcmVkIGFkZGl0aW9uYWwgZmFjaWxp dGllcy4NCj4NCj5Ib3cgZG9lcyB0aGlzIGV2ZW4gd29yaywgZ2l2ZW4gdGhhdCB0aGUgUFJJVkFM IGlzIGVuY29kZWQgd2l0aCAzDQo+ZGlnaXRzPyAgSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgbWF4 aW11bSBwb3NzaWJsZSBmYWNpbGl0eSB2YWx1ZSBpcw0KPjEyNC4NCj4NCj4+IFBsZWFzZSBzdWdn ZXN0IGFuDQo+PiBhbHRlcm5hdGl2ZSBjb2RpbmcgdGhhdCBjYW4gYmUgdXNlZCB0byBhZGQgZmFj aWxpdGllcyB0aHJvdWdoDQo+PiBhdWdtZW50YXRpb24uIElzIGl0IHRoYXQgd2Ugc2hvdWxkIGhh dmUgdHdvIHNlcGFyYXRlIGZhY2lsaXR5IGZpZWxkczoNCj4+IFJGQyA1NDI0ICgwLTI0KSBhbmQg VmVuZG9yIFNwZWNpZmljIHN0YXJ0aW5nIGF0IDI0Pw0KPg0KPk9uZSBvcHRpb24gY291bGQgYmUg dG8gZG86DQo+DQo+ICB0eXBlZGVmIGZhY2lsaXR5IHsNCj4gICAgdHlwZSB1bmlvbiB7DQo+ICAg ICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ICAgICAgICBlbnVtIGtlcm4gICB7IHZhbHVlIDA7IH0N Cj4gICAgICAgIC4uLg0KPiAgICAgICAgZW51bSBsb2NhbDggeyB2YWx1ZSAyMzsgfQ0KPiAgICAg IH0NCj4gICAgICB0eXBlIHVpbnQxNiB7DQo+ICAgICAgICByYW5nZSAiMjQuLjEyNCI7ICAvLyBv ciAwLi45OTkNCj4gICAgICB9DQo+ICAgIH0NCj4gIH0NCj4NCj5JdCBpcyBub3QgY2xlYXIgdG8g bWUgaWYgdGhpcyBpcyBhbGxvd2VkIGJ5IFJGQyA1NDI0LiAgSXQgc2F5cyB0aGF0Og0KPg0KPiAg RmFjaWxpdHkgYW5kIFNldmVyaXR5IHZhbHVlcyBhcmUgbm90IG5vcm1hdGl2ZSBidXQgb2Z0ZW4g dXNlZA0KPg0KPkJ1dCB0aGVuIGl0IGFsc28gc2F5czoNCj4NCj4gIEZhY2lsaXR5IHZhbHVlcyBN VVNUIGJlIGluIHRoZSByYW5nZSBvZiAwIHRvIDIzIGluY2x1c2l2ZQ0KPg0KPlNvIGlmIHdlIGFs bG93IG90aGVyIGZhY2lsaXRpZXMsIHNob3VsZG4ndCB3ZSBhbHNvIGFsbG93IG90aGVyDQo+c2Vy dmVyaXRpZXM/DQo+DQo+T3Igc2hvdWxkIHdlIGFsbG93IHRoZW0gdG8gY29uZmlndXJlIHByaXZh bCAwLi45OTk/DQoNCltjbHlkZV0gSSBsaWtlIHlvdXIgcHJvcG9zYWwgdG8gcmVjb21tZW5kIHRo YXQgdmVuZG9yLXNwZWNpZmljIGlkZW50aXRpZXMgYmUgZGVyaXZlZCBmcm9tIHN0YW5kYXJkIG9u ZXMuIEJ1dCB0aGV5IHdpbGwgbm90IHdhbnQgdG8gYmUgY29uZmluZWQgdG8gdGhlIGJhc2Ugc2V0 IG9mIDI0LiB0aGVyZWZvcmUgeW91ciBwcm9wb3NhbCB1c2luZyBhIHVuaW9uIG9mIHRoZSBlbnVt IGFuZCB1aW50MTYgYWJvdmUgc2VlbXMgdG8gYmUgdGhlIGJlc3Qgd2F5IGZvcndhcmQuDQoNCj4N Cj4+ID5vICBXaHkgZG8gd2UgaGF2ZSB0aGVzZToNCj4+ID4NCj4+ID4gICAgZmVhdHVyZSBmaWxl LWxvZ2dpbmctc3RydWN0dXJlZC1kYXRhDQo+PiA+DQo+PiA+ICAgIGZlYXR1cmUgcmVtb3RlLWxv Z2dpbmctc3RydWN0dXJlZC1kYXRhDQo+PiA+DQo+PiA+ICBJIHdvdWxkIGFzc3VtZSB0aGF0IGlm IHRoZSBkZXZpY2Ugc3VwcG9ydHMgc3RydWN0dXJlZCBkYXRhLCBpdCB3b3VsZA0KPj4gPiAgZG8g c28gcmVnYXJkbGVzcyBvZiBsb2dnaW5nIG1ldGhvZD8gIEkuZS4sIGEgc2luZ2xlIGZlYXR1cmUN Cj4+ID4gICJzdHJ1Y3R1cmVkLWRhdGEiIHdvdWxkIGJlIGVub3VnaD8NCj4+ID4NCj4+ID4gIEJ1 dCBpcyB0aGlzIChzdHJ1Y3R1cmVkIGRhdGEpIHR5cGljYWxseSBjb25maWd1cmFibGUgaW4NCj4+ ID4gIGltcGxlbWVudGF0aW9ucywgYW5kIGlmIGl0IGlzLCBpdCBpcyBjb25maWd1cmFibGUgcGVy ICJhY3Rpb24iIGxpa2UNCj4+ID4gIHRoaXM/DQo+PiANCj4+IFtjbHlkZV0gVGhlIGhpc3Rvcnkg b2YgdGhpcyBpcyB0aGF0IHdlIGFncmVlZCB0byBzdXBwb3J0DQo+PiBmaWxlLWxvZ2dpbmctc3Ry dWN0dXJlZC1kYXRhIGFzIGEgZmVhdHVyZSAoY3VycmVudGx5IGltcGxlbWVudGVkIGJ5DQo+PiBK VU5PUykgc2luY2UgaXQgaXMgY2FsbGVkIG91dCBpbiBSRkMgNTQyNC4gVGhlbiBzb21lb25lIChh dCB0aGUgSGF3YWlpDQo+PiBtZWV0aW5nKSBhc2tlZCwgaWYgd2Ugc3VwcG9ydCBzdHJ1Y3R1cmVk IGRhdGEgZm9yIGZpbGVzLCB3aHkgbm90DQo+PiBzdXBwb3J0IGZvciByZW1vdGUgbG9nZ2luZyB0 b28/IEFsdGhvdWdoIEkgZG8gbm90IGtub3cgb2YgYW55b25lIHdobw0KPj4gaGFzIGltcGxlbWVu dGVkIHRoaXMsIEkgYWdyZWVkIHRvIHN1cHBvcnQgaXQgZm9yIHJlbW90ZSBsb2dnaW5nIGFzIGEN Cj4+IHNlcGFyYXRlIGZlYXR1cmUuIFdlIGFyZSB0YWxraW5nIGFib3V0IHR3byBkaWZmZXJlbnQg ZnVuY3Rpb25hbGl0aWVzDQo+PiBoZXJlLiBQZXJoYXBzIHRoZSBiZXN0IHNvbHV0aW9uIGlzIHRv IHJlbW92ZSByZW1vdGUtbG9nZ2luZyBzdHJ1Y3R1cmVkDQo+PiBkYXRhIGFuZCBsZXQgaXQgYmUg c3VwcG9ydGVkIHRocm91Z2ggYXVnbWVudGF0aW9uIHNob3VsZCBhbnlvbmUNCj4+IHJlcXVpcmUg aXQgaW4gdGhlIGZ1dHVyZS4NCj4NCj5MZXQgbWUgdGFrZSBvbmUgc3RlcCBiYWNrLiAgV2hhdCBl eGFjdGx5IGRvZXMgaXQgbWVhbiB0bzoNCj4NCj4gICAgICAgbG9nIG1lc3NhZ2VzIA0KPiAgICAg ICB0byBhIGZpbGUgaW4gc3RydWN0dXJlZC1kYXRhIGZvcm1hdCBhcyBwZXIgUkZDIDU0MjQNCj4N Cj5SRkMgNTQyNCBkZWZpbmVzIHRoZSBmb3JtYXQgb2YgYSBzeXNsb2cgbWVzc2FnZSwgd2l0aCB0 aGUgcnVsZQ0KPiJTWVNMT0ctTVNHIi4gIFRoaXMgbWVzc2FnZSBmb3JtYXQgY29udGFpbnMgc3Ry dWN0dXJlZCBkYXRhLg0KPg0KPlNvIGlmIHlvdSBoYXZlIG5vdCBlbmFibGVkIHN0cnVjdHVyZWQg ZGF0YSAod2l0aCB5b3VyIG1vZGVsKSwgd2hhdCBpcw0KPnRoZSBleHBlY3RlZCBmb3JtYXQgb2Yg dGhlIG1lc3NhZ2U/ICBEb2VzIGl0IHN0aWxsIGNvbnRhaW4gdGhlIEhFQURFUg0KPmFzIGRlZmlu ZWQgaW4gNTQyNCwgb3IganVzdCBzb21lIG1lc3NhZ2UgZm9ybWF0IChtYXliZSBhcyBleGFwbGFp bmVkDQo+aW4gUkZDIDMxNjQpPw0KDQpbY2x5ZGVdIFBsZWFzZSBzZWUgUkZDIDU0MjQgc2VjdGlv biA2LjAgU3lzbG9nIE1lc3NhZ2UgRm9ybWF0LiBTVFJVQ1RVUkVELURBVEEgYXVnbWVudHMgdGhl IHN5c2xvZyBtZXNzYWdlLiA7LSkNCg0KSWYgc3RydWN0dXJlZCBkYXRhIGlzIG9mZiwgdGhlIFNU UlVDVFVSRUQtREFUQSBwb3J0aW9uIG9mIHRoZSBzeXNsb2cgbWVzc2FnZSBpcyBub3QgcHJlc2Vu dCBhbmQgZXZlcnl0aGluZyBlbHNlIGlzIHByZXNlbnQuDQoNCj4NCj4+ID5vICBJIGRvIG5vdCB1 bmRlcnN0YW5kIHdoYXQgdGhlIGdsb2JhbC1sb2dnaW5nLWFjdGlvbiBkb2VzLiAgVGhlDQo+PiA+ ICAgZGVzY3JpcHRpb24gc2F5czoNCj4+ID4NCj4+ID4gICAgICAgICBHbG9iYWwgbG9nZ2luZyBy ZXByZXNlbnRzIHRoZSBhYmlsaXR5IHRvDQo+PiA+ICAgICAgICAgcGVyZm9ybSBnbG9iYWwgbG9n IG1lc3NhZ2Ugc3VwcHJlc3Npb24uDQo+PiA+DQo+PiA+ICAgRG9lcyB0aGlzIG1lYW4gdGhhdCB0 aGUgZ2xvYmFsIGxldmVsICpzdXBwcmVzc2VzKiBtYXRjaGluZw0KPj4gPiAgIG1lc3NhZ2VzPw0K Pj4gPg0KPj4gPiAgIFRoZSB0ZXh0IHRhbGtzIGFib3V0ICJncm91cCBsZXZlbCBzdXBwcmVzc2lv biIsIGJ1dCB0aGUgbW9kZWwgaGFzDQo+PiA+ICAgImdsb2JhbCBsb2dnaW5nIGFjdGlvbiIuICBU aGlzIGlzIGEgYml0IGNvbmZ1c2luZy4NCj4+ID4NCj4+ID4gICBTbyB3aGF0IGRvZXMgdGhpcyBj b25maWd1cmF0aW9uIG1lYW46DQo+PiA+DQo+PiA+ICAgICA8Z2xvYmFsLWxvZ2dpbmctYWN0aW9u Pg0KPj4gPiAgICAgICA8bm9uZS8+DQo+PiA+ICAgICA8L2dsb2JhbC1sb2dnaW5nLWFjdGlvbj4N Cj4+ID4NCj4+ID4gICBEb2VzIGl0IG1lYW5zIHRoYXQgbm8gbWVzc2FnZXMgYXJlIHN1cHByZXNz ZWQsIG9yIHRoYXQgYWxsIG1lc3NhZ2VzDQo+PiA+ICAgYXJlIHN1cHByZXNzZWQ/DQo+PiANCj4+ IFtjbHlkZV0gR2xvYmFsIGxvZ2dpbmcgaXMgYSBmaXJzdCBsZXZlbCBzdXBwcmVzc2lvbiBmaWx0 ZXIuIFBsZWFzZSBzZWUNCj4+IHRoZSBkaWFncmFtIGluIHRoZSBSRkMuIEdpdmVuIHRoYXQgb25s eSBhIGZldyBOT1MgaW1wbGVtZW50IGl0IHdlDQo+PiBjb3VsZCByZW1vdmUgaXQgYW5kIGxlYXZl IGl0IGZvciBhdWdtZW50YXRpb24gZm9yIHRob3NlIHZlbmRvcnMgdGhhdA0KPj4gaW1wbGVtZW50 IGl0LiA8bm9uZS8+IG1lYW5zIHRoYXQgbm8gZmFjaWxpdGllcyBwYXJ0aWNpcGF0ZSBpbiB0aGUN Cj4+IGZpbHRlciBhbmQgdGhlcmVmb3JlIHRoZSBmaWx0ZXIgaXMgdHVybmVkIG9mZi4NCj4NCj5P ay4NCj4NCj5NeSBwb2ludCBpcyB0aGF0IHRoZSB0ZXh0IGlzIHVuY2xlYXIuICBCdXQgaWYgeW91 IHJlbW92ZSB0aGlzIHRoYXQNCj5wcm9ibGVtIGdvZXMgYXdheXMgOy0pDQoNCltjbHlkZV0gSSB3 aWxsIHJlbW92ZSBnbG9iYWwgbG9nZ2luZy4NCg0KPg0KPj4gPG5vbmUvPiBpcyB1c2VmdWwgd2hl biB5b3Ugd2FudCB0byB0dXJuIG9mZiBhY3Rpb25zIHRoYXQgZGVmYXVsdCB0byBvbg0KPj4gKHN1 Y2ggYXMgdGhlIGNvbnNvbGUpLg0KPj4gDQo+PiA+DQo+PiA+DQo+PiA+byBUaGUgdXNhZ2Ugb2Yg dGhlIGluLW1lbW9yeSBsb2cgYnVmZmVyIGlzIGEgYml0IHVuY2xlYXIuICBJIHRoaW5rIHRoZQ0K Pj4gPiAgIHNwZWMgbmVlZHMgdG8gZXhwbGFpbiBob3cgdGhpcyBsb2cgYnVmZmVyIGlzIHN1cHBv c2VkIHRvIGJlIHVzZWQuDQo+PiA+ICAgUGVyaGFwcyB3ZSBzaG91bGQgYWxzbyBwcm92aWRlIGEg bWVjaGFuaXNtIHRvIHJlYWQgdGhpcyBidWZmZXI/DQo+PiA+ICAgSS5lLiwgcHJvdmlkZSBhIGNv bmZpZyBmYWxzZSBsaXN0IG9mIGJ1ZmZlcmVkIG1lc3NhZ2VzPw0KPj4gDQo+PiBbY2x5ZGVdIElu LW1lbW9yeSBsb2cgYnVmZmVycyBhcmUgY2lyY3VsYXIgcXVldWVzIG9mIGxvZw0KPj4gbWVzc2Fn ZXMuIE5ldHdvcmsgZWxlbWVudHMgdGhhdCBjYW4gZXhwZXJpZW5jZSBsb2cgbWVzc2FnZSBldmVu dA0KPj4gc3Rvcm1zIHVzZSBpbi1tZW1vcnkgYnVmZmVycyB0byBhdm9pZCBsb3NzIG9mIHN5c2xv ZyBtZXNzYWdlcy4NCj4NCj5UaGlzIGRvZXNuJ3QgYW5zd2VyIG15IHF1ZXN0aW9uIC0gaG93IGlz IHRoZSBidWZmZXIgc3VwcG9zZWQgdG8gYmUNCj51c2VkPw0KDQpbY2x5ZGVdIFdoZW4gYSBoaWdo IHZvbHVtZSBvZiBzeXNsb2cgbWVzc2FnZXMgaXMgZXhwZWN0ZWQsIHNheSBieSB0dXJuaW5nIG9u IGRlYnVnIGxldmVsIG1lc3NhZ2VzIG9yIGR1cmluZyBldmVudCBzdG9ybXMsIGJ1ZmZlcmVkIGxv Z2dpbmcgY2FwdHVyZXMgbWVzc2FnZSByZWxpYWJseSB1bnRpbCB0aGUgbG9nIGJ1ZmZlciBpcyBm dWxsIHdoZW4gaXQgd3JhcHMuIFlvdSBhY2Nlc3MgdGhlIGJ1ZmZlcmVkIGxvZyB1c2luZyBhICJz aG93IGxvZyIgY29tbWFuZCB3aGljaCBkaXNwbGF5cyB0aGUgbWVzc2FnZXMgaW4gdGhlIGJ1ZmZl ci4NCg0KPg0KPj4gPm8gIEZvciByZW1vdGUgbG9nZ2luZywgSSB0aGluayB0aGUgInZyZi1uYW1l IiBsZWFmIHNob3VsZCBiZSByZW1vdmVkLg0KPj4gPiAgIEl0IGlzIG5vdCBjbGVhciBob3cgdGhp cyBtYXBzIHRvIHRoZSByb3V0aW5nIHdvcmssIGFuZCBpdCBjYW4NCj4+ID4gICBhbHdheXMgYmUg YXVnbWVudGVkIGxhdGVyLCBvciBhIHZlbmRvciBjYW4gZG8gYSBwcm9wcmlldGFyeQ0KPj4gPiAg IGF1Z21lbnRhdGlvbi4NCj4+IA0KPj4gW2NseWRlfSBNdWx0aXBsZSB2ZW5kb3JzIGFkZCBWUkYg bmFtZSB0byB0aGUgc2VydmVyIGNvbm5lY3Rpb24NCj4+IHNwZWNpZmljYXRpb24gc28gdGhhdCB0 aGUgY29ycmVjdCByb3V0aW5nIHRhYmxlIGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUNCj4+IGFjY2Vz cyB0aGUgc2VydmVyLiBJIGFtIHN1cnByaXNlZCB0aGF0IFZSRiBpcyBub3QgaW4geW91ciBiZXN0 DQo+PiBwcmFjdGljZSBPdXRib3VuZCBDb25uZWN0aW9uIHBhdHRlcm4uDQo+DQo+VGhlIHJlYXNv biBpcyB0aGF0IGhvdyB0byBoYW5kbGUgdGhpcyBpcyBvbmdvaW5nIHdvcmsgaW4gdGhlIHJvdXRp bmcNCj5jb25maWcuICBXaGVuIHRoYXQgd29yaywgd2UgY2FuL25lZWQgdG8gcmV2aXNpdCB0aGlz LiAgQnV0IGlmIHdlIGFkZA0KPnNvbWV0aGluZyBub3csIHRoZXJlJ3MgYSByaXNrIHRoYXQgd2hh dCB3ZSBkbyBkbyBub3QgZml0IGludG8gdGhlaXINCj53b3JrLg0KDQpbY2x5ZGVdIEkgd2lsbCBy ZW1vdmUgcmVmZXJlbmNlcyB0byBWUkYuDQoNCj4NCj4+ID5vICBsZWFmIGZpbGUtbnVtYmVyIGhh cyBhIGRlZmF1bHQgb2YgMS4gIElzbid0IHRoaXMgYSBiaXQgc21hbGwgZm9yIGENCj4+ID4gICBm aWxlIGFyY2hpdmU/DQo+PiANCj4+IFtjbHlkZV0gSSBjaG9zZSAxIChwZXJoYXBzIG5haXZlbHkp IGZvciB0aG9zZSB2ZW5kb3JzIHRoYXQgZG8gbm90DQo+PiBpbXBsZW1lbnQgdGhlIGZpbGUtbnVt YmVyIGNvbmNlcHQuIEkgd2lsbCBiZSBoYXBweSB0byBjaGFuZ2UgdG8gYQ0KPj4gY29uc2Vuc3Vz IG51bWJlci4NCj4NCj5XaGF0IGhhcHBlbnMgd2hlbiBhbGwgZmlsZXMgYXJlIGZ1bGw/ICBJIHRo aW5rIHRoZSB0ZXh0IG5lZWRzIHRvDQo+c3BlY2lmeSB0aGlzLg0KDQpbY2x5ZGVdIEkgd2lsbCBj bGFyaWZ5IHRoaXMgYmVoYXZpb3IgaW4gdGhlIGRlc2NyaXB0aW9uLg0KDQo+DQo+PiA+byAgSSBk b24ndCB1bmRlcnN0YW5kIGhvdyB0aGUgbGVhZiAic2VsZWN0LW1lc3NhZ2Utc2V2ZXJpdHkiIGlz DQo+PiA+ICAgc3VwcG9zZWQgdG8gYmUgdXNlZC4NCj4+IA0KPj4gSnVlcmdlbiBmZWx0IHRoYXQg aXQgd2FzIGltcG9ydGFudCB0aGF0IHRoaXMgbW9kZWwgc3VwcG9ydCBMaW51eA0KPj4gc3lzbG9n IHNlbGVjdG9yIHByb2Nlc3NpbmcuIExpbnV4IHN5c2xvZyBhZGRzICJlcXVhbHMiIGFuZA0KPj4g Im5vdC1lcXVhbHMiIGNvbXBhcmlzb25zIHRvIHRoZSBzdGFuZGFyZCAiZXF1YWxzLW9yLWhpZ2hl ciIgc2V2ZXJpdHkNCj4+IGNvbXBhcmlzb24uIFRoaXMgaXMgYSBmZWF0dXJlIGJlY2F1c2Ugbm90 IGFsbCBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydA0KPj4gdGhpcy4NCj4NCj5GaW5lLCBidXQgbXkg cG9pbnQgaXMgdGhhdCB0aGUgdGV4dCBuZWVkcyB0byBiZXR0ZXIgZXhwbGFpbiAobW9yZQ0KPnNw ZWNpZmljKSBob3cgaXQgaXMgc3VwcG9zZWQgdG8gd29yay4gIEZvciBleGFtcGxlIGl0IHNheXM6 DQo+DQo+ICAgICAgICAgIGVudW0gZXF1YWxzIHsNCj4gICAgICAgICAgICBkZXNjcmlwdGlvbg0K PiAgICAgICAgICAgICAgIlRoaXMgbGVhZiBzcGVjaWZpZXMgYWxsIG1lc3NhZ2VzIGZvciB0aGUg c3BlY2lmaWVkIA0KPiAgICAgICAgICAgICAgIHNldmVyaXR5LiI7DQo+ICAgICAgICAgIH0NCj4N Cj5JdCBzYXlzICJUaGlzIGxlYWYiLCBidXQgcHJvYmFibHkgbWVhbiAiVGhpcyB2YWx1ZSIuICBX aGF0IGV4YWN0bHkgaXMNCj4idGhlIHNwZWNpZmllZCBzZXZlcml0eSIuDQo+DQoNCltjbHlkZV0g QWdyZWVkIHRoYXQgdGhlIHRleHQgY2FuIGJlIGNsZWFyZXIuIA0KDQo+DQo+DQo+DQo+L21hcnRp bg0K From nobody Wed Apr 8 23:23:25 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F64F1B2D0F for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 23:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pmzs_r0iiK51 for <netmod@ietfa.amsl.com>; Wed, 8 Apr 2015 23:23:21 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 022531B2D0D for <netmod@ietf.org>; Wed, 8 Apr 2015 23:23:20 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id D21B01280943; Thu, 9 Apr 2015 08:23:19 +0200 (CEST) Date: Thu, 09 Apr 2015 08:23:19 +0200 (CEST) Message-Id: <20150409.082319.278951169841775666.mbj@tail-f.com> To: cwildes@cisco.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <9E933BD9-E257-45F5-B055-CCA24BAA8F1F@cisco.com> References: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> <9E933BD9-E257-45F5-B055-CCA24BAA8F1F@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/If8kSSjzrtFrFHsDflYKcgstWQ4> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 06:23:23 -0000 Hi, "Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote: > Hi Martin, > > My responses inline... > > > > On 4/8/15, 3:12 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > > >Hi, > > > >"Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote: > >> On 4/2/15, 5:42 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > >> >o Given that the standard defines a fixed set of 24 facilities, it > >> > seems odd that the facilities are modelled as identities, and not > >> > as an enumeration. Using identities gives the impression that this > >> > is an extensible set of values. > >> > >> [clyde] A number of vendors need to augment the list of facilities - > >> some with several hundred additional facilities. > > > >How does this even work, given that the PRIVAL is encoded with 3 > >digits? It seems to me that the maximum possible facility value is > >124. > > > >> Please suggest an > >> alternative coding that can be used to add facilities through > >> augmentation. Is it that we should have two separate facility fields: > >> RFC 5424 (0-24) and Vendor Specific starting at 24? > > > >One option could be to do: > > > > typedef facility { > > type union { > > type enumeration { > > enum kern { value 0; } > > ... > > enum local8 { value 23; } > > } > > type uint16 { > > range "24..124"; // or 0..999 > > } > > } > > } > > > >It is not clear to me if this is allowed by RFC 5424. It says that: > > > > Facility and Severity values are not normative but often used > > > >But then it also says: > > > > Facility values MUST be in the range of 0 to 23 inclusive > > > >So if we allow other facilities, shouldn't we also allow other > >serverities? > > > >Or should we allow them to configure prival 0..999? > > [clyde] I like your proposal to recommend that vendor-specific > identities be derived from standard ones. But they will not want to be > confined to the base set of 24. therefore your proposal using a union > of the enum and uint16 above seems to be the best way forward. But this solution does not handle the case that Juergen described, where other facility names are mapped to the standard value space (0..23). I assume you mean that these vendors do not implement RFC 5424 (which limits the facilitiy numbers to 0..23)? Can you describe in more detail such an implementation, and what the messages look like in such a case? > >> >o Why do we have these: > >> > > >> > feature file-logging-structured-data > >> > > >> > feature remote-logging-structured-data > >> > > >> > I would assume that if the device supports structured data, it would > >> > do so regardless of logging method? I.e., a single feature > >> > "structured-data" would be enough? > >> > > >> > But is this (structured data) typically configurable in > >> > implementations, and if it is, it is configurable per "action" like > >> > this? > >> > >> [clyde] The history of this is that we agreed to support > >> file-logging-structured-data as a feature (currently implemented by > >> JUNOS) since it is called out in RFC 5424. Then someone (at the Hawaii > >> meeting) asked, if we support structured data for files, why not > >> support for remote logging too? Although I do not know of anyone who > >> has implemented this, I agreed to support it for remote logging as a > >> separate feature. We are talking about two different functionalities > >> here. Perhaps the best solution is to remove remote-logging structured > >> data and let it be supported through augmentation should anyone > >> require it in the future. > > > >Let me take one step back. What exactly does it mean to: > > > > log messages > > to a file in structured-data format as per RFC 5424 > > > >RFC 5424 defines the format of a syslog message, with the rule > >"SYSLOG-MSG". This message format contains structured data. > > > >So if you have not enabled structured data (with your model), what is > >the expected format of the message? Does it still contain the HEADER > >as defined in 5424, or just some message format (maybe as exaplained > >in RFC 3164)? > > [clyde] Please see RFC 5424 section 6.0 Syslog Message > Format. STRUCTURED-DATA augments the syslog message. ;-) Well, STRUCTURED-DATA is one part of SYSLOG-MSG. > If structured data is off, the STRUCTURED-DATA portion of the syslog > message is not present and everything else is present. Do you mean that if structured data is off, you want the message to NOT follow the format defined in 5424 (i.e., NOT follow SYSLOG-MSG), or do you mean that if structured data is off, the message is formatted with STRUCTURED-DATA = NILVALUE? Whatever the answer is, it needs to be specified so that an implementor knows what to do. Some examples might help as well. > >> <none/> is useful when you want to turn off actions that default to on > >> (such as the console). > >> > >> > > >> > > >> >o The usage of the in-memory log buffer is a bit unclear. I think the > >> > spec needs to explain how this log buffer is supposed to be used. > >> > Perhaps we should also provide a mechanism to read this buffer? > >> > I.e., provide a config false list of buffered messages? > >> > >> [clyde] In-memory log buffers are circular queues of log > >> messages. Network elements that can experience log message event > >> storms use in-memory buffers to avoid loss of syslog messages. > > > >This doesn't answer my question - how is the buffer supposed to be > >used? > > [clyde] When a high volume of syslog messages is expected, say by > turning on debug level messages or during event storms, buffered > logging captures message reliably until the log buffer is full when it > wraps. You access the buffered log using a "show log" command which > displays the messages in the buffer. This needs to be specified in the text. And my original question remains - should this data model provide a mechanism to read this buffer? I think we should - or remove the buffered-logging-action. /martin From nobody Thu Apr 9 00:11:50 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6F81A1A70 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 00:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HneFAXaeyx0I for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 00:11:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF1D1A1A68 for <netmod@ietf.org>; Thu, 9 Apr 2015 00:11:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2B5F0F64; Thu, 9 Apr 2015 09:11:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LK0VE6zq8CYj; Thu, 9 Apr 2015 09:11:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 09:11:43 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43F1F20013; Thu, 9 Apr 2015 09:11:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NoFszNg24CX3; Thu, 9 Apr 2015 09:11:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28F922002B; Thu, 9 Apr 2015 09:11:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F0D432BC0AF; Thu, 9 Apr 2015 09:11:41 +0200 (CEST) Date: Thu, 9 Apr 2015 09:11:40 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Anees Shaikh <aashaikh@google.com> Message-ID: <20150409071140.GA26731@elstar.local> Mail-Followup-To: Anees Shaikh <aashaikh@google.com>, Andy Bierman <andy@yumaworks.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> References: <9157089.1428086622910.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> <CABCOCHTXJaeCJbvR+xwoK6bOXrouQRbT-hHu3QaSa0B7E09SOA@mail.gmail.com> <CAJK7ZqJAoDkR+9QpJJ+kZeQTnowG=U0-iGWz+8NQntvr53B07A@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAJK7ZqJAoDkR+9QpJJ+kZeQTnowG=U0-iGWz+8NQntvr53B07A@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/S2V96Rk7T_--Hcm9cqxwgevFeS0> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 07:11:49 -0000 On Mon, Apr 06, 2015 at 01:58:04AM -0700, Anees Shaikh wrote: > > Regarding the definition of statistics, there is some discussion in the > draft -- we consider three types of state data: i) statistics / counters, > ii) element- or protocol-generated state (e.g., #prefixes received on a BGP > session), iii) current, actual configuration (that may differ from intended > configuration). The problem is that all of this is not clear cut. If I receive an IP address via DHCP, is that not element- or protocol-generated state? I guess you assume it is current, actual configuration - but what makes something current, actual configuration and what makes it element- or protocol-generated state? Why are #prefixes received on a BGP session not statistics - sounds like counter/gauge to me. While we can discuss these particular examples, I do wonder if even the examples used to promote the idea really work easily. RFC 3535 says this: 2. It is necessary to make a clear distinction between configuration data, data that describes operational state and statistics. Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols. This is have we have been working with since then. It remains unclear why we now should move to a system distinguishing 4 different kinds of data instead of the 3 we talk about since the IAB workshop. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 9 00:15:10 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225291A1A8D for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 00:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVW1yzvEQKrj for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 00:15:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E7A3C1A1A7F for <netmod@ietf.org>; Thu, 9 Apr 2015 00:15:01 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 09D291280AF6; Thu, 9 Apr 2015 09:15:01 +0200 (CEST) Date: Thu, 09 Apr 2015 09:15:00 +0200 (CEST) Message-Id: <20150409.091500.933434364578438624.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <etPan.55241a7a.41a7c4c9.855@corretto.local> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/-wmuxO6eOzlI5wPmCWz0RM-gHeU> Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 07:15:08 -0000 Hi, Rob Shakir <rjs@rob.sh> wrote: > It feels rather like, right now, I am being told that the current > proposal we put forward is wrong, but also not being offered another > solution that meets the requirements. It is easier to shoot down a proposed to solution to the P vs NP problem than providing a correct solution ;-) > We did reach out to Martin to > discuss his (expired) draft [1] back in December - he counselled us > that the approach did not seem usable to him. Correct. Specifically, the idea was that in order to avoid data model duplication, where more or less every config knob had a corresponding state knob, we could introduce an operational data store with the same schema as the config data stores (+ more). This doesn't seem usable b/c: 1. There is often not a 1-1 relationship between config and state nodes. 2. The value space is sometimes not the same in config and state (e.g., "duplex" which could be {auto,half,full} in config vs {half,full} in state; or "state" which could be {up,down} in config vs {up,testing,error,down,...} in state.) 3. The semantics of the nodes are different, leading to description statements on the form: "In config, this node means..., but in state it means ...". Your proposed solution with explicitly duplicating all config nodes as config false nodes has the same problems, and in addition it has some problems of its own, e.g., the relocation problem that Andy mentioned, where leafrefs don't point to the correct leaf, and the lifecycle problem (where non-configured nodes do nto show up in state). /martin From nobody Thu Apr 9 00:40:59 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84B61A702A for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 00:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubibh4gd1JGi for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 00:40:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718721A7018 for <netmod@ietf.org>; Thu, 9 Apr 2015 00:40:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 42657FA3; Thu, 9 Apr 2015 09:40:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xkf4jre9fRcA; Thu, 9 Apr 2015 09:40:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 09:40:53 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1117B2002B; Thu, 9 Apr 2015 09:40:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r3LmE1P-drym; Thu, 9 Apr 2015 09:40:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 941FC20013; Thu, 9 Apr 2015 09:40:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6098832BC171; Thu, 9 Apr 2015 09:40:51 +0200 (CEST) Date: Thu, 9 Apr 2015 09:40:51 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Randy Presuhn <randy_presuhn@mindspring.com> Message-ID: <20150409074051.GB26731@elstar.local> Mail-Followup-To: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> References: <171379.1428441544263.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <171379.1428441544263.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9oEykaydpsnGna6HtD3Yy9NzIeg> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 07:40:58 -0000 On Tue, Apr 07, 2015 at 02:19:03PM -0700, Randy Presuhn wrote: > > I think we're actually in violent agreement, though you and I are > describing it in characteristically different ways. That's > not new. :-) My point is that formulating it as a datastore > problem (or as an extension to the corresponding model/protocol > mechanisms) is really just another attempt at using structure > to solve a problem which is just an instance of a class of > problems which are fundamentally independent of models' structures. > > Sticking to "operational state" falls apart if one decides to > slice and dice the information at finer levels of granularity, > e.g. performance statistics, security statistics, throughput, > alarm statuses, etc. If there's just one big bucket of "operational > state", the datastore view is kinda plausible. If finer, potentially > overlapping subcategorization are needed, the datastore view > quickly becomes a mass of spaghetti. The question is whether > application developers or users benefit enough from > having that finer level of granularity represented in models > to make it worth the modeling effort. You know my leanings > on that point, but since I'm not implementing this stuff, I'm > staying officially agnostic. > > It's a tough issue because rigorously specifying the semantic > relationships almost certainly means someone's implementation > would have to change in order to conform to the more fully/precisely > specified semantics. Netconf / Netmod has tried very hard to be > minimally constraining on vendors' implementation, so I think > there's a built-in cultural bias against dealing with these > problems. It's certainly the group's right to stick with this > approach, but that also means that this class of problems will > continue to accrete ad hoc solutions. It's conceivable that > that's the right thing to do, even though I instinctually > recoil from it. > I think one aspect we have to keep in mind is that it is hard to control how people write YANG models. Not all module writers will have the same level of time and sophistication. And there will be several organizations involved in writing models, not just the IETF. So facing reality, we have to accept that YANG module structures will never be perfect. Even if we agree on some structural rules for the IETF and we find lots of volunteers to review all data models for compliance to these rules (I see a big problem here), we will fail for modules done outside the IETF. I think this can be compared to APIs of many open source C libraries. Would it not be nice if they were all following similar conventions? Well, the reality is that they don't and hence there is a learning curve which each of them. (But there is also some good aspect of this, people are free to try out other hopefully better ideas.) I think the key here is accepting the reality of a fully distributed and loosely controlled YANG data model development process. If YANG becomes successful and widely used, I believe we will need at some time something like Andy's conformance packages or other data model annotations that provide additional meta-data to further automate processing and that can cut through data models in several different meaningful aspects. I agree with Randy that trying to encode all of these cross-cutting aspects into data model structure is not really workable. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 9 02:00:59 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612671B29B1 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 02:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpWt3cNjqFtv for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 02:00:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED081B29B0 for <netmod@ietf.org>; Thu, 9 Apr 2015 02:00:55 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:2001:5ee2:74d3:88f2] (unknown [IPv6:2001:1488:fffe:6:2001:5ee2:74d3:88f2]) by mail.nic.cz (Postfix) with ESMTPSA id B8D231400C3; Thu, 9 Apr 2015 11:00:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1428570053; bh=CJW7Wqr8BC8bVKqWlHvjDxJZjsoYttboFCpiEVFhyBE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=k5P5f1NRgmnnCr6//YNcgIk5piigYDNMgAhL8J+XOku4kXOrtXCfCsFo1RYqs0XUq eH53jMsYLYAWflksqCV3qjcEIxEe9HAiHQa+bMAkq/1UzesnIPq+We+6kSOKUR1w9U 2RAdgKyh+xgNjDepI+3FgEFgyb/MR2KUqAyhlmjo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150409.091500.933434364578438624.mbj@tail-f.com> Date: Thu, 9 Apr 2015 11:00:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj@tail-f.com> X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/dqb2Yju2jL9nbObfFxAhbda3kF4> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 09:00:58 -0000 > On 09 Apr 2015, at 09:15, Martin Bjorklund <mbj@tail-f.com> wrote: >=20 > Hi, >=20 > Rob Shakir <rjs@rob.sh> wrote: >> It feels rather like, right now, I am being told that the current >> proposal we put forward is wrong, but also not being offered another >> solution that meets the requirements. >=20 > It is easier to shoot down a proposed to solution to the P vs NP > problem than providing a correct solution ;-) >=20 >> We did reach out to Martin to >> discuss his (expired) draft [1] back in December - he counselled us >> that the approach did not seem usable to him. >=20 > Correct. Specifically, the idea was that in order to avoid data model > duplication, where more or less every config knob had a corresponding > state knob, we could introduce an operational data store with the same > schema as the config data stores (+ more). This doesn't seem usable > b/c: Yes, although maybe there was one thing that we got right in that draft, = and that still seems to me as a reasonable starting point: The operational state datastore consists of all parameters that provide information about the instantaneous state of the device and immediately influence the device's behavior. The configuration datastore can be thought of as a blueprint for the operational datastore. The first definition IMO sufficiently discriminates state data from = statistics, although one could also argue that a device may change its = behaviour based on traffic statistics. Anyway, this distinction is not = that important. The second definition could perhaps use =E2=80=9Cinstructions=E2=80=9D = instead of =E2=80=9Cblueprint=E2=80=9D, thus emphasizing the fact that = configuration needn=E2=80=99t always have the same structure and content = as state data.=20 This view of state versus configuration also opens the possibility of = having alternative management protocols, each with its own schema and = scope of configuration instructions. >=20 > 1. There is often not a 1-1 relationship between config and state > nodes. >=20 > 2. The value space is sometimes not the same in config and > state (e.g., "duplex" which could be {auto,half,full} in config vs > {half,full} in state; or "state" which could be {up,down} in > config vs {up,testing,error,down,...} in state.) >=20 > 3. The semantics of the nodes are different, leading to description > statements on the form: "In config, this node means..., but in > state it means =E2=80=A6". Agreed, and the moral of the story is that state and configuration are = related but still distinct entities. One of the reasons why we failed was IMO that we didn=E2=80=99t dare to = move away from the configuration-centric data modelling where almost all = relevant semantic constraints are specified for configuration data. In my opinion, application of a new configuration could proceed in the = following steps: 1. Configuration is tentatively applied to the current operational = state. 2. The new state is completely validated. 3. If all constraints are met, the new state is (atomically) installed = in the device. In order to be able to use a data model in #2, semantic constraints, = default values etc. need to be specified for state data. This doesn=E2=80=99t prevent validation of configuration(s) but that is = really a separate action. Lada >=20 > Your proposed solution with explicitly duplicating all config nodes > as config false nodes has the same problems, and in addition it has > some problems of its own, e.g., the relocation problem that Andy > mentioned, where leafrefs don't point to the correct leaf, and the > lifecycle problem (where non-configured nodes do nto show up in > state). >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 9 02:54:28 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D17A1B2D61 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 02:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNkUOcvFjB7i for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 02:54:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7911B2D5F for <netmod@ietf.org>; Thu, 9 Apr 2015 02:54:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B0CA08F1; Thu, 9 Apr 2015 11:54:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Vry6-k7MfUNJ; Thu, 9 Apr 2015 11:54:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 11:54:23 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8CF12002B; Thu, 9 Apr 2015 11:54:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gC1s8GQZ2XRQ; Thu, 9 Apr 2015 11:54:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C2A420013; Thu, 9 Apr 2015 11:54:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 729DC32BC60A; Thu, 9 Apr 2015 11:54:20 +0200 (CEST) Date: Thu, 9 Apr 2015 11:54:19 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150409095419.GA27651@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> 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: <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/P3AL5HWMOOo9PjGxDSz218FzhZo> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 09:54:26 -0000 On Thu, Apr 09, 2015 at 11:00:53AM +0200, Ladislav Lhotka wrote: > > > One of the reasons why we failed was IMO that we didn’t dare to move away from the configuration-centric data modelling where almost all relevant semantic constraints are specified for configuration data. > I disagree with the notion that we 'failed'. I believe it is a feature that we validate configuration data and that we resisted to try to validate operational state (which changes dynamically). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 9 03:23:24 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5791B2DFC for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 03:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEK46Z-gUK5X for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 03:23:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1431B2DF7 for <netmod@ietf.org>; Thu, 9 Apr 2015 03:23:20 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:2001:5ee2:74d3:88f2] (unknown [IPv6:2001:1488:fffe:6:2001:5ee2:74d3:88f2]) by mail.nic.cz (Postfix) with ESMTPSA id C724314015E; Thu, 9 Apr 2015 12:23:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1428574998; bh=d1mF1YD+VvUt9s6aIMUOHFYb+kPxX6gbnrQDIt7g5d8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Hhn1tfqqmaRojQm/88eOErrkMDItYZET7tdtS9bTitaUMvkyOzIzPWypaClqARuwn d+nf+YMjWMheqMBm1xUCXk7prOkEBGQ66TqTGVdOFaXnWbJc6aUKp5+29pgFL5aUzY SApvMuUYeiP2vTHluU4dJAxAjlMbetBARNyauEUk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150409095419.GA27651@elstar.local> Date: Thu, 9 Apr 2015 12:23:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96AB4691-2642-4CA8-9E03-4FE8785CB959@nic.cz> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ICnWleSjSwVs3HEAbvtrPoe9cCo> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 10:23:23 -0000 > On 09 Apr 2015, at 11:54, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >=20 > On Thu, Apr 09, 2015 at 11:00:53AM +0200, Ladislav Lhotka wrote: >>=20 >>=20 >> One of the reasons why we failed was IMO that we didn=E2=80=99t dare = to move away from the configuration-centric data modelling where almost = all relevant semantic constraints are specified for configuration data. >>=20 >=20 > I disagree with the notion that we 'failed'. I believe it is a feature Of course I was only talking about = draft-bjorklund-netmod-operational-00. Lada > that we validate configuration data and that we resisted to try to > validate operational state (which changes dynamically). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 9 09:24:56 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896FD1B2E8B for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 09:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlab4uLamuc7 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 09:24:53 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 655111B2E7D for <netmod@ietf.org>; Thu, 9 Apr 2015 09:24:49 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so95205278lbb.0 for <netmod@ietf.org>; Thu, 09 Apr 2015 09:24:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=PE983gS5sYdtDJ6YpGfFXDN4X1weN5GKdKlC0PCn/rM=; b=EGiZL/X28hU9iSbPaocOtbEzVOtmYb/8CbuqoJvNJraDnnmDsEnHVaJ65hHVlVb/ov Amz8FQS6RovDh6gCYVfca6OM6DoPjPDqxPFGitKmXDV57BquZ0lP04AmfdFL4EF5tvk9 be8CWOpVmRfODcxjgybzhCuakKj9p4J3lm4qfea5sV7GejbE1+d2cJhHA00UyRTAvNJ1 kB8yWS7h4Gcq0d+ZODpJm+vwJyDrVqy6bNe7DYIOD/OCx2LsFZMJo83TG6ea2rech+Gd UBsVxcdE/AI82Z2Yt7o7h9YB44CfYxu6B3PmfjcpIFu9+Cum8yZpr9oAE60nDmzpfuu0 /Pdw== X-Gm-Message-State: ALoCoQki7gpGpL3xAvlNjbkMamMCkts8X5iGYwzjRKGXtOZBGTT5nfFVzguTgGcAlkQ+dsOTIiA9 MIME-Version: 1.0 X-Received: by 10.113.4.105 with SMTP id cd9mr28846566lbd.38.1428596687923; Thu, 09 Apr 2015 09:24:47 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 9 Apr 2015 09:24:47 -0700 (PDT) In-Reply-To: <20150409095419.GA27651@elstar.local> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> Date: Thu, 9 Apr 2015 09:24:47 -0700 Message-ID: <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Ladislav Lhotka <lhotka@nic.cz>, =?UTF-8?Q?Martin_Bj=C3=B6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/TchBLU96UBn7kyOAd27g0PTfBJg> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 16:24:54 -0000 On Thu, Apr 9, 2015 at 2:54 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 09, 2015 at 11:00:53AM +0200, Ladislav Lhotka wrote: >> >> >> One of the reasons why we failed was IMO that we didn=E2=80=99t dare to = move away from the configuration-centric data modelling where almost all re= levant semantic constraints are specified for configuration data. >> > > I disagree with the notion that we 'failed'. I believe it is a feature > that we validate configuration data and that we resisted to try to > validate operational state (which changes dynamically). > I also do not understand the comment that we have "configuration-centric" data modeling. NETCONF was chartered to work on a Network Configuration Protocol, so not surprising that it focuses on configuration. It is not a defect or failure that new functionality related to ephemeral config or correlation of config to operational state would require new data modeling and/or protocol features. Failure would be if the leadership did not understand that the protocols, the YANG language, and the data models need to evolve together. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 9 11:03:06 2015 Return-Path: <cwildes@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384231B3053 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 11:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5CDlPzCTMJD for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 11:03:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6991B3055 for <netmod@ietf.org>; Thu, 9 Apr 2015 11:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10198; q=dns/txt; s=iport; t=1428602583; x=1429812183; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6u02pzyQu9uLiYHD2Js6I9h1vw1rvrq/nYCqWltYQrs=; b=TJEbO1djgfFNtvR8XOQE9stirFUBh84mfkR7qT5FkeHGxejb25s3hOxM PACk+nb9eiAGwKOV4fHGwv6LNZ/XemuwP53f+f3iB0rVOyrlDIhbY7X6F ObDoo2/pSlM3HdrCjalUf/o4Ah9NU09jZI97+X2Cw81/GOS5LWWeCd7sd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQD2vSZV/4gNJK1cgwiBLgWDEMkLAhyBKEwBAQEBAQF+hCABAQQjEUUQAgEIDgoCAiYCAgIwFRACBA4FG4gPuACWVwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoKhEkzB4JoL4EWBZB6iguBHYM6gmWJXoNLIoNvb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208";a="410554155" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 09 Apr 2015 18:03:02 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t39I32DC025302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 18:03:02 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.15]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 13:03:02 -0500 From: "Clyde Wildes (cwildes)" <cwildes@cisco.com> To: Martin Bjorklund <mbj@tail-f.com> Thread-Topic: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Thread-Index: AQHQbUJudYHdDoBQEEyPBz3VYG8aJ51CAAMAgAFCO4CAAFg2AIAA+jCAgABOJAA= Date: Thu, 9 Apr 2015 18:03:08 +0000 Message-ID: <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> References: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> <9E933BD9-E257-45F5-B055-CCA24BAA8F1F@cisco.com> <20150409.082319.278951169841775666.mbj@tail-f.com> In-Reply-To: <20150409.082319.278951169841775666.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.157.242] Content-Type: text/plain; charset="utf-8" Content-ID: <49281CFE7801BA4E9F6936010BC15205@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/653IVzrt6EkcIrd1lkVW5NlVygI> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 18:03:05 -0000 SGkgTWFydGluLA0KDQpBbnN3ZXJzIGlubGluZS4uLg0KDQoNCk9uIDQvOC8xNSwgMTE6MjMgUE0s ICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KDQo+SGksDQo+DQo+ IkNseWRlIFdpbGRlcyAoY3dpbGRlcykiIDxjd2lsZGVzQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBI aSBNYXJ0aW4sDQo+PiANCj4+IE15IHJlc3BvbnNlcyBpbmxpbmUuLi4NCj4+IA0KPj4gDQo+PiAN Cj4+IE9uIDQvOC8xNSwgMzoxMiBBTSwgIk1hcnRpbiBCam9ya2x1bmQiIDxtYmpAdGFpbC1mLmNv bT4gd3JvdGU6DQo+PiANCj4+ID5IaSwNCj4+ID4NCj4+ID4iQ2x5ZGUgV2lsZGVzIChjd2lsZGVz KSIgPGN3aWxkZXNAY2lzY28uY29tPiB3cm90ZToNCj4+ID4+IE9uIDQvMi8xNSwgNTo0MiBBTSwg Ik1hcnRpbiBCam9ya2x1bmQiIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+PiA+PiA+byAgR2l2 ZW4gdGhhdCB0aGUgc3RhbmRhcmQgZGVmaW5lcyBhIGZpeGVkIHNldCBvZiAyNCBmYWNpbGl0aWVz LCBpdA0KPj4gPj4gPiAgIHNlZW1zIG9kZCB0aGF0IHRoZSBmYWNpbGl0aWVzIGFyZSBtb2RlbGxl ZCBhcyBpZGVudGl0aWVzLCBhbmQgbm90DQo+PiA+PiA+ICAgYXMgYW4gZW51bWVyYXRpb24uICBV c2luZyBpZGVudGl0aWVzIGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhpcw0KPj4gPj4gPiAg IGlzIGFuIGV4dGVuc2libGUgc2V0IG9mIHZhbHVlcy4NCj4+ID4+IA0KPj4gPj4gW2NseWRlXSBB IG51bWJlciBvZiB2ZW5kb3JzIG5lZWQgdG8gYXVnbWVudCB0aGUgbGlzdCBvZiBmYWNpbGl0aWVz IC0NCj4+ID4+IHNvbWUgd2l0aCBzZXZlcmFsIGh1bmRyZWQgYWRkaXRpb25hbCBmYWNpbGl0aWVz Lg0KPj4gPg0KPj4gPkhvdyBkb2VzIHRoaXMgZXZlbiB3b3JrLCBnaXZlbiB0aGF0IHRoZSBQUklW QUwgaXMgZW5jb2RlZCB3aXRoIDMNCj4+ID5kaWdpdHM/ICBJdCBzZWVtcyB0byBtZSB0aGF0IHRo ZSBtYXhpbXVtIHBvc3NpYmxlIGZhY2lsaXR5IHZhbHVlIGlzDQo+PiA+MTI0Lg0KPj4gPg0KPj4g Pj4gUGxlYXNlIHN1Z2dlc3QgYW4NCj4+ID4+IGFsdGVybmF0aXZlIGNvZGluZyB0aGF0IGNhbiBi ZSB1c2VkIHRvIGFkZCBmYWNpbGl0aWVzIHRocm91Z2gNCj4+ID4+IGF1Z21lbnRhdGlvbi4gSXMg aXQgdGhhdCB3ZSBzaG91bGQgaGF2ZSB0d28gc2VwYXJhdGUgZmFjaWxpdHkgZmllbGRzOg0KPj4g Pj4gUkZDIDU0MjQgKDAtMjQpIGFuZCBWZW5kb3IgU3BlY2lmaWMgc3RhcnRpbmcgYXQgMjQ/DQo+ PiA+DQo+PiA+T25lIG9wdGlvbiBjb3VsZCBiZSB0byBkbzoNCj4+ID4NCj4+ID4gIHR5cGVkZWYg ZmFjaWxpdHkgew0KPj4gPiAgICB0eXBlIHVuaW9uIHsNCj4+ID4gICAgICB0eXBlIGVudW1lcmF0 aW9uIHsNCj4+ID4gICAgICAgIGVudW0ga2VybiAgIHsgdmFsdWUgMDsgfQ0KPj4gPiAgICAgICAg Li4uDQo+PiA+ICAgICAgICBlbnVtIGxvY2FsOCB7IHZhbHVlIDIzOyB9DQo+PiA+ICAgICAgfQ0K Pj4gPiAgICAgIHR5cGUgdWludDE2IHsNCj4+ID4gICAgICAgIHJhbmdlICIyNC4uMTI0IjsgIC8v IG9yIDAuLjk5OQ0KPj4gPiAgICAgIH0NCj4+ID4gICAgfQ0KPj4gPiAgfQ0KPj4gPg0KPj4gPkl0 IGlzIG5vdCBjbGVhciB0byBtZSBpZiB0aGlzIGlzIGFsbG93ZWQgYnkgUkZDIDU0MjQuICBJdCBz YXlzIHRoYXQ6DQo+PiA+DQo+PiA+ICBGYWNpbGl0eSBhbmQgU2V2ZXJpdHkgdmFsdWVzIGFyZSBu b3Qgbm9ybWF0aXZlIGJ1dCBvZnRlbiB1c2VkDQo+PiA+DQo+PiA+QnV0IHRoZW4gaXQgYWxzbyBz YXlzOg0KPj4gPg0KPj4gPiAgRmFjaWxpdHkgdmFsdWVzIE1VU1QgYmUgaW4gdGhlIHJhbmdlIG9m IDAgdG8gMjMgaW5jbHVzaXZlDQo+PiA+DQo+PiA+U28gaWYgd2UgYWxsb3cgb3RoZXIgZmFjaWxp dGllcywgc2hvdWxkbid0IHdlIGFsc28gYWxsb3cgb3RoZXINCj4+ID5zZXJ2ZXJpdGllcz8NCj4+ ID4NCj4+ID5PciBzaG91bGQgd2UgYWxsb3cgdGhlbSB0byBjb25maWd1cmUgcHJpdmFsIDAuLjk5 OT8NCj4+IA0KPj4gW2NseWRlXSBJIGxpa2UgeW91ciBwcm9wb3NhbCB0byByZWNvbW1lbmQgdGhh dCB2ZW5kb3Itc3BlY2lmaWMNCj4+IGlkZW50aXRpZXMgYmUgZGVyaXZlZCBmcm9tIHN0YW5kYXJk IG9uZXMuIEJ1dCB0aGV5IHdpbGwgbm90IHdhbnQgdG8gYmUNCj4+IGNvbmZpbmVkIHRvIHRoZSBi YXNlIHNldCBvZiAyNC4gdGhlcmVmb3JlIHlvdXIgcHJvcG9zYWwgdXNpbmcgYSB1bmlvbg0KPj4g b2YgdGhlIGVudW0gYW5kIHVpbnQxNiBhYm92ZSBzZWVtcyB0byBiZSB0aGUgYmVzdCB3YXkgZm9y d2FyZC4NCj4NCj5CdXQgdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCBoYW5kbGUgdGhlIGNhc2UgdGhh dCBKdWVyZ2VuIGRlc2NyaWJlZCwNCj53aGVyZSBvdGhlciBmYWNpbGl0eSBuYW1lcyBhcmUgbWFw cGVkIHRvIHRoZSBzdGFuZGFyZCB2YWx1ZSBzcGFjZQ0KPigwLi4yMykuDQo+DQo+SSBhc3N1bWUg eW91IG1lYW4gdGhhdCB0aGVzZSB2ZW5kb3JzIGRvIG5vdCBpbXBsZW1lbnQgUkZDIDU0MjQgKHdo aWNoDQo+bGltaXRzIHRoZSBmYWNpbGl0aXkgbnVtYmVycyB0byAwLi4yMyk/ICBDYW4geW91IGRl c2NyaWJlIGluIG1vcmUNCj5kZXRhaWwgc3VjaCBhbiBpbXBsZW1lbnRhdGlvbiwgYW5kIHdoYXQg dGhlIG1lc3NhZ2VzIGxvb2sgbGlrZSBpbiBzdWNoDQo+YSBjYXNlPw0KDQpbY2x5ZGVdIFllcyBz b21lIHZlbmRvcnMgZG8gbm90IGZvbGxvdyBSRkMgNTQyNCBleGFjdGx5IC0gdGhlIGNhc2UgdGhh dCBJIGFtIHRhbGtpbmcgYWJvdXQgaXMgd2hlbiBhIHZlbmRvciBzdXBwb3J0cyAwLi4yMyBhbmQg YWRkcyBhZGRpdGlvbmFsIGZhY2lsaXRpZXMgdG8gdGhlIGxpc3QgYWJvdmUgMjMuIFRoZSB2ZW5k b3IgY3JlYXRlcyBhIG5ldyBmYWNpbGl0eSBjb2RlIGZvciBlYWNoIG1ham9yIHNvZnR3YXJlIGNv bXBvbmVudCBpbiB0aGUgc3lzdGVtIGFuZCBlYWNoIGNvbXBvbmVudCB1c2VzIGl0J3Mgb3duIGZh Y2lsaXR5IHdoZW4gY3JlYXRpbmcgYSBzeXNsb2cgbWVzc2FnZS4gVGhlIG1lc3NhZ2UgcHJpb3Jp dHkgaXMgdGhlIHNhbWUgZXhjZXB0IHRoYXQgdGhlIGZhY2lsaXR5IHJhbmdlcyBmcm9tICggMCB0 byAyMyBwbHVzIGZpcnN0LXZlbmRvci1mYWNpbGl0eSB0byBtYXgtdmVuZG9yLWZhY2lsaXR5ICkg KiA4LiBUaGUgcXVlc3Rpb24gaXMgZG8gd2Ugd2FudCB0byBhbGxvdyB2ZW5kb3JzIHRvIGV4dGVu ZCB0aGUgZmFjaWxpdHkgYW5kIGhvdz8gSSB3b3VsZCBhbnN3ZXIgeWVzLCB3ZSBzaG91bGQgY3Jl YXRlIGEgbW9kZWwgdGhhdCBhbGxvd3MgdmVuZG9ycyB0byBleHRlbmQgdGhlIGZhY2lsaXR5Lg0K DQo+DQo+PiA+PiA+byAgV2h5IGRvIHdlIGhhdmUgdGhlc2U6DQo+PiA+PiA+DQo+PiA+PiA+ICAg IGZlYXR1cmUgZmlsZS1sb2dnaW5nLXN0cnVjdHVyZWQtZGF0YQ0KPj4gPj4gPg0KPj4gPj4gPiAg ICBmZWF0dXJlIHJlbW90ZS1sb2dnaW5nLXN0cnVjdHVyZWQtZGF0YQ0KPj4gPj4gPg0KPj4gPj4g PiAgSSB3b3VsZCBhc3N1bWUgdGhhdCBpZiB0aGUgZGV2aWNlIHN1cHBvcnRzIHN0cnVjdHVyZWQg ZGF0YSwgaXQgd291bGQNCj4+ID4+ID4gIGRvIHNvIHJlZ2FyZGxlc3Mgb2YgbG9nZ2luZyBtZXRo b2Q/ICBJLmUuLCBhIHNpbmdsZSBmZWF0dXJlDQo+PiA+PiA+ICAic3RydWN0dXJlZC1kYXRhIiB3 b3VsZCBiZSBlbm91Z2g/DQo+PiA+PiA+DQo+PiA+PiA+ICBCdXQgaXMgdGhpcyAoc3RydWN0dXJl ZCBkYXRhKSB0eXBpY2FsbHkgY29uZmlndXJhYmxlIGluDQo+PiA+PiA+ICBpbXBsZW1lbnRhdGlv bnMsIGFuZCBpZiBpdCBpcywgaXQgaXMgY29uZmlndXJhYmxlIHBlciAiYWN0aW9uIiBsaWtlDQo+ PiA+PiA+ICB0aGlzPw0KPj4gPj4gDQo+PiA+PiBbY2x5ZGVdIFRoZSBoaXN0b3J5IG9mIHRoaXMg aXMgdGhhdCB3ZSBhZ3JlZWQgdG8gc3VwcG9ydA0KPj4gPj4gZmlsZS1sb2dnaW5nLXN0cnVjdHVy ZWQtZGF0YSBhcyBhIGZlYXR1cmUgKGN1cnJlbnRseSBpbXBsZW1lbnRlZCBieQ0KPj4gPj4gSlVO T1MpIHNpbmNlIGl0IGlzIGNhbGxlZCBvdXQgaW4gUkZDIDU0MjQuIFRoZW4gc29tZW9uZSAoYXQg dGhlIEhhd2FpaQ0KPj4gPj4gbWVldGluZykgYXNrZWQsIGlmIHdlIHN1cHBvcnQgc3RydWN0dXJl ZCBkYXRhIGZvciBmaWxlcywgd2h5IG5vdA0KPj4gPj4gc3VwcG9ydCBmb3IgcmVtb3RlIGxvZ2dp bmcgdG9vPyBBbHRob3VnaCBJIGRvIG5vdCBrbm93IG9mIGFueW9uZSB3aG8NCj4+ID4+IGhhcyBp bXBsZW1lbnRlZCB0aGlzLCBJIGFncmVlZCB0byBzdXBwb3J0IGl0IGZvciByZW1vdGUgbG9nZ2lu ZyBhcyBhDQo+PiA+PiBzZXBhcmF0ZSBmZWF0dXJlLiBXZSBhcmUgdGFsa2luZyBhYm91dCB0d28g ZGlmZmVyZW50IGZ1bmN0aW9uYWxpdGllcw0KPj4gPj4gaGVyZS4gUGVyaGFwcyB0aGUgYmVzdCBz b2x1dGlvbiBpcyB0byByZW1vdmUgcmVtb3RlLWxvZ2dpbmcgc3RydWN0dXJlZA0KPj4gPj4gZGF0 YSBhbmQgbGV0IGl0IGJlIHN1cHBvcnRlZCB0aHJvdWdoIGF1Z21lbnRhdGlvbiBzaG91bGQgYW55 b25lDQo+PiA+PiByZXF1aXJlIGl0IGluIHRoZSBmdXR1cmUuDQo+PiA+DQo+PiA+TGV0IG1lIHRh a2Ugb25lIHN0ZXAgYmFjay4gIFdoYXQgZXhhY3RseSBkb2VzIGl0IG1lYW4gdG86DQo+PiA+DQo+ PiA+ICAgICAgIGxvZyBtZXNzYWdlcyANCj4+ID4gICAgICAgdG8gYSBmaWxlIGluIHN0cnVjdHVy ZWQtZGF0YSBmb3JtYXQgYXMgcGVyIFJGQyA1NDI0DQo+PiA+DQo+PiA+UkZDIDU0MjQgZGVmaW5l cyB0aGUgZm9ybWF0IG9mIGEgc3lzbG9nIG1lc3NhZ2UsIHdpdGggdGhlIHJ1bGUNCj4+ID4iU1lT TE9HLU1TRyIuICBUaGlzIG1lc3NhZ2UgZm9ybWF0IGNvbnRhaW5zIHN0cnVjdHVyZWQgZGF0YS4N Cj4+ID4NCj4+ID5TbyBpZiB5b3UgaGF2ZSBub3QgZW5hYmxlZCBzdHJ1Y3R1cmVkIGRhdGEgKHdp dGggeW91ciBtb2RlbCksIHdoYXQgaXMNCj4+ID50aGUgZXhwZWN0ZWQgZm9ybWF0IG9mIHRoZSBt ZXNzYWdlPyAgRG9lcyBpdCBzdGlsbCBjb250YWluIHRoZSBIRUFERVINCj4+ID5hcyBkZWZpbmVk IGluIDU0MjQsIG9yIGp1c3Qgc29tZSBtZXNzYWdlIGZvcm1hdCAobWF5YmUgYXMgZXhhcGxhaW5l ZA0KPj4gPmluIFJGQyAzMTY0KT8NCj4+IA0KPj4gW2NseWRlXSBQbGVhc2Ugc2VlIFJGQyA1NDI0 IHNlY3Rpb24gNi4wIFN5c2xvZyBNZXNzYWdlDQo+PiBGb3JtYXQuIFNUUlVDVFVSRUQtREFUQSBh dWdtZW50cyB0aGUgc3lzbG9nIG1lc3NhZ2UuIDstKQ0KPg0KPldlbGwsIFNUUlVDVFVSRUQtREFU QSBpcyBvbmUgcGFydCBvZiBTWVNMT0ctTVNHLg0KPg0KPj4gSWYgc3RydWN0dXJlZCBkYXRhIGlz IG9mZiwgdGhlIFNUUlVDVFVSRUQtREFUQSBwb3J0aW9uIG9mIHRoZSBzeXNsb2cNCj4+IG1lc3Nh Z2UgaXMgbm90IHByZXNlbnQgYW5kIGV2ZXJ5dGhpbmcgZWxzZSBpcyBwcmVzZW50Lg0KPg0KPkRv IHlvdSBtZWFuIHRoYXQgaWYgc3RydWN0dXJlZCBkYXRhIGlzIG9mZiwgeW91IHdhbnQgdGhlIG1l c3NhZ2UgdG8NCj5OT1QgZm9sbG93IHRoZSBmb3JtYXQgZGVmaW5lZCBpbiA1NDI0IChpLmUuLCBO T1QgZm9sbG93IFNZU0xPRy1NU0cpLA0KPm9yIGRvIHlvdSBtZWFuIHRoYXQgaWYgc3RydWN0dXJl ZCBkYXRhIGlzIG9mZiwgdGhlIG1lc3NhZ2UgaXMNCj5mb3JtYXR0ZWQgd2l0aCBTVFJVQ1RVUkVE LURBVEEgPSBOSUxWQUxVRT8NCj4NCj5XaGF0ZXZlciB0aGUgYW5zd2VyIGlzLCBpdCBuZWVkcyB0 byBiZSBzcGVjaWZpZWQgc28gdGhhdCBhbg0KPmltcGxlbWVudG9yIGtub3dzIHdoYXQgdG8gZG8u DQo+DQo+U29tZSBleGFtcGxlcyBtaWdodCBoZWxwIGFzIHdlbGwuDQoNCltjbHlkZV0gSWYgc3Ry dWN0dXJlZCBkYXRhIGlzIG9mZiwgdGhlIG1lc3NhZ2UgaXMgZm9ybWF0dGVkIHdpdGggU1RSVUNU VVJFRC1EQVRBID0gTklMVkFMVUUuIEkgd2lsbCBpbmNsdWRlIHRoaXMgaW4gdGhlIGRlc2NyaXB0 aW9uLg0KDQo+DQo+PiA+PiA8bm9uZS8+IGlzIHVzZWZ1bCB3aGVuIHlvdSB3YW50IHRvIHR1cm4g b2ZmIGFjdGlvbnMgdGhhdCBkZWZhdWx0IHRvIG9uDQo+PiA+PiAoc3VjaCBhcyB0aGUgY29uc29s ZSkuDQo+PiA+PiANCj4+ID4+ID4NCj4+ID4+ID4NCj4+ID4+ID5vIFRoZSB1c2FnZSBvZiB0aGUg aW4tbWVtb3J5IGxvZyBidWZmZXIgaXMgYSBiaXQgdW5jbGVhci4gIEkgdGhpbmsgdGhlDQo+PiA+ PiA+ICAgc3BlYyBuZWVkcyB0byBleHBsYWluIGhvdyB0aGlzIGxvZyBidWZmZXIgaXMgc3VwcG9z ZWQgdG8gYmUgdXNlZC4NCj4+ID4+ID4gICBQZXJoYXBzIHdlIHNob3VsZCBhbHNvIHByb3ZpZGUg YSBtZWNoYW5pc20gdG8gcmVhZCB0aGlzIGJ1ZmZlcj8NCj4+ID4+ID4gICBJLmUuLCBwcm92aWRl IGEgY29uZmlnIGZhbHNlIGxpc3Qgb2YgYnVmZmVyZWQgbWVzc2FnZXM/DQo+PiA+PiANCj4+ID4+ IFtjbHlkZV0gSW4tbWVtb3J5IGxvZyBidWZmZXJzIGFyZSBjaXJjdWxhciBxdWV1ZXMgb2YgbG9n DQo+PiA+PiBtZXNzYWdlcy4gTmV0d29yayBlbGVtZW50cyB0aGF0IGNhbiBleHBlcmllbmNlIGxv ZyBtZXNzYWdlIGV2ZW50DQo+PiA+PiBzdG9ybXMgdXNlIGluLW1lbW9yeSBidWZmZXJzIHRvIGF2 b2lkIGxvc3Mgb2Ygc3lzbG9nIG1lc3NhZ2VzLg0KPj4gPg0KPj4gPlRoaXMgZG9lc24ndCBhbnN3 ZXIgbXkgcXVlc3Rpb24gLSBob3cgaXMgdGhlIGJ1ZmZlciBzdXBwb3NlZCB0byBiZQ0KPj4gPnVz ZWQ/DQo+PiANCj4+IFtjbHlkZV0gV2hlbiBhIGhpZ2ggdm9sdW1lIG9mIHN5c2xvZyBtZXNzYWdl cyBpcyBleHBlY3RlZCwgc2F5IGJ5DQo+PiB0dXJuaW5nIG9uIGRlYnVnIGxldmVsIG1lc3NhZ2Vz IG9yIGR1cmluZyBldmVudCBzdG9ybXMsIGJ1ZmZlcmVkDQo+PiBsb2dnaW5nIGNhcHR1cmVzIG1l c3NhZ2UgcmVsaWFibHkgdW50aWwgdGhlIGxvZyBidWZmZXIgaXMgZnVsbCB3aGVuIGl0DQo+PiB3 cmFwcy4gWW91IGFjY2VzcyB0aGUgYnVmZmVyZWQgbG9nIHVzaW5nIGEgInNob3cgbG9nIiBjb21t YW5kIHdoaWNoDQo+PiBkaXNwbGF5cyB0aGUgbWVzc2FnZXMgaW4gdGhlIGJ1ZmZlci4NCj4NCj5U aGlzIG5lZWRzIHRvIGJlIHNwZWNpZmllZCBpbiB0aGUgdGV4dC4gIEFuZCBteSBvcmlnaW5hbCBx dWVzdGlvbg0KPnJlbWFpbnMgLSBzaG91bGQgdGhpcyBkYXRhIG1vZGVsIHByb3ZpZGUgYSBtZWNo YW5pc20gdG8gcmVhZCB0aGlzDQo+YnVmZmVyPyAgSSB0aGluayB3ZSBzaG91bGQgLSBvciByZW1v dmUgdGhlIGJ1ZmZlcmVkLWxvZ2dpbmctYWN0aW9uLg0KDQpbY2x5ZGVdIFdlIGNyZWF0ZWQgYSBj b25maWcgbW9kZWwgYW5kIG9wZXIgZGF0YSBpcyBub3QgaW5jbHVkZWQuIFR5cGljYWxseSBmb3Ig dGhvc2UgdmVuZG9ycyB0aGF0IHN1cHBvcnQgaW4tbWVtb3J5IGxvZyBidWZmZXJzIHRoZSBzaG93 IGNvbW1hbmQgZGVmYXVsdHMgdG8gdGhlIGluLW1lbW9yeSBidWZmZXIgaWYgY29uZmlndXJlZC4N Cg0KVGhhbmtzLA0KDQpDbHlkZQ0KDQoNCj4NCj4NCj4vbWFydGluDQo= From nobody Thu Apr 9 11:42:08 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49B81A8830 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 11:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9xEaFojrE8o for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 11:42:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 482AB1A88E4 for <netmod@ietf.org>; Thu, 9 Apr 2015 11:42:04 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 4C2E91280943; Thu, 9 Apr 2015 20:42:03 +0200 (CEST) Date: Thu, 09 Apr 2015 20:42:03 +0200 (CEST) Message-Id: <20150409.204203.616084923040805879.mbj@tail-f.com> To: cwildes@cisco.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> References: <9E933BD9-E257-45F5-B055-CCA24BAA8F1F@cisco.com> <20150409.082319.278951169841775666.mbj@tail-f.com> <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/c-TPqOqfOYyo71vVwuSKdJomYDI> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 18:42:07 -0000 "Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote: > Hi Martin, > > Answers inline... > > > On 4/8/15, 11:23 PM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > > >Hi, > > > >"Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote: > >> Hi Martin, > >> > >> My responses inline... > >> > >> > >> > >> On 4/8/15, 3:12 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > >> > >> >Hi, > >> > > >> >"Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote: > >> >> On 4/2/15, 5:42 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: > >> >> >o Given that the standard defines a fixed set of 24 facilities, it > >> >> > seems odd that the facilities are modelled as identities, and not > >> >> > as an enumeration. Using identities gives the impression that this > >> >> > is an extensible set of values. > >> >> > >> >> [clyde] A number of vendors need to augment the list of facilities - > >> >> some with several hundred additional facilities. > >> > > >> >How does this even work, given that the PRIVAL is encoded with 3 > >> >digits? It seems to me that the maximum possible facility value is > >> >124. > >> > > >> >> Please suggest an > >> >> alternative coding that can be used to add facilities through > >> >> augmentation. Is it that we should have two separate facility fields: > >> >> RFC 5424 (0-24) and Vendor Specific starting at 24? > >> > > >> >One option could be to do: > >> > > >> > typedef facility { > >> > type union { > >> > type enumeration { > >> > enum kern { value 0; } > >> > ... > >> > enum local8 { value 23; } > >> > } > >> > type uint16 { > >> > range "24..124"; // or 0..999 > >> > } > >> > } > >> > } > >> > > >> >It is not clear to me if this is allowed by RFC 5424. It says that: > >> > > >> > Facility and Severity values are not normative but often used > >> > > >> >But then it also says: > >> > > >> > Facility values MUST be in the range of 0 to 23 inclusive > >> > > >> >So if we allow other facilities, shouldn't we also allow other > >> >serverities? > >> > > >> >Or should we allow them to configure prival 0..999? > >> > >> [clyde] I like your proposal to recommend that vendor-specific > >> identities be derived from standard ones. But they will not want to be > >> confined to the base set of 24. therefore your proposal using a union > >> of the enum and uint16 above seems to be the best way forward. > > > >But this solution does not handle the case that Juergen described, > >where other facility names are mapped to the standard value space > >(0..23). > > > >I assume you mean that these vendors do not implement RFC 5424 (which > >limits the facilitiy numbers to 0..23)? Can you describe in more > >detail such an implementation, and what the messages look like in such > >a case? > > [clyde] Yes some vendors do not follow RFC 5424 exactly - the case > that I am talking about is when a vendor supports 0..23 and adds > additional facilities to the list above 23. The vendor creates a new > facility code for each major software component in the system and each > component uses it's own facility when creating a syslog message. The > message priority is the same except that the facility ranges from ( 0 > to 23 plus first-vendor-facility to max-vendor-facility ) * 8. The > question is do we want to allow vendors to extend the facility and > how? I would answer yes, we should create a model that allows vendors > to extend the facility. Ok. In this case, the model with identities might work pretty well. If a vendor follows 5424 strictly, no additional identities are required. If a vendor has different names (possibly > 24), but still follow the protocol faithfully, additional identities that map to the 24 identities can be defined. And if a vendor doesn't follow the syslog protocol (as you describe above), identities that derive from syslog:syslog-facility can be defined. So the WG needs to decide if this last use case should be supported. > >> >> >o Why do we have these: > >> >> > > >> >> > feature file-logging-structured-data > >> >> > > >> >> > feature remote-logging-structured-data > >> >> > > >> >> > I would assume that if the device supports structured data, it would > >> >> > do so regardless of logging method? I.e., a single feature > >> >> > "structured-data" would be enough? > >> >> > > >> >> > But is this (structured data) typically configurable in > >> >> > implementations, and if it is, it is configurable per "action" like > >> >> > this? > >> >> > >> >> [clyde] The history of this is that we agreed to support > >> >> file-logging-structured-data as a feature (currently implemented by > >> >> JUNOS) since it is called out in RFC 5424. Then someone (at the Hawaii > >> >> meeting) asked, if we support structured data for files, why not > >> >> support for remote logging too? Although I do not know of anyone who > >> >> has implemented this, I agreed to support it for remote logging as a > >> >> separate feature. We are talking about two different functionalities > >> >> here. Perhaps the best solution is to remove remote-logging structured > >> >> data and let it be supported through augmentation should anyone > >> >> require it in the future. > >> > > >> >Let me take one step back. What exactly does it mean to: > >> > > >> > log messages > >> > to a file in structured-data format as per RFC 5424 > >> > > >> >RFC 5424 defines the format of a syslog message, with the rule > >> >"SYSLOG-MSG". This message format contains structured data. > >> > > >> >So if you have not enabled structured data (with your model), what is > >> >the expected format of the message? Does it still contain the HEADER > >> >as defined in 5424, or just some message format (maybe as exaplained > >> >in RFC 3164)? > >> > >> [clyde] Please see RFC 5424 section 6.0 Syslog Message > >> Format. STRUCTURED-DATA augments the syslog message. ;-) > > > >Well, STRUCTURED-DATA is one part of SYSLOG-MSG. > > > >> If structured data is off, the STRUCTURED-DATA portion of the syslog > >> message is not present and everything else is present. > > > >Do you mean that if structured data is off, you want the message to > >NOT follow the format defined in 5424 (i.e., NOT follow SYSLOG-MSG), > >or do you mean that if structured data is off, the message is > >formatted with STRUCTURED-DATA = NILVALUE? > > > >Whatever the answer is, it needs to be specified so that an > >implementor knows what to do. > > > >Some examples might help as well. > > [clyde] If structured data is off, the message is formatted with > STRUCTURED-DATA = NILVALUE. I will include this in the description. Ok, good! > >> >> <none/> is useful when you want to turn off actions that default to on > >> >> (such as the console). > >> >> > >> >> > > >> >> > > >> >> >o The usage of the in-memory log buffer is a bit unclear. I think the > >> >> > spec needs to explain how this log buffer is supposed to be used. > >> >> > Perhaps we should also provide a mechanism to read this buffer? > >> >> > I.e., provide a config false list of buffered messages? > >> >> > >> >> [clyde] In-memory log buffers are circular queues of log > >> >> messages. Network elements that can experience log message event > >> >> storms use in-memory buffers to avoid loss of syslog messages. > >> > > >> >This doesn't answer my question - how is the buffer supposed to be > >> >used? > >> > >> [clyde] When a high volume of syslog messages is expected, say by > >> turning on debug level messages or during event storms, buffered > >> logging captures message reliably until the log buffer is full when it > >> wraps. You access the buffered log using a "show log" command which > >> displays the messages in the buffer. > > > >This needs to be specified in the text. And my original question > >remains - should this data model provide a mechanism to read this > >buffer? I think we should - or remove the buffered-logging-action. > > [clyde] We created a config model and oper data is not > included. Typically for those vendors that support in-memory log > buffers the show command defaults to the in-memory buffer if > configured. But is there value in having a standard config model for this but let vendors define proprietary mechanisms for reading the buffer? Why not also define a way to read the buffer? /martin From nobody Thu Apr 9 12:50:02 2015 Return-Path: <cwildes@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41D1B3161 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 12:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.01 X-Spam-Level: X-Spam-Status: No, score=-13.01 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, IXHASH_X1=1.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtiQ2hEmB-7f for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 12:49:58 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B644B1B319B for <netmod@ietf.org>; Thu, 9 Apr 2015 12:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14570; q=dns/txt; s=iport; t=1428608915; x=1429818515; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=db01HU6G7cXIODNvrcC/NR7DDTjjSpWPMuGfOLN+Yzs=; b=he4M8qymKxsIoCG9t1+ymJodgbbX64/Y0eB0HcdrbG84TbbqNmvlcIYT kaCEaXfShJWEtDoZLI1hmszIJs43gmLYL1bEN1Hu9na37iT30b7r5ea/v esaE7U29N9ZYzL7wq2duO44unFgq6rI3w1A7QlSX4pybTht2xcFQ8IIsk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CMBQAQ1yZV/5pdJa1cgkVDgS4FgxDBP4dUAhyBKzoSAQEBAQEBAX2EHwEBAQQjClwCAQgRAwECKAMCAgIwFAkIAgQBEogquAWWXgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4RYExiCaC+BFgWOa4IWigsBgRyDN4xDg0sig29vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208,217";a="139819445" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 09 Apr 2015 19:48:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t39JmXPT017633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 19:48:33 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.15]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 14:48:33 -0500 From: "Clyde Wildes (cwildes)" <cwildes@cisco.com> To: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] syslog-model-03: list of syslog-selectors vs grouping used in-line Thread-Index: AQHQcv4oCEsMmboE3UWcR8cDZpaBig== Date: Thu, 9 Apr 2015 19:48:39 +0000 Message-ID: <EC6C49DB-EA44-483E-A99F-6282608346C5@cisco.com> References: <A125E53CE190A749957C19483DC79F9F5C9E2D3D@US70TWXCHMBA11.zam.alcatel-lucent.com> In-Reply-To: <A125E53CE190A749957C19483DC79F9F5C9E2D3D@US70TWXCHMBA11.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.157.242] Content-Type: multipart/alternative; boundary="_000_EC6C49DBEA44483EA99F6282608346C5ciscocom_" MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/kscJ5fntSYtwcYfdQfR5dQk8tuU> Subject: Re: [netmod] syslog-model-03: list of syslog-selectors vs grouping used in-line X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 19:50:00 -0000 --_000_EC6C49DBEA44483EA99F6282608346C5ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFzb24sDQoNCkkgcGFzc2VkIHlvdXIgcHJvcG9zYWwgYnkgb25lIG9mIG15IFlBTkcgZG9jdG9y IGZyaWVuZHMgYW5kIEkgaGF2ZSBhZGRlZCBoaXMgcmVzcG9uc2UgaW5saW5lIGJlbG934oCmDQoN Cg0KRnJvbTogPFN0ZXJuZT4sICJKYXNvbiAoSmFzb24pIg0KRGF0ZTogVGh1cnNkYXksIE1hcmNo IDI2LCAyMDE1IGF0IDU6MjYgUE0NClRvOiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RA aWV0Zi5vcmc+Ig0KU3ViamVjdDogW25ldG1vZF0gc3lzbG9nLW1vZGVsLTAzOiBsaXN0IG9mIHN5 c2xvZy1zZWxlY3RvcnMgdnMgZ3JvdXBpbmcgdXNlZCBpbi1saW5lDQoNCkhpIGFsbCwNCg0KVGhl IGN1cnJlbnQgbW9kZWwgdXNlcyB0aGUgc3lzbG9nLXNlbGVjdG9yICdpbi1saW5lJyBpbnNpZGUg ZWFjaCBkaXN0cmlidXRvci9hY3Rpb24gb2JqZWN0LiBTb21lIGltcGxlbWVudGF0aW9ucyBoYXZl IGEgbGlzdCBvZiBzZWxlY3RvciBwb2xpY2llcyBhbmQgdGhlbiB0aGUgZGlzdHJpYnV0b3JzL2Fj dGlvbnMgcmVmZXJlbmNlIGEgc2VsZWN0b3IgcG9saWN5LiBJdCB3b3VsZCBiZSBnb29kIGlmIHRo ZSBtb2RlbCBjYW4gc29tZWhvdyBhY2NvbW1vZGF0ZSB0aGUgbGF0dGVyLiBIZXJlIGlzIGEgcHJv cG9zYWw6DQoNClJlbmFtZSB0aGUgZ3JvdXBpbmcgc3lzbG9nLXNlbGVjdG9yIGdyb3VwaW5nIHRv IHN5c2xvZy1zZWxlY3Rvci1wYXJtcy4NCg0KQ3JlYXRlIGEgbmV3IGdyb3VwaW5nIG9uIHRvcCBv ZiB0aGUgY3VycmVudCBzeXNsb2ctc2VsZWN0b3I6DQogICAgZ3JvdXBpbmcgc3lzbG9nLXNlbGVj dG9yIHsNCiAgICAgICAgY2hvaWNlIHByb2ZpbGUtb3ItaW5saW5lIHsNCiAgICAgICAgICAgIGNh c2UgaW5saW5lIHsNCiAgICAgICAgICAgICAgICB1c2VzIHN5c2xvZy1zZWxlY3Rvci1wYXJtczsN CiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGNhc2UgcHJvZmlsZSB7DQogICAgICAgICAgICAg ICAgLi4ubGVhZnJlZiB0byBhIHN5c2xvZy1zZWxlY3Rvci1wcm9maWxlLi4uDQogICAgICAgICAg ICB9DQogICAgICAgIH0NCiAgICB9DQoNCg0KQWRkIGEgc3lzbG9nIHNlbGVjdG9yIGxpc3Q6DQog ICAgbGlzdCBzeXNsb2ctc2VsZWN0b3ItcHJvZmlsZSB7DQogICAgICAgIGtleSAic3lzbG9nLXNl bC1pZCI7DQogICAgICAgIGxlYWYgc3lzbG9nLXNlbC1pZCB7dHlwZSB1aW50MTY7fQ0KICAgICAg ICB1c2VzIHN5c2xvZy1zZWxlY3Rvci1wYXJtczsNCiAgICB9DQoNCkhhdmluZyBhIGxpc3Qgb2Yg c3lzbG9nIHNlbGVjdG9ycyBpcyBhbHNvIG5pY2UgZm9yIGF1Z21lbnRhdGlvbnMuIFlvdSBjYW4n dCBkaXJlY3RseSBhdWdtZW50IGEgZ3JvdXBpbmcgaW4gWUFORyAtIHlvdSBtdXN0IGF1Z21lbnQg YW4gaW5zdGFuY2Ugb2Ygd2hlcmUgdGhlIGdyb3VwaW5nIGlzIHVzZWQuIFdoZW4gdGhlIGdyb3Vw aW5nIGlzIGlubGluZSBpbiBlYWNoIHN5c2xvZyBkaXN0cmlidXRvci9hY3Rpb24geW91J2QgaGF2 ZSB0byBhdWdtZW50IGluIGVhY2ggb2YgdGhvc2UgcGxhY2VzIHRvIGFkZCBzb21ldGhpbmcgdG8g dGhlIHNlbGVjdG9yIGxvZ2ljLg0KDQoiV2l0aCBhIGNob2ljZSBsaWtlIHRoYXQsIHRoZSAqb3Bl cmF0b3IqIGNhbiBjaG9vc2UgaWYgaGUgd2FudHMgdG8gdXNlIHByb2ZpbGUgb3IgaW5saW5lIHN0 eWxlLiBDb25mb3JtaW5nICppbXBsZW1lbnRhdGlvbnMqIHdvdWxkIGhhdmUgdG8gaW1wbGVtZW50 IGJvdGguIEkgZG9u4oCZdCB0aGluayB0aGF0IHdhcyB0aGUgaW50ZW50LiBJZiBKYXNvbiB3YW50 cyB0byBhbGxvdyBzb21lIGltcGxlbWVudGF0aW9ucyB0byBzdXBwb3J0IGFkZGl0aW9uYWwgZnVu Y3Rpb25hbGl0eSwgaWYtZmVhdHVyZSBpcyB0aGUgc3RhdGVtZW50IHRvIHVzZS4gVGhlcmUgcHJv YmFibHkgaXMgbm8gcmVhbGx5IG5pY2Ugd2F5IHRvIGV4cHJlc3Mgd2hhdCBKYXNvbiBpcyBsb29r aW5nIGZvciB3aXRoIGFuIGlmLWZlYXR1cmUgd2l0aG91dCBtYWtpbmcgZGVlcGVyIG1vZGlmaWNh dGlvbnMgdG8gdGhlIG1vZGVsLiAod2h5IHdvdWxkIHlvdSB3YW50IGEgKm51bWJlciogYXMgcHJv ZmlsZSBpZD8pIi4NCg0KSSBiZWxpZXZlIHRoYXQgdGhpcyB3b3VsZCB3b3JrIGJ1dCBpdCBtYWtl cyB0aGUgbW9kZWwgbW9yZSBjb21wbGljYXRlZC4gQ3JlYXRlIGEgbmV3IGdyb3VwaW5nIG9uIHRv cCBvZiB0aGUgY3VycmVudCBzeXNsb2ctc2VsZWN0b3IgYXMgYWJvdmUgYnV0IGFsd2F5cyByZXF1 aXJlIGEgc3lzbG9nLXNlbGVjdG9yLXByb2ZpbGU6DQoNCiAgICBncm91cGluZyBzeXNsb2ctc2Vs ZWN0b3Igew0KICAgICAgLi4ubGVhZnJlZiB0byBhIHN5c2xvZy1zZWxlY3Rvci1wcm9maWxlLi4u DQogICAgfQ0KDQogICAgbGlzdCBzeXNsb2ctc2VsZWN0b3ItcHJvZmlsZSB7DQogICAgICAgIGtl eSAic3lzbG9nLXNlbC1pZCI7DQogICAgICAgIGxlYWYgc3lzbG9nLXNlbC1pZCB7dHlwZSBzdHJp bmc7fQ0KICAgICAgICB1c2VzIHN5c2xvZy1zZWxlY3Rvci1wYXJtczsNCiAgICB9DQoNClBsZWFz ZSBjb21tZW50Lg0KDQpUaGFua3MsDQoNCkNseWRlDQoNClJlZ2FyZHMsDQpKYXNvbg0KDQo= --_000_EC6C49DBEA44483EA99F6282608346C5ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <E3F93442225A4A4B840804730727AF08@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGRpdj5KYXNvbiw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgcGFzc2VkIHlvdXIg cHJvcG9zYWwgYnkgb25lIG9mIG15IFlBTkcgZG9jdG9yIGZyaWVuZHMgYW5kIEkgaGF2ZSBhZGRl ZCBoaXMgcmVzcG9uc2UgaW5saW5lIGJlbG934oCmPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O IiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAg MCA0MHB4OyBib3JkZXI6bm9uZTsgcGFkZGluZzowcHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNr OyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ QURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGlu OyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJv bTogPC9zcGFuPiZsdDtTdGVybmUmZ3Q7LCAmcXVvdDtKYXNvbiAoSmFzb24pJnF1b3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgTWFy Y2ggMjYsIDIwMTUgYXQgNToyNiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1v ZEBpZXRmLm9yZzwvYT4mcXVvdDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U3ViamVjdDogPC9zcGFuPltuZXRtb2RdIHN5c2xvZy1tb2RlbC0wMzogbGlzdCBvZiBzeXNsb2ct c2VsZWN0b3JzIHZzIGdyb3VwaW5nIHVzZWQgaW4tbGluZTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu OjAgMCAwIDQwcHg7IGJvcmRlcjpub25lOyBwYWRkaW5nOjBweDsiPg0KPG1ldGEgbmFtZT0iR2Vu ZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgRXhjaGFuZ2UgU2VydmVyIj4NCjwhLS0gY29udmVy dGVkIGZyb20gcnRmIC0tPjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFw dDsgcGFkZGluZy1sZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAt LT48L3N0eWxlPjwvYmxvY2txdW90ZT4NCjxkaXY+PGZvbnQgZmFjZT0iQ29uc29sYXMiIHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luOjAgMCAwIDQwcHg7IGJvcmRlcjpub25lOyBwYWRkaW5nOjBweDsiPg0KPGRpdj5IaSBh bGwsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUgY3VycmVudCBtb2RlbCB1c2Vz IHRoZSBzeXNsb2ctc2VsZWN0b3IgJ2luLWxpbmUnIGluc2lkZSBlYWNoIGRpc3RyaWJ1dG9yL2Fj dGlvbiBvYmplY3QuIFNvbWUgaW1wbGVtZW50YXRpb25zIGhhdmUgYSBsaXN0IG9mIHNlbGVjdG9y IHBvbGljaWVzIGFuZCB0aGVuIHRoZSBkaXN0cmlidXRvcnMvYWN0aW9ucyByZWZlcmVuY2UgYSBz ZWxlY3RvciBwb2xpY3kuIEl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIG1vZGVsIGNhbiBzb21laG93 IGFjY29tbW9kYXRlDQogdGhlIGxhdHRlci4gSGVyZSBpcyBhIHByb3Bvc2FsOjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+UmVuYW1lIHRoZSBncm91cGluZyBzeXNsb2ctc2VsZWN0b3Ig Z3JvdXBpbmcgdG8gc3lzbG9nLXNlbGVjdG9yLXBhcm1zLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Q3JlYXRlIGEgbmV3IGdyb3VwaW5nIG9uIHRvcCBvZiB0aGUgY3VycmVudCBzeXNs b2ctc2VsZWN0b3I6PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBncm91cGluZyBzeXNs b2ctc2VsZWN0b3IgezwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY2hvaWNlIHByb2ZpbGUtb3ItaW5saW5lIHs8L2Rpdj4NCjxkaXY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNhc2UgaW5saW5lIHs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHVzZXMgc3lzbG9nLXNlbGVjdG9yLXBhcm1zOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fTwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBwcm9maWxlIHs8L2Rpdj4NCjxkaXY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLmxlYWZyZWYgdG8gYSBzeXNsb2ctc2VsZWN0 b3ItcHJvZmlsZS4uLjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvZGl2Pg0KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvZGl2Pg0KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsgfTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PkFkZCBhIHN5c2xvZyBzZWxlY3RvciBsaXN0OjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJz cDsmbmJzcDsgbGlzdCBzeXNsb2ctc2VsZWN0b3ItcHJvZmlsZSB7PC9kaXY+DQo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgJnF1b3Q7c3lzbG9nLXNl bC1pZCZxdW90Ozs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGxlYWYgc3lzbG9nLXNlbC1pZCB7dHlwZSB1aW50MTY7fTwvZGl2Pg0KPGRpdj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlcyBzeXNsb2ctc2Vs ZWN0b3ItcGFybXM7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyB9PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5IYXZpbmcgYSBsaXN0IG9mIHN5c2xvZyBzZWxlY3RvcnMgaXMg YWxzbyBuaWNlIGZvciBhdWdtZW50YXRpb25zLiBZb3UgY2FuJ3QgZGlyZWN0bHkgYXVnbWVudCBh IGdyb3VwaW5nIGluIFlBTkcgLSB5b3UgbXVzdCBhdWdtZW50IGFuIGluc3RhbmNlIG9mIHdoZXJl IHRoZSBncm91cGluZyBpcyB1c2VkLiBXaGVuIHRoZSBncm91cGluZyBpcyBpbmxpbmUgaW4gZWFj aCBzeXNsb2cgZGlzdHJpYnV0b3IvYWN0aW9uIHlvdSdkIGhhdmUgdG8gYXVnbWVudA0KIGluIGVh Y2ggb2YgdGhvc2UgcGxhY2VzIHRvIGFkZCBzb21ldGhpbmcgdG8gdGhlIHNlbGVjdG9yIGxvZ2lj LjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsg Zm9udC1zaXplOiBtZWRpdW07Ij4mcXVvdDtXaXRoIGEgY2hvaWNlIGxpa2UgdGhhdCwgdGhlICpv cGVyYXRvciogY2FuIGNob29zZSBpZiBoZSB3YW50cyB0byB1c2UgcHJvZmlsZSBvciBpbmxpbmUg c3R5bGUuIENvbmZvcm1pbmcgKmltcGxlbWVudGF0aW9ucyogd291bGQgaGF2ZSB0byBpbXBsZW1l bnQgYm90aC4gSSBkb27igJl0IHRoaW5rIHRoYXQgd2FzIHRoZSBpbnRlbnQuIElmIEphc29uIHdh bnRzDQogdG8gYWxsb3cgc29tZSBpbXBsZW1lbnRhdGlvbnMgdG8gc3VwcG9ydCBhZGRpdGlvbmFs IGZ1bmN0aW9uYWxpdHksIGlmLWZlYXR1cmUgaXMgdGhlIHN0YXRlbWVudCB0byB1c2UuIFRoZXJl IHByb2JhYmx5IGlzIG5vIHJlYWxseSBuaWNlIHdheSB0byBleHByZXNzIHdoYXQgSmFzb24gaXMg bG9va2luZyBmb3Igd2l0aCBhbiBpZi1mZWF0dXJlIHdpdGhvdXQgbWFraW5nIGRlZXBlciBtb2Rp ZmljYXRpb25zIHRvIHRoZSBtb2RlbC4gKHdoeSB3b3VsZA0KIHlvdSB3YW50IGEgKm51bWJlciog YXMgcHJvZmlsZSBpZD8pJnF1b3Q7Ljwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgZm9udC1zaXplOiBt ZWRpdW07Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pkk8c3BhbiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1zaXplOiBtZWRpdW07Ij4mbmJzcDtiZWxpZXZlIHRoYXQgdGhpcyB3 b3VsZCB3b3JrIGJ1dCBpdCBtYWtlcyB0aGUgbW9kZWwgbW9yZSBjb21wbGljYXRlZC4gQ3JlYXRl IGEmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsiPm5ldyBncm91cGlu ZyBvbiB0b3Agb2YgdGhlIGN1cnJlbnQgc3lzbG9nLXNlbGVjdG9yIGFzIGFib3ZlIGJ1dCBhbHdh eXMgcmVxdWlyZQ0KIGEgc3lzbG9nLXNlbGVjdG9yLXByb2ZpbGU6PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpOyBmb250LXNpemU6IG1lZGl1bTsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsiPiZu YnNwOyAmbmJzcDsgZ3JvdXBpbmcgc3lzbG9nLXNlbGVjdG9yIHs8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb25zb2xhczsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IC4uLmxlYWZyZWYg dG8gYSBzeXNsb2ctc2VsZWN0b3ItcHJvZmlsZS4uLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENvbnNvbGFzOyI+Jm5ic3A7ICZuYnNwOyB9PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQ29uc29sYXM7Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhczsiPiZuYnNwOyAmbmJzcDsgbGlzdCBzeXNsb2ctc2VsZWN0b3ItcHJvZmlsZSB7 PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsga2V5ICZxdW90O3N5c2xvZy1zZWwtaWQmcXVv dDs7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBzeXNsb2ctc2VsLWlkIHt0eXBl IHN0cmluZzt9PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlcyBzeXNsb2ctc2VsZWN0 b3ItcGFybXM7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7Ij4mbmJz cDsmbmJzcDsmbmJzcDsgfTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NClBsZWFzZSBj b21tZW50LjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpUaGFua3MsPC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCkNseWRlPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2IGlk PSIiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N Cjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ29uc29sYXMiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luOjAgMCAwIDQwcHg7IGJvcmRlcjpub25lOyBwYWRkaW5nOjBweDsiPg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij5SZWdh cmRzLDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPkphc29uPC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMXB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EC6C49DBEA44483EA99F6282608346C5ciscocom_-- From nobody Thu Apr 9 13:01:16 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7D91B3176 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqvNEBk1G-rK for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:01:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B6E1B3171 for <netmod@ietf.org>; Thu, 9 Apr 2015 13:01:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8C289114C; Thu, 9 Apr 2015 22:01:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4G6OxmeYQT5z; Thu, 9 Apr 2015 22:00:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 22:01:09 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E6E120013; Thu, 9 Apr 2015 22:01:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id amKFY9VmvNVE; Thu, 9 Apr 2015 22:01:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A1DE2002B; Thu, 9 Apr 2015 22:01:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EA50A32BCFFA; Thu, 9 Apr 2015 22:01:05 +0200 (CEST) Date: Thu, 9 Apr 2015 22:01:04 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: "Clyde Wildes (cwildes)" <cwildes@cisco.com> Message-ID: <20150409200102.GC647@elstar.local> Mail-Followup-To: "Clyde Wildes (cwildes)" <cwildes@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> <9E933BD9-E257-45F5-B055-CCA24BAA8F1F@cisco.com> <20150409.082319.278951169841775666.mbj@tail-f.com> <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/eqztkly1uoNhkKg_qgnZJRgZcwk> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 20:01:14 -0000 On Thu, Apr 09, 2015 at 06:03:08PM +0000, Clyde Wildes (cwildes) wrote: > > [clyde] Yes some vendors do not follow RFC 5424 exactly - the case that I am talking about is when a vendor supports 0..23 and adds additional facilities to the list above 23. The vendor creates a new facility code for each major software component in the system and each component uses it's own facility when creating a syslog message. The message priority is the same except that the facility ranges from ( 0 to 23 plus first-vendor-facility to max-vendor-facility ) * 8. The question is do we want to allow vendors to extend the facility and how? I would answer yes, we should create a model that allows vendors to extend the facility. > In a nutshell, the vendor is violating a protocol MUST. Do we have to support implementations that violate protocol MUSTs? This is a difficult question to answer and I think this requires input from people who were involved in the creation of the protocol MUST. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 9 13:05:18 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0A51B3187 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcJOp2255BMF for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:05:14 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB461B318A for <netmod@ietf.org>; Thu, 9 Apr 2015 13:05:08 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 116BA1280AF6; Thu, 9 Apr 2015 22:05:07 +0200 (CEST) Date: Thu, 09 Apr 2015 22:05:05 +0200 (CEST) Message-Id: <20150409.220505.220589316913687460.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150409200102.GC647@elstar.local> References: <20150409.082319.278951169841775666.mbj@tail-f.com> <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> <20150409200102.GC647@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/7FR4mjEv54jEAcUtU00gtl7UDyU> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 20:05:16 -0000 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 09, 2015 at 06:03:08PM +0000, Clyde Wildes (cwildes) wrote: > > > > [clyde] Yes some vendors do not follow RFC 5424 exactly - the case that I am talking about is when a vendor supports 0..23 and adds additional facilities to the list above 23. The vendor creates a new facility code for each major software component in the system and each component uses it's own facility when creating a syslog message. The message priority is the same except that the facility ranges from ( 0 to 23 plus first-vendor-facility to max-vendor-facility ) * 8. The question is do we want to allow vendors to extend the facility and how? I would answer yes, we should create a model that allows vendors to extend the facility. > > > > In a nutshell, the vendor is violating a protocol MUST. Do we have to > support implementations that violate protocol MUSTs? This is a > difficult question to answer and I think this requires input from > people who were involved in the creation of the protocol MUST. One way to handle this is to do the identity solution we discussed, maybe even with the "MUST NOT derive directly from syslog:syslog-facility". The vendors that break the protocol MUST can then break our MUST NOT and add their own facilities. /martin From nobody Thu Apr 9 13:08:38 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FF11B30F0 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfTzKti_yJ_b for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:08:34 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.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 3FA481B30F1 for <netmod@ietf.org>; Thu, 9 Apr 2015 13:08:34 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so99678800lbb.0 for <netmod@ietf.org>; Thu, 09 Apr 2015 13:08:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=EohxmjzAvP+7FaWeSA8tTxiX9yr19qhsZuNITtcyFUI=; b=SkgIufiPrT6eUgNbQOu+2eYWM626hevuDSceEzMmjp4QXrNFb9paEMO5HT0iIU23aN z41WrQiUTkdNWHsWR2SNIqr3JnyZYmlkdQ+lBICkkF5RlkDHcfDLpUvFgNcPZ0CQLK9N YhKvYFHsa1aXWm12oAKVJWijU73jVRb2QPn7YmjYWZmSJfelFequ4I2I8JKK9SQMSzUP V57yTMVRGENyAdWGc6UxXIUSdZtyQEozwDAzUtI3sNB3UCG07MN5Y+FfDAnmRaKrY417 mTOfG269WuK8OWFGreu9q6cuDUt2gLWZqkOF/a3arf0ulSVB+JCJmCyE+43WFy1pGfcA sO1w== X-Gm-Message-State: ALoCoQl92c89PXdqCwFLb95Al94BKzoFzk1ZaF3g4BH9dNk0vC+O8w/EEy2Ey18GwlI9PkMsOuwt MIME-Version: 1.0 X-Received: by 10.152.42.141 with SMTP id o13mr6044570lal.33.1428610112783; Thu, 09 Apr 2015 13:08:32 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 9 Apr 2015 13:08:32 -0700 (PDT) In-Reply-To: <20150409200102.GC647@elstar.local> References: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> <9E933BD9-E257-45F5-B055-CCA24BAA8F1F@cisco.com> <20150409.082319.278951169841775666.mbj@tail-f.com> <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> <20150409200102.GC647@elstar.local> Date: Thu, 9 Apr 2015 13:08:32 -0700 Message-ID: <CABCOCHQkxwxf_rBLQSb2g+66qyoU7nsafyYHGAndXjmAuvhjjQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Clyde Wildes (cwildes)" <cwildes@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/VRZFUza8-jQ87UXM6mPuWBPGO0A> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 20:08:36 -0000 On Thu, Apr 9, 2015 at 1:01 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 09, 2015 at 06:03:08PM +0000, Clyde Wildes (cwildes) wrote: >> >> [clyde] Yes some vendors do not follow RFC 5424 exactly - the case that = I am talking about is when a vendor supports 0..23 and adds additional faci= lities to the list above 23. The vendor creates a new facility code for eac= h major software component in the system and each component uses it's own f= acility when creating a syslog message. The message priority is the same ex= cept that the facility ranges from ( 0 to 23 plus first-vendor-facility to = max-vendor-facility ) * 8. The question is do we want to allow vendors to e= xtend the facility and how? I would answer yes, we should create a model th= at allows vendors to extend the facility. >> > > In a nutshell, the vendor is violating a protocol MUST. Do we have to > support implementations that violate protocol MUSTs? This is a > difficult question to answer and I think this requires input from > people who were involved in the creation of the protocol MUST. > I know it is not possible in this case, but your comment is an excellent su= mmary of why protocol WGs should be writing their own YANG modules, and not NETMO= D WG. > /js Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 9 13:19:42 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B729D1A8977 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQD1v7tAveC5 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:19:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F6A1A894E for <netmod@ietf.org>; Thu, 9 Apr 2015 13:19:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A18811151; Thu, 9 Apr 2015 22:19:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PkMg7LQ-Nv5L; Thu, 9 Apr 2015 22:19:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 22:19:36 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B51F62002B; Thu, 9 Apr 2015 22:19:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2qBYnvVpmgZO; Thu, 9 Apr 2015 22:19:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F9BE20013; Thu, 9 Apr 2015 22:19:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0943432BD0BA; Thu, 9 Apr 2015 22:19:32 +0200 (CEST) Date: Thu, 9 Apr 2015 22:19:31 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150409201928.GE647@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, "Clyde Wildes (cwildes)" <cwildes@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> <20150408.121209.2229937792289064739.mbj@tail-f.com> <9E933BD9-E257-45F5-B055-CCA24BAA8F1F@cisco.com> <20150409.082319.278951169841775666.mbj@tail-f.com> <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> <20150409200102.GC647@elstar.local> <CABCOCHQkxwxf_rBLQSb2g+66qyoU7nsafyYHGAndXjmAuvhjjQ@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHQkxwxf_rBLQSb2g+66qyoU7nsafyYHGAndXjmAuvhjjQ@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/QDrLfZKYarHzktt0FvJWA1_HoWw> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 20:19:40 -0000 On Thu, Apr 09, 2015 at 01:08:32PM -0700, Andy Bierman wrote: > On Thu, Apr 9, 2015 at 1:01 PM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: > > On Thu, Apr 09, 2015 at 06:03:08PM +0000, Clyde Wildes (cwildes) wrote: > >> > >> [clyde] Yes some vendors do not follow RFC 5424 exactly - the case that I am talking about is when a vendor supports 0..23 and adds additional facilities to the list above 23. The vendor creates a new facility code for each major software component in the system and each component uses it's own facility when creating a syslog message. The message priority is the same except that the facility ranges from ( 0 to 23 plus first-vendor-facility to max-vendor-facility ) * 8. The question is do we want to allow vendors to extend the facility and how? I would answer yes, we should create a model that allows vendors to extend the facility. > >> > > > > In a nutshell, the vendor is violating a protocol MUST. Do we have to > > support implementations that violate protocol MUSTs? This is a > > difficult question to answer and I think this requires input from > > people who were involved in the creation of the protocol MUST. > > > > I know it is not possible in this case, but your comment is an > excellent summary of why protocol WGs should be writing their own > YANG modules, and not NETMOD WG. The reason we do the SYSLOG model in NETMOD is because there is no SYSLOG WG anymore. I would be really happy if people who actively contributed to the SYSLOG WG would be involved in the data model work as well. At the end, getting the right people involved matters, not so much how the WG is called. I tried to reach out to some of those people in order to get them involved but I do also understand why they prefer not to follow the NETMOD mailing - where most of the messages are not related to SYSLOG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 9 13:21:51 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BB71B31C9 for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJDoyZGSGgTj for <netmod@ietfa.amsl.com>; Thu, 9 Apr 2015 13:21:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61ACF1B31C8 for <netmod@ietf.org>; Thu, 9 Apr 2015 13:21:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 319D41151; Thu, 9 Apr 2015 22:21:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id an51K_TO7APA; Thu, 9 Apr 2015 22:21:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 22:21:44 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B0D02002B; Thu, 9 Apr 2015 22:21:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tax4IXSXzIRT; Thu, 9 Apr 2015 22:21:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC5E020013; Thu, 9 Apr 2015 22:21:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5D2B532BD135; Thu, 9 Apr 2015 22:21:39 +0200 (CEST) Date: Thu, 9 Apr 2015 22:21:38 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Martin Bjorklund <mbj@tail-f.com> Message-ID: <20150409202136.GF647@elstar.local> Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, cwildes@cisco.com, netmod@ietf.org References: <20150409.082319.278951169841775666.mbj@tail-f.com> <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> <20150409200102.GC647@elstar.local> <20150409.220505.220589316913687460.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150409.220505.220589316913687460.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/0KvMOFZ5I9hyXO_edD5bDGUJYiY> Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 09 Apr 2015 20:21:48 -0000 On Thu, Apr 09, 2015 at 10:05:05PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > On Thu, Apr 09, 2015 at 06:03:08PM +0000, Clyde Wildes (cwildes) wrote: > > > > > > [clyde] Yes some vendors do not follow RFC 5424 exactly - the case that I am talking about is when a vendor supports 0..23 and adds additional facilities to the list above 23. The vendor creates a new facility code for each major software component in the system and each component uses it's own facility when creating a syslog message. The message priority is the same except that the facility ranges from ( 0 to 23 plus first-vendor-facility to max-vendor-facility ) * 8. The question is do we want to allow vendors to extend the facility and how? I would answer yes, we should create a model that allows vendors to extend the facility. > > > > > > > In a nutshell, the vendor is violating a protocol MUST. Do we have to > > support implementations that violate protocol MUSTs? This is a > > difficult question to answer and I think this requires input from > > people who were involved in the creation of the protocol MUST. > > One way to handle this is to do the identity solution we discussed, > maybe even with the "MUST NOT derive directly from > syslog:syslog-facility". The vendors that break the protocol MUST can > then break our MUST NOT and add their own facilities. > This is then at least formally consistent. Whatever the reason for the protocol MUST has been... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 10 01:37:29 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFD51B2AFA for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 01:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHTn9tEi_hZt for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 01:37:26 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6791B2ABE for <netmod@ietf.org>; Fri, 10 Apr 2015 01:37:25 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C3E661CC00B4; Fri, 10 Apr 2015 10:37:27 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin =?utf-8?Q?Bj=C3=B6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod\@ietf.org" <netmod@ietf.org> In-Reply-To: <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 10 Apr 2015 10:37:21 +0200 Message-ID: <m21tjsbcqm.fsf@birdie.labs.nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/-JR_kADM7ibISi89s19auVjXTgc> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 08:37:28 -0000 Andy Bierman <andy@yumaworks.com> writes: > On Thu, Apr 9, 2015 at 2:54 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: >> On Thu, Apr 09, 2015 at 11:00:53AM +0200, Ladislav Lhotka wrote: >>> >>> >>> One of the reasons why we failed was IMO that we didn=E2=80=99t dare to= move away from the configuration-centric data modelling where almost all r= elevant semantic constraints are specified for configuration data. >>> >> >> I disagree with the notion that we 'failed'. I believe it is a feature >> that we validate configuration data and that we resisted to try to >> validate operational state (which changes dynamically). >> > > I also do not understand the comment that we have "configuration-centric" > data modeling. NETCONF was chartered to work on a Network > Configuration Protocol, so not surprising that it focuses on > configuration. Validity of a configuration may depend on things that are external to it - such a configuration in itself can satisfy all constraints of a data model but still be in conflict with the current state of the device, and has to be rejected. This becomes really important when there are mechanisms that modify the state but don't sync the changes with NETCONF configuration datastores. Maybe this is not everybody's problem but I do work with devices where this possibility has to be addressed. Lada > > It is not a defect or failure that new functionality related to > ephemeral config or correlation of config to operational state > would require new data modeling and/or protocol features. > > Failure would be if the leadership did not understand that the > protocols, the YANG language, and the data models need to > evolve together. > > >> /js >> > > Andy > >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 10 03:33:43 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8B21B2BC6 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 03:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA8GHFTrh7c3 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 03:33:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBA71B2BC7 for <netmod@ietf.org>; Fri, 10 Apr 2015 03:33:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 425E8115A; Fri, 10 Apr 2015 12:33:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id t0eKB-k8LZzm; Fri, 10 Apr 2015 12:33:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Apr 2015 12:33:38 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 596A72002B; Fri, 10 Apr 2015 12:33:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id p_1VShZfi3sV; Fri, 10 Apr 2015 12:33:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A91DE2002C; Fri, 10 Apr 2015 12:33:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AEF2932BD8D8; Fri, 10 Apr 2015 12:33:34 +0200 (CEST) Date: Fri, 10 Apr 2015 12:33:34 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150410103334.GA2626@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <m21tjsbcqm.fsf@birdie.labs.nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/3eiRGHyDfCLTVtx2LicJAw_YGfg> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 10:33:42 -0000 On Fri, Apr 10, 2015 at 10:37:21AM +0200, Ladislav Lhotka wrote: > > Validity of a configuration may depend on things that are external to it > - such a configuration in itself can satisfy all constraints of a data > model but still be in conflict with the current state of the device, and > has to be rejected. > > This becomes really important when there are mechanisms that modify the > state but don't sync the changes with NETCONF configuration > datastores. Maybe this is not everybody's problem but I do work with > devices where this possibility has to be addressed. > Yes, operational state can differ from config state. I think we understand that pretty well since the IAB workshop. There is nothing new here (except that perhaps some people describe this same idea now with different terms). Your idea of extending validity of configuration as we have it today to validity of configuration with regard to operational state (which is changing dynamically and also impacted by device and implementation constraints) scares me a lot. The ultimate arbitrator is the device and it is an illusion to believe they will all handle all possible conflict situations in the same way. We may be able to control this process for ephemeral datastores as they are newly designed (so we can design in rules and priorities) but everything beyond that scares me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 10 04:26:02 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1349C1B2C77 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 04:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCcp_53skRdR for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 04:26:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141091B2C67 for <netmod@ietf.org>; Fri, 10 Apr 2015 04:25:59 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id EA75613F64F; Fri, 10 Apr 2015 13:25:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1428665157; bh=zqgdhqPByLDyGXbpWgUE3nghj7tdOQt8DExtNi19cUc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vmygq80cQVwsNSO0FYPN3V/g6FwwN2eLQWmRTuNnRXBcM+OTG9qSPCT74W179PNzR 2h/5ocNKPAMeLFsj265AlVMzTO0y0hpCxziJ1RYEiKfv6rryEVa68RrhNRKbzCGm6R a4YEDjJZ/EFXC/bS5XapPjHHofM4YxTGMoUjLjFM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150410103334.GA2626@elstar.local> Date: Fri, 10 Apr 2015 13:25:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/IhQsj1TFDAv4wx_nGMmuVi5A8Ww> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 11:26:02 -0000 > On 10 Apr 2015, at 12:33, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >=20 > On Fri, Apr 10, 2015 at 10:37:21AM +0200, Ladislav Lhotka wrote: >>=20 >> Validity of a configuration may depend on things that are external to = it >> - such a configuration in itself can satisfy all constraints of a = data >> model but still be in conflict with the current state of the device, = and >> has to be rejected. >>=20 >> This becomes really important when there are mechanisms that modify = the >> state but don't sync the changes with NETCONF configuration >> datastores. Maybe this is not everybody's problem but I do work with >> devices where this possibility has to be addressed. >>=20 >=20 > Yes, operational state can differ from config state. I think we > understand that pretty well since the IAB workshop. There is nothing > new here (except that perhaps some people describe this same idea now > with different terms). Does RFC 6241 really discriminate between running config and state? o running configuration datastore: A configuration datastore holding the complete configuration currently active on the device. What does =E2=80=9Ccurrently active=E2=80=9D mean? If a parameter = changes in running, does it mean that it becomes the value that=E2=80=99s = used operationally? Immediately or eventually? If such a state parameter = is changed through other means, will the (different) value in running = override it, and if so, when? >=20 > Your idea of extending validity of configuration as we have it today > to validity of configuration with regard to operational state (which > is changing dynamically and also impacted by device and implementation > constraints) scares me a lot. The ultimate arbitrator is the device > and it is an illusion to believe they will all handle all possible > conflict situations in the same way. I am not saying an upfront validation can catch everything, run-time = errors certainly cannot be avoided. On the other hand, I do claim that = some validity errors could be discovered if state is also taken into = account. Since we allow system-controlled list entries that may exist = only in *-state lists, some properties such as =E2=80=9Cunique=E2=80=9D = leafs need to be satisfied in the state version of the list. Lada >=20 > We may be able to control this process for ephemeral datastores as > they are newly designed (so we can design in rules and priorities) but > everything beyond that scares me. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 10 04:45:07 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3331B2CAF for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 04:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bX3Gozt-p38o for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 04:44:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375941B2CA5 for <netmod@ietf.org>; Fri, 10 Apr 2015 04:44:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 088D7110F; Fri, 10 Apr 2015 13:44:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BBqk_J4ZZoJ8; Fri, 10 Apr 2015 13:44:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Apr 2015 13:44:53 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 466972002B; Fri, 10 Apr 2015 13:44:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Tbm8qxGyJ3jx; Fri, 10 Apr 2015 13:44:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 717F420013; Fri, 10 Apr 2015 13:44:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A754932BDA0E; Fri, 10 Apr 2015 13:44:49 +0200 (CEST) Date: Fri, 10 Apr 2015 13:44:49 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150410114448.GA2830@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> 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: <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/r9M7owwXPajELGk-kCg_cG49Qmc> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 11:44:57 -0000 On Fri, Apr 10, 2015 at 01:25:56PM +0200, Ladislav Lhotka wrote: > > > On 10 Apr 2015, at 12:33, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > > > On Fri, Apr 10, 2015 at 10:37:21AM +0200, Ladislav Lhotka wrote: > >> > >> Validity of a configuration may depend on things that are external to it > >> - such a configuration in itself can satisfy all constraints of a data > >> model but still be in conflict with the current state of the device, and > >> has to be rejected. > >> > >> This becomes really important when there are mechanisms that modify the > >> state but don't sync the changes with NETCONF configuration > >> datastores. Maybe this is not everybody's problem but I do work with > >> devices where this possibility has to be addressed. > >> > > > > Yes, operational state can differ from config state. I think we > > understand that pretty well since the IAB workshop. There is nothing > > new here (except that perhaps some people describe this same idea now > > with different terms). > > Does RFC 6241 really discriminate between running config and state? > > o running configuration datastore: A configuration datastore holding > the complete configuration currently active on the device. > > What does “currently active” mean? If a parameter changes in running, does it mean that it becomes the value that’s used operationally? Immediately or eventually? If such a state parameter is changed through other means, will the (different) value in running override it, and if so, when? > I recommend reading RFC 6244 Section 4.3.2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 10 04:59:18 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E231B2CD1 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 04:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4Qf9z9T2rIH for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 04:59:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195FC1B2CCC for <netmod@ietf.org>; Fri, 10 Apr 2015 04:59:14 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id DCF3813FE1C; Fri, 10 Apr 2015 13:59:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1428667152; bh=D2yHiirgADsRVSLHd/99940+FgqWDKbe5SIkJGKiSGM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=suqY3CJT5zm3KaS1xhf+0hxBaF5Af2V3TY5e8RKX3jbXhO1S8J1oE64/B5iwTBgXD ZIJF6ys6yx+JnrWWAsdZwfOfNwz4GONUuhifP5FzfO580SYHJe+L3QRsss7jvVidJ+ O9kMaEOA/+7LqBeE6Wvj16RMllHSVT6DnoY4zLwA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150410114448.GA2830@elstar.local> Date: Fri, 10 Apr 2015 13:59:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> References: <etPan.5523c4ee.66ef438d.855@corretto.local> <CABCOCHTWytA5j0HB1-vvWRL6qamofAZW8DRUZtdOX-QotpydKg@mail.gmail.com> <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/odx-qoYQtwGsT8fSV06g4uuXcZc> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 11:59:17 -0000 > On 10 Apr 2015, at 13:44, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >=20 > On Fri, Apr 10, 2015 at 01:25:56PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 10 Apr 2015, at 12:33, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>=20 >>> On Fri, Apr 10, 2015 at 10:37:21AM +0200, Ladislav Lhotka wrote: >>>>=20 >>>> Validity of a configuration may depend on things that are external = to it >>>> - such a configuration in itself can satisfy all constraints of a = data >>>> model but still be in conflict with the current state of the = device, and >>>> has to be rejected. >>>>=20 >>>> This becomes really important when there are mechanisms that modify = the >>>> state but don't sync the changes with NETCONF configuration >>>> datastores. Maybe this is not everybody's problem but I do work = with >>>> devices where this possibility has to be addressed. >>>>=20 >>>=20 >>> Yes, operational state can differ from config state. I think we >>> understand that pretty well since the IAB workshop. There is nothing >>> new here (except that perhaps some people describe this same idea = now >>> with different terms). >>=20 >> Does RFC 6241 really discriminate between running config and state? >>=20 >> o running configuration datastore: A configuration datastore = holding >> the complete configuration currently active on the device. >>=20 >> What does =E2=80=9Ccurrently active=E2=80=9D mean? If a parameter = changes in running, does it mean that it becomes the value that=E2=80=99s = used operationally? Immediately or eventually? If such a state parameter = is changed through other means, will the (different) value in running = override it, and if so, when? >>=20 >=20 > I recommend reading RFC 6244 Section 4.3.2. Maybe I can=E2=80=99t properly read between the lines but I don=E2=80=99t = see an answer to ANY of my questions there. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 10 05:24:23 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114E01B2F0C for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 05:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6VFLI-AD21u for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 05:24:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC75E1B2EF2 for <netmod@ietf.org>; Fri, 10 Apr 2015 05:24:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BDC521159; Fri, 10 Apr 2015 14:24:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qeNp5D7nr3ED; Fri, 10 Apr 2015 14:23:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Apr 2015 14:24:17 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 828452002B; Fri, 10 Apr 2015 14:24:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YMwtLB_9-cUN; Fri, 10 Apr 2015 14:24:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FAE120013; Fri, 10 Apr 2015 14:24:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9401E32BDC0D; Fri, 10 Apr 2015 14:24:15 +0200 (CEST) Date: Fri, 10 Apr 2015 14:24:15 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150410122415.GC2969@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> References: <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> 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: <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/6_cQqEuyHtyW2ZFQc_IAl5xl0ZI> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 12:24:22 -0000 On Fri, Apr 10, 2015 at 01:59:12PM +0200, Ladislav Lhotka wrote: > > > On 10 Apr 2015, at 13:44, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > > > On Fri, Apr 10, 2015 at 01:25:56PM +0200, Ladislav Lhotka wrote: > >> > >>> On 10 Apr 2015, at 12:33, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > >>> > >>> On Fri, Apr 10, 2015 at 10:37:21AM +0200, Ladislav Lhotka wrote: > >>>> > >>>> Validity of a configuration may depend on things that are external to it > >>>> - such a configuration in itself can satisfy all constraints of a data > >>>> model but still be in conflict with the current state of the device, and > >>>> has to be rejected. > >>>> > >>>> This becomes really important when there are mechanisms that modify the > >>>> state but don't sync the changes with NETCONF configuration > >>>> datastores. Maybe this is not everybody's problem but I do work with > >>>> devices where this possibility has to be addressed. > >>>> > >>> > >>> Yes, operational state can differ from config state. I think we > >>> understand that pretty well since the IAB workshop. There is nothing > >>> new here (except that perhaps some people describe this same idea now > >>> with different terms). > >> > >> Does RFC 6241 really discriminate between running config and state? > >> > >> o running configuration datastore: A configuration datastore holding > >> the complete configuration currently active on the device. > >> > >> What does “currently active” mean? If a parameter changes in running, does it mean that it becomes the value that’s used operationally? Immediately or eventually? If such a state parameter is changed through other means, will the (different) value in running override it, and if so, when? > >> > > > > I recommend reading RFC 6244 Section 4.3.2. > > Maybe I can’t properly read between the lines but I don’t see an answer to ANY of my questions there. > config = configuration data (as in RFC 6244 Section 4.3.2) config != current operational state (as in RFC 6244 Section 4.3.2) running config = configuration data currently used startup config = configuration data used at next startup => running config != current operational state The device implementation arbitrates and decides. Config is passed to the device at certain events (e.g., when the config is loaded or a change committed or the device or a function of it restarted). From the perspective of the internal code, config is one of the many sources of information that tells it how to behave. Control protocols inject additional information, the device learns additional information, the device has limitations and policies that tell it how to arbitrate the information. NETCONF validates configuration data in configuration datastores. And going beyond that is IMHO not feasible nor helpful. What matters operationally is what the device actually does. This is represented by the operational state. What a device actually does might not be valid (due to bugs, resource limitations, hardware changes, broken control protocols, bad karma, whatever). Network management systems have to check whether device behavior do matches the expectations. This check is essential and can't be replaced by validation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 10 08:20:14 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781B91A1B1E for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 08:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ4Gatk5QY_0 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 08:20:12 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2241A1AF0 for <netmod@ietf.org>; Fri, 10 Apr 2015 08:20:11 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so16206120lbb.0 for <netmod@ietf.org>; Fri, 10 Apr 2015 08:20:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=p6To+iWBcCOls5BsRuQPSO6HEFsRAnSB33b/7W05eHA=; b=TeYz6aXIjMG0S12IR7l1VM1MCl3yXPkl9zCpnqH4+T89MW22iR3sc76iWKSoAIn9+0 ba9P6UJEFWmSJxBswpA1EYC6aJnSYrL4rM4SNJdjzgOeaYb54FraOPyqeZ7wTKq0vG0w DsP8O20heo4QR9c31BjWK7sTBQEQ8W/QUzg0MTUU4zQOcG4QgT04NF30jCabjzIwIu8M u2o7y5RrXR3h3UUrTCZpbY8secC+uIXEiHN9niDnpW5205Zq0xt5Gjs/IDxNWzcqN+7A Cwxjd6ZF39kPzC6F1Hf8CAzZSu1CIylgmr8CTydfmZMpg3Avn1xCBXjxKH1RNFPipIjy UeGA== X-Gm-Message-State: ALoCoQlzkxYpHtDINMA2Q1c9YeT8YAml8OqgIeVUF1il1SWM+UB0+Cyb+ZhtGQnzRrmteCpTzUwq MIME-Version: 1.0 X-Received: by 10.112.56.42 with SMTP id x10mr1878902lbp.123.1428679209992; Fri, 10 Apr 2015 08:20:09 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 10 Apr 2015 08:20:09 -0700 (PDT) In-Reply-To: <20150410122415.GC2969@elstar.local> References: <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> <20150410122415.GC2969@elstar.local> Date: Fri, 10 Apr 2015 08:20:09 -0700 Message-ID: <CABCOCHQtVosOPWUj_yhDATFcBnJ_1KEi6sjmWNJpmZz1do6+2Q@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, =?UTF-8?Q?Martin_Bj=C3=B6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/GgHPBII76Du2-Rz1Wkx8YL-kJD0> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 15:20:13 -0000 On Fri, Apr 10, 2015 at 5:24 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Apr 10, 2015 at 01:59:12PM +0200, Ladislav Lhotka wrote: >> >> > On 10 Apr 2015, at 13:44, Juergen Schoenwaelder <j.schoenwaelder@jacob= s-university.de> wrote: >> > >> > On Fri, Apr 10, 2015 at 01:25:56PM +0200, Ladislav Lhotka wrote: >> >> >> >>> On 10 Apr 2015, at 12:33, Juergen Schoenwaelder <j.schoenwaelder@jac= obs-university.de> wrote: >> >>> >> >>> On Fri, Apr 10, 2015 at 10:37:21AM +0200, Ladislav Lhotka wrote: >> >>>> >> >>>> Validity of a configuration may depend on things that are external = to it >> >>>> - such a configuration in itself can satisfy all constraints of a d= ata >> >>>> model but still be in conflict with the current state of the device= , and >> >>>> has to be rejected. >> >>>> >> >>>> This becomes really important when there are mechanisms that modify= the >> >>>> state but don't sync the changes with NETCONF configuration >> >>>> datastores. Maybe this is not everybody's problem but I do work wit= h >> >>>> devices where this possibility has to be addressed. >> >>>> >> >>> >> >>> Yes, operational state can differ from config state. I think we >> >>> understand that pretty well since the IAB workshop. There is nothing >> >>> new here (except that perhaps some people describe this same idea no= w >> >>> with different terms). >> >> >> >> Does RFC 6241 really discriminate between running config and state? >> >> >> >> o running configuration datastore: A configuration datastore holdi= ng >> >> the complete configuration currently active on the device. >> >> >> >> What does =E2=80=9Ccurrently active=E2=80=9D mean? If a parameter cha= nges in running, does it mean that it becomes the value that=E2=80=99s used= operationally? Immediately or eventually? If such a state parameter is cha= nged through other means, will the (different) value in running override it= , and if so, when? >> >> >> > >> > I recommend reading RFC 6244 Section 4.3.2. >> >> Maybe I can=E2=80=99t properly read between the lines but I don=E2=80=99= t see an answer to ANY of my questions there. >> > > config =3D configuration data (as in RFC 6244 Section 4.3.2) > > config !=3D current operational state (as in RFC 6244 Section 4.3.2) > > running config =3D configuration data currently used > > startup config =3D configuration data used at next startup > > =3D> running config !=3D current operational state > > The device implementation arbitrates and decides. Config is passed to > the device at certain events (e.g., when the config is loaded or a > change committed or the device or a function of it restarted). From > the perspective of the internal code, config is one of the many > sources of information that tells it how to behave. Control protocols > inject additional information, the device learns additional > information, the device has limitations and policies that tell it how > to arbitrate the information. > > NETCONF validates configuration data in configuration datastores. And > going beyond that is IMHO not feasible nor helpful. What matters > operationally is what the device actually does. This is represented by > the operational state. What a device actually does might not be valid > (due to bugs, resource limitations, hardware changes, broken control > protocols, bad karma, whatever). Network management systems have to > check whether device behavior do matches the expectations. This check > is essential and can't be replaced by validation. > +1 Validation of the configuration MUST NOT include the operational state. The config represents the desired state of operator controlled settings. There may be lots of ways for the system to behave in response to the config contents. Some operational state will never mirror the config (e.g., duplex=3Dauto). Some operational state will reflect higher priority ephemeral config (from I2RS). Some operational state will reflect problems in the network preventing the operator's settings from being used. Proper network management protocol mechanisms are needed to understand the current operational state of a device. The I2RS pub/sub work might be the right hammer for this nail. The problem is not the YANG config-stmt, or the lack of 'config' containers. > /js Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 10 09:41:26 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03141AD357 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1BZVAT6ULA9 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 09:41:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25C21AD359 for <netmod@ietf.org>; Fri, 10 Apr 2015 09:41:22 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 3484F14004B; Fri, 10 Apr 2015 18:41:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1428684080; bh=TwJBZk5cL5GU3Lps5uBgyNpSDm7VNFhgQnepXaOgmLw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lZnAcQBepIeWg02ni1nK+gcQ2NT4lLB68zsVNRWKGdqYgtH1cWbIbdBPuh600H1EN YWcluNGJ6ykEQUcUGT8OzEFOt91JqtQ7XD5xjQ+fGz08pb4g+FfrHhW6Ei8Ju2fhs/ Gn6umKbauvwUwMAnuA2BXIYNCHXUPDYcb7yUXhKs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <CABCOCHQtVosOPWUj_yhDATFcBnJ_1KEi6sjmWNJpmZz1do6+2Q@mail.gmail.com> Date: Fri, 10 Apr 2015 18:41:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <980C74F5-A0DD-4E59-9886-FCAAB66C60BD@nic.cz> References: <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> <20150410122415.GC2969@elstar.local> <CABCOCHQtVosOPWUj_yhDATFcBnJ_1KEi6sjmWNJpmZz1do6+2Q@mail.gmail.com> To: Andy Bierman <andy@yumaworks.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/5zOFWLQ8zqgdzG_nowJGAUkdjME> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 16:41:25 -0000 > On 10 Apr 2015, at 17:20, Andy Bierman <andy@yumaworks.com> wrote: >=20 > On Fri, Apr 10, 2015 at 5:24 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: >> On Fri, Apr 10, 2015 at 01:59:12PM +0200, Ladislav Lhotka wrote: >>>=20 >>>> On 10 Apr 2015, at 13:44, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>=20 >>>> On Fri, Apr 10, 2015 at 01:25:56PM +0200, Ladislav Lhotka wrote: >>>>>=20 >>>>>> On 10 Apr 2015, at 12:33, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>=20 >>>>>> On Fri, Apr 10, 2015 at 10:37:21AM +0200, Ladislav Lhotka wrote: >>>>>>>=20 >>>>>>> Validity of a configuration may depend on things that are = external to it >>>>>>> - such a configuration in itself can satisfy all constraints of = a data >>>>>>> model but still be in conflict with the current state of the = device, and >>>>>>> has to be rejected. >>>>>>>=20 >>>>>>> This becomes really important when there are mechanisms that = modify the >>>>>>> state but don't sync the changes with NETCONF configuration >>>>>>> datastores. Maybe this is not everybody's problem but I do work = with >>>>>>> devices where this possibility has to be addressed. >>>>>>>=20 >>>>>>=20 >>>>>> Yes, operational state can differ from config state. I think we >>>>>> understand that pretty well since the IAB workshop. There is = nothing >>>>>> new here (except that perhaps some people describe this same idea = now >>>>>> with different terms). >>>>>=20 >>>>> Does RFC 6241 really discriminate between running config and = state? >>>>>=20 >>>>> o running configuration datastore: A configuration datastore = holding >>>>> the complete configuration currently active on the device. >>>>>=20 >>>>> What does =E2=80=9Ccurrently active=E2=80=9D mean? If a parameter = changes in running, does it mean that it becomes the value that=E2=80=99s = used operationally? Immediately or eventually? If such a state parameter = is changed through other means, will the (different) value in running = override it, and if so, when? >>>>>=20 >>>>=20 >>>> I recommend reading RFC 6244 Section 4.3.2. >>>=20 >>> Maybe I can=E2=80=99t properly read between the lines but I don=E2=80=99= t see an answer to ANY of my questions there. >>>=20 >>=20 >> config =3D configuration data (as in RFC 6244 Section 4.3.2) >>=20 >> config !=3D current operational state (as in RFC 6244 Section 4.3.2) >>=20 >> running config =3D configuration data currently used >>=20 >> startup config =3D configuration data used at next startup >>=20 >> =3D> running config !=3D current operational state >>=20 >> The device implementation arbitrates and decides. Config is passed to >> the device at certain events (e.g., when the config is loaded or a >> change committed or the device or a function of it restarted). From >> the perspective of the internal code, config is one of the many >> sources of information that tells it how to behave. Control protocols >> inject additional information, the device learns additional >> information, the device has limitations and policies that tell it how >> to arbitrate the information. >>=20 >> NETCONF validates configuration data in configuration datastores. And >> going beyond that is IMHO not feasible nor helpful. What matters >> operationally is what the device actually does. This is represented = by >> the operational state. What a device actually does might not be valid >> (due to bugs, resource limitations, hardware changes, broken control >> protocols, bad karma, whatever). Network management systems have to >> check whether device behavior do matches the expectations. This check >> is essential and can't be replaced by validation. >>=20 >=20 >=20 > +1 >=20 >=20 > Validation of the configuration MUST NOT include the operational = state. > The config represents the desired state of operator controlled = settings. > There may be lots of ways for the system to behave in response > to the config contents. Some operational state will never mirror > the config (e.g., duplex=3Dauto). Some operational state will reflect > higher priority ephemeral config (from I2RS). Some operational Even if ephemeral config is declared as having higher priority, it can = still happen that its combination with =E2=80=9Cnormal=E2=80=9D config = is invalid. For example, running defines some RIBs, ephemeral defines = other RIBs, each datastore satisfies all data model constraints but the = joint list of RIBs may be invalid. That=E2=80=99s why I think it is the = combined effect of all =E2=80=9Cdesired states=E2=80=9D and other = contributions to the operational state that have to be considered. > state will reflect problems in the network preventing the operator's > settings from being used. >=20 > Proper network management protocol mechanisms are needed > to understand the current operational state of a device. > The I2RS pub/sub work might be the right hammer for this nail. > The problem is not the YANG config-stmt, or the lack of 'config' > containers. You also proposed the operational state datastore. What properties = should it have? Lada >=20 >=20 >> /js >=20 >=20 > Andy >=20 >>=20 >> -- >> 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/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 10 09:56:58 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B001AD36C for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 09:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGTSfucVm7R3 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 09:56:54 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943BD1AD36F for <netmod@ietf.org>; Fri, 10 Apr 2015 09:56:53 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so18165473lbb.0 for <netmod@ietf.org>; Fri, 10 Apr 2015 09:56:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QxalwpXxUgaw0j9i5gVrJRiLqoAnxh0RBSG6+AKSqrk=; b=DyNop31sVGptpod8GthwFvHfCMDSgKebaT8UAz2w8JaO5xp3u+8XmX+eeGxF2mYKo3 iNSe+f47xbI8KaoAKfRb41/3+cRNa08dcSe1vRiRLYH9TiXWBTm5hwGWWxIeFVZM5RwD /xk67p6rbqlXAuUbCUG8Kfl264DFa6oVJ/6GFdAaOudV/QCHckHAv9HUGCwFTgufmlBV jMNcQgR9xRPGKhSdgsFSFI4jF9EhlPq6wtY7deAGQ4hkF/12ApyO8gi+IjbIVz1VqRcN JPFlfCKPjpk9rx+8hUs7QkO+4EC9g5eho1XJ/JWMUoyrgRrTNiSyaPN9BWRiF44tOIjl s0+w== X-Gm-Message-State: ALoCoQmco2FLb7iImHoiN89B4cm923eAkC0KrniYsJQxry6TS7aXPfSVMr29t2+MI9bZ0Gw9nqbZ MIME-Version: 1.0 X-Received: by 10.152.234.169 with SMTP id uf9mr2266319lac.88.1428685011998; Fri, 10 Apr 2015 09:56:51 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 10 Apr 2015 09:56:51 -0700 (PDT) In-Reply-To: <980C74F5-A0DD-4E59-9886-FCAAB66C60BD@nic.cz> References: <etPan.55241a7a.41a7c4c9.855@corretto.local> <20150409.091500.933434364578438624.mbj@tail-f.com> <80C04A45-1F2A-4850-ACC2-1427DEE172E0@nic.cz> <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> <20150410122415.GC2969@elstar.local> <CABCOCHQtVosOPWUj_yhDATFcBnJ_1KEi6sjmWNJpmZz1do6+2Q@mail.gmail.com> <980C74F5-A0DD-4E59-9886-FCAAB66C60BD@nic.cz> Date: Fri, 10 Apr 2015 09:56:51 -0700 Message-ID: <CABCOCHTGZEvdjsXbK7scGYFAyuw_okrgUW9meEX5Vqt1+o0MKA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Zmnf1dXo5dAiUngu_5deAmxHlTI> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 16:56:56 -0000 On Fri, Apr 10, 2015 at 9:41 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > >> On 10 Apr 2015, at 17:20, Andy Bierman <andy@yumaworks.com> wrote: >> >> On Fri, Apr 10, 2015 at 5:24 AM, Juergen Schoenwaelder >> <j.schoenwaelder@jacobs-university.de> wrote: >>> On Fri, Apr 10, 2015 at 01:59:12PM +0200, Ladislav Lhotka wrote: >>>> >>>>> On 10 Apr 2015, at 13:44, Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de> wrote: >>>>> >>>>> On Fri, Apr 10, 2015 at 01:25:56PM +0200, Ladislav Lhotka wrote: >>>>>> >>>>>>> On 10 Apr 2015, at 12:33, Juergen Schoenwaelder <j.schoenwaelder@ja= cobs-university.de> wrote: >>>>>>> >>>>>>> On Fri, Apr 10, 2015 at 10:37:21AM +0200, Ladislav Lhotka wrote: >>>>>>>> >>>>>>>> Validity of a configuration may depend on things that are external= to it >>>>>>>> - such a configuration in itself can satisfy all constraints of a = data >>>>>>>> model but still be in conflict with the current state of the devic= e, and >>>>>>>> has to be rejected. >>>>>>>> >>>>>>>> This becomes really important when there are mechanisms that modif= y the >>>>>>>> state but don't sync the changes with NETCONF configuration >>>>>>>> datastores. Maybe this is not everybody's problem but I do work wi= th >>>>>>>> devices where this possibility has to be addressed. >>>>>>>> >>>>>>> >>>>>>> Yes, operational state can differ from config state. I think we >>>>>>> understand that pretty well since the IAB workshop. There is nothin= g >>>>>>> new here (except that perhaps some people describe this same idea n= ow >>>>>>> with different terms). >>>>>> >>>>>> Does RFC 6241 really discriminate between running config and state? >>>>>> >>>>>> o running configuration datastore: A configuration datastore holdi= ng >>>>>> the complete configuration currently active on the device. >>>>>> >>>>>> What does =E2=80=9Ccurrently active=E2=80=9D mean? If a parameter ch= anges in running, does it mean that it becomes the value that=E2=80=99s use= d operationally? Immediately or eventually? If such a state parameter is ch= anged through other means, will the (different) value in running override i= t, and if so, when? >>>>>> >>>>> >>>>> I recommend reading RFC 6244 Section 4.3.2. >>>> >>>> Maybe I can=E2=80=99t properly read between the lines but I don=E2=80= =99t see an answer to ANY of my questions there. >>>> >>> >>> config =3D configuration data (as in RFC 6244 Section 4.3.2) >>> >>> config !=3D current operational state (as in RFC 6244 Section 4.3.2) >>> >>> running config =3D configuration data currently used >>> >>> startup config =3D configuration data used at next startup >>> >>> =3D> running config !=3D current operational state >>> >>> The device implementation arbitrates and decides. Config is passed to >>> the device at certain events (e.g., when the config is loaded or a >>> change committed or the device or a function of it restarted). From >>> the perspective of the internal code, config is one of the many >>> sources of information that tells it how to behave. Control protocols >>> inject additional information, the device learns additional >>> information, the device has limitations and policies that tell it how >>> to arbitrate the information. >>> >>> NETCONF validates configuration data in configuration datastores. And >>> going beyond that is IMHO not feasible nor helpful. What matters >>> operationally is what the device actually does. This is represented by >>> the operational state. What a device actually does might not be valid >>> (due to bugs, resource limitations, hardware changes, broken control >>> protocols, bad karma, whatever). Network management systems have to >>> check whether device behavior do matches the expectations. This check >>> is essential and can't be replaced by validation. >>> >> >> >> +1 >> >> >> Validation of the configuration MUST NOT include the operational state. >> The config represents the desired state of operator controlled settings. >> There may be lots of ways for the system to behave in response >> to the config contents. Some operational state will never mirror >> the config (e.g., duplex=3Dauto). Some operational state will reflect >> higher priority ephemeral config (from I2RS). Some operational > > Even if ephemeral config is declared as having higher priority, it can st= ill happen that its combination with =E2=80=9Cnormal=E2=80=9D config is inv= alid. For example, running defines some RIBs, ephemeral defines other RIBs,= each datastore satisfies all data model constraints but the joint list of = RIBs may be invalid. That=E2=80=99s why I think it is the combined effect o= f all =E2=80=9Cdesired states=E2=80=9D and other contributions to the opera= tional state that have to be considered. > This sounds like a bug in the vaporware. The persistent configuration is self-contained. The ephemeral config does not exist when the device boots. It may never get added to the device (e.g., controller is missing). The validation of I2RS config as it is added to the device needs to be handled correctly. >> state will reflect problems in the network preventing the operator's >> settings from being used. >> >> Proper network management protocol mechanisms are needed >> to understand the current operational state of a device. >> The I2RS pub/sub work might be the right hammer for this nail. >> The problem is not the YANG config-stmt, or the lack of 'config' >> containers. > > You also proposed the operational state datastore. What properties should= it have? > No I did not propose an operational datastore. I agree with Martin that mirroring the config data is mostly pointless. Protocol operations would work better. I hope whatever properties the I2RS WG agrees on can be implemented efficiently. > Lada Andy > >> >> >>> /js >> >> >> Andy >> >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Apr 10 10:17:39 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2551A8776 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 10:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3Odlz8lK2sK for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 10:17:36 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4121A879F for <netmod@ietf.org>; Fri, 10 Apr 2015 10:17:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NkEBQ43/3XmziA5p1lo7F4ldy9NY9ec+t57Of7p1A/NDtuGqqB02j5Sa03/8IkRi; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1YgcYS-0004rY-8P for netmod@ietf.org; Fri, 10 Apr 2015 13:17:20 -0400 Received: from 76.254.48.249 by webmail.earthlink.net with HTTP; Fri, 10 Apr 2015 13:17:19 -0400 Message-ID: <4189559.1428686240197.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Fri, 10 Apr 2015 10:17:19 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537f529e1e134496b92edfffa200a259f32350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9jJQ1TFDL6D2yB1y3aHkxBbWTpU> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 17:17:37 -0000 Hi - >From: Ladislav Lhotka <lhotka@nic.cz> >Sent: Apr 10, 2015 9:41 AM >To: Andy Bierman <andy@yumaworks.com> >Cc: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder <j.schoenwaelder@jacobs-university.d= e>, Martin Bj=C3=B6rklund <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mi= ndspring.com>, "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] New 6087bis issues - connect config - state - statis= tics ... >Even if ephemeral config is declared as having higher priority, >it can still happen that its combination with =E2=80=9Cnormal=E2=80=9D con= fig >is invalid. That's an error in modeling, pure and simple. >For example, running defines some RIBs, ephemeral defines >other RIBs, each datastore satisfies all data model constraints Model constraints do not completely define the behaviour of anything other than "post-it" objects. >but the joint list of RIBs may be invalid. That's an error in defining how the "joint list of RIBs" works, IMO. An analogy would be a subroutine library. Sure, all the modules might compile cleanly, and even make it through lint, but that doesn't mean that, when working together, there are no memory leaks. > That=E2=80=99s why I think it is the combined effect of all > =E2=80=9Cdesired states=E2=80=9D and other contributions to the operation= al > state that have to be considered. I think there's a conceptual sleight-of-hand here. Certainly one would like configuration management to result in systems that can always be brought to to a desired state. But that's only true in an absolute sense as long as the configuration management mechanism effectively overrules all other inputs to the system. As soon as one admits the possibility of information sourced elsewhere overriding explicit configuration data in determining the system state, one must retreat to a less ambitious understanding of what "desired state" really means. Randy From nobody Fri Apr 10 10:38:59 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6DC1A8A59 for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dCMLcvz66BE for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 10:38:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256311A8873 for <netmod@ietf.org>; Fri, 10 Apr 2015 10:38:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E6FC08FE; Fri, 10 Apr 2015 19:38:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9xCuffs-OCBY; Fri, 10 Apr 2015 19:38:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Apr 2015 19:38:55 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFC4B2002B; Fri, 10 Apr 2015 19:38:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6SatlgcVOHA6; Fri, 10 Apr 2015 19:38:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BF0220013; Fri, 10 Apr 2015 19:38:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1FD0832BE4E8; Fri, 10 Apr 2015 19:38:52 +0200 (CEST) Date: Fri, 10 Apr 2015 19:38:51 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150410173851.GB5455@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> References: <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> <20150410122415.GC2969@elstar.local> <CABCOCHQtVosOPWUj_yhDATFcBnJ_1KEi6sjmWNJpmZz1do6+2Q@mail.gmail.com> <980C74F5-A0DD-4E59-9886-FCAAB66C60BD@nic.cz> 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: <980C74F5-A0DD-4E59-9886-FCAAB66C60BD@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/0J-qDkOHYf2wWE7AojZ3ixDHDKA> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 17:38:58 -0000 On Fri, Apr 10, 2015 at 06:41:19PM +0200, Ladislav Lhotka wrote: > > Even if ephemeral config is declared as having higher priority, it > can still happen that its combination with “normal” config is > invalid. For example, running defines some RIBs, ephemeral defines > other RIBs, each datastore satisfies all data model constraints but > the joint list of RIBs may be invalid. That’s why I think it is the > combined effect of all “desired states” and other contributions to > the operational state that have to be considered. > Yes. The device itself is the final arbitrator. In many cases, it will know how to resolve conflicts - and this will be implementation dependent or even specific to the different pieces of hardware plugged into a device, in some (hopefully rare) cases the device might simply die and reboot. > You also proposed the operational state datastore. What properties > should it have? Operational state is defined in RFC 6244 section 4.3.2. Section 4.3.3 of the same RFC discusses how to deal with operational state from a NETCONF perspective. What we are doing so far is what is described in Section 4.3.3.1. And we noted that config and state data models or often different in the details. The most important point I think is that the operational state model must report what the device is actually doing. If it does something wired, then this wiredness should show up in the operational state. In other words, saying operational state is invalid (from the device perspective) is not meaningful - if the state is there, it should be reported. Operational state is the ultimate ground truth. (And as a consequence, you should have few constraints on the operational state part of the data model.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 10 11:04:46 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFBE1B29DA for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 11:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlzpbRFZrWYA for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 11:04:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA561B29D0 for <netmod@ietf.org>; Fri, 10 Apr 2015 11:04:43 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:a5a8:dd0e:e346:adc1] (unknown [IPv6:2a01:5e0:29:ffff:a5a8:dd0e:e346:adc1]) by mail.nic.cz (Postfix) with ESMTPSA id 789A113FE1C; Fri, 10 Apr 2015 20:04:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1428689080; bh=9mc2fWBxkNtBQpTL6a/WAgJVmLbg6lXs4qOl/krIHIE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Io+dzZnnWianPpVyYQhngqZeDaNoyj8Cw2AhqWa5qOh5qUl8335M0IpDJWMEkUXaV tujGSdSJDkm96c6xiEeqfoxB3SNHbGQFWdZyB0UGqqe4m3H5sBpyg/oxOTVjcoIfB9 2KeIhVh/Xi2wX/mT9sycflU5RUiXYc85d7K1OZcs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150410173851.GB5455@elstar.local> Date: Fri, 10 Apr 2015 20:04:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82BE9069-E80C-4EEA-992B-DA8A390CC638@nic.cz> References: <20150409095419.GA27651@elstar.local> <CABCOCHRL5Om0-4-J8Njsosi98=tV5Q7Z+t8G-eSansmJJ_we2w@mail.gmail.com> <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> <20150410122415.GC2969@elstar.local> <CABCOCHQtVosOPWUj_yhDATFcBnJ_1KEi6sjmWNJpmZz1do6+2Q@mail.gmail.com> <980C74F5-A0DD-4E59-9886-FCAAB66C60BD@nic.cz> <20150410173851.GB5455@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/3m7yFg3uM3aOOCRciAORQbwlXQY> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 18:04:45 -0000 > On 10 Apr 2015, at 19:38, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >=20 > On Fri, Apr 10, 2015 at 06:41:19PM +0200, Ladislav Lhotka wrote: >>=20 >> Even if ephemeral config is declared as having higher priority, it >> can still happen that its combination with =E2=80=9Cnormal=E2=80=9D = config is >> invalid. For example, running defines some RIBs, ephemeral defines >> other RIBs, each datastore satisfies all data model constraints but >> the joint list of RIBs may be invalid. That=E2=80=99s why I think it = is the >> combined effect of all =E2=80=9Cdesired states=E2=80=9D and other = contributions to >> the operational state that have to be considered. >>=20 >=20 > Yes. The device itself is the final arbitrator. In many cases, it will > know how to resolve conflicts - and this will be implementation > dependent or even specific to the different pieces of hardware plugged > into a device, in some (hopefully rare) cases the device might simply > die and reboot. >=20 >> You also proposed the operational state datastore. What properties >> should it have? >=20 > Operational state is defined in RFC 6244 section 4.3.2. Section 4.3.3 > of the same RFC discusses how to deal with operational state from a > NETCONF perspective. What we are doing so far is what is described in > Section 4.3.3.1. And we noted that config and state data models or > often different in the details. The most important point I think is > that the operational state model must report what the device is > actually doing. If it does something wired, then this wiredness should > show up in the operational state. In other words, saying operational > state is invalid (from the device perspective) is not meaningful - if > the state is there, it should be reported. Operational state is the Sure, but I was talking about validating *tentative* operational state. = If it=E2=80=99s broken, then it cannot be installed as =E2=80=9Creal=E2=80= =9D operational state. So it boils down to considering what would happen = if certain changes are applied. This problem cannot be fully assessed = just by looking into the desired state submitted by a single management = protocol. Yes, the device is the final arbiter and some errors can only = be checked at runtime, but I still think at least a part of business = rules for device operation could be expressed in a data model and = discovered without going through trial and error. Lada > ultimate ground truth. (And as a consequence, you should have few > constraints on the operational state part of the data model.) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 10 11:29:29 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F151F1B2D3F for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 11:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lnhu2_6t9hWX for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 11:29:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1FD1B2D3C for <netmod@ietf.org>; Fri, 10 Apr 2015 11:29:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8EA35114C; Fri, 10 Apr 2015 20:29:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5-gA3rCCOnS1; Fri, 10 Apr 2015 20:28:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Apr 2015 20:29:23 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2ED0D2002B; Fri, 10 Apr 2015 20:29:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LMTSernQhFbG; Fri, 10 Apr 2015 20:29:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 077BD20013; Fri, 10 Apr 2015 20:29:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D6A2232BE57B; Fri, 10 Apr 2015 20:29:19 +0200 (CEST) Date: Fri, 10 Apr 2015 20:29:19 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150410182919.GA5587@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj@tail-f.com>, Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> References: <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> <20150410122415.GC2969@elstar.local> <CABCOCHQtVosOPWUj_yhDATFcBnJ_1KEi6sjmWNJpmZz1do6+2Q@mail.gmail.com> <980C74F5-A0DD-4E59-9886-FCAAB66C60BD@nic.cz> <20150410173851.GB5455@elstar.local> <82BE9069-E80C-4EEA-992B-DA8A390CC638@nic.cz> 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: <82BE9069-E80C-4EEA-992B-DA8A390CC638@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/QUKEYDScQ2qnS0AoHJauYW6onCM> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 18:29:28 -0000 On Fri, Apr 10, 2015 at 08:04:38PM +0200, Ladislav Lhotka wrote: > > > On 10 Apr 2015, at 19:38, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > > > On Fri, Apr 10, 2015 at 06:41:19PM +0200, Ladislav Lhotka wrote: > >> > >> Even if ephemeral config is declared as having higher priority, it > >> can still happen that its combination with “normal” config is > >> invalid. For example, running defines some RIBs, ephemeral defines > >> other RIBs, each datastore satisfies all data model constraints but > >> the joint list of RIBs may be invalid. That’s why I think it is the > >> combined effect of all “desired states” and other contributions to > >> the operational state that have to be considered. > >> > > > > Yes. The device itself is the final arbitrator. In many cases, it will > > know how to resolve conflicts - and this will be implementation > > dependent or even specific to the different pieces of hardware plugged > > into a device, in some (hopefully rare) cases the device might simply > > die and reboot. > > > >> You also proposed the operational state datastore. What properties > >> should it have? > > > > Operational state is defined in RFC 6244 section 4.3.2. Section 4.3.3 > > of the same RFC discusses how to deal with operational state from a > > NETCONF perspective. What we are doing so far is what is described in > > Section 4.3.3.1. And we noted that config and state data models or > > often different in the details. The most important point I think is > > that the operational state model must report what the device is > > actually doing. If it does something wired, then this wiredness should > > show up in the operational state. In other words, saying operational > > state is invalid (from the device perspective) is not meaningful - if > > the state is there, it should be reported. Operational state is the > > Sure, but I was talking about validating *tentative* operational state. If it’s broken, then it cannot be installed as “real” operational state. So it boils down to considering what would happen if certain changes are applied. This problem cannot be fully assessed just by looking into the desired state submitted by a single management protocol. Yes, the device is the final arbiter and some errors can only be checked at runtime, but I still think at least a part of business rules for device operation could be expressed in a data model and discovered without going through trial and error. > I have no clue what *tentative* operational state is. I believe trying to validate anything that involves operational state is a bad idea. I guess I am done here since I am just repeating myself. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 10 12:06:25 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FA81A87BB for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 12:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEvwbPW1WgXO for <netmod@ietfa.amsl.com>; Fri, 10 Apr 2015 12:06:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CB0E71B2D71 for <netmod@ietf.org>; Fri, 10 Apr 2015 12:06:03 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 2C0151CC0098; Fri, 10 Apr 2015 21:06:06 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> In-Reply-To: <20150410182919.GA5587@elstar.local> References: <m21tjsbcqm.fsf@birdie.labs.nic.cz> <20150410103334.GA2626@elstar.local> <8134BF96-BD17-46E8-B7D3-53F724CE2B79@nic.cz> <20150410114448.GA2830@elstar.local> <C53168E1-7BE2-4B03-AE44-587ABAD375AD@nic.cz> <20150410122415.GC2969@elstar.local> <CABCOCHQtVosOPWUj_yhDATFcBnJ_1KEi6sjmWNJpmZz1do6+2Q@mail.gmail.com> <980C74F5-A0DD-4E59-9886-FCAAB66C60BD@nic.cz> <20150410173851.GB5455@elstar.local> <82BE9069-E80C-4EEA-992B-DA8A390CC638@nic.cz> <20150410182919.GA5587@elstar.local> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 10 Apr 2015 21:05:59 +0200 Message-ID: <m28udz7qi0.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/OhQOCT4g2Qglvi9LqthjiLDfQyg> Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] New 6087bis issues - connect config - state - statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 10 Apr 2015 19:06:24 -0000 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes: > > I have no clue what *tentative* operational state is. I believe trying > to validate anything that involves operational state is a bad idea. I > guess I am done here since I am just repeating myself. OK, here's an example: { "ietf-interfaces:interfaces-state": { "interface": [ { "name": "eth0", "type": "iana-if-type:ethernetCsmacd", "ietf:ip": { "ipv4" : { "address": { "ip": "192.0.2.1", "prefix-length": 24, ... } } }, ... }, { "name": "eth1", "type": "iana-if-type:ethernetCsmacd", ... } ] } } No interface configuration present, which means that the address 192.0.2.1 was assigned e.g. via DHCP. Now if a client creates an "interface" entry that tries to configure address 192.0.2.1/24 on eth1 (such a configuration is valid). The tentative operational state than is: { "ietf-interfaces:interfaces-state": { "interface": [ { "name": "eth0", "type": "iana-if-type:ethernetCsmacd", "ietf:ip": { "ipv4" : { "address": { "ip": "192.0.2.1", "prefix-length": 24, ... } } }, ... }, { "name": "eth1", "type": "iana-if-type:ethernetCsmacd", "ietf:ip": { "ipv4" : { "address": { "ip": "192.0.2.1", "prefix-length": 24, ... } } }, ... } ] } } The duplicate address can then be immediately discovered and the configuration rejected, if the data model had a corresponding must statement on *state data*. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Apr 12 23:54:56 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CA01B2E24 for <netmod@ietfa.amsl.com>; Sun, 12 Apr 2015 23:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_54=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7Xvka4R-3cW for <netmod@ietfa.amsl.com>; Sun, 12 Apr 2015 23:54:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A16D01B2E26 for <netmod@ietf.org>; Sun, 12 Apr 2015 23:54:53 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 731F21CC0167; Mon, 13 Apr 2015 08:54:51 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: "Lisa \(Yi\) Huang" <lyihuang@juniper.net> In-Reply-To: <D14D9C0C.13BF0%lyihuang@juniper.net> References: <D14D9C0C.13BF0%lyihuang@juniper.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 13 Apr 2015 08:54:50 +0200 Message-ID: <m2a8ycr005.fsf@birdie.labs.nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/gKDFBZQ1M45iKS4Lbr_XGLUemB8> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] tool to validate json again yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 06:54:55 -0000 Hi Lisa, "Lisa (Yi) Huang" <lyihuang@juniper.net> writes: > Lada and all, > > I am looking for a tool validate json instance to yang. Do you have any > recommendation? > > Currently, pyang can generate jtox which I could use to convert json to > xml. After that the xml can be validated with xsd generated from yang. I > am wondering whether there is a better way to do it. Thanks, Yes, there is - use DSDL schemas rather than XSD. The "xsd" plugin in pyang is deprecated. Below is a Makefile from a project where we use this way of JSON validation (make validate). It is still indirect in that it goes via XML, but I am not aware of any open source tool that can validate JSON directly. For more details about XML instance validation using DSDL, see this tutorial: https://github.com/mbj4668/pyang/wiki/InstanceValidation Hope this helps, Lada MODULES = securris ymod = $(addsuffix .yang, $(MODULES)) TARGET ?= config BASE ?= sample xsltdir = ../../xslt bn = $(BASE)-$(TARGET) schemas = $(bn).rng $(BASE)-gdefs-config.rng $(bn)-dsrl.xsl $(bn)-sch.xsl tgt = --stringparam target $(TARGET) rngparms = $(tgt) --stringparam basename $(BASE) --stringparam schema-dir \ $(PYANG_RNG_LIBDIR) $(PYANG_XSLT_DIR)/gen-relaxng.xsl Y2DOPTS = -t $(TARGET) -b $(BASE) .PHONY = clean all: $(schemas) model.tree model.xsl %.yang: %.yinx @xsltproc $(xsltdir)/canonicalize.xsl $< | \ xsltproc --output $@ $(xsltdir)/yin2yang.xsl - $(bn).xml: model.jtox $(bn).json @json2xml -t $(TARGET) -o $@ $^ model.jtox: $(ymod) @pyang -o $@ -f jtox $^ model.xsl: $(ymod) @pyang -o $@ -f jsonxsl $^ model.tree: $(ymod) @pyang -o $@ -f tree $^ $(bn).dsdl: $(ymod) @pyang -f dsdl -o $@ --dsdl-no-documentation --dsdl-no-dublin-core $^ $(bn).rng: $(bn).dsdl @xsltproc --output $@ $(rngparms) $< $(BASE)-gdefs-config.rng: $(bn).dsdl @xsltproc --output $@ --stringparam gdefs-only 1 $(rngparms) $< $(bn).rnc: $(bn).rng $(BASE)-gdefs-config.rng @trang -I rng -O rnc $< $@ $(bn)-dsrl.xsl: $(bn).dsdl @xsltproc $(tgt) $(PYANG_XSLT_DIR)/gen-dsrl.xsl $< | \ xsltproc --output $@ $(PYANG_XSLT_DIR)/dsrl2xslt.xsl - $(bn)-sch.xsl: $(bn).dsdl @xsltproc $(tgt) $(PYANG_XSLT_DIR)/gen-schematron.xsl $< | \ xsltproc $(PYANG_XSLT_DIR)/iso_abstract_expand.xsl - | \ xsltproc -o $@ $(PYANG_XSLT_DIR)/iso_svrl_for_xslt1.xsl - validate: $(bn).xml $(schemas) @jing $(bn).rng $< @xsltproc $(bn)-dsrl.xsl $< | xsltproc $(bn)-sch.xsl - | \ xsltproc $(PYANG_XSLT_DIR)/svrl2text.xsl - clean: @rm -f $(schemas) $(bn).xml *.dsdl model.* *.rnc > > Lisa > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 13 06:58:04 2015 Return-Path: <jason.sterne@alcatel-lucent.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D6E1A1BB8 for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 06:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAqgnhW3Sw7G for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 06:58:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0EC1A1B73 for <netmod@ietf.org>; Mon, 13 Apr 2015 06:58:01 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id EA768CF1FDA50; Mon, 13 Apr 2015 13:57:55 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t3DDvuwL002295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 09:57:58 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.179]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 09:57:56 -0400 From: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Martin Bjorklund" <mbj@tail-f.com> Thread-Topic: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Thread-Index: AQHQcwLSPtnCcK57vk2HBZSygy44Lp1K+b7g Date: Mon, 13 Apr 2015 13:57:56 +0000 Message-ID: <A125E53CE190A749957C19483DC79F9F5C9EBD59@US70TWXCHMBA11.zam.alcatel-lucent.com> References: <20150409.082319.278951169841775666.mbj@tail-f.com> <1D28D7FF-0E7E-47CD-BCFD-F788BA944C78@cisco.com> <20150409200102.GC647@elstar.local> <20150409.220505.220589316913687460.mbj@tail-f.com> <20150409202136.GF647@elstar.local> In-Reply-To: <20150409202136.GF647@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9a7Q5ZbCIRS4GlUmlx9n17AFkfY> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 13:58:03 -0000 Hi guys, I think part of the confusion here is that: 1) the syslog RFC is mainly concerned with describing the external on-the-w= ire protocol/encoding of how to carry syslog messages 2) the syslog YANG model is mainly concerned with describing distributors a= nd filtering within a node Those are not the same things. None of the "Message Producers", "Message Distributors" and syslog selector= /filtering from the YANG model is covered in the RFC. The YANG model is try= ing to capture common implementations of internal node log event filtering = and distribution. Many implementations filter on their internal equivalent of "facility" (whi= ch may or may not be called facility). We need to allow that in this YANG = model - that is one of the main things this model is trying to normalize. When a "remote" action/distributor is used that is really where RFC 5424 co= mes into play. The messages that go to a remote syslog collector do need t= o conform to RFC 5424. Implementations use a variety of methods to map inte= rnal facility/severity to the external RFC 5424 format and values. For the = facility field some implementations simply stamp every log event for a give= n remote destination with a fixed RFC 5424 facility value. That is what th= e "leaf destination-facility" is for in the model. Other implementations = may map internal facilities to RFC 5424 facilities (or just use purely RFC = 5424 facility values internally and externally with no mapping required). I think we should just standardize the 0..23 RFC 5424 facility values as id= entities and let vendors augment and use those augmentations at minimum in = the filtering/syslog-selector. It can then be vendor-specific (with augmen= tation) if a vendor needs to add some more complex configurable mapping (be= sides the "leaf destination-facility" which is common enough to leave in). Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwa= elder Sent: Thursday, April 09, 2015 4:22 PM To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt On Thu, Apr 09, 2015 at 10:05:05PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > On Thu, Apr 09, 2015 at 06:03:08PM +0000, Clyde Wildes (cwildes) wrote: > > >=20 > > > [clyde] Yes some vendors do not follow RFC 5424 exactly - the case th= at I am talking about is when a vendor supports 0..23 and adds additional f= acilities to the list above 23. The vendor creates a new facility code for = each major software component in the system and each component uses it's ow= n facility when creating a syslog message. The message priority is the same= except that the facility ranges from ( 0 to 23 plus first-vendor-facility = to max-vendor-facility ) * 8. The question is do we want to allow vendors t= o extend the facility and how? I would answer yes, we should create a model= that allows vendors to extend the facility. > > > > >=20 > > In a nutshell, the vendor is violating a protocol MUST. Do we have=20 > > to support implementations that violate protocol MUSTs? This is a=20 > > difficult question to answer and I think this requires input from=20 > > people who were involved in the creation of the protocol MUST. >=20 > One way to handle this is to do the identity solution we discussed,=20 > maybe even with the "MUST NOT derive directly from=20 > syslog:syslog-facility". The vendors that break the protocol MUST can=20 > then break our MUST NOT and add their own facilities. > This is then at least formally consistent. Whatever the reason for the prot= ocol MUST has been... /js --=20 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 From nobody Mon Apr 13 07:02:59 2015 Return-Path: <jason.sterne@alcatel-lucent.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0011A7D84 for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 07:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsN8X9hs1CLO for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 07:02:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 4DEDB1A7034 for <netmod@ietf.org>; Mon, 13 Apr 2015 07:02:44 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 2C400BD654651; Mon, 13 Apr 2015 14:02:40 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t3DE2eLA019343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 10:02:40 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.179]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 10:02:40 -0400 From: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> To: "Clyde Wildes (cwildes)" <cwildes@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Thread-Index: AQHQbUJuPtnCcK57vk2HBZSygy44Lp1CAAMAgAj/kBA= Date: Mon, 13 Apr 2015 14:02:39 +0000 Message-ID: <A125E53CE190A749957C19483DC79F9F5C9EBD78@US70TWXCHMBA11.zam.alcatel-lucent.com> References: <20150402.144231.1437388601493142848.mbj@tail-f.com> <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> In-Reply-To: <A202CA46-6C75-42F9-BD46-18136F02F48B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/s8-AMHjJfVgsOxVIe-GZGU7s408> Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 14:02:52 -0000 Hi guys, A few comments below with [>>JTS]. Regards, Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Clyde Wildes (cw= ildes) Sent: Tuesday, April 07, 2015 5:59 PM To: Martin Bjorklund; netmod@ietf.org Subject: Re: [netmod] mbj review of draft-ietf-netmod-syslog-model-03.txt Martin, Thanks for your review! My responses are inline... On 4/2/15, 5:42 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote: >Hi, > >I have reviewd this document and have some comments: =20 > > >o typedef severity should have a reference to RFC 5424. [clyde] Agreed - I will make the change. > > >o Given that the standard defines a fixed set of 24 facilities, it > seems odd that the facilities are modelled as identities, and not > as an enumeration. Using identities gives the impression that this > is an extensible set of values. [clyde] A number of vendors need to augment the list of facilities - some w= ith several hundred additional facilities. Please suggest an alternative co= ding that can be used to add facilities through augmentation. Is it that we= should have two separate facility fields: RFC 5424 (0-24) and Vendor Speci= fic starting at 24? > >o Why do we have these: > > feature file-logging-structured-data > > feature remote-logging-structured-data > > I would assume that if the device supports structured data, it would =20 > do so regardless of logging method? I.e., a single feature =20 > "structured-data" would be enough? > > But is this (structured data) typically configurable in =20 > implementations, and if it is, it is configurable per "action" like =20 > this? [clyde] The history of this is that we agreed to support file-logging-struc= tured-data as a feature (currently implemented by JUNOS) since it is called= out in RFC 5424. Then someone (at the Hawaii meeting) asked, if we support= structured data for files, why not support for remote logging too? Althoug= h I do not know of anyone who has implemented this, I agreed to support it = for remote logging as a separate feature. We are talking about two differen= t functionalities here. Perhaps the best solution is to remove remote-loggi= ng structured data and let it be supported through augmentation should anyo= ne require it in the future. [>>JTS] Agree - let's remove it especially if it is not prevalent. Current = deployments likely use SNMP notifications if they need structured informati= on and the industry longer term is probably more likely to focus on NETCONF= based notifications rather than further evolution of syslog. > > >o I do not understand what the global-logging-action does. The > description says: > > Global logging represents the ability to > perform global log message suppression. > > Does this mean that the global level *suppresses* matching > messages? > > The text talks about "group level suppression", but the model has > "global logging action". This is a bit confusing. > > So what does this configuration mean: > > <global-logging-action> > <none/> > </global-logging-action> > > Does it means that no messages are suppressed, or that all messages > are suppressed? [clyde] Global logging is a first level suppression filter. Please see the = diagram in the RFC. Given that only a few NOS implement it we could remove = it and leave it for augmentation for those vendors that implement it. <none= /> means that no facilities participate in the filter and therefore the fil= ter is turned off. <none/> is useful when you want to turn off actions that default to on (suc= h as the console).=20 [>>JTS] This is a somewhat confusing mix of meaning for <none>. In the glo= bal filter it means let everything through. For console are we saying it m= eans block everything ? We need to also clarify (for global & distributors= ) what the absence of any selector means (vs <none>). > > >o The usage of the in-memory log buffer is a bit unclear. I think the > spec needs to explain how this log buffer is supposed to be used. > Perhaps we should also provide a mechanism to read this buffer? > I.e., provide a config false list of buffered messages? [clyde] In-memory log buffers are circular queues of log messages. Network = elements that can experience log message event storms use in-memory buffers= to avoid loss of syslog messages. [>>JTS] I think these are just intended to be circular queues that an opera= tor can request to view (in CLI and we should also make them viewable in NE= TCONF via <get>). They don't feed any other distributor so I don't think t= hey really have anything to do with mitigating event storms or event loss (= if an operator doesn't look at them for a while then some of the older even= ts will always be overwritten). It is just a "pull" method for an operator= to be able to access recent log events (without having them pop up on thei= r terminal session - i.e. "push"). > > >o It is important to remember that the names of choices and cases are > not visible in the instantiated data. Thus, when you have nice > descriptive names for the choices and cases, and these names convey > some meaning, this meaning is lost when you just look at instance > data. For example, this instance: > > <console-logging-action> > <severity>warning</severity> > </console-logging-action> > > does not convey the meaning of the chosen case, which is called > "logging-facility-all". I.e., from the instance data above you > cannot tell that we're actually matching on all facilities. > > I think you said you are changing this grouping a bit, and if so I > will have a look in the next revision. [clyde] I will examine our use of choice/case with an eye to rewording for = clarity. > > >o For the remote logging, it seems only UDP is supported. I think > the data model should follow the recommendation in section 3 in > draft-schoenw-netmod-yang-pattern-00 so that multiple transports > can be supported. Maybe this model should support the TLS and DTLS > transports? [clyde] I agree to follow the recommendation in section 3 of draft-schoenw-= netmod-yang-pattern-00. > > >o For remote logging, I think the "vrf-name" leaf should be removed. > It is not clear how this maps to the routing work, and it can > always be augmented later, or a vendor can do a proprietary > augmentation. [clyde} Multiple vendors add VRF name to the server connection specificatio= n so that the correct routing table can be used to provide access the serve= r. I am surprised that VRF is not in your best practice Outbound Connection= pattern. > >o For remote logging is it a good idea to have "source-interface"? > If so, should we have this in all our models for outgoing > connections? [clyde] source-interface is implemented by multiple vendors to force log me= ssages to have the same source information in outgoing syslog packets. This= makes it easier for the remote server to implement firewall protection. [>>JTS] Some implementations that support this do it globally rather than p= er distributor. If we want to leave this in can we make it global (that ca= n easily be supported by implementations that have either per distributor o= r global) ? =20 > > >o leaf file-name is supposed to refer to a local file. If inet:uri > is supposed to be used, it should state that this MUST be with > scheme "file" (i.e., on the form "file:..."). But is inet:uri the > correct type to use? [clyde] I will update the description to indicate that the file scheme shou= ld be used. > > >o leaf file-number has a default of 1. Isn't this a bit small for a > file archive? [clyde] I chose 1 (perhaps naively) for those vendors that do not implement= the file-number concept. I will be happy to change to a consensus number. > > >o leaf file-size has a default of 262144. Why this number? [clyde] There was a brief discussion on the list and this seemed like a goo= d tradeoff. > > >o leaf file-permission has the teo values "world-readable" and > "no-world-readable". This seems a bit restrictive for some kinds > of systems, and it is also underspecified (what exactly does > "no-world-readable" mean?). Maybe it is better to leave this out? [clyde] Multiple vendors implement a binary switch for syslog world read pr= otection: on for anyone; off for no. If we remove this almost every vendor = will have to add it back through augmentation. It's not meant to be a gener= al Unix file-permission mask value. [>>JTS] I really don't think this is done in a common enough way to put int= o the base standard model. > > >o I think some nodes can get better names. Maybe: > > syslog / log-actions / global > console > buffer > file > remote > terminal > > This allows for future nodes (non-actions) directly underneath > "syslog", and it removes the "-logging-action" suffix everywhere. [clyde] I will make this change. > > I also suggest you remove the containers > "logging-advanced-level-processing" and "logging-match-processing" > and just move their leafs up one level: > > global / logging-level-scope /... > select-message-severity > pattern-match [clyde] Agreed. > > Some other suggestions: > > OLD: logging-files > NEW: log-file (note singluar) > > OLD: file-name > NEW: name (remove redundant prefix) > > OLD: file-logging-strucured-data > NEW: structured-data (remove redundant prefix) > > OLD: file-logging-archive > NEW: file-archive > > OLD: file-number > NEW: number-of-files > > OLD: file-size > NEW: max-file-size > > OLD: remote-logging-structured-data > NEW: structured-data (remove redundant prefix) [clyde] I will make these changes. > > >o I don't understand how the leaf "select-message-severity" is > supposed to be used. Juergen felt that it was important that this model support Linux syslog sel= ector processing. Linux syslog adds "equals" and "not-equals" comparisons t= o the standard "equals-or-higher" severity comparison. This is a feature be= cause not all implementations support this. > > >o I think container syslog-sign should have: > > reference > "RFC 5848: Signed Syslog Messages"; > > (Yes I know this is also defined on the top-level, but it is nice > to have the reference available when it is used.) > > BTW this is the style the RFC editor prefers, so you may want to > change the current top-level reference to: > > reference > "RFC 5424: The Syslog Protocol > RFC 5848: Signed Syslog Messages"; [clyde] Agreed. > > >o I don't know anything about signed syslog messages, but are these > config params all that are needed? [clyde] Yes, Alex Clemm provided the list from the RFC. Thanks, Clyde > > > >/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 From nobody Mon Apr 13 07:11:37 2015 Return-Path: <jason.sterne@alcatel-lucent.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6871A8029 for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8ib29lKlOPa for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 07:11:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452AD1A7011 for <netmod@ietf.org>; Mon, 13 Apr 2015 07:11:33 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id C4FEC17D8B07C for <netmod@ietf.org>; Mon, 13 Apr 2015 14:11:28 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t3DEBUtN001119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netmod@ietf.org>; Mon, 13 Apr 2015 10:11:31 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.179]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 10:11:31 -0400 From: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> To: "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: mandatory ACL type (was "comments on acl-model-02") Thread-Index: AQHQdfO9+1SL04157USyMOLNDBGWIQ== Date: Mon, 13 Apr 2015 14:11:30 +0000 Message-ID: <A125E53CE190A749957C19483DC79F9F5C9EBDB7@US70TWXCHMBA11.zam.alcatel-lucent.com> References: <A125E53CE190A749957C19483DC79F9F5C9DFFD4@US70TWXCHMBA11.zam.alcatel-lucent.com> In-Reply-To: <A125E53CE190A749957C19483DC79F9F5C9DFFD4@US70TWXCHMBA11.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/3qghcPKYmFHHSlly4Vt_k2SJs0g> Subject: [netmod] mandatory ACL type (was "comments on acl-model-02") X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 14:11:35 -0000 Hi guys, Extracting my comments about ACL type into its own thread. I saw Martin al= so had some comments on this topic. The ACL type was mandatory in an older version of the draft and I think we = should put it back as mandatory. Implementations that don't *need* that le= af value can work fine whether they get it during ACL creation or not but s= ome implementations need to know the type. It would also be good to create separate identities for IPv4-access-control= -list and IPv6-access-control-list instead of bundling them into IP-access-= control-list. If we're separating into types in the model it should be the = 3 basic types in the base model: v4, v6 and enet. That would also help if we decide to put some constraints that allow/disall= ow certain matching criteria when the type is a specific value (e.g. don't = allow a v6 address match in a v4 list). We'd have to be careful about how = those constraints are formulated though - especially if we want to allow au= gmentations of the list-type for "mixed" ACLs. A new "mixed-v4-enet" type (= identity) would also need to use the destination-ipv4-network matching crit= eria (can "when" or "must" logic be changed by an augmentation ? I'm not s= ure that works). Regards, Jason From nobody Mon Apr 13 08:25:11 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E301ACD7C for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 08:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWQzdL7iDQyL for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 08:25:09 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC431ACD71 for <netmod@ietf.org>; Mon, 13 Apr 2015 08:25:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BB43D1230 for <netmod@ietf.org>; Mon, 13 Apr 2015 17:25:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id g1inY4IWiYys for <netmod@ietf.org>; Mon, 13 Apr 2015 17:25:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Mon, 13 Apr 2015 17:25:07 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5EC720031 for <netmod@ietf.org>; Mon, 13 Apr 2015 17:25:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iOUhr7q7xc6G; Mon, 13 Apr 2015 17:25:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F9072002B; Mon, 13 Apr 2015 17:25:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7E33432C02B2; Mon, 13 Apr 2015 17:25:03 +0200 (CEST) Date: Mon, 13 Apr 2015 17:25:03 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: netmod@ietf.org Message-ID: <20150413152503.GA14839@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150401142727.GA75021@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401142727.GA75021@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/-xk3aIFhZRdh4G_ea3aFzLUnAAM> Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 15:25:10 -0000 On Wed, Apr 01, 2015 at 04:27:27PM +0200, Juergen Schoenwaelder wrote: > Hi, > > this I-D has been presented at IETF 92 and there was support to adopt > this work as WG work item. The abstract of the document says: > > This document defines a YANG extension statement that allows for > defining the syntax of metadata annotions in YANG modules. The > document also specifies the XML and JSON encoding of annotations and > other rules for annotating instances of YANG data nodes. > > This is a call to verify this on the mailing list. Given the support > this saw at IETF 92, I will read silence as support. People who see an > issue with adopting this document should send an email with an > explanation to the WG and/or the WG chairs by April 10th. > Since I have not received any further comments, I conclude that the metadata document will become a WG document now. Lada, please post the next version as draft-ietf-netmod-yang-metadata-00 and I will approve it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Mon Apr 13 08:39:21 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810161ACDBA for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 08:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM1JUrulIPK2 for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 08:39:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98711ACDB7 for <netmod@ietf.org>; Mon, 13 Apr 2015 08:39:18 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:c90e:15b0:209b:60c9] (unknown [IPv6:2001:718:1a02:1:c90e:15b0:209b:60c9]) by mail.nic.cz (Postfix) with ESMTPSA id 1975113F64F; Mon, 13 Apr 2015 17:39:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1428939556; bh=6mostpSaO688Yp05fEAj1ABCvO+1e19r/X3r4r3ZBms=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=G2N6/7DsXyplawSwLF160Nq+9dIQv+1xOQbD1bMbRYNWCpMJw+AKZSdkLjQJBjLBC cSdqfNzOISIDAyuHDBFK+aIZvLhuORYsC0CLgT6Sw2HDJYTblQk3klWjbCdmn82p5w mk5FN2uRSsyVuqQyAAYpJUWiS4GmsznlHXUxJRFc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150413152503.GA14839@elstar.local> Date: Mon, 13 Apr 2015 17:39:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4344AE95-A6EE-4C5B-A513-20E0ADF2BFE8@nic.cz> References: <20150401142727.GA75021@elstar.local> <20150413152503.GA14839@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/pUR9Vdkyb60fou2_ZBycBZySEb4> Cc: netmod@ietf.org Subject: Re: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 15:39:20 -0000 > On 13 Apr 2015, at 17:25, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >=20 > On Wed, Apr 01, 2015 at 04:27:27PM +0200, Juergen Schoenwaelder wrote: >> Hi, >>=20 >> this I-D has been presented at IETF 92 and there was support to adopt >> this work as WG work item. The abstract of the document says: >>=20 >> This document defines a YANG extension statement that allows for >> defining the syntax of metadata annotions in YANG modules. The >> document also specifies the XML and JSON encoding of annotations = and >> other rules for annotating instances of YANG data nodes. >>=20 >> This is a call to verify this on the mailing list. Given the support >> this saw at IETF 92, I will read silence as support. People who see = an >> issue with adopting this document should send an email with an >> explanation to the WG and/or the WG chairs by April 10th. >>=20 >=20 > Since I have not received any further comments, I conclude that the > metadata document will become a WG document now. Lada, please post > the next version as draft-ietf-netmod-yang-metadata-00 and I will > approve it. Will do. Thanks, Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Apr 13 09:29:04 2015 Return-Path: <cwildes@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC4F1ACE53 for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_8bdui8sSoc for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 09:29:00 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245FD1ACE55 for <netmod@ietf.org>; Mon, 13 Apr 2015 09:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27192; q=dns/txt; s=iport; t=1428942540; x=1430152140; h=from:to:subject:date:message-id:mime-version; bh=oRcz9RT+SahMx9PalIY83lj3e2D0zghVsg5B4ZIRTDI=; b=ceFHc19DDxUGOeNj9uNUCDDnjM3xXhFrtcGCqtVMHC4IyNHGkV7gUUJl US/x4jsTUx1Hj7Ty68XhR4qzscFCXxB2paHgf8fVaPe7aPYloS3PXY0N7 htfvMxSv806+pjT/7qaDfKQ6RpGIXO78c6ZVSO930dYz4z1A3YP4wk/Lx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnBABc7itV/4wNJK1cgkVHUlwFgxDBfQmBToYBAhyBHjgUAQEBAQEBAX2EHwECBCMEBl4BCBEDAQIoAwIEMBQJCgQBEogqDbcUlgkBAQEBAQEEAQEBAQEBAQEaiyuEGQsGAQYgBxMegmKBRQWGI4hPghqKD4EdgzeJDoM9g00iggAfgVBvAYECCBcifwEBAQ X-IronPort-AV: E=Sophos;i="5.11,570,1422921600"; d="scan'208,217";a="140798731" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 13 Apr 2015 16:28:59 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t3DGSxuc007227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 16:28:59 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.176]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 11:28:58 -0500 From: "Clyde Wildes (cwildes)" <cwildes@cisco.com> To: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] Some feedback on syslog-model-03 Thread-Index: AQHQdgbxuQK/CkiEE0SpGPH/I5/mhA== Date: Mon, 13 Apr 2015 16:29:48 +0000 Message-ID: <44D65B60-78B3-4F3B-93B1-686551084FDF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.157.242] Content-Type: multipart/alternative; boundary="_000_44D65B6078B34F3B93B1686551084FDFciscocom_" MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/_MxRcLuM3kBZOCTrIlXXhfBVR6Y> Subject: Re: [netmod] Some feedback on syslog-model-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 16:29:03 -0000 --_000_44D65B6078B34F3B93B1686551084FDFciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFzb24sDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXchDQoNCk15IGNvbW1lbnRzIGFyZSBp bmxpbmXigKYNCg0KRnJvbTogPFN0ZXJuZT4sICJKYXNvbiAoSmFzb24pIg0KRGF0ZTogVGh1cnNk YXksIE1hcmNoIDI2LCAyMDE1IGF0IDU6MjIgUE0NClRvOiAibmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+Ig0KU3ViamVjdDogW25ldG1vZF0gU29tZSBmZWVkYmFjayBvbiBz eXNsb2ctbW9kZWwtMDMNCg0KSGkgYWxsLA0KDQpEdXJpbmcgYSBudW1iZXIgb2YgZGlzY3Vzc2lv bnMgdGhpcyB3ZWVrIHdpdGggb3RoZXIgdmVuZG9ycyBhbmQgb3BlcmF0b3JzIEkgd2FzIGVuY291 cmFnZWQgdG8gZW5zdXJlIHRoYXQgSSByYWlzZSBjb21tZW50cy9pc3N1ZXMgZnJvbSBBTFUgd2l0 aCBzb21lIG9mIHRoZSBZQU5HIG1vZGVscyB1bmRlcndheSBpbmNsdWRpbmcgc3lzbG9nLiAgQ2x5 ZGUgYW5kIEkgbWV0IHRoaXMgbW9ybmluZyBhbmQgd2UgdGhvdWdodCBpdCB3b3VsZCBiZSBnb29k IGZvciBtZSB0byBwb3N0IHRoZSBjb21tZW50cyB0byB0aGUgbGlzdC4NCg0KSSdtIGdvaW5nIHRv IGJyZWFrIHRoZSBjb21tZW50cyBpbnRvIGEgZmV3IGVtYWlsIHRocmVhZHMgLSBpdCBzb21ldGlt ZXMgZ2V0cyBjb25mdXNpbmcgaWYgdG9vIG1hbnkgaXNzdWVzIGFyZSBjb21iaW5lZCBpbnRvIGEg c2luZ2xlIGRpc2N1c3Npb24uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpBKSBjbGFyaWZ5IHN5c2xvZy1zZWxlY3RvciBiZWhhdmlvcg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSXQgd291bGQgYmUg Z29vZCB0byBjbGFyaWZ5IHRoZSBiZWhhdmlvciBvZiB0aGUgc2VsZWN0b3IvZmlsdGVyIGluIHRo ZSBkcmFmdCB0ZXh0ICYgeWFuZyBtb2R1bGUuIElmIHdlIGNvbnNpZGVyIHRoZSB1c2Ugb2YgdGhl IHN5c2xvZy1zZWxlY3RvciBpbnNpZGUgdGhlIG1lc3NhZ2UtZGlzdHJpYnV0b3JzIChidWZmZXJl ZC1sb2dnaW5nLWFjdGlvbiwgZmlsZS1sb2dnaW5nLWFjdGlvbiwgZXRjKSBJIGJlbGlldmUgdGhl IGludGVuZGVkIGJlaGF2aW9yIGlzIHRoYXQgd2hlbiBhIHNlbGVjdG9yIGlzIHVzZWQvY29uZmln dXJlZCB0aGVuIGl0IGlzIGVmZmVjdGl2ZWx5IGEg4oCcZGVmYXVsdCBkZW554oCdIGZpbHRlciB0 aGF0IG9ubHkgYWxsb3dzIGxvZyBldmVudHMgdG8gcGFzcyB0aGUgc2VsZWN0b3IgaWYgdGhleSBt YXRjaCB0aGUgY29uZmlndXJlZCBmYWNpbGl0eStzZXZlcml0eSAob3IgdGhlIGNvbmZpZ3VyZWQg c2V2ZXJpdHkpLiAgSW4gb3RoZXIgd29yZHMgLT4gaWYgdGhlcmUgaXMgbm8gPHNldmVyaXR5PiBv ciA8ZmFjaWxpdHk+IHRhZ3MgaW5zaWRlIGEgPGJ1ZmZlcmVkLWxvZ2dpbmctYWN0aW9uPiAoaS5l LiBubyBzZWxlY3RvciBjb25maWcpIHRoZW4gbm8gbG9nIGV2ZW50cyB3b3VsZCBnbyB0byB0aGUg YnVmZmVyLg0KDQpbY2x5ZGVdIFlvdXIgZGVzY3JpcHRpb24gaXMgY29ycmVjdC4gSXQgaXMgYSAi ZGVmYXVsdCBkZW55IiBmaWx0ZXIuDQoNCkknbSBhIGxpdHRsZSBsZXNzIGNsZWFyIG9uIHRoZSBl eHBlY3RlZCBiZWhhdmlvciBvciBuZWVkIGZvciB0aGUgPG5vbmU+IChjYXNlIGxvZ2dpbmctZmFj aWxpdHktbm9uZSkgbGVhZi4gSXNuJ3QgaXQganVzdCBlcXVpdmFsZW50IHRvIHRoZSBhYnNlbmNl IG9mIGFueSA8c2V2ZXJpdHk+IG9yIDxmYWNpbGl0eT4gaXRlbXMgY29uZmlndXJlZCA/DQoNCltj bHlkZV0gTW9zdCBOT1MgaGF2ZSBhIGRlZmF1bHQgc3lzbG9nIGJlaGF2aW9yIGZvciBzb21lIG9m IHRoZSBhY3Rpb25zLiBUaGUgPG5vbmU+IGNhc2Ugd2FzIG1lYW50IHRvIHJlbW92ZSB0aGUgZGVm YXVsdCBiZWhhdmlvci4gQSBiZXR0ZXIgd2F5IGZvcndhcmQgd291bGQgYmUgZm9yIHRoZSB1c2Vy IHRvIHVzZSBhIE5ldGNvbmYvUmVzdGNvbmYgImRlbGV0ZSIgb3BlcmF0aW9uIG9uIHRoZSBzZWxl Y3RvciBmb3IgdGhlIGFwcHJvcHJpYXRlIGFjdGlvbiB0byByZW1vdmUgdGhlIGRlZmF1bHQgYmVo YXZpb3IuIFRoZXJlZm9yZSBsb2dnaW5nLWZhY2lsaXR5LW5vbmUgc2hvdWxkIGJlIHJlbW92ZWQu DQoNCkluIGFkZGl0aW9uIHRvIHRoZSBhYm92ZSBJIHRoaW5rIHRoYXQgZW11bGF0aW5nIHRoZSBy c3lzbG9nIHNlbGVjdG9yIHByaW9yaXR5IGJlaGF2aW9yIChodHRwOi8vd3d3LnJzeXNsb2cuY29t L2RvYy92OC1zdGFibGUvY29uZmlndXJhdGlvbi9maWx0ZXJzLmh0bWwpIHdoZXJlICJub25lIiBp cyBhbiBhdHRyaWJ1dGUgdG8gc3VwcHJlc3MgYWxsIG1lc3NhZ2VzIGZyb20gb25lIG9yIG1vcmUg ZmFjaWxpdGllcyBzaG91bGQgYmUgaW1wbGVtZW50ZWQuDQoNCldlIHNob3VsZCBhbHNvIGJlIGV4 cGxpY2l0IHRoYXQgdGhlIChiYXNpYykgc2V2ZXJpdHkgc2VsZWN0aW9uIGlzIGFuICdlcXVhbHMt b3ItaGlnaGVyJyBzZXZlcml0eSBkZWNpc2lvbiAobm90ZSB0aGF0IGFsdGhvdWdoIGxvd2VyIHNl dmVyaXR5IGVudW0gdmFsdWVzIGFyZSBhY3R1YWxseSBtb3JlIGNyaXRpY2FsIHRoYW4gaGlnaGVy IHZhbHVlcywgZS5nLiBlbWVyZ2VuY3k9MCwgd2Ugc2hvdWxkIGRlc2NyaWJlIHRoaXMgaW4gdGVy bXMgb2Ygc2V2ZXJpdHkvY3JpdGljYWxpdHkgSU1PKS4NCg0KW2NseWRlXSBJIGFncmVlIHRoYXQg dGhlIGRvY3VtZW50YXRpb24gc2hvdWxkIGJlIGltcHJvdmVkLg0KDQpJcyBhbGwgdGhlIGJlaGF2 aW9yIGFib3ZlIChpbmNsdWRpbmcgPG5vbmU+KSBpbnRlbmRlZCB0byBiZSB0aGUgZXhhY3Qgc2Ft ZSBmb3IgdGhlIG9wdGlvbmFsIGdsb2JhbC1sb2dnaW5nLWFjdGlvbiA/ICBJZiB0aGF0IGlzIHRo ZSBjYXNlIGFuZCB0aGUgZmVhdHVyZSBpcyBzdXBwb3J0ZWQgb24gYSBwbGF0Zm9ybSB0aGVuIEkg dGhpbmsgdGhhdCBtZWFucyB0aGF0IG5vIGdsb2JhbCBjb25maWcgd291bGQgbWVhbiBubyBsb2cg bWVzc2FnZXMgc2VudCB0byBhbnkgZGlzdHJpYnV0b3JzLg0KDQpbY2x5ZGVdIGdsb2JhbC1sb2dn aW5nLWFjdGlvbiBzaG91bGQgYmUgcmVtb3ZlZCBhbmQgYWRkZWQgYXMgbmVlZGVkIGFzIGEgdmVu ZG9yIHNwZWNpZmljIGF1Z21lbnRhdGlvbi4NCg0KSSdtIGhhcHB5IHRvIGhlbHAgY29uc3RydWN0 IHNvbWUgc3BlY2lmaWMgdGV4dC9kZXNjcmlwdGlvbnMgYnV0IHdhbnRlZCB0byBtYWtlIHN1cmUg SSB1bmRlcnN0YW5kIHRoZSBpbnRlbnQgZmlyc3QuDQoNCltjbHlkZV0gVGhhbmtzIQ0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQikgc3RydWN0dXJl ZCBkYXRhIGFzIGEgc2luZ2xlIGZlYXR1cmUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpUaGVyZSBhcmUgY3VycmVudGx5IHR3byBzdHJ1Y3R1cmVkIGRh dGEgcmVsYXRlZCBmZWF0dXJlcy4gIFNob3VsZCB3ZSBjb21iaW5lIHRoYXQgaW50byBhIHNpbmds ZSBmZWF0dXJlID8gIERvIHRoZSB2ZW5kb3JzIHdobyBzdXBwb3J0IHRoaXMgbm90IHRlbmQgdG8g dGhlbiBzdXBwb3J0IGl0IGZvciBib3RoIGZpbGVzIGFuZCByZW1vdGUgZGVzdGluYXRpb25zIGFu eXdheXMgPw0KDQpbY2x5ZGVdIEluIGEgc2VwYXJhdGUgdGhyZWFkIEkgYWR2b2NhdGVkIHJlbW92 YWwgb2YgdGhlIHN0cnVjdHVyZWQgZGF0YSBsb2dnaW5nIGZlYXR1cmUgZm9yIHJlbW90ZSBtZXNz YWdlIGRlbGl2ZXJ5LiBObyB2ZW5kb3IgaGFzIGltcGxlbWVudGVkIHRoaXMgQUZBSUsgYW5kIGl0 IGNvdWxkIGJlIGFkZGVkIGFzIGEgdmVuZG9yIHNwZWNpZmljIGF1Z21lbnRhdGlvbiBpZiBuZWVk ZWQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpD KSBtYXggc2l6ZXMvbnVtYmVycyBmb3IgbG9ncw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZXJlIGFyZSBhIGZldyBwbGFjZXMgd2hlcmUgYSBzaXpl IGlzIGNvbmZpZ3VyZWQgKGJ1ZmZlci1zaXplLCBmaWxlLXNpemUpLiBJbXBsZW1lbnRhdGlvbnMg d2lsbCB2YXJ5IG9uIHdoYXQgdW5pdHMgYXJlIHVzZWQgaW4gYSB3YXkgdGhhdCBpc24ndCByZWFs bHkgZGlyZWN0bHkgY29udmVydGlibGUgKGUuZy4gYnl0ZXMgdnMgIyBvZiBsb2cgbWVzc2FnZXMp Lg0KDQpGb3IgZmlsZSBsb2dnaW5nIHNvbWUgaW1wbGVtZW50YXRpb25zIHVzZSBhIHJldGVudGlv biB0aW1lIHJhdGhlciB0aGFuIGEgc2l6ZSBsaW1pdCBvciBmaWxlIG51bWJlciBsaW1pdCBzbyBJ J20gZ2xhZCB0byBzZWUgYW4gaWYtZmVhdHVyZSBhcm91bmQgdGhpcyAob3IgcmVtb3RlIGl0IGFu ZCBsZXQgdGhlIHZlbmRvciBhdWdtZW50IGZvciB0aGF0KQ0KDQpJdCBpcyBwcm9iYWJseSBtb3Jl IGNvbW1vbiB0byBoYXZlIGEgc2l6ZSBmb3IgdGhlIG1lbW9yeSBidWZmZXJzIHNvIHRoYXQgaXMg cHJvYmFibHkgT0sgdG8gbGVhdmUgaW4uDQoNCldoYXRldmVyIHNpemVzIHJlbWFpbiBpbiB0aGUg bW9kZWw6DQotIHJlbW92ZSBhbnkgZGVmYXVsdCB2YWx1ZXMNCi0gZXhwbGFpbiBpbiB0aGUgZGVz Y3JpcHRpb24gdGhhdCAiVGhpcyBsZWFmIHNwZWNpZmllcyB0aGUgbWF4aW11bSB4eXogc2l6ZS4g IFRoZSB1bml0cyBhcmUgbm90IHNwZWNpZmllZCBpbiB0aGlzIG1vZGVsIGFuZCB2YXJpZXMgYnkg aW1wbGVtZW50YXRpb24gKGUuZy4gYnl0ZXMgdnMgbnVtYmVyIG9mIGxvZyBtZXNzYWdlcykuIg0K DQpbY2x5ZGVdIFBsZWFzZSBiZSBzcGVjaWZpYyBhYm91dCB0aGUgZGVmYXVsdCB2YWx1ZXMgdGhh dCB5b3UgZmVlbCBhcmUgaW5hcHByb3ByaWF0ZS4gT25lIG9mIHRoZSBZQU5HIGRvY3RvciBmZWVk YmFjayBpdGVtcyB3YXMgdG8gaW5jbHVkZSBkZWZhdWx0cyBmb3IgY2xhcml0eS4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkQpIHRlcm1pbmFsIGRp c3RyaWJ1dG9yIGFuZCBwZXJzaXN0ZW5jeQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClRlcm1pbmFsIGxvZ2dpbmcgaXMgc2Vzc2lvbi1zcGVjaWZpYyBp biBzZXZlcmFsIGltcGxlbWVudGF0aW9ucyBhbmQgY29uZmlnIGdlbmVyYWxseSBkaXNhcHBlYXJz IG9uY2UgdGhlIHNlc3Npb24gaXMgZG9uZS4gIEl0IGlzIGFsc28gbm90IGNsZWFyIHdoYXQgbG9n Z2luZyB0byB0aGUgbG9jYWwgc2Vzc2lvbiBzaG91bGQgcmVhbGx5IG1lYW4gZm9yIGEgbmV0Y29u ZiBzZXNzaW9uLiAgSSdtIG5vdCBzdXJlIHRoaXMgZGlzdHJpYnV0b3Igc2hvdWxkIGJlIGluIHRo ZSBtb2RlbC4NCg0KW2NseWRlXSBUZXJtaW5hbCBsb2dnaW5nIGlzIGltcGxlbWVudGVkIGJ5IGFs bCBvZiB0aGUgdmVuZG9ycyB3ZSBleGFtaW5lZC4gUGxlYXNlIGV4cGxhaW4geW91ciBjb25jZXJu IGFib3V0IGxvZ2dpbmcgdG8gdGhlIE5ldGNvbmYgc2Vzc2lvbiB0ZXJtaW5hbC4gV291bGQgbm90 IHRoaXMgYmUgdGhlIHNhbWUgZm9yIGFueSB0ZXJtaW5hbCB0aGF0IHJlY2VpdmVkIHN5c2xvZyBt ZXNzYWdlcyBhbmQgd2FzIGFsc28gdXNlZCBmb3Igb3RoZXIgcHVycG9zZXM/DQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFKSBlZGl0b3JpYWwvbWlu b3IgbWlzYw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Ci0gU2hvdWxkIHdlIHVwZGF0ZSB0aGUgV0cgY2hhaXIgbmFtZSAoRGF2aWQgS2Vzc2VucykgPw0K DQpbY2x5ZGVdIEFncmVlZC4NCg0KLSBJJ2Qgc3VnZ2VzdCAnbGlzdCBsb2dnaW5nLWZhY2lsaXRp ZXMnIGFuZCAna2V5ICJmYWNpbGl0eSInIGJlIGNoYW5nZWQgdG8gJ2xpc3QgZmFjaWxpdHknIHdp dGggJ2tleSAiZmFjaWxpdHktbmFtZSInLiAgSWYgYSBsaXN0IGlzIGluIGEgY29udGFpbmVyIHRo ZW4gdGhlIHBsdXJhbCBuYW1lIG1ha2VzIHNlbnNlIGZvciB0aGUgY29udGFpbmVyIGJ1dCBJIHRo aW5rIHNpbmd1bGFyIGlzIGJldHRlciBmb3IgdGhlIGxpc3QgKGxpa2UgaG93IGlldGYtaW50ZXJm YWNlcyBpcyBkb25lKS4NCg0KW2NseWRlXSBBZ3JlZWQuDQoNCi0gVGhlIGludHJvZHVjdGlvbiBz YXlzICJXZSBhcmUgdXNpbmcgZGVmaW5pdGlvbnMgb2YgU3lzbG9nIHByb3RvY29sIGZyb20gW1JG QzMxNjRdIGluIHRoaXMgZHJhZnQuIiBidXQgdGhlIFlBTkcgbW9kZWwgbW9zdGx5IHJlZmVyZW5j ZXMgNTQyNC4NCg0KW2NseWRlXSBXZSB3aWxsIGNoYW5nZSB0aGlzLg0KDQotIEluIHNlY3Rpb24g MyBpbnN0ZWFkIG9mICJncm91cCBsZXZlbCIgcGVyaGFwcyBpdCBpcyBiZXR0ZXIgdG8gdXNlICJn bG9iYWwgbGV2ZWwiIChhbmQgaW4gdGhlIGZpZ3VyZSkgPyAgSSdtIG5vdCBzdXJlIHdoYXQgZ3Jv dXAgbWVhbnMgKHdoaWNoIGdyb3VwIC0gaW1wbGllcyBpdCBpc24ndCBuZWNlc3NhcmlseSB0aGUg ZW50aXJlIGxvZyBzdHJlYW0pLg0KDQpbY2x5ZGVdIEdyb3VwIGxldmVsIHN1cHByZXNzaW9uIG5v IGxvbmdlciBhcHBsaWVzIG9uY2UgdGhlIGdsb2JhbC1sb2dnaW5nLWFjdGlvbiBpcyByZW1vdmVk LiBXZSB3aWxsIHJlbW92ZSBpdC4NCg0KLSBNYXliZSB1c2UgdGhlIHRlcm0gIlJlbW92ZSBDb2xs ZWN0b3IocykiIGluc3RlYWQgb2YgU2VydmVyKHMpID8gQ29sbGVjdG9yIHNlZW1zIG1vcmUgaW4g bGluZSB3aXRoIFJGQzU0MjQgKG9yICJSZW1vdGUgUmVjZWl2ZXIiIGlmIG90aGVycyBwcmVmZXIg dGhhdCkuDQoNCltjbHlkZV0gQWdyZWVkLg0KDQotIEluIHRoZSBTZWN0aW9uIDMgZmlndXJlIG1h a2UgYWxsIHRoZSBEaXN0cmlidXRvcnMgaGF2ZSBhIGNvbW1vbiB1c2Ugb2YgcGx1cmFsIHZzIHNp bmd1bGFyICJidWZmZXIocykiLCAiTG9nIEZpbGUocykiLCAiUmVtb3RlIENvbGxlY3RvcihzKSIu ICAgVXNlciBUZXJtaW5hbCBzaG91bGQgcHJvYmFibHkgYmUgc2luZ3VsYXIuDQoNCltjbHlkZV0g V2UgdHJpZWQgdG8gdXNlIG5hbWVzIHRoYXQgbWlycm9yIHRoZSBhY3R1YWwgdXNlIGNhc2VzOiBv bmUgY29uc29sZTsgb25lIGxvZyBidWZmZXI7IG9uZSBvciBtb3JlIGxvZyBmaWxlczsgb25lIG9y IG1vcmUgdXNlciB0ZXJtaW5hbHM7IGFuZCBvbmUgb3IgbW9yZSByZW1vdGUgc2VydmVycy4NCg0K LSBEb2N1bWVudCBpcyBtaXNzaW5nIHRoZSBzdGFuZGFyZCBsZWdlbmQgZm9yIHRoZSBQWUFORyB0 cmVlDQoNCltjbHlkZV0gV2Ugd2lsbCBmaXggdGhpcy4NCg0KVGhhbmtzLA0KDQpDbHlkZQ0KDQpS ZWdhcmRzLA0KSmFzb24NCg0KDQoNCg0KDQo= --_000_44D65B6078B34F3B93B1686551084FDFciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7118C23DE850D54BB2FCC5E1DB869B4D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkhpIEphc29uLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciB5 b3VyIHJldmlldyE8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk15IGNvbW1lbnRzIGFy ZSBpbmxpbmXigKY8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUi PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh bj4mbHQ7U3Rlcm5lJmd0OywgJnF1b3Q7SmFzb24gKEphc29uKSZxdW90Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIE1hcmNoIDI2LCAy MDE1IGF0IDU6MjIgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv c3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5v cmc8L2E+JnF1b3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6 IDwvc3Bhbj5bbmV0bW9kXSBTb21lIGZlZWRiYWNrIG9uIHN5c2xvZy1tb2RlbC0wMzxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNv bnRlbnQ9Ik1pY3Jvc29mdCBFeGNoYW5nZSBTZXJ2ZXIiPg0KPCEtLSBjb252ZXJ0ZWQgZnJvbSBy dGYgLS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5n LWxlZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+ DQo8ZGl2Pjxmb250IGZhY2U9IkNvbnNvbGFzIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDsiPg0KPGRpdj5IaSBhbGwsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRp dj5EdXJpbmcgYSBudW1iZXIgb2YgZGlzY3Vzc2lvbnMgdGhpcyB3ZWVrIHdpdGggb3RoZXIgdmVu ZG9ycyBhbmQgb3BlcmF0b3JzIEkgd2FzIGVuY291cmFnZWQgdG8gZW5zdXJlIHRoYXQgSSByYWlz ZSBjb21tZW50cy9pc3N1ZXMgZnJvbSBBTFUgd2l0aCBzb21lIG9mIHRoZSBZQU5HIG1vZGVscyB1 bmRlcndheSBpbmNsdWRpbmcgc3lzbG9nLiZuYnNwOyBDbHlkZSBhbmQgSSBtZXQgdGhpcyBtb3Ju aW5nIGFuZCB3ZSB0aG91Z2h0IGl0IHdvdWxkIGJlDQogZ29vZCBmb3IgbWUgdG8gcG9zdCB0aGUg Y29tbWVudHMgdG8gdGhlIGxpc3QuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JJ20g Z29pbmcgdG8gYnJlYWsgdGhlIGNvbW1lbnRzIGludG8gYSBmZXcgZW1haWwgdGhyZWFkcyAtIGl0 IHNvbWV0aW1lcyBnZXRzIGNvbmZ1c2luZyBpZiB0b28gbWFueSBpc3N1ZXMgYXJlIGNvbWJpbmVk IGludG8gYSBzaW5nbGUgZGlzY3Vzc2lvbi48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8 ZGl2PkEpIGNsYXJpZnkgc3lzbG9nLXNlbGVjdG9yIGJlaGF2aW9yPC9kaXY+DQo8ZGl2Pi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj5JdCB3b3VsZCBiZSBnb29kIHRvIGNsYXJpZnkgdGhlIGJlaGF2aW9y IG9mIHRoZSBzZWxlY3Rvci9maWx0ZXIgaW4gdGhlIGRyYWZ0IHRleHQgJmFtcDsgeWFuZyBtb2R1 bGUuIElmIHdlIGNvbnNpZGVyIHRoZSB1c2Ugb2YgdGhlIHN5c2xvZy1zZWxlY3RvciBpbnNpZGUg dGhlIG1lc3NhZ2UtZGlzdHJpYnV0b3JzIChidWZmZXJlZC1sb2dnaW5nLWFjdGlvbiwgZmlsZS1s b2dnaW5nLWFjdGlvbiwgZXRjKSBJIGJlbGlldmUgdGhlIGludGVuZGVkIGJlaGF2aW9yDQogaXMg dGhhdCB3aGVuIGEgc2VsZWN0b3IgaXMgdXNlZC9jb25maWd1cmVkIHRoZW4gaXQgaXMgZWZmZWN0 aXZlbHkgYSDigJxkZWZhdWx0IGRlbnnigJ0gZmlsdGVyIHRoYXQgb25seSBhbGxvd3MgbG9nIGV2 ZW50cyB0byBwYXNzIHRoZSBzZWxlY3RvciBpZiB0aGV5IG1hdGNoIHRoZSBjb25maWd1cmVkIGZh Y2lsaXR5JiM0MztzZXZlcml0eSAob3IgdGhlIGNvbmZpZ3VyZWQgc2V2ZXJpdHkpLiZuYnNwOyBJ biBvdGhlciB3b3JkcyAtJmd0OyBpZiB0aGVyZSBpcyBubyAmbHQ7c2V2ZXJpdHkmZ3Q7DQogb3Ig Jmx0O2ZhY2lsaXR5Jmd0OyB0YWdzIGluc2lkZSBhICZsdDtidWZmZXJlZC1sb2dnaW5nLWFjdGlv biZndDsgKGkuZS4gbm8gc2VsZWN0b3IgY29uZmlnKSB0aGVuIG5vIGxvZyBldmVudHMgd291bGQg Z28gdG8gdGhlIGJ1ZmZlci48L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwv c3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PltjbHlkZV0gWW91ciBkZXNjcmlwdGlvbiBp cyBjb3JyZWN0LiBJdCBpcyBhICZxdW90O2RlZmF1bHQgZGVueSZxdW90OyBmaWx0ZXIuPC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ29uc29sYXMiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JJ20gYSBsaXR0bGUgbGVzcyBjbGVhciBvbiB0aGUgZXhw ZWN0ZWQgYmVoYXZpb3Igb3IgbmVlZCBmb3IgdGhlICZsdDtub25lJmd0OyAoY2FzZSBsb2dnaW5n LWZhY2lsaXR5LW5vbmUpIGxlYWYuIElzbid0IGl0IGp1c3QgZXF1aXZhbGVudCB0byB0aGUgYWJz ZW5jZSBvZiBhbnkgJmx0O3NldmVyaXR5Jmd0OyBvciAmbHQ7ZmFjaWxpdHkmZ3Q7IGl0ZW1zIGNv bmZpZ3VyZWQgPzwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W2NseWRlXSBNb3N0IE5PUyBoYXZlIGEgZGVmYXVsdCBz eXNsb2cgYmVoYXZpb3IgZm9yIHNvbWUgb2YgdGhlIGFjdGlvbnMuIFRoZSAmbHQ7bm9uZSZndDsg Y2FzZSB3YXMgbWVhbnQgdG8gcmVtb3ZlIHRoZSBkZWZhdWx0IGJlaGF2aW9yLiBBIGJldHRlciB3 YXkgZm9yd2FyZCB3b3VsZCBiZSBmb3IgdGhlIHVzZXIgdG8gdXNlIGEgTmV0Y29uZi9SZXN0Y29u ZiAmcXVvdDtkZWxldGUmcXVvdDsgb3BlcmF0aW9uIG9uIHRoZSBzZWxlY3RvciBmb3IgdGhlIGFw cHJvcHJpYXRlDQogYWN0aW9uIHRvIHJlbW92ZSB0aGUgZGVmYXVsdCBiZWhhdmlvci4gVGhlcmVm b3JlIGxvZ2dpbmctZmFjaWxpdHktbm9uZSBzaG91bGQgYmUgcmVtb3ZlZC48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkluIGFkZGl0aW9uIHRvIHRoZSBhYm92ZSBJIHRoaW5rIHRoYXQg ZW11bGF0aW5nIHRoZSByc3lzbG9nIHNlbGVjdG9yIHByaW9yaXR5IGJlaGF2aW9yICg8YSBocmVm PSJodHRwOi8vd3d3LnJzeXNsb2cuY29tL2RvYy92OC1zdGFibGUvY29uZmlndXJhdGlvbi9maWx0 ZXJzLmh0bWwiPmh0dHA6Ly93d3cucnN5c2xvZy5jb20vZG9jL3Y4LXN0YWJsZS9jb25maWd1cmF0 aW9uL2ZpbHRlcnMuaHRtbDwvYT4pIHdoZXJlICZxdW90O25vbmUmcXVvdDsgaXMgYW4gYXR0cmli dXRlDQogdG8gc3VwcHJlc3MgYWxsIG1lc3NhZ2VzIGZyb20gb25lIG9yIG1vcmUgZmFjaWxpdGll cyBzaG91bGQgYmUgaW1wbGVtZW50ZWQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+V2Ugc2hvdWxkIGFsc28gYmUg ZXhwbGljaXQgdGhhdCB0aGUgKGJhc2ljKSBzZXZlcml0eSBzZWxlY3Rpb24gaXMgYW4gJ2VxdWFs cy1vci1oaWdoZXInIHNldmVyaXR5IGRlY2lzaW9uIChub3RlIHRoYXQgYWx0aG91Z2ggbG93ZXIg c2V2ZXJpdHkgZW51bSB2YWx1ZXMgYXJlIGFjdHVhbGx5IG1vcmUgY3JpdGljYWwgdGhhbiBoaWdo ZXIgdmFsdWVzLCBlLmcuIGVtZXJnZW5jeT0wLCB3ZSBzaG91bGQgZGVzY3JpYmUgdGhpcyBpbiB0 ZXJtcyBvZg0KIHNldmVyaXR5L2NyaXRpY2FsaXR5IElNTykuPC9kaXY+DQo8L3NwYW4+PC9mb250 Pjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PltjbHlkZV0gSSBhZ3JlZSB0aGF0IHRo ZSBkb2N1bWVudGF0aW9uIHNob3VsZCBiZSBpbXByb3ZlZC48L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+PGZvbnQgZmFjZT0iQ29uc29sYXMiIHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0OyI+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+SXMgYWxsIHRoZSBiZWhhdmlvciBhYm92ZSAoaW5jbHVkaW5nICZsdDtub25lJmd0Oykg aW50ZW5kZWQgdG8gYmUgdGhlIGV4YWN0IHNhbWUgZm9yIHRoZSBvcHRpb25hbCBnbG9iYWwtbG9n Z2luZy1hY3Rpb24gPyZuYnNwOyBJZiB0aGF0IGlzIHRoZSBjYXNlIGFuZCB0aGUgZmVhdHVyZSBp cyBzdXBwb3J0ZWQgb24gYSBwbGF0Zm9ybSB0aGVuIEkgdGhpbmsgdGhhdCBtZWFucyB0aGF0IG5v IGdsb2JhbCBjb25maWcgd291bGQgbWVhbiBubyBsb2cgbWVzc2FnZXMNCiBzZW50IHRvIGFueSBk aXN0cmlidXRvcnMuPC9kaXY+DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PltjbHlkZV0gZ2xvYmFsLWxvZ2dpbmctYWN0aW9uIHNob3VsZCBiZSByZW1vdmVk IGFuZCBhZGRlZCBhcyBuZWVkZWQgYXMgYSB2ZW5kb3Igc3BlY2lmaWMgYXVnbWVudGF0aW9uLjwv ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48Zm9udCBmYWNlPSJDb25zb2xh cyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PkknbSBoYXBweSB0byBoZWxwIGNvbnN0cnVjdCBzb21lIHNwZWNpZmljIHRl eHQvZGVzY3JpcHRpb25zIGJ1dCB3YW50ZWQgdG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZCB0aGUg aW50ZW50IGZpcnN0LjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L3NwYW4+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5bY2x5ZGVdIFRoYW5rcyE8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiI+PGZvbnQgZmFjZT0iQ29uc29sYXMiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0OyI+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj5CKSBzdHJ1Y3R1cmVk IGRhdGEgYXMgYSBzaW5nbGUgZmVhdHVyZTwvZGl2Pg0KPGRpdj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj5UaGVyZSBhcmUgY3VycmVu dGx5IHR3byBzdHJ1Y3R1cmVkIGRhdGEgcmVsYXRlZCBmZWF0dXJlcy4mbmJzcDsgU2hvdWxkIHdl IGNvbWJpbmUgdGhhdCBpbnRvIGEgc2luZ2xlIGZlYXR1cmUgPyZuYnNwOyBEbyB0aGUgdmVuZG9y cyB3aG8gc3VwcG9ydCB0aGlzIG5vdCB0ZW5kIHRvIHRoZW4gc3VwcG9ydCBpdCBmb3IgYm90aCBm aWxlcyBhbmQgcmVtb3RlIGRlc3RpbmF0aW9ucyBhbnl3YXlzID88L2Rpdj4NCjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W2NseWRlXSBJbiBhIHNlcGFyYXRl IHRocmVhZCBJIGFkdm9jYXRlZCByZW1vdmFsIG9mIHRoZSBzdHJ1Y3R1cmVkIGRhdGEgbG9nZ2lu ZyBmZWF0dXJlIGZvciByZW1vdGUgbWVzc2FnZSBkZWxpdmVyeS4gTm8gdmVuZG9yIGhhcyBpbXBs ZW1lbnRlZCB0aGlzIEFGQUlLIGFuZCBpdCBjb3VsZCBiZSBhZGRlZCBhcyBhIHZlbmRvciBzcGVj aWZpYyBhdWdtZW50YXRpb24gaWYgbmVlZGVkLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9E WV9TRUNUSU9OIj48Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2PkMpIG1heCBzaXpl cy9udW1iZXJzIGZvciBsb2dzPC9kaXY+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2PlRoZXJlIGFyZSBhIGZldyBwbGFjZXMg d2hlcmUgYSBzaXplIGlzIGNvbmZpZ3VyZWQgKGJ1ZmZlci1zaXplLCBmaWxlLXNpemUpLiBJbXBs ZW1lbnRhdGlvbnMgd2lsbCB2YXJ5IG9uIHdoYXQgdW5pdHMgYXJlIHVzZWQgaW4gYSB3YXkgdGhh dCBpc24ndCByZWFsbHkgZGlyZWN0bHkgY29udmVydGlibGUgKGUuZy4gYnl0ZXMgdnMgIyBvZiBs b2cgbWVzc2FnZXMpLg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Gb3IgZmlsZSBs b2dnaW5nIHNvbWUgaW1wbGVtZW50YXRpb25zIHVzZSBhIHJldGVudGlvbiB0aW1lIHJhdGhlciB0 aGFuIGEgc2l6ZSBsaW1pdCBvciBmaWxlIG51bWJlciBsaW1pdCBzbyBJJ20gZ2xhZCB0byBzZWUg YW4gaWYtZmVhdHVyZSBhcm91bmQgdGhpcyAob3IgcmVtb3RlIGl0IGFuZCBsZXQgdGhlIHZlbmRv ciBhdWdtZW50IGZvciB0aGF0KTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SXQgaXMg cHJvYmFibHkgbW9yZSBjb21tb24gdG8gaGF2ZSBhIHNpemUgZm9yIHRoZSBtZW1vcnkgYnVmZmVy cyBzbyB0aGF0IGlzIHByb2JhYmx5IE9LIHRvIGxlYXZlIGluLjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+V2hhdGV2ZXIgc2l6ZXMgcmVtYWluIGluIHRoZSBtb2RlbDo8L2Rpdj4NCjxk aXY+LSByZW1vdmUgYW55IGRlZmF1bHQgdmFsdWVzPC9kaXY+DQo8ZGl2Pi0gZXhwbGFpbiBpbiB0 aGUgZGVzY3JpcHRpb24gdGhhdCAmcXVvdDtUaGlzIGxlYWYgc3BlY2lmaWVzIHRoZSBtYXhpbXVt IHh5eiBzaXplLiZuYnNwOyBUaGUgdW5pdHMgYXJlIG5vdCBzcGVjaWZpZWQgaW4gdGhpcyBtb2Rl bCBhbmQgdmFyaWVzIGJ5IGltcGxlbWVudGF0aW9uIChlLmcuIGJ5dGVzIHZzIG51bWJlciBvZiBs b2cgbWVzc2FnZXMpLiZxdW90OzwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L3NwYW4+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5bY2x5ZGVdIFBsZWFzZSBiZSBzcGVjaWZpYyBhYm91dCB0aGUgZGVm YXVsdCB2YWx1ZXMgdGhhdCB5b3UgZmVlbCBhcmUgaW5hcHByb3ByaWF0ZS4gT25lIG9mIHRoZSBZ QU5HIGRvY3RvciBmZWVkYmFjayBpdGVtcyB3YXMgdG8gaW5jbHVkZSBkZWZhdWx0cyBmb3IgY2xh cml0eS48L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+PGZvbnQgZmFjZT0i Q29uc29sYXMiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj5EKSB0ZXJtaW5hbCBkaXN0cmlidXRvciBhbmQgcGVyc2lz dGVuY3k8L2Rpdj4NCjxkaXY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08L2Rpdj4NCjxkaXY+VGVybWluYWwgbG9nZ2luZyBpcyBzZXNzaW9uLXNwZWNpZmlj IGluIHNldmVyYWwgaW1wbGVtZW50YXRpb25zIGFuZCBjb25maWcgZ2VuZXJhbGx5IGRpc2FwcGVh cnMgb25jZSB0aGUgc2Vzc2lvbiBpcyBkb25lLiZuYnNwOyBJdCBpcyBhbHNvIG5vdCBjbGVhciB3 aGF0IGxvZ2dpbmcgdG8gdGhlIGxvY2FsIHNlc3Npb24gc2hvdWxkIHJlYWxseSBtZWFuIGZvciBh IG5ldGNvbmYgc2Vzc2lvbi4mbmJzcDsgSSdtIG5vdCBzdXJlIHRoaXMgZGlzdHJpYnV0b3Igc2hv dWxkDQogYmUgaW4gdGhlIG1vZGVsLjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L3NwYW4+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5bY2x5ZGVdIFRlcm1pbmFsIGxvZ2dpbmcgaXMgaW1wbGVtZW50 ZWQgYnkgYWxsIG9mIHRoZSB2ZW5kb3JzIHdlIGV4YW1pbmVkLiBQbGVhc2UgZXhwbGFpbiB5b3Vy IGNvbmNlcm4gYWJvdXQgbG9nZ2luZyB0byB0aGUgTmV0Y29uZiBzZXNzaW9uIHRlcm1pbmFsLiBX b3VsZCBub3QgdGhpcyBiZSB0aGUgc2FtZSBmb3IgYW55IHRlcm1pbmFsIHRoYXQgcmVjZWl2ZWQg c3lzbG9nIG1lc3NhZ2VzIGFuZCB3YXMgYWxzbyB1c2VkIGZvciBvdGhlcg0KIHB1cnBvc2VzPzwv ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48Zm9udCBmYWNlPSJDb25zb2xh cyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPC9kaXY+DQo8ZGl2PkUpIGVkaXRvcmlhbC9taW5vciBtaXNjPC9kaXY+DQo8ZGl2Pi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2Pi0g U2hvdWxkIHdlIHVwZGF0ZSB0aGUgV0cgY2hhaXIgbmFtZSAoRGF2aWQgS2Vzc2VucykgPzwvZGl2 Pg0KPC9zcGFuPjwvZm9udD48L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bY2x5ZGVd IEFncmVlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPjxmb250IGZhY2U9IkNvbnNvbGFzIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDsiPg0KPGRpdj4tIEknZCBzdWdnZXN0ICdsaXN0IGxvZ2dpbmctZmFjaWxp dGllcycgYW5kICdrZXkgJnF1b3Q7ZmFjaWxpdHkmcXVvdDsnIGJlIGNoYW5nZWQgdG8gJ2xpc3Qg ZmFjaWxpdHknIHdpdGggJ2tleSAmcXVvdDtmYWNpbGl0eS1uYW1lJnF1b3Q7Jy4mbmJzcDsgSWYg YSBsaXN0IGlzIGluIGEgY29udGFpbmVyIHRoZW4gdGhlIHBsdXJhbCBuYW1lIG1ha2VzIHNlbnNl IGZvciB0aGUgY29udGFpbmVyIGJ1dCBJIHRoaW5rIHNpbmd1bGFyIGlzIGJldHRlciBmb3IgdGhl IGxpc3QgKGxpa2UgaG93DQogaWV0Zi1pbnRlcmZhY2VzIGlzIGRvbmUpLjwvZGl2Pg0KPC9zcGFu PjwvZm9udD48L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bY2x5ZGVdIEFncmVlZC48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pjxmb250IGZhY2U9IkNvbnNvbGFzIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDsiPg0KPGRpdj4tIFRoZSBpbnRyb2R1Y3Rpb24gc2F5cyAmcXVvdDtXZSBhcmUgdXNpbmcg ZGVmaW5pdGlvbnMgb2YgU3lzbG9nIHByb3RvY29sIGZyb20gW1JGQzMxNjRdIGluIHRoaXMgZHJh ZnQuJnF1b3Q7IGJ1dCB0aGUgWUFORyBtb2RlbCBtb3N0bHkgcmVmZXJlbmNlcyA1NDI0LjwvZGl2 Pg0KPC9zcGFuPjwvZm9udD48L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bY2x5ZGVd IFdlIHdpbGwgY2hhbmdlIHRoaXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+LSBJbiBzZWN0aW9uIDMgaW5zdGVh ZCBvZiAmcXVvdDtncm91cCBsZXZlbCZxdW90OyBwZXJoYXBzIGl0IGlzIGJldHRlciB0byB1c2Ug JnF1b3Q7Z2xvYmFsIGxldmVsJnF1b3Q7IChhbmQgaW4gdGhlIGZpZ3VyZSkgPyZuYnNwOyBJJ20g bm90IHN1cmUgd2hhdCBncm91cCBtZWFucyAod2hpY2ggZ3JvdXAgLSBpbXBsaWVzIGl0IGlzbid0 IG5lY2Vzc2FyaWx5IHRoZSBlbnRpcmUgbG9nIHN0cmVhbSkuPC9kaXY+DQo8L3NwYW4+PC9mb250 Pjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PltjbHlkZV0gR3JvdXAgbGV2ZWwgc3Vw cHJlc3Npb24gbm8gbG9uZ2VyIGFwcGxpZXMgb25jZSB0aGUgZ2xvYmFsLWxvZ2dpbmctYWN0aW9u IGlzIHJlbW92ZWQuIFdlIHdpbGwgcmVtb3ZlIGl0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+PGZvbnQgZmFjZT0iQ29uc29sYXMiIHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+DQo8ZGl2Pi0gTWF5YmUgdXNl IHRoZSB0ZXJtICZxdW90O1JlbW92ZSBDb2xsZWN0b3IocykmcXVvdDsgaW5zdGVhZCBvZiBTZXJ2 ZXIocykgPyBDb2xsZWN0b3Igc2VlbXMgbW9yZSBpbiBsaW5lIHdpdGggUkZDNTQyNCAob3IgJnF1 b3Q7UmVtb3RlIFJlY2VpdmVyJnF1b3Q7IGlmIG90aGVycyBwcmVmZXIgdGhhdCkuPC9kaXY+DQo8 L3NwYW4+PC9mb250Pjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PltjbHlkZV0gQWdy ZWVkLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+PGZvbnQgZmFjZT0iQ29uc29sYXMiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0OyI+DQo8ZGl2Pi0gSW4gdGhlIFNlY3Rpb24gMyBmaWd1cmUgbWFrZSBhbGwgdGhl IERpc3RyaWJ1dG9ycyBoYXZlIGEgY29tbW9uIHVzZSBvZiBwbHVyYWwgdnMgc2luZ3VsYXIgJnF1 b3Q7YnVmZmVyKHMpJnF1b3Q7LCAmcXVvdDtMb2cgRmlsZShzKSZxdW90OywgJnF1b3Q7UmVtb3Rl IENvbGxlY3RvcihzKSZxdW90Oy4mbmJzcDsmbmJzcDsgVXNlciBUZXJtaW5hbCBzaG91bGQgcHJv YmFibHkgYmUgc2luZ3VsYXIuPC9kaXY+DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PltjbHlkZV0gV2UgdHJpZWQgdG8gdXNlIG5hbWVzIHRoYXQgbWlycm9y IHRoZSBhY3R1YWwgdXNlIGNhc2VzOiBvbmUgY29uc29sZTsgb25lIGxvZyBidWZmZXI7IG9uZSBv ciBtb3JlIGxvZyBmaWxlczsgb25lIG9yIG1vcmUgdXNlciB0ZXJtaW5hbHM7IGFuZCBvbmUgb3Ig bW9yZSByZW1vdGUgc2VydmVycy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iPjxmb250IGZhY2U9IkNvbnNvbGFzIiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsiPg0KPGRpdj4tIERvY3VtZW50IGlzIG1pc3Npbmcg dGhlIHN0YW5kYXJkIGxlZ2VuZCBmb3IgdGhlIFBZQU5HIHRyZWU8L2Rpdj4NCjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W2NseWRlXSBXZSB3aWxsIGZpeCB0 aGlzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+Q2x5ZGU8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+PGZvbnQgZmFjZT0iQ29uc29sYXMiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0OyI+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRp dj5KYXNvbjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7 Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L3NwYW4+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_44D65B6078B34F3B93B1686551084FDFciscocom_-- From nobody Mon Apr 13 11:38:16 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAF01B2A63 for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5kK2S_yq6UX for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:38:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058E71B2A8F for <netmod@ietf.org>; Mon, 13 Apr 2015 11:38:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EBF8374B for <netmod@ietf.org>; Mon, 13 Apr 2015 20:38:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fPcNYhOaQIMr for <netmod@ietf.org>; Mon, 13 Apr 2015 20:38:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Mon, 13 Apr 2015 20:38:07 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F038520013 for <netmod@ietf.org>; Mon, 13 Apr 2015 20:38:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vH-gwCCjRbc8; Mon, 13 Apr 2015 20:38:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6257A2002B; Mon, 13 Apr 2015 20:38:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A62E532C06F7; Mon, 13 Apr 2015 20:38:04 +0200 (CEST) Date: Mon, 13 Apr 2015 20:38:04 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: netmod@ietf.org Message-ID: <20150413183804.GA15367@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150401144248.GB75145@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401144248.GB75145@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/SmGoNmon7DeV6SQYuQVCwZ_ywmY> Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 18:38:15 -0000 On Wed, Apr 01, 2015 at 04:42:48PM +0200, Juergen Schoenwaelder wrote: > Hi, > > following the discussions at IETF 92 and previous virtual interim > meetings and the mailing list, the proposal is to adopt Y34-05. Please > speak up by Friday 2015-04-10 if you disagree with this proposal. > Since there were no comments on the mailing list, I have moved this issue to EDIT. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Mon Apr 13 11:39:52 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74EF1B316F for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5ZLQp1jbslr for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:39:50 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1A31B2AAA for <netmod@ietf.org>; Mon, 13 Apr 2015 11:39:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C4A7A11EC for <netmod@ietf.org>; Mon, 13 Apr 2015 20:39:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5bCYr2D8_xVX for <netmod@ietf.org>; Mon, 13 Apr 2015 20:39:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Mon, 13 Apr 2015 20:39:26 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF4212002B for <netmod@ietf.org>; Mon, 13 Apr 2015 20:39:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Opfao7trbs2I; Mon, 13 Apr 2015 20:39:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D85320013; Mon, 13 Apr 2015 20:39:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C274D32C0723; Mon, 13 Apr 2015 20:39:23 +0200 (CEST) Date: Mon, 13 Apr 2015 20:39:23 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: netmod@ietf.org Message-ID: <20150413183923.GB15367@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150401144858.GC75145@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401144858.GC75145@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/pqqrTsSlbci2lbB4KcyZTyzAnj0> Subject: Re: [netmod] VRFY :Y26: allow mandatory nodes in augment X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 18:39:51 -0000 On Wed, Apr 01, 2015 at 04:48:58PM +0200, Juergen Schoenwaelder wrote: > Hi, > > the opinion after discussion of this issue at the IETF 92 meeting was > leaning towards adoption of Y26-02, hence the proposal is to adopt > Y26-02. Please speak up by Friday 2015-04-10 if you disagree with this > proposal. > Since there were no comments on the mailing list, I have moved this issue to EDIT. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Mon Apr 13 11:40:59 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644AD1AD0C6 for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKD34W6hkHec for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:40:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D2B1A0210 for <netmod@ietf.org>; Mon, 13 Apr 2015 11:40:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 31C26A45 for <netmod@ietf.org>; Mon, 13 Apr 2015 20:40:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tvVtHLjmRDsY for <netmod@ietf.org>; Mon, 13 Apr 2015 20:40:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Mon, 13 Apr 2015 20:40:52 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6C0A2002B for <netmod@ietf.org>; Mon, 13 Apr 2015 20:40:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8mdP-Wrdyq-Z; Mon, 13 Apr 2015 20:40:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BE4B20013; Mon, 13 Apr 2015 20:40:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8F94A32C074D; Mon, 13 Apr 2015 20:40:49 +0200 (CEST) Date: Mon, 13 Apr 2015 20:40:49 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: netmod@ietf.org Message-ID: <20150413184049.GC15367@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150401145334.GD75145@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401145334.GD75145@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/EYGZQmy7unO5_gurXNuxq0pDAnw> Subject: Re: [netmod] VRFY :Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 18:40:58 -0000 On Wed, Apr 01, 2015 at 04:53:34PM +0200, Juergen Schoenwaelder wrote: > Hi, > > this issue was discussed at the IETF 92 meeting and a small team met > to look at the encoding. This team made a very minor change of > solution Y36-03 and the proposal is now to adopt Y36-03. Please speak > up by Friday 2015-04-10 if you disagree with this proposal. Since there were no comments on the mailing list, I have moved this issue to EDIT. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Mon Apr 13 11:42:14 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464841AD26E for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfHNbqtJoDOf for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:42:06 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86451B2A37 for <netmod@ietf.org>; Mon, 13 Apr 2015 11:42:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C71F8F6C for <netmod@ietf.org>; Mon, 13 Apr 2015 20:41:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BLipUB23Wknh for <netmod@ietf.org>; Mon, 13 Apr 2015 20:41:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Mon, 13 Apr 2015 20:41:58 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E19C32002B for <netmod@ietf.org>; Mon, 13 Apr 2015 20:41:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id naob0bixzfdO; Mon, 13 Apr 2015 20:41:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9203420013; Mon, 13 Apr 2015 20:41:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E74B332C0779; Mon, 13 Apr 2015 20:41:56 +0200 (CEST) Date: Mon, 13 Apr 2015 20:41:56 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: netmod@ietf.org Message-ID: <20150413184156.GD15367@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150401145945.GE75145@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401145945.GE75145@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/kvRDcZoQaP3kIgd2vqGcVK-h0GE> Subject: Re: [netmod] VRFY :57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 18:42:13 -0000 On Wed, Apr 01, 2015 at 04:59:45PM +0200, Juergen Schoenwaelder wrote: > Hi, > > this issue was discussed at the IETF 92 meeting and several people > raised concerns that the solution causes significant changes (moving > towards identifying elements by position/value) and the value of doing > this is relatively small. See the meeting minutes for more details. > The proposal is now to move Y57 to DEAD. Please speak up by Friday > 2015-04-10 if you disagree with this proposal. Since there were no comments on the mailing list, I have moved this issue to DEAD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Mon Apr 13 11:44:59 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C5E1B2A3E for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqNOxyRzf6jm for <netmod@ietfa.amsl.com>; Mon, 13 Apr 2015 11:44:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F3B1AD26E for <netmod@ietf.org>; Mon, 13 Apr 2015 11:44:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6CA6B1263 for <netmod@ietf.org>; Mon, 13 Apr 2015 20:44:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OiN9uyaSZsdq for <netmod@ietf.org>; Mon, 13 Apr 2015 20:44:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Mon, 13 Apr 2015 20:44:52 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF90920035 for <netmod@ietf.org>; Mon, 13 Apr 2015 20:44:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tQjzkov3-kKc; Mon, 13 Apr 2015 20:44:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26D6620013; Mon, 13 Apr 2015 20:44:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7BAD232C07AA; Mon, 13 Apr 2015 20:44:50 +0200 (CEST) Date: Mon, 13 Apr 2015 20:44:50 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: netmod@ietf.org Message-ID: <20150413184450.GE15367@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150401144119.GA75145@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150401144119.GA75145@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/tfB9jdOafsvXwskctOV72vemqxQ> Subject: Re: [netmod] VRFY :12: initialized-by system X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Apr 2015 18:44:58 -0000 On Wed, Apr 01, 2015 at 04:41:19PM +0200, Juergen Schoenwaelder wrote: > Hi, > > Martin proposed to move this issue to DEAD instead of implementing > Y12-01 since it became clear that the proposed new statement only > covers part of the problem. Please speak up by Friday 2015-04-10 if > you disagree with this proposal. > Since there were no comments against moving this to DEAD on the mailing list, I have moved this issue to DEAD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Tue Apr 14 01:38:02 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD0C1B357A for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 01:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcQJF1fVSWBn for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 01:37:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 374D21B3577 for <netmod@ietf.org>; Tue, 14 Apr 2015 01:37:57 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 068FB1CC0474 for <netmod@ietf.org>; Tue, 14 Apr 2015 10:37:56 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: netmod@ietf.org User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 14 Apr 2015 10:37:54 +0200 Message-ID: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/qe31V0oeov6YWOCS2GDhtvD5TwU> Subject: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 08:38:00 -0000 Hi, I assume that, according to Y34-05, anydata node has to play the same role as a container. That is, if we have anydata foo; then "foo": { "bar": 42 } is allowed but "foo": 42 or "foo": [1, 2] is not. Is it correct? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 14 02:16:21 2015 Return-Path: <jernejt@mg-soft.si> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6AB1A1A91 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v64FTAM2TKC3 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:16:18 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF5C1A1A81 for <netmod@ietf.org>; Tue, 14 Apr 2015 02:16:18 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id BB85FC4175C1; Tue, 14 Apr 2015 11:16:16 +0200 (CEST) Message-ID: <552CDADE.8000203@mg-soft.si> Date: Tue, 14 Apr 2015 11:16:14 +0200 From: Jernej Tuljak <jernejt@mg-soft.si> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org References: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> In-Reply-To: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/4ElxcJGnuPtealW1nAfmduf4Rxk> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:16:20 -0000 This would be a silly requirement, IMO. Especially since with anyxml foo; <foo>character data</foo> or even <foo bar="val">character data</foo> are considered OK. Anydata should be able to play a role of a container or a leaf, same as anyxml. Jernej Dne 14.4.2015 ob 10:37 je Ladislav Lhotka zapisal(a): > Hi, > > I assume that, according to Y34-05, anydata node has to play the same > role as a container. That is, if we have > > anydata foo; > > then > > "foo": { > "bar": 42 > } > > is allowed but > > "foo": 42 > > or > > "foo": [1, 2] > > is not. > > Is it correct? > > Thanks, Lada > From nobody Tue Apr 14 02:25:20 2015 Return-Path: <bclaise@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640691A1B5C for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-8vZ3TtJ0NL for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:25:18 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12241A1B6D for <netmod@ietf.org>; Tue, 14 Apr 2015 02:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2264; q=dns/txt; s=iport; t=1429003517; x=1430213117; h=message-id:date:from:mime-version:to:subject; bh=k2YCUjBa3ZWYn4V8y8f/CH4iEW01KPIYztL7q27d0/A=; b=azy78A24BljBtgggI8AQGQsZwRcJBEbhv8Kvq9lgDmnVAuAjzkOwl7CP CZk+LZFHLgeOHlF573JzRo5qXlIopeuSAj0lQs/jAG+xhrMO9CjBx5pBJ sIGtJdBRMocHMnnqz96+Sa4YyCpzj8YoJKRYh7RdVzbieBO5Xn6TvoEB4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D4AwBJ3CxV/xbLJq1ch0/CPAmHSgOCARQBAQEBAQEBfYRJVSABHBYLAgsDAgECAUsNCAEBiCamV49VlhQBAQgBAQEBHpMWgUUFmx+BHYM3gkSNVCKDcTyCdAEBAQ X-IronPort-AV: E=Sophos;i="5.11,575,1422921600"; d="scan'208,217";a="430898385" 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; 14 Apr 2015 09:25:16 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3E9PFwv019948 for <netmod@ietf.org>; Tue, 14 Apr 2015 09:25:16 GMT Message-ID: <552CDD2A.4060809@cisco.com> Date: Tue, 14 Apr 2015 11:26:02 +0200 From: Benoit Claise <bclaise@cisco.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: NETMOD Working Group <netmod@ietf.org> Content-Type: multipart/alternative; boundary="------------040601090501020502000606" Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/GYc3JlQg-MR4PaR2V5gPTvXnohA> Subject: [netmod] Looking for a new NETMOD co-chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:25:19 -0000 This is a multi-part message in MIME format. --------------040601090501020502000606 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, As you can see from the NETMOD meeting minutes: * AOB (YANG Language and Infrastructure) JS announces that he plans to step down as NETMOD co-chair when the YANG 1.1 work has been finished. People interested to become NETMOD co-chair should contact BC. Where JS = Juergen Schoenwaelder and BC = Benoit Claise First of all, let me thank Juergen for his exceptional work during all these years. In his always professional attitude, Juergen committed to stay until the YANG 1.1 work is completed. This gives us some freedom for his transition. For example, we can plan the transition in a few months, or add a third chair now. If you would be interested in becoming the NETMOD co-chair, please let me know. Regards, Benoit --------------040601090501020502000606 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Dear all,<br> <br> As you can see from the NETMOD meeting minutes:<br> <blockquote>* AOB (YANG Language and Infrastructure)<br> <br>   JS announces that he plans to step down as NETMOD co-chair when the<br>   YANG 1.1 work has been finished. People interested to become NETMOD<br>   co-chair should contact BC.<br> </blockquote> Where JS = Juergen Schoenwaelder and BC = Benoit Claise<br> <br> First of all, let me thank Juergen for his exceptional work during all these years.<br> In his always professional attitude, Juergen committed to stay until the YANG 1.1 work is completed.<br> This gives us some freedom for his transition. For example, we can plan the transition in a few months, or add a third chair now.<br> <br> If you would be interested in becoming the NETMOD co-chair, please let me know.<br> <br> Regards, Benoit<br> </body> </html> --------------040601090501020502000606-- From nobody Tue Apr 14 02:28:40 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB811A7003 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiKx07z5jnCS for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:28:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27831A87AB for <netmod@ietf.org>; Tue, 14 Apr 2015 02:26:42 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 25F6F13F9DD; Tue, 14 Apr 2015 11:26:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429003601; bh=6pXVIgybpXzEh1FSCOaz4hrUUtjYeT/teEL0eFE6FhI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=JkZxDakf+BgeTKKWxwMYhZPAsoRvBmnb8jnLfM+TPgkR8eNvoYa0GDwOnfjAtM7sA aHN2vCHr2L0cT7u1yRFwpPMWoAuE8uu15wQSbEGZCSk5B1C2dDwa3XT5bA3Vl66PFZ AS3GeUOcrbQuT0l6s9NlGUsrwEL7WG/kUGN8lqV4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <552CDADE.8000203@mg-soft.si> Date: Tue, 14 Apr 2015 11:26:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73C6278F-2C0B-40C1-BA40-F3BDD5ECB760@nic.cz> References: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> <552CDADE.8000203@mg-soft.si> To: Jernej Tuljak <jernejt@mg-soft.si> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/52jZUgMwQsRV3ge9P3hjViUyOOU> Cc: netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:28:39 -0000 > On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> wrote: >=20 > This would be a silly requirement, IMO. Especially since with >=20 > anyxml foo; >=20 > <foo>character data</foo> >=20 > or even >=20 > <foo bar=3D"val">character data</foo> >=20 > are considered OK. >=20 > Anydata should be able to play a role of a container or a leaf, same = as anyxml. But then for XML encoding there would essentially be no difference = between anyxml and any data, right? Lada >=20 > Jernej >=20 > Dne 14.4.2015 ob 10:37 je Ladislav Lhotka zapisal(a): >> Hi, >>=20 >> I assume that, according to Y34-05, anydata node has to play the same >> role as a container. That is, if we have >>=20 >> anydata foo; >>=20 >> then >>=20 >> "foo": { >> "bar": 42 >> } >>=20 >> is allowed but >>=20 >> "foo": 42 >>=20 >> or >>=20 >> "foo": [1, 2] >>=20 >> is not. >>=20 >> Is it correct? >>=20 >> Thanks, Lada >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 14 02:33:44 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56861A3B9D for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWFcKNYSRAtd for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:33:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB621A1B76 for <netmod@ietf.org>; Tue, 14 Apr 2015 02:31:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EF8EAFD7; Tue, 14 Apr 2015 11:31:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yL1RQpjYISTM; Tue, 14 Apr 2015 11:31:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 14 Apr 2015 11:31:28 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1D662002C; Tue, 14 Apr 2015 11:31:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7-2RkrPmNBLe; Tue, 14 Apr 2015 11:31:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5740D20013; Tue, 14 Apr 2015 11:31:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A19F332C1032; Tue, 14 Apr 2015 11:31:25 +0200 (CEST) Date: Tue, 14 Apr 2015 11:31:25 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150414093125.GB17083@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org References: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> <552CDADE.8000203@mg-soft.si> <73C6278F-2C0B-40C1-BA40-F3BDD5ECB760@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73C6278F-2C0B-40C1-BA40-F3BDD5ECB760@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/jihDL4z7778CkMIMy8nx6-65mtw> Cc: Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:33:42 -0000 On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: > > > On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> wrote: > > > > This would be a silly requirement, IMO. Especially since with > > > > anyxml foo; > > > > <foo>character data</foo> > > > > or even > > > > <foo bar="val">character data</foo> > > > > are considered OK. > > > > Anydata should be able to play a role of a container or a leaf, same as anyxml. > > But then for XML encoding there would essentially be no difference between anyxml and any data, right? > For the XML encoding, anydata is a true subset of anyxml. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Tue Apr 14 02:34:57 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9841A1EED for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9NMUM0HcAiG for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:34:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CD71A7004 for <netmod@ietf.org>; Tue, 14 Apr 2015 02:33:52 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:6df9:a437:3e35:7014] (unknown [IPv6:2001:718:1a02:1:6df9:a437:3e35:7014]) by mail.nic.cz (Postfix) with ESMTPSA id 3282013F64F; Tue, 14 Apr 2015 11:33:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429004031; bh=kTfNhGQHtPOIRa4CkyyuFkb3iTHz6LMEAlKUoU7jd7o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WHM/s6zoj5mfj5rrXw+SLWMjeHS5+JESUaJP8TDxe35A2Pg3NTevZpaUO640JxopZ jUOAtx5lbFY+zEaytzeJ5AdaXj/Qs5QsCiYvA/ZBR9jXvysCYxhamXAbsXZj5UKFQI aKikVUJL4+jEtZMDtCkGkpu19iWqxIQAP3Nv52iQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150414093125.GB17083@elstar.local> Date: Tue, 14 Apr 2015 11:33:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> References: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> <552CDADE.8000203@mg-soft.si> <73C6278F-2C0B-40C1-BA40-F3BDD5ECB760@nic.cz> <20150414093125.GB17083@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/yjeJ5V6J122fZzkqV6gDQYqqCBk> Cc: Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:34:55 -0000 > On 14 Apr 2015, at 11:31, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >=20 > On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: >>=20 >>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> wrote: >>>=20 >>> This would be a silly requirement, IMO. Especially since with >>>=20 >>> anyxml foo; >>>=20 >>> <foo>character data</foo> >>>=20 >>> or even >>>=20 >>> <foo bar=3D"val">character data</foo> >>>=20 >>> are considered OK. >>>=20 >>> Anydata should be able to play a role of a container or a leaf, same = as anyxml. >>=20 >> But then for XML encoding there would essentially be no difference = between anyxml and any data, right? >>=20 >=20 > For the XML encoding, anydata is a true subset of anyxml. So what=E2=80=99s your answer to my question? Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 14 02:36:56 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9591A1B8A for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LWI5y0-zeMN for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:36:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAABA1A1B6C for <netmod@ietf.org>; Tue, 14 Apr 2015 02:36:53 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:6df9:a437:3e35:7014] (unknown [IPv6:2001:718:1a02:1:6df9:a437:3e35:7014]) by mail.nic.cz (Postfix) with ESMTPSA id 7DC5113F64F; Tue, 14 Apr 2015 11:36:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429004212; bh=5Pe+Re9KBUsiFu7/p2zW6n0KBUdMNLn8JwYtKypwwL0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AIgDZmgAE2QtXpEA94SP6DSajMWfQPBVgvJNzAwit+pJqi/kSTkvDAiM+fq04ana+ IomhzJ/h7pffeQ89aaAR8Atxrsgb4UdWW3HA1s1DyA7UbEpX4On39hgIo1PiPxu9vM 315zcDdb+B+Fgi9/56dqlnm/UWBKTtgUJQN81iy0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> Date: Tue, 14 Apr 2015 11:36:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> References: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> <552CDADE.8000203@mg-soft.si> <73C6278F-2C0B-40C1-BA40-F3BDD5ECB760@nic.cz> <20150414093125.GB17083@elstar.local> <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/oQLcnFi1dtSyHQ0dQvo_mNfN2pk> Cc: Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:36:55 -0000 > On 14 Apr 2015, at 11:33, Ladislav Lhotka <lhotka@nic.cz> wrote: >=20 >>=20 >> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>=20 >> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: >>>=20 >>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> wrote: >>>>=20 >>>> This would be a silly requirement, IMO. Especially since with >>>>=20 >>>> anyxml foo; >>>>=20 >>>> <foo>character data</foo> >>>>=20 >>>> or even >>>>=20 >>>> <foo bar=3D"val">character data</foo> >>>>=20 >>>> are considered OK. >>>>=20 >>>> Anydata should be able to play a role of a container or a leaf, = same as anyxml. >>>=20 >>> But then for XML encoding there would essentially be no difference = between anyxml and any data, right? >>>=20 >>=20 >> For the XML encoding, anydata is a true subset of anyxml. >=20 >=20 > So what=E2=80=99s your answer to my question? To be specific, will the following be allowed for =E2=80=9Canydata = foo=E2=80=9D in XML encoding? <foo>42</foo> Lada >=20 > Lada >=20 >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 14 02:39:00 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD651A1BBB for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrDyGlLmKDyX for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:38:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CF21A6F32 for <netmod@ietf.org>; Tue, 14 Apr 2015 02:38:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 12C7D9E4; Tue, 14 Apr 2015 11:38:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id p2RbB9__ob2L; Tue, 14 Apr 2015 11:38:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 14 Apr 2015 11:38:48 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D41DE2002C; Tue, 14 Apr 2015 11:38:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6cHA152otevT; Tue, 14 Apr 2015 11:38:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D75220013; Tue, 14 Apr 2015 11:38:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 694B932C10A5; Tue, 14 Apr 2015 11:38:45 +0200 (CEST) Date: Tue, 14 Apr 2015 11:38:45 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150414093845.GA17183@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org References: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> <552CDADE.8000203@mg-soft.si> <73C6278F-2C0B-40C1-BA40-F3BDD5ECB760@nic.cz> <20150414093125.GB17083@elstar.local> <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> 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: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/MMvTfgbT4_0J2MTSLLdWpicIJ2U> Cc: Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:38:58 -0000 On Tue, Apr 14, 2015 at 11:33:51AM +0200, Ladislav Lhotka wrote: > > > On 14 Apr 2015, at 11:31, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > > > On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: > >> > >>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> wrote: > >>> > >>> This would be a silly requirement, IMO. Especially since with > >>> > >>> anyxml foo; > >>> > >>> <foo>character data</foo> > >>> > >>> or even > >>> > >>> <foo bar="val">character data</foo> > >>> > >>> are considered OK. > >>> > >>> Anydata should be able to play a role of a container or a leaf, same as anyxml. > >> > >> But then for XML encoding there would essentially be no difference between anyxml and any data, right? > >> > > > > For the XML encoding, anydata is a true subset of anyxml. > > So what’s your answer to my question? > The answer was "for the XML encoding, anydata is a true subset of anyxml". Or in other words, it is not correct to say "there would essentially be no difference between anyxml and any data" since anyxml allows things like processing instructions, mixed content, etc. that anydata does not allow. But if you look at only the subset that anydata allows, then your statements becomes correct (perhaps this was implicit in your statement - hard to tell). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Tue Apr 14 02:43:03 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B371A1BCB for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B64Pr-JevUon for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:42:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C24D1A1B87 for <netmod@ietf.org>; Tue, 14 Apr 2015 02:42:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 25A14FB1; Tue, 14 Apr 2015 11:41:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id iZlhJf8XR6o6; Tue, 14 Apr 2015 11:41:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 14 Apr 2015 11:41:57 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 611E520013; Tue, 14 Apr 2015 11:41:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Yq2hp8OmpZQg; Tue, 14 Apr 2015 11:41:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9491F20031; Tue, 14 Apr 2015 11:41:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E06B232C10D9; Tue, 14 Apr 2015 11:41:54 +0200 (CEST) Date: Tue, 14 Apr 2015 11:41:54 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150414094154.GB17183@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org References: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> <552CDADE.8000203@mg-soft.si> <73C6278F-2C0B-40C1-BA40-F3BDD5ECB760@nic.cz> <20150414093125.GB17083@elstar.local> <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> 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: <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/8dhaQTBHlbPP27Vt3tZkQpvT7EA> Cc: Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:43:02 -0000 On Tue, Apr 14, 2015 at 11:36:52AM +0200, Ladislav Lhotka wrote: > > > On 14 Apr 2015, at 11:33, Ladislav Lhotka <lhotka@nic.cz> wrote: > > > >> > >> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > >> > >> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: > >>> > >>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> wrote: > >>>> > >>>> This would be a silly requirement, IMO. Especially since with > >>>> > >>>> anyxml foo; > >>>> > >>>> <foo>character data</foo> > >>>> > >>>> or even > >>>> > >>>> <foo bar="val">character data</foo> > >>>> > >>>> are considered OK. > >>>> > >>>> Anydata should be able to play a role of a container or a leaf, same as anyxml. > >>> > >>> But then for XML encoding there would essentially be no difference between anyxml and any data, right? > >>> > >> > >> For the XML encoding, anydata is a true subset of anyxml. > > > > > > So what’s your answer to my question? > > To be specific, will the following be allowed for “anydata foo” in XML encoding? > > <foo>42</foo> > Well, I have not seen the edits yet, but unless there are strong reasons to not allow this, why should it not be legal to have a leaf there? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Tue Apr 14 02:54:58 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B121D1A702B for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDKB9WPgmHnd for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 02:54:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F6C1A701E for <netmod@ietf.org>; Tue, 14 Apr 2015 02:54:55 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:6df9:a437:3e35:7014] (unknown [IPv6:2001:718:1a02:1:6df9:a437:3e35:7014]) by mail.nic.cz (Postfix) with ESMTPSA id 1808313F64F; Tue, 14 Apr 2015 11:54:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429005294; bh=QYP9Yw3pn28n5i4GFfWm9+Ka3RLL1FoR1ga5W96CGDw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QvCMG8ubZKyvQkY+gak1V+O9cQ3MQA+/Q8XIlxPEicyS5VB2EgHpVMkce6q0VLWnG By4r/x6SZUPfD8qGSyRsMuK3/FyPYGXvnl/8+CnK026vXa5KujMU52gzlXRDz66ges h79+vP8ZK+2der9A+iEp/DtPjFVv6fEx1TYjvnUQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150414093845.GA17183@elstar.local> Date: Tue, 14 Apr 2015 11:54:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <94B451E4-F02B-4C8A-B634-8B815A76F671@nic.cz> References: <m2vbgzxfz1.fsf@birdie.labs.nic.cz> <552CDADE.8000203@mg-soft.si> <73C6278F-2C0B-40C1-BA40-F3BDD5ECB760@nic.cz> <20150414093125.GB17083@elstar.local> <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <20150414093845.GA17183@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/W7OwWaPiM_-zn8j5CvikIpLDfIA> Cc: Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 09:54:56 -0000 > On 14 Apr 2015, at 11:38, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >=20 > On Tue, Apr 14, 2015 at 11:33:51AM +0200, Ladislav Lhotka wrote: >>=20 >>> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>=20 >>> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> = wrote: >>>>>=20 >>>>> This would be a silly requirement, IMO. Especially since with >>>>>=20 >>>>> anyxml foo; >>>>>=20 >>>>> <foo>character data</foo> >>>>>=20 >>>>> or even >>>>>=20 >>>>> <foo bar=3D"val">character data</foo> >>>>>=20 >>>>> are considered OK. >>>>>=20 >>>>> Anydata should be able to play a role of a container or a leaf, = same as anyxml. >>>>=20 >>>> But then for XML encoding there would essentially be no difference = between anyxml and any data, right? >>>>=20 >>>=20 >>> For the XML encoding, anydata is a true subset of anyxml. >>=20 >> So what=E2=80=99s your answer to my question? >>=20 >=20 > The answer was "for the XML encoding, anydata is a true subset of > anyxml". Or in other words, it is not correct to say "there would > essentially be no difference between anyxml and any data" since anyxml > allows things like processing instructions, mixed content, etc. that Does RFC 6020 prevent processing instructions (or XML comments, for that = matter) from appearing *anywhere* in an XML instance document? I believe = it is not so. > anydata does not allow. But if you look at only the subset that > anydata allows, then your statements becomes correct (perhaps this > was implicit in your statement - hard to tell). Then I am questioning the meaning of =E2=80=9Cunknown chunk of data that = can be modeled with YANG=E2=80=9D. An isolated number like 42 cannot be = modeled with YANG (or show me a module that does it). Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 14 03:01:17 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121841A8738 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 03:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy2BxMIn0pHI for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 03:01:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 341791A872D for <netmod@ietf.org>; Tue, 14 Apr 2015 03:01:10 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9354C1AE0471; Tue, 14 Apr 2015 12:01:08 +0200 (CEST) Date: Tue, 14 Apr 2015 12:01:08 +0200 (CEST) Message-Id: <20150414.120108.2000386990242822687.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150414094154.GB17183@elstar.local> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/atP3_q0p7X9JhhFkEfp7GeERVGE> Cc: jernejt@mg-soft.si, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 10:01:14 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBPbiBUdWUsIEFwciAxNCwgMjAxNSBhdCAxMTozNjo1MkFNICswMjAwLCBM YWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4gDQo+ID4gPiBPbiAxNCBBcHIgMjAxNSwgYXQgMTE6 MzMsIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4gPiANCj4gPiA+ PiANCj4gPiA+PiBPbiAxNCBBcHIgMjAxNSwgYXQgMTE6MzEsIEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPiA+PiAN Cj4gPiA+PiBPbiBUdWUsIEFwciAxNCwgMjAxNSBhdCAxMToyNjo0MUFNICswMjAwLCBMYWRpc2xh diBMaG90a2Egd3JvdGU6DQo+ID4gPj4+IA0KPiA+ID4+Pj4gT24gMTQgQXByIDIwMTUsIGF0IDEx OjE2LCBKZXJuZWogVHVsamFrIDxqZXJuZWp0QG1nLXNvZnQuc2k+IHdyb3RlOg0KPiA+ID4+Pj4g DQo+ID4gPj4+PiBUaGlzIHdvdWxkIGJlIGEgc2lsbHkgcmVxdWlyZW1lbnQsIElNTy4gRXNwZWNp YWxseSBzaW5jZSB3aXRoDQo+ID4gPj4+PiANCj4gPiA+Pj4+IGFueXhtbCBmb287DQo+ID4gPj4+ PiANCj4gPiA+Pj4+IDxmb28+Y2hhcmFjdGVyIGRhdGE8L2Zvbz4NCj4gPiA+Pj4+IA0KPiA+ID4+ Pj4gb3IgZXZlbg0KPiA+ID4+Pj4gDQo+ID4gPj4+PiA8Zm9vIGJhcj0idmFsIj5jaGFyYWN0ZXIg ZGF0YTwvZm9vPg0KPiA+ID4+Pj4gDQo+ID4gPj4+PiBhcmUgY29uc2lkZXJlZCBPSy4NCj4gPiA+ Pj4+IA0KPiA+ID4+Pj4gQW55ZGF0YSBzaG91bGQgYmUgYWJsZSB0byBwbGF5IGEgcm9sZSBvZiBh IGNvbnRhaW5lciBvciBhIGxlYWYsIHNhbWUgYXMgYW55eG1sLg0KPiA+ID4+PiANCj4gPiA+Pj4g QnV0IHRoZW4gZm9yIFhNTCBlbmNvZGluZyB0aGVyZSB3b3VsZCBlc3NlbnRpYWxseSBiZSBubyBk aWZmZXJlbmNlIGJldHdlZW4gYW55eG1sIGFuZCBhbnkgZGF0YSwgcmlnaHQ/DQo+ID4gPj4+IA0K PiA+ID4+IA0KPiA+ID4+IEZvciB0aGUgWE1MIGVuY29kaW5nLCBhbnlkYXRhIGlzIGEgdHJ1ZSBz dWJzZXQgb2YgYW55eG1sLg0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IFNvIHdoYXTigJlzIHlvdXIg YW5zd2VyIHRvIG15IHF1ZXN0aW9uPw0KPiA+IA0KPiA+IFRvIGJlIHNwZWNpZmljLCB3aWxsIHRo ZSBmb2xsb3dpbmcgYmUgYWxsb3dlZCBmb3Ig4oCcYW55ZGF0YSBmb2/igJ0gaW4gWE1MIGVuY29k aW5nPw0KPiA+IA0KPiA+IDxmb28+NDI8L2Zvbz4NCj4gPg0KPiANCj4gV2VsbCwgSSBoYXZlIG5v dCBzZWVuIHRoZSBlZGl0cyB5ZXQsIGJ1dCB1bmxlc3MgdGhlcmUgYXJlIHN0cm9uZw0KPiByZWFz b25zIHRvIG5vdCBhbGxvdyB0aGlzLCB3aHkgc2hvdWxkIGl0IG5vdCBiZSBsZWdhbCB0byBoYXZl IGEgbGVhZg0KPiB0aGVyZT8NCg0KSSB3b3VsZCBzYXkgdGhhdCB0aGlzIGlzIG5vdCB2YWxpZC4g IE5vdGUgdGhhdCB0aGUgZGF0YSBtb2RlbCB3YXM6DQoNCiAgYW55ZGF0YSBmb287DQoNCkl0IHdv dWxkIGJlIGVuY29kZWQgYXMgYW4gWE1MIGVsZW1lbnQgImZvbyIgd2l0aCBzb21lIHVua25vd24g c2V0IG9mDQpub2RlcyBpbiBpdC4gIEp1c3QgbGlrZSBhbnl4bWwuDQoNCg0KDQoNCi9tYXJ0aW4N Cg== From nobody Tue Apr 14 04:40:39 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16D1A8A94 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 04:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPgs2ABq99S2 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 04:40:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9DB1A8A74 for <netmod@ietf.org>; Tue, 14 Apr 2015 04:40:12 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 540D313FB92; Tue, 14 Apr 2015 13:40:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429011610; bh=2j453vzJbMCSMQvzurzsyxd/zlXE1ujG7PnjjYZuhec=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Hp59liLU+ljY9w4Z4lN3oPdAiptJFEa0P+TQL5mIkvU/1XsoiXtNOAaa/MiisOL14 f23/qEO7gH95uWj6IsTcfLRuJKRY9RYNQ72Ov98MDgjsKGoJ3IL8CpYZXB3c2YahSj OnLLx7iQfXli5aw4kxpDc7iqtYwAng/5+R0t7Nn0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150414.120108.2000386990242822687.mbj@tail-f.com> Date: Tue, 14 Apr 2015 13:40:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj@tail-f.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9iLyxfd2dl4Zwmp_yfNCIz-3ho0> Cc: Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 11:40:38 -0000 > On 14 Apr 2015, at 12:01, Martin Bjorklund <mbj@tail-f.com> wrote: >=20 > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >> On Tue, Apr 14, 2015 at 11:36:52AM +0200, Ladislav Lhotka wrote: >>>=20 >>>> On 14 Apr 2015, at 11:33, Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>=20 >>>>>=20 >>>>> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>>=20 >>>>> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> = wrote: >>>>>>>=20 >>>>>>> This would be a silly requirement, IMO. Especially since with >>>>>>>=20 >>>>>>> anyxml foo; >>>>>>>=20 >>>>>>> <foo>character data</foo> >>>>>>>=20 >>>>>>> or even >>>>>>>=20 >>>>>>> <foo bar=3D"val">character data</foo> >>>>>>>=20 >>>>>>> are considered OK. >>>>>>>=20 >>>>>>> Anydata should be able to play a role of a container or a leaf, = same as anyxml. >>>>>>=20 >>>>>> But then for XML encoding there would essentially be no = difference between anyxml and any data, right? >>>>>>=20 >>>>>=20 >>>>> For the XML encoding, anydata is a true subset of anyxml. >>>>=20 >>>>=20 >>>> So what=E2=80=99s your answer to my question? >>>=20 >>> To be specific, will the following be allowed for =E2=80=9Canydata = foo=E2=80=9D in XML encoding? >>>=20 >>> <foo>42</foo> >>>=20 >>=20 >> Well, I have not seen the edits yet, but unless there are strong >> reasons to not allow this, why should it not be legal to have a leaf >> there? >=20 > I would say that this is not valid. Note that the data model was: >=20 > anydata foo; >=20 > It would be encoded as an XML element "foo" with some unknown set of > nodes in it. Just like anyxml. Just to clarify: if we have anydata foo; anyxml bar; then <foo>42</foo> isn't allowed but <bar>42</bar> is. Correct? Lada =20 >=20 >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 14 07:56:49 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A658F1ACE00 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 07:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_zYC6cSmH39 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 07:56:45 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DB11ACE22 for <netmod@ietf.org>; Tue, 14 Apr 2015 07:56:45 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so10731600lbc.1 for <netmod@ietf.org>; Tue, 14 Apr 2015 07:56:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ThWOWIpNerYe8/Cxlg/lKtp5/FfIzI1bFXdeMGsGZKA=; b=jmtu3H1bMD0Z41Xvv6ul7/1BoyDkUsBvMAViEGJD9IWYV/aXbHCkeUAJ4dFKPFU1GE Gedcc5P/V3qo5FUOqc0jX9STRolfbX2N73+IaEyaiukDHPArQ/AinveTELV0UsGrJD87 rGX4LwEpKmSgA03gByRXea9KnOCjGxrfMupRoM3fDm7EXZbGJjgN0J86SJsz3XeOZJs5 QNv9Cw8C/fCE3HqkY01PGLgxAFKz/taxXB72JjaaYXRlWh/0N3xzjWnwr6Ox3uBOuvWM NNDwSJN9+pEFvBEZaymtfybsYZO3MM0Js66KQdaNgVP7SPFesdfRsyv23nDu1CB0BjYR Zj6w== X-Gm-Message-State: ALoCoQmIcWy1gJH9BIseRf1R01byBWIvtka0rpsdsdRTMMHeWEK/MKr8yh44jkZKI396RhUJS5oS MIME-Version: 1.0 X-Received: by 10.112.51.138 with SMTP id k10mr19188959lbo.82.1429023403807; Tue, 14 Apr 2015 07:56:43 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 14 Apr 2015 07:56:43 -0700 (PDT) In-Reply-To: <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> Date: Tue, 14 Apr 2015 07:56:43 -0700 Message-ID: <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/beyD7iwUezsnfqkTzZNkZhpL_60> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 14:56:47 -0000 On Tue, Apr 14, 2015 at 4:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > >> On 14 Apr 2015, at 12:01, Martin Bjorklund <mbj@tail-f.com> wrote: >> >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>> On Tue, Apr 14, 2015 at 11:36:52AM +0200, Ladislav Lhotka wrote: >>>> >>>>> On 14 Apr 2015, at 11:33, Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>> >>>>>> >>>>>> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder <j.schoenwaelder@jac= obs-university.de> wrote: >>>>>> >>>>>> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: >>>>>>> >>>>>>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> wrote= : >>>>>>>> >>>>>>>> This would be a silly requirement, IMO. Especially since with >>>>>>>> >>>>>>>> anyxml foo; >>>>>>>> >>>>>>>> <foo>character data</foo> >>>>>>>> >>>>>>>> or even >>>>>>>> >>>>>>>> <foo bar=3D"val">character data</foo> >>>>>>>> >>>>>>>> are considered OK. >>>>>>>> >>>>>>>> Anydata should be able to play a role of a container or a leaf, sa= me as anyxml. >>>>>>> >>>>>>> But then for XML encoding there would essentially be no difference = between anyxml and any data, right? >>>>>>> >>>>>> >>>>>> For the XML encoding, anydata is a true subset of anyxml. >>>>> >>>>> >>>>> So what=E2=80=99s your answer to my question? >>>> >>>> To be specific, will the following be allowed for =E2=80=9Canydata foo= =E2=80=9D in XML encoding? >>>> >>>> <foo>42</foo> >>>> >>> >>> Well, I have not seen the edits yet, but unless there are strong >>> reasons to not allow this, why should it not be legal to have a leaf >>> there? >> >> I would say that this is not valid. Note that the data model was: >> >> anydata foo; >> >> It would be encoded as an XML element "foo" with some unknown set of >> nodes in it. Just like anyxml. > > Just to clarify: if we have > > anydata foo; > anyxml bar; > > then <foo>42</foo> isn't allowed but <bar>42</bar> is. Correct? > No -- anydata can be a leaf or a container. > Lada Andy > > >> >> >> >> >> /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Apr 14 08:21:39 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB911B2CF7 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVg_OBS07IB3 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 08:21:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D191B2D66 for <netmod@ietf.org>; Tue, 14 Apr 2015 08:18:03 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:f582:e6be:1fd9:be04] (unknown [IPv6:2a01:5e0:29:ffff:f582:e6be:1fd9:be04]) by mail.nic.cz (Postfix) with ESMTPSA id A036513F6EF; Tue, 14 Apr 2015 17:18:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429024681; bh=pXSfDdHKMByRZ4SyUQW5tQGj4lmKKZL+E17GMTp2Lrg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZH/4knAMgj/vt7aWGVUqgVXB09kSvTyB/zLmfVSCyZvFMiIyFBdFoQ2T3We9a0eue gvD3DOSgRw8oKUmL4e/suxtOiVMxS/J8FvUATYDHGjApA2eaAeQ+0DA+U6CTMitoQf YqMraMacKWjTJnQpK27ggwP2mwLc6n6eEuoSrpt8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> Date: Tue, 14 Apr 2015 17:18:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> To: Andy Bierman <andy@yumaworks.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/-6zOLhzhP_xWcCpAEs3noiNyEsY> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 15:21:37 -0000 > On 14 Apr 2015, at 16:56, Andy Bierman <andy@yumaworks.com> wrote: >=20 > On Tue, Apr 14, 2015 at 4:40 AM, Ladislav Lhotka <lhotka@nic.cz> = wrote: >>=20 >>> On 14 Apr 2015, at 12:01, Martin Bjorklund <mbj@tail-f.com> wrote: >>>=20 >>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>> On Tue, Apr 14, 2015 at 11:36:52AM +0200, Ladislav Lhotka wrote: >>>>>=20 >>>>>> On 14 Apr 2015, at 11:33, Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>=20 >>>>>>> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> = wrote: >>>>>>>>>=20 >>>>>>>>> This would be a silly requirement, IMO. Especially since with >>>>>>>>>=20 >>>>>>>>> anyxml foo; >>>>>>>>>=20 >>>>>>>>> <foo>character data</foo> >>>>>>>>>=20 >>>>>>>>> or even >>>>>>>>>=20 >>>>>>>>> <foo bar=3D"val">character data</foo> >>>>>>>>>=20 >>>>>>>>> are considered OK. >>>>>>>>>=20 >>>>>>>>> Anydata should be able to play a role of a container or a = leaf, same as anyxml. >>>>>>>>=20 >>>>>>>> But then for XML encoding there would essentially be no = difference between anyxml and any data, right? >>>>>>>>=20 >>>>>>>=20 >>>>>>> For the XML encoding, anydata is a true subset of anyxml. >>>>>>=20 >>>>>>=20 >>>>>> So what=E2=80=99s your answer to my question? >>>>>=20 >>>>> To be specific, will the following be allowed for =E2=80=9Canydata = foo=E2=80=9D in XML encoding? >>>>>=20 >>>>> <foo>42</foo> >>>>>=20 >>>>=20 >>>> Well, I have not seen the edits yet, but unless there are strong >>>> reasons to not allow this, why should it not be legal to have a = leaf >>>> there? >>>=20 >>> I would say that this is not valid. Note that the data model was: >>>=20 >>> anydata foo; >>>=20 >>> It would be encoded as an XML element "foo" with some unknown set of >>> nodes in it. Just like anyxml. >>=20 >> Just to clarify: if we have >>=20 >> anydata foo; >> anyxml bar; >>=20 >> then <foo>42</foo> isn't allowed but <bar>42</bar> is. Correct? >>=20 >=20 > No -- anydata can be a leaf or a container. Then here doesn=E2=80=99t seem to be consensus about what anydata is = supposed to mean. Lada >=20 >> Lada >=20 > Andy >=20 >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 14 09:08:20 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7524A1B2D7F for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 09:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTD4DwQ8gk0E for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 09:08:15 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 E02971B2E30 for <netmod@ietf.org>; Tue, 14 Apr 2015 09:05:48 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so12471789lbb.2 for <netmod@ietf.org>; Tue, 14 Apr 2015 09:05:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Gd96mfb4S410KkdQwIXz/fFxkeNLelTPMEi0mH12w58=; b=NCjh6LgX7a9eMadirKwWZQdb9IeOnzYP1SjSu3um+1f4CwdmfoVs3prtsAZMfsJN4l afkBT6nDeaMFTieVRFSS90Ni+qhlvFBfRK17tl2+8wrlQUiQyxDRJ4MPPKEM9WOldycv CfSGtojIlWGwRi00UP4rEV6ojtGmR48dGGykVwxNg65J7g/dvMiCUeCMRnGlNfUHZEPl 9CRlEBbvD3ptgoKJnxZbPyVO+jZbGCV10HpjK5NDMXtlgIui8OJFdBX/T8TirNVhS/+y 3/DHUvdWHMQmSfYPo3IakV+g+dtFLOPvv9Tm/XeNNZPSAQWpEfqluHA3mHyNsze+3Ih6 OZvA== X-Gm-Message-State: ALoCoQm/6+EmHhBJYb2E/mYQA4c/1UAQUKt17eIuifQ63HXTdvr1aIBqDK652y0F6EX+56YZHOk1 MIME-Version: 1.0 X-Received: by 10.112.139.130 with SMTP id qy2mr13294716lbb.33.1429027547383; Tue, 14 Apr 2015 09:05:47 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 14 Apr 2015 09:05:47 -0700 (PDT) In-Reply-To: <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> Date: Tue, 14 Apr 2015 09:05:47 -0700 Message-ID: <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/vuPvxxtK31A3PdLtX1pRKrCRP9g> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 16:08:19 -0000 On Tue, Apr 14, 2015 at 8:18 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > >> On 14 Apr 2015, at 16:56, Andy Bierman <andy@yumaworks.com> wrote: >> >> On Tue, Apr 14, 2015 at 4:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: >>> >>>> On 14 Apr 2015, at 12:01, Martin Bjorklund <mbj@tail-f.com> wrote: >>>> >>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>> On Tue, Apr 14, 2015 at 11:36:52AM +0200, Ladislav Lhotka wrote: >>>>>> >>>>>>> On 14 Apr 2015, at 11:33, Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder <j.schoenwaelder@j= acobs-university.de> wrote: >>>>>>>> >>>>>>>> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: >>>>>>>>> >>>>>>>>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> wro= te: >>>>>>>>>> >>>>>>>>>> This would be a silly requirement, IMO. Especially since with >>>>>>>>>> >>>>>>>>>> anyxml foo; >>>>>>>>>> >>>>>>>>>> <foo>character data</foo> >>>>>>>>>> >>>>>>>>>> or even >>>>>>>>>> >>>>>>>>>> <foo bar=3D"val">character data</foo> >>>>>>>>>> >>>>>>>>>> are considered OK. >>>>>>>>>> >>>>>>>>>> Anydata should be able to play a role of a container or a leaf, = same as anyxml. >>>>>>>>> >>>>>>>>> But then for XML encoding there would essentially be no differenc= e between anyxml and any data, right? >>>>>>>>> >>>>>>>> >>>>>>>> For the XML encoding, anydata is a true subset of anyxml. >>>>>>> >>>>>>> >>>>>>> So what=E2=80=99s your answer to my question? >>>>>> >>>>>> To be specific, will the following be allowed for =E2=80=9Canydata f= oo=E2=80=9D in XML encoding? >>>>>> >>>>>> <foo>42</foo> >>>>>> >>>>> >>>>> Well, I have not seen the edits yet, but unless there are strong >>>>> reasons to not allow this, why should it not be legal to have a leaf >>>>> there? >>>> >>>> I would say that this is not valid. Note that the data model was: >>>> >>>> anydata foo; >>>> >>>> It would be encoded as an XML element "foo" with some unknown set of >>>> nodes in it. Just like anyxml. >>> >>> Just to clarify: if we have >>> >>> anydata foo; >>> anyxml bar; >>> >>> then <foo>42</foo> isn't allowed but <bar>42</bar> is. Correct? >>> >> >> No -- anydata can be a leaf or a container. > > Then here doesn=E2=80=99t seem to be consensus about what anydata is supp= osed to mean. > I think there is consensus, but you don't agree with it. Why do you think anydata must be a container? anydata is just a tree of data nodes. The derivative case is a tree consisting of 1 leaf. It doesn't really help much to worry about the correct schema to use for a blob that has no schema. It doesn't matter if 1 implementation thinks nodes are leafs and another thinks they are leaf-lists. There is no schema, so nobody is right (or wrong) about the proper YANG data nodes to use. Don't expect any interoperability out of anydata. The only difference from anyxml is that mixed mode XML and processing instructions are not allowed. Andy > Lada > > >> >>> Lada >> >> Andy >> >>> >>> >>>> >>>> >>>> >>>> >>>> /martin >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Tue Apr 14 09:42:27 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5951B2E96 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 09:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0KztQSTN_s1 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 09:42:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DEE1B2E91 for <netmod@ietf.org>; Tue, 14 Apr 2015 09:42:21 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:dd61:9523:a657:fd36] (unknown [IPv6:2a01:5e0:29:ffff:dd61:9523:a657:fd36]) by mail.nic.cz (Postfix) with ESMTPSA id 359AF13F9DD; Tue, 14 Apr 2015 18:42:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429029739; bh=G6RLnk9ljETx+xSHNTdhV/iYgm/RIqVb8Xx41jJFVNA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ts6ia5vjpmqGSTQKySUMbm/hejUDmxaOrs7EYGSpgAIMbv0w1m1McO7Pw1YCGwZvH q1sN0pvfrL5AebeGGneMFJMq7Gxb7+zOc/0ZGJ0HqdrqQD2+JNIlzKBk5ag4lVraT5 863cFnYRHh60ihVd6qlCP6rySJdAadIGpf368n+E= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> Date: Tue, 14 Apr 2015 18:42:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> To: Andy Bierman <andy@yumaworks.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/rkO5fMB0EOLWTOof_AytaoR-GTA> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 16:42:24 -0000 > On 14 Apr 2015, at 18:05, Andy Bierman <andy@yumaworks.com> wrote: >=20 > On Tue, Apr 14, 2015 at 8:18 AM, Ladislav Lhotka <lhotka@nic.cz> = wrote: >>=20 >>> On 14 Apr 2015, at 16:56, Andy Bierman <andy@yumaworks.com> wrote: >>>=20 >>> On Tue, Apr 14, 2015 at 4:40 AM, Ladislav Lhotka <lhotka@nic.cz> = wrote: >>>>=20 >>>>> On 14 Apr 2015, at 12:01, Martin Bjorklund <mbj@tail-f.com> wrote: >>>>>=20 >>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote: >>>>>> On Tue, Apr 14, 2015 at 11:36:52AM +0200, Ladislav Lhotka wrote: >>>>>>>=20 >>>>>>>> On 14 Apr 2015, at 11:33, Ladislav Lhotka <lhotka@nic.cz> = wrote: >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>=20 >>>>>>>>> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka = wrote: >>>>>>>>>>=20 >>>>>>>>>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> This would be a silly requirement, IMO. Especially since = with >>>>>>>>>>>=20 >>>>>>>>>>> anyxml foo; >>>>>>>>>>>=20 >>>>>>>>>>> <foo>character data</foo> >>>>>>>>>>>=20 >>>>>>>>>>> or even >>>>>>>>>>>=20 >>>>>>>>>>> <foo bar=3D"val">character data</foo> >>>>>>>>>>>=20 >>>>>>>>>>> are considered OK. >>>>>>>>>>>=20 >>>>>>>>>>> Anydata should be able to play a role of a container or a = leaf, same as anyxml. >>>>>>>>>>=20 >>>>>>>>>> But then for XML encoding there would essentially be no = difference between anyxml and any data, right? >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> For the XML encoding, anydata is a true subset of anyxml. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> So what=E2=80=99s your answer to my question? >>>>>>>=20 >>>>>>> To be specific, will the following be allowed for =E2=80=9Canydata= foo=E2=80=9D in XML encoding? >>>>>>>=20 >>>>>>> <foo>42</foo> >>>>>>>=20 >>>>>>=20 >>>>>> Well, I have not seen the edits yet, but unless there are strong >>>>>> reasons to not allow this, why should it not be legal to have a = leaf >>>>>> there? >>>>>=20 >>>>> I would say that this is not valid. Note that the data model was: >>>>>=20 >>>>> anydata foo; >>>>>=20 >>>>> It would be encoded as an XML element "foo" with some unknown set = of >>>>> nodes in it. Just like anyxml. >>>>=20 >>>> Just to clarify: if we have >>>>=20 >>>> anydata foo; >>>> anyxml bar; >>>>=20 >>>> then <foo>42</foo> isn't allowed but <bar>42</bar> is. Correct? >>>>=20 >>>=20 >>> No -- anydata can be a leaf or a container. >>=20 >> Then here doesn=E2=80=99t seem to be consensus about what anydata is = supposed to mean. >>=20 >=20 > I think there is consensus, but you don't agree with it. Martin also said <foo>42</foo> is not valid for =E2=80=9Canydata foo=E2=80= =9D. =20 > Why do you think anydata must be a container? Because I thought that it was the *content* of an anydata instance that = needs to be (potentially) modellable with YANG. So you are essentially saying that anydata =3D=3D anyxml minus mixed = content, but this IMO doesn=E2=80=99t warrant introducing a new type of = data node. Lada >=20 > anydata is just a tree of data nodes. The derivative case is > a tree consisting of 1 leaf. It doesn't really help much to worry = about > the correct schema to use for a blob that has no schema. > It doesn't matter if 1 implementation thinks nodes are leafs > and another thinks they are leaf-lists. There is no schema, > so nobody is right (or wrong) about the proper YANG data nodes > to use. >=20 >=20 > Don't expect any interoperability out of anydata. > The only difference from anyxml is that mixed mode XML > and processing instructions are not allowed. >=20 >=20 > Andy >=20 >> Lada >>=20 >>=20 >>>=20 >>>> Lada >>>=20 >>> Andy >>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> /martin >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Apr 14 13:29:58 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6FC1B2A43 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 13:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuImsp31bDl7 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 13:29:55 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 0ECF31B2A47 for <netmod@ietf.org>; Tue, 14 Apr 2015 13:29:55 -0700 (PDT) Received: by laat2 with SMTP id t2so17568702laa.1 for <netmod@ietf.org>; Tue, 14 Apr 2015 13:29:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Zx28vCWsODogW7AV8vVNrCmWapzssChXeAJUceJNa4Y=; b=S4fQWSH4i0eQzv3Uu95whQcePwI9UFuehPncJx+VnZRLpbYR6+e+5V+btiQhq+DK+r R5LPtT8X1Pr/EkZTVDTQp8hsr5wvjgsFWcS9vfFwwEn5X5zGzQn0uCkWLfcoCdNnAWa0 1QjELPGFXuO/ialCCkJDLww7mgPhOIDvQiz5eTc1UeXpaqYMWrje/gqlFY4jDZNOHTtR KHjIe7IBiN8tt4thj7MaMz/LFEsLvjy054QOEd53Ubd4IRK6m+7+Sq2vTcP1dXHhZX1J VYCn5Uai0fTy43wn3SAZRGG9dE8k8EzwQivtSfoqe9rjiErxd1zZAFgrd8X2/oipSlfu vUTw== X-Gm-Message-State: ALoCoQnXThYAu5tIq/dJCcmnZv6lzcnXHaNeohjQtK0yWgCQKrgNx90sNH9WJkRVg81xmx9nZMev MIME-Version: 1.0 X-Received: by 10.152.87.46 with SMTP id u14mr20492388laz.82.1429043393585; Tue, 14 Apr 2015 13:29:53 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 14 Apr 2015 13:29:53 -0700 (PDT) In-Reply-To: <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> Date: Tue, 14 Apr 2015 13:29:53 -0700 Message-ID: <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Ep1pQTfoPrhA0h0ynBCZ2xyVcWQ> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 20:29:57 -0000 On Tue, Apr 14, 2015 at 9:42 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > >> On 14 Apr 2015, at 18:05, Andy Bierman <andy@yumaworks.com> wrote: >> >> On Tue, Apr 14, 2015 at 8:18 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: >>> >>>> On 14 Apr 2015, at 16:56, Andy Bierman <andy@yumaworks.com> wrote: >>>> >>>> On Tue, Apr 14, 2015 at 4:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote= : >>>>> >>>>>> On 14 Apr 2015, at 12:01, Martin Bjorklund <mbj@tail-f.com> wrote: >>>>>> >>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>> On Tue, Apr 14, 2015 at 11:36:52AM +0200, Ladislav Lhotka wrote: >>>>>>>> >>>>>>>>> On 14 Apr 2015, at 11:33, Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14 Apr 2015, at 11:31, Juergen Schoenwaelder <j.schoenwaelder= @jacobs-university.de> wrote: >>>>>>>>>> >>>>>>>>>> On Tue, Apr 14, 2015 at 11:26:41AM +0200, Ladislav Lhotka wrote: >>>>>>>>>>> >>>>>>>>>>>> On 14 Apr 2015, at 11:16, Jernej Tuljak <jernejt@mg-soft.si> w= rote: >>>>>>>>>>>> >>>>>>>>>>>> This would be a silly requirement, IMO. Especially since with >>>>>>>>>>>> >>>>>>>>>>>> anyxml foo; >>>>>>>>>>>> >>>>>>>>>>>> <foo>character data</foo> >>>>>>>>>>>> >>>>>>>>>>>> or even >>>>>>>>>>>> >>>>>>>>>>>> <foo bar=3D"val">character data</foo> >>>>>>>>>>>> >>>>>>>>>>>> are considered OK. >>>>>>>>>>>> >>>>>>>>>>>> Anydata should be able to play a role of a container or a leaf= , same as anyxml. >>>>>>>>>>> >>>>>>>>>>> But then for XML encoding there would essentially be no differe= nce between anyxml and any data, right? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> For the XML encoding, anydata is a true subset of anyxml. >>>>>>>>> >>>>>>>>> >>>>>>>>> So what=E2=80=99s your answer to my question? >>>>>>>> >>>>>>>> To be specific, will the following be allowed for =E2=80=9Canydata= foo=E2=80=9D in XML encoding? >>>>>>>> >>>>>>>> <foo>42</foo> >>>>>>>> >>>>>>> >>>>>>> Well, I have not seen the edits yet, but unless there are strong >>>>>>> reasons to not allow this, why should it not be legal to have a lea= f >>>>>>> there? >>>>>> >>>>>> I would say that this is not valid. Note that the data model was: >>>>>> >>>>>> anydata foo; >>>>>> >>>>>> It would be encoded as an XML element "foo" with some unknown set of >>>>>> nodes in it. Just like anyxml. >>>>> >>>>> Just to clarify: if we have >>>>> >>>>> anydata foo; >>>>> anyxml bar; >>>>> >>>>> then <foo>42</foo> isn't allowed but <bar>42</bar> is. Correct? >>>>> >>>> >>>> No -- anydata can be a leaf or a container. >>> >>> Then here doesn=E2=80=99t seem to be consensus about what anydata is su= pposed to mean. >>> >> >> I think there is consensus, but you don't agree with it. > > Martin also said <foo>42</foo> is not valid for =E2=80=9Canydata foo=E2= =80=9D. > >> Why do you think anydata must be a container? > > Because I thought that it was the *content* of an anydata instance that n= eeds to be (potentially) modellable with YANG. > I suppose the data model should indicate whether a leaf makes sense for the specific object. > So you are essentially saying that anydata =3D=3D anyxml minus mixed cont= ent, but this IMO doesn=E2=80=99t warrant introducing a new type of data no= de. I don't think anydata is warranted at all, because nobody actually implements anyxml as it is defined. Some people who don't even implement YANG insist everybody else should support anyxml with mixed mode. Now we will bloat the standard and double-down on anyxml -- not only MUST everybody implement it, but we MUST implement 2 versions of it. I am curious why anydata would be wonderful if only it was restricted to be a container instead of a container or a leaf. It seems just as lame and misguided to me with or without this restriction. > > Lada Andy > >> >> anydata is just a tree of data nodes. The derivative case is >> a tree consisting of 1 leaf. It doesn't really help much to worry about >> the correct schema to use for a blob that has no schema. >> It doesn't matter if 1 implementation thinks nodes are leafs >> and another thinks they are leaf-lists. There is no schema, >> so nobody is right (or wrong) about the proper YANG data nodes >> to use. >> >> >> Don't expect any interoperability out of anydata. >> The only difference from anyxml is that mixed mode XML >> and processing instructions are not allowed. >> >> >> Andy >> >>> Lada >>> >>> >>>> >>>>> Lada >>>> >>>> Andy >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> /martin >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Tue Apr 14 14:21:14 2015 Return-Path: <kwatsen@juniper.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994861A1F16 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKpEn0KiJEx9 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 14:21:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0441B3085 for <netmod@ietf.org>; Tue, 14 Apr 2015 14:17:06 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 14 Apr 2015 21:17:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.233]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.233]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 21:17:05 +0000 From: Kent Watsen <kwatsen@juniper.net> To: Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz> Thread-Topic: [netmod] anydata Thread-Index: AQHQdo5X3TmlvoZOyEaBHYld7YMdHp1MOjIAgAAC7ICAAAFSgIAAAK6AgAAA2ACAAAFoAIAABWAAgAAbqoCAADbsgIAABfIAgAANWoCAAAozAIAAP5aA///KIoA= Date: Tue, 14 Apr 2015 21:17:04 +0000 Message-ID: <D152F710.9FBBE%kwatsen@juniper.net> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> In-Reply-To: <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: <CO1PR05MB458614275F36C54A6F6EBE2A5E60@CO1PR05MB458.namprd05.prod.outlook.com> x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(50986999)(54356999)(19580395003)(36756003)(76176999)(106116001)(66066001)(102836002)(87936001)(2656002)(62966003)(77156002)(4001350100001)(4001410100001)(99286002)(15395725005)(93886004)(92566002)(2900100001)(15975445007)(122556002)(83506001)(46102003)(2950100001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 054642504A Content-Type: text/plain; charset="us-ascii" Content-ID: <5C32B5A29DEECB44B517935AF8CCE56E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 21:17:04.9429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/gpEyH4wHcLfy3pMJNJCs6E1rqtc> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 21:21:11 -0000 >>> Why do you think anydata must be a container? >> >> Because I thought that it was the *content* of an anydata instance that >>needs to be (potentially) modellable with YANG. Y34-05 says: Introduce a new 'anydata' statement that represents an unknown chunk of data that can be modeled with YANG. So let's say I have private YANG module foo: module foo { namespace "http://example.com/foo"; leaf bar { type string; } } Now let's say there is a some other YANG module inet-widgets: module inet-widgets { namespace "urn:ietf:params:xml:ns:yang:ietf-widgets"; anydata opaque-data ; } Then the XML would be: <opaque-data xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-widgets"> <bar xmlns=3D"http://example.com/foo">42</bar> </opaque-data> Or in JSON: { "inet-widgets:opaque-data" : { "foo:bar" : 42 } } Correct? Thanks, Kent From nobody Tue Apr 14 14:34:37 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E81A1BB9 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 14:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hznb6k2zhAFW for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 14:34:32 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 C2E551A1B57 for <netmod@ietf.org>; Tue, 14 Apr 2015 14:34:23 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so19409028lbb.3 for <netmod@ietf.org>; Tue, 14 Apr 2015 14:34:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g01zK5xq4UArK1oT9eF1mJfwPuWf6v08ZkVqOpfUacU=; b=Nb+eueaPI2c5GY/cOOm8xPTkAymkWoIMncN1xcFF96VBZLX5/e2ZrEmAiR14vJg3JE EvW8NlwNJ/m9GdG33gcs08ybWFDRN3cIulkKHQFYSk9yxXa+kfu+nyGBqrjeUUPLg5n8 mfUP+LgzZcneinEKBq+YoG7Nn1gqSDcBWrjr77t8ylJHSTJvonZI06Nud11f22x4byS3 ZHVo3fF/4KvfTsZ7Mx9RrwE2uxKVYKGqsbtLToN8OPFTfw9sJyBKFY88gaBAewqXXCyK MRd1khXxUhoBsaFcvTlXEWzNoX+49Y6Qi/s7Ze9nRunpj9hPaqRWHK/xijO14zCt8ob2 7rlg== X-Gm-Message-State: ALoCoQntuC4A6WvrrQijFd/dd9j7aXs16BO9t8lvMtN3Ne236OuxPDts8nHCvLdPFIS87oCIyFUn MIME-Version: 1.0 X-Received: by 10.152.37.40 with SMTP id v8mr20971626laj.123.1429047262330; Tue, 14 Apr 2015 14:34:22 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 14 Apr 2015 14:34:22 -0700 (PDT) In-Reply-To: <D152F710.9FBBE%kwatsen@juniper.net> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> <D152F710.9FBBE%kwatsen@juniper.net> Date: Tue, 14 Apr 2015 14:34:22 -0700 Message-ID: <CABCOCHRp5eS7EYyFOrv1JxH3txP=f3P3RyrV9TodEz=TCdtbBQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Kent Watsen <kwatsen@juniper.net> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/f7gjDwigFMvbtAOGHNh2OFSKkV8> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Apr 2015 21:34:34 -0000 On Tue, Apr 14, 2015 at 2:17 PM, Kent Watsen <kwatsen@juniper.net> wrote: > >>>> Why do you think anydata must be a container? >>> >>> Because I thought that it was the *content* of an anydata instance that >>>needs to be (potentially) modellable with YANG. > > > Y34-05 says: > > Introduce a new 'anydata' statement that represents an > unknown chunk of data that can be modeled with YANG. > > > So let's say I have private YANG module foo: > > module foo { > namespace "http://example.com/foo"; > leaf bar { > type string; > } > } > > Now let's say there is a some other YANG module inet-widgets: > > module inet-widgets { > namespace "urn:ietf:params:xml:ns:yang:ietf-widgets"; > anydata opaque-data ; > } > > Then the XML would be: > > <opaque-data xmlns="urn:ietf:params:xml:ns:yang:ietf-widgets"> > <bar xmlns="http://example.com/foo">42</bar> > </opaque-data> > > Or in JSON: > > { > "inet-widgets:opaque-data" : { > "foo:bar" : 42 > } > } > > > Correct? correct for this data model. Note that the client knows nothing about 'opaque-data' so it has no reason to expect a container or a leaf. An empty leaf and an empty container can look the same in XML But it us not hard for the server to check that anydata can only be a container. I don't have any strong use-cases for allowing anydata to be a leaf. Nor do I have reason for forbidding it from being a leaf. Maybe it is easier to understand your way. anydata == container of arbitrary YANG data nodes anyxml == mixed mode XML (we will pretend every server MUST support this, yet zero so far do that) > > Thanks, > Kent > Andy From nobody Tue Apr 14 23:21:02 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9726B1B2DB8 for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 23:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_BACKHAIR_34=1, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um2w-OVmpFjB for <netmod@ietfa.amsl.com>; Tue, 14 Apr 2015 23:20:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146B91B2D87 for <netmod@ietf.org>; Tue, 14 Apr 2015 23:20:58 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:fce5:2058:fa00:32d4] (unknown [IPv6:2001:718:1a02:1:fce5:2058:fa00:32d4]) by mail.nic.cz (Postfix) with ESMTPSA id 795EE13F962; Wed, 15 Apr 2015 08:20:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429078856; bh=Irxki4A9Ot/Q8Li5rTgS7SAs+/tITNsNkTig4/Fw964=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=a3dnpjtgQB6FjTNBlXwz843o8OURD7Lu23fSwsUTKZ9ONbx9RZ1gglRuYV4+O545z fsmKkbxokUVpBvRvsc6XbZOkaVHOU8onir3Mi4Rg28u5ArTHSDFQ+YgIAv4Jk+DWXs vH2NnsKZyw//qfvcebtNDCUo/B42lFQGTfabffNI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <D152F710.9FBBE%kwatsen@juniper.net> Date: Wed, 15 Apr 2015 08:20:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <197BCF9C-48B3-4293-94F7-16E95D12D985@nic.cz> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> <D152F710.9FBBE%kwatsen@juniper.net> To: Kent Watsen <kwatsen@juniper.net> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9li37oVbmokyL0Z3oNj5d798SWs> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2015 06:20:59 -0000 > On 14 Apr 2015, at 23:17, Kent Watsen <kwatsen@juniper.net> wrote: >=20 >=20 >>>> Why do you think anydata must be a container? >>>=20 >>> Because I thought that it was the *content* of an anydata instance = that >>> needs to be (potentially) modellable with YANG. >=20 >=20 > Y34-05 says: >=20 > Introduce a new 'anydata' statement that represents an > unknown chunk of data that can be modeled with YANG. >=20 >=20 > So let's say I have private YANG module foo: >=20 > module foo { > namespace "http://example.com/foo"; > leaf bar { > type string; > } > } >=20 > Now let's say there is a some other YANG module inet-widgets: >=20 > module inet-widgets { > namespace "urn:ietf:params:xml:ns:yang:ietf-widgets"; > anydata opaque-data ; > } >=20 > Then the XML would be: >=20 > <opaque-data xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-widgets"> > <bar xmlns=3D"http://example.com/foo">42</bar> > </opaque-data> >=20 > Or in JSON: >=20 > { > "inet-widgets:opaque-data" : { > "foo:bar" : 42 > } > } >=20 >=20 > Correct? Right, this is exactly how I understand the Y34-05 wording. With this = approach it is also easy to map XML<->JSON - otherwise we could have = problems with mapping things like "foo": [1, 2] which maps to <foo>1</foo> <foo>2</foo> (i.e. two anydata foo instances in XML). Lada >=20 > Thanks, > Kent >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 15 01:09:10 2015 Return-Path: <jernejt@mg-soft.si> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509361B32C5 for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 01:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_34=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftHD9jo3uLPw for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 01:09:06 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 788A31B32C4 for <netmod@ietf.org>; Wed, 15 Apr 2015 01:09:06 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 54341C4175C2; Wed, 15 Apr 2015 10:09:05 +0200 (CEST) Message-ID: <552E1C9F.90501@mg-soft.si> Date: Wed, 15 Apr 2015 10:09:03 +0200 From: Jernej Tuljak <jernejt@mg-soft.si> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ladislav Lhotka <lhotka@nic.cz>, Kent Watsen <kwatsen@juniper.net> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> <D152F710.9FBBE%kwatsen@juniper.net> <197BCF9C-48B3-4293-94F7-16E95D12D985@nic.cz> In-Reply-To: <197BCF9C-48B3-4293-94F7-16E95D12D985@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/bKm8plEzcnnWdo22agwW9dUvNVY> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2015 08:09:08 -0000 Dne 15.4.2015 ob 8:20 je Ladislav Lhotka zapisal(a): >> On 14 Apr 2015, at 23:17, Kent Watsen <kwatsen@juniper.net> wrote: >> >> >>>>> Why do you think anydata must be a container? >>>> Because I thought that it was the *content* of an anydata instance that >>>> needs to be (potentially) modellable with YANG. >> >> Y34-05 says: >> >> Introduce a new 'anydata' statement that represents an >> unknown chunk of data that can be modeled with YANG. >> >> >> So let's say I have private YANG module foo: >> >> module foo { >> namespace "http://example.com/foo"; >> leaf bar { >> type string; >> } >> } >> >> Now let's say there is a some other YANG module inet-widgets: >> >> module inet-widgets { >> namespace "urn:ietf:params:xml:ns:yang:ietf-widgets"; >> anydata opaque-data ; >> } >> >> Then the XML would be: >> >> <opaque-data xmlns="urn:ietf:params:xml:ns:yang:ietf-widgets"> >> <bar xmlns="http://example.com/foo">42</bar> >> </opaque-data> >> >> Or in JSON: >> >> { >> "inet-widgets:opaque-data" : { >> "foo:bar" : 42 >> } >> } >> >> >> Correct? > Right, this is exactly how I understand the Y34-05 wording. With this approach it is also easy to map XML<->JSON - otherwise we could have problems with mapping things like > > "foo": [1, 2] > > which maps to > > <foo>1</foo> > <foo>2</foo> > > (i.e. two anydata foo instances in XML). A container or a leaf (!). The same as anyxml. If anydata _content_ has a requirement that it must be modeled using YANG, then I agree with your original example. The anydata node must be a container. I don't agree this is the right way to do it however. How would one model output of an RPC such as <get-schema> in ietf-netconf-monitoring using anydata for the XML encoding? The payload may contain character data where anydata now seems to require instances of YANG data nodes. "foo": "character data" <foo>character data</foo> should be legal. One could even argue that both of these "represent an unknown chunk of data that can be modeled with YANG", therefore anydata may represent them. Jernej > > Lada > > >> Thanks, >> Kent >> > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > From nobody Wed Apr 15 01:11:18 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DBA1B32C9 for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 01:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.939 X-Spam-Level: ** X-Spam-Status: No, score=2.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_210=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-2v1e6qON5S for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 01:11:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C75C1B328B for <netmod@ietf.org>; Wed, 15 Apr 2015 01:11:14 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:fce5:2058:fa00:32d4] (unknown [IPv6:2001:718:1a02:1:fce5:2058:fa00:32d4]) by mail.nic.cz (Postfix) with ESMTPSA id 392F913F9DD for <netmod@ietf.org>; Wed, 15 Apr 2015 10:11:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429085473; bh=oNghwyxbfPlOfsML20wV5pqYlbN4nEz84pHC5L1r7O4=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=DdNXgkt82tP/8TM3WPWduEwFkNM6JkxYZQh7OzIqaCjX3FCYQvzyJ7RKGmlq40S8E VvtiuaT7lRuORe0QTh41cDy07UnjrdIwtJ+c0t/EJRHIZiPum4cuJ5zP4kqlnnnold lj8208NqFgJlvk/iQX6R4YwMhY/k7iqWtxHcJ42o= From: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <AB52620F-7390-4B90-AB05-5607DC2865EB@nic.cz> Date: Wed, 15 Apr 2015 10:11:13 +0200 To: NETMOD Working Group <netmod@ietf.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Qw1dCGZ8lFW4HiU9x8rpJJPhCZY> Subject: [netmod] routing-cfg-18 schema X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2015 08:11:16 -0000 Hi, the editors of draft-ietf-netmod-routing-cfg implemented all changes to = the data model that were agreed upon in Dallas. The resulting schema of = the trees affected by the changes (interface, interface-state, routing = and routing-state) is shown below. Unless somebody has objections, we = will submit it in this form as revision -18 on Friday. Thanks, Acee and Lada =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D module: ietf-interfaces +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw description? string | +--rw type identityref | +--rw enabled? boolean | +--rw ip:ipv4! | | +--rw ip:enabled? boolean | | +--rw ip:forwarding? boolean | | +--rw ip:mtu? uint16 | | +--rw ip:address* [ip] | | | +--rw ip:ip inet:ipv4-address-no-zone | | | +--rw (subnet) | | | +--:(prefix-length) | | | +--rw ip:prefix-length? uint8 | | +--rw ip:neighbor* [ip] | | +--rw ip:ip inet:ipv4-address-no-zone | | +--rw ip:link-layer-address yang:phys-address | +--rw ip:ipv6! | +--rw ip:enabled? boolean | +--rw ip:forwarding? boolean | +--rw ip:mtu? uint32 | +--rw ip:address* [ip] | | +--rw ip:ip inet:ipv6-address-no-zone | | +--rw ip:prefix-length uint8 | +--rw ip:neighbor* [ip] | | +--rw ip:ip inet:ipv6-address-no-zone | | +--rw ip:link-layer-address yang:phys-address | +--rw ip:dup-addr-detect-transmits? uint32 | +--rw ip:autoconf | | +--rw ip:create-global-addresses? boolean | +--rw v6ur:ipv6-router-advertisements | +--rw v6ur:send-advertisements? boolean | +--rw v6ur:max-rtr-adv-interval? uint16 | +--rw v6ur:min-rtr-adv-interval? uint16 | +--rw v6ur:managed-flag? boolean | +--rw v6ur:other-config-flag? boolean | +--rw v6ur:link-mtu? uint32 | +--rw v6ur:reachable-time? uint32 | +--rw v6ur:retrans-timer? uint32 | +--rw v6ur:cur-hop-limit? uint8 | +--rw v6ur:default-lifetime? uint16 | +--rw v6ur:prefix-list | +--rw v6ur:prefix* [prefix-spec] | +--rw v6ur:prefix-spec inet:ipv6-prefix | +--rw (control-adv-prefixes)? | +--:(no-advertise) | | +--rw v6ur:no-advertise? empty | +--:(advertise) | +--rw v6ur:valid-lifetime? uint32 | +--rw v6ur:on-link-flag? boolean | +--rw v6ur:preferred-lifetime? uint32 | +--rw v6ur:autonomous-flag? boolean +--ro interfaces-state +--ro interface* [name] +--ro name string +--ro type identityref +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-state-ref +--ro lower-layer-if* interface-state-ref +--ro speed? yang:gauge64 +--ro statistics | +--ro discontinuity-time yang:date-and-time | +--ro in-octets? yang:counter64 | +--ro in-unicast-pkts? yang:counter64 | +--ro in-broadcast-pkts? yang:counter64 | +--ro in-multicast-pkts? yang:counter64 | +--ro in-discards? yang:counter32 | +--ro in-errors? yang:counter32 | +--ro in-unknown-protos? yang:counter32 | +--ro out-octets? yang:counter64 | +--ro out-unicast-pkts? yang:counter64 | +--ro out-broadcast-pkts? yang:counter64 | +--ro out-multicast-pkts? yang:counter64 | +--ro out-discards? yang:counter32 | +--ro out-errors? yang:counter32 +--ro ip:ipv4! | +--ro ip:forwarding? boolean | +--ro ip:mtu? uint16 | +--ro ip:address* [ip] | | +--ro ip:ip inet:ipv4-address-no-zone | | +--ro (subnet)? | | | +--:(prefix-length) | | | +--ro ip:prefix-length? uint8 | | +--ro ip:origin? ip-address-origin | +--ro ip:neighbor* [ip] | +--ro ip:ip inet:ipv4-address-no-zone | +--ro ip:link-layer-address? yang:phys-address | +--ro ip:origin? neighbor-origin +--ro ip:ipv6! | +--ro ip:forwarding? boolean | +--ro ip:mtu? uint32 | +--ro ip:address* [ip] | | +--ro ip:ip inet:ipv6-address-no-zone | | +--ro ip:prefix-length uint8 | | +--ro ip:origin? ip-address-origin | | +--ro ip:status? enumeration | +--ro ip:neighbor* [ip] | | +--ro ip:ip inet:ipv6-address-no-zone | | +--ro ip:link-layer-address? yang:phys-address | | +--ro ip:origin? neighbor-origin | | +--ro ip:is-router? empty | | +--ro ip:state? enumeration | +--ro v6ur:ipv6-router-advertisements | +--ro v6ur:send-advertisements? boolean | +--ro v6ur:max-rtr-adv-interval? uint16 | +--ro v6ur:min-rtr-adv-interval? uint16 | +--ro v6ur:managed-flag? boolean | +--ro v6ur:other-config-flag? boolean | +--ro v6ur:link-mtu? uint32 | +--ro v6ur:reachable-time? uint32 | +--ro v6ur:retrans-timer? uint32 | +--ro v6ur:cur-hop-limit? uint8 | +--ro v6ur:default-lifetime? uint16 | +--ro v6ur:prefix-list | +--ro v6ur:prefix* [prefix-spec] | +--ro v6ur:prefix-spec inet:ipv6-prefix | +--ro v6ur:valid-lifetime? uint32 | +--ro v6ur:on-link-flag? boolean | +--ro v6ur:preferred-lifetime? uint32 | +--ro v6ur:autonomous-flag? boolean +--ro rt:routing-instance? routing-instance-state-ref module: ietf-routing +--ro routing-state | +--ro routing-instance* [name] | +--ro name string | +--ro type? identityref | +--ro interfaces | | +--ro interface* if:interface-state-ref | +--ro routing-protocols | | +--ro routing-protocol* [type name] | | +--ro type identityref | | +--ro name string | | +--ro route-preference route-preference | +--ro ribs | +--ro rib* [name] | +--ro name string | +--ro address-family identityref | +--ro default-rib? boolean {multiple-ribs}? | +--ro routes | +--ro route* | +--ro route-preference? route-preference | +--ro next-hop | | +--ro (next-hop-options) | | +--:(simple-next-hop) | | | +--ro outgoing-interface? -> = /routing-state/routing-instance/interfaces/interface | | | +--ro v6ur:next-hop-address? = inet:ipv6-address | | | +--ro v4ur:next-hop-address? = inet:ipv4-address | | +--:(special-next-hop) | | +--ro special-next-hop? enumeration | +--ro source-protocol identityref | +--ro active? empty | +--ro last-updated? yang:date-and-time | +--ro v6ur:destination-prefix? inet:ipv6-prefix | +--ro v4ur:destination-prefix? inet:ipv4-prefix +--rw routing +--rw routing-instance* [name] +--rw name string +--rw type? identityref +--rw enabled? boolean +--rw router-id? yang:dotted-quad +--rw description? string +--rw interfaces | +--rw interface* if:interface-ref +--rw routing-protocols | +--rw routing-protocol* [type name] | +--rw type identityref | +--rw name string | +--rw description? string | +--rw enabled? boolean | +--rw route-preference? route-preference | +--rw static-routes | +--rw v6ur:ipv6 | | +--rw v6ur:route* [destination-prefix] | | +--rw v6ur:destination-prefix inet:ipv6-prefix | | +--rw v6ur:description? string | | +--rw v6ur:next-hop | | +--rw (next-hop-options) | | +--:(simple-next-hop) | | | +--rw v6ur:outgoing-interface? -> = /rt:routing/routing-instance/interfaces/interface | | +--:(special-next-hop) | | | +--rw v6ur:special-next-hop? = enumeration | | +--:(next-hop-address) | | +--rw v6ur:next-hop-address? = inet:ipv6-address | +--rw v4ur:ipv4 | +--rw v4ur:route* [destination-prefix] | +--rw v4ur:destination-prefix inet:ipv4-prefix | +--rw v4ur:description? string | +--rw v4ur:next-hop | +--rw (next-hop-options) | +--:(simple-next-hop) | | +--rw v4ur:outgoing-interface? -> = /rt:routing/routing-instance/interfaces/interface | +--:(special-next-hop) | | +--rw v4ur:special-next-hop? = enumeration | +--:(next-hop-address) | +--rw v4ur:next-hop-address? = inet:ipv4-address +--rw ribs +--rw rib* [name] +--rw name string +--rw address-family identityref +--rw description? string +--rw default-rib? boolean {multiple-ribs}? rpcs: +---x fib-route =20 +---w input =20 | +---w routing-instance-name routing-instance-state-ref | +---w destination-address | +---w address-family identityref | +---w v6ur:address? inet:ipv6-address | +---w v4ur:address? inet:ipv4-address +--ro output =20 +--ro route +--ro address-family identityref +--ro next-hop | +--ro (next-hop-options) | +--:(simple-next-hop) | | +--ro outgoing-interface? -> = /routing-state/routing-instance/interfaces/interface | | +--ro v6ur:next-hop-address? inet:ipv6-address | | +--ro v4ur:next-hop-address? inet:ipv4-address | +--:(special-next-hop) | +--ro special-next-hop? enumeration +--ro source-protocol identityref +--ro active? empty +--ro last-updated? yang:date-and-time +--ro v6ur:destination-prefix? inet:ipv6-prefix +--ro v4ur:destination-prefix? inet:ipv4-prefix -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 15 02:26:16 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6E01B33C6 for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_BACKHAIR_34=1, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjysxwouMCVQ for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 02:26:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197C91A1B2D for <netmod@ietf.org>; Wed, 15 Apr 2015 02:26:11 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:fce5:2058:fa00:32d4] (unknown [IPv6:2001:718:1a02:1:fce5:2058:fa00:32d4]) by mail.nic.cz (Postfix) with ESMTPSA id B9D1013F9DD; Wed, 15 Apr 2015 11:26:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429089969; bh=7hzlehwVjyZttaVEkimP4YULVoCkJQoTf+qWM1LHhg0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NSt510V8AwQEzoFLoyTtAs9rD3sMklOxgGLIgNG53vjagfbzZEjkdFEnRv1HZNxIw cTmD0+LruU9ib9Bbn6qE0tVSNqamYw32NFMbaKb7Uj21KzZYa4mEb3cYk7791sPjBp SGuTj1Z3aivkCLrCxesT+zO0QLiSS7j9PhmSbGzA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <552E1C9F.90501@mg-soft.si> Date: Wed, 15 Apr 2015 11:26:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <064DA485-DCF9-4F70-A7F4-23BDC3D8277B@nic.cz> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> <D152F710.9FBBE%kwatsen@juniper.net> <197BCF9C-48B3-4293-94F7-16E95D12D985@nic.cz> <552E1C9F.90501@mg-soft.si> To: Jernej Tuljak <jernejt@mg-soft.si> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/TcXFilEjyDQHvmhicK7d2RKtqOs> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2015 09:26:15 -0000 > On 15 Apr 2015, at 10:09, Jernej Tuljak <jernejt@mg-soft.si> wrote: >=20 > Dne 15.4.2015 ob 8:20 je Ladislav Lhotka zapisal(a): >>> On 14 Apr 2015, at 23:17, Kent Watsen <kwatsen@juniper.net> wrote: >>>=20 >>>=20 >>>>>> Why do you think anydata must be a container? >>>>> Because I thought that it was the *content* of an anydata instance = that >>>>> needs to be (potentially) modellable with YANG. >>>=20 >>> Y34-05 says: >>>=20 >>> Introduce a new 'anydata' statement that represents an >>> unknown chunk of data that can be modeled with YANG. >>>=20 >>>=20 >>> So let's say I have private YANG module foo: >>>=20 >>> module foo { >>> namespace "http://example.com/foo"; >>> leaf bar { >>> type string; >>> } >>> } >>>=20 >>> Now let's say there is a some other YANG module inet-widgets: >>>=20 >>> module inet-widgets { >>> namespace "urn:ietf:params:xml:ns:yang:ietf-widgets"; >>> anydata opaque-data ; >>> } >>>=20 >>> Then the XML would be: >>>=20 >>> <opaque-data xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-widgets"> >>> <bar xmlns=3D"http://example.com/foo">42</bar> >>> </opaque-data> >>>=20 >>> Or in JSON: >>>=20 >>> { >>> "inet-widgets:opaque-data" : { >>> "foo:bar" : 42 >>> } >>> } >>>=20 >>>=20 >>> Correct? >> Right, this is exactly how I understand the Y34-05 wording. With this = approach it is also easy to map XML<->JSON - otherwise we could have = problems with mapping things like >>=20 >> "foo": [1, 2] >>=20 >> which maps to >>=20 >> <foo>1</foo> >> <foo>2</foo> >>=20 >> (i.e. two anydata foo instances in XML). >=20 > A container or a leaf (!). The same as anyxml. But in JSON it=92s different: if "foo": 42 can be modelled in YANG, then arguably "foo": [1,2] can be modelled as well. >=20 > If anydata _content_ has a requirement that it must be modeled using = YANG, then I agree with your original example. The anydata node must be = a container. I don't agree this is the right way to do it however. >=20 > How would one model output of an RPC such as <get-schema> in = ietf-netconf-monitoring using anydata for the XML encoding? The payload = may contain character data where anydata now seems to require I think this really requires anyxml because neither XSD nor RELAX NG = (XML syntax) can be modelled with YANG - nor converted to JSON. > instances of YANG data nodes. >=20 > "foo": "character data" > <foo>character data</foo> >=20 > should be legal. >=20 > One could even argue that both of these "represent an unknown chunk of = data that can be modeled with YANG", therefore anydata may represent = them. In this case, I=92d prefer to just introduce =93anydata=94 as a synonym = for =93anyxml=94, deprecate the latter, and the guidelines document to = say that anydata/anyxml SHOULD NOT use mixed content. Introducing a new = data node type in YANG is quite a big change, and just getting rid of = mixed content (which is BTW a problem only for XML encoding) is IMO not = a sufficient reason. I think it would work just fine. In every use case of anyxml/anydata I = am aware of, it is not that the instance can contain really anything - = the content always has to comply to some schema although it may be = different for different servers or different RPC requests. In your = <get-schema> example, the client definitely expects a schema in the = requested format and not just arbitrary XML. Lada >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>=20 >>> Thanks, >>> Kent >>>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 15 05:29:56 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512F91A8AA1 for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 05:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNwISerqV7aM for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 05:29:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 520DA1A8A8B for <netmod@ietf.org>; Wed, 15 Apr 2015 05:29:52 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 38E3B1AE0473; Wed, 15 Apr 2015 14:29:50 +0200 (CEST) Date: Wed, 15 Apr 2015 14:29:50 +0200 (CEST) Message-Id: <20150415.142950.1683736142422907052.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHRp5eS7EYyFOrv1JxH3txP=f3P3RyrV9TodEz=TCdtbBQ@mail.gmail.com> References: <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> <D152F710.9FBBE%kwatsen@juniper.net> <CABCOCHRp5eS7EYyFOrv1JxH3txP=f3P3RyrV9TodEz=TCdtbBQ@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/o2Yfb_coIx70iiwtVlTC2Ae6gpI> Cc: jernejt@mg-soft.si, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2015 12:29:54 -0000 Andy Bierman <andy@yumaworks.com> wrote: > On Tue, Apr 14, 2015 at 2:17 PM, Kent Watsen <kwatsen@juniper.net> wrote: > > > >>>> Why do you think anydata must be a container? > >>> > >>> Because I thought that it was the *content* of an anydata instance that > >>>needs to be (potentially) modellable with YANG. > > > > > > Y34-05 says: > > > > Introduce a new 'anydata' statement that represents an > > unknown chunk of data that can be modeled with YANG. > > > > > > So let's say I have private YANG module foo: > > > > module foo { > > namespace "http://example.com/foo"; > > leaf bar { > > type string; > > } > > } > > > > Now let's say there is a some other YANG module inet-widgets: > > > > module inet-widgets { > > namespace "urn:ietf:params:xml:ns:yang:ietf-widgets"; > > anydata opaque-data ; > > } > > > > Then the XML would be: > > > > <opaque-data xmlns="urn:ietf:params:xml:ns:yang:ietf-widgets"> > > <bar xmlns="http://example.com/foo">42</bar> > > </opaque-data> > > > > Or in JSON: > > > > { > > "inet-widgets:opaque-data" : { > > "foo:bar" : 42 > > } > > } > > > > > > Correct? > > correct for this data model. > Note that the client knows nothing about 'opaque-data' > so it has no reason to expect a container or a leaf. > An empty leaf and an empty container can look the > same in XML > > But it us not hard for the server to check that anydata > can only be a container. I don't have any strong use-cases > for allowing anydata to be a leaf. Nor do I have reason > for forbidding it from being a leaf. The anydata node is encoded as an XML element. So if we have: anydata foo; and the XML: <foo>42</foo> it means that the contents of the anydata is not a leaf, but just a value. If we allowed this, should we also allow: <foo>42</foo> <foo>43</foo> ? This gets complicated. It is certainly ok for an anydata node to contain a leaf: <foo> <bar>42</bar> </foo> > Maybe it is easier to understand your way. > > anydata == container of arbitrary YANG data nodes > anyxml == mixed mode XML (we will pretend every server > MUST support this, yet zero so far do that) Agree. /martin From nobody Wed Apr 15 05:33:13 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72B81A8ACD for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 05:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAetRkItUKiL for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 05:33:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C141A8AC7 for <netmod@ietf.org>; Wed, 15 Apr 2015 05:33:09 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:fce5:2058:fa00:32d4] (unknown [IPv6:2001:718:1a02:1:fce5:2058:fa00:32d4]) by mail.nic.cz (Postfix) with ESMTPSA id 19E0E13F6EF; Wed, 15 Apr 2015 14:33:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429101188; bh=zlLMAQT1+1qnzYNU266OxBcYdzheiyRB59FecqW0+x8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XWMsvNoKfTZdygJ1IqHCTBqTot9B4K9ikdk0Q9Cz45im8r68h9n2tzTR+gbpCoQEd Sd3dtKUoLjM4FFT//SyJX692rD8OAnx03zfRiHGEVV7uyvv86KEUlsDNs9lT3djrc1 JjNi2X+iwT+VEuI78mlQa/WxcdgDETtUBZ+OgBYQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150415.142950.1683736142422907052.mbj@tail-f.com> Date: Wed, 15 Apr 2015 14:33:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: <EA450771-3167-48C3-A24C-93F5E667A8C4@nic.cz> References: <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> <D152F710.9FBBE%kwatsen@juniper.net> <CABCOCHRp5eS7EYyFOrv1JxH3txP=f3P3RyrV9TodEz=TCdtbBQ@mail.gmail.com> <20150415.142950.1683736142422907052.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj@tail-f.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/FLD7idhHpRtVv0X5PHqR6D48qOQ> Cc: Jernej Tuljak <jernejt@mg-soft.si>, netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2015 12:33:11 -0000 > On 15 Apr 2015, at 14:29, Martin Bjorklund <mbj@tail-f.com> wrote: > > Andy Bierman <andy@yumaworks.com> wrote: >> On Tue, Apr 14, 2015 at 2:17 PM, Kent Watsen <kwatsen@juniper.net> wrote: >>> >>>>>> Why do you think anydata must be a container? >>>>> >>>>> Because I thought that it was the *content* of an anydata instance that >>>>> needs to be (potentially) modellable with YANG. >>> >>> >>> Y34-05 says: >>> >>> Introduce a new 'anydata' statement that represents an >>> unknown chunk of data that can be modeled with YANG. >>> >>> >>> So let's say I have private YANG module foo: >>> >>> module foo { >>> namespace "http://example.com/foo"; >>> leaf bar { >>> type string; >>> } >>> } >>> >>> Now let's say there is a some other YANG module inet-widgets: >>> >>> module inet-widgets { >>> namespace "urn:ietf:params:xml:ns:yang:ietf-widgets"; >>> anydata opaque-data ; >>> } >>> >>> Then the XML would be: >>> >>> <opaque-data xmlns="urn:ietf:params:xml:ns:yang:ietf-widgets"> >>> <bar xmlns="http://example.com/foo">42</bar> >>> </opaque-data> >>> >>> Or in JSON: >>> >>> { >>> "inet-widgets:opaque-data" : { >>> "foo:bar" : 42 >>> } >>> } >>> >>> >>> Correct? >> >> correct for this data model. >> Note that the client knows nothing about 'opaque-data' >> so it has no reason to expect a container or a leaf. >> An empty leaf and an empty container can look the >> same in XML >> >> But it us not hard for the server to check that anydata >> can only be a container. I don't have any strong use-cases >> for allowing anydata to be a leaf. Nor do I have reason >> for forbidding it from being a leaf. > > The anydata node is encoded as an XML element. So if we have: > > anydata foo; > > and the XML: > > <foo>42</foo> > > it means that the contents of the anydata is not a leaf, but just a > value. > > If we allowed this, should we also allow: > > <foo>42</foo> > <foo>43</foo> > > ? This gets complicated. > > It is certainly ok for an anydata node to contain a leaf: > > <foo> > <bar>42</bar> > </foo> > >> Maybe it is easier to understand your way. >> >> anydata == container of arbitrary YANG data nodes >> anyxml == mixed mode XML (we will pretend every server >> MUST support this, yet zero so far do that) > > Agree. +1 Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 15 05:33:51 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D021A8ADD for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 05:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyStOKrC5Dgj for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 05:33:49 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CA30E1A8ADC for <netmod@ietf.org>; Wed, 15 Apr 2015 05:33:48 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1748C1AE0473; Wed, 15 Apr 2015 14:33:48 +0200 (CEST) Date: Wed, 15 Apr 2015 14:33:47 +0200 (CEST) Message-Id: <20150415.143347.1914656301225287499.mbj@tail-f.com> To: jernejt@mg-soft.si From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <552E1C9F.90501@mg-soft.si> References: <D152F710.9FBBE%kwatsen@juniper.net> <197BCF9C-48B3-4293-94F7-16E95D12D985@nic.cz> <552E1C9F.90501@mg-soft.si> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/wB1VcAMQEe52Po3Kgdej5BWQ3fc> Cc: netmod@ietf.org Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2015 12:33:50 -0000 Jernej Tuljak <jernejt@mg-soft.si> wrote: > How would one model output of an RPC such as <get-schema> in > ietf-netconf-monitoring using anydata for the XML encoding? You wouldn't, since the schema is not modelled in YANG. If we want to avoid anyxml, you could model it as a string (makes an YIN module look ugly over the wire, not a big issue maybe) or binary (needs a decoder on the client). /martin From nobody Wed Apr 15 09:34:30 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400C61A9148 for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 09:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjhinlurcvQX for <netmod@ietfa.amsl.com>; Wed, 15 Apr 2015 09:34:27 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 A7C7C1B2D6E for <netmod@ietf.org>; Wed, 15 Apr 2015 09:34:26 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so38409745lbb.2 for <netmod@ietf.org>; Wed, 15 Apr 2015 09:34:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qaMV8ToqsmWx0luA4iZpD2fGE92H7yiicoNBa+tZ6Gw=; b=gR2W+Ki/StmBmrMMAB37x/NRexFJkCvXck0vi0B+zKqvWHb+zRdqd6xIlge8olm+7l sbCaHTWfWYJkalIfuvk9g8XArA7Y9iXp1JzPAcDeUz7ZjTbTSDYqkxyIgCCjUgTwJN2Y 7pqUMJ918Q/6f7Xk6I4xuZk5IidqXAe6b6tIQ17nF3DeXN5B0HHUORBSC0xerEdXG5VT A7cwb+7y0pkxTrFpMUcGhdD6Ua+RPz20HxKc5acgNrGYpOf4gw9dQPUq5qfvphA52Bed qwr8mtSQ6V3aWLzSoEzA8soH9ZFu/UZn6TNAMdyLYEKlSIFa/p7R8GzzpUFCOcKxO46f J/dw== X-Gm-Message-State: ALoCoQniPRl5IVO1+CeG72arOrSRmdva/BpHpy8g3Pgp8Lx1ATZvq2jHmsq6DwxzgQodUFzsbcJj MIME-Version: 1.0 X-Received: by 10.152.37.40 with SMTP id v8mr24801869laj.123.1429115665111; Wed, 15 Apr 2015 09:34:25 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 15 Apr 2015 09:34:24 -0700 (PDT) In-Reply-To: <20150415.143347.1914656301225287499.mbj@tail-f.com> References: <D152F710.9FBBE%kwatsen@juniper.net> <197BCF9C-48B3-4293-94F7-16E95D12D985@nic.cz> <552E1C9F.90501@mg-soft.si> <20150415.143347.1914656301225287499.mbj@tail-f.com> Date: Wed, 15 Apr 2015 09:34:24 -0700 Message-ID: <CABCOCHTLKYM4zEwr_TM10UcUHMwxpMMXw0j1FyqQ+E=9Q=ehew@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/qGfwCfYN8nbDQck3OjEBPTucECQ> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2015 16:34:28 -0000 On Wed, Apr 15, 2015 at 5:33 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Jernej Tuljak <jernejt@mg-soft.si> wrote: >> How would one model output of an RPC such as <get-schema> in >> ietf-netconf-monitoring using anydata for the XML encoding? > > You wouldn't, since the schema is not modelled in YANG. > > If we want to avoid anyxml, you could model it as a string (makes an > YIN module look ugly over the wire, not a big issue maybe) or binary > (needs a decoder on the client). > I don't think anyxml can be avoided. Modeling XML as a string is a non-starter. The tools will treat the content as a string. They have no way of knowing that <get-schema> output is special and >foo< must be converted to <foo> before using it. The <get-schema> operation would continue to use anyxml I guess. > > /martin Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 16 02:19:05 2015 Return-Path: <internet-drafts@ietf.org> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07EA1B3054; Thu, 16 Apr 2015 02:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHV-O6juktfv; Thu, 16 Apr 2015 02:19:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A86191B3031; Thu, 16 Apr 2015 02:19:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: <i-d-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416091902.391.84715.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 02:19:02 -0700 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ILbRXGpf-t_dmGQjJMoDu69MI7M> Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-metadata-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 09:19:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Defining and Using Metadata with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-metadata-00.txt Pages : 16 Date : 2015-04-16 Abstract: This document defines a YANG extension statement that allows for defining syntax of metadata annotions in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 16 02:55:57 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108FA1A8B84 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 02:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-TaDppsCepS for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 02:55:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 795E91A8BB1 for <netmod@ietf.org>; Thu, 16 Apr 2015 02:55:52 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8F0221CC08DE; Thu, 16 Apr 2015 11:55:50 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net> In-Reply-To: <CABCOCHRp5eS7EYyFOrv1JxH3txP=f3P3RyrV9TodEz=TCdtbBQ@mail.gmail.com> References: <706ABBA4-DDAA-4E8D-897D-8274BF4FDA9C@nic.cz> <145830BC-40C5-496F-BA94-550EB0E3A273@nic.cz> <20150414094154.GB17183@elstar.local> <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> <D152F710.9FBBE%kwatsen@juniper.net> <CABCOCHRp5eS7EYyFOrv1JxH3txP=f3P3RyrV9TodEz=TCdtbBQ@mail.gmail.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 16 Apr 2015 11:55:49 +0200 Message-ID: <m27ftcpfbu.fsf@birdie.labs.nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/D4hlPJhU7iCTtagokz5-we0UW8k> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 09:55:56 -0000 Andy Bierman <andy@yumaworks.com> writes: > On Tue, Apr 14, 2015 at 2:17 PM, Kent Watsen <kwatsen@juniper.net> wrote: >> >>>>> Why do you think anydata must be a container? >>>> >>>> Because I thought that it was the *content* of an anydata instance that >>>>needs to be (potentially) modellable with YANG. >> >> >> Y34-05 says: >> >> Introduce a new 'anydata' statement that represents an >> unknown chunk of data that can be modeled with YANG. >> >> >> So let's say I have private YANG module foo: >> >> module foo { >> namespace "http://example.com/foo"; >> leaf bar { >> type string; >> } >> } >> >> Now let's say there is a some other YANG module inet-widgets: >> >> module inet-widgets { >> namespace "urn:ietf:params:xml:ns:yang:ietf-widgets"; >> anydata opaque-data ; >> } >> >> Then the XML would be: >> >> <opaque-data xmlns="urn:ietf:params:xml:ns:yang:ietf-widgets"> >> <bar xmlns="http://example.com/foo">42</bar> >> </opaque-data> >> >> Or in JSON: >> >> { >> "inet-widgets:opaque-data" : { >> "foo:bar" : 42 >> } >> } >> >> >> Correct? > > correct for this data model. > Note that the client knows nothing about 'opaque-data' > so it has no reason to expect a container or a leaf. > An empty leaf and an empty container can look the > same in XML > > But it us not hard for the server to check that anydata > can only be a container. I don't have any strong use-cases > for allowing anydata to be a leaf. Nor do I have reason > for forbidding it from being a leaf. > > Maybe it is easier to understand your way. > > anydata == container of arbitrary YANG data nodes Could we then agree on the following change to the wording of Y34-05? OLD - Introduce a new 'anydata' statement that represents an unknown chunk of data that can be modeled with YANG NEW - Introduce a new 'anydata' statement that represents a container whose content is an unknown chunk of data that can be modeled with YANG. Lada > anyxml == mixed mode XML (we will pretend every server > MUST support this, yet zero so far do that) > > > > >> >> Thanks, >> Kent >> > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 16 09:41:34 2015 Return-Path: <svshah@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDEC1B2CD1 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 09:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPdTDu0IF3E2 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 09:41:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0101B2CCB for <netmod@ietf.org>; Thu, 16 Apr 2015 09:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2896; q=dns/txt; s=iport; t=1429202492; x=1430412092; h=from:to:subject:date:message-id:mime-version; bh=enz/Kgg265/RKHcKFb2ehyQqBMr+fGjKMwSFSwUmBUw=; b=CIXKsSVZFFvkOO+3aIm1UCduKIWThKS/3vtUzBBNQJUm6aNMbne6j5vk WA6YEzLD61+9ohplzP5SEJXB+sykir/cIwaIJckN+N4lg1HOZ+JMAMh1v tc11LemLXde+IyHbniYD0iYccghb24aAr5kNWvIyRVVRKN09nNLjp806y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQDk5S9V/51dJa1cgkVHgTPPJUwBAQEBAQF+hCeBCwEMAXMfCASIPaMYpTQMIJRbBZEWihmUeyKDb4IzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,589,1422921600"; d="scan'208,217";a="412416799" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 16 Apr 2015 16:41:05 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3GGf58Q011613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netmod@ietf.org>; Thu, 16 Apr 2015 16:41:05 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.214]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 16 Apr 2015 11:41:05 -0500 From: "Shitanshu Shah (svshah)" <svshah@cisco.com> To: "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: any guidelines for statistics data model Thread-Index: AQHQeGQhm3Rhh25jBEum1KsMeKRWdw== Date: Thu, 16 Apr 2015 16:41:04 +0000 Message-ID: <D155342E.1083E%svshah@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.76.247] Content-Type: multipart/alternative; boundary="_000_D155342E1083Esvshahciscocom_" MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/VOjcUsSmPjFd3yn6XlBEeuYuzZM> Subject: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 16:41:33 -0000 --_000_D155342E1083Esvshahciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Am curious to know if there is any guidelines on how stats to be modeled? I= understand that one style may not fit all but at the least for consistency= across different technologies if there is any list defined from which is t= he best preferred approach to the least preferred? Like from one extreme, embedding stats in each config container, to another= extreme, each vendor to implement its own RPC? We are working on a diffserv data model and one specific aspect of this mod= el is that there is a config model to define a template which then associat= ed, by reference of a template name, to different interfaces. The stats req= uirement is for each interface relevant instance in this case and thus embe= dding stats in the config template not sure make sense. Thus we may have options of either 1) define separate (separate from config= ) model for stats with the same key definition but stats model is then used= directly under interface or 2) use of RPC Regards, Shitanshu --_000_D155342E1083Esvshahciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <BDE629E08AB545488FF6D649FF5C1A8F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div><br> </div> <div>Hi,</div> <div><br> </div> <div>Am curious to know if there is any guidelines on how stats to be model= ed? I understand that one style may not fit all but at the least for consis= tency across different technologies if there is any list defined from which= is the best preferred approach to the least preferred?</div> <div><br> </div> <div>Like from one extreme, embedding stats in each config container, to an= other extreme, each vendor to implement its own RPC?</div> <div><br> </div> <div>We are working on a diffserv data model and one specific aspect of thi= s model is that there is a config model to define a template which then ass= ociated, by reference of a template name, to different interfaces. The stat= s requirement is for each interface relevant instance in this case and thus embedding stats in the config temp= late not sure make sense.</div> <div><br> </div> <div>Thus we may have options of either 1) define separate (separate from c= onfig) model for stats with the same key definition but stats model is then= used directly under interface or 2) use of RPC</div> <div><br> </div> <div>Regards,</div> <div>Shitanshu</div> </body> </html> --_000_D155342E1083Esvshahciscocom_-- From nobody Thu Apr 16 11:28:29 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7551B2EB1 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 11:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oAC1gJ3QjYd for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 11:28:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E9F1B2F0D for <netmod@ietf.org>; Thu, 16 Apr 2015 11:28:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E34CAA04; Thu, 16 Apr 2015 20:28:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LTpDEpuV7l40; Thu, 16 Apr 2015 20:28:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Apr 2015 20:28:22 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00C832002C; Thu, 16 Apr 2015 20:28:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tfQKnTmzQtc6; Thu, 16 Apr 2015 20:28:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3C6B20013; Thu, 16 Apr 2015 20:28:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8025732C3AC0; Thu, 16 Apr 2015 20:28:18 +0200 (CEST) Date: Thu, 16 Apr 2015 20:28:18 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: "Shitanshu Shah (svshah)" <svshah@cisco.com> Message-ID: <20150416182817.GA6038@elstar.local> Mail-Followup-To: "Shitanshu Shah (svshah)" <svshah@cisco.com>, "netmod@ietf.org" <netmod@ietf.org> References: <D155342E.1083E%svshah@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <D155342E.1083E%svshah@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/WJ-zB16FfyAtK2Svn6pIW6zL1oY> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 18:28:27 -0000 On Thu, Apr 16, 2015 at 04:41:04PM +0000, Shitanshu Shah (svshah) wrote: > > Hi, > > Am curious to know if there is any guidelines on how stats to be modeled? I understand that one style may not fit all but at the least for consistency across different technologies if there is any list defined from which is the best preferred approach to the least preferred? > > Like from one extreme, embedding stats in each config container, to another extreme, each vendor to implement its own RPC? > > We are working on a diffserv data model and one specific aspect of this model is that there is a config model to define a template which then associated, by reference of a template name, to different interfaces. The stats requirement is for each interface relevant instance in this case and thus embedding stats in the config template not sure make sense. > > Thus we may have options of either 1) define separate (separate from config) model for stats with the same key definition but stats model is then used directly under interface or 2) use of RPC > If stats are associated with an interface, they should be modeled as such, i.e., augment them at an apropriate place into the /interface-state tree. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 16 12:03:00 2015 Return-Path: <aashaikh@google.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8341B3499 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 12:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byUlT8jssYKA for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 12:02:57 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 2F7981A008F for <netmod@ietf.org>; Thu, 16 Apr 2015 12:02:57 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so50466738obb.3 for <netmod@ietf.org>; Thu, 16 Apr 2015 12:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gpMJc8AvzGTZeBvggDAaFv//V//P1tnxc+J04RuQwik=; b=erNdSoHd/IVMTM9tWPKz0qrV6sG7aDZbapW43fr0zbLV93pl9g2awKJPAuzXbGvrHo hNwEveILYk5H3qZJLnTEjopKxqiIAl/UnWJlJxODOPPJZzBjCU3guZEAEarYHmqXTHka SoUe5y8IeAw++xT/RAh0T6I1c+wyMjBGnEWALqOXfbkAnQ77OwJGlMol/GH2ua7Ai2H/ FiujzKuKzBozO1/fPOOuAma07EsJmJpTpQoPQxJlDq4IJPNTiXThoZCXrPUP/pFwi0sS ieqy40KO3bpH5jwaiQgNLxiYOjbHaaDygbxZYpRCLVtJyNGxz7Wk6LvrTS6mzAHDNGm6 k8yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=gpMJc8AvzGTZeBvggDAaFv//V//P1tnxc+J04RuQwik=; b=lNBC11lEVjCwi2jGBOe/gqXLMu/Ka+HDi2TO6nHuH9Yrbwm3S52tJe2M7zxOZuNjFO DdVI46bEv2afkHUcBj/pqnUwr0qRVO0R109fIm7fPHepsoMoH7hqwSMy7yt9bcNjIFBV YPL4ks72G2iV+WbQMGXCtR2WTVGd9hWKnVTEQyHNlLVNjklMiKFIx2wYHvOi5+S/SWQz h/AXDeu9F36gF1m9/pARn7JnUoA4JcmUljVl4lA5Epw07ptdBJXSpY8bNyWuReCg7kxn QO3zzxS+D6UEQXde0FTl8x02fGzsW2t72qQRFapD9In3a+m1Ma2z8QsX8fRwRrE8+vim 9OWw== X-Gm-Message-State: ALoCoQlfxpfU4fEbP2gwMijsFxhtchioKkKHgDX2joHR5vbwc9AxDtF3e+j1iJrFYPIdjDIBk8zd MIME-Version: 1.0 X-Received: by 10.60.34.193 with SMTP id b1mr27148613oej.19.1429210976575; Thu, 16 Apr 2015 12:02:56 -0700 (PDT) Received: by 10.182.73.137 with HTTP; Thu, 16 Apr 2015 12:02:56 -0700 (PDT) In-Reply-To: <20150416182817.GA6038@elstar.local> References: <D155342E.1083E%svshah@cisco.com> <20150416182817.GA6038@elstar.local> Date: Thu, 16 Apr 2015 12:02:56 -0700 Message-ID: <CAJK7ZqKRJAcYuP3FgM3wjWK40JcfMswr=TyUk+FtVqXv9r6j4w@mail.gmail.com> From: Anees Shaikh <aashaikh@google.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Shitanshu Shah (svshah)" <svshah@cisco.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: multipart/alternative; boundary=089e01160c0491883f0513dc1c8c Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/RsiFrIG4FnM7oBQtS5PRM5phCMA> Subject: Re: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 19:02:58 -0000 --089e01160c0491883f0513dc1c8c Content-Type: text/plain; charset=UTF-8 I suggest you have a look at draft-openconfig-netmod-opstate-00, which describes an operational perspective on how to represent state (including stats/counters) in a consistent way using current YANG constructs. thanks. -- Anees On Thu, Apr 16, 2015 at 11:28 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 16, 2015 at 04:41:04PM +0000, Shitanshu Shah (svshah) wrote: > > > > Hi, > > > > Am curious to know if there is any guidelines on how stats to be > modeled? I understand that one style may not fit all but at the least for > consistency across different technologies if there is any list defined from > which is the best preferred approach to the least preferred? > > > > Like from one extreme, embedding stats in each config container, to > another extreme, each vendor to implement its own RPC? > > > > We are working on a diffserv data model and one specific aspect of this > model is that there is a config model to define a template which then > associated, by reference of a template name, to different interfaces. The > stats requirement is for each interface relevant instance in this case and > thus embedding stats in the config template not sure make sense. > > > > Thus we may have options of either 1) define separate (separate from > config) model for stats with the same key definition but stats model is > then used directly under interface or 2) use of RPC > > > > If stats are associated with an interface, they should be modeled as > such, i.e., augment them at an apropriate place into the > /interface-state tree. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e01160c0491883f0513dc1c8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I suggest you have a look at=C2=A0draft-openconfig-netmod-= opstate-00, which describes an operational perspective on how to represent = state (including stats/counters) in a consistent way using current YANG con= structs.=C2=A0<div><br></div><div>thanks.</div><div>-- Anees</div></div><di= v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Apr 16, 2015= at 11:28 AM, Juergen Schoenwaelder <span dir=3D"ltr"><<a href=3D"mailto= :j.schoenwaelder@jacobs-university.de" target=3D"_blank">j.schoenwaelder@ja= cobs-university.de</a>></span> wrote:<br><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <div class=3D"HOEnZb"><div class=3D"h5">On Thu, Apr 16, 2015 at 04:41:04PM = +0000, Shitanshu Shah (svshah) wrote:<br> ><br> > Hi,<br> ><br> > Am curious to know if there is any guidelines on how stats to be model= ed? I understand that one style may not fit all but at the least for consis= tency across different technologies if there is any list defined from which= is the best preferred approach to the least preferred?<br> ><br> > Like from one extreme, embedding stats in each config container, to an= other extreme, each vendor to implement its own RPC?<br> ><br> > We are working on a diffserv data model and one specific aspect of thi= s model is that there is a config model to define a template which then ass= ociated, by reference of a template name, to different interfaces. The stat= s requirement is for each interface relevant instance in this case and thus= embedding stats in the config template not sure make sense.<br> ><br> > Thus we may have options of either 1) define separate (separate from c= onfig) model for stats with the same key definition but stats model is then= used directly under interface or 2) use of RPC<br> ><br> <br> </div></div>If stats are associated with an interface, they should be model= ed as<br> such, i.e., augment them at an apropriate place into the<br> /interface-state tree.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> /js<br> <br> --<br> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH<br> Phone: <a href=3D"tel:%2B49%20421%20200%203587" value=3D"+494212003587">+49= 421 200 3587</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany<br> Fax:=C2=A0 =C2=A0<a href=3D"tel:%2B49%20421%20200%203103" value=3D"+4942120= 03103">+49 421 200 3103</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<a href=3D= "http://www.jacobs-university.de/" target=3D"_blank">http://www.jacobs-univ= ersity.de/</a>><br> <br> _______________________________________________<br> netmod mailing list<br> <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">= https://www.ietf.org/mailman/listinfo/netmod</a><br> </font></span></blockquote></div><br></div> --089e01160c0491883f0513dc1c8c-- From nobody Thu Apr 16 12:24:35 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABBE1B3518 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 12:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PjGumD2dPmJ for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 12:24:32 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7CB1A0AC8 for <netmod@ietf.org>; Thu, 16 Apr 2015 12:24:31 -0700 (PDT) Received: by labbd9 with SMTP id bd9so64450296lab.2 for <netmod@ietf.org>; Thu, 16 Apr 2015 12:24:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cg25RAZqIPKldwXMWk9iYRyyBscXEcVDOCp/WOZchbQ=; b=hpiZ2ilyamkQiNl96RbkiJr3aPxtdGPyZMGY1TD4dtc5L1Blu0i+0lv1sUUklnQwnz 1BxarLl0zKxkqpdGqx9zm3A+kiQnDYrRynZpFBk2VfzTJE+K/Ph1gFOorKQBlCPut9D9 TJAJ4z2eX701ZV2R9N/jYE+CWo3axjz3yP+7p/iSNbqe2hPQYTL5TU6r0nEa6kzfDS1n ietcbIsxY+PeQOKfw8f1XlBknZc2yliQmXi8q80qmEmz4FxDeJe7yCG0wzhRYkEOlfBA cNiuvJo2sWCJwYVzaJ5U1wh/cC/SMw6mO2DGeOREQWz33c7e+m5Bz2S075S7VR3Y1xf8 a0kg== X-Gm-Message-State: ALoCoQl/67jHQUCP/4oF32fG6MYXKnDV+YSTHweToDyUjna7zNOuHBRoAmyRxeo1zXzP8ZtFItGn MIME-Version: 1.0 X-Received: by 10.152.115.173 with SMTP id jp13mr29513808lab.119.1429212269686; Thu, 16 Apr 2015 12:24:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 16 Apr 2015 12:24:29 -0700 (PDT) In-Reply-To: <D155342E.1083E%svshah@cisco.com> References: <D155342E.1083E%svshah@cisco.com> Date: Thu, 16 Apr 2015 12:24:29 -0700 Message-ID: <CABCOCHSCNsn6CARAPPgMSughd7SoPtzQ+R_g7bU3dWGwaieeaw@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: "Shitanshu Shah (svshah)" <svshah@cisco.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/cpE7NA8SgVRA7_Ee4S-6rhHxCAA> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 19:24:34 -0000 On Thu, Apr 16, 2015 at 9:41 AM, Shitanshu Shah (svshah) <svshah@cisco.com> wrote: > > Hi, > > Am curious to know if there is any guidelines on how stats to be modeled? I > understand that one style may not fit all but at the least for consistency > across different technologies if there is any list defined from which is the > best preferred approach to the least preferred? > > Like from one extreme, embedding stats in each config container, to another > extreme, each vendor to implement its own RPC? > You are mixing 2 different issues: 1) data organization: where should the operational data be located relative to other data nodes in the system 2) protocol mechanism: should standard <get> be used or separate <get-foo>, <get-bar> operations be used? For 1) I prefer the least amount of redundant information and implementation. For 2) I prefer standard <get> Andy > We are working on a diffserv data model and one specific aspect of this > model is that there is a config model to define a template which then > associated, by reference of a template name, to different interfaces. The > stats requirement is for each interface relevant instance in this case and > thus embedding stats in the config template not sure make sense. > > Thus we may have options of either 1) define separate (separate from config) > model for stats with the same key definition but stats model is then used > directly under interface or 2) use of RPC > > Regards, > Shitanshu > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Apr 16 12:28:38 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AC81B34EB for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 12:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBIdTcnpp7Xy for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 12:28:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEB51B338B for <netmod@ietf.org>; Thu, 16 Apr 2015 12:28:35 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 98D0C1AE0B12; Thu, 16 Apr 2015 21:28:33 +0200 (CEST) Date: Thu, 16 Apr 2015 21:29:02 +0200 (CEST) Message-Id: <20150416.212902.128988457635254802.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150416182817.GA6038@elstar.local> References: <D155342E.1083E%svshah@cisco.com> <20150416182817.GA6038@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Q18iCpQhYyZvEPDDii2J5-TEXRA> Cc: netmod@ietf.org Subject: Re: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 19:28:37 -0000 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 16, 2015 at 04:41:04PM +0000, Shitanshu Shah (svshah) > wrote: > > > > Hi, > > > > Am curious to know if there is any guidelines on how stats to be > > modeled? I understand that one style may not fit all but at the least > > for consistency across different technologies if there is any list > > defined from which is the best preferred approach to the least > > preferred? > > > > Like from one extreme, embedding stats in each config container, to > > another extreme, each vendor to implement its own RPC? > > > > We are working on a diffserv data model and one specific aspect of > > this model is that there is a config model to define a template which > > then associated, by reference of a template name, to different > > interfaces. The stats requirement is for each interface relevant > > instance in this case and thus embedding stats in the config template > > not sure make sense. > > > > Thus we may have options of either 1) define separate (separate from > > config) model for stats with the same key definition but stats model > > is then used directly under interface or 2) use of RPC > > > > If stats are associated with an interface, they should be modeled as > such, i.e., augment them at an apropriate place into the > /interface-state tree. Agreed. And this also answers your second question - model this as config false data rather than defining a special operation to retrieve it. /martin From nobody Thu Apr 16 12:37:52 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630DD1B3569 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 12:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cJhcRYwlmS7 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 12:37:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CBE8C1B353D for <netmod@ietf.org>; Thu, 16 Apr 2015 12:37:47 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 1DCAE1AE0B12 for <netmod@ietf.org>; Thu, 16 Apr 2015 21:37:47 +0200 (CEST) Date: Thu, 16 Apr 2015 21:38:15 +0200 (CEST) Message-Id: <20150416.213815.599521480253388697.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund <mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/YWe2ARZ4nCqvr1V1zxAtWjQ6CBQ> Subject: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 19:37:51 -0000 Hi, After the latest lengthy discussion on the list, I have updated the issues list (https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html) with my proposal for the solution to the problem (Y45-03), and Lada's refined version (Y45-04). I think it would be useful if people could indicate their preferred solution to this problem. My preference is Y45-04. It is flexible for module writers, and straightforward to understand for module readers. /martin From nobody Thu Apr 16 13:17:57 2015 Return-Path: <steve.baillargeon@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5FB1B3665 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 13:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTt3C6zBA29s for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 13:17:53 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242C91B3662 for <netmod@ietf.org>; Thu, 16 Apr 2015 13:17:53 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-a3-552fc20201e1 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 44.FA.12456.202CF255; Thu, 16 Apr 2015 16:06:59 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 16:17:51 -0400 From: Steve Baillargeon <steve.baillargeon@ericsson.com> To: Anees Shaikh <aashaikh@google.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Shitanshu Shah (svshah)" <svshah@cisco.com>, "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: [netmod] any guidelines for statistics data model Thread-Index: AQHQeGQhm3Rhh25jBEum1KsMeKRWd51QOH0AgAAJrgD//8KdkA== Date: Thu, 16 Apr 2015 20:17:50 +0000 Message-ID: <DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66@eusaamb105.ericsson.se> References: <D155342E.1083E%svshah@cisco.com> <20150416182817.GA6038@elstar.local> <CAJK7ZqKRJAcYuP3FgM3wjWK40JcfMswr=TyUk+FtVqXv9r6j4w@mail.gmail.com> In-Reply-To: <CAJK7ZqKRJAcYuP3FgM3wjWK40JcfMswr=TyUk+FtVqXv9r6j4w@mail.gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonVpf5kH6owYlvHBYbdypaXN34k9Fi /sVGVouFh5cwObB4TPm9kdVjwaZSjyVLfjJ5bDjgGcASxWWTkpqTWZZapG+XwJXx8HQjY8GX bYwVXV132BoYOzYxdjFyckgImEjc/fqFDcIWk7hwbz2YLSRwlFGi93RpFyMXkL2cUeLKiu9g CTYBC4n1c5cxgyREBHYzStw4fJsZJCEsYCexYkEfWJGIgL3E78bjTBC2k8Tti+/YQWwWAVWJ O1OusYLYvAK+EkcXLmGD2DAbaMOMZWANnAKBEqdfPQMbyiggK7H77HWwOLOAuMStJ/OZIE4V kFiy5zwzhC0q8fLxP1YIW0lizutrzBD1+RL/GhoZIZYJSpyc+YRlAqPILCSjZiEpm4WkbBYj B1BcU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYuQoLU4ty003MtjECIyyYxJsujsY97y0 PMQowMGoxMO7QFw/VIg1say4MvcQozQHi5I476IHB0OEBNITS1KzU1MLUovii0pzUosPMTJx cEo1MBb+ZH7tJrpo6/Ryj5UFshkTkxRKp5+euS6vmWO3xzITn+2XZru+P7D56Epx3yohgVmJ PR9rl0tHCNfvz/iV9mJL4LmUy78V9G/M9EudeXmaTZUX/4FWxVmbvj73LHpRUXRJ821D4KIl J75emJYnaNtnxJdRZ/7Vs7UxVOD7blOxqGcTSpYd9lJiKc5INNRiLipOBAAbpx6dkwIAAA== Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/-yUauxqbG7QuQn5VV5aYRn_yZKc> Subject: Re: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 20:17:55 -0000 --_000_DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66eusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3ZSBuZWVkIGd1aWRlbGluZXMgZm9yIHN0YXRpc3RpY3MuIFRoZXJlIGlzIHBsZW50 eSBvZiBsZXNzb25zIHRvIGxlYXJuICh0byBkbyBhbmQgbm90IHRvIGRvKSBmcm9tIHN0YXRzIGRl ZmluZWQgaW4gU05NUCBNSUJzLg0KSGF2aW5nIGRyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3Rh dGUtMDAgYW5kIGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwODdiaXMtMDEgYXJlIGV4Y2VsbGVudCBp ZGVhLiBTaG91bGQgdGhleSBiZSBjb25zb2xpZGF0ZWQgaW50byBvbmU/DQpJIGp1c3Qgc3RhcnRl ZCB3cml0aW5nIG15IG93biBndWlkZWxpbmVzIGZvciBtb2RlbGluZyBZQU5HIHN0YXRpc3RpY3Mg KG1vcmUgcXVlc3Rpb25zIHRoYW4gYW5zd2VycyBzbyBmYXIpLiBJTU8gTWFydGluIGRpZCBzZXQg dGhlIHN0YWdlIGZvciB0aGUgYmFzZSBzZXQgb2YgZ3VpZGVsaW5lcyBmb3Igc3RhdCBkZWZpbml0 aW9uIGluIFJGQzcyMjMuDQoNClNvbWUgb2YgbXkgbm90ZXMgYXJlOg0KDQoNCsK3ICAgICAgICAg SSBzZWUgdGhlIHVzYWdlIG9mIGdyb3VwaW5nIHdoZXJlYXMgYSBzaW5nbGUgcm8gY29udGFpbmVy IGZvciBzdGF0cyBjb3VsZCBlYXNpbHkgZG8NCg0KwrcgICAgICAgICBJIHByZWZlciB0byB1c2Ug cm8gc3RhdGlzdGljcyBhcyBvcHBvc2VkIHRvIHJvIGNvdW50ZXJzDQoNCsK3ICAgICAgICAgV2hl biBkZWZpbmluZyBhIDY0LWJpdCBjb3VudGVyLCB3ZSBzaG91bGQgdXNlIHRoZSBjb21tb24gWUFO RyBkYXRhIHR5cGVzIGFzIG11Y2ggcG9zc2libGUuIE1hbnkgbmV3IGRyYWZ0cyBhcmUgaWdub3Jp bmcgaXQuDQoNCsK3ICAgICAgICAgSSBiZWxpZXZlIHdlIG5lZWQgdG8gZGVmaW5lIGFkZGl0aW9u YWwgc3RhdHMgYXMgY29tbW9uIFlBTkcgZGF0YSB0eXBlcy4NCg0KwrcgICAgICAgICBJIHNlZSB0 aGF0IG1vc3Qgc3RhdHMgYXJlIGRlZmluZWQgYXMgb3B0aW9uYWwgbm9kZXMuIEkgcHJlZmVyIHdl IGRlZmluZSBhIHNtYWxsIHNldCBvZiBtYW5kYXRvcnkgc3RhdHMgKHdoZW4gYXBwbGljYWJsZSkg YW5kIGxldCB0aGUgdmVuZG9yIGluZGljYXRlcyB3aGVuIGEgc3BlY2lmaWMgbWFuZGF0b3J5IHN0 YXQgaXMgbm90IGN1cnJlbnRseSBzdXBwb3J0ZWQuDQoNCsK3ICAgICAgICAgVGhlIGNvdW50ZXIg bmFtZSAobGVhZiBpZGVudGlmaWVyKSBpcyBzdGlsbCBhbiBhcnQgZm9ybS4gSSBhbSBob3Bpbmcg d2UgY291bGQgZGVmaW5lIGEgc2ltcGxlIG5hbWluZyBjb252ZW50aW9uLiBTaW1wbGUgdGhpbmdz IGxpa2UgcmUtdXNpbmcgdGhlIHNhbWUgc3RhdCBuYW1lLCBpbiB2cyBpbnB1dCBhbmQgb2N0ZXRz IHZzIGJ5dGVzLCBldGMNCg0KLVN0ZXZlIEINCg0KDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRt b2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZWVzIFNoYWlraA0KU2VudDogVGh1 cnNkYXksIEFwcmlsIDE2LCAyMDE1IDM6MDMgUE0NClRvOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7 IFNoaXRhbnNodSBTaGFoIChzdnNoYWgpOyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb bmV0bW9kXSBhbnkgZ3VpZGVsaW5lcyBmb3Igc3RhdGlzdGljcyBkYXRhIG1vZGVsDQoNCkkgc3Vn Z2VzdCB5b3UgaGF2ZSBhIGxvb2sgYXQgZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZS0w MCwgd2hpY2ggZGVzY3JpYmVzIGFuIG9wZXJhdGlvbmFsIHBlcnNwZWN0aXZlIG9uIGhvdyB0byBy ZXByZXNlbnQgc3RhdGUgKGluY2x1ZGluZyBzdGF0cy9jb3VudGVycykgaW4gYSBjb25zaXN0ZW50 IHdheSB1c2luZyBjdXJyZW50IFlBTkcgY29uc3RydWN0cy4NCg0KdGhhbmtzLg0KLS0gQW5lZXMN Cg0KT24gVGh1LCBBcHIgMTYsIDIwMTUgYXQgMTE6MjggQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCk9uIFRodSwgQXByIDE2LCAyMDE1 IGF0IDA0OjQxOjA0UE0gKzAwMDAsIFNoaXRhbnNodSBTaGFoIChzdnNoYWgpIHdyb3RlOg0KPg0K PiBIaSwNCj4NCj4gQW0gY3VyaW91cyB0byBrbm93IGlmIHRoZXJlIGlzIGFueSBndWlkZWxpbmVz IG9uIGhvdyBzdGF0cyB0byBiZSBtb2RlbGVkPyBJIHVuZGVyc3RhbmQgdGhhdCBvbmUgc3R5bGUg bWF5IG5vdCBmaXQgYWxsIGJ1dCBhdCB0aGUgbGVhc3QgZm9yIGNvbnNpc3RlbmN5IGFjcm9zcyBk aWZmZXJlbnQgdGVjaG5vbG9naWVzIGlmIHRoZXJlIGlzIGFueSBsaXN0IGRlZmluZWQgZnJvbSB3 aGljaCBpcyB0aGUgYmVzdCBwcmVmZXJyZWQgYXBwcm9hY2ggdG8gdGhlIGxlYXN0IHByZWZlcnJl ZD8NCj4NCj4gTGlrZSBmcm9tIG9uZSBleHRyZW1lLCBlbWJlZGRpbmcgc3RhdHMgaW4gZWFjaCBj b25maWcgY29udGFpbmVyLCB0byBhbm90aGVyIGV4dHJlbWUsIGVhY2ggdmVuZG9yIHRvIGltcGxl bWVudCBpdHMgb3duIFJQQz8NCj4NCj4gV2UgYXJlIHdvcmtpbmcgb24gYSBkaWZmc2VydiBkYXRh IG1vZGVsIGFuZCBvbmUgc3BlY2lmaWMgYXNwZWN0IG9mIHRoaXMgbW9kZWwgaXMgdGhhdCB0aGVy ZSBpcyBhIGNvbmZpZyBtb2RlbCB0byBkZWZpbmUgYSB0ZW1wbGF0ZSB3aGljaCB0aGVuIGFzc29j aWF0ZWQsIGJ5IHJlZmVyZW5jZSBvZiBhIHRlbXBsYXRlIG5hbWUsIHRvIGRpZmZlcmVudCBpbnRl cmZhY2VzLiBUaGUgc3RhdHMgcmVxdWlyZW1lbnQgaXMgZm9yIGVhY2ggaW50ZXJmYWNlIHJlbGV2 YW50IGluc3RhbmNlIGluIHRoaXMgY2FzZSBhbmQgdGh1cyBlbWJlZGRpbmcgc3RhdHMgaW4gdGhl IGNvbmZpZyB0ZW1wbGF0ZSBub3Qgc3VyZSBtYWtlIHNlbnNlLg0KPg0KPiBUaHVzIHdlIG1heSBo YXZlIG9wdGlvbnMgb2YgZWl0aGVyIDEpIGRlZmluZSBzZXBhcmF0ZSAoc2VwYXJhdGUgZnJvbSBj b25maWcpIG1vZGVsIGZvciBzdGF0cyB3aXRoIHRoZSBzYW1lIGtleSBkZWZpbml0aW9uIGJ1dCBz dGF0cyBtb2RlbCBpcyB0aGVuIHVzZWQgZGlyZWN0bHkgdW5kZXIgaW50ZXJmYWNlIG9yIDIpIHVz ZSBvZiBSUEMNCj4NCklmIHN0YXRzIGFyZSBhc3NvY2lhdGVkIHdpdGggYW4gaW50ZXJmYWNlLCB0 aGV5IHNob3VsZCBiZSBtb2RlbGVkIGFzDQpzdWNoLCBpLmUuLCBhdWdtZW50IHRoZW0gYXQgYW4g YXByb3ByaWF0ZSBwbGFjZSBpbnRvIHRoZQ0KL2ludGVyZmFjZS1zdGF0ZSB0cmVlLg0KDQovanMN Cg0KLS0NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkg QnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4Nzx0ZWw6JTJCNDklMjA0MjElMjAy MDAlMjAzNTg3PiAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55 DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMzx0ZWw6JTJCNDklMjA0MjElMjAyMDAlMjAzMTAzPiAg ICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QN Cm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K --_000_DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66eusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1u YW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQ5OTM0ODU1MTsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExNTMxMjc3MTYgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdlIG5l ZWQgZ3VpZGVsaW5lcyBmb3Igc3RhdGlzdGljcy4gVGhlcmUgaXMgcGxlbnR5IG9mIGxlc3NvbnMg dG8gbGVhcm4gKHRvIGRvIGFuZCBub3QgdG8gZG8pIGZyb20gc3RhdHMgZGVmaW5lZCBpbiBTTk1Q IE1JQnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhhdmluZyBkcmFmdC1vcGVuY29u ZmlnLW5ldG1vZC1vcHN0YXRlLTAwIGFuZCBkcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTAx IGFyZSBleGNlbGxlbnQgaWRlYS4gU2hvdWxkIHRoZXkgYmUgY29uc29saWRhdGVkIGludG8gb25l PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGp1c3Qgc3RhcnRlZCB3cml0aW5nIG15 IG93biBndWlkZWxpbmVzIGZvciBtb2RlbGluZyBZQU5HIHN0YXRpc3RpY3MgKG1vcmUgcXVlc3Rp b25zIHRoYW4gYW5zd2VycyBzbyBmYXIpLiBJTU8gTWFydGluIGRpZCBzZXQgdGhlIHN0YWdlIGZv ciB0aGUgYmFzZSBzZXQgb2YNCiBndWlkZWxpbmVzIGZvciBzdGF0IGRlZmluaXRpb24gaW4gUkZD NzIyMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlNvbWUgb2YgbXkgbm90ZXMgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBzZWUgdGhlIHVzYWdlIG9mIGdyb3VwaW5nIHdoZXJlYXMgYSBzaW5n bGUgcm8gY29udGFpbmVyIGZvciBzdGF0cyBjb3VsZCBlYXNpbHkgZG88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBwcmVmZXIgdG8gdXNlIHJv IHN0YXRpc3RpY3MgYXMgb3Bwb3NlZCB0byBybyBjb3VudGVyczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGVuIGRlZmluaW5nIGEgNjQtYml0 IGNvdW50ZXIsIHdlIHNob3VsZCB1c2UgdGhlIGNvbW1vbiBZQU5HIGRhdGEgdHlwZXMgYXMgbXVj aCBwb3NzaWJsZS4gTWFueSBuZXcgZHJhZnRzIGFyZSBpZ25vcmluZyBpdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5 N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHdlIG5l ZWQgdG8gZGVmaW5lIGFkZGl0aW9uYWwgc3RhdHMgYXMgY29tbW9uIFlBTkcgZGF0YSB0eXBlcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBz ZWUgdGhhdCBtb3N0IHN0YXRzIGFyZSBkZWZpbmVkIGFzIG9wdGlvbmFsIG5vZGVzLiBJIHByZWZl ciB3ZSBkZWZpbmUgYSBzbWFsbCBzZXQgb2YgbWFuZGF0b3J5IHN0YXRzICh3aGVuIGFwcGxpY2Fi bGUpIGFuZCBsZXQgdGhlIHZlbmRvciBpbmRpY2F0ZXMNCiB3aGVuIGEgc3BlY2lmaWMgbWFuZGF0 b3J5IHN0YXQgaXMgbm90IGN1cnJlbnRseSBzdXBwb3J0ZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjb3VudGVyIG5hbWUgKGxlYWYg aWRlbnRpZmllcikgaXMgc3RpbGwgYW4gYXJ0IGZvcm0uIEkgYW0gaG9waW5nIHdlIGNvdWxkIGRl ZmluZSBhIHNpbXBsZSBuYW1pbmcgY29udmVudGlvbi4gU2ltcGxlIHRoaW5ncyBsaWtlIHJlLXVz aW5nIHRoZSBzYW1lDQogc3RhdCBuYW1lLCBpbiB2cyBpbnB1dCBhbmQgb2N0ZXRzIHZzIGJ5dGVz LCBldGM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPi1TdGV2ZSBCPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbmV0bW9kIFtt YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZWVz IFNoYWlraDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMTUgMzowMyBQ TTxicj4NCjxiPlRvOjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBTaGl0YW5zaHUgU2hhaCAo c3ZzaGFoKTsgbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9k XSBhbnkgZ3VpZGVsaW5lcyBmb3Igc3RhdGlzdGljcyBkYXRhIG1vZGVsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdWdnZXN0IHlvdSBoYXZlIGEgbG9vayBhdCZuYnNw O2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3RhdGUtMDAsIHdoaWNoIGRlc2NyaWJlcyBhbiBv cGVyYXRpb25hbCBwZXJzcGVjdGl2ZSBvbiBob3cgdG8gcmVwcmVzZW50IHN0YXRlIChpbmNsdWRp bmcgc3RhdHMvY291bnRlcnMpIGluIGEgY29uc2lzdGVudCB3YXkgdXNpbmcgY3VycmVudCBZQU5H IGNvbnN0cnVjdHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj50aGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSBBbmVlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciAxNiwgMjAxNSBhdCAxMToyOCBBTSwgSnVlcmdl biBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gVGh1 LCBBcHIgMTYsIDIwMTUgYXQgMDQ6NDE6MDRQTSAmIzQzOzAwMDAsIFNoaXRhbnNodSBTaGFoIChz dnNoYWgpIHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7 IEFtIGN1cmlvdXMgdG8ga25vdyBpZiB0aGVyZSBpcyBhbnkgZ3VpZGVsaW5lcyBvbiBob3cgc3Rh dHMgdG8gYmUgbW9kZWxlZD8gSSB1bmRlcnN0YW5kIHRoYXQgb25lIHN0eWxlIG1heSBub3QgZml0 IGFsbCBidXQgYXQgdGhlIGxlYXN0IGZvciBjb25zaXN0ZW5jeSBhY3Jvc3MgZGlmZmVyZW50IHRl Y2hub2xvZ2llcyBpZiB0aGVyZSBpcyBhbnkgbGlzdCBkZWZpbmVkIGZyb20gd2hpY2ggaXMgdGhl IGJlc3QgcHJlZmVycmVkIGFwcHJvYWNoIHRvDQogdGhlIGxlYXN0IHByZWZlcnJlZD88YnI+DQom Z3Q7PGJyPg0KJmd0OyBMaWtlIGZyb20gb25lIGV4dHJlbWUsIGVtYmVkZGluZyBzdGF0cyBpbiBl YWNoIGNvbmZpZyBjb250YWluZXIsIHRvIGFub3RoZXIgZXh0cmVtZSwgZWFjaCB2ZW5kb3IgdG8g aW1wbGVtZW50IGl0cyBvd24gUlBDPzxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGFyZSB3b3JraW5n IG9uIGEgZGlmZnNlcnYgZGF0YSBtb2RlbCBhbmQgb25lIHNwZWNpZmljIGFzcGVjdCBvZiB0aGlz IG1vZGVsIGlzIHRoYXQgdGhlcmUgaXMgYSBjb25maWcgbW9kZWwgdG8gZGVmaW5lIGEgdGVtcGxh dGUgd2hpY2ggdGhlbiBhc3NvY2lhdGVkLCBieSByZWZlcmVuY2Ugb2YgYSB0ZW1wbGF0ZSBuYW1l LCB0byBkaWZmZXJlbnQgaW50ZXJmYWNlcy4gVGhlIHN0YXRzIHJlcXVpcmVtZW50IGlzIGZvciBl YWNoIGludGVyZmFjZQ0KIHJlbGV2YW50IGluc3RhbmNlIGluIHRoaXMgY2FzZSBhbmQgdGh1cyBl bWJlZGRpbmcgc3RhdHMgaW4gdGhlIGNvbmZpZyB0ZW1wbGF0ZSBub3Qgc3VyZSBtYWtlIHNlbnNl Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRodXMgd2UgbWF5IGhhdmUgb3B0aW9ucyBvZiBlaXRoZXIg MSkgZGVmaW5lIHNlcGFyYXRlIChzZXBhcmF0ZSBmcm9tIGNvbmZpZykgbW9kZWwgZm9yIHN0YXRz IHdpdGggdGhlIHNhbWUga2V5IGRlZmluaXRpb24gYnV0IHN0YXRzIG1vZGVsIGlzIHRoZW4gdXNl ZCBkaXJlY3RseSB1bmRlciBpbnRlcmZhY2Ugb3IgMikgdXNlIG9mIFJQQzxicj4NCiZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBzdGF0 cyBhcmUgYXNzb2NpYXRlZCB3aXRoIGFuIGludGVyZmFjZSwgdGhleSBzaG91bGQgYmUgbW9kZWxl ZCBhczxicj4NCnN1Y2gsIGkuZS4sIGF1Z21lbnQgdGhlbSBhdCBhbiBhcHJvcHJpYXRlIHBsYWNl IGludG8gdGhlPGJyPg0KL2ludGVyZmFjZS1zdGF0ZSB0cmVlLjxicj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4vanM8L3NwYW4+PGJyPg0K PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imhv ZW56YiI+SnVlcmdlbiBTY2hvZW53YWVsZGVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8L3NwYW4+PGJyPg0KPHNw YW4gY2xhc3M9ImhvZW56YiI+UGhvbmU6IDxhIGhyZWY9InRlbDolMkI0OSUyMDQyMSUyMDIwMCUy MDM1ODciPiYjNDM7NDkgNDIxIDIwMCAzNTg3PC9hPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueTwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5GYXg6Jm5ic3A7ICZuYnNwOzxhIGhyZWY9InRlbDolMkI0 OSUyMDQyMSUyMDIwMCUyMDMxMDMiPiYjNDM7NDkgNDIxIDIwMCAzMTAzPC9hPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5qYWNvYnMtdW5p dmVyc2l0eS5kZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5 LmRlLzwvYT4mZ3Q7PC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJob2VuemIiPm5ldG1vZCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImhvZW56YiI+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGll dGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66eusaamb105erics_-- From nobody Thu Apr 16 15:07:31 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410771B33CB for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 15:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6UGgXF7woBf for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 15:07:27 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3FB1B2A30 for <netmod@ietf.org>; Thu, 16 Apr 2015 15:07:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8909E129F; Fri, 17 Apr 2015 00:07:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Vyn86XqSvmed; Fri, 17 Apr 2015 00:07:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Apr 2015 00:07:24 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B15BE2002C; Fri, 17 Apr 2015 00:07:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m59GeMA-l5gC; Fri, 17 Apr 2015 00:07:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 212C720013; Fri, 17 Apr 2015 00:07:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7BD1532C3F55; Fri, 17 Apr 2015 00:07:22 +0200 (CEST) Date: Fri, 17 Apr 2015 00:07:22 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Steve Baillargeon <steve.baillargeon@ericsson.com> Message-ID: <20150416220722.GB6703@elstar.local> Mail-Followup-To: Steve Baillargeon <steve.baillargeon@ericsson.com>, Anees Shaikh <aashaikh@google.com>, "Shitanshu Shah (svshah)" <svshah@cisco.com>, "netmod@ietf.org" <netmod@ietf.org> References: <D155342E.1083E%svshah@cisco.com> <20150416182817.GA6038@elstar.local> <CAJK7ZqKRJAcYuP3FgM3wjWK40JcfMswr=TyUk+FtVqXv9r6j4w@mail.gmail.com> <DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66@eusaamb105.ericsson.se> 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: <DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66@eusaamb105.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Qglp4Be5NMPmR4OgU7CXnjsDvU8> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 22:07:29 -0000 On Thu, Apr 16, 2015 at 08:17:50PM +0000, Steve Baillargeon wrote: > > Some of my notes are: > > > I see the usage of grouping whereas a single ro container for stats could easily do ??? > I prefer to use ro statistics as opposed to ro counters ??? > When defining a 64-bit counter, we should use the common YANG data types as much possible. Many new drafts are ignoring it. It is in general a good idea to use common types. > I believe we need to define additional stats as common YANG data types. Which ones? > I see that most stats are defined as optional nodes. I prefer we define a small set of mandatory stats (when applicable) and let the vendor indicates when a specific mandatory stat is not currently supported. This not only applies to statistics / counters. > The counter name (leaf identifier) is still an art form. I am hoping we could define a simple naming convention. Simple things like re-using the same stat name, in vs input and octets vs bytes, etc > Use the units statement to define the units. (Agreeing on a common set of unit writing styles may be nice.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 16 15:16:28 2015 Return-Path: <steve.baillargeon@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6E91A90C5 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 15:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5rSbgbEXqXY for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 15:16:25 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13561A0378 for <netmod@ietf.org>; Thu, 16 Apr 2015 15:16:25 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-73-552fddc3dede Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4F.32.12456.3CDDF255; Thu, 16 Apr 2015 18:05:23 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 18:16:17 -0400 From: Steve Baillargeon <steve.baillargeon@ericsson.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thread-Topic: [netmod] any guidelines for statistics data model Thread-Index: AQHQeGQhm3Rhh25jBEum1KsMeKRWd51QOH0AgAAJrgD//8KdkIAAcOoA//+9ewA= Date: Thu, 16 Apr 2015 22:16:16 +0000 Message-ID: <DCF22B50497F7641B6DDD16ECC516F7F3F1DCBEA@eusaamb105.ericsson.se> References: <D155342E.1083E%svshah@cisco.com> <20150416182817.GA6038@elstar.local> <CAJK7ZqKRJAcYuP3FgM3wjWK40JcfMswr=TyUk+FtVqXv9r6j4w@mail.gmail.com> <DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66@eusaamb105.ericsson.se> <20150416220722.GB6703@elstar.local> In-Reply-To: <20150416220722.GB6703@elstar.local> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXSPn+7hu/qhBp0TrC027lS0uLrxJ6PF /IuNrBYLDy9hcmDxmPJ7I6vHgk2lHkuW/GTy2HDAM4AlissmJTUnsyy1SN8ugStj1uZTjAV/ +Cq+7znC3MC4nruLkZNDQsBE4s2MQ6wQtpjEhXvr2boYuTiEBI4ySkyav54FwlnOKLH84ntG kCo2AQuJ9XOXMYPYIgIOEv3butlAbGaBaokPT06BxYUF7CRWLOhjg6ixl/jdeJwJwvaT6Pn2 GMxmEVCV2PW2gx3E5hXwlfh0bSsLiC0k0MYkcf6SOIjNKWAo8e/cf7C9jAKyErvPXmeC2CUu cevJfCaIqwUkluw5zwxhi0q8fPwP6hsliTmvrzFD1OtILNj9CepObYllC18zQ+wVlDg58wnL BEaxWUjGzkLSMgtJyywkLQsYWVYxcpQWp5blphsZbGIERtIxCTbdHYx7XloeYhTgYFTi4V0g rh8qxJpYVlyZe4hRmoNFSZx30YODIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYS9gvT5ny oGLX5UqT3NUxMQZpPKq5LXFNDk/XxGRPvGChLTfJISKg/1dl5oV/hxbPDtyzU2fnzK+WLcyh BwTlLltkteoUmX5RcqtRSNrQ3GomcbO+vqxjR0OZQpOK/gsjz1Bu/cSN1YmnTnJmp+u3LiiZ 8EJwQneCmsZdse/3Ncu/Z5XN/qPEUpyRaKjFXFScCAA5Z7kThQIAAA== Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/vfYcHkjyCnvWEbUMVDbXYU7KrEo> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Apr 2015 22:16:27 -0000 Hi JS I was not specifically talking about the units statement but I also have it= on my to do list. Can I proceed with a few pages (draft?) on stats guidelines?=20 -Steve -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, April 16, 2015 6:07 PM To: Steve Baillargeon Cc: Anees Shaikh; Shitanshu Shah (svshah); netmod@ietf.org Subject: Re: [netmod] any guidelines for statistics data model On Thu, Apr 16, 2015 at 08:17:50PM +0000, Steve Baillargeon wrote: >=20 > Some of my notes are: >=20 >=20 > * I see the usage of grouping whereas a single ro container for s= tats could easily do ??? =20 > * I prefer to use ro statistics as opposed to ro counters ??? =20 > * When defining a 64-bit counter, we should use the common YANG d= ata types as much possible. Many new drafts are ignoring it. It is in general a good idea to use common types. > * I believe we need to define additional stats as common YANG dat= a types. Which ones? > * I see that most stats are defined as optional nodes. I prefer w= e define a small set of mandatory stats (when applicable) and let the vendo= r indicates when a specific mandatory stat is not currently supported. This not only applies to statistics / counters. > * The counter name (leaf identifier) is still an art form. I am h= oping we could define a simple naming convention. Simple things like re-usi= ng the same stat name, in vs input and octets vs bytes, etc > Use the units statement to define the units. (Agreeing on a common set of u= nit writing styles may be nice.) /js --=20 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/> From nobody Thu Apr 16 23:04:27 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7A71ACE95 for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 23:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf4L_4HgxThD for <netmod@ietfa.amsl.com>; Thu, 16 Apr 2015 23:04:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1191ACE93 for <netmod@ietf.org>; Thu, 16 Apr 2015 23:04:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5EC6F6F7; Fri, 17 Apr 2015 08:04:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ekTl00_uBIH2; Fri, 17 Apr 2015 08:03:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Apr 2015 08:04:21 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5FF592002C; Fri, 17 Apr 2015 08:04:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZvMadu4pAh37; Fri, 17 Apr 2015 08:04:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45C5C20013; Fri, 17 Apr 2015 08:04:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9BCDC32C4202; Fri, 17 Apr 2015 08:04:16 +0200 (CEST) Date: Fri, 17 Apr 2015 08:04:15 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Steve Baillargeon <steve.baillargeon@ericsson.com> Message-ID: <20150417060415.GA7332@elstar.local> Mail-Followup-To: Steve Baillargeon <steve.baillargeon@ericsson.com>, Anees Shaikh <aashaikh@google.com>, "Shitanshu Shah (svshah)" <svshah@cisco.com>, "netmod@ietf.org" <netmod@ietf.org> References: <D155342E.1083E%svshah@cisco.com> <20150416182817.GA6038@elstar.local> <CAJK7ZqKRJAcYuP3FgM3wjWK40JcfMswr=TyUk+FtVqXv9r6j4w@mail.gmail.com> <DCF22B50497F7641B6DDD16ECC516F7F3F1DCB66@eusaamb105.ericsson.se> <20150416220722.GB6703@elstar.local> <DCF22B50497F7641B6DDD16ECC516F7F3F1DCBEA@eusaamb105.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <DCF22B50497F7641B6DDD16ECC516F7F3F1DCBEA@eusaamb105.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/_Kx-31Iv3tSF8V91nt9ULT1DMrA> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] any guidelines for statistics data model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 06:04:26 -0000 Oh, if the question is whether we use 'bytes' or 'octets', I think the policy in the IETF has always been to prefer 'octets'. The reason is that octet _always_ means 8 bits while the number of bits in a byte is historically not necessarily 8 bits (even though this is the common case today). http://en.wikipedia.org/wiki/Byte /js On Thu, Apr 16, 2015 at 10:16:16PM +0000, Steve Baillargeon wrote: > Hi JS > I was not specifically talking about the units statement but I also have it on my to do list. > Can I proceed with a few pages (draft?) on stats guidelines? > > -Steve > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, April 16, 2015 6:07 PM > To: Steve Baillargeon > Cc: Anees Shaikh; Shitanshu Shah (svshah); netmod@ietf.org > Subject: Re: [netmod] any guidelines for statistics data model > > On Thu, Apr 16, 2015 at 08:17:50PM +0000, Steve Baillargeon wrote: > > > > Some of my notes are: > > > > > > * I see the usage of grouping whereas a single ro container for stats could easily do > > ??? > > > * I prefer to use ro statistics as opposed to ro counters > > ??? > > > * When defining a 64-bit counter, we should use the common YANG data types as much possible. Many new drafts are ignoring it. > > It is in general a good idea to use common types. > > > * I believe we need to define additional stats as common YANG data types. > > Which ones? > > > * I see that most stats are defined as optional nodes. I prefer we define a small set of mandatory stats (when applicable) and let the vendor indicates when a specific mandatory stat is not currently supported. > > This not only applies to statistics / counters. > > > * The counter name (leaf identifier) is still an art form. I am hoping we could define a simple naming convention. Simple things like re-using the same stat name, in vs input and octets vs bytes, etc > > > > Use the units statement to define the units. (Agreeing on a common set of unit writing styles may be nice.) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- 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/> From nobody Fri Apr 17 01:00:37 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6111B2A8A for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 01:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOKJrNrcmy5t for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 01:00:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16271B2A90 for <netmod@ietf.org>; Fri, 17 Apr 2015 01:00:13 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:fd66:d8e8:d026:d77b] (unknown [IPv6:2001:718:1a02:1:fd66:d8e8:d026:d77b]) by mail.nic.cz (Postfix) with ESMTPSA id 2090913FE1A; Fri, 17 Apr 2015 10:00:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429257611; bh=nC2b4X0vfRUo8oWcg3EnmtqXpSgMfX77sMoUiSqc/Oo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jDuhGRFLKK7nlE2Rmjnjb49sPpLdyUM0kWUULhEMN7eYebO7XDx6USKVcbyXgieCm 44vrYSaLiiZh/ucSrvNPB4N+6mGx5mLQKv6upORyVMTrCUQVSa/nYrWC72D5bH4ac4 F+SnCi7tDjmFIu4AvgsAFVQ98+zsbMeh5U7CBYHg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150416.213815.599521480253388697.mbj@tail-f.com> Date: Fri, 17 Apr 2015 10:00:12 +0200 Content-Transfer-Encoding: 7bit Message-Id: <ECE5C01D-DD77-4634-81F6-E64D818261E4@nic.cz> References: <20150416.213815.599521480253388697.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj@tail-f.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/hnCSdJj0m3StkJN28pmSkGjuUqI> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 08:00:36 -0000 > On 16 Apr 2015, at 21:38, Martin Bjorklund <mbj@tail-f.com> wrote: > > Hi, > > After the latest lengthy discussion on the list, I have updated the > issues list > (https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html) with > my proposal for the solution to the problem (Y45-03), and Lada's > refined version (Y45-04). > > I think it would be useful if people could indicate their preferred > solution to this problem. > > > My preference is Y45-04. It is flexible for module writers, and > straightforward to understand for module readers. Same here. Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 17 01:16:06 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968581B2ABF for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 01:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNMpGqDrN6-T for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 01:16:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E681B2ABE for <netmod@ietf.org>; Fri, 17 Apr 2015 01:16:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C44661281; Fri, 17 Apr 2015 10:16:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ULR3m00vphxs; Fri, 17 Apr 2015 10:15:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Apr 2015 10:16:01 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C6682002C; Fri, 17 Apr 2015 10:16:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UF595ypqkjIT; Fri, 17 Apr 2015 10:16:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D260020013; Fri, 17 Apr 2015 10:15:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5327F32C45A3; Fri, 17 Apr 2015 10:15:58 +0200 (CEST) Date: Fri, 17 Apr 2015 10:15:57 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Martin Bjorklund <mbj@tail-f.com> Message-ID: <20150417081557.GA7724@elstar.local> Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org References: <20150416.213815.599521480253388697.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150416.213815.599521480253388697.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/l0sUsT36FaARhMrjY2skBUlM1BM> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 08:16:04 -0000 On Thu, Apr 16, 2015 at 09:38:15PM +0200, Martin Bjorklund wrote: > My preference is Y45-04. It is flexible for module writers, and > straightforward to understand for module readers. As a technical contributor, I support Martin's proposal to adopt Y45-04. It seems to handle all the cases and it is consistent with the old YANG design philosophy that readers are first priority, model writers second priority, and tool writers third priority. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 17 01:28:52 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB62D1B2AE7 for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 01:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq1mTv8iVgx2 for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 01:28:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC7C1B2AE0 for <netmod@ietf.org>; Fri, 17 Apr 2015 01:28:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 57A4BF6B; Fri, 17 Apr 2015 10:28:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IeK-S3rS2lw0; Fri, 17 Apr 2015 10:28:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Apr 2015 10:28:45 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8C9C20031; Fri, 17 Apr 2015 10:28:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hiaa9Z1Q-n6u; Fri, 17 Apr 2015 10:28:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A51E720013; Fri, 17 Apr 2015 10:28:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3670732C4683; Fri, 17 Apr 2015 10:28:42 +0200 (CEST) Date: Fri, 17 Apr 2015 10:28:41 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150417082841.GC7724@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net>, Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> References: <20150414.120108.2000386990242822687.mbj@tail-f.com> <2287C5B1-12DC-455C-8A88-8F135C02A5CC@nic.cz> <CABCOCHQ-_4bPtTaXOjEkY1KQH7YTtj18kcrN6CW2vEuQ3s1rsA@mail.gmail.com> <53D35612-6D65-4E38-B636-6D7ED2655CE5@nic.cz> <CABCOCHTjPGHykUHRswDN0=go4+WWtS_LxF9n=SbXVaDkZgz9Dg@mail.gmail.com> <F5C91677-5666-426E-8CCF-B161C9CC0CCE@nic.cz> <CABCOCHTcPK7BP_Qhjm3A8VYdOM7oi27a_MGix2H4-JK3dbzxzQ@mail.gmail.com> <D152F710.9FBBE%kwatsen@juniper.net> <CABCOCHRp5eS7EYyFOrv1JxH3txP=f3P3RyrV9TodEz=TCdtbBQ@mail.gmail.com> <m27ftcpfbu.fsf@birdie.labs.nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <m27ftcpfbu.fsf@birdie.labs.nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/kCf_0P79lQy7PLTJRAGOdS2r3UY> Cc: Jernej Tuljak <jernejt@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 08:28:49 -0000 On Thu, Apr 16, 2015 at 11:55:49AM +0200, Ladislav Lhotka wrote: > Could we then agree on the following change to the wording of Y34-05? > > OLD > > - Introduce a new 'anydata' statement that represents an unknown > chunk of data that can be modeled with YANG > > NEW > > - Introduce a new 'anydata' statement that represents a container > whose content is an unknown chunk of data that can be modeled with > YANG. OK for me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 17 05:38:21 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C150B1B2BAA for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 05:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q2Po7F4DJrg for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 05:38:17 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 5205A1B2B9E for <netmod@ietf.org>; Fri, 17 Apr 2015 05:38:17 -0700 (PDT) Received: by labbd9 with SMTP id bd9so79203469lab.2 for <netmod@ietf.org>; Fri, 17 Apr 2015 05:38:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=XtzTVrBk2hAGqxD3pyP7XvLCIR4zxOtkzAbZM3QrOTU=; b=QKfs6cmA70D61fP9zrrXGWdRkmOaWSn9FSlz+TQ9basIOAUisSV3IvXiZPU/cJ8Nx2 sR8Kep8W+wEVb8RlHMxHE01UOOhBazoS4aK7X88LT5SqalBRsdczJjmscmRzDVS6D92s c3hqvnPW3+TLl72mTooGauuYj8B/I4RDAbWLBya8td3UA9B+q6sBHKfK0PVq0wWC01mv ZqQkYf21XBYy5x4YcQLG1CBGq6UxNc0T6yRL+1GMgaIQ4ZNBDGyyD2rywC0inqElSbFv e50lk9mFd+ceo/+/5niffyNw01TVUzmNUdJ/eGY4SJ2FUFyZCvH2YOCASoPJuS2BGEe0 NKig== X-Gm-Message-State: ALoCoQnUVg5DjGEfqqt1znrJDI8Y7Oelh8+7d0gllhsmNbqfgzOGGB4rpU1/Rf5Z5Sg3Ado8cPQ4 MIME-Version: 1.0 X-Received: by 10.152.87.46 with SMTP id u14mr3223379laz.82.1429274295608; Fri, 17 Apr 2015 05:38:15 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 17 Apr 2015 05:38:15 -0700 (PDT) In-Reply-To: <20150417081557.GA7724@elstar.local> References: <20150416.213815.599521480253388697.mbj@tail-f.com> <20150417081557.GA7724@elstar.local> Date: Fri, 17 Apr 2015 05:38:15 -0700 Message-ID: <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/7_6ZK_Mo68XuJ2ROJ5d25Cuv9iQ> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 12:38:19 -0000 Hi, I don't see how Y45 solves any problems module foo { import bar { prefix B; } import bar { prefix b; } import bar { prefix bar; } ... } This seems allowed -- what problem is solved by allowing the same module to be used with different prefixes? What if some have import-by-revision and others don't? What revision is used for the imports without revision? Don't they drift, just as before? module foo { import bar { prefix B; revision-data 2015-01-01; } import bar { prefix b; revision-data 2015-02-01; } import bar { prefix bar; revision-data 2015-03-01; } augment /B:X { ... } augment /b:X { ... } augment /bar:X { ... } ... } How is the augment-multiple revisions problem solved? IMO YANG 1.1 is getting way too complicated for humans to grok by inspection. This leads to over-reliance on tools to show the "real" YANG module. The probability that the intended model and the real model diverge is significantly increased. Andy On Fri, Apr 17, 2015 at 1:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 16, 2015 at 09:38:15PM +0200, Martin Bjorklund wrote: > >> My preference is Y45-04. It is flexible for module writers, and >> straightforward to understand for module readers. > > As a technical contributor, I support Martin's proposal to adopt > Y45-04. It seems to handle all the cases and it is consistent with the > old YANG design philosophy that readers are first priority, model > writers second priority, and tool writers third priority. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 17 05:59:53 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4549A1B2C2B for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 05:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gE74XsiK6jc for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 05:59:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D391B2C25 for <netmod@ietf.org>; Fri, 17 Apr 2015 05:59:42 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 0A5D713FE1A; Fri, 17 Apr 2015 14:59:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429275581; bh=9QEcIk51oqSumlXWOSNSO3I7XbouUB9+4Q/KwZaIuIU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fy74DvW31JZbxxFcNBozUJ2jmIGf6ufujcVB/lEzrIAfc+DXOpapYVjUzoRsykYpf Dr4FA8icSL7mgVxHZ+GPqJ6IVjcGldI0N+DAe1IC9AtRREOP07ACrCgKd59f0YiF2t 5sa+3hebVwNDmSHiKyan/Ss6E12ESx+CtokiVEdk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> Date: Fri, 17 Apr 2015 14:59:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7874CDC9-3386-4E7B-A621-369F6B4F35A5@nic.cz> References: <20150416.213815.599521480253388697.mbj@tail-f.com> <20150417081557.GA7724@elstar.local> <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> To: Andy Bierman <andy@yumaworks.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/FNGGBak000KG55Q2ZVoW-rib6BI> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 12:59:46 -0000 > On 17 Apr 2015, at 14:38, Andy Bierman <andy@yumaworks.com> wrote: >=20 > Hi, >=20 > I don't see how Y45 solves any problems >=20 > module foo { > import bar { prefix B; } > import bar { prefix b; } > import bar { prefix bar; } >=20 > ... > } >=20 > This seems allowed -- what problem is solved by allowing the same > module to be used with different prefixes? Multiple imports make sense only if different revisions are imported, = and this gives the designer of the importing module the option to use = stuff from different revisions of the imported module. I=E2=80=99d suggest that one module can be imported once without = revision and then every revision can be imported at most once.=20 >=20 > What if some have import-by-revision and others don't? > What revision is used for the imports without revision? For groupings and typedefs this is determined by the advertisement of = the imported module with "conformance=3Dno-protocol-accessible-nodes", = see Y45-03.=20 > Don't they drift, just as before? >=20 > module foo { > import bar { prefix B; revision-data 2015-01-01; } > import bar { prefix b; revision-data 2015-02-01; } > import bar { prefix bar; revision-data 2015-03-01; } >=20 > augment /B:X { ... } >=20 > augment /b:X { ... } >=20 > augment /bar:X { ... } > ... > } >=20 > How is the augment-multiple revisions problem solved? For augments, the revisions specified for imports is completely ignored, = what counts is the revision that the server implements. >=20 > IMO YANG 1.1 is getting way too complicated for humans to grok by > inspection. This leads to over-reliance on tools to show the "real" > YANG module. The probability that the intended model and the > real model diverge is significantly increased. I don=E2=80=99t think so. In most cases, one import per module should be = all that=E2=80=99s needed, and it is up to the designer of the importing = module whether the revision of a grouping or typedef will be fixed, or = whether it is left to implementations which revision is chosen. And a big benefit of this solution is that modules won=E2=80=99t be = cluttered with different versions of the same typedef or grouping = bearing different names. Lada >=20 >=20 > Andy >=20 >=20 >=20 > On Fri, Apr 17, 2015 at 1:15 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: >> On Thu, Apr 16, 2015 at 09:38:15PM +0200, Martin Bjorklund wrote: >>=20 >>> My preference is Y45-04. It is flexible for module writers, and >>> straightforward to understand for module readers. >>=20 >> As a technical contributor, I support Martin's proposal to adopt >> Y45-04. It seems to handle all the cases and it is consistent with = the >> old YANG design philosophy that readers are first priority, model >> writers second priority, and tool writers third priority. >>=20 >> /js >>=20 >> -- >> 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/> >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 17 06:01:02 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E791B2C25 for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 06:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HjUn-Q7Q3fv for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 06:00:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD86E1B2C23 for <netmod@ietf.org>; Fri, 17 Apr 2015 06:00:58 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 2305E1AE046D; Fri, 17 Apr 2015 15:00:57 +0200 (CEST) Date: Fri, 17 Apr 2015 15:01:32 +0200 (CEST) Message-Id: <20150417.150132.2114608334094896635.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> References: <20150416.213815.599521480253388697.mbj@tail-f.com> <20150417081557.GA7724@elstar.local> <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/X6b5p9bwjJFFNnq7s0BVpdZpzg0> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 13:01:01 -0000 Andy Bierman <andy@yumaworks.com> wrote: > Hi, > > I don't see how Y45 solves any problems I assume you mean Y45-03 and Y45-04. > module foo { > import bar { prefix B; } > import bar { prefix b; } > import bar { prefix bar; } > > ... > } > > This seems allowed This can easily be made illegal. It is actually not obvious that this is illegal in YANG 1.0. > -- what problem is solved by allowing the same > module to be used with different prefixes? Importing the same module and same revision with different prefixes does not seem very useful. Ok to make illegal. > What if some have import-by-revision and others don't? I assume you mean a situation like: import bar { prefix b; } import bar { revision-date 2004-04-01; prefix b1; } > What revision is used for the imports without revision? > Don't they drift, just as before? When the prefix "b" is used, it works just as if the second import wasn't there. The import by revision doesn't affect the other import. To answer your question, this works just like today - the server decides which version of bar to implement. > module foo { > import bar { prefix B; revision-data 2015-01-01; } > import bar { prefix b; revision-data 2015-02-01; } > import bar { prefix bar; revision-data 2015-03-01; } > > augment /B:X { ... } > > augment /b:X { ... } > > augment /bar:X { ... } > ... > } > > How is the augment-multiple revisions problem solved? >From Y45-03: If a server implements a module A that imports B, and A augments B or has a leafref to a node in B, the server MUST implement *some version* of module B that has the nodes A references. This is regardless of A imports B by revision or not. > IMO YANG 1.1 is getting way too complicated for humans to grok by > inspection. I disagree. Even in YANG 1.0 you can have different modules importing a common module by different revisions. In YANG 1.0 it is not clear what this means. With Y45-04 this is clarified. I think it is failry obvious which types are used in: import ietf-inet-types { revision-date 2013-07-17; prefix inet; } import ietf-inet-types { revision-date 2010-09-24; prefix inet6021; } leaf foo { type inet:ip-address-no-zone; } leaf bar { type inet6021:ip-address; } /martin > This leads to over-reliance on tools to show the "real" > YANG module. The probability that the intended model and the > real model diverge is significantly increased. > > > Andy > > > > On Fri, Apr 17, 2015 at 1:15 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: > > On Thu, Apr 16, 2015 at 09:38:15PM +0200, Martin Bjorklund wrote: > > > >> My preference is Y45-04. It is flexible for module writers, and > >> straightforward to understand for module readers. > > > > As a technical contributor, I support Martin's proposal to adopt > > Y45-04. It seems to handle all the cases and it is consistent with the > > old YANG design philosophy that readers are first priority, model > > writers second priority, and tool writers third priority. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Apr 17 06:48:57 2015 Return-Path: <internet-drafts@ietf.org> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F411B2CFE; Fri, 17 Apr 2015 06:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXzxDV90cGo0; Fri, 17 Apr 2015 06:48:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1B81B2CF3; Fri, 17 Apr 2015 06:48:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: <i-d-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150417134855.967.82679.idtracker@ietfa.amsl.com> Date: Fri, 17 Apr 2015 06:48:55 -0700 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/qvVX4DFPQ5N1an8ttVg5H1csI8Y> Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-18.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 13:48:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for Routing Management Authors : Ladislav Lhotka Acee Lindem Filename : draft-ietf-netmod-routing-cfg-18.txt Pages : 70 Date : 2015-04-17 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for routing protocols, route filters and other functions. The core routing data model provides common building blocks for such extensions - routing instances, routes, routing information bases (RIB), and routing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 17 07:01:38 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665C21B2CF2 for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 07:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79bsNZr3QwZs for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 07:01:36 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 D105D1A8BB3 for <netmod@ietf.org>; Fri, 17 Apr 2015 07:01:35 -0700 (PDT) Received: by layy10 with SMTP id y10so81019831lay.0 for <netmod@ietf.org>; Fri, 17 Apr 2015 07:01:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7S92nUiGVlGXbYruO32oMnD7ooHSSaFNb7QWg2f+Ack=; b=BGJ1rljCD+qtO3EAKFECizWfekmELUCodQzdsbmKE1c/Hht9F96aaljsHXamY5kqZ0 z7SrWKE896sSNbgeNa+Xhc629VpA8SZbLb7XfjZJyCk8CIQaDHOltN0JP/Y5WqSocsH9 lPVu6fxU2/0xlcONv8oe3XcDW/mHg77++NRZqd35BCzeYBioSKonCxWmkTL6HwpdTuX9 MLVcvawJA25U3f99jdXaN/7BsfUlDW8ro7J+jVVqN2EyjLbROjRbD6m/aQwbEe5p9ncp ChIcAjre9n1wcTnPEmOgrhsvoCR9lBLg8ygKgR/Bh//OwWUV8Pj+Yr+NyzXMRyxot8aV t23A== X-Gm-Message-State: ALoCoQn9upzEaGyqIEXC6OZqnTXwhLQZEXTrtpD2sh7uV0W3ilTkYaqHss0Qiak7O7UQZfsiRmFI MIME-Version: 1.0 X-Received: by 10.152.37.40 with SMTP id v8mr3935780laj.123.1429279294290; Fri, 17 Apr 2015 07:01:34 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 17 Apr 2015 07:01:34 -0700 (PDT) In-Reply-To: <20150417.150132.2114608334094896635.mbj@tail-f.com> References: <20150416.213815.599521480253388697.mbj@tail-f.com> <20150417081557.GA7724@elstar.local> <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> <20150417.150132.2114608334094896635.mbj@tail-f.com> Date: Fri, 17 Apr 2015 07:01:34 -0700 Message-ID: <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/E2I00AFFWPEHJ0-IetywpqG6-T4> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 14:01:38 -0000 On Fri, Apr 17, 2015 at 6:01 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Andy Bierman <andy@yumaworks.com> wrote: >> Hi, >> >> I don't see how Y45 solves any problems > > I assume you mean Y45-03 and Y45-04. > >> module foo { >> import bar { prefix B; } >> import bar { prefix b; } >> import bar { prefix bar; } >> >> ... >> } >> >> This seems allowed > > This can easily be made illegal. It is actually not obvious that this > is illegal in YANG 1.0. OK > >> -- what problem is solved by allowing the same >> module to be used with different prefixes? > > Importing the same module and same revision with different prefixes > does not seem very useful. Ok to make illegal. > >> What if some have import-by-revision and others don't? > > I assume you mean a situation like: > > import bar { > prefix b; > } > import bar { > revision-date 2004-04-01; > prefix b1; > } > Yes -- I do not understand the edits for the YANG guidelines for when to use an import with revision vs. without revision. >> What revision is used for the imports without revision? >> Don't they drift, just as before? > > When the prefix "b" is used, it works just as if the second import > wasn't there. The import by revision doesn't affect the other > import. > I did not realize Y45-4 combined Y45-03. I missed the words "As Y45-03..." > To answer your question, this works just like today - the server > decides which version of bar to implement. > >> module foo { >> import bar { prefix B; revision-data 2015-01-01; } >> import bar { prefix b; revision-data 2015-02-01; } >> import bar { prefix bar; revision-data 2015-03-01; } >> >> augment /B:X { ... } >> >> augment /b:X { ... } >> >> augment /bar:X { ... } >> ... >> } >> >> How is the augment-multiple revisions problem solved? > > From Y45-03: > > If a server implements a module A that imports B, and A augments B > or has a leafref to a node in B, the server MUST implement *some > version* of module B that has the nodes A references. This is > regardless of A imports B by revision or not. > >> IMO YANG 1.1 is getting way too complicated for humans to grok by >> inspection. > > I disagree. Even in YANG 1.0 you can have different modules importing > a common module by different revisions. In YANG 1.0 it is not clear > what this means. With Y45-04 this is clarified. > IMO the rules for Y45-03 are not obvious and readers will not intuitively guess all these rules. That's what makes it complicated. > I think it is failry obvious which types are used in: > > import ietf-inet-types { > revision-date 2013-07-17; > prefix inet; > } > import ietf-inet-types { > revision-date 2010-09-24; > prefix inet6021; > } > leaf foo { > type inet:ip-address-no-zone; > } > leaf bar { > type inet6021:ip-address; > } > I agree Y45-04 syntax is better than the inline uses@date. That was scary. I am not as worried about abuse and confusion for the IETF modules written by YANG experts. We can write usage guidelines, and IETF modules change very slowly over time. I am more concerned about the vendor modules that quickly get really complicated, or create unintended results in the validation or code generation. > > /martin > > Andy > > > >> This leads to over-reliance on tools to show the "real" >> YANG module. The probability that the intended model and the >> real model diverge is significantly increased. >> >> >> Andy >> >> >> >> On Fri, Apr 17, 2015 at 1:15 AM, Juergen Schoenwaelder >> <j.schoenwaelder@jacobs-university.de> wrote: >> > On Thu, Apr 16, 2015 at 09:38:15PM +0200, Martin Bjorklund wrote: >> > >> >> My preference is Y45-04. It is flexible for module writers, and >> >> straightforward to understand for module readers. >> > >> > As a technical contributor, I support Martin's proposal to adopt >> > Y45-04. It seems to handle all the cases and it is consistent with the >> > old YANG design philosophy that readers are first priority, model >> > writers second priority, and tool writers third priority. >> > >> > /js >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> From nobody Fri Apr 17 07:27:45 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CFD1B2D6B for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 07:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnE4otpA0W4u for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 07:27:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 244081B2D65 for <netmod@ietf.org>; Fri, 17 Apr 2015 07:27:40 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 6F79D1AE046D; Fri, 17 Apr 2015 16:27:38 +0200 (CEST) Date: Fri, 17 Apr 2015 16:28:14 +0200 (CEST) Message-Id: <20150417.162814.885796193974027337.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> References: <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> <20150417.150132.2114608334094896635.mbj@tail-f.com> <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ut2vQqF8HaOMO8885RqwY8b3L34> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 14:27:44 -0000 Andy Bierman <andy@yumaworks.com> wrote: > On Fri, Apr 17, 2015 at 6:01 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > Andy Bierman <andy@yumaworks.com> wrote: > >> Hi, > >> > >> I don't see how Y45 solves any problems > > > > I assume you mean Y45-03 and Y45-04. > > > >> module foo { > >> import bar { prefix B; } > >> import bar { prefix b; } > >> import bar { prefix bar; } > >> > >> ... > >> } > >> > >> This seems allowed > > > > This can easily be made illegal. It is actually not obvious that this > > is illegal in YANG 1.0. > > OK > > > > > >> -- what problem is solved by allowing the same > >> module to be used with different prefixes? > > > > Importing the same module and same revision with different prefixes > > does not seem very useful. Ok to make illegal. > > > >> What if some have import-by-revision and others don't? > > > > I assume you mean a situation like: > > > > import bar { > > prefix b; > > } > > import bar { > > revision-date 2004-04-01; > > prefix b1; > > } > > > > Yes -- I do not understand the edits for the YANG guidelines > for when to use an import with revision vs. without revision. I would say that for IETF models, we should be very conservative when changing a typedef or grouping. An exception is typedefs like iana-physical-class, which is designed to be extended (in a controlled fashion). Taken together this means that IETF modules should in most cases use import without revision. > >> IMO YANG 1.1 is getting way too complicated for humans to grok by > >> inspection. > > > > I disagree. Even in YANG 1.0 you can have different modules importing > > a common module by different revisions. In YANG 1.0 it is not clear > > what this means. With Y45-04 this is clarified. > > > > > IMO the rules for Y45-03 are not obvious and > readers will not intuitively guess all these rules. > That's what makes it complicated. I think the vast majority of modules will look like in YANG 1.0 - they will have a single import of any particular module, mostly w/o revision. The difference is that with Y45-04 there are clear rules that people can read if needed. YANG 1.0 is more confusing, since there are no clear rules. It might be confusing if a imports b@2004-04-01, and a server advertises a and b@2015-04-01. One might question if that is valid or not (it is valid). But again, we have the same situation in YANG 1.0. > I agree Y45-04 syntax is better than the inline uses@date. > That was scary. > > I am not as worried about abuse and confusion for > the IETF modules written by YANG experts. We can write > usage guidelines, and IETF modules change very slowly over time. > > I am more concerned about the vendor modules that quickly get > really complicated, or create unintended results in the validation > or code generation. The worst they can do is start to use import-by revison of different revisions of the same module. But this just means that they cherry pick typedefs or groupings from specific revisions. It is at least clear what this means. /martin From nobody Fri Apr 17 07:44:33 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CF91B2DBB for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nqDWoUCu8aM for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 07:44:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC181B2DAA for <netmod@ietf.org>; Fri, 17 Apr 2015 07:44:29 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:cc0f:cae5:7abf:c1e8] (unknown [IPv6:2001:718:1a02:1:cc0f:cae5:7abf:c1e8]) by mail.nic.cz (Postfix) with ESMTPSA id 021FD13FB6A for <netmod@ietf.org>; Fri, 17 Apr 2015 16:44:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429281868; bh=ginUDBjJaf3GsOoHddQxvZCJyH5E2P3DgJLFNjyNiJg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=bwnGEtXzS3qQkbJ4mW1dckT8myC+uEp76cutcl1DXTM4pg5bfXXNEJ27w2wbAuxM6 20RLH3mfPeIpuJknsctogbbvTbRzFTvWoJBt434OK2LNo6tAlvgqqg600mEvooTu1V 3CHhF1eCe7ob42LhbWekgscsuq79tNM7yMknmjgk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150417.162814.885796193974027337.mbj@tail-f.com> Date: Fri, 17 Apr 2015 16:44:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <395227FA-70CD-48D7-8B8C-70A97BF68E41@nic.cz> References: <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> <20150417.150132.2114608334094896635.mbj@tail-f.com> <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> <20150417.162814.885796193974027337.mbj@tail-f.com> To: NETMOD Working Group <netmod@ietf.org> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/mI51oN3qa7N3v3_CEK7g_7kjF2A> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 14:44:31 -0000 > On 17 Apr 2015, at 16:28, Martin Bjorklund <mbj@tail-f.com> wrote: >=20 > Andy Bierman <andy@yumaworks.com> wrote: >> On Fri, Apr 17, 2015 at 6:01 AM, Martin Bjorklund <mbj@tail-f.com> = wrote: >>> Andy Bierman <andy@yumaworks.com> wrote: >>>> Hi, >>>>=20 >>>> I don't see how Y45 solves any problems >>>=20 >>> I assume you mean Y45-03 and Y45-04. >>>=20 >>>> module foo { >>>> import bar { prefix B; } >>>> import bar { prefix b; } >>>> import bar { prefix bar; } >>>>=20 >>>> ... >>>> } >>>>=20 >>>> This seems allowed >>>=20 >>> This can easily be made illegal. It is actually not obvious that = this >>> is illegal in YANG 1.0. >>=20 >> OK >>=20 >>=20 >>>=20 >>>> -- what problem is solved by allowing the same >>>> module to be used with different prefixes? >>>=20 >>> Importing the same module and same revision with different prefixes >>> does not seem very useful. Ok to make illegal. >>>=20 >>>> What if some have import-by-revision and others don't? >>>=20 >>> I assume you mean a situation like: >>>=20 >>> import bar { >>> prefix b; >>> } >>> import bar { >>> revision-date 2004-04-01; >>> prefix b1; >>> } >>>=20 >>=20 >> Yes -- I do not understand the edits for the YANG guidelines >> for when to use an import with revision vs. without revision. >=20 > I would say that for IETF models, we should be very conservative when > changing a typedef or grouping. An exception is typedefs like > iana-physical-class, which is designed to be extended (in a controlled > fashion). Taken together this means that IETF modules should in most > cases use import without revision. It depends, in some cases it might be preferable to fix the revision = because then the module author can guarantee that things won=E2=80=99t = break. =20 >=20 >>>> IMO YANG 1.1 is getting way too complicated for humans to grok by >>>> inspection. >>>=20 >>> I disagree. Even in YANG 1.0 you can have different modules = importing >>> a common module by different revisions. In YANG 1.0 it is not clear >>> what this means. With Y45-04 this is clarified. >>>=20 >>=20 >>=20 >> IMO the rules for Y45-03 are not obvious and >> readers will not intuitively guess all these rules. >> That's what makes it complicated. >=20 > I think the vast majority of modules will look like in YANG 1.0 - they > will have a single import of any particular module, mostly w/o > revision. The difference is that with Y45-04 there are clear rules > that people can read if needed. YANG 1.0 is more confusing, since > there are no clear rules. >=20 > It might be confusing if a imports b@2004-04-01, and a server > advertises a and b@2015-04-01. One might question if that is valid or > not (it is valid). But again, we have the same situation in YANG 1.0. It could be valid if b both defines types/groupings and also has = target(s) for augments. Lada >=20 >> I agree Y45-04 syntax is better than the inline uses@date. >> That was scary. >>=20 >> I am not as worried about abuse and confusion for >> the IETF modules written by YANG experts. We can write >> usage guidelines, and IETF modules change very slowly over time. >>=20 >> I am more concerned about the vendor modules that quickly get >> really complicated, or create unintended results in the validation >> or code generation. >=20 > The worst they can do is start to use import-by revison of different > revisions of the same module. But this just means that they > cherry pick typedefs or groupings from specific revisions. It is at > least clear what this means. >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 17 09:37:31 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A4F1A6FDB for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 09:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxL5yEyFdySt for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 09:37:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57071A6F0B for <netmod@ietf.org>; Fri, 17 Apr 2015 09:37:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 80553EA3; Fri, 17 Apr 2015 18:37:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0HzJqyLN7eL1; Fri, 17 Apr 2015 18:36:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Apr 2015 18:37:26 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BB5120031; Fri, 17 Apr 2015 18:37:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ick3nRH-nqtc; Fri, 17 Apr 2015 18:37:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2D5420013; Fri, 17 Apr 2015 18:37:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 29F4032C51E4; Fri, 17 Apr 2015 18:37:24 +0200 (CEST) Date: Fri, 17 Apr 2015 18:37:23 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Martin Bjorklund <mbj@tail-f.com> Message-ID: <20150417163721.GD8783@elstar.local> Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com, netmod@ietf.org References: <CABCOCHTWMp2PjCs4iQE1fBdF4Q_4dPhajcoUJS3-Z5+Z+ZVShA@mail.gmail.com> <20150417.150132.2114608334094896635.mbj@tail-f.com> <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> <20150417.162814.885796193974027337.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150417.162814.885796193974027337.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/LBRB3PdLjvP-cF9kmHyjB2kUeBA> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 16:37:31 -0000 On Fri, Apr 17, 2015 at 04:28:14PM +0200, Martin Bjorklund wrote: > > I am more concerned about the vendor modules that quickly get > > really complicated, or create unintended results in the validation > > or code generation. > > The worst they can do is start to use import-by revison of different > revisions of the same module. But this just means that they > cherry pick typedefs or groupings from specific revisions. It is at > least clear what this means. > I think this is a big improvement. While cherry picking will likely not be needed when modules are well designed and maintained, I am pretty sure it will be necessary to handle cases where this is not the case (e.g., a maintainer did not forsee things correctly) or adoption of a new version is something that is implemented gradually in a couple of firmware releases. Being able to clearly say which grouping or typedef is used where is a big win. Previous proposals assumed that everything can be upgraded always in one go (in my view unrealistic) or that definitions are simply copied and duplicated and then start a life of their own (in my view to be avoided). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 17 14:25:55 2015 Return-Path: <bclaise@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2D21B2F14 for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 14:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiFPj6gZeh53 for <netmod@ietfa.amsl.com>; Fri, 17 Apr 2015 14:25:52 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B918D1B304C for <netmod@ietf.org>; Fri, 17 Apr 2015 14:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2047; q=dns/txt; s=iport; t=1429305951; x=1430515551; h=message-id:date:from:mime-version:to:subject; bh=oW+Nre3aC9tiNvlUQxvAjqu0pQyq8RfzWFtWa86pHco=; b=QY+puJxNvIxWVYDip9ZOzTlqwB8o0jCV+JZVRiLz9sr1Nt4AN1SmX5kn wCKCar4qnQAwXBsJW6wHm6uY51cFjxibPTPDcxP8s94MpgzE5edo3h7oe ucWGPLmAVEV4K9QTQ1xzWYfAho1n9hB/tcdF2tGye4TddvWU3gyMcRJEa 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CwBADweTFV/xbLJq1dg15dgxbEZoV+A4F4EQEBAQEBAQF9hEpVIAEcFgsCCwMCAQIBSw0IAQGIJw2jQY9WlS0BAQgCAR+TFIFFBY8EjDyHH41rIoN1PIJ1AQEB X-IronPort-AV: E=Sophos;i="5.11,597,1422921600"; d="scan'208,217";a="431764480" 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; 17 Apr 2015 21:25:50 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3HLPnum004128 for <netmod@ietf.org>; Fri, 17 Apr 2015 21:25:50 GMT Message-ID: <55317A98.4050606@cisco.com> Date: Fri, 17 Apr 2015 23:26:48 +0200 From: Benoit Claise <bclaise@cisco.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: NETMOD Working Group <netmod@ietf.org> Content-Type: multipart/alternative; boundary="------------070705060005050704000307" Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/mIKZCBLVliowLrHPek0NBMZE9a0> Subject: [netmod] Some OpenDaylight YANG modules statistics X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Apr 2015 21:25:53 -0000 This is a multi-part message in MIME format. --------------070705060005050704000307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Enjoy. http://www.claise.be/2015/04/ietf-yang-modules-statistiques/ In a nutshell: * IETF YANG MODELS * Number of correctly extracted YANG models from IETF drafts: 118 * Number of YANG models in IETF drafts that passed compilation: 30/118 * Number of all YANG models in IETF drafts (example, badly formatted, etc. ): 198 * * OPENDAYLIGHT YANG MODELS * Number of YANG models in Hydrogen release: 274 * Number of YANG models in Helium release: 372 * Number of YANG models in Lithium release: 529 Regards, Benoit --------------070705060005050704000307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Enjoy.<br> <br> <a class="moz-txt-link-freetext" href="http://www.claise.be/2015/04/ietf-yang-modules-statistiques/">http://www.claise.be/2015/04/ietf-yang-modules-statistiques/</a><br> In a nutshell:<br> <blockquote> <ul> <li>IETF YANG MODELS </li> <li>Number of correctly extracted YANG models from IETF drafts: 118 </li> <li>Number of YANG models in IETF drafts that passed compilation: 30/118 </li> <li>Number of all YANG models in IETF drafts (example, badly formatted, etc. ): 198 </li> <li> <br> </li> <li>OPENDAYLIGHT YANG MODELS </li> <li>Number of YANG models in Hydrogen release: 274 </li> <li>Number of YANG models in Helium release: 372 </li> <li>Number of YANG models in Lithium release: 529 </li> </ul> </blockquote> <br> Regards, Benoit </body> </html> --------------070705060005050704000307-- From nobody Tue Apr 21 09:00:52 2015 Return-Path: <bclaise@cisco.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C715D1ACF08 for <netmod@ietfa.amsl.com>; Tue, 21 Apr 2015 09:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_zlL7Se6rH5 for <netmod@ietfa.amsl.com>; Tue, 21 Apr 2015 09:00:49 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6FB1ACF1D for <netmod@ietf.org>; Tue, 21 Apr 2015 09:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85; q=dns/txt; s=iport; t=1429632034; x=1430841634; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=bu3KrHVtVh2lFtiwALtTHfIDprwDDbBhDJoqIhywSyI=; b=A0DiROFFcjgyR5EHbu7Nsdee/48xH4pzOPR4/wzrmr6A8Z6N5jA7i3AU rGGnEkDnijccq/nMyxz+gbRuAbshu+/adsOP4af9Kq29F/NxhNYLVD9Bg xTfUp0KHWCaLuoSNBy37t6zl+lMnaMl9raJVYnspWYDOxW05dnVVHVYPw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHFwBfczZV/xbLJq1bAYNdGkKDGMJ/CYFPh34UAQEBAQEBAX1BAQIChAQVQDYCBRYLAgsDAgECAUsNCAEBBYgiDacUj1WVJIEhjHqFD4FFAQSbV4cpjX8igUWCMDwxAYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,616,1422921600"; d="scan'208";a="460291520" 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; 21 Apr 2015 16:00:32 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3LG0WGX022812 for <netmod@ietf.org>; Tue, 21 Apr 2015 16:00:32 GMT Message-ID: <55367450.6060006@cisco.com> Date: Tue, 21 Apr 2015 18:01:20 +0200 From: Benoit Claise <bclaise@cisco.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: NETMOD Working Group <netmod@ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ShzvTzLG4cQWKgWXChXyIR-r0w0> Subject: [netmod] YANG Editing Session at IETF 93 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Apr 2015 16:00:50 -0000 FYI. http://www.ietf.org/meeting/93/tutorials/yang-session.html Regards, Benoit From nobody Tue Apr 21 17:38:14 2015 Return-Path: <steve.baillargeon@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEB91B2F7A for <netmod@ietfa.amsl.com>; Tue, 21 Apr 2015 17:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgoPcAf38rGW for <netmod@ietfa.amsl.com>; Tue, 21 Apr 2015 17:38:11 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2B51B2F77 for <netmod@ietf.org>; Tue, 21 Apr 2015 17:38:11 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-5b-55368a19f935 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 45.6D.17241.91A86355; Tue, 21 Apr 2015 19:34:17 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Tue, 21 Apr 2015 20:38:10 -0400 From: Steve Baillargeon <steve.baillargeon@ericsson.com> To: NETMOD Working Group <netmod@ietf.org> Thread-Topic: [netmod] New Version Notification for draft-baill-netmod-yang-ip-stats-00.txt Thread-Index: AdB8k5lShwy1kEoIT8yGFVCBiGYVqg== Date: Wed, 22 Apr 2015 00:38:09 +0000 Message-ID: <DCF22B50497F7641B6DDD16ECC516F7F3F1F12B0@eusaamb105.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyuXSPt65kl1mowYO14hbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEro/vVEdaCb3wV+1a8Zm1gPMLXxcjJISFgIvFxVQsLhC0mceHe erYuRi4OIYGjjBIrXzWxQzjLGSV+PZrDClLFJmAhsX7uMuYuRg4OEQEtiaOf5UDCwgIRErsW NTOD2CICsRITWy+zQ5ToSRzvNQIJswioSmz6e5kRxOYV8JXYfbkXzGYUkJXYffY6E4jNLCAu cevJfCaIewQkluw5zwxhi0q8fPyPFcJWkpi09BwryHhmAU2J9bv0IVoVJaZ0P2SHGC8ocXLm E5YJjMKzkEydhdAxC0nHLCQdCxhZVjFylBanluWmGxluYgSG8DEJNscdjAs+WR5iFOBgVOLh XWBnGirEmlhWXJl7iFGag0VJnLfsysEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyVf9UM TiW7TdgpdvpeggvbNGvva0+7dkREar5MmTk1x1n7xvOTCkZbHyWvsdlcyGih37NZdT2D6OH/ VvNevbWNvzurdr1Xv2Xs1Mhdh0/pRDQcz2T+I3dHYbLeta7kO5HPLNWP71A6w/WntYujbELe 7nOv0kvXP39Wtqbp3qwV2wVO/9WtFZimxFKckWioxVxUnAgApvn8LkICAAA= Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/bm5F51UOcloz_2VKRbTBTtN1DyQ> Subject: [netmod] New Version Notification for draft-baill-netmod-yang-ip-stats-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 00:38:13 -0000 SGkNCkEgbmV3IGRyYWZ0IGZvciBZQU5HIElQL0lDTVAgU3RhdGlzdGljcyBiZWVuIHB1Ymxpc2hl ZC4gDQpZb3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgYXBwcmVjaWF0ZWQuDQoNClJl Z2FyZHMNClN0ZXZlIEINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBUdWVzZGF5LCBBcHJpbCAyMSwgMjAxNSA1OjMyIFBNDQpUbzogU3RldmUgQmFpbGxhcmdl b247IFN0ZXZlIEJhaWxsYXJnZW9uDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWJhaWxsLW5ldG1vZC15YW5nLWlwLXN0YXRzLTAwLnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1iYWlsbC1uZXRtb2QteWFuZy1pcC1zdGF0cy0wMC50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3RldmUgQmFpbGxhcmdlb24gYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtYmFpbGwtbmV0bW9k LXlhbmctaXAtc3RhdHMNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlBIFlBTkcgRGF0YSBNb2RlbCBm b3IgYmFzaWMgSVAgYW5kIElDTVAgU3RhdGlzdGljcw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wNC0y MQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMzYNClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1iYWlsbC1uZXRt b2QteWFuZy1pcC1zdGF0cy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1iYWlsbC1uZXRtb2QteWFuZy1pcC1zdGF0cy8NCkh0bWxp emVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iYWlsbC1uZXRtb2Qt eWFuZy1pcC1zdGF0cy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgWUFORyBkYXRhIG1vZGVsIGZvciBiYXNpYyBJUCBhbmQgSUNNUA0KICAgc3RhdGlzdGljcyBm b3IgbW9uaXRvcmluZyBJUHY0IGFuZCBJUHY2IGltcGxlbWVudGF0aW9ucy4NCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Apr 22 06:52:31 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE07A1A9084 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 06:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwOS0XE2OXue for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 06:52:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 991221A9100 for <netmod@ietf.org>; Wed, 22 Apr 2015 06:52:25 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F2371AE0457; Wed, 22 Apr 2015 15:52:23 +0200 (CEST) Date: Wed, 22 Apr 2015 15:52:23 +0200 (CEST) Message-Id: <20150422.155223.1511113663648161770.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150417163721.GD8783@elstar.local> References: <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> <20150417.162814.885796193974027337.mbj@tail-f.com> <20150417163721.GD8783@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/3WKYdHM-dLdtW5FwDTJ6HArd0xc> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 13:52:29 -0000 Hi, Does any one else have any input to this thread? So far, we have three people in favor of Y45-04. Andy, what is your preferred solution? /martin Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Apr 17, 2015 at 04:28:14PM +0200, Martin Bjorklund wrote: > > > I am more concerned about the vendor modules that quickly get > > > really complicated, or create unintended results in the validation > > > or code generation. > > > > The worst they can do is start to use import-by revison of different > > revisions of the same module. But this just means that they > > cherry pick typedefs or groupings from specific revisions. It is at > > least clear what this means. > > > > I think this is a big improvement. While cherry picking will likely > not be needed when modules are well designed and maintained, I am > pretty sure it will be necessary to handle cases where this is not the > case (e.g., a maintainer did not forsee things correctly) or adoption > of a new version is something that is implemented gradually in a > couple of firmware releases. Being able to clearly say which grouping > or typedef is used where is a big win. Previous proposals assumed that > everything can be upgraded always in one go (in my view unrealistic) > or that definitions are simply copied and duplicated and then start a > life of their own (in my view to be avoided). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > From nobody Wed Apr 22 08:58:58 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFFC1B36D4 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 08:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du1INILFsqXP for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 08:58:55 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 3CCD81ACEA0 for <netmod@ietf.org>; Wed, 22 Apr 2015 08:58:45 -0700 (PDT) Received: by laat2 with SMTP id t2so178425402laa.1 for <netmod@ietf.org>; Wed, 22 Apr 2015 08:58:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FReBD5wE11B9URkP3G9V/XEGI19qqBaSBv0j9+SXI74=; b=QwJpTKDuYjF/aXmuvdr5L28FLI0Zi3OJAsFoTPVO5lrm+IpwzgWcvTBRmqYvQC1zYj 4IlJOXIkMAI7hNpCrLacPqh+cy6TGTeczV5siT2HBjJzHbbUyguzVsro+r72+L/s43dZ wOZb3znKa4JpT/ggbc++Yokm96IFiYMB0le7wLc7gBchQLcmN3r34Wen2Y7SKkeSfxqR qK7hLUHcJiskYQHksiJeLV/jRxzqs+tdmSBTqTtfh9WeNCPXLqzzJVufPZfJejrqv7dt TVcWynaP/JC7FJAj4NRERZ3UA8bkXGIvFIc1P3P1E6RXGL7MNQvBa6BDHMZDAPvyAMIM rjcw== X-Gm-Message-State: ALoCoQkmslz5YCjmikUTDEO6NBwwHn+HWhsEc5x0xU4gqaUB8xtPtYyz3knJW7aH+U+QCf8943wg MIME-Version: 1.0 X-Received: by 10.152.87.164 with SMTP id az4mr7162824lab.123.1429718323611; Wed, 22 Apr 2015 08:58:43 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 22 Apr 2015 08:58:43 -0700 (PDT) In-Reply-To: <20150422.155223.1511113663648161770.mbj@tail-f.com> References: <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> <20150417.162814.885796193974027337.mbj@tail-f.com> <20150417163721.GD8783@elstar.local> <20150422.155223.1511113663648161770.mbj@tail-f.com> Date: Wed, 22 Apr 2015 08:58:43 -0700 Message-ID: <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/VAHdfu9n_9XWgYfFopt-pYHTWgc> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 15:58:57 -0000 On Wed, Apr 22, 2015 at 6:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Hi, > > Does any one else have any input to this thread? So far, we have > three people in favor of Y45-04. Andy, what is your preferred > solution? > I still prefer Y45-02. The arguments that the complexity in Y45-03+04 won't get used very often apply equally to the duplicated typedefs and groupings in Y45-02, so they mean nothing. One has to assume that the full complexity allowed by the solution will be used. The really scary part is that a server just picks *some* revision to implement, and other modules can cherry-pick from revisions released after the supported one. YANG constraints and update rules do not actually support this "feature". They assume that if statement A is added to revision Y, that the server will have to implement revision Y in order to use statement A. Now when designers add new statements, they will need to take into consideration how they will behave if mixed with every possible revision of every cross-referenced statement. > > /martin Andy > > > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >> On Fri, Apr 17, 2015 at 04:28:14PM +0200, Martin Bjorklund wrote: >> > > I am more concerned about the vendor modules that quickly get >> > > really complicated, or create unintended results in the validation >> > > or code generation. >> > >> > The worst they can do is start to use import-by revison of different >> > revisions of the same module. But this just means that they >> > cherry pick typedefs or groupings from specific revisions. It is at >> > least clear what this means. >> > >> >> I think this is a big improvement. While cherry picking will likely >> not be needed when modules are well designed and maintained, I am >> pretty sure it will be necessary to handle cases where this is not the >> case (e.g., a maintainer did not forsee things correctly) or adoption >> of a new version is something that is implemented gradually in a >> couple of firmware releases. Being able to clearly say which grouping >> or typedef is used where is a big win. Previous proposals assumed that >> everything can be upgraded always in one go (in my view unrealistic) >> or that definitions are simply copied and duplicated and then start a >> life of their own (in my view to be avoided). >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> From nobody Wed Apr 22 09:18:53 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C758C1B375B for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 09:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkOc3DTDBaO0 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 09:18:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3071B3741 for <netmod@ietf.org>; Wed, 22 Apr 2015 09:18:49 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:29a6:d943:431b:2425] (unknown [IPv6:2a01:5e0:29:ffff:29a6:d943:431b:2425]) by mail.nic.cz (Postfix) with ESMTPSA id A919A140117; Wed, 22 Apr 2015 18:18:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429719527; bh=9i/P0vmR52yVKoc3nRXdc6XXVYfooSsLz+XPUqPDm0k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dA+1Hsewx7rekN5yKMfX50U7mf0MYe0Jl78nYZGFGE8sz/ecqXE3XBy15BGVNvoIJ 9flptBqwzDqiquulylyX9XpbpQpqXduSLKefVpTB+RyJ35A0ynypT9A1m5jPReeMIe wSnretL6nzsGno4C6eYV7p7u02ux6ZUaQui7+Gu8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> Date: Wed, 22 Apr 2015 18:18:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <630CF867-7F21-4844-BA6C-22E41FF0A341@nic.cz> References: <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> <20150417.162814.885796193974027337.mbj@tail-f.com> <20150417163721.GD8783@elstar.local> <20150422.155223.1511113663648161770.mbj@tail-f.com> <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> To: Andy Bierman <andy@yumaworks.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/HICLpZzLaWHb2QmvDUYNpzpyKvM> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 16:18:51 -0000 > On 22 Apr 2015, at 17:58, Andy Bierman <andy@yumaworks.com> wrote: >=20 > On Wed, Apr 22, 2015 at 6:52 AM, Martin Bjorklund <mbj@tail-f.com> = wrote: >> Hi, >>=20 >> Does any one else have any input to this thread? So far, we have >> three people in favor of Y45-04. Andy, what is your preferred >> solution? >>=20 >=20 > I still prefer Y45-02. >=20 > The arguments that the complexity in Y45-03+04 won't get used very = often > apply equally to the duplicated typedefs and groupings in Y45-02, > so they mean nothing. One has to assume that the full complexity > allowed by the solution will be used. It is different: updates to typedefs&groupings may be used relatively = often, what I think will be rarely needed are different revisions of a = module in the same importing module. Y45-02 would clutter modules even = if almost everybody is fine with the most recent revisions.=20 >=20 > The really scary part is that a server just picks *some* revision to > implement, and other modules can cherry-pick from revisions released > after the supported one. YANG constraints and update rules > do not actually support this "feature". They assume that if statement = A > is added to revision Y, that the server will have to implement = revision Y > in order to use statement A. >=20 > Now when designers add new statements, they will need to take into > consideration how they will behave if mixed with every possible > revision of every > cross-referenced statement. They can use import by revision. Lada >=20 >>=20 >> /martin >=20 > Andy >=20 >>=20 >>=20 >>=20 >>=20 >> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>> On Fri, Apr 17, 2015 at 04:28:14PM +0200, Martin Bjorklund wrote: >>>>> I am more concerned about the vendor modules that quickly get >>>>> really complicated, or create unintended results in the validation >>>>> or code generation. >>>>=20 >>>> The worst they can do is start to use import-by revison of = different >>>> revisions of the same module. But this just means that they >>>> cherry pick typedefs or groupings from specific revisions. It is = at >>>> least clear what this means. >>>>=20 >>>=20 >>> I think this is a big improvement. While cherry picking will likely >>> not be needed when modules are well designed and maintained, I am >>> pretty sure it will be necessary to handle cases where this is not = the >>> case (e.g., a maintainer did not forsee things correctly) or = adoption >>> of a new version is something that is implemented gradually in a >>> couple of firmware releases. Being able to clearly say which = grouping >>> or typedef is used where is a big win. Previous proposals assumed = that >>> everything can be upgraded always in one go (in my view unrealistic) >>> or that definitions are simply copied and duplicated and then start = a >>> life of their own (in my view to be avoided). >>>=20 >>> /js >>>=20 >>> -- >>> 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/> >>>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Apr 22 10:16:49 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED241ACD7F for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 10:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84Zjg8uBgzBI for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 10:16:46 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43CA1AD34D for <netmod@ietf.org>; Wed, 22 Apr 2015 10:16:43 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so185452714lbb.2 for <netmod@ietf.org>; Wed, 22 Apr 2015 10:16:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vVR9dWFazTmKW4+6q6OPxdXfZfy1AoUSbahFALfkI5k=; b=jVkjy0PK/TAhYyHCtmkS1nI5hTGp4Y57nxxorwpVeHzXb8GR25/qzz7VfQCmD6mvfw H7pleXkfY+vZshNDWDBeJYe5WIihcg5HMOQ7GF1QbL4EzgcLwpnGwQcwG4QpgM03u6Dd E20zrJlg0Aqnyb3R7DygDrTzcZUZ3iy1LF4L5Ze9vgVJoLd98z6ntnRBn5PrTnqWsX6D nL0JQR6s4ehCHo0YSv+xohYxymesiuEUVviyB045YB2q6vRgfBOMkuIUPZzz0lNVkGpp qbDou+HU7gnB8dY/e1LzKT3pOax8vFs5AiE886rfzlNtkuXlvRHY8sowAtvzxmP1iOZU b/Jw== X-Gm-Message-State: ALoCoQnDCgwNb6hVEyaXL+ualzQ5Vmeu80Z9HjPFAlZrqLAO7Vq/BL7KRQ2t2Bit3Hvn0BD5khNg MIME-Version: 1.0 X-Received: by 10.152.87.233 with SMTP id bb9mr564794lab.38.1429723002145; Wed, 22 Apr 2015 10:16:42 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 22 Apr 2015 10:16:42 -0700 (PDT) In-Reply-To: <630CF867-7F21-4844-BA6C-22E41FF0A341@nic.cz> References: <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> <20150417.162814.885796193974027337.mbj@tail-f.com> <20150417163721.GD8783@elstar.local> <20150422.155223.1511113663648161770.mbj@tail-f.com> <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> <630CF867-7F21-4844-BA6C-22E41FF0A341@nic.cz> Date: Wed, 22 Apr 2015 10:16:42 -0700 Message-ID: <CABCOCHT_QXM0Ws7mYMWcRu+Cn4qxW9C-8ibXpXxTPhaAStExyQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/iVTR1Y-umqLdQAyo15mpJX0rPGw> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 17:16:48 -0000 On Wed, Apr 22, 2015 at 9:18 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > >> On 22 Apr 2015, at 17:58, Andy Bierman <andy@yumaworks.com> wrote: >> >> On Wed, Apr 22, 2015 at 6:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote= : >>> Hi, >>> >>> Does any one else have any input to this thread? So far, we have >>> three people in favor of Y45-04. Andy, what is your preferred >>> solution? >>> >> >> I still prefer Y45-02. >> >> The arguments that the complexity in Y45-03+04 won't get used very often >> apply equally to the duplicated typedefs and groupings in Y45-02, >> so they mean nothing. One has to assume that the full complexity >> allowed by the solution will be used. > > It is different: updates to typedefs&groupings may be used relatively oft= en, what I think will be rarely needed are different revisions of a module = in the same importing module. Y45-02 would clutter modules even if almost e= verybody is fine with the most recent revisions. > This is complete speculation on your part. There is no evidence at all of typedefs and groupings expanding from RFC to RFC. IANA maintained modules do not count. I-D to I-D changes do not count. >> >> The really scary part is that a server just picks *some* revision to >> implement, and other modules can cherry-pick from revisions released >> after the supported one. YANG constraints and update rules >> do not actually support this "feature". They assume that if statement A >> is added to revision Y, that the server will have to implement revision = Y >> in order to use statement A. >> >> Now when designers add new statements, they will need to take into >> consideration how they will behave if mixed with every possible >> revision of every >> cross-referenced statement. > > They can use import by revision. Or they can choose not to use it. We assume everybody will just know when to choose one instead of the other. > > Lada Andy > >> >>> >>> /martin >> >> Andy >> >>> >>> >>> >>> >>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>> On Fri, Apr 17, 2015 at 04:28:14PM +0200, Martin Bjorklund wrote: >>>>>> I am more concerned about the vendor modules that quickly get >>>>>> really complicated, or create unintended results in the validation >>>>>> or code generation. >>>>> >>>>> The worst they can do is start to use import-by revison of different >>>>> revisions of the same module. But this just means that they >>>>> cherry pick typedefs or groupings from specific revisions. It is at >>>>> least clear what this means. >>>>> >>>> >>>> I think this is a big improvement. While cherry picking will likely >>>> not be needed when modules are well designed and maintained, I am >>>> pretty sure it will be necessary to handle cases where this is not the >>>> case (e.g., a maintainer did not forsee things correctly) or adoption >>>> of a new version is something that is implemented gradually in a >>>> couple of firmware releases. Being able to clearly say which grouping >>>> or typedef is used where is a big win. Previous proposals assumed that >>>> everything can be upgraded always in one go (in my view unrealistic) >>>> or that definitions are simply copied and duplicated and then start a >>>> life of their own (in my view to be avoided). >>>> >>>> /js >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >>>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Wed Apr 22 11:14:08 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59E61A6FF1 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qUdd1ST111F for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:14:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B921A1B78 for <netmod@ietf.org>; Wed, 22 Apr 2015 11:14:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 55D471DE1; Wed, 22 Apr 2015 20:14:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id r5bSgddpjf7S; Wed, 22 Apr 2015 20:13:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Apr 2015 20:13:58 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A63BA2002B; Wed, 22 Apr 2015 20:13:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wl-9EQc02kfm; Wed, 22 Apr 2015 20:13:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 703F420013; Wed, 22 Apr 2015 20:13:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B4EDF32CC35D; Wed, 22 Apr 2015 20:13:56 +0200 (CEST) Date: Wed, 22 Apr 2015 20:13:56 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150422181356.GG982@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> <20150417.162814.885796193974027337.mbj@tail-f.com> <20150417163721.GD8783@elstar.local> <20150422.155223.1511113663648161770.mbj@tail-f.com> <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/9bqqndCBi37lyPorCMk0kM_zjeg> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 18:14:06 -0000 On Wed, Apr 22, 2015 at 08:58:43AM -0700, Andy Bierman wrote: > On Wed, Apr 22, 2015 at 6:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > Hi, > > > > Does any one else have any input to this thread? So far, we have > > three people in favor of Y45-04. Andy, what is your preferred > > solution? > > > > I still prefer Y45-02. > > The arguments that the complexity in Y45-03+04 won't get used very often > apply equally to the duplicated typedefs and groupings in Y45-02, > so they mean nothing. One has to assume that the full complexity > allowed by the solution will be used. > > The really scary part is that a server just picks *some* revision to > implement, and other modules can cherry-pick from revisions released > after the supported one. YANG constraints and update rules > do not actually support this "feature". They assume that if statement A > is added to revision Y, that the server will have to implement revision Y > in order to use statement A. We are primarily talking about typedefs and groupings and as a matter of fact, you implement them in the module that is importing them. I generally do not implement ietf-inet-types, modules that implement something imported from ietf-inet-types implement stuff. Y45-04 makes it clear what a module that imported from ietf-inet-types implements and it allows gradual updates (instead of forcing everything to import from a single revision of ietf-inet-types). The alternative, Y45-02, requires that any semantic changes to typedefs or groupings requires to define a new typedef/grouping with a new name. In particular, you can't add an enum to an enumeration anymore. This breaks for example RFC 6643 (since SMIv2 do allow to add enums). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Wed Apr 22 11:20:22 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0D61AD0B5 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwbBMTgJJzQt for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:20:18 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12A11AD0A1 for <netmod@ietf.org>; Wed, 22 Apr 2015 11:20:02 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so186767362lbb.2 for <netmod@ietf.org>; Wed, 22 Apr 2015 11:20:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b+M4gBur9kYdyPmFdOiVu4jhM2bfTIMm8mBewMEAtJA=; b=It2If+/SQ2LXxJADEtwoYTKQrLvdjlIYhAfeVXQMO3P3e6lpVfokfQzPh+cXdter8K 7sMk+LkZtHlfCJNE2WQVMZqn9ifdwK3McuKxdTdv7XQTzyN7n+rSglM9V+EY9VqPc3l+ 52WZIqIWiJyHQw+K96/W2S5y/ABNFdmyidlcucZPANtuhlamfF8pHpR2E0sozBTVbpkG zHVTMhrCCBG5xhfOxbIouJBnOtLQ0XBXp++O72gtiLyR622kuiUsDVwhoMYgsbShOUcE E87O5/+LaVstb12n9hOxpiaAmBfKC6qBNXUrn/tCIOMROyoj9vd2FsQV6YQeiSPc1G9i Pckw== X-Gm-Message-State: ALoCoQnozPNaAkP8GLFZqBaTtcTRPIzN+FQziZpquw9+MkI8SVOnnfNQ2MATAHH1dwWohVyZEqwa MIME-Version: 1.0 X-Received: by 10.152.87.164 with SMTP id az4mr7699246lab.123.1429726801272; Wed, 22 Apr 2015 11:20:01 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 22 Apr 2015 11:20:01 -0700 (PDT) In-Reply-To: <630CF867-7F21-4844-BA6C-22E41FF0A341@nic.cz> References: <CABCOCHRMaHDpLsPobVwzWbHuOJsfUq+N1bL6GxyaHL6uCh-vug@mail.gmail.com> <20150417.162814.885796193974027337.mbj@tail-f.com> <20150417163721.GD8783@elstar.local> <20150422.155223.1511113663648161770.mbj@tail-f.com> <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> <630CF867-7F21-4844-BA6C-22E41FF0A341@nic.cz> Date: Wed, 22 Apr 2015 11:20:01 -0700 Message-ID: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/svWWMRZPK5s_QIrT-03HgrfYXyM> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 18:20:20 -0000 Hi, I am curious how the solution proposal deals with augments for nodes that don't exist yet: module base { ... revision 2014-01-01; leaf foo { type string; } } module base { ... revision 2015-01-01; typedef XXX { type int32; } leaf foo { type string; } container bar; } module aug1 { ... import base { prefix b; revision-date 2015-01-01; } revision 2015-03-03; leaf Y { must ../b:bar/aug1:baz; type b:XXX; } augment /b:bar { leaf baz { type int32; } } } Let's say the server implements base@2014-01-01, and also implements aug1@2015-03-03? This module augments container /bar, which does not exist in the version supported by the server. The designer of "aug1" clearly intends to use base@2015-01-01 (hence import-by-revision). Since the server picked the old version of 'base', the augment /b:bar is invalid and the must-stmt for /Y will always be false. Cherry-picking the XXX typedef does not really help. That is allowed but the /Y leaf is still broken. Andy On Wed, Apr 22, 2015 at 9:18 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > >> On 22 Apr 2015, at 17:58, Andy Bierman <andy@yumaworks.com> wrote: >> >> On Wed, Apr 22, 2015 at 6:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote= : >>> Hi, >>> >>> Does any one else have any input to this thread? So far, we have >>> three people in favor of Y45-04. Andy, what is your preferred >>> solution? >>> >> >> I still prefer Y45-02. >> >> The arguments that the complexity in Y45-03+04 won't get used very often >> apply equally to the duplicated typedefs and groupings in Y45-02, >> so they mean nothing. One has to assume that the full complexity >> allowed by the solution will be used. > > It is different: updates to typedefs&groupings may be used relatively oft= en, what I think will be rarely needed are different revisions of a module = in the same importing module. Y45-02 would clutter modules even if almost e= verybody is fine with the most recent revisions. > >> >> The really scary part is that a server just picks *some* revision to >> implement, and other modules can cherry-pick from revisions released >> after the supported one. YANG constraints and update rules >> do not actually support this "feature". They assume that if statement A >> is added to revision Y, that the server will have to implement revision = Y >> in order to use statement A. >> >> Now when designers add new statements, they will need to take into >> consideration how they will behave if mixed with every possible >> revision of every >> cross-referenced statement. > > They can use import by revision. > > Lada > >> >>> >>> /martin >> >> Andy >> >>> >>> >>> >>> >>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>> On Fri, Apr 17, 2015 at 04:28:14PM +0200, Martin Bjorklund wrote: >>>>>> I am more concerned about the vendor modules that quickly get >>>>>> really complicated, or create unintended results in the validation >>>>>> or code generation. >>>>> >>>>> The worst they can do is start to use import-by revison of different >>>>> revisions of the same module. But this just means that they >>>>> cherry pick typedefs or groupings from specific revisions. It is at >>>>> least clear what this means. >>>>> >>>> >>>> I think this is a big improvement. While cherry picking will likely >>>> not be needed when modules are well designed and maintained, I am >>>> pretty sure it will be necessary to handle cases where this is not the >>>> case (e.g., a maintainer did not forsee things correctly) or adoption >>>> of a new version is something that is implemented gradually in a >>>> couple of firmware releases. Being able to clearly say which grouping >>>> or typedef is used where is a big win. Previous proposals assumed that >>>> everything can be upgraded always in one go (in my view unrealistic) >>>> or that definitions are simply copied and duplicated and then start a >>>> life of their own (in my view to be avoided). >>>> >>>> /js >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >>>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Wed Apr 22 11:50:52 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC98E1A877F for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPs6j_NWlgYR for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:50:49 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A167C1B29CF for <netmod@ietf.org>; Wed, 22 Apr 2015 11:50:42 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 4C3951AE0457; Wed, 22 Apr 2015 20:50:41 +0200 (CEST) Date: Wed, 22 Apr 2015 20:52:08 +0200 (CEST) Message-Id: <20150422.205208.1181266232792526869.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> References: <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> <630CF867-7F21-4844-BA6C-22E41FF0A341@nic.cz> <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/7yt8SwScLoNDt1J2aMfk6N-5gWA> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 18:50:51 -0000 Andy Bierman <andy@yumaworks.com> wrote: > Hi, > > I am curious how the solution proposal deals with augments > for nodes that don't exist yet: > > > module base { > ... > revision 2014-01-01; > > leaf foo { type string; } > > } > > > module base { > ... > revision 2015-01-01; > > typedef XXX { type int32; } > > leaf foo { type string; } > > container bar; > > } > > > module aug1 { > ... > import base { prefix b; revision-date 2015-01-01; } > revision 2015-03-03; > > leaf Y { > must ../b:bar/aug1:baz; > type b:XXX; > } > > augment /b:bar { > leaf baz { type int32; } > } > } > > Let's say the server implements base@2014-01-01, > and also implements aug1@2015-03-03? This isn't allowed, since the augment implies a run-time dependency - the server MUST implement a version of "base" where the node "/bar" exists. /martin > This module augments container /bar, which does not exist in > the version supported by the server. The designer of "aug1" > clearly intends to use base@2015-01-01 (hence import-by-revision). > > Since the server picked the old version of 'base', the augment /b:bar > is invalid and the must-stmt for /Y will always be false. > Cherry-picking the XXX typedef does not really help. > That is allowed but the /Y leaf is still broken. > > > Andy > > > > > On Wed, Apr 22, 2015 at 9:18 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > > >> On 22 Apr 2015, at 17:58, Andy Bierman <andy@yumaworks.com> wrote: > >> > >> On Wed, Apr 22, 2015 at 6:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > >>> Hi, > >>> > >>> Does any one else have any input to this thread? So far, we have > >>> three people in favor of Y45-04. Andy, what is your preferred > >>> solution? > >>> > >> > >> I still prefer Y45-02. > >> > >> The arguments that the complexity in Y45-03+04 won't get used very often > >> apply equally to the duplicated typedefs and groupings in Y45-02, > >> so they mean nothing. One has to assume that the full complexity > >> allowed by the solution will be used. > > > > It is different: updates to typedefs&groupings may be used relatively often, what I think will be rarely needed are different revisions of a module in the same importing module. Y45-02 would clutter modules even if almost everybody is fine with the most recent revisions. > > > >> > >> The really scary part is that a server just picks *some* revision to > >> implement, and other modules can cherry-pick from revisions released > >> after the supported one. YANG constraints and update rules > >> do not actually support this "feature". They assume that if statement A > >> is added to revision Y, that the server will have to implement revision Y > >> in order to use statement A. > >> > >> Now when designers add new statements, they will need to take into > >> consideration how they will behave if mixed with every possible > >> revision of every > >> cross-referenced statement. > > > > They can use import by revision. > > > > Lada > > > >> > >>> > >>> /martin > >> > >> Andy > >> > >>> > >>> > >>> > >>> > >>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > >>>> On Fri, Apr 17, 2015 at 04:28:14PM +0200, Martin Bjorklund wrote: > >>>>>> I am more concerned about the vendor modules that quickly get > >>>>>> really complicated, or create unintended results in the validation > >>>>>> or code generation. > >>>>> > >>>>> The worst they can do is start to use import-by revison of different > >>>>> revisions of the same module. But this just means that they > >>>>> cherry pick typedefs or groupings from specific revisions. It is at > >>>>> least clear what this means. > >>>>> > >>>> > >>>> I think this is a big improvement. While cherry picking will likely > >>>> not be needed when modules are well designed and maintained, I am > >>>> pretty sure it will be necessary to handle cases where this is not the > >>>> case (e.g., a maintainer did not forsee things correctly) or adoption > >>>> of a new version is something that is implemented gradually in a > >>>> couple of firmware releases. Being able to clearly say which grouping > >>>> or typedef is used where is a big win. Previous proposals assumed that > >>>> everything can be upgraded always in one go (in my view unrealistic) > >>>> or that definitions are simply copied and duplicated and then start a > >>>> life of their own (in my view to be avoided). > >>>> > >>>> /js > >>>> > >>>> -- > >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > >>>> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > From nobody Wed Apr 22 11:53:44 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E241B29E3 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KywDkBqyedej for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:53:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 05DC71B29DB for <netmod@ietf.org>; Wed, 22 Apr 2015 11:53:34 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 467211AE0457; Wed, 22 Apr 2015 20:53:33 +0200 (CEST) Date: Wed, 22 Apr 2015 20:55:00 +0200 (CEST) Message-Id: <20150422.205500.724381137955217423.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHT_QXM0Ws7mYMWcRu+Cn4qxW9C-8ibXpXxTPhaAStExyQ@mail.gmail.com> References: <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> <630CF867-7F21-4844-BA6C-22E41FF0A341@nic.cz> <CABCOCHT_QXM0Ws7mYMWcRu+Cn4qxW9C-8ibXpXxTPhaAStExyQ@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/MBPbaHbPuL2DVJq2-w67D9SSslo> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 18:53:42 -0000 Andy Bierman <andy@yumaworks.com> wrote: > On Wed, Apr 22, 2015 at 9:18 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > > >> On 22 Apr 2015, at 17:58, Andy Bierman <andy@yumaworks.com> wrote: > >> > >> On Wed, Apr 22, 2015 at 6:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > >>> Hi, > >>> > >>> Does any one else have any input to this thread? So far, we have > >>> three people in favor of Y45-04. Andy, what is your preferred > >>> solution? > >>> > >> > >> I still prefer Y45-02. Y45-02 is the biggest change compared with YANG 1.0. > >> The arguments that the complexity in Y45-03+04 won't get used very often > >> apply equally to the duplicated typedefs and groupings in Y45-02, > >> so they mean nothing. One has to assume that the full complexity > >> allowed by the solution will be used. > > > > It is different: updates to typedefs&groupings may be used > relatively often, what I think will be rarely needed are different > revisions of a module in the same importing module. Y45-02 would > clutter modules even if almost everybody is fine with the most > recent revisions. +1 > This is complete speculation on your part. > There is no evidence at all of typedefs and groupings > expanding from RFC to RFC. IANA maintained modules > do not count. Why wouldn't IANA maintained modules count? Are you proposing to have different upgrade rules for modules maintained by IANA? /martin From nobody Wed Apr 22 11:58:31 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1837D1B29E2 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 481PzmOtF994 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 11:58:29 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 BD96F1AD49B for <netmod@ietf.org>; Wed, 22 Apr 2015 11:58:28 -0700 (PDT) Received: by lagv1 with SMTP id v1so182213526lag.3 for <netmod@ietf.org>; Wed, 22 Apr 2015 11:58:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZibFhukDb2Bm4ILHmPtKSEEqbfqslMFkC75MnCEulWk=; b=ggRvU8TJgr8zfhHSEwbd1smzWKKwRblv/4LkzMlClgfdSEuFjltjXfZGDH6w07X8/f KHBbgbRihTWuJcvNwvm9AIeUY74vZs9sQVai50exUbBhAAw4AnKyBDoJ5y39Kw4MnNZf TTBrG4zqRAMD6b/4ke96yV1AS+ZnhE7YoKReX3HBrCg+YD9vGYgJj9rjTVQ6T5JpGmrt gjdl91UEm8Z7FVcmyywUJpbFwPAmKT97VbhHeaspy48rht9p1yKni4a29dnWNl2ZY2Cq HidQ48HJEKMXkDqydmU+mkrHCLl8TUuVsguqYmESCDEByvJ+VXGhQvdvORVHKWcuqSs4 dSFg== X-Gm-Message-State: ALoCoQnt+hoSPoaox2rMpLrL9o1vdwh1gzUJ7ZpK+09wade/PwyCFqRolAjPTyb1F2LA3P7MhPBm MIME-Version: 1.0 X-Received: by 10.152.42.141 with SMTP id o13mr26157563lal.33.1429729107143; Wed, 22 Apr 2015 11:58:27 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 22 Apr 2015 11:58:27 -0700 (PDT) In-Reply-To: <20150422.205208.1181266232792526869.mbj@tail-f.com> References: <CABCOCHR+hq8gN1Z4MgPNWXFytjHb0fwA5jcf0nM_VUKekxjyXA@mail.gmail.com> <630CF867-7F21-4844-BA6C-22E41FF0A341@nic.cz> <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> Date: Wed, 22 Apr 2015 11:58:27 -0700 Message-ID: <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ekaspW8b21NeNlWnqJn6p-xOd4g> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 18:58:31 -0000 On Wed, Apr 22, 2015 at 11:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Andy Bierman <andy@yumaworks.com> wrote: >> Hi, >> >> I am curious how the solution proposal deals with augments >> for nodes that don't exist yet: >> >> >> module base { >> ... >> revision 2014-01-01; >> >> leaf foo { type string; } >> >> } >> >> >> module base { >> ... >> revision 2015-01-01; >> >> typedef XXX { type int32; } >> >> leaf foo { type string; } >> >> container bar; >> >> } >> >> >> module aug1 { >> ... >> import base { prefix b; revision-date 2015-01-01; } >> revision 2015-03-03; >> >> leaf Y { >> must ../b:bar/aug1:baz; >> type b:XXX; >> } >> >> augment /b:bar { >> leaf baz { type int32; } >> } >> } >> >> Let's say the server implements base@2014-01-01, >> and also implements aug1@2015-03-03? > > This isn't allowed, since the augment implies a run-time dependency - > the server MUST implement a version of "base" where the node "/bar" > exists. > > Where does it say this is not allowed? So the server cannot just pick a revision of "base". It must be aware of all the other modules that use "base" and make sure all modules work together? > /martin > Andy > > >> This module augments container /bar, which does not exist in >> the version supported by the server. The designer of "aug1" >> clearly intends to use base@2015-01-01 (hence import-by-revision). >> >> Since the server picked the old version of 'base', the augment /b:bar >> is invalid and the must-stmt for /Y will always be false. >> Cherry-picking the XXX typedef does not really help. >> That is allowed but the /Y leaf is still broken. >> >> >> Andy >> >> >> >> >> On Wed, Apr 22, 2015 at 9:18 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: >> > >> >> On 22 Apr 2015, at 17:58, Andy Bierman <andy@yumaworks.com> wrote: >> >> >> >> On Wed, Apr 22, 2015 at 6:52 AM, Martin Bjorklund <mbj@tail-f.com> wr= ote: >> >>> Hi, >> >>> >> >>> Does any one else have any input to this thread? So far, we have >> >>> three people in favor of Y45-04. Andy, what is your preferred >> >>> solution? >> >>> >> >> >> >> I still prefer Y45-02. >> >> >> >> The arguments that the complexity in Y45-03+04 won't get used very of= ten >> >> apply equally to the duplicated typedefs and groupings in Y45-02, >> >> so they mean nothing. One has to assume that the full complexity >> >> allowed by the solution will be used. >> > >> > It is different: updates to typedefs&groupings may be used relatively = often, what I think will be rarely needed are different revisions of a modu= le in the same importing module. Y45-02 would clutter modules even if almos= t everybody is fine with the most recent revisions. >> > >> >> >> >> The really scary part is that a server just picks *some* revision to >> >> implement, and other modules can cherry-pick from revisions released >> >> after the supported one. YANG constraints and update rules >> >> do not actually support this "feature". They assume that if statement= A >> >> is added to revision Y, that the server will have to implement revisi= on Y >> >> in order to use statement A. >> >> >> >> Now when designers add new statements, they will need to take into >> >> consideration how they will behave if mixed with every possible >> >> revision of every >> >> cross-referenced statement. >> > >> > They can use import by revision. >> > >> > Lada >> > >> >> >> >>> >> >>> /martin >> >> >> >> Andy >> >> >> >>> >> >>> >> >>> >> >>> >> >>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >> >>>> On Fri, Apr 17, 2015 at 04:28:14PM +0200, Martin Bjorklund wrote: >> >>>>>> I am more concerned about the vendor modules that quickly get >> >>>>>> really complicated, or create unintended results in the validatio= n >> >>>>>> or code generation. >> >>>>> >> >>>>> The worst they can do is start to use import-by revison of differe= nt >> >>>>> revisions of the same module. But this just means that they >> >>>>> cherry pick typedefs or groupings from specific revisions. It is = at >> >>>>> least clear what this means. >> >>>>> >> >>>> >> >>>> I think this is a big improvement. While cherry picking will likely >> >>>> not be needed when modules are well designed and maintained, I am >> >>>> pretty sure it will be necessary to handle cases where this is not = the >> >>>> case (e.g., a maintainer did not forsee things correctly) or adopti= on >> >>>> of a new version is something that is implemented gradually in a >> >>>> couple of firmware releases. Being able to clearly say which groupi= ng >> >>>> or typedef is used where is a big win. Previous proposals assumed t= hat >> >>>> everything can be upgraded always in one go (in my view unrealistic= ) >> >>>> or that definitions are simply copied and duplicated and then start= a >> >>>> life of their own (in my view to be avoided). >> >>>> >> >>>> /js >> >>>> >> >>>> -- >> >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any >> >>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> >>>> >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> > >> > >> > >> > >> From nobody Wed Apr 22 12:04:00 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE02C1B2A06 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 12:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPUMcqUtAf2H for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 12:03:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 323C31B392B for <netmod@ietf.org>; Wed, 22 Apr 2015 12:03:38 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C7A41AE0457; Wed, 22 Apr 2015 21:03:37 +0200 (CEST) Date: Wed, 22 Apr 2015 21:05:04 +0200 (CEST) Message-Id: <20150422.210504.631639827959853956.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/1h6DbvOGczGR8Tu5SkVafpYkc-o> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 19:03:58 -0000 Andy Bierman <andy@yumaworks.com> wrote: > On Wed, Apr 22, 2015 at 11:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > Andy Bierman <andy@yumaworks.com> wrote: > >> Hi, > >> > >> I am curious how the solution proposal deals with augments > >> for nodes that don't exist yet: > >> > >> > >> module base { > >> ... > >> revision 2014-01-01; > >> > >> leaf foo { type string; } > >> > >> } > >> > >> > >> module base { > >> ... > >> revision 2015-01-01; > >> > >> typedef XXX { type int32; } > >> > >> leaf foo { type string; } > >> > >> container bar; > >> > >> } > >> > >> > >> module aug1 { > >> ... > >> import base { prefix b; revision-date 2015-01-01; } > >> revision 2015-03-03; > >> > >> leaf Y { > >> must ../b:bar/aug1:baz; > >> type b:XXX; > >> } > >> > >> augment /b:bar { > >> leaf baz { type int32; } > >> } > >> } > >> > >> Let's say the server implements base@2014-01-01, > >> and also implements aug1@2015-03-03? > > > > This isn't allowed, since the augment implies a run-time dependency - > > the server MUST implement a version of "base" where the node "/bar" > > exists. > > > > > > Where does it say this is not allowed? If a server implements a module A that imports B, and A augments B or has a leafref to a node in B, the server MUST implement *some version* of module B that has the nodes A references. This is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ regardless of A imports B by revision or not. The whole idea is to decouple the revision-date used in the import in order to fix the typedef from the version needed for augment. > So the server cannot just pick a revision of "base". > It must be aware of all the other modules that use "base" > and make sure all modules work together? Right. This is not different from how it works in YANG 1.0. /martin From nobody Wed Apr 22 16:06:30 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D57B1B3B5D for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 16:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2HCo9WDwLXe for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 16:06:27 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 637881B3B50 for <netmod@ietf.org>; Wed, 22 Apr 2015 16:06:14 -0700 (PDT) Received: by laat2 with SMTP id t2so824339laa.1 for <netmod@ietf.org>; Wed, 22 Apr 2015 16:06:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dSZnKkUQqNhFBNsIq+bQl7GztRtxXYZ/IIXexMaF+Jo=; b=Jcucb4MAdR8H3r79iFoYxLZ1JW4WOOGi4ObFJS0IMaZPf8NXddyNakmfqm66yEr9H4 IO3/Y9hcytIBV3tzptGpS3TkMgq4CKPpsa3ngXUADwOiQT0nUpeWKHfJ9MWz36rzWGHX +JDkozeSKan2qunMadxlChWkEPcuvOlEPEaEnx+zJr8HFV/MUh8K0SuulYH7AMiD/sts kXjU1dkfwAFBTEw+D1fpEPCdaI44kr766VrMf5ZUIZy6Qr4blh04ucihMxgRL8Ur18Fw L4XaKNTiIGiMhgMhq804PgXyVLE5WS0jm5SdqAedThh71/5iIX6GrhISGWQeEm+40LZ0 rfQA== X-Gm-Message-State: ALoCoQlTF97+TbVaZwjE4JV8hlK/3bKOOCsGO9vR9QiY+L2Khq2f2/xTsrWeutPwUn1m+iPqtZQA MIME-Version: 1.0 X-Received: by 10.112.56.42 with SMTP id x10mr26959313lbp.123.1429743972855; Wed, 22 Apr 2015 16:06:12 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 22 Apr 2015 16:06:12 -0700 (PDT) In-Reply-To: <20150422.210504.631639827959853956.mbj@tail-f.com> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> Date: Wed, 22 Apr 2015 16:06:12 -0700 Message-ID: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Gy0GBfn8I9K8wyBk-y1JfsPE2Yg> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 23:06:29 -0000 .... >> >> Where does it say this is not allowed? > > If a server implements a module A that imports B, and A augments B > or has a leafref to a node in B, the server MUST implement *some > version* of module B that has the nodes A references. This is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > regardless of A imports B by revision or not. > > > The whole idea is to decouple the revision-date used in the import in > order to fix the typedef from the version needed for augment. > This is the part that will really confuse users. For augment-stmts, the revision-date is ignored in import-by-revision. IMO this will not work well because the designer will write a module expecting the augmented module to be the one specified by import-by-revision. If 2 or more modules augment different versions of the /bar container over time at least 1 of them will be applied to the wrong version of the augmented module. This will cause unpredictable results because YANG statements can interact in complex ways (e.g., must/when). >> So the server cannot just pick a revision of "base". >> It must be aware of all the other modules that use "base" >> and make sure all modules work together? > > Right. This is not different from how it works in YANG 1.0. > IMO importing multiple revisions at once and picking typedefs and groupings from revisions ahead of the supported one makes this problem much worse. > > /martin Andy From nobody Wed Apr 22 16:25:11 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08151B2B36 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 16:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usr2rptGNgMk for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 16:25:08 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D8B1B2B45 for <netmod@ietf.org>; Wed, 22 Apr 2015 16:25:07 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so1071826lbb.2 for <netmod@ietf.org>; Wed, 22 Apr 2015 16:25:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KzfY7wK4kg+z6K9cPEgYKAOgHdDDKkDLrKA/KdzeNBA=; b=GkadLNvmkn69M8oc6K7hN0IhgMA5FVSZruotQ6TAUUkKH0ABX3GFdjn7cqbv21D37S LNMZXGhwvJaBOM4avfKzCOHRlBV/l4VHqyiSvfoSKqOe6Tv3DpMIRd9THI3zYUavQUqn tIpYDkmJ/P3BP0Fc4ArmUoUk8EnoCnyqEjd5MZ4/ZGm2vtgzboEyRASo5yGPq+kvryP0 H8AphIeqv7Gs+wN4Ch4+xz4xNybGM1H0I8yjA5UMklajjX9AIxAlwxs0zMG0/SSf2yui 0joTQfwjTFP0AO/3uUbqDA2si1ktm522vpk/ms3t7Cb+IW4hKIbJf6o5Y8SV+Cp/eHxG VfqA== X-Gm-Message-State: ALoCoQlQwggEZLUT7eBwqAwKIdUAfIgvACw8pFv86XVJ73vD7DaXV2ewYk8GNWLzLYtA7kw1/Xht MIME-Version: 1.0 X-Received: by 10.152.42.141 with SMTP id o13mr26991334lal.33.1429745106346; Wed, 22 Apr 2015 16:25:06 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 22 Apr 2015 16:25:06 -0700 (PDT) In-Reply-To: <20150422.210504.631639827959853956.mbj@tail-f.com> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> Date: Wed, 22 Apr 2015 16:25:06 -0700 Message-ID: <CABCOCHTCWiNwqjkwPcaU-ej-9-FUV6h87h74+U8438EVY-igPg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/GTMZw9ff_el0HRM3PUJEZHLsybM> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Apr 2015 23:25:10 -0000 Hi, What is the use-case for allowing "some version" vs. the "most recent" as the supported version, from the set of versions in use by a given server. I understand the need for existing modules to freeze their imports to prevent typedef and grouping drift. These modules can use import-by-revision, and keep using older typedefs/groupings, even as the exporter module is updated. I don't think a vendor should be allowed to pick some statements from a newer version, and not implement that version of the module (i.e., all base module protocol-accessible objects). When vendors or SDOs write YANG modules with import-by-revision, these modules will be designed to integrate with the expected version. Results with vendor-selected back-revs will not be predictable. Andy On Wed, Apr 22, 2015 at 12:05 PM, Martin Bjorklund <mbj@tail-f.com> wrote: > Andy Bierman <andy@yumaworks.com> wrote: >> On Wed, Apr 22, 2015 at 11:52 AM, Martin Bjorklund <mbj@tail-f.com> wrote: >> > Andy Bierman <andy@yumaworks.com> wrote: >> >> Hi, >> >> >> >> I am curious how the solution proposal deals with augments >> >> for nodes that don't exist yet: >> >> >> >> >> >> module base { >> >> ... >> >> revision 2014-01-01; >> >> >> >> leaf foo { type string; } >> >> >> >> } >> >> >> >> >> >> module base { >> >> ... >> >> revision 2015-01-01; >> >> >> >> typedef XXX { type int32; } >> >> >> >> leaf foo { type string; } >> >> >> >> container bar; >> >> >> >> } >> >> >> >> >> >> module aug1 { >> >> ... >> >> import base { prefix b; revision-date 2015-01-01; } >> >> revision 2015-03-03; >> >> >> >> leaf Y { >> >> must ../b:bar/aug1:baz; >> >> type b:XXX; >> >> } >> >> >> >> augment /b:bar { >> >> leaf baz { type int32; } >> >> } >> >> } >> >> >> >> Let's say the server implements base@2014-01-01, >> >> and also implements aug1@2015-03-03? >> > >> > This isn't allowed, since the augment implies a run-time dependency - >> > the server MUST implement a version of "base" where the node "/bar" >> > exists. >> > >> > >> >> Where does it say this is not allowed? > > If a server implements a module A that imports B, and A augments B > or has a leafref to a node in B, the server MUST implement *some > version* of module B that has the nodes A references. This is > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > regardless of A imports B by revision or not. > > > The whole idea is to decouple the revision-date used in the import in > order to fix the typedef from the version needed for augment. > >> So the server cannot just pick a revision of "base". >> It must be aware of all the other modules that use "base" >> and make sure all modules work together? > > Right. This is not different from how it works in YANG 1.0. > > > /martin From nobody Wed Apr 22 23:24:44 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398BD1A8BB5 for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 23:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH4A2gu74hGM for <netmod@ietfa.amsl.com>; Wed, 22 Apr 2015 23:24:40 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE11A8AF9 for <netmod@ietf.org>; Wed, 22 Apr 2015 23:24:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 323681AE046D; Thu, 23 Apr 2015 08:24:20 +0200 (CEST) Date: Thu, 23 Apr 2015 08:24:20 +0200 (CEST) Message-Id: <20150423.082420.1625646335358043694.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHTCWiNwqjkwPcaU-ej-9-FUV6h87h74+U8438EVY-igPg@mail.gmail.com> References: <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHTCWiNwqjkwPcaU-ej-9-FUV6h87h74+U8438EVY-igPg@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Son1PlQTeRC3kV4aTeijPdPA7Ac> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 06:24:42 -0000 Andy Bierman <andy@yumaworks.com> wrote: > Hi, > > What is the use-case for allowing "some version" vs. > the "most recent" as the supported version, from the > set of versions in use by a given server. Just to make sure we mean the same thing, here's an example: a@2000-01-02 imports by-revision b@2000-01-02 and uses a typedef from b@2000-01-02 You're asking about a server that implements and advertises: A: a@2000-01-02 b@2000-01-01 <-- NOTE: previous version of b A server that implements and advertises: B: a@2000-01-02 b@2000-01-02 or maybe even C: a@2000-01-02 b@2000-01-03 are OK. If it turns out that A is problematic, it is fine with me to make it illegal. (but currently I don't see how it would be problematic) There might be one use case for A. Suppose b is something like ietf-interfaces and it gets widely implemented and deployed. In a few years from now we update that module, and add a typedef. This typedef is then used by some other module "a". Assume that an implementation that has the old version of ietf-interfaces wants to add support for "a". It is now forced to either implement the new ietf-interfaces, or not implement "a". This situation can be avoided with careful design of the modules; for example, we can always put typedefs like this in separate modules (just like was done with -TCs). However, with Y45-04, such conventions with separate modules are not needed. > I understand the need for existing modules to freeze their imports > to prevent typedef and grouping drift. These modules can use > import-by-revision, and keep using older typedefs/groupings, > even as the exporter module is updated. > > I don't think a vendor should be allowed to pick some statements > from a newer version, and not implement that version of the > module (i.e., all base module protocol-accessible objects). > > When vendors or SDOs write YANG modules with import-by-revision, > these modules will be designed to integrate with the expected > version. Results with vendor-selected back-revs will not be predictable. Do you have an example that shows how this can be problematic? /martin From nobody Thu Apr 23 00:01:19 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0988F1ACF58 for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 00:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-ZUqmKvn0Zs for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 00:01:13 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 191A71B2E70 for <netmod@ietf.org>; Thu, 23 Apr 2015 00:01:03 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 6DCAB1CC012A; Thu, 23 Apr 2015 09:01:04 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 23 Apr 2015 09:01:00 +0200 Message-ID: <m2lhhjl45v.fsf@birdie.labs.nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/_7NMBkUzEShNza5pTA5GD_Q6hQs> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 07:01:18 -0000 Andy Bierman <andy@yumaworks.com> writes: > .... >>> >>> Where does it say this is not allowed? >> >> If a server implements a module A that imports B, and A augments B >> or has a leafref to a node in B, the server MUST implement *some >> version* of module B that has the nodes A references. This is >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> regardless of A imports B by revision or not. >> >> >> The whole idea is to decouple the revision-date used in the import in >> order to fix the typedef from the version needed for augment. >> > > > This is the part that will really confuse users. > For augment-stmts, the revision-date is ignored > in import-by-revision. This is because the function of import is overloaded - augments really have nothing in common with using groupings and typedefs from another module. In hindsight, it would probably have been better to decouple augments from imports altogether by not using prefixes in schema node identifiers. For example, augment "/ietf-interfaces:interfaces/interface" { ... } would work just fine. > > IMO this will not work well because the designer will write > a module expecting the augmented module to be the > one specified by import-by-revision. Well, if the server implements another revision, it must be the revision that gets augmented. I don't see any other option. Lada > > If 2 or more modules augment different versions of > the /bar container over time at least 1 of them will > be applied to the wrong version of the augmented module. > This will cause unpredictable results because YANG > statements can interact in complex ways (e.g., must/when). > > >>> So the server cannot just pick a revision of "base". >>> It must be aware of all the other modules that use "base" >>> and make sure all modules work together? >> >> Right. This is not different from how it works in YANG 1.0. >> > > IMO importing multiple revisions at once and picking typedefs > and groupings from revisions ahead of the supported one > makes this problem much worse. > > > > >> >> /martin > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 23 00:34:56 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228A51B2F28 for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 00:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe2BGOcXZhDa for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 00:34:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01CF1B2F1E for <netmod@ietf.org>; Thu, 23 Apr 2015 00:34:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 14429233B; Thu, 23 Apr 2015 09:34:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ei0-1ZeWHzDC; Thu, 23 Apr 2015 09:34:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Apr 2015 09:34:35 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E50920013; Thu, 23 Apr 2015 09:34:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3IM_vW8sTnGW; Thu, 23 Apr 2015 09:34:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C0EF2002B; Thu, 23 Apr 2015 09:34:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2CC1832CC8F4; Thu, 23 Apr 2015 09:34:30 +0200 (CEST) Date: Thu, 23 Apr 2015 09:34:29 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150423073428.GA2450@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Ozdz_rjJgKraTjNwzJiNnWFH0Ag> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 07:34:54 -0000 On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: > .... > >> > >> Where does it say this is not allowed? > > > > If a server implements a module A that imports B, and A augments B > > or has a leafref to a node in B, the server MUST implement *some > > version* of module B that has the nodes A references. This is > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > regardless of A imports B by revision or not. > > > > > > The whole idea is to decouple the revision-date used in the import in > > order to fix the typedef from the version needed for augment. > > > > This is the part that will really confuse users. > For augment-stmts, the revision-date is ignored > in import-by-revision. Not sure what 'ignored' means here. At module compile time, if a module refers to /b:bar than this /b:bar must resolve to something defined in the revision that is used by the compiler (and import by revision nails this down to an exact version). > IMO this will not work well because the designer will write > a module expecting the augmented module to be the > one specified by import-by-revision. Likely, but it can also be a newer revision of the module that you implement, no? > If 2 or more modules augment different versions of > the /bar container over time at least 1 of them will > be applied to the wrong version of the augmented module. > This will cause unpredictable results because YANG > statements can interact in complex ways (e.g., must/when). Sure, you can create something not implementable with must/when statements - you do not even need imports for that and this is part of YANG 1.0 as well. > >> So the server cannot just pick a revision of "base". > >> It must be aware of all the other modules that use "base" > >> and make sure all modules work together? > > > > Right. This is not different from how it works in YANG 1.0. I assume that modules that are not implementable (e.g., due to must constraints that can never be true) will not be implemented. I also assume that a server announcing a set of modules that can't be compiled together will receive appropriate customer feedback. What Y45-04 primarily fixes is any ambiguity at module compile time concerning the typedefs and groupings being used. The other problem space, namely what are meaningful combinations of modules, is not addressed by Y45-04 and left for further study. (I personally believe we need at some point in time something like packages but this hopefully can be done as a language extension; fixing the typedef and grouping drift is something we have to resolve in YANG 1.1 since it impacts the semantics of imports.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 23 00:59:54 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AD81B2F2B for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 00:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjrpSgyF3rII for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 00:59:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E521B2F64 for <netmod@ietf.org>; Thu, 23 Apr 2015 00:59:49 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 024D113FAA4; Thu, 23 Apr 2015 09:59:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429775987; bh=E3aov9yITx/b4/I/2az5PE8bxXeFQMc2jwYy7Hb9qiM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SAbZXxYlq3KJoRyXTaf82NoG1Eh3U67E1MsB3ZzuxP3XjfeJwWIyLG/uljCEcXSkD rpRMPwMwqPW0fiX0BXkzu2oX2oZqwaSw3ZaDZCVZsfdtocQ1fHJwYqhO2s0lholkus eFw9akv+OZ2Uc8J1cYX31aPcl2fpOrIG7QeWqMgg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <20150423073428.GA2450@elstar.local> Date: Thu, 23 Apr 2015 09:59:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91F6FB70-B8D8-454F-9DDA-43F547030694@nic.cz> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= <j.schoenwaelder@jacobs-university.de> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/zuGL_Y6esNCn_EcaH4uaTtL9sFw> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 07:59:54 -0000 > On 23 Apr 2015, at 09:34, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >=20 > On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: >> .... >>>>=20 >>>> Where does it say this is not allowed? >>>=20 >>> If a server implements a module A that imports B, and A augments = B >>> or has a leafref to a node in B, the server MUST implement *some >>> version* of module B that has the nodes A references. This is >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> regardless of A imports B by revision or not. >>>=20 >>>=20 >>> The whole idea is to decouple the revision-date used in the import = in >>> order to fix the typedef from the version needed for augment. >>>=20 >>=20 >> This is the part that will really confuse users. >> For augment-stmts, the revision-date is ignored >> in import-by-revision. >=20 > Not sure what 'ignored' means here. At module compile time, if a > module refers to /b:bar than this /b:bar must resolve to something > defined in the revision that is used by the compiler (and import by > revision nails this down to an exact version). >=20 >> IMO this will not work well because the designer will write >> a module expecting the augmented module to be the >> one specified by import-by-revision. >=20 > Likely, but it can also be a newer revision of the module that you > implement, no? >=20 >> If 2 or more modules augment different versions of >> the /bar container over time at least 1 of them will >> be applied to the wrong version of the augmented module. >> This will cause unpredictable results because YANG >> statements can interact in complex ways (e.g., must/when). >=20 > Sure, you can create something not implementable with must/when > statements - you do not even need imports for that and this is > part of YANG 1.0 as well. >=20 >>>> So the server cannot just pick a revision of "base". >>>> It must be aware of all the other modules that use "base" >>>> and make sure all modules work together? >>>=20 >>> Right. This is not different from how it works in YANG 1.0. >=20 > I assume that modules that are not implementable (e.g., due to must > constraints that can never be true) will not be implemented. I also > assume that a server announcing a set of modules that can't be > compiled together will receive appropriate customer feedback. >=20 > What Y45-04 primarily fixes is any ambiguity at module compile time > concerning the typedefs and groupings being used. The other problem Y45-04 also gives module designers a chance to decide for each grouping = or typedef to either fix the revision that=E2=80=99s used, or leave it = to a server implementor to choose the revision. It is then of course the = implementor=E2=80=99s responsibility to make sure that the revisions = work together. RFC6087bis can give some advice in this respect, for example that = IANA-controlled types should in general be imported without revision. > space, namely what are meaningful combinations of modules, is not > addressed by Y45-04 and left for further study. (I personally believe > we need at some point in time something like packages but this > hopefully can be done as a language extension; fixing the typedef and > grouping drift is something we have to resolve in YANG 1.1 since it > impacts the semantics of imports.) +1 Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 23 10:49:26 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056E11B311A for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 10:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEKucVUT_0XK for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 10:49:14 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (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 9CE401B30AD for <netmod@ietf.org>; Thu, 23 Apr 2015 10:48:55 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so18915047lbb.2 for <netmod@ietf.org>; Thu, 23 Apr 2015 10:48:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=IXxRgmVLybKonH+OR1YaXcaVAKJwvVmD6TK0qqojnC0=; b=S+XFRwCLXSr9XJl+5LEl+FE74MJlaPq8QrNCsnpPnL8wea+ekaaTluNAm4ty2QxjpC QNhj3f2iMJ88iGhhG0ZXy1sV6cNHxo0Fcm4q2GxPkipes2pH1iaHTx42mfqcs8UemSHS fDPg4qanPtAjs4UG/xbxoCEvOaiVkTY6W/h/pGA2yTtxG2QQNSE4EIV+8Jzx1S5t4zaj oeVLSAVzwLyAN5y9IYye1b//wNV4983XxkA8UVpdcfgUXZn3BdtRgJErmLoHT9p/CWm1 H8/MKpzsrq5zTierjBXsxY1Rfjhbyhcw23fMIm9oI/K+W93P8AfVxTUvQ7goQz0n4iKG UJWg== X-Gm-Message-State: ALoCoQlwjO2/s9CvjoxaWp0pbKqw6J9TNicHcpBzJNfsKHhRJOyDESQX3PsAUSpW4KSHeOTrh6u0 MIME-Version: 1.0 X-Received: by 10.112.130.129 with SMTP id oe1mr3351411lbb.37.1429811334176; Thu, 23 Apr 2015 10:48:54 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 23 Apr 2015 10:48:54 -0700 (PDT) In-Reply-To: <20150423073428.GA2450@elstar.local> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> Date: Thu, 23 Apr 2015 10:48:54 -0700 Message-ID: <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/PFeVSaB5pqs6gWt5DUdzMwwG1N0> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 17:49:22 -0000 On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: >> .... >> >> >> >> Where does it say this is not allowed? >> > >> > If a server implements a module A that imports B, and A augments B >> > or has a leafref to a node in B, the server MUST implement *some >> > version* of module B that has the nodes A references. This is >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > regardless of A imports B by revision or not. >> > >> > >> > The whole idea is to decouple the revision-date used in the import in >> > order to fix the typedef from the version needed for augment. >> > >> >> This is the part that will really confuse users. >> For augment-stmts, the revision-date is ignored >> in import-by-revision. > > Not sure what 'ignored' means here. At module compile time, if a > module refers to /b:bar than this /b:bar must resolve to something > defined in the revision that is used by the compiler (and import by > revision nails this down to an exact version). > >> IMO this will not work well because the designer will write >> a module expecting the augmented module to be the >> one specified by import-by-revision. > > Likely, but it can also be a newer revision of the module that you > implement, no? > >> If 2 or more modules augment different versions of >> the /bar container over time at least 1 of them will >> be applied to the wrong version of the augmented module. >> This will cause unpredictable results because YANG >> statements can interact in complex ways (e.g., must/when). > > Sure, you can create something not implementable with must/when > statements - you do not even need imports for that and this is > part of YANG 1.0 as well. > >> >> So the server cannot just pick a revision of "base". >> >> It must be aware of all the other modules that use "base" >> >> and make sure all modules work together? >> > >> > Right. This is not different from how it works in YANG 1.0. > > I assume that modules that are not implementable (e.g., due to must > constraints that can never be true) will not be implemented. I also > assume that a server announcing a set of modules that can't be > compiled together will receive appropriate customer feedback. > > What Y45-04 primarily fixes is any ambiguity at module compile time > concerning the typedefs and groupings being used. The other problem > space, namely what are meaningful combinations of modules, is not > addressed by Y45-04 and left for further study. (I personally believe > we need at some point in time something like packages but this > hopefully can be done as a language extension; fixing the typedef and > grouping drift is something we have to resolve in YANG 1.1 since it > impacts the semantics of imports.) > You missed my point. The authors of a module that imports a specific revision of another module expect that the import-by-revision will be honored. It should not be up to the vendor to pick a down-rev version. The vendor MUST implement the version specified in the import-stmt or the API will not be exactly as specified in the combined YANG modules, and will not be interoperable. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 23 11:04:08 2015 Return-Path: <linda.dunbar@huawei.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002261ACDBC; Thu, 23 Apr 2015 10:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy2gqxZa2nZv; Thu, 23 Apr 2015 10:13:03 -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 5311B1ACDA7; Thu, 23 Apr 2015 10:13:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT49007; Thu, 23 Apr 2015 17:12:59 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Apr 2015 18:12:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 23 Apr 2015 10:12:53 -0700 From: Linda Dunbar <linda.dunbar@huawei.com> To: "i2nsf@ietf.org" <i2nsf@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "sacm@ietf.org" <sacm@ietf.org>, "pcp@ietf.org" <pcp@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "dots@ietf.org" <dots@ietf.org>, "opsawg@ietf.org" <OpsAWG@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "ops-ads@tools.ietf.org" <ops-ads@tools.ietf.org> Thread-Topic: I2NSF: Interface to network security functions : problem-statement, framework, use cases, and potential solution Thread-Index: AQHQfeL7u793L89A7kyGIFebPlU0DZ1aykFw Date: Thu, 23 Apr 2015 17:12:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C09765@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/o2MIiRRyUSREJynQWkgIqZLQlxU> X-Mailman-Approved-At: Thu, 23 Apr 2015 11:04:07 -0700 Cc: "mile@ietf.org" <mile@ietf.org> Subject: [netmod] I2NSF: Interface to network security functions : problem-statement, framework, use cases, and potential solution X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 17:13:05 -0000 VGhlICJpMm5zZi1wcm9ibGVtLXN0YXRlbWVudCIgZHJhZnQgZGVzY3JpYmVzIHRoZSBtb3RpdmF0 aW9uIGFuZCB0aGUgcHJvYmxlbSBzcGFjZSBhc3NvY2lhdGVkIHdpdGggc2VydmljZSBwcm92aWRl cnMgcHJvdmlkaW5nIGhvc3RlZCBzZWN1cml0eSBzb2x1dGlvbnMgdG8gZGVsaXZlciBjb3N0LWVm ZmVjdGl2ZSBtYW5hZ2VkIHNlY3VyaXR5IHNlcnZpY2VzIHRvIGVudGVycHJpc2UgY3VzdG9tZXJz IHdobyBkb24ndCBvd24gb3IgaGF2ZSB0aGUgc2VjdXJpdHkgZnVuY3Rpb25zIG9uIHRoZWlyIHBy ZW1pc2VzLiANCg0KU2luY2UgdGhlIGkybnNmLXByb2JsZW0tc3RhdGVtZW50LTAxIGRyYWZ0LCB0 aHJlZSBJMk5TRiB1c2UgY2FzZSBkcmFmdHMsIGEgZ2FwIGFuYWx5c2lzIGRyYWZ0LCBhbmQgYSBw YWNrZXQtYmFzZWQgcGFyYWRpZ20gZHJhZnQgaGF2ZSBiZWVuIHB1Ymxpc2hlZC4gDQpXZSByZW1v dmVkIHRoZSByZWR1bmRhbnQgY29udGVudCBmcm9tIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFm dCwgbWFraW5nIGl0IGZvY3VzIGV4Y2x1c2l2ZWx5IG9uIHRoZSBwcm9ibGVtIHNwYWNlIG9mIHNl Y3VyaXR5IGZ1bmN0aW9ucyBub3QgaG9zdGVkIG9uIGN1c3RvbWVyJ3MgcHJlbWlzZXMgYW5kIGJl aW5nIGRpc3RyaWJ1dGVkIChkcml2ZW4gYnkgTkZWIGFuZCBob3N0ZWQgc2VjdXJpdHkgc2Vydmlj ZXMpLg0KDQpJbiBjb25qdW5jdGlvbiB3aXRoIHRoZSAiaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnRz IiwgdGhlcmUgYXJlIGFsc28gSTJOU0YgZnJhbWV3b3JrIGRyYWZ0LCBwb3RlbnRpYWwgSTJOU0Yg c29sdXRpb24gZHJhZnQsIHVzZSBjYXNlIGRyYWZ0cyAodW5kZXIgcHJvY2VzcyBvZiBtZXJnaW5n KSwgZ2FwLWFuYWx5c2lzIGFuZCBkYXRhIG1vZGVsaW5nIGRyYWZ0Og0KDQpodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmsvDQoNCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotaTJuc2YtcGFja2V0Lw0KDQpo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpYS1pMm5zZi1jYXBhYmlsaXR5 LWludGVyZmFjZS1pbS8gKG5ldyByZXZpc2lvbiBpcyB0byBiZSB1cGxvYWRlZCBzb29uIHRvIHJl ZmxlY3QgdGhlIGRpc2N1c3Npb24gb2YgRjJGIG1lZXRpbmdzIGF0IElFVEY5MiBEYWxsYXMpLiAN Cg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXN0b3ItaTJuc2YtYWNj ZXNzLXVzZWNhc2VzLw0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xaS1p Mm5zZi1hY2Nlc3MtbmV0d29yay11c2VjYXNlLw0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC16YXJueS1pMm5zZi1kYXRhLWNlbnRlci11c2UtY2FzZXMvDQoNCmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctZ2FwLWFuYWx5c2lzLw0KDQpJMk5T RiBpcyBhYm91dCBzZWN1cml0eSBmdW5jdGlvbnMgbWFuYWdlbWVudC4gVGhlIHVsdGltYXRlIGdv YWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVycHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkg ZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIgb3duIHByZW1pc2UgYnV0IGluc3RlYWQgaG9z dGVkIGluIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCB0byBlc3RhYmxpc2ggaG93IHRvIGNvbW11 bmljYXRlIGRlc2lyZWQgc2VjdXJpdHkgcG9saWNpZXMgdG8gTlNGIGFuZCBob3cgdG8gZ2V0IHBl cmZvcm1hbmNlIGRhdGEgb3IgcmVwb3J0IG91dCBvZiBOU0YuICANCg0KQWxzbyBjb3B5IHRvIHRo ZSBJMk5TRiByZWxldmFudCBJRVRGIFdHczogSTJSUywgTkVUTU9ELCBORVRDT05GLCBTQUNNLCBN SUxFLCBQQ1AsIERPVFMsIFNGQywgYW5kIE9wQXJlYXMsIGluIGhvcGUgdG8gZ2V0IGZlZWRiYWNr IGFuZCBzdWdnZXN0aW9ucyBmcm9tIHdpZGVyIGF1ZGllbmNlLiANCg0KVGhhbmtzIGluIGFkdmFu Y2UsIA0KDQpMaW5kYSBEdW5iYXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgMTE6MzEgQU0NClRvOiBNb2hhbWVk IEJvdWNhZGFpcjsgU2hhaWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBDaHJpc3RpYW4g SmFjcXVlbmV0OyBNeW8gWmFybnk7IENocmlzdGlhbiBKYWNxdWVuZXQ7IE15byBaYXJueTsgU2hh aWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBNb2hhbWVkIEJvdWNhZGFpcg0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxl bS1zdGF0ZW1lbnQtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJh ci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudC0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LWR1bmJhci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudA0KUmV2aXNp b246CTAzDQpUaXRsZToJCUludGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyAo STJOU0YpIFByb2JsZW0gU3RhdGVtZW50DQpEb2N1bWVudCBkYXRlOgkyMDE1LTA0LTIzDQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1pMm5zZi1wcm9i bGVtLXN0YXRlbWVudC0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQvDQpIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHVuYmFyLWkybnNm LXByb2JsZW0tc3RhdGVtZW50LTAzDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTAzDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1vdGl2YXRpb24gYW5k IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3INCiAgIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3Vy aXR5IEZ1bmN0aW9ucyAoSTJOU0YpLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From nobody Thu Apr 23 11:15:41 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046D81A700E for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 11:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biuQvzijz1sx for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 11:15:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842A91B3165 for <netmod@ietf.org>; Thu, 23 Apr 2015 11:15:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D7193772; Thu, 23 Apr 2015 20:15:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8ghx9yDo571U; Thu, 23 Apr 2015 20:15:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Apr 2015 20:15:17 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C4CF2002B; Thu, 23 Apr 2015 20:15:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nBpPRS_-zSzm; Thu, 23 Apr 2015 20:15:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0302020013; Thu, 23 Apr 2015 20:15:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 17A5432CD984; Thu, 23 Apr 2015 20:15:13 +0200 (CEST) Date: Thu, 23 Apr 2015 20:15:13 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150423181513.GA4274@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/dhx6jShL1_EmjXtsEOsSegV4j5M> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 18:15:41 -0000 On Thu, Apr 23, 2015 at 10:48:54AM -0700, Andy Bierman wrote: > On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: > > On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: > >> .... > >> >> > >> >> Where does it say this is not allowed? > >> > > >> > If a server implements a module A that imports B, and A augments B > >> > or has a leafref to a node in B, the server MUST implement *some > >> > version* of module B that has the nodes A references. This is > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > regardless of A imports B by revision or not. > >> > > >> > > >> > The whole idea is to decouple the revision-date used in the import in > >> > order to fix the typedef from the version needed for augment. > >> > > >> > >> This is the part that will really confuse users. > >> For augment-stmts, the revision-date is ignored > >> in import-by-revision. > > > > Not sure what 'ignored' means here. At module compile time, if a > > module refers to /b:bar than this /b:bar must resolve to something > > defined in the revision that is used by the compiler (and import by > > revision nails this down to an exact version). > > > >> IMO this will not work well because the designer will write > >> a module expecting the augmented module to be the > >> one specified by import-by-revision. > > > > Likely, but it can also be a newer revision of the module that you > > implement, no? > > > >> If 2 or more modules augment different versions of > >> the /bar container over time at least 1 of them will > >> be applied to the wrong version of the augmented module. > >> This will cause unpredictable results because YANG > >> statements can interact in complex ways (e.g., must/when). > > > > Sure, you can create something not implementable with must/when > > statements - you do not even need imports for that and this is > > part of YANG 1.0 as well. > > > >> >> So the server cannot just pick a revision of "base". > >> >> It must be aware of all the other modules that use "base" > >> >> and make sure all modules work together? > >> > > >> > Right. This is not different from how it works in YANG 1.0. > > > > I assume that modules that are not implementable (e.g., due to must > > constraints that can never be true) will not be implemented. I also > > assume that a server announcing a set of modules that can't be > > compiled together will receive appropriate customer feedback. > > > > What Y45-04 primarily fixes is any ambiguity at module compile time > > concerning the typedefs and groupings being used. The other problem > > space, namely what are meaningful combinations of modules, is not > > addressed by Y45-04 and left for further study. (I personally believe > > we need at some point in time something like packages but this > > hopefully can be done as a language extension; fixing the typedef and > > grouping drift is something we have to resolve in YANG 1.1 since it > > impacts the semantics of imports.) > > You missed my point. > > The authors of a module that imports a specific revision of > another module expect that the import-by-revision will > be honored. It should not be up to the vendor to pick a > down-rev version. The vendor MUST implement the version specified > in the import-stmt or the API will not be exactly as specified in the > combined YANG modules, and will not be interoperable. There is confusion here, for sure. The problem is that implement is used in two different meanings. - By using import by revision, it is exactly defined what the typedefs and groupings are that must be implemented. There is no ambiguity here (no typedef or grouping drift). - If a module augments something in another module, then this something must of course exist. Note that Y45-04 even with import-by-revision does not require that exactly the revision imported is implemented. In particular, it should be safe to implement any newer revision. To find out out which revisions have been implemented, you read the modules announcements. In other words, the import makes it clear what is imported into a specific module; it does not pose a strict requirement of which module versions must combined in an implementation. There might be additional module dependencies (e.g., embedded in must of when statements) that may make some combinations impossible to implement. An implementation that announces something impossible to implement is broken or simply unfaithful. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 23 11:34:41 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26FA1B3190 for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MJ7MLChJdhY for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 11:34:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D22731B3197 for <netmod@ietf.org>; Thu, 23 Apr 2015 11:34:14 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id E1AC11AE0CF5; Thu, 23 Apr 2015 20:34:12 +0200 (CEST) Date: Thu, 23 Apr 2015 20:35:49 +0200 (CEST) Message-Id: <20150423.203549.2054515192189852164.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> References: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/0eflZhLGO_onTxXSAHdAL_d0w5g> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 18:34:40 -0000 Andy Bierman <andy@yumaworks.com> wrote: > On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: > > On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: > >> .... > >> >> > >> >> Where does it say this is not allowed? > >> > > >> > If a server implements a module A that imports B, and A augments B > >> > or has a leafref to a node in B, the server MUST implement *some > >> > version* of module B that has the nodes A references. This is > >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > regardless of A imports B by revision or not. > >> > > >> > > >> > The whole idea is to decouple the revision-date used in the import in > >> > order to fix the typedef from the version needed for augment. > >> > > >> > >> This is the part that will really confuse users. > >> For augment-stmts, the revision-date is ignored > >> in import-by-revision. > > > > Not sure what 'ignored' means here. At module compile time, if a > > module refers to /b:bar than this /b:bar must resolve to something > > defined in the revision that is used by the compiler (and import by > > revision nails this down to an exact version). > > > >> IMO this will not work well because the designer will write > >> a module expecting the augmented module to be the > >> one specified by import-by-revision. > > > > Likely, but it can also be a newer revision of the module that you > > implement, no? > > > >> If 2 or more modules augment different versions of > >> the /bar container over time at least 1 of them will > >> be applied to the wrong version of the augmented module. > >> This will cause unpredictable results because YANG > >> statements can interact in complex ways (e.g., must/when). > > > > Sure, you can create something not implementable with must/when > > statements - you do not even need imports for that and this is > > part of YANG 1.0 as well. > > > >> >> So the server cannot just pick a revision of "base". > >> >> It must be aware of all the other modules that use "base" > >> >> and make sure all modules work together? > >> > > >> > Right. This is not different from how it works in YANG 1.0. > > > > I assume that modules that are not implementable (e.g., due to must > > constraints that can never be true) will not be implemented. I also > > assume that a server announcing a set of modules that can't be > > compiled together will receive appropriate customer feedback. > > > > What Y45-04 primarily fixes is any ambiguity at module compile time > > concerning the typedefs and groupings being used. The other problem > > space, namely what are meaningful combinations of modules, is not > > addressed by Y45-04 and left for further study. (I personally believe > > we need at some point in time something like packages but this > > hopefully can be done as a language extension; fixing the typedef and > > grouping drift is something we have to resolve in YANG 1.1 since it > > impacts the semantics of imports.) > > > > You missed my point. > > The authors of a module that imports a specific revision of > another module expect that the import-by-revision will > be honored. It should not be up to the vendor to pick a > down-rev version. The vendor MUST implement the version specified > in the import-stmt But this can never work. Two separate modules might import two different version of a common module. Then the server cannot implement them. The only reasonable conclusion from this statement is to remove import-by revision from YANG 1.1. (and then you really didn't gain anything b/c the server can implement any version it likes) > or the API will not be exactly as specified in the > combined YANG modules, and will not be interoperable. This is where your idea of packages come in. Juergen has also pointed this out. In a package, we can define a set of revisions of modules and features that a server must implement in order to claim conformance to the package. /martin From nobody Thu Apr 23 11:48:39 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728621A03E3 for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqBGSnCZrXIh for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 11:48:36 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 275A31B31A5 for <netmod@ietf.org>; Thu, 23 Apr 2015 11:48:16 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so20091015lbb.2 for <netmod@ietf.org>; Thu, 23 Apr 2015 11:48:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kz8nvGFwf/5HEJMfV99erMowubanBybgIu7gheLysvo=; b=XVOukfptizgCZCOhImsroJs0MpTpNr7Wi9WcKXJvD9wFK/ZO4J49++BVNrhNZwLyCS B/tTXaHS51vy6kj0DNj3aL962ty9TFiJlycLA/YLq0fPacIqtxJ+CAllCJfeaRrSIT9S KkOOE899SmiD8qX78zTMeBVXldGL2fym4IUfs9KLcEAOd8KmvUfUgdkjOe7VKY0YxV5n co11K69r/Ku01PMvW3IvvnrRBez0O8bbc6ExykbgxGntNFtGdrXkgYy0XItCdUBYerAP eJiCq1fki1BGLjydoIj3wu/w3TY6+Y8qdS2OrEl91zTM+A/UiyEuyqYxw+adwVD6T+jr q+4A== X-Gm-Message-State: ALoCoQk3AAuOrEL3EcYlQlLLWJ1wCTfsD58NiFDK5jNYt6yUvAk1R8uHWTUHFTV3RFcs56/ErNj/ MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr3708039lab.82.1429814894719; Thu, 23 Apr 2015 11:48:14 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 23 Apr 2015 11:48:14 -0700 (PDT) In-Reply-To: <20150423.203549.2054515192189852164.mbj@tail-f.com> References: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <20150423.203549.2054515192189852164.mbj@tail-f.com> Date: Thu, 23 Apr 2015 11:48:14 -0700 Message-ID: <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/C1M68KebdPNX1eLz26sjWV1z1Js> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 18:48:38 -0000 On Thu, Apr 23, 2015 at 11:35 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Andy Bierman <andy@yumaworks.com> wrote: >> On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder >> <j.schoenwaelder@jacobs-university.de> wrote: >> > On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: >> >> .... >> >> >> >> >> >> Where does it say this is not allowed? >> >> > >> >> > If a server implements a module A that imports B, and A augments B >> >> > or has a leafref to a node in B, the server MUST implement *some >> >> > version* of module B that has the nodes A references. This is >> >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> > regardless of A imports B by revision or not. >> >> > >> >> > >> >> > The whole idea is to decouple the revision-date used in the import in >> >> > order to fix the typedef from the version needed for augment. >> >> > >> >> >> >> This is the part that will really confuse users. >> >> For augment-stmts, the revision-date is ignored >> >> in import-by-revision. >> > >> > Not sure what 'ignored' means here. At module compile time, if a >> > module refers to /b:bar than this /b:bar must resolve to something >> > defined in the revision that is used by the compiler (and import by >> > revision nails this down to an exact version). >> > >> >> IMO this will not work well because the designer will write >> >> a module expecting the augmented module to be the >> >> one specified by import-by-revision. >> > >> > Likely, but it can also be a newer revision of the module that you >> > implement, no? >> > >> >> If 2 or more modules augment different versions of >> >> the /bar container over time at least 1 of them will >> >> be applied to the wrong version of the augmented module. >> >> This will cause unpredictable results because YANG >> >> statements can interact in complex ways (e.g., must/when). >> > >> > Sure, you can create something not implementable with must/when >> > statements - you do not even need imports for that and this is >> > part of YANG 1.0 as well. >> > >> >> >> So the server cannot just pick a revision of "base". >> >> >> It must be aware of all the other modules that use "base" >> >> >> and make sure all modules work together? >> >> > >> >> > Right. This is not different from how it works in YANG 1.0. >> > >> > I assume that modules that are not implementable (e.g., due to must >> > constraints that can never be true) will not be implemented. I also >> > assume that a server announcing a set of modules that can't be >> > compiled together will receive appropriate customer feedback. >> > >> > What Y45-04 primarily fixes is any ambiguity at module compile time >> > concerning the typedefs and groupings being used. The other problem >> > space, namely what are meaningful combinations of modules, is not >> > addressed by Y45-04 and left for further study. (I personally believe >> > we need at some point in time something like packages but this >> > hopefully can be done as a language extension; fixing the typedef and >> > grouping drift is something we have to resolve in YANG 1.1 since it >> > impacts the semantics of imports.) >> > >> >> You missed my point. >> >> The authors of a module that imports a specific revision of >> another module expect that the import-by-revision will >> be honored. It should not be up to the vendor to pick a >> down-rev version. The vendor MUST implement the version specified >> in the import-stmt > > But this can never work. Two separate modules might import two > different version of a common module. Then the server cannot > implement them. The only reasonable conclusion from this statement is > to remove import-by revision from YANG 1.1. (and then you really > didn't gain anything b/c the server can implement any version it > likes) > Both foo and bar augment X. If foo imports X@R1 and bar imports X@R2 then IMO the server has to implement X@R2. I agree it is OK for foo to augment X and also bar to augment X. The augment of X@R1 should still work in X@R2. But we cannot be very sure that the "bar" augment of X@R2 will work with X@R1. IMO treating import-by-revision as "min-revision" means that the server can only choose newer than the specified import-by-revision, never lower than that. Using the typedefs and groupings from the specified revision may not mix well with augmented objects from a previous version. >> or the API will not be exactly as specified in the >> combined YANG modules, and will not be interoperable. > > This is where your idea of packages come in. Juergen has also pointed > this out. In a package, we can define a set of revisions of modules > and features that a server must implement in order to claim > conformance to the package. > Well, we don't have conformance packages, just "inline complexity". > > /martin > > Andy > > > > > > > > > > > > > > From nobody Thu Apr 23 12:04:10 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1853E1A1BD4 for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXlbNWyTANnX for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:04:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 69A671A8762 for <netmod@ietf.org>; Thu, 23 Apr 2015 12:02:50 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id AB6B21AE0CF5; Thu, 23 Apr 2015 21:02:49 +0200 (CEST) Date: Thu, 23 Apr 2015 21:04:26 +0200 (CEST) Message-Id: <20150423.210426.472771978800503967.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> References: <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <20150423.203549.2054515192189852164.mbj@tail-f.com> <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/p9FBGv4s7Kc3t4SaWJS48HlmZaA> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 19:04:09 -0000 Andy Bierman <andy@yumaworks.com> wrote: > On Thu, Apr 23, 2015 at 11:35 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > Andy Bierman <andy@yumaworks.com> wrote: > >> On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder > >> <j.schoenwaelder@jacobs-university.de> wrote: > >> > On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: > >> >> .... > >> >> >> > >> >> >> Where does it say this is not allowed? > >> >> > > >> >> > If a server implements a module A that imports B, and A augments B > >> >> > or has a leafref to a node in B, the server MUST implement *some > >> >> > version* of module B that has the nodes A references. This is > >> >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> >> > regardless of A imports B by revision or not. > >> >> > > >> >> > > >> >> > The whole idea is to decouple the revision-date used in the import in > >> >> > order to fix the typedef from the version needed for augment. > >> >> > > >> >> > >> >> This is the part that will really confuse users. > >> >> For augment-stmts, the revision-date is ignored > >> >> in import-by-revision. > >> > > >> > Not sure what 'ignored' means here. At module compile time, if a > >> > module refers to /b:bar than this /b:bar must resolve to something > >> > defined in the revision that is used by the compiler (and import by > >> > revision nails this down to an exact version). > >> > > >> >> IMO this will not work well because the designer will write > >> >> a module expecting the augmented module to be the > >> >> one specified by import-by-revision. > >> > > >> > Likely, but it can also be a newer revision of the module that you > >> > implement, no? > >> > > >> >> If 2 or more modules augment different versions of > >> >> the /bar container over time at least 1 of them will > >> >> be applied to the wrong version of the augmented module. > >> >> This will cause unpredictable results because YANG > >> >> statements can interact in complex ways (e.g., must/when). > >> > > >> > Sure, you can create something not implementable with must/when > >> > statements - you do not even need imports for that and this is > >> > part of YANG 1.0 as well. > >> > > >> >> >> So the server cannot just pick a revision of "base". > >> >> >> It must be aware of all the other modules that use "base" > >> >> >> and make sure all modules work together? > >> >> > > >> >> > Right. This is not different from how it works in YANG 1.0. > >> > > >> > I assume that modules that are not implementable (e.g., due to must > >> > constraints that can never be true) will not be implemented. I also > >> > assume that a server announcing a set of modules that can't be > >> > compiled together will receive appropriate customer feedback. > >> > > >> > What Y45-04 primarily fixes is any ambiguity at module compile time > >> > concerning the typedefs and groupings being used. The other problem > >> > space, namely what are meaningful combinations of modules, is not > >> > addressed by Y45-04 and left for further study. (I personally believe > >> > we need at some point in time something like packages but this > >> > hopefully can be done as a language extension; fixing the typedef and > >> > grouping drift is something we have to resolve in YANG 1.1 since it > >> > impacts the semantics of imports.) > >> > > >> > >> You missed my point. > >> > >> The authors of a module that imports a specific revision of > >> another module expect that the import-by-revision will > >> be honored. It should not be up to the vendor to pick a > >> down-rev version. The vendor MUST implement the version specified > >> in the import-stmt > > > > But this can never work. Two separate modules might import two > > different version of a common module. Then the server cannot > > implement them. The only reasonable conclusion from this statement is > > to remove import-by revision from YANG 1.1. (and then you really > > didn't gain anything b/c the server can implement any version it > > likes) > > > > Both foo and bar augment X. > > If foo imports X@R1 and bar imports X@R2 then IMO the server > has to implement X@R2. I agree it is OK for foo to augment X > and also bar to augment X. The augment of X@R1 should > still work in X@R2. > > But we cannot be very sure that the "bar" augment of X@R2 > will work with X@R1. Does this mean that your are ok with Y45-04, provided we change the text about "any revision" to text about "any revision >= the imported revision"? /martin From nobody Thu Apr 23 12:05:23 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9E91ACE08 for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avIQfVD8SI5S for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:05:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EDA1A871B for <netmod@ietf.org>; Thu, 23 Apr 2015 12:03:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8636A6FC; Thu, 23 Apr 2015 21:03:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Bea-_g_Oa-tB; Thu, 23 Apr 2015 21:03:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Apr 2015 21:03:53 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 417722002B; Thu, 23 Apr 2015 21:03:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id H5fW5H78cCz0; Thu, 23 Apr 2015 21:03:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48FF220013; Thu, 23 Apr 2015 21:03:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 662BA32CDB39; Thu, 23 Apr 2015 21:03:50 +0200 (CEST) Date: Thu, 23 Apr 2015 21:03:50 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150423190350.GB4421@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <20150423.203549.2054515192189852164.mbj@tail-f.com> <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/eVgYraB5do1jaXRjhB9zXryx8MA> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 19:05:22 -0000 On Thu, Apr 23, 2015 at 11:48:14AM -0700, Andy Bierman wrote: > Both foo and bar augment X. > > If foo imports X@R1 and bar imports X@R2 then IMO the server > has to implement X@R2. I agree it is OK for foo to augment X > and also bar to augment X. The augment of X@R1 should > still work in X@R2. > > But we cannot be very sure that the "bar" augment of X@R2 > will work with X@R1. Yes, if module authors create something like this, it will not be implemented. The same is true for must statements that will never be true. > IMO treating import-by-revision as "min-revision" > means that the server can only choose newer than > the specified import-by-revision, never lower than that. > Using the typedefs and groupings from the specified revision > may not mix well with augmented objects from a previous version. This is not what Y45-04 says. The imported revision is important for resolving typedefs and groupings. There might be older versions that define something that gets augmented and which has never changed since then and in such a situation there is no reason to not allow this. The set module combinations that can work together is orthogonal to the question how typedef and grouping drift is avoided. > >> or the API will not be exactly as specified in the > >> combined YANG modules, and will not be interoperable. > > > > This is where your idea of packages come in. Juergen has also pointed > > this out. In a package, we can define a set of revisions of modules > > and features that a server must implement in order to claim > > conformance to the package. > > Well, we don't have conformance packages, just "inline complexity". The assumption is that we can add conformance packages later via extensions. Addressing typedef and grouping drift is something we have to as part of YANG 1.1 because this import semantics can't be changed with extensions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 23 12:20:53 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303361AD35A for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECYufnvjmtpW for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:20:48 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936B91AD09F for <netmod@ietf.org>; Thu, 23 Apr 2015 12:20:45 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so20731789lbb.3 for <netmod@ietf.org>; Thu, 23 Apr 2015 12:20:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xcQ2AwfW5A5J/lUt/b4KrIRV8AkcU861PwJL/j29kQo=; b=aIlMFhjHyXYgEiCy4lPaHZc3bkcNe+tr86FPe6UW6dabTSia2KjU+6YS7otZiyydvl JLqN2Lck0a3E16xOzEyofAqW9MDAjhrOnl1tEZ4FCBHfJRbe+913EFkERa4GaI601gR2 NY3qnVABKSINa8wY+8DTAE12jeLl9F1oCxjIDPAFeCE6vZi8r8g2zlAJCrl7unq5Z3IS d7HAQvhaE0K+I7UmXcD+ysTgncgxJdbZTMvMnLGE+BT9LJOo2kujJ5S6zmYHdIgSYoaV WJB13gEcNlq1BqD1UTqATAq922dawyy14qsGTKH75ezueEtgkGgrqQwsTVuWoQIpLKAp RzPg== X-Gm-Message-State: ALoCoQn8L1Q9lU6UuvpBP0H1regVqTHhwJ+ek0VGu1Vm0U8Co1dLeAt120Ejg1/L35Cqa9aLaUPW MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr3824292lab.82.1429816844076; Thu, 23 Apr 2015 12:20:44 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 23 Apr 2015 12:20:43 -0700 (PDT) In-Reply-To: <20150423.210426.472771978800503967.mbj@tail-f.com> References: <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <20150423.203549.2054515192189852164.mbj@tail-f.com> <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> <20150423.210426.472771978800503967.mbj@tail-f.com> Date: Thu, 23 Apr 2015 12:20:43 -0700 Message-ID: <CABCOCHSKaAE_dbwr0HjaHYvfJd-wk3dq7TF7O9vs7ecL2gzPjg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Mwx1ECQv5LC6B3LpvbOliAQ4oCQ> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 19:20:52 -0000 On Thu, Apr 23, 2015 at 12:04 PM, Martin Bjorklund <mbj@tail-f.com> wrote: > Andy Bierman <andy@yumaworks.com> wrote: >> On Thu, Apr 23, 2015 at 11:35 AM, Martin Bjorklund <mbj@tail-f.com> wrote: >> > Andy Bierman <andy@yumaworks.com> wrote: >> >> On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder >> >> <j.schoenwaelder@jacobs-university.de> wrote: >> >> > On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: >> >> >> .... >> >> >> >> >> >> >> >> Where does it say this is not allowed? >> >> >> > >> >> >> > If a server implements a module A that imports B, and A augments B >> >> >> > or has a leafref to a node in B, the server MUST implement *some >> >> >> > version* of module B that has the nodes A references. This is >> >> >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> > regardless of A imports B by revision or not. >> >> >> > >> >> >> > >> >> >> > The whole idea is to decouple the revision-date used in the import in >> >> >> > order to fix the typedef from the version needed for augment. >> >> >> > >> >> >> >> >> >> This is the part that will really confuse users. >> >> >> For augment-stmts, the revision-date is ignored >> >> >> in import-by-revision. >> >> > >> >> > Not sure what 'ignored' means here. At module compile time, if a >> >> > module refers to /b:bar than this /b:bar must resolve to something >> >> > defined in the revision that is used by the compiler (and import by >> >> > revision nails this down to an exact version). >> >> > >> >> >> IMO this will not work well because the designer will write >> >> >> a module expecting the augmented module to be the >> >> >> one specified by import-by-revision. >> >> > >> >> > Likely, but it can also be a newer revision of the module that you >> >> > implement, no? >> >> > >> >> >> If 2 or more modules augment different versions of >> >> >> the /bar container over time at least 1 of them will >> >> >> be applied to the wrong version of the augmented module. >> >> >> This will cause unpredictable results because YANG >> >> >> statements can interact in complex ways (e.g., must/when). >> >> > >> >> > Sure, you can create something not implementable with must/when >> >> > statements - you do not even need imports for that and this is >> >> > part of YANG 1.0 as well. >> >> > >> >> >> >> So the server cannot just pick a revision of "base". >> >> >> >> It must be aware of all the other modules that use "base" >> >> >> >> and make sure all modules work together? >> >> >> > >> >> >> > Right. This is not different from how it works in YANG 1.0. >> >> > >> >> > I assume that modules that are not implementable (e.g., due to must >> >> > constraints that can never be true) will not be implemented. I also >> >> > assume that a server announcing a set of modules that can't be >> >> > compiled together will receive appropriate customer feedback. >> >> > >> >> > What Y45-04 primarily fixes is any ambiguity at module compile time >> >> > concerning the typedefs and groupings being used. The other problem >> >> > space, namely what are meaningful combinations of modules, is not >> >> > addressed by Y45-04 and left for further study. (I personally believe >> >> > we need at some point in time something like packages but this >> >> > hopefully can be done as a language extension; fixing the typedef and >> >> > grouping drift is something we have to resolve in YANG 1.1 since it >> >> > impacts the semantics of imports.) >> >> > >> >> >> >> You missed my point. >> >> >> >> The authors of a module that imports a specific revision of >> >> another module expect that the import-by-revision will >> >> be honored. It should not be up to the vendor to pick a >> >> down-rev version. The vendor MUST implement the version specified >> >> in the import-stmt >> > >> > But this can never work. Two separate modules might import two >> > different version of a common module. Then the server cannot >> > implement them. The only reasonable conclusion from this statement is >> > to remove import-by revision from YANG 1.1. (and then you really >> > didn't gain anything b/c the server can implement any version it >> > likes) >> > >> >> Both foo and bar augment X. >> >> If foo imports X@R1 and bar imports X@R2 then IMO the server >> has to implement X@R2. I agree it is OK for foo to augment X >> and also bar to augment X. The augment of X@R1 should >> still work in X@R2. >> >> But we cannot be very sure that the "bar" augment of X@R2 >> will work with X@R1. > > Does this mean that your are ok with Y45-04, provided we change the > text about "any revision" to text about "any revision >= the imported > revision"? > That would make Y45-04 better. YANG 1.1 is still too complicated and the likelihood of "pilot error" is way too high, but that will take care of itself somehow (perhaps free tools will hide the complexity). > > /martin Andy From nobody Thu Apr 23 12:28:30 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4341AD0BC for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC_ysDT8rF4n for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:28:26 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF451AD0D3 for <netmod@ietf.org>; Thu, 23 Apr 2015 12:28:14 -0700 (PDT) Received: by laat2 with SMTP id t2so20160407laa.1 for <netmod@ietf.org>; Thu, 23 Apr 2015 12:28:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BsnPYunETXAx9ZGgY6ogJN3ViLYYsQm3TeqNCbs2RIY=; b=dNY4gOycsHmzhAd4VddfNigDnN7zT/rrCIyaW3C5KTUdK8TLXu3vvSXGifX2yBhPoI PzxvGQLDiRKqv5bdjZWdfJqPLnzL2iatLQfXsKg4QYzBMrHZZxgRYnmJoenAYwPQBnK5 6PW2FAk3LGcPRjefQdatmP689wN348C8crpZyjZZOHF5SPnW0ELeAIKZ1pMUxMvLwrko kVDmatorlqFmpNhFe6Z2be90IHaFO/xWkXlZSW2rAE0/t65C5i/XAsvaFs9N211S8j0x LS19tAqeqEp0TBFFuvHeIEV//CUQSzPP0q6cEGEVQoHcG7MJRnWiRKFAOkS6dKJNUcKB XbfA== X-Gm-Message-State: ALoCoQl+fubunMw/X32JFnpjInnXGOv73Q3adSaLXUZK3wSscV59+fqtT3CP98y5lgdT/gYBopLv MIME-Version: 1.0 X-Received: by 10.112.125.33 with SMTP id mn1mr3848185lbb.82.1429817293213; Thu, 23 Apr 2015 12:28:13 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 23 Apr 2015 12:28:13 -0700 (PDT) In-Reply-To: <20150423190350.GB4421@elstar.local> References: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <20150423.203549.2054515192189852164.mbj@tail-f.com> <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> <20150423190350.GB4421@elstar.local> Date: Thu, 23 Apr 2015 12:28:13 -0700 Message-ID: <CABCOCHQcPiSHYr0hOg2YVFO2yue3JqMr28kojC55JjHk1p95nw@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/dtB1p9lJNveyN9ezCA4qhA6dNyg> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 19:28:28 -0000 On Thu, Apr 23, 2015 at 12:03 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 23, 2015 at 11:48:14AM -0700, Andy Bierman wrote: > >> Both foo and bar augment X. >> >> If foo imports X@R1 and bar imports X@R2 then IMO the server >> has to implement X@R2. I agree it is OK for foo to augment X >> and also bar to augment X. The augment of X@R1 should >> still work in X@R2. >> >> But we cannot be very sure that the "bar" augment of X@R2 >> will work with X@R1. > > Yes, if module authors create something like this, it will not be > implemented. The same is true for must statements that will never be > true. Let me try to explain my concern again... The authors of "bar" expect that module X rev 2 will be supported. That is why they used import-by-revision. Mixing typedefs and groupings from R2 and protocol accessible objects from R1 is not what they expect. They cannot possibly write their module "bar" for every possible combination of down-rev X modules the vendor may choose. It is not the fault of the designers if bar does not work with X@R1. They expect X@R2 to be used. Andy > >> IMO treating import-by-revision as "min-revision" >> means that the server can only choose newer than >> the specified import-by-revision, never lower than that. >> Using the typedefs and groupings from the specified revision >> may not mix well with augmented objects from a previous version. > > This is not what Y45-04 says. The imported revision is important for > resolving typedefs and groupings. There might be older versions that > define something that gets augmented and which has never changed since > then and in such a situation there is no reason to not allow this. > The set module combinations that can work together is orthogonal to > the question how typedef and grouping drift is avoided. > >> >> or the API will not be exactly as specified in the >> >> combined YANG modules, and will not be interoperable. >> > >> > This is where your idea of packages come in. Juergen has also pointed >> > this out. In a package, we can define a set of revisions of modules >> > and features that a server must implement in order to claim >> > conformance to the package. >> >> Well, we don't have conformance packages, just "inline complexity". > > The assumption is that we can add conformance packages later via > extensions. Addressing typedef and grouping drift is something we have > to as part of YANG 1.1 because this import semantics can't be changed > with extensions. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Thu Apr 23 12:54:18 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8851B321D for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:54:17 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-YWph1ljkSw for <netmod@ietfa.amsl.com>; Thu, 23 Apr 2015 12:54:15 -0700 (PDT) Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197501B3218 for <netmod@ietf.org>; Thu, 23 Apr 2015 12:54:06 -0700 (PDT) Received: from [192.168.2.32] ([73.8.162.228]) by p3plsmtpa06-03.prod.phx3.secureserver.net with id KXu41q0034vySjM01Xu4eB; Thu, 23 Apr 2015 12:54:05 -0700 Message-ID: <55394DDB.9000201@seguesoft.com> Date: Thu, 23 Apr 2015 14:54:03 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com References: <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <20150423.203549.2054515192189852164.mbj@tail-f.com> <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> <20150423.210426.472771978800503967.mbj@tail-f.com> In-Reply-To: <20150423.210426.472771978800503967.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/XnvZcFw2_sobm_FIVqshiWONK0I> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 23 Apr 2015 19:54:17 -0000 >>> But this can never work. Two separate modules might import two >>> different version of a common module. Then the server cannot >>> implement them. The only reasonable conclusion from this statement is >>> to remove import-by revision from YANG 1.1. (and then you really >>> didn't gain anything b/c the server can implement any version it >>> likes) >>> >> Both foo and bar augment X. >> >> If foo imports X@R1 and bar imports X@R2 then IMO the server >> has to implement X@R2. I agree it is OK for foo to augment X >> and also bar to augment X. The augment of X@R1 should >> still work in X@R2. >> >> But we cannot be very sure that the "bar" augment of X@R2 >> will work with X@R1. > Does this mean that your are ok with Y45-04, provided we change the > text about "any revision" to text about "any revision >= the imported > revision"? I think this is an important point. This way we are not completely redefining the meaning of "import" . So is my understanding below correct after reading this thread? If I want to use a particular typedef in an ancient version of foo , and also augment a node A in a newer version of foo (the ancient version of foo does not have node A defined), I must do: 1) Import foo with a revision-date that contains my particular typedef, 2) I must also at the same time, either import a version of foo that has node A defined, or import foo without revision, with a different prefix. (This way the reference to node A in my augment can only make sense) Thanks --Xiang From nobody Fri Apr 24 00:26:27 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FB21ACDE1 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 00:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvBouiSxyz25 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 00:26:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED901B351A for <netmod@ietf.org>; Fri, 24 Apr 2015 00:26:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DD0028F8; Fri, 24 Apr 2015 09:26:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id J7AjFZq6iOMy; Fri, 24 Apr 2015 09:26:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 24 Apr 2015 09:26:04 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0386820013; Fri, 24 Apr 2015 09:26:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wZjUyg9dj17C; Fri, 24 Apr 2015 09:26:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3A602002B; Fri, 24 Apr 2015 09:26:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E0D0D32CE0D1; Fri, 24 Apr 2015 09:26:01 +0200 (CEST) Date: Fri, 24 Apr 2015 09:26:01 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Xiang Li <xiangli@seguesoft.com> Message-ID: <20150424072600.GB5506@elstar.local> Mail-Followup-To: Xiang Li <xiangli@seguesoft.com>, Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com, netmod@ietf.org References: <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <20150423.203549.2054515192189852164.mbj@tail-f.com> <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> <20150423.210426.472771978800503967.mbj@tail-f.com> <55394DDB.9000201@seguesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55394DDB.9000201@seguesoft.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/CpMaEd1C-t5RNDVZAIjDCvYHnlA> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 07:26:26 -0000 On Thu, Apr 23, 2015 at 02:54:03PM -0500, Xiang Li wrote: > > So is my understanding below correct after reading this thread? > > If I want to use a particular typedef in an ancient version of foo , and > also augment a > node A in a newer version of foo (the ancient version of foo does not > have node A defined), > I must do: > > 1) Import foo with a revision-date that contains my particular typedef, > 2) I must also at the same time, either import a version of foo that > has node A defined, > or import foo without revision, with a different prefix. (This way > the reference to node A > in my augment can only make sense) > Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 24 00:38:01 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF61B352A for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 00:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS0R9q-Q9I_M for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 00:37:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D3D1ACDE1 for <netmod@ietf.org>; Fri, 24 Apr 2015 00:37:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 597E793B; Fri, 24 Apr 2015 09:37:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0kruKobFQnM9; Fri, 24 Apr 2015 09:37:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 24 Apr 2015 09:37:40 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 483992002B; Fri, 24 Apr 2015 09:37:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Mch7vpalwCt1; Fri, 24 Apr 2015 09:37:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A08FD20013; Fri, 24 Apr 2015 09:37:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ACD5232CE110; Fri, 24 Apr 2015 09:37:38 +0200 (CEST) Date: Fri, 24 Apr 2015 09:37:38 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150424073738.GC5506@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <20150423.203549.2054515192189852164.mbj@tail-f.com> <CABCOCHR-PL5stEnONGJAzTDEDdm3nk5E4SbFahJ-Z8UmTB=-5w@mail.gmail.com> <20150423190350.GB4421@elstar.local> <CABCOCHQcPiSHYr0hOg2YVFO2yue3JqMr28kojC55JjHk1p95nw@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHQcPiSHYr0hOg2YVFO2yue3JqMr28kojC55JjHk1p95nw@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/kxULksn7MfF0qFDgieylUTFyj14> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 07:38:00 -0000 On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: > > Let me try to explain my concern again... > > The authors of "bar" expect that module X rev 2 will be supported. > That is why they used import-by-revision. Mixing typedefs and > groupings from R2 and protocol accessible objects from R1 is not what > they expect. They cannot possibly write their module "bar" > for every possible combination of down-rev X modules the vendor may choose. > > It is not the fault of the designers if bar does not work with X@R1. > They expect X@R2 to be used. > I can easily construct cases where this may not be true nor problematic. If we make the interpretation min-revision, I am sure we will regret it at some point in time since we will have a hard time to ever retire an RFC because there is an incentive to always refer to the initial definition for the /interfaces container defined in ietf-interfaces.yang unless there is a specific need to require a newer revision. This is in particular a concern if ietf-interfaces.yang is updated with additions that do not at all affect the /interfaces container. The assumption that the set of imports used by all modules determines the version of modules a server implements does not work with the goal that a server implements exactly one version of every module. This only works if you have full control over the module revision process. Anyway, if the consensus is to make the semantics min-revision, I will go along with it. But I am convinced we will regret it at some point in time or we declare that we all moved to a newer version of a module but implementations will cheat. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 24 01:07:09 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F62D1B358D for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 01:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N94IFk9kUNk for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 01:07:05 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B54AA1B359E for <netmod@ietf.org>; Fri, 24 Apr 2015 01:06:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B80E51AE0476; Fri, 24 Apr 2015 10:06:44 +0200 (CEST) Date: Fri, 24 Apr 2015 10:06:44 +0200 (CEST) Message-Id: <20150424.100644.959374717987870887.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <20150424073738.GC5506@elstar.local> References: <20150423190350.GB4421@elstar.local> <CABCOCHQcPiSHYr0hOg2YVFO2yue3JqMr28kojC55JjHk1p95nw@mail.gmail.com> <20150424073738.GC5506@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/UyQvvN5uMdeTEGdXAK8BLclxsUk> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 08:07:08 -0000 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: > > > > Let me try to explain my concern again... > > > > The authors of "bar" expect that module X rev 2 will be supported. > > That is why they used import-by-revision. Mixing typedefs and > > groupings from R2 and protocol accessible objects from R1 is not what > > they expect. They cannot possibly write their module "bar" > > for every possible combination of down-rev X modules the vendor may choose. > > > > It is not the fault of the designers if bar does not work with X@R1. > > They expect X@R2 to be used. > > > > I can easily construct cases where this may not be true nor > problematic. If we make the interpretation min-revision, I am sure we > will regret it at some point in time I agree. The min-revision rule would be an unnecessary CLR. I asked before for an example of where the proposed solution is problematic, and where the min-revision would solve that. > since we will have a hard time to > ever retire an RFC because there is an incentive to always refer to > the initial definition for the /interfaces container defined in > ietf-interfaces.yang unless there is a specific need to require a > newer revision. This is in particular a concern if > ietf-interfaces.yang is updated with additions that do not at all > affect the /interfaces container. > > The assumption that the set of imports used by all modules determines > the version of modules a server implements does not work with the goal > that a server implements exactly one version of every module. This > only works if you have full control over the module revision process. > > Anyway, if the consensus is to make the semantics min-revision, I will > go along with it. But I am convinced we will regret it at some point > in time or we declare that we all moved to a newer version of a module > but implementations will cheat. I have updated the issues list with this solution, Y45-05. Maybe the chairs can do another poll for consensus on this issue? /martin From nobody Fri Apr 24 02:03:26 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47C1B3631 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 02:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7Mfkvb0Jd9k for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 02:03:23 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8A11B3669 for <netmod@ietf.org>; Fri, 24 Apr 2015 02:02:47 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 211861CC01DD; Fri, 24 Apr 2015 11:02:49 +0200 (CEST) From: Ladislav Lhotka <lhotka@nic.cz> To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod\@ietf.org" <netmod@ietf.org> In-Reply-To: <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 24 Apr 2015 11:02:46 +0200 Message-ID: <m2r3r9uceh.fsf@birdie.labs.nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/F-ZXNhTjKZC-BYiypSCbGBW_-t8> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 09:03:25 -0000 Andy Bierman <andy@yumaworks.com> writes: > On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: >> On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: >>> .... >>> >> >>> >> Where does it say this is not allowed? >>> > >>> > If a server implements a module A that imports B, and A augments B >>> > or has a leafref to a node in B, the server MUST implement *some >>> > version* of module B that has the nodes A references. This is >>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> > regardless of A imports B by revision or not. >>> > >>> > >>> > The whole idea is to decouple the revision-date used in the import in >>> > order to fix the typedef from the version needed for augment. >>> > >>> >>> This is the part that will really confuse users. >>> For augment-stmts, the revision-date is ignored >>> in import-by-revision. >> >> Not sure what 'ignored' means here. At module compile time, if a >> module refers to /b:bar than this /b:bar must resolve to something >> defined in the revision that is used by the compiler (and import by >> revision nails this down to an exact version). >> >>> IMO this will not work well because the designer will write >>> a module expecting the augmented module to be the >>> one specified by import-by-revision. >> >> Likely, but it can also be a newer revision of the module that you >> implement, no? >> >>> If 2 or more modules augment different versions of >>> the /bar container over time at least 1 of them will >>> be applied to the wrong version of the augmented module. >>> This will cause unpredictable results because YANG >>> statements can interact in complex ways (e.g., must/when). >> >> Sure, you can create something not implementable with must/when >> statements - you do not even need imports for that and this is >> part of YANG 1.0 as well. >> >>> >> So the server cannot just pick a revision of "base". >>> >> It must be aware of all the other modules that use "base" >>> >> and make sure all modules work together? >>> > >>> > Right. This is not different from how it works in YANG 1.0. >> >> I assume that modules that are not implementable (e.g., due to must >> constraints that can never be true) will not be implemented. I also >> assume that a server announcing a set of modules that can't be >> compiled together will receive appropriate customer feedback. >> >> What Y45-04 primarily fixes is any ambiguity at module compile time >> concerning the typedefs and groupings being used. The other problem >> space, namely what are meaningful combinations of modules, is not >> addressed by Y45-04 and left for further study. (I personally believe >> we need at some point in time something like packages but this >> hopefully can be done as a language extension; fixing the typedef and >> grouping drift is something we have to resolve in YANG 1.1 since it >> impacts the semantics of imports.) >> > > You missed my point. > > The authors of a module that imports a specific revision of > another module expect that the import-by-revision will > be honored. It should not be up to the vendor to pick a > down-rev version. The vendor MUST implement the version specified > in the import-stmt or the API will not be exactly as specified in the > combined YANG modules, and will not be interoperable. If import-by-revision already implies the server must implement that revision of the imported module, one can then ask why the server needs to advertise this module again. In fact, the semantics of import is often confusing for new users, see e.g. a recent pyang issue: https://github.com/mbj4668/pyang/issues/131 And for augments it's even weirder because an augment in fact *exports* stuff into the imported module. Lada > > >> /js >> > > Andy > >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 24 04:19:44 2015 Return-Path: <balazs.lengyel@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A781A8A7B for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 04:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaFL3Idovkb8 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 04:19:38 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2E51A8A56 for <netmod@ietf.org>; Fri, 24 Apr 2015 04:19:37 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-77-553a26c77a98 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.B0.28835.7C62A355; Fri, 24 Apr 2015 13:19:36 +0200 (CEST) Received: from [159.107.197.252] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.210.2; Fri, 24 Apr 2015 13:19:35 +0200 Message-ID: <553A26C7.1060406@ericsson.com> Date: Fri, 24 Apr 2015 13:19:35 +0200 From: Balazs Lengyel <balazs.lengyel@ericsson.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvje4JNatQg8vTeCzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxroZr9kKutgrZvcdZGlgXMvaxcjJISFgItHXcoQNwhaTuHBv PZDNxSEkcJRRovPpc3YIZy2jxJw125hAqngFtCVaPsxk7GLk4GARUJVYeacSJMwmYCQxtf88 C4gtKhAlMfHrIRaIckGJkzOfgNkiAuoSM3eCLODgEBZQkJg8NQ8kzCxgITFz/nlGCFteYvvb OcwgtpCAhsTDC39ZJzDyzUIyaRaSlllIWhYwMq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnE CAyog1t+W+1gPPjc8RCjAAejEg/vgsWWoUKsiWXFlbmHGKU5WJTEee2MD4UICaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYOT9xn01+GnbJn7GnE7/2Bbe+JurLvjVH1rwPTp8wm5x3n0hR08l TfKcsyw7sHm3jpO5qvAJxkD2EPmVjv9K1B5/nNcSIv1a+vouLsb6HRqTZGWZpD25N0q+Eij1 C5BZ77opjeMxMxfbuhXG/bm15zO1LJIUr8XuZLi0WEXsmPTB0AAD+U9pSizFGYmGWsxFxYkA XfYBBQkCAAA= Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/FBREJfyXMB1e7yz_W2mzxs9rKDM> Subject: [netmod] if-feature on key leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 11:19:43 -0000 Hello, While reviewing the YANG 1.1 draft I found the following: " A leaf that is a list key MUST NOT have any "if-feature" statements, unless the conditions specified in the "if-feature" statements are the same as the "if-feature" conditions in effect on the leaf's parent node." I simply fail to understand for what reason do we allow if-feature on key leafs. The leaf will be present or not following the same rules as its parent list. So if you have or don't have the if-feature on the leaf, the effect is exactly the same. Then why complicate things by allowing it on the leaf? I propose to simply state: A leaf that is a list key MUST NOT have any "if-feature" statements. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Fri Apr 24 04:42:40 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D6E1A8F36 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 04:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLv09xLyUTka for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 04:42:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597BB1A8BC5 for <netmod@ietf.org>; Fri, 24 Apr 2015 04:42:36 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 6B05B140428; Fri, 24 Apr 2015 13:42:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429875754; bh=zhiWG2wzrmNsl86THjstL+kGJO8uTviuo0ql7nRd3gY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Bc0q4MwZ2Q6nEaNXNcwvsp3hGsP6M3sjFfnfrEY2T3Z5S1QfTv+zeOKFMhXtRT7Vf s7pCnc8OULM5zwev++JVr5lzbYMAAaOuzqgdQMdFklBo1H0+4gGTaUmpZ2Ks1jMzD2 +7jhnsO+8SA8zAyDnECHr6ln1X01KCFJDBuduJPo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <553A26C7.1060406@ericsson.com> Date: Fri, 24 Apr 2015 13:42:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0966D713-453B-474E-A493-0DC719C05234@nic.cz> References: <553A26C7.1060406@ericsson.com> To: Balazs Lengyel <balazs.lengyel@ericsson.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/zppQYngRXiOyVn1ibTVDMJC1ERU> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] if-feature on key leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 11:42:38 -0000 > On 24 Apr 2015, at 13:19, Balazs Lengyel <balazs.lengyel@ericsson.com> = wrote: >=20 > Hello, > While reviewing the YANG 1.1 draft I found the following: > " A leaf that is a list key MUST NOT have any "if-feature" = statements, > unless the conditions specified in the "if-feature" statements are > the same as the "if-feature" conditions in effect on the leaf's > parent node." >=20 > I simply fail to understand for what reason do we allow if-feature on > key leafs. The leaf will be present or not following the same rules as > its parent list. So if you have or don't have the if-feature on the > leaf, the effect is exactly the same. Then why complicate things by > allowing it on the leaf? The only use case is when the key leaf is in a grouping and contains the = if-feature statement there. Lada=20 >=20 > I propose to simply state: > A leaf that is a list key MUST NOT have any "if-feature" statements. >=20 > regards Balazs >=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 24 04:50:53 2015 Return-Path: <balazs.lengyel@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85DF1A9008 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 04:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-rTSbVwbz9w for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 04:50:49 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000E01A9005 for <netmod@ietf.org>; Fri, 24 Apr 2015 04:50:48 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-74-553a2e1791de Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.A2.19337.71E2A355; Fri, 24 Apr 2015 13:50:47 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.111]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Fri, 24 Apr 2015 13:50:46 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= <balazs.lengyel@ericsson.com> To: Ladislav Lhotka <lhotka@nic.cz> Thread-Topic: [netmod] if-feature on key leafs Thread-Index: AQHQfoCT/6flu/+83U2azMKvle5nLJ1b6PoAgAAhp2A= Date: Fri, 24 Apr 2015 11:50:46 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11ECAD027@ESESSMB103.ericsson.se> References: <553A26C7.1060406@ericsson.com> <0966D713-453B-474E-A493-0DC719C05234@nic.cz> In-Reply-To: <0966D713-453B-474E-A493-0DC719C05234@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja64nlWoweoTQhYXVs1ls5h/sZHV gcljyZKfTB6bLt9hDGCK4rJJSc3JLEst0rdL4MqY3tfNUrCDt+Jdl2wD4z6uLkZODgkBE4kt p8+yQthiEhfurWfrYuTiEBI4yiixbuE9KGcJo8Tam8fBqtgEXCWOffrOAmKLCChLXJzwE8xm FlCXuHPqMRuILSygK3Hzz31miBo9iUt9u6BsK4kD/84ygtgsAqoSi+bOAevlFfCVOPj3Mth8 IYFoiSl9r8FqOIHq+1+dZAKxGYGu+35qDRPELnGJW0/mM0FcLSCxZM95ZghbVOLl439AcziA bCWJaVvTIMr1JG5MncIGYWtLLFv4mhliraDEyZlPWCYwis1CMnUWkpZZSFpmIWlZwMiyilG0 OLU4KTfdyFgvtSgzubg4P08vL7VkEyMweg5u+a26g/HyG8dDjAIcjEo8vAsWW4YKsSaWFVfm HmKU5mBREue1Mz4UIiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR98P0oOjzby1bzm3jvj5Z Zs0Em92lV3elzkgrSubWetqeoD5nZZzaTsYKV+a9h4qPOiY4T2LJS9t+YcKz5YXbqm6WHPXU 8nsx9f2zzprtmbsEeaMlDr+InxW6Lv9aeJGNmUG6U0UxT1Jt/6fzF9fM3+1/pKDvOOcHyfZp W0IjOLewLAxrCrBSYinOSDTUYi4qTgQAadWEw38CAAA= Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ErZOnK4xUUX4a1H3hbk1MJd9ER4> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] if-feature on key leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 11:50:50 -0000 Even in a grouping case you still need to put the exact same if-feature on = the list. SO what do you gain? Balazs -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Friday, 24 April, 2015 13:43 To: Bal=E1zs Lengyel Cc: netmod@ietf.org Subject: Re: [netmod] if-feature on key leafs > On 24 Apr 2015, at 13:19, Balazs Lengyel <balazs.lengyel@ericsson.com> wr= ote: >=20 > Hello, > While reviewing the YANG 1.1 draft I found the following: > " A leaf that is a list key MUST NOT have any "if-feature" statements, > unless the conditions specified in the "if-feature" statements are > the same as the "if-feature" conditions in effect on the leaf's > parent node." >=20 > I simply fail to understand for what reason do we allow if-feature on=20 > key leafs. The leaf will be present or not following the same rules as=20 > its parent list. So if you have or don't have the if-feature on the=20 > leaf, the effect is exactly the same. Then why complicate things by=20 > allowing it on the leaf? The only use case is when the key leaf is in a grouping and contains the if= -feature statement there. Lada=20 >=20 > I propose to simply state: > A leaf that is a list key MUST NOT have any "if-feature" statements. >=20 > regards Balazs >=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 24 05:03:43 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA79B1A9130 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLVxZSdUTLxw for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:03:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBB51A9173 for <netmod@ietf.org>; Fri, 24 Apr 2015 05:03:15 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:e9fc:db6c:4c87:3bf5] (unknown [IPv6:2001:718:1a02:1:e9fc:db6c:4c87:3bf5]) by mail.nic.cz (Postfix) with ESMTPSA id 88C7F140428; Fri, 24 Apr 2015 14:03:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429876993; bh=7XB0AvRxA5hhceGWgaVLKjZ4L+EJcrY9D8qVzmS7Ldc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=F9iHXYD1siMRQVPYHcBWNYtwxJKtzJHosoiFIIhVMszzkMsUm9lbOrTMoBh5EX6Kh dQqa0qdDtStd/2wC4/uID854L+xkXdG9c+Sd2+l/mw/34QmblcDtiYW1V0eKZ+QAS/ arhDmRfI7ALj81s9pdT1ifNjpAjgXZcm/mbnbebo= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <971D4B790EC8B846BE223DD23AF72FF11ECAD027@ESESSMB103.ericsson.se> Date: Fri, 24 Apr 2015 14:03:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <DED7E768-5E37-4321-BCC1-9D25EF9C7D37@nic.cz> References: <553A26C7.1060406@ericsson.com> <0966D713-453B-474E-A493-0DC719C05234@nic.cz> <971D4B790EC8B846BE223DD23AF72FF11ECAD027@ESESSMB103.ericsson.se> To: Balazs Lengyel <balazs.lengyel@ericsson.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/evY2XnCR9OogqSSVxXJE9QOd9wI> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] if-feature on key leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 12:03:42 -0000 > On 24 Apr 2015, at 13:50, Bal=E1zs Lengyel = <balazs.lengyel@ericsson.com> wrote: >=20 > Even in a grouping case you still need to put the exact same = if-feature on the list. SO what do you gain? You may want to use the same grouping elsewhere (not in a list) and then = the if-feature may come into play. That said, I supported Y07-03, so I am not the right person to defend = Y07-01. In any case, making if-feature on keys illegal could possibly make some YANG 1.0 modules = invalid, which is against the charter. Lada=20 > Balazs >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 > Sent: Friday, 24 April, 2015 13:43 > To: Bal=E1zs Lengyel > Cc: netmod@ietf.org > Subject: Re: [netmod] if-feature on key leafs >=20 >=20 >> On 24 Apr 2015, at 13:19, Balazs Lengyel = <balazs.lengyel@ericsson.com> wrote: >>=20 >> Hello, >> While reviewing the YANG 1.1 draft I found the following: >> " A leaf that is a list key MUST NOT have any "if-feature" = statements, >> unless the conditions specified in the "if-feature" statements are >> the same as the "if-feature" conditions in effect on the leaf's >> parent node." >>=20 >> I simply fail to understand for what reason do we allow if-feature on=20= >> key leafs. The leaf will be present or not following the same rules = as=20 >> its parent list. So if you have or don't have the if-feature on the=20= >> leaf, the effect is exactly the same. Then why complicate things by=20= >> allowing it on the leaf? >=20 > The only use case is when the key leaf is in a grouping and contains = the if-feature statement there. >=20 > Lada=20 >=20 >>=20 >> I propose to simply state: >> A leaf that is a list key MUST NOT have any "if-feature" statements. >>=20 >> regards Balazs >>=20 >>=20 >> --=20 >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 24 05:36:14 2015 Return-Path: <balazs.lengyel@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420B1B2D76 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2PpvCva2jsq for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:36:11 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D101B2D74 for <netmod@ietf.org>; Fri, 24 Apr 2015 05:36:10 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-c7-553a38b86d29 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.35.28835.8B83A355; Fri, 24 Apr 2015 14:36:08 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.111]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Fri, 24 Apr 2015 14:36:07 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= <balazs.lengyel@ericsson.com> To: Ladislav Lhotka <lhotka@nic.cz> Thread-Topic: [netmod] if-feature on key leafs Thread-Index: AQHQfoCT/6flu/+83U2azMKvle5nLJ1b6PoAgAAhp2D//+QcAIAAKU3A Date: Fri, 24 Apr 2015 12:36:06 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11ECAD0DE@ESESSMB103.ericsson.se> References: <553A26C7.1060406@ericsson.com> <0966D713-453B-474E-A493-0DC719C05234@nic.cz> <971D4B790EC8B846BE223DD23AF72FF11ECAD027@ESESSMB103.ericsson.se> <DED7E768-5E37-4321-BCC1-9D25EF9C7D37@nic.cz> In-Reply-To: <DED7E768-5E37-4321-BCC1-9D25EF9C7D37@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje4OC6tQgxOvNS0urJrLZjH/YiOr A5PHkiU/mTw2Xb7DGMAUxWWTkpqTWZZapG+XwJVx5PdixoIPohU3/n9la2BcJNjFyMkhIWAi MXXHfVYIW0ziwr31bCC2kMBRRonedXldjFxA9hJGiT0nLjCCJNgEXCWOffrOAmKLCChLXJzw E8xmFlCXuHPqMVizsICuxM0/95khavQkLvXtgrLdJB7fOQlWzyKgKvF/3WWwOK+Ar8TqZV+Y IZadZ5Q4trEJLMEpYCVx9vAjsMWMQNd9P7WGCWKZuMStJ/OZIK4WkFiy5zwzhC0q8fLxP6hv FCV2nm1nhqjXk7gxdQobhK0tsWzha6jFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRtHi 1OLi3HQjI73Uoszk4uL8PL281JJNjMAIOrjlt9UOxoPPHQ8xCnAwKvHwLlhsGSrEmlhWXJl7 iFGag0VJnNfO+FCIkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbz2uUecksWBBXlnhHRjolm lf7Lmbrfcv7HZ4oLZ3CXx6WxxS5iWJT6ccsrQdGJLQ3fwiaoPe6e7zXhVkbULA4p08NqJ7Kn rvf/p2Z/XXP9fJ7PPbEtsvwFi12mpBQVLs96lsrS+irp8sOSLUEaEn8Eve48mno5NIPl2dTJ U1puTdu68Zgqo78SS3FGoqEWc1FxIgDNhjU8gQIAAA== Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/JlhskDHCgIeW8TL92ywn8QfwsmQ> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] if-feature on key leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 12:36:12 -0000 We are anyway restricting if-feature on key leafs compared to YANG 1.0 so w= e are already backwards incompatible. However in this case this is more of = a bugfix then a true incompatibility. IMHO the grouping use case is really-really a corner case. Regards Balazs -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Friday, 24 April, 2015 14:03 To: Bal=E1zs Lengyel Cc: netmod@ietf.org Subject: Re: [netmod] if-feature on key leafs > On 24 Apr 2015, at 13:50, Bal=E1zs Lengyel <balazs.lengyel@ericsson.com> = wrote: >=20 > Even in a grouping case you still need to put the exact same if-feature o= n the list. SO what do you gain? You may want to use the same grouping elsewhere (not in a list) and then th= e if-feature may come into play. That said, I supported Y07-03, so I am not the right person to defend Y07-0= 1. In any case, making if-feature on keys illegal could possibly make some = YANG 1.0 modules invalid, which is against the charter. Lada=20 > Balazs >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Friday, 24 April, 2015 13:43 > To: Bal=E1zs Lengyel > Cc: netmod@ietf.org > Subject: Re: [netmod] if-feature on key leafs >=20 >=20 >> On 24 Apr 2015, at 13:19, Balazs Lengyel <balazs.lengyel@ericsson.com> w= rote: >>=20 >> Hello, >> While reviewing the YANG 1.1 draft I found the following: >> " A leaf that is a list key MUST NOT have any "if-feature" statements, >> unless the conditions specified in the "if-feature" statements are =20 >> the same as the "if-feature" conditions in effect on the leaf's =20 >> parent node." >>=20 >> I simply fail to understand for what reason do we allow if-feature on=20 >> key leafs. The leaf will be present or not following the same rules=20 >> as its parent list. So if you have or don't have the if-feature on=20 >> the leaf, the effect is exactly the same. Then why complicate things=20 >> by allowing it on the leaf? >=20 > The only use case is when the key leaf is in a grouping and contains the = if-feature statement there. >=20 > Lada >=20 >>=20 >> I propose to simply state: >> A leaf that is a list key MUST NOT have any "if-feature" statements. >>=20 >> regards Balazs >>=20 >>=20 >> --=20 >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 24 05:38:08 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17F21B2D9A for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiL4qYmW-rVr for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:38:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6577B1B2D96 for <netmod@ietf.org>; Fri, 24 Apr 2015 05:38:00 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:e9fc:db6c:4c87:3bf5] (unknown [IPv6:2001:718:1a02:1:e9fc:db6c:4c87:3bf5]) by mail.nic.cz (Postfix) with ESMTPSA id D316B14094F; Fri, 24 Apr 2015 14:37:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1429879078; bh=TC3+vjieHZjgBISAcmmP5JBH44KJ+/2vdrGo47umuHk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=C2ziCRzNvQ5Bpoz7xQjiPHsV5yHpjo7XkgPWapr95I+wQsbsIxm355oGbmFZl5qLd eZuO5VHWhfnKXuMrhIkKoV6JhlAu1LjXgf0uIgYf0wy5BVdIceBYH0Gn9PkVCFA6Z4 LAwk/WRajs3tMhG10zxZ18wIXAYRFPEuKd9nUnzU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <971D4B790EC8B846BE223DD23AF72FF11ECAD0DE@ESESSMB103.ericsson.se> Date: Fri, 24 Apr 2015 14:37:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33A10600-09D2-4586-A6C5-ED5EDEBBDE2F@nic.cz> References: <553A26C7.1060406@ericsson.com> <0966D713-453B-474E-A493-0DC719C05234@nic.cz> <971D4B790EC8B846BE223DD23AF72FF11ECAD027@ESESSMB103.ericsson.se> <DED7E768-5E37-4321-BCC1-9D25EF9C7D37@nic.cz> <971D4B790EC8B846BE223DD23AF72FF11ECAD0DE@ESESSMB103.ericsson.se> To: Balazs Lengyel <balazs.lengyel@ericsson.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/nGNyX_pmY7KxCH_DFTBSvjETGKQ> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] if-feature on key leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 12:38:03 -0000 > On 24 Apr 2015, at 14:36, Bal=E1zs Lengyel = <balazs.lengyel@ericsson.com> wrote: >=20 > We are anyway restricting if-feature on key leafs compared to YANG 1.0 = so we are already backwards incompatible. However in this case this is = more of a bugfix then a true incompatibility. > IMHO the grouping use case is really-really a corner case. I fully agree with you. :-) Lada >=20 > Regards Balazs >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 > Sent: Friday, 24 April, 2015 14:03 > To: Bal=E1zs Lengyel > Cc: netmod@ietf.org > Subject: Re: [netmod] if-feature on key leafs >=20 >=20 >> On 24 Apr 2015, at 13:50, Bal=E1zs Lengyel = <balazs.lengyel@ericsson.com> wrote: >>=20 >> Even in a grouping case you still need to put the exact same = if-feature on the list. SO what do you gain? >=20 > You may want to use the same grouping elsewhere (not in a list) and = then the if-feature may come into play. >=20 > That said, I supported Y07-03, so I am not the right person to defend = Y07-01. In any case, making if-feature on keys illegal could possibly = make some YANG 1.0 modules invalid, which is against the charter. >=20 > Lada=20 >=20 >> Balazs >>=20 >> -----Original Message----- >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] >> Sent: Friday, 24 April, 2015 13:43 >> To: Bal=E1zs Lengyel >> Cc: netmod@ietf.org >> Subject: Re: [netmod] if-feature on key leafs >>=20 >>=20 >>> On 24 Apr 2015, at 13:19, Balazs Lengyel = <balazs.lengyel@ericsson.com> wrote: >>>=20 >>> Hello, >>> While reviewing the YANG 1.1 draft I found the following: >>> " A leaf that is a list key MUST NOT have any "if-feature" = statements, >>> unless the conditions specified in the "if-feature" statements are =20= >>> the same as the "if-feature" conditions in effect on the leaf's =20 >>> parent node." >>>=20 >>> I simply fail to understand for what reason do we allow if-feature = on=20 >>> key leafs. The leaf will be present or not following the same rules=20= >>> as its parent list. So if you have or don't have the if-feature on=20= >>> the leaf, the effect is exactly the same. Then why complicate things=20= >>> by allowing it on the leaf? >>=20 >> The only use case is when the key leaf is in a grouping and contains = the if-feature statement there. >>=20 >> Lada >>=20 >>>=20 >>> I propose to simply state: >>> A leaf that is a list key MUST NOT have any "if-feature" statements. >>>=20 >>> regards Balazs >>>=20 >>>=20 >>> --=20 >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 >>> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Apr 24 05:43:02 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A471B2DBB for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jws1IkvouL1 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:42:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6803E1B2DB5 for <netmod@ietf.org>; Fri, 24 Apr 2015 05:42:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 396136DD; Fri, 24 Apr 2015 14:42:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jwrC0hnbRLkF; Fri, 24 Apr 2015 14:42:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 24 Apr 2015 14:42:54 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB0602002B; Fri, 24 Apr 2015 14:42:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aDmzdrUjWX7w; Fri, 24 Apr 2015 14:42:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D274B20013; Fri, 24 Apr 2015 14:42:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0792932CE4D3; Fri, 24 Apr 2015 14:42:51 +0200 (CEST) Date: Fri, 24 Apr 2015 14:42:51 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Ladislav Lhotka <lhotka@nic.cz> Message-ID: <20150424124251.GA6132@elstar.local> Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <m2r3r9uceh.fsf@birdie.labs.nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/w37ICjkUnEexvyKflq2KomZ5x2M> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 12:43:00 -0000 On Fri, Apr 24, 2015 at 11:02:46AM +0200, Ladislav Lhotka wrote: > Andy Bierman <andy@yumaworks.com> writes: > > > On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder > > <j.schoenwaelder@jacobs-university.de> wrote: > >> On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: > >>> .... > >>> >> > >>> >> Where does it say this is not allowed? > >>> > > >>> > If a server implements a module A that imports B, and A augments B > >>> > or has a leafref to a node in B, the server MUST implement *some > >>> > version* of module B that has the nodes A references. This is > >>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> > regardless of A imports B by revision or not. > >>> > > >>> > > >>> > The whole idea is to decouple the revision-date used in the import in > >>> > order to fix the typedef from the version needed for augment. > >>> > > >>> > >>> This is the part that will really confuse users. > >>> For augment-stmts, the revision-date is ignored > >>> in import-by-revision. > >> > >> Not sure what 'ignored' means here. At module compile time, if a > >> module refers to /b:bar than this /b:bar must resolve to something > >> defined in the revision that is used by the compiler (and import by > >> revision nails this down to an exact version). > >> > >>> IMO this will not work well because the designer will write > >>> a module expecting the augmented module to be the > >>> one specified by import-by-revision. > >> > >> Likely, but it can also be a newer revision of the module that you > >> implement, no? > >> > >>> If 2 or more modules augment different versions of > >>> the /bar container over time at least 1 of them will > >>> be applied to the wrong version of the augmented module. > >>> This will cause unpredictable results because YANG > >>> statements can interact in complex ways (e.g., must/when). > >> > >> Sure, you can create something not implementable with must/when > >> statements - you do not even need imports for that and this is > >> part of YANG 1.0 as well. > >> > >>> >> So the server cannot just pick a revision of "base". > >>> >> It must be aware of all the other modules that use "base" > >>> >> and make sure all modules work together? > >>> > > >>> > Right. This is not different from how it works in YANG 1.0. > >> > >> I assume that modules that are not implementable (e.g., due to must > >> constraints that can never be true) will not be implemented. I also > >> assume that a server announcing a set of modules that can't be > >> compiled together will receive appropriate customer feedback. > >> > >> What Y45-04 primarily fixes is any ambiguity at module compile time > >> concerning the typedefs and groupings being used. The other problem > >> space, namely what are meaningful combinations of modules, is not > >> addressed by Y45-04 and left for further study. (I personally believe > >> we need at some point in time something like packages but this > >> hopefully can be done as a language extension; fixing the typedef and > >> grouping drift is something we have to resolve in YANG 1.1 since it > >> impacts the semantics of imports.) > >> > > > > You missed my point. > > > > The authors of a module that imports a specific revision of > > another module expect that the import-by-revision will > > be honored. It should not be up to the vendor to pick a > > down-rev version. The vendor MUST implement the version specified > > in the import-stmt or the API will not be exactly as specified in the > > combined YANG modules, and will not be interoperable. > > If import-by-revision already implies the server must implement that > revision of the imported module, one can then ask why the server needs > to advertise this module again. > > In fact, the semantics of import is often confusing for new users, see > e.g. a recent pyang issue: > > https://github.com/mbj4668/pyang/issues/131 > > And for augments it's even weirder because an augment in fact *exports* > stuff into the imported module. Whether this is a bug or feature of pyang can be debated but at the end it not so relevant. The key here is to recognize that resolution of references at module compile time is one thing and module versions implemented on a server is another thing. This is almost like in C: the compiler (or pre-processor) cares about the definitions (or headers) you import, the linker cares of resolving symbol dependencies. The libraries that make up your program are not determined by the #include, they are at best implied by the #includes but even then ultimately it is the symbol references in your object files that matter. The import statement must take care of determining which definitions are used when a module is compiled. The module announcement says which module versions have been 'linked' together in an implementation. And in the future, we may define packages of modules (and their versions) that serve certain use cases. But the idea is that this can be detached from the YANG 1.1 work where we have to clarify how we deal with typedef and grouping drift. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 24 05:46:13 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174371B2DD3 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb-MkzV4FaNm for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 05:46:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B961B2D80 for <netmod@ietf.org>; Fri, 24 Apr 2015 05:46:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 823DBA53; Fri, 24 Apr 2015 14:46:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ghgl3uYVSlHC; Fri, 24 Apr 2015 14:46:06 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 24 Apr 2015 14:46:09 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBC2F2002B; Fri, 24 Apr 2015 14:46:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M6F9lkzTX4dA; Fri, 24 Apr 2015 14:46:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12B6520013; Fri, 24 Apr 2015 14:46:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 08F2932CE50A; Fri, 24 Apr 2015 14:46:09 +0200 (CEST) Date: Fri, 24 Apr 2015 14:46:08 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: =?iso-8859-1?Q?Bal=E1zs?= Lengyel <balazs.lengyel@ericsson.com> Message-ID: <20150424124608.GB6132@elstar.local> Mail-Followup-To: =?iso-8859-1?Q?Bal=E1zs?= Lengyel <balazs.lengyel@ericsson.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org> References: <553A26C7.1060406@ericsson.com> <0966D713-453B-474E-A493-0DC719C05234@nic.cz> <971D4B790EC8B846BE223DD23AF72FF11ECAD027@ESESSMB103.ericsson.se> <DED7E768-5E37-4321-BCC1-9D25EF9C7D37@nic.cz> <971D4B790EC8B846BE223DD23AF72FF11ECAD0DE@ESESSMB103.ericsson.se> 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: <971D4B790EC8B846BE223DD23AF72FF11ECAD0DE@ESESSMB103.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/aqMc4s35yZ-S4_lG0QmPwR6tQhg> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] if-feature on key leafs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 12:46:13 -0000 On Fri, Apr 24, 2015 at 12:36:06PM +0000, Balzs Lengyel wrote: > We are anyway restricting if-feature on key leafs compared to YANG > 1.0 so we are already backwards incompatible. However in this case > this is more of a bugfix then a true incompatibility. IMHO the > grouping use case is really-really a corner case. Perhaps this is not terribly useful but then there are a number of things that are legal and perhaps not terribly useful. It can be dangerous to rule out stuff because of 'who would ever do it' and then later someone has to do extra work to ensure that if-feature definitions are not repeated, e.g., when translating from other models into YANG. Since it was not considered broken to repeat stuff, I would rather not touch this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 24 08:00:12 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C77E1ACDE9 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4AMA80QyfFH for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 08:00:08 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 183761ACDF1 for <netmod@ietf.org>; Fri, 24 Apr 2015 08:00:07 -0700 (PDT) Received: by layy10 with SMTP id y10so37335364lay.0 for <netmod@ietf.org>; Fri, 24 Apr 2015 08:00:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=MH04ZBd0qJkYqdkjT4wYNBrUSM7US6CByOFbITx6cvQ=; b=aaaWVT2rtyB1YPKKFWJnQKeUvNvBwqI1F8npIrD15mTM6uIj2dWVFhBF8K4u+W6533 /YEJegUCA5O6TaLqmcMeLGWF+c5K5u3Irh+Fj+e6Oe50iTScGT/kQUdgSb3MlNvfB1ek hwn4oFImSv8TOxtrYbxxXBmH+a1Vf89mV0Auq+foR9MbPk9aT+lapOmoHpmlp/wSLnvx qE4Av2X4UdIyokMAotGr6b8HY5PK1Hzo18cwFcTog1PXyOlxTTGwHO3vSUwUylLQRhKc hdfN0w5OkEsXgFVf39MK8mudHEq4zxmF8tqGAxw9bgfbGYIHlmoNZkfZDJjUvdCHNLDZ zYlw== X-Gm-Message-State: ALoCoQnAX6gmz2jW5O5TjBj7ZRI9gdbu9vMqhRpDNHrUdtjP5hVFVlQJNCADd9qzMn2GmyeFU795 MIME-Version: 1.0 X-Received: by 10.112.130.129 with SMTP id oe1mr7106905lbb.37.1429887605470; Fri, 24 Apr 2015 08:00:05 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 24 Apr 2015 08:00:05 -0700 (PDT) In-Reply-To: <20150424124251.GA6132@elstar.local> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> <20150424124251.GA6132@elstar.local> Date: Fri, 24 Apr 2015 08:00:05 -0700 Message-ID: <CABCOCHQjwkF4QCo5d37YuQfzk2bR5KwzycwK3QB9wJW1dAsLpA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/AEjAvbeWcbx3gZ4BQhgFFCN5pqw> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 15:00:10 -0000 Hi, >From a conformance POV, letting the vendor choose among many obsolete revisions and still claim conformance it totally broken. The data model writers are supposed to specify conformance at module-write-time, The vendor should not be specifying conformance at module-load-time. The goal of conformance is to specify what the client and server are supposed to implement. The goal of server capability discovery is to specify what the server actually implements. I think the WG is confused (or ignoring) the difference. Andy On Fri, Apr 24, 2015 at 5:42 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Apr 24, 2015 at 11:02:46AM +0200, Ladislav Lhotka wrote: >> Andy Bierman <andy@yumaworks.com> writes: >> >> > On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder >> > <j.schoenwaelder@jacobs-university.de> wrote: >> >> On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: >> >>> .... >> >>> >> >> >>> >> Where does it say this is not allowed? >> >>> > >> >>> > If a server implements a module A that imports B, and A augments B >> >>> > or has a leafref to a node in B, the server MUST implement *some >> >>> > version* of module B that has the nodes A references. This is >> >>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >>> > regardless of A imports B by revision or not. >> >>> > >> >>> > >> >>> > The whole idea is to decouple the revision-date used in the import in >> >>> > order to fix the typedef from the version needed for augment. >> >>> > >> >>> >> >>> This is the part that will really confuse users. >> >>> For augment-stmts, the revision-date is ignored >> >>> in import-by-revision. >> >> >> >> Not sure what 'ignored' means here. At module compile time, if a >> >> module refers to /b:bar than this /b:bar must resolve to something >> >> defined in the revision that is used by the compiler (and import by >> >> revision nails this down to an exact version). >> >> >> >>> IMO this will not work well because the designer will write >> >>> a module expecting the augmented module to be the >> >>> one specified by import-by-revision. >> >> >> >> Likely, but it can also be a newer revision of the module that you >> >> implement, no? >> >> >> >>> If 2 or more modules augment different versions of >> >>> the /bar container over time at least 1 of them will >> >>> be applied to the wrong version of the augmented module. >> >>> This will cause unpredictable results because YANG >> >>> statements can interact in complex ways (e.g., must/when). >> >> >> >> Sure, you can create something not implementable with must/when >> >> statements - you do not even need imports for that and this is >> >> part of YANG 1.0 as well. >> >> >> >>> >> So the server cannot just pick a revision of "base". >> >>> >> It must be aware of all the other modules that use "base" >> >>> >> and make sure all modules work together? >> >>> > >> >>> > Right. This is not different from how it works in YANG 1.0. >> >> >> >> I assume that modules that are not implementable (e.g., due to must >> >> constraints that can never be true) will not be implemented. I also >> >> assume that a server announcing a set of modules that can't be >> >> compiled together will receive appropriate customer feedback. >> >> >> >> What Y45-04 primarily fixes is any ambiguity at module compile time >> >> concerning the typedefs and groupings being used. The other problem >> >> space, namely what are meaningful combinations of modules, is not >> >> addressed by Y45-04 and left for further study. (I personally believe >> >> we need at some point in time something like packages but this >> >> hopefully can be done as a language extension; fixing the typedef and >> >> grouping drift is something we have to resolve in YANG 1.1 since it >> >> impacts the semantics of imports.) >> >> >> > >> > You missed my point. >> > >> > The authors of a module that imports a specific revision of >> > another module expect that the import-by-revision will >> > be honored. It should not be up to the vendor to pick a >> > down-rev version. The vendor MUST implement the version specified >> > in the import-stmt or the API will not be exactly as specified in the >> > combined YANG modules, and will not be interoperable. >> >> If import-by-revision already implies the server must implement that >> revision of the imported module, one can then ask why the server needs >> to advertise this module again. >> >> In fact, the semantics of import is often confusing for new users, see >> e.g. a recent pyang issue: >> >> https://github.com/mbj4668/pyang/issues/131 >> >> And for augments it's even weirder because an augment in fact *exports* >> stuff into the imported module. > > Whether this is a bug or feature of pyang can be debated but at the > end it not so relevant. > > The key here is to recognize that resolution of references at module > compile time is one thing and module versions implemented on a server > is another thing. This is almost like in C: the compiler (or > pre-processor) cares about the definitions (or headers) you import, > the linker cares of resolving symbol dependencies. The libraries that > make up your program are not determined by the #include, they are at > best implied by the #includes but even then ultimately it is the > symbol references in your object files that matter. > > The import statement must take care of determining which definitions > are used when a module is compiled. The module announcement says which > module versions have been 'linked' together in an implementation. And > in the future, we may define packages of modules (and their versions) > that serve certain use cases. But the idea is that this can be > detached from the YANG 1.1 work where we have to clarify how we deal > with typedef and grouping drift. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 24 08:13:45 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEBC1A883A for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4acNTaM7bBL for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 08:13:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2ECB1A89ED for <netmod@ietf.org>; Fri, 24 Apr 2015 08:13:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 759FD6FA; Fri, 24 Apr 2015 17:13:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tYpThkmBKUPP; Fri, 24 Apr 2015 17:13:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 24 Apr 2015 17:13:40 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82CA52002B; Fri, 24 Apr 2015 17:13:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fG47K0isUBd7; Fri, 24 Apr 2015 17:13:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85C3E20013; Fri, 24 Apr 2015 17:13:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A2AC932CEB07; Fri, 24 Apr 2015 17:13:38 +0200 (CEST) Date: Fri, 24 Apr 2015 17:13:38 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150424151338.GA6855@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> <20150424124251.GA6132@elstar.local> <CABCOCHQjwkF4QCo5d37YuQfzk2bR5KwzycwK3QB9wJW1dAsLpA@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHQjwkF4QCo5d37YuQfzk2bR5KwzycwK3QB9wJW1dAsLpA@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/KuZfwDFxMeiSlW497qRo_oWAVkY> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 15:13:44 -0000 On Fri, Apr 24, 2015 at 08:00:05AM -0700, Andy Bierman wrote: > Hi, > > From a conformance POV, letting the vendor choose among > many obsolete revisions and still claim conformance > it totally broken. The data model writers are supposed > to specify conformance at module-write-time, > The vendor should not be specifying conformance at > module-load-time. > > The goal of conformance is to specify what the client and server > are supposed to implement. The goal of server capability discovery > is to specify what the server actually implements. I think the WG is > confused (or ignoring) the difference. > Sure, I may be confused. But let me try to explain again how I look at this: a) With Y45-04, we are fixing the typedef drift and grouping drift problem. This is an important module compile time issue. Fixing this makes it unambiguous at module compile time what the definitions resolve to. b) A server announces the modules and the revisions it implements via the yang library data model. This covers the 'server capability discovery' you mention above. (Note: Once I have the modules at their specific revisions, I can can compile them without any typedef drift and grouping drift issues.) c) The part that we do not cover is the 'specification of conformance that a server has to implement' (to support certain use cases). This is what we assume to be able to cover in the future using language extensions (and you wrote a pretty decent proposal for this a while ago). I think I learned during the many discussions that the idea to derive c) out of the imports is not workable. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 24 08:54:13 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356631B3090 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 08:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFKJd_-AS3d9 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 08:54:10 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 574441A6EE1 for <netmod@ietf.org>; Fri, 24 Apr 2015 08:54:10 -0700 (PDT) Received: by labbd9 with SMTP id bd9so38465410lab.2 for <netmod@ietf.org>; Fri, 24 Apr 2015 08:54:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=sABMJU88yQcJYxPmPCOpnSTuCGZ3ZJ3CC2uVOypPjHo=; b=RU4MqW6QqCbnYltAhjLzsreTBJQnbwqyKNN3wcysQmOI8bvE2lyVXvwY61/Em61Id5 usoTZDMpbEifCi82WUO18FesvvgL+R2AuKjOWLT7LRf73K8DKtRQ9MiBF/YK+ric5cZ1 fV+T3OENysn2jBsWpVg1McU2fnCqNehz2szniaIVZyjY5hgce4I+uNRNROblKLVF9qS5 dx3BigRgeWBRg/SuRjsfvsgm2QGfvE2qLSyc/I1O32h/FdFolvlbZLfEiXZx8l3zDMb2 Qr0MbBDtcOsKT5CZDti3upSBt1ybB2xsNdTFd6oJD0nDuLmspRTbjCACB8I1fDNotOq4 PSSA== X-Gm-Message-State: ALoCoQnss/x71Wh5Xurlf9Gn5qt5h3eLVJsyAqnbK3hgHhv1H7f3vcza8rrtkmZxmdCbbriua7vT MIME-Version: 1.0 X-Received: by 10.152.8.231 with SMTP id u7mr7295257laa.37.1429890848821; Fri, 24 Apr 2015 08:54:08 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 24 Apr 2015 08:54:08 -0700 (PDT) In-Reply-To: <20150424151338.GA6855@elstar.local> References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> <20150424124251.GA6132@elstar.local> <CABCOCHQjwkF4QCo5d37YuQfzk2bR5KwzycwK3QB9wJW1dAsLpA@mail.gmail.com> <20150424151338.GA6855@elstar.local> Date: Fri, 24 Apr 2015 08:54:08 -0700 Message-ID: <CABCOCHQXZks8xjkbwcdSuM5T08gB=E9Yx-jZGCiy0T22xVW0SA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/Qznbr9obLFpkAsAsKDUeVAtmKtM> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 15:54:12 -0000 On Fri, Apr 24, 2015 at 8:13 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Apr 24, 2015 at 08:00:05AM -0700, Andy Bierman wrote: >> Hi, >> >> From a conformance POV, letting the vendor choose among >> many obsolete revisions and still claim conformance >> it totally broken. The data model writers are supposed >> to specify conformance at module-write-time, >> The vendor should not be specifying conformance at >> module-load-time. >> >> The goal of conformance is to specify what the client and server >> are supposed to implement. The goal of server capability discovery >> is to specify what the server actually implements. I think the WG is >> confused (or ignoring) the difference. >> > > Sure, I may be confused. But let me try to explain again how I look at > this: > > a) With Y45-04, we are fixing the typedef drift and grouping drift > problem. This is an important module compile time issue. Fixing > this makes it unambiguous at module compile time what the > definitions resolve to. > > b) A server announces the modules and the revisions it implements via > the yang library data model. This covers the 'server capability > discovery' you mention above. (Note: Once I have the modules at > their specific revisions, I can can compile them without any > typedef drift and grouping drift issues.) > > c) The part that we do not cover is the 'specification of conformance > that a server has to implement' (to support certain use cases). > This is what we assume to be able to cover in the future using > language extensions (and you wrote a pretty decent proposal for > this a while ago). > > I think I learned during the many discussions that the idea to derive > c) out of the imports is not workable. > But the current solution is even worse than no solution. The client developer needs to be able to code to the model and have that code with servers that conform to the model. The problem is that for conformance purposes, the contents of the model cannot be determined at run-time. A client will need to code to specific server implementations or code to work with every possible combination of module revisions the server vendor may choose. > /js Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Fri Apr 24 10:12:21 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244051B37D1 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 10:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PBuCIKENX5Y for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 10:12:17 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id B865B1B37CE for <netmod@ietf.org>; Fri, 24 Apr 2015 10:12:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cIxTKnp7IRQT81D4ipcZ8jBvpNHF2m0/ejiBLMHcmEOJadDpqK4lDlcA4cCGSwkZ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Ylh9E-0001OF-7c for netmod@ietf.org; Fri, 24 Apr 2015 13:12:16 -0400 Received: from 76.254.54.242 by webmail.earthlink.net with HTTP; Fri, 24 Apr 2015 13:12:15 -0400 Message-ID: <12027168.1429895536241.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Fri, 24 Apr 2015 10:12:15 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537fb558b05b5ceaf49074f6e6161b07ca2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.27 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/CfHoxkNLoTFALS4-timw5GFKYQ8> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 17:12:19 -0000 Hi - >From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> >Sent: Apr 24, 2015 12:37 AM >To: Andy Bierman <andy@yumaworks.com> >Cc: "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] Y45 wrap up ... >The assumption that the set of imports used by all modules determines >the version of modules a server implements does not work with the goal >that a server implements exactly one version of every module. This ... The goal that "a server implements exactly one version" strikes me as unrealistic for multi-vendor / "open" systems and systems with hot swappable (redundant) component subsystems. Randy From nobody Fri Apr 24 10:23:58 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D4C1B37FC for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 10:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHOx2XVNqgkO for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 10:23:56 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205161B37F9 for <netmod@ietf.org>; Fri, 24 Apr 2015 10:23:56 -0700 (PDT) Received: by labbd9 with SMTP id bd9so40194707lab.2 for <netmod@ietf.org>; Fri, 24 Apr 2015 10:23:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6wXb27DGr5EZfTrDQkiG31pArkt3dvKHBmKONvxTh3U=; b=H+uZ/WALpIEgr2roYgKuXKLekbHkxYa0tlvaXtN0BZFd7LnRxUzSKlpDB5QhBj9N6H xl0IirnnpJ59e8H53YLdaJ9imu89q5OSCSrM4wTwSIZozBTaPryXx+OjlEWJa9/FE5fA hh8+nGBG6h4fD3VIWxY5LLCE8LFa2N/P7wBO2HD+2bJTMr64s79OXhU7A3A87I4jlpyp xZalY6dmzP/mePsm09U/bwc41t4XsP5Uuju0KeKMMVpcH2rUCAid5O1wuJzhWeSlvtI/ acyAdxjsctZDJLG3QS1xw4DB99OEQqjVudV1sJlXGxDQyxcMsQ4RIPIaQFSsGxm3XXqp l7bw== X-Gm-Message-State: ALoCoQkTtztEXv2xrVJPx8uW+ErEcxTT3JMA4ZpHEfWkcLGVewBRyJxD+JUTpv3na8yjM8b+KkeA MIME-Version: 1.0 X-Received: by 10.112.204.72 with SMTP id kw8mr7805166lbc.88.1429896234583; Fri, 24 Apr 2015 10:23:54 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 24 Apr 2015 10:23:54 -0700 (PDT) In-Reply-To: <12027168.1429895536241.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> References: <12027168.1429895536241.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Fri, 24 Apr 2015 10:23:54 -0700 Message-ID: <CABCOCHRuv75u+j_+q=_ROgCtE=x9Obwf--Gg4Wq7+K=nSnbMbQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/eMl8MH7qas_G0wK_kgUl9PvAslU> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 17:23:58 -0000 On Fri, Apr 24, 2015 at 10:12 AM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > >>From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> >>Sent: Apr 24, 2015 12:37 AM >>To: Andy Bierman <andy@yumaworks.com> >>Cc: "netmod@ietf.org" <netmod@ietf.org> >>Subject: Re: [netmod] Y45 wrap up > ... >>The assumption that the set of imports used by all modules determines >>the version of modules a server implements does not work with the goal >>that a server implements exactly one version of every module. This > ... > > The goal that "a server implements exactly one version" strikes > me as unrealistic for multi-vendor / "open" systems and systems > with hot swappable (redundant) component subsystems. > But this is fairly unmanageable. You are suggesting (for example) that the interface instances on line card 1 are from rev 1, and the interface instances from line card 2 are from rev 5, etc. At this point, static conformance is worthless. You need run-time operations to ask the server implementation what it will accept. Or you use trial-and-error and do not have the luxury of coding to the data model. You build data silos so you can try obscere undocumented tricks to know what is really supported. Oh wait, that's how SNMP and CLI work today. Hopefully we will do better with YANG. Maybe some future version. > Randy Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 24 10:36:29 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE991B3822 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 10:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9N9nMXLSXDi for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 10:36:26 -0700 (PDT) Received: from p3plsmtpa09-03.prod.phx3.secureserver.net (p3plsmtpa09-03.prod.phx3.secureserver.net [173.201.193.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5339B1B3755 for <netmod@ietf.org>; Fri, 24 Apr 2015 10:36:26 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa09-03.prod.phx3.secureserver.net with id KtcQ1q00N4vySjM01tcRfR; Fri, 24 Apr 2015 10:36:25 -0700 Message-ID: <553A7F18.3040409@seguesoft.com> Date: Fri, 24 Apr 2015 12:36:25 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: netmod@ietf.org References: <CABCOCHRiBdYNeqFmGr79Y3H6KvbpEucqhSo+OBQFbLQN3kx5Rw@mail.gmail.com> <20150422.205208.1181266232792526869.mbj@tail-f.com> <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> <20150424124251.GA6132@elstar.local> In-Reply-To: <20150424124251.GA6132@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/y0W7VODoZBdz7R-TYACRyWs3WXc> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 17:36:28 -0000 Hi Juergen, On 4/24/2015 7:42 AM, Juergen Schoenwaelder wrote: > On Fri, Apr 24, 2015 at 11:02:46AM +0200, Ladislav Lhotka wrote: >> Andy Bierman <andy@yumaworks.com> writes: >> >>> On Thu, Apr 23, 2015 at 12:34 AM, Juergen Schoenwaelder >>> <j.schoenwaelder@jacobs-university.de> wrote: >>>> On Wed, Apr 22, 2015 at 04:06:12PM -0700, Andy Bierman wrote: >>>>> .... >>>>>>> Where does it say this is not allowed? >>>>>> If a server implements a module A that imports B, and A augments B >>>>>> or has a leafref to a node in B, the server MUST implement *some >>>>>> version* of module B that has the nodes A references. This is >>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> regardless of A imports B by revision or not. >>>>>> >>>>>> >>>>>> The whole idea is to decouple the revision-date used in the import in >>>>>> order to fix the typedef from the version needed for augment. >>>>>> >>>>> This is the part that will really confuse users. >>>>> For augment-stmts, the revision-date is ignored >>>>> in import-by-revision. >>>> Not sure what 'ignored' means here. At module compile time, if a >>>> module refers to /b:bar than this /b:bar must resolve to something >>>> defined in the revision that is used by the compiler (and import by >>>> revision nails this down to an exact version). >>>> >>>>> IMO this will not work well because the designer will write >>>>> a module expecting the augmented module to be the >>>>> one specified by import-by-revision. >>>> Likely, but it can also be a newer revision of the module that you >>>> implement, no? >>>> >>>>> If 2 or more modules augment different versions of >>>>> the /bar container over time at least 1 of them will >>>>> be applied to the wrong version of the augmented module. >>>>> This will cause unpredictable results because YANG >>>>> statements can interact in complex ways (e.g., must/when). >>>> Sure, you can create something not implementable with must/when >>>> statements - you do not even need imports for that and this is >>>> part of YANG 1.0 as well. >>>> >>>>>>> So the server cannot just pick a revision of "base". >>>>>>> It must be aware of all the other modules that use "base" >>>>>>> and make sure all modules work together? >>>>>> Right. This is not different from how it works in YANG 1.0. >>>> I assume that modules that are not implementable (e.g., due to must >>>> constraints that can never be true) will not be implemented. I also >>>> assume that a server announcing a set of modules that can't be >>>> compiled together will receive appropriate customer feedback. >>>> >>>> What Y45-04 primarily fixes is any ambiguity at module compile time >>>> concerning the typedefs and groupings being used. The other problem >>>> space, namely what are meaningful combinations of modules, is not >>>> addressed by Y45-04 and left for further study. (I personally believe >>>> we need at some point in time something like packages but this >>>> hopefully can be done as a language extension; fixing the typedef and >>>> grouping drift is something we have to resolve in YANG 1.1 since it >>>> impacts the semantics of imports.) >>>> >>> You missed my point. >>> >>> The authors of a module that imports a specific revision of >>> another module expect that the import-by-revision will >>> be honored. It should not be up to the vendor to pick a >>> down-rev version. The vendor MUST implement the version specified >>> in the import-stmt or the API will not be exactly as specified in the >>> combined YANG modules, and will not be interoperable. >> If import-by-revision already implies the server must implement that >> revision of the imported module, one can then ask why the server needs >> to advertise this module again. >> >> In fact, the semantics of import is often confusing for new users, see >> e.g. a recent pyang issue: >> >> https://github.com/mbj4668/pyang/issues/131 >> >> And for augments it's even weirder because an augment in fact *exports* >> stuff into the imported module. > Whether this is a bug or feature of pyang can be debated but at the > end it not so relevant. > > The key here is to recognize that resolution of references at module > compile time is one thing and module versions implemented on a server > is another thing. This is almost like in C: the compiler (or > pre-processor) cares about the definitions (or headers) you import, > the linker cares of resolving symbol dependencies. The libraries that > make up your program are not determined by the #include, they are at > best implied by the #includes but even then ultimately it is the > symbol references in your object files that matter. True. But because we have "augment", the meaning of "import-by-revision" is now overloaded. When augmenting, the seemly logic behind "augmenting the imported module with the specific revision" does imply the server is required to support the revision that is being imported. The "min-revision-rule" helps guarantee this. The question to me now is this: is a module designer allowed to call out the minimum revision for the augmented module that a server must support? To me it appears allowing that is reasonable, probably because the module designer may expect some capabilities must be available first before starting to design the augmenting module. However I don't have a concrete use-case example so I am not entirely sure about this feature. If the answer to this question is "Yes" then I think it may not be entirely possible to restrain "importing-by-revision" to only mean to incorporate typdef and other declarations, and we need this "min-revision-rule". Otherwise I agree this "min-revision-rule" is not needed and "revision-date" must be completely ignored for augmenting purpose. --Xiang From nobody Fri Apr 24 12:13:05 2015 Return-Path: <jason.sterne@alcatel-lucent.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3D1B319C for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 12:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlqvI_NcoQ6j for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 12:13:03 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 0537E1B315F for <netmod@ietf.org>; Fri, 24 Apr 2015 12:13:02 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 2D418143C5C06 for <netmod@ietf.org>; Fri, 24 Apr 2015 19:12:57 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t3OJCweS032482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netmod@ietf.org>; Fri, 24 Apr 2015 15:12:58 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.179]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 24 Apr 2015 15:12:59 -0400 From: "Sterne, Jason (Jason)" <jason.sterne@alcatel-lucent.com> To: "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: mandatory ACL type (was "comments on acl-model-02") Thread-Index: AQHQdfO9+1SL04157USyMOLNDBGWIZ1cUJ/w Date: Fri, 24 Apr 2015 19:12:59 +0000 Message-ID: <A125E53CE190A749957C19483DC79F9F5C9F6BEE@US70TWXCHMBA11.zam.alcatel-lucent.com> References: <A125E53CE190A749957C19483DC79F9F5C9DFFD4@US70TWXCHMBA11.zam.alcatel-lucent.com> <A125E53CE190A749957C19483DC79F9F5C9EBDB7@US70TWXCHMBA11.zam.alcatel-lucent.com> In-Reply-To: <A125E53CE190A749957C19483DC79F9F5C9EBDB7@US70TWXCHMBA11.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/BRROCwTdLmPGC1iRXBI1flyxgG8> Subject: Re: [netmod] mandatory ACL type (was "comments on acl-model-02") X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 19:13:04 -0000 Hi all, To add some more info for my suggestions below: Cisco IOS-XR has separate lists for ipv4 and ipv6 (probably IOS as well - d= idn't check): ipv4 access-list <name> ipv6 access-list <name> Junos has separate lists for v4 and v6: access-list <xyz> ... ipv6 access-list <abc> ... ALU SR OS has separate lists for v4 and v6 (and mac): filter ip-filter <id|name> ... filter ipv6-filter <id|name> ... filter mac-filter <id|name> ... Huawei uses separate lists for v4 and v6: acl number 3000 acl ipv6 number 3000 Having a mandatory type fits in better with all those models and is fine fo= r implementations that don't need the type. Regards, Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Jason (J= ason) Sent: Monday, April 13, 2015 10:12 AM To: netmod@ietf.org Subject: [netmod] mandatory ACL type (was "comments on acl-model-02") Hi guys, Extracting my comments about ACL type into its own thread. I saw Martin al= so had some comments on this topic. The ACL type was mandatory in an older version of the draft and I think we = should put it back as mandatory. Implementations that don't *need* that le= af value can work fine whether they get it during ACL creation or not but s= ome implementations need to know the type. It would also be good to create separate identities for IPv4-access-control= -list and IPv6-access-control-list instead of bundling them into IP-access-= control-list. If we're separating into types in the model it should be the = 3 basic types in the base model: v4, v6 and enet. That would also help if we decide to put some constraints that allow/disall= ow certain matching criteria when the type is a specific value (e.g. don't = allow a v6 address match in a v4 list). We'd have to be careful about how = those constraints are formulated though - especially if we want to allow au= gmentations of the list-type for "mixed" ACLs. A new "mixed-v4-enet" type (= identity) would also need to use the destination-ipv4-network matching crit= eria (can "when" or "must" logic be changed by an augmentation ? I'm not s= ure that works). Regards, Jason _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 24 12:21:17 2015 Return-Path: <randy_presuhn@mindspring.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5941A1A70 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 12:21:13 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG4vvh-tuG37 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 12:21:11 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id A0CAC1A7D80 for <netmod@ietf.org>; Fri, 24 Apr 2015 12:21:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bmh//pOsFcCqHANOpk3z2SK4za3fW7plDeoHzvUebtLKLRmpziPmrHpZWkCQRGyG; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Ylj9y-0004iu-So for netmod@ietf.org; Fri, 24 Apr 2015 15:21:10 -0400 Received: from 76.254.54.242 by webmail.earthlink.net with HTTP; Fri, 24 Apr 2015 15:21:10 -0400 Message-ID: <4980979.1429903270867.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Fri, 24 Apr 2015 12:21:10 -0700 (GMT-07:00) From: Randy Presuhn <randy_presuhn@mindspring.com> To: "netmod@ietf.org" <netmod@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537aa64f22a40f952af2c8d31b653dc8bbc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/sxzBWOrBSdPS_25exg1V-YnPXFU> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn <randy_presuhn@mindspring.com> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 19:21:13 -0000 Hi - >From: Andy Bierman <andy@yumaworks.com> >Sent: Apr 24, 2015 10:23 AM >To: Randy Presuhn <randy_presuhn@mindspring.com> >Cc: "netmod@ietf.org" <netmod@ietf.org> >Subject: Re: [netmod] Y45 wrap up > >On Fri, Apr 24, 2015 at 10:12 AM, Randy Presuhn ><randy_presuhn@mindspring.com> wrote: >> Hi - >> >>>From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> >>>Sent: Apr 24, 2015 12:37 AM >>>To: Andy Bierman <andy@yumaworks.com> >>>Cc: "netmod@ietf.org" <netmod@ietf.org> >>>Subject: Re: [netmod] Y45 wrap up >> ... >>>The assumption that the set of imports used by all modules determines >>>the version of modules a server implements does not work with the goal >>>that a server implements exactly one version of every module. This >> ... >> >> The goal that "a server implements exactly one version" strikes >> me as unrealistic for multi-vendor / "open" systems and systems >> with hot swappable (redundant) component subsystems. >> > >But this is fairly unmanageable. >You are suggesting (for example) that the interface instances >on line card 1 are from rev 1, and the interface instances from >line card 2 are from rev 5, etc. I know products like this have existed. Perhaps the answer is simply that netconf is the not right tool for that job. >At this point, static conformance is worthless. You need run-time >operations to ask the server implementation what it will accept. "Worthless" is perhaps a little strong, but yes. >Or you use trial-and-error and do not have the luxury of coding >to the data model. I think "coding to the data model" (at least as I understand the phrase) is a poor strategy for complex or long-lived product lines. The design has to be at a higher level, or every minor rev will create major churn in the management infrastructure. >You build data silos so you can try obscere >undocumented tricks to know what is really supported. >Oh wait, that's how SNMP and CLI work today. My experience in SNMP was that the "undocumented tricks" were to cope with (1) errors in the implementation of the protocol (2) errors in the implementation of the data models *This* discussion has thus far limited itself to assuming that the protocol and data model implementations are correct. It's only been about accurately representing model or the configuration (in the classic sense of configuration management) of an implementation. >Hopefully we >will do better with YANG. Maybe some future version. Hope springs eternal. It seems like things work fine until the problem is actually one of configuration management. Randy From nobody Fri Apr 24 12:50:29 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644D41A037D for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 12:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYndVfwmxWun for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 12:50:25 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C801A0372 for <netmod@ietf.org>; Fri, 24 Apr 2015 12:50:25 -0700 (PDT) Received: by laat2 with SMTP id t2so42728561laa.1 for <netmod@ietf.org>; Fri, 24 Apr 2015 12:50:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=etsNkyMM3m/Rm/RV1LlrkvsVbsr1sXv+v/ok7NlWxII=; b=R5qmo/Kvdzo2Tj6zfO0xrrBDM0KhfvnAqGISTwBM+5W9DHi9ZN/UdOOrrslF7wZs75 d4EZUMUdnH1BNpmMD4JtKynCm8BfKhGOA7z6ZwnxbQVjwYbmyMMuOWANsOxiiB8zRl6J p1tzEUhriI/KArUo8nU7UXnZ0O1ZWuD1wSFluXrJpv6H7rYe7Gw9PFGn06MT+ZCth+Rz 0Ae/DrvEXiI7ypchlwCdJxl9cLINu371x7za+UgHWd0lcpUZasogG6z+0FcKTqAP5DQ4 JIZRPjO595Fo4iRq7Xm61KWW0lHlnmcQ7lAkXoos7xHOvGWy0bWegmAOBGf1iHRwEIqF oicg== X-Gm-Message-State: ALoCoQkOqHa7vXBtjg6IvhUE+PeT80kIDBN0KlwCTbczIF2anT2HErJID4jig+Ns6me5BkjGhSRC MIME-Version: 1.0 X-Received: by 10.152.87.233 with SMTP id bb9mr65155lab.38.1429905023452; Fri, 24 Apr 2015 12:50:23 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 24 Apr 2015 12:50:23 -0700 (PDT) In-Reply-To: <4980979.1429903270867.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> References: <4980979.1429903270867.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Fri, 24 Apr 2015 12:50:23 -0700 Message-ID: <CABCOCHR5zGQExkHKPnkHgOveOY6tNBdekuD3gR25Vj2ha5Cpyg@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Randy Presuhn <randy_presuhn@mindspring.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/kTvaEvItN7ju4VS5yJmIJ7sA8lI> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 19:50:27 -0000 On Fri, Apr 24, 2015 at 12:21 PM, Randy Presuhn <randy_presuhn@mindspring.com> wrote: > Hi - > >>From: Andy Bierman <andy@yumaworks.com> >>Sent: Apr 24, 2015 10:23 AM >>To: Randy Presuhn <randy_presuhn@mindspring.com> >>Cc: "netmod@ietf.org" <netmod@ietf.org> >>Subject: Re: [netmod] Y45 wrap up >> >>On Fri, Apr 24, 2015 at 10:12 AM, Randy Presuhn >><randy_presuhn@mindspring.com> wrote: >>> Hi - >>> >>>>From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> >>>>Sent: Apr 24, 2015 12:37 AM >>>>To: Andy Bierman <andy@yumaworks.com> >>>>Cc: "netmod@ietf.org" <netmod@ietf.org> >>>>Subject: Re: [netmod] Y45 wrap up >>> ... >>>>The assumption that the set of imports used by all modules determines >>>>the version of modules a server implements does not work with the goal >>>>that a server implements exactly one version of every module. This >>> ... >>> >>> The goal that "a server implements exactly one version" strikes >>> me as unrealistic for multi-vendor / "open" systems and systems >>> with hot swappable (redundant) component subsystems. >>> >> >>But this is fairly unmanageable. >>You are suggesting (for example) that the interface instances >>on line card 1 are from rev 1, and the interface instances from >>line card 2 are from rev 5, etc. > > I know products like this have existed. > Perhaps the answer is simply that netconf > is the not right tool for that job. > I doubt these products use standard mechanisms to know which instances are rev. 1 and which are rev. 5. That's what I mean by data silos. This may be too difficult to standardize in the data modeling language. It would be scary if we need an RPC operation so the client can ask for every instance of every data node "what revision of the module are you from?" >>At this point, static conformance is worthless. You need run-time >>operations to ask the server implementation what it will accept. > > "Worthless" is perhaps a little strong, but yes. > >>Or you use trial-and-error and do not have the luxury of coding >>to the data model. > > I think "coding to the data model" (at least as I understand > the phrase) is a poor strategy for complex or long-lived > product lines. The design has to be at a higher level, or > every minor rev will create major churn in the management > infrastructure. Not if the YANG update rules are followed carefully. We expect old clients to keep working with new servers, or at least that is the goal. > >>You build data silos so you can try obscere >>undocumented tricks to know what is really supported. >>Oh wait, that's how SNMP and CLI work today. > > My experience in SNMP was that the "undocumented tricks" > were to cope with > (1) errors in the implementation of the protocol > (2) errors in the implementation of the data models > > *This* discussion has thus far limited itself to assuming > that the protocol and data model implementations are correct. > It's only been about accurately representing model or the > configuration (in the classic sense of configuration management) > of an implementation. > IMO, one could interpret the rev1/rev5 interface instances example as a broken implementation. The server advertises just 1 revision of the ietf-interfaces module, and if it doesn't honor that, then in (the simplistic) terms of YANG conformance, is not implemented correctly. >>Hopefully we >>will do better with YANG. Maybe some future version. > > Hope springs eternal. It seems like things work fine until > the problem is actually one of configuration management. > We want automated tools to do the right thing without intervention. This is a hard problem that NETCONF and YANG are in the early stages of solving. > Randy > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 24 15:02:35 2015 Return-Path: <internet-drafts@ietf.org> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F7C1ACED7; Fri, 24 Apr 2015 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdCIkiHkqldY; Fri, 24 Apr 2015 15:02:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 639E51ACE95; Fri, 24 Apr 2015 15:02:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: <i-d-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150424220232.15780.49425.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 15:02:32 -0700 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/UhlFH0RrgukxWV4nEaOvqQscTzQ> Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 24 Apr 2015 22:02:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author : Andy Bierman Filename : draft-ietf-netmod-rfc6087bis-02.txt Pages : 38 Date : 2015-04-24 Abstract: This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-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 Fri Apr 24 21:24:48 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF6E1ACE47 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 21:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: 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-EkhskbbtD1 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2015 21:24:46 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (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 8C97B1ACE3A for <netmod@ietf.org>; Fri, 24 Apr 2015 21:24:45 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so49573339lbc.1 for <netmod@ietf.org>; Fri, 24 Apr 2015 21:24:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0GpcHKGk54I7mX/nXAdNM43/p/8jQ+jied9BTwlt4uQ=; b=VQLWch0jMQZYoKhyCDvlqccTJRWxhusooXbmtQVz5jbBfZmx5Gwbis7ibRVItqo9qz 0vjSEg8Nhyt5Dgl8//aHnHiKP/43O3a9EWWhqxIk2JkWTNw+hT+8suEjUIvCKQXBzFL0 3ExvfMHZXdLqaP1kBKJDHWt8GNLIYdqNMCQc7QgOM7xYOtWNCsOWiSyLCQXdvi2HQsHJ OnwSs5DMLlMnUw8UpItGYWOnTBjannPN7dYPtqMMFwfZBOL+9qmK26GKOv6mBuylZdO+ MUWWirot6XXayMDSzt8AAyfjs57mwo4avU/dZbGJYfvSnrgLXC+/FAEF8UHo7rBGprDq BvqQ== X-Gm-Message-State: ALoCoQk6C1SCiNNvc3hSSlmN+jAqA73pBF/RvNe+/1eAGZK4DGJfRLG1Bz/v9fKPV/OOVWEgmT8A MIME-Version: 1.0 X-Received: by 10.112.130.129 with SMTP id oe1mr1312787lbb.37.1429935884072; Fri, 24 Apr 2015 21:24:44 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 24 Apr 2015 21:24:43 -0700 (PDT) In-Reply-To: <20150424.100644.959374717987870887.mbj@tail-f.com> References: <20150423190350.GB4421@elstar.local> <CABCOCHQcPiSHYr0hOg2YVFO2yue3JqMr28kojC55JjHk1p95nw@mail.gmail.com> <20150424073738.GC5506@elstar.local> <20150424.100644.959374717987870887.mbj@tail-f.com> Date: Fri, 24 Apr 2015 21:24:43 -0700 Message-ID: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/mQQQidEztcDLWIWQE6UUor1xcjw> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 25 Apr 2015 04:24:47 -0000 On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >> > >> > Let me try to explain my concern again... >> > >> > The authors of "bar" expect that module X rev 2 will be supported. >> > That is why they used import-by-revision. Mixing typedefs and >> > groupings from R2 and protocol accessible objects from R1 is not what >> > they expect. They cannot possibly write their module "bar" >> > for every possible combination of down-rev X modules the vendor may choose. >> > >> > It is not the fault of the designers if bar does not work with X@R1. >> > They expect X@R2 to be used. >> > >> >> I can easily construct cases where this may not be true nor >> problematic. If we make the interpretation min-revision, I am sure we >> will regret it at some point in time > > I agree. The min-revision rule would be an unnecessary CLR. > > I asked before for an example of where the proposed solution is > problematic, and where the min-revision would solve that. Here is a simple example that I find problematic. This is what I mean by coding to the model. The client developer adds code to augment a base node if the port-knob-type is 'fastest' module base { ... revision 2014-01-01; typedef port-knob-type { type enumeration { enum fast; enum faster; } } list port-knob { key name; leaf name { type string; } leaf knob-type { type port-knob-type; } } } module base { ... revision 2015-01-01; typedef port-knob-type { type enumeration { enum fast; enum faster; enum fastest' // added new enum } } list port-knob { key name; leaf name { type string; } leaf knob-type { type port-knob-type; default fast; } } module aug1 { ... import base { prefix b; revision-date "2015-01-01"; } augment b:/port-knob { when "b:knob-type = 'faster'"; leaf alt-knob-type { type b:port-knob-type; } } augment b:/port-knob { when "b:knob-type = 'fastest'"; leaf boost-factor { type uint32; } } } The 'aug1' developer clearly intends for the server to support base@2015-01-01. But the vendor decides to advertise base@2014-01-01. The 'port-knob' list is augmented with the new version of the port-knob-type (if 'faster') even though the server implements the old version. The ''boost-factor'' leaf will never augment the port-knob list because server does not support the 'fastest' enum. This is more than just confusing, especially if the server advertises that it conforms to the "aug1" module. Andy > >> since we will have a hard time to >> ever retire an RFC because there is an incentive to always refer to >> the initial definition for the /interfaces container defined in >> ietf-interfaces.yang unless there is a specific need to require a >> newer revision. This is in particular a concern if >> ietf-interfaces.yang is updated with additions that do not at all >> affect the /interfaces container. >> >> The assumption that the set of imports used by all modules determines >> the version of modules a server implements does not work with the goal >> that a server implements exactly one version of every module. This >> only works if you have full control over the module revision process. >> >> Anyway, if the consensus is to make the semantics min-revision, I will >> go along with it. But I am convinced we will regret it at some point >> in time or we declare that we all moved to a newer version of a module >> but implementations will cheat. > > I have updated the issues list with this solution, Y45-05. > > Maybe the chairs can do another poll for consensus on this issue? > > > /martin From nobody Sun Apr 26 05:57:36 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35B61AD0C9 for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 05:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3Z-eWjlFzsF for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 05:57:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE0C1AD0B7 for <netmod@ietf.org>; Sun, 26 Apr 2015 05:57:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 22A5A946; Sun, 26 Apr 2015 14:57:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FXCkAET0zLmf; Sun, 26 Apr 2015 14:57:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 26 Apr 2015 14:57:31 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24ED920031; Sun, 26 Apr 2015 14:57:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g8hP36JOuy8Q; Sun, 26 Apr 2015 14:57:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 033BF2002B; Sun, 26 Apr 2015 14:57:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 267CE32F0589; Sun, 26 Apr 2015 14:57:27 +0200 (CEST) Date: Sun, 26 Apr 2015 14:57:27 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150426125727.GA16630@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> <20150424124251.GA6132@elstar.local> <CABCOCHQjwkF4QCo5d37YuQfzk2bR5KwzycwK3QB9wJW1dAsLpA@mail.gmail.com> <20150424151338.GA6855@elstar.local> <CABCOCHQXZks8xjkbwcdSuM5T08gB=E9Yx-jZGCiy0T22xVW0SA@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHQXZks8xjkbwcdSuM5T08gB=E9Yx-jZGCiy0T22xVW0SA@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/uDkiadVMcPxK10BFAM0yB6LFebQ> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Apr 2015 12:57:36 -0000 On Fri, Apr 24, 2015 at 08:54:08AM -0700, Andy Bierman wrote: > On Fri, Apr 24, 2015 at 8:13 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: > > On Fri, Apr 24, 2015 at 08:00:05AM -0700, Andy Bierman wrote: > >> Hi, > >> > >> From a conformance POV, letting the vendor choose among > >> many obsolete revisions and still claim conformance > >> it totally broken. The data model writers are supposed > >> to specify conformance at module-write-time, > >> The vendor should not be specifying conformance at > >> module-load-time. > >> > >> The goal of conformance is to specify what the client and server > >> are supposed to implement. The goal of server capability discovery > >> is to specify what the server actually implements. I think the WG is > >> confused (or ignoring) the difference. > >> > > > > Sure, I may be confused. But let me try to explain again how I look at > > this: > > > > a) With Y45-04, we are fixing the typedef drift and grouping drift > > problem. This is an important module compile time issue. Fixing > > this makes it unambiguous at module compile time what the > > definitions resolve to. > > > > b) A server announces the modules and the revisions it implements via > > the yang library data model. This covers the 'server capability > > discovery' you mention above. (Note: Once I have the modules at > > their specific revisions, I can can compile them without any > > typedef drift and grouping drift issues.) > > > > c) The part that we do not cover is the 'specification of conformance > > that a server has to implement' (to support certain use cases). > > This is what we assume to be able to cover in the future using > > language extensions (and you wrote a pretty decent proposal for > > this a while ago). > > > > I think I learned during the many discussions that the idea to derive > > c) out of the imports is not workable. > > > > But the current solution is even worse than no solution. > The client developer needs to be able to code to the model > and have that code with servers that conform to the model. > I believe Y45-04 allows that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Sun Apr 26 09:08:16 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4CB1A1AB3 for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 09:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.721 X-Spam-Level: X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTqRJR0hBqUS for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 09:08:13 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 55E211A1A27 for <netmod@ietf.org>; Sun, 26 Apr 2015 09:08:13 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so66485056lbb.2 for <netmod@ietf.org>; Sun, 26 Apr 2015 09:08:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=t6saw2OTGnwjL7Jd9jDPxrjN22KzdryuZeO2jqe4rVM=; b=iR8R72fgo41Ck9KQIDdEnpgce+8o2wh+6yf7T0xo//AnuQ/zyeAIP/dbq4nTfDmElu 2m6HsXxkAFCggQ+Q5qAYr+AAlpD7CgfhztQwu/fZiSknV1eww0LIZ8IduvMY9n/X5kpz 03UYoYB7ganU5VMfd+7XwkgwTDpoSgusJFXJNwLkSOh5dyJXXsIgA/TaPqOc02GkYqLr m33v38pUiYqX7gL+24/oJL8q3D/nktCnAr3QCigxqKj6J+YTaQgI9Wu3A+/G5rgNAGSg RnorpzB8Nk1X59AvjjGI/1Vcz+3i80f6jzIvLKzEYj5NDFWP8OuPJ2zmC80kbhc1Psrs zgEg== X-Gm-Message-State: ALoCoQksDR9cASglxfqy0jB5t9wkia1+m4ZYk0O1x7pGUOhxwFmDSRVkqiTo8B5Y44ScGAPC9eii MIME-Version: 1.0 X-Received: by 10.152.87.164 with SMTP id az4mr6711868lab.123.1430064491761; Sun, 26 Apr 2015 09:08:11 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Apr 2015 09:08:11 -0700 (PDT) In-Reply-To: <20150426125727.GA16630@elstar.local> References: <CABCOCHQfXYUhB_gYDbDzJRQwr7=yhxnshagEAH+Jor1e7D=XZA@mail.gmail.com> <20150422.210504.631639827959853956.mbj@tail-f.com> <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> <20150424124251.GA6132@elstar.local> <CABCOCHQjwkF4QCo5d37YuQfzk2bR5KwzycwK3QB9wJW1dAsLpA@mail.gmail.com> <20150424151338.GA6855@elstar.local> <CABCOCHQXZks8xjkbwcdSuM5T08gB=E9Yx-jZGCiy0T22xVW0SA@mail.gmail.com> <20150426125727.GA16630@elstar.local> Date: Sun, 26 Apr 2015 09:08:11 -0700 Message-ID: <CABCOCHQdeyw-3RvDmJBxbXqoGCJ4gF=ym-cD-kWs793K=TGmhQ@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/yfVroRADOpV5_ZlkIY9gkn5dRLE> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Apr 2015 16:08:15 -0000 On Sun, Apr 26, 2015 at 5:57 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Apr 24, 2015 at 08:54:08AM -0700, Andy Bierman wrote: >> On Fri, Apr 24, 2015 at 8:13 AM, Juergen Schoenwaelder >> <j.schoenwaelder@jacobs-university.de> wrote: >> > On Fri, Apr 24, 2015 at 08:00:05AM -0700, Andy Bierman wrote: >> >> Hi, >> >> >> >> From a conformance POV, letting the vendor choose among >> >> many obsolete revisions and still claim conformance >> >> it totally broken. The data model writers are supposed >> >> to specify conformance at module-write-time, >> >> The vendor should not be specifying conformance at >> >> module-load-time. >> >> >> >> The goal of conformance is to specify what the client and server >> >> are supposed to implement. The goal of server capability discovery >> >> is to specify what the server actually implements. I think the WG is >> >> confused (or ignoring) the difference. >> >> >> > >> > Sure, I may be confused. But let me try to explain again how I look at >> > this: >> > >> > a) With Y45-04, we are fixing the typedef drift and grouping drift >> > problem. This is an important module compile time issue. Fixing >> > this makes it unambiguous at module compile time what the >> > definitions resolve to. >> > >> > b) A server announces the modules and the revisions it implements via >> > the yang library data model. This covers the 'server capability >> > discovery' you mention above. (Note: Once I have the modules at >> > their specific revisions, I can can compile them without any >> > typedef drift and grouping drift issues.) >> > >> > c) The part that we do not cover is the 'specification of conformance >> > that a server has to implement' (to support certain use cases). >> > This is what we assume to be able to cover in the future using >> > language extensions (and you wrote a pretty decent proposal for >> > this a while ago). >> > >> > I think I learned during the many discussions that the idea to derive >> > c) out of the imports is not workable. >> > >> >> But the current solution is even worse than no solution. >> The client developer needs to be able to code to the model >> and have that code with servers that conform to the model. >> > > I believe Y45-04 allows that. > I don't think more than 1 revision of a module needs to be imported. Cherry-picking from all available revisions is a bad precedent. The 'port-knob-type' example is the most common use-case -- adding a new enum to a typedef. The WG already agreed (I think) that the server MUST support the base module augmented from another module. The example shows the server MUST implement the same (or more recent) version that is used by any module that augments the module, in order to claim conformance for both the augmented and augmenting modules. > /js Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Sun Apr 26 10:18:15 2015 Return-Path: <j.schoenwaelder@jacobs-university.de> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C1A1A9218 for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 10:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3SIHg_CiYIv for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 10:18:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605E21A9164 for <netmod@ietf.org>; Sun, 26 Apr 2015 10:18:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D87E9F9B; Sun, 26 Apr 2015 19:18:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jQky3e9skC2f; Sun, 26 Apr 2015 19:18:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 26 Apr 2015 19:18:09 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9C322002B; Sun, 26 Apr 2015 19:18:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zX59QqM4cNRX; Sun, 26 Apr 2015 19:18:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 274E620013; Sun, 26 Apr 2015 19:18:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 74D6232F06AC; Sun, 26 Apr 2015 19:18:06 +0200 (CEST) Date: Sun, 26 Apr 2015 19:18:05 +0200 From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> To: Andy Bierman <andy@yumaworks.com> Message-ID: <20150426171805.GA16991@elstar.local> Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> References: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> <20150424124251.GA6132@elstar.local> <CABCOCHQjwkF4QCo5d37YuQfzk2bR5KwzycwK3QB9wJW1dAsLpA@mail.gmail.com> <20150424151338.GA6855@elstar.local> <CABCOCHQXZks8xjkbwcdSuM5T08gB=E9Yx-jZGCiy0T22xVW0SA@mail.gmail.com> <20150426125727.GA16630@elstar.local> <CABCOCHQdeyw-3RvDmJBxbXqoGCJ4gF=ym-cD-kWs793K=TGmhQ@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CABCOCHQdeyw-3RvDmJBxbXqoGCJ4gF=ym-cD-kWs793K=TGmhQ@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/N3vjhx3T0WtkP0vQzueAvvyAafg> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Apr 2015 17:18:14 -0000 On Sun, Apr 26, 2015 at 09:08:11AM -0700, Andy Bierman wrote: > On Sun, Apr 26, 2015 at 5:57 AM, Juergen Schoenwaelder > <j.schoenwaelder@jacobs-university.de> wrote: > > On Fri, Apr 24, 2015 at 08:54:08AM -0700, Andy Bierman wrote: > >> On Fri, Apr 24, 2015 at 8:13 AM, Juergen Schoenwaelder > >> <j.schoenwaelder@jacobs-university.de> wrote: > >> > On Fri, Apr 24, 2015 at 08:00:05AM -0700, Andy Bierman wrote: > >> >> Hi, > >> >> > >> >> From a conformance POV, letting the vendor choose among > >> >> many obsolete revisions and still claim conformance > >> >> it totally broken. The data model writers are supposed > >> >> to specify conformance at module-write-time, > >> >> The vendor should not be specifying conformance at > >> >> module-load-time. > >> >> > >> >> The goal of conformance is to specify what the client and server > >> >> are supposed to implement. The goal of server capability discovery > >> >> is to specify what the server actually implements. I think the WG is > >> >> confused (or ignoring) the difference. > >> >> > >> > > >> > Sure, I may be confused. But let me try to explain again how I look at > >> > this: > >> > > >> > a) With Y45-04, we are fixing the typedef drift and grouping drift > >> > problem. This is an important module compile time issue. Fixing > >> > this makes it unambiguous at module compile time what the > >> > definitions resolve to. > >> > > >> > b) A server announces the modules and the revisions it implements via > >> > the yang library data model. This covers the 'server capability > >> > discovery' you mention above. (Note: Once I have the modules at > >> > their specific revisions, I can can compile them without any > >> > typedef drift and grouping drift issues.) > >> > > >> > c) The part that we do not cover is the 'specification of conformance > >> > that a server has to implement' (to support certain use cases). > >> > This is what we assume to be able to cover in the future using > >> > language extensions (and you wrote a pretty decent proposal for > >> > this a while ago). > >> > > >> > I think I learned during the many discussions that the idea to derive > >> > c) out of the imports is not workable. > >> > > >> > >> But the current solution is even worse than no solution. > >> The client developer needs to be able to code to the model > >> and have that code with servers that conform to the model. > >> > > > > I believe Y45-04 allows that. > > > > I don't think more than 1 revision of a module needs to be imported. > Cherry-picking from all available revisions is a bad precedent. What are the alternatives? Move definitions into many very small modules so that all-or-nothing updates are workable? Require that all semantically changed definitions get a new name? The later is the at the end the same except that you maintain all revisions inside the module. In other words, cherry-picking by itself is not a bad precedent, we have been doing that before - the question is just how we maintain the different versions. > The 'port-knob-type' example is the most common use-case -- > adding a new enum to a typedef. The WG already agreed (I think) > that the server MUST support the base module augmented > from another module. The example shows the server MUST implement > the same (or more recent) version that is used by any module that > augments the module, in order to claim conformance for both the > augmented and augmenting modules. I do not think that the WG agreed on something yet. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Sun Apr 26 10:30:12 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9961AC3BC for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 10:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcCsYerdLeQt for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 10:30: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 A9E5A1AC3B9 for <netmod@ietf.org>; Sun, 26 Apr 2015 10:30:08 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 39F531AE0A6C; Sun, 26 Apr 2015 19:30:07 +0200 (CEST) Date: Sun, 26 Apr 2015 19:32:11 +0200 (CEST) Message-Id: <20150426.193211.1077355394949650317.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> References: <20150424073738.GC5506@elstar.local> <20150424.100644.959374717987870887.mbj@tail-f.com> <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/ROALV1UF7xtT6ZVXiFwBMyiGgpo> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Apr 2015 17:30:11 -0000 Andy Bierman <andy@yumaworks.com> wrote: > On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > >> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: > >> > > >> > Let me try to explain my concern again... > >> > > >> > The authors of "bar" expect that module X rev 2 will be supported. > >> > That is why they used import-by-revision. Mixing typedefs and > >> > groupings from R2 and protocol accessible objects from R1 is not what > >> > they expect. They cannot possibly write their module "bar" > >> > for every possible combination of down-rev X modules the vendor may choose. > >> > > >> > It is not the fault of the designers if bar does not work with X@R1. > >> > They expect X@R2 to be used. > >> > > >> > >> I can easily construct cases where this may not be true nor > >> problematic. If we make the interpretation min-revision, I am sure we > >> will regret it at some point in time > > > > I agree. The min-revision rule would be an unnecessary CLR. > > > > I asked before for an example of where the proposed solution is > > problematic, and where the min-revision would solve that. > > > Here is a simple example that I find problematic. > This is what I mean by coding to the model. > The client developer adds code to augment a base node > if the port-knob-type is 'fastest' > > > module base { > ... > revision 2014-01-01; > typedef port-knob-type { > type enumeration { > enum fast; > enum faster; > } > } > list port-knob { > key name; > leaf name { type string; } > leaf knob-type { type port-knob-type; } > } > } > > > module base { > ... > revision 2015-01-01; > typedef port-knob-type { > type enumeration { > enum fast; > enum faster; > enum fastest' // added new enum > } > } > list port-knob { > key name; > leaf name { type string; } > leaf knob-type { > type port-knob-type; > default fast; > > } > } > > module aug1 { > ... > import base { > prefix b; > revision-date "2015-01-01"; > } > > augment b:/port-knob { > when "b:knob-type = 'faster'"; > leaf alt-knob-type { > type b:port-knob-type; > } > } > > augment b:/port-knob { > when "b:knob-type = 'fastest'"; > leaf boost-factor { type uint32; } > } > > } > > > The 'aug1' developer clearly intends for the server to > support base@2015-01-01. > > But the vendor decides to advertise base@2014-01-01. Well, boost-factor is only relevant if b:knob-type is 'fastest'. So if the vendor advertises base@2014-01-01, b:knob-type can never be 'fastest'. I don't see any problem with this. > The 'port-knob' list is augmented with the new version > of the port-knob-type (if 'faster') even though the server implements > the old version. > > The ''boost-factor'' leaf will never augment the port-knob list > because server does not support the 'fastest' enum. > > This is more than just confusing, especially if the server > advertises that it conforms to the "aug1" module. It advertises that it *implements* aug1. I think Juergen has tried to say several times that what we're trying to do is really to let the server advertise what it implements, and then add possibly more useful conformance functions later (maybe something like your packages). /martin From nobody Sun Apr 26 11:04:48 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5706B1AD47E for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 11:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja9S4fc9lWk3 for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 11:04:45 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 7E6F01AD379 for <netmod@ietf.org>; Sun, 26 Apr 2015 11:04:45 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so67475790lbb.0 for <netmod@ietf.org>; Sun, 26 Apr 2015 11:04:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1dPbYDOxSACKJw+bx58dAEr40uQ6JMT0JOACeR8Vfys=; b=mqFpmmn1ox7jN1hm/iSwK+TSYjx8dgxXVuaa20gdSb5xYZOzJN5saPrZ6HHxJ644eC oi5yDj8cL1zi1kazNbidsIm3TzjPxMzgt38KWzbLu9Z5Gm4Bd2pjk78Z7aRFojCU+auR mrrForyHluMnwvd/dE97NForSYvpzEGthB7DpZMrejroLIOPzw3IgBCNL6K0DM5SAoie 3wapPAcnV63XbTwWfqdbQb63F2n1CgRPEeOvnk7ckGs1yodXzuO79vgLv03WWaYG5kI6 SrbE1l95D0fcAFzSD+uQUCeWIDkKAODOqMzgQQPfYeqd25rKDieDZkD8E0z6GAuTXhQC c9RA== X-Gm-Message-State: ALoCoQm+TZ7OUxhrDR2kcjCc0CrwdLe5vXTY/WRYJgzSLfLgwJBzOdxr7lCyOppvKmOJcF/qTJNz MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr6934405lab.82.1430071483857; Sun, 26 Apr 2015 11:04:43 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Apr 2015 11:04:43 -0700 (PDT) In-Reply-To: <20150426171805.GA16991@elstar.local> References: <CABCOCHQqtD2yhtq3x9rLBeYj-HAz=UDhSSKGwSZ9UTbGyraLug@mail.gmail.com> <20150423073428.GA2450@elstar.local> <CABCOCHTdvjhYjr6b437hfYeT+gGGgqTvMN7jr04pHXC3-c0Bzg@mail.gmail.com> <m2r3r9uceh.fsf@birdie.labs.nic.cz> <20150424124251.GA6132@elstar.local> <CABCOCHQjwkF4QCo5d37YuQfzk2bR5KwzycwK3QB9wJW1dAsLpA@mail.gmail.com> <20150424151338.GA6855@elstar.local> <CABCOCHQXZks8xjkbwcdSuM5T08gB=E9Yx-jZGCiy0T22xVW0SA@mail.gmail.com> <20150426125727.GA16630@elstar.local> <CABCOCHQdeyw-3RvDmJBxbXqoGCJ4gF=ym-cD-kWs793K=TGmhQ@mail.gmail.com> <20150426171805.GA16991@elstar.local> Date: Sun, 26 Apr 2015 11:04:43 -0700 Message-ID: <CABCOCHRiD133R4HE+nQHAhCsG00kmOvtHFnEtOMb=OUy2WJN+w@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/yEyENZUHJZORbPFU-eBFEZXSask> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Apr 2015 18:04:47 -0000 On Sun, Apr 26, 2015 at 10:18 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Apr 26, 2015 at 09:08:11AM -0700, Andy Bierman wrote: >> On Sun, Apr 26, 2015 at 5:57 AM, Juergen Schoenwaelder >> <j.schoenwaelder@jacobs-university.de> wrote: >> > On Fri, Apr 24, 2015 at 08:54:08AM -0700, Andy Bierman wrote: >> >> On Fri, Apr 24, 2015 at 8:13 AM, Juergen Schoenwaelder >> >> <j.schoenwaelder@jacobs-university.de> wrote: >> >> > On Fri, Apr 24, 2015 at 08:00:05AM -0700, Andy Bierman wrote: >> >> >> Hi, >> >> >> >> >> >> From a conformance POV, letting the vendor choose among >> >> >> many obsolete revisions and still claim conformance >> >> >> it totally broken. The data model writers are supposed >> >> >> to specify conformance at module-write-time, >> >> >> The vendor should not be specifying conformance at >> >> >> module-load-time. >> >> >> >> >> >> The goal of conformance is to specify what the client and server >> >> >> are supposed to implement. The goal of server capability discovery >> >> >> is to specify what the server actually implements. I think the WG is >> >> >> confused (or ignoring) the difference. >> >> >> >> >> > >> >> > Sure, I may be confused. But let me try to explain again how I look at >> >> > this: >> >> > >> >> > a) With Y45-04, we are fixing the typedef drift and grouping drift >> >> > problem. This is an important module compile time issue. Fixing >> >> > this makes it unambiguous at module compile time what the >> >> > definitions resolve to. >> >> > >> >> > b) A server announces the modules and the revisions it implements via >> >> > the yang library data model. This covers the 'server capability >> >> > discovery' you mention above. (Note: Once I have the modules at >> >> > their specific revisions, I can can compile them without any >> >> > typedef drift and grouping drift issues.) >> >> > >> >> > c) The part that we do not cover is the 'specification of conformance >> >> > that a server has to implement' (to support certain use cases). >> >> > This is what we assume to be able to cover in the future using >> >> > language extensions (and you wrote a pretty decent proposal for >> >> > this a while ago). >> >> > >> >> > I think I learned during the many discussions that the idea to derive >> >> > c) out of the imports is not workable. >> >> > >> >> >> >> But the current solution is even worse than no solution. >> >> The client developer needs to be able to code to the model >> >> and have that code with servers that conform to the model. >> >> >> > >> > I believe Y45-04 allows that. >> > >> >> I don't think more than 1 revision of a module needs to be imported. >> Cherry-picking from all available revisions is a bad precedent. > > What are the alternatives? Move definitions into many very small > modules so that all-or-nothing updates are workable? Require that all > semantically changed definitions get a new name? The later is the at > the end the same except that you maintain all revisions inside the > module. In other words, cherry-picking by itself is not a bad > precedent, we have been doing that before - the question is just how > we maintain the different versions. > I don't think the YANG module packaging and imports used is a good way to document the conformance requirements for meaningful sets of protocol accessible objects. That's why I proposed conformance packages in the YANG Conformance draft. The only way the using import without revision is really safe is if all definitions used from the importing module were available from the very first revision. Since we are on the first revision of everything, the need for a "min-revision" is not apparent yet. If we ever change a definition to obsolete, then the need for a "max-revision" will become apparent. (These parameters were in the original conformance draft). Andy >> The 'port-knob-type' example is the most common use-case -- >> adding a new enum to a typedef. The WG already agreed (I think) >> that the server MUST support the base module augmented >> from another module. The example shows the server MUST implement >> the same (or more recent) version that is used by any module that >> augments the module, in order to claim conformance for both the >> augmented and augmenting modules. > > I do not think that the WG agreed on something yet. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> From nobody Sun Apr 26 11:11:34 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D70E1B2BCE for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 11:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3etPyp5xBII2 for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 11:11:31 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 B7E081B2A10 for <netmod@ietf.org>; Sun, 26 Apr 2015 11:11:30 -0700 (PDT) Received: by labbd9 with SMTP id bd9so65553970lab.2 for <netmod@ietf.org>; Sun, 26 Apr 2015 11:11:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pElY0ryPbso9eNz1xiAkwnFnuLrU3OgtC92QRCsGDG4=; b=ms1THj/Qhdy6Mcl84ulizQ+WgA8y3JCeM9tqgdtvnfai6s1eL2LGl2RkCjeK/eV0Pq TKDXr+MAUXW1V8p6ab1WMaTBgSYHls12CKzmWrRpwd2kJnUvyRNkPVkvUpTOlkH0hRGi x0u/+Pnw3LWsEKJJXnYabsqEdxnYazkFgTebrlFEr/S6eTdy1tZHayqh5WmsglKpEM3Z WRNiMmdrOVHpjLMHlGSX1E35lYpQzLvdfPdcchLp9aBylyV1fztDyuVGrFORR0gg7v32 hCllLNLjHJjZvOMO3fs7rTAC4h6In0uZ+/Boz63hmZs16RTdWdeO5eNmbY/6XI+qF3T+ 9pVw== X-Gm-Message-State: ALoCoQlItUrUa7ENe1QDmKQ70WLKo5nQK1qtcyhdinkZfUcV7NicG3UXqx5uOVLOJiWgxYck6RPl MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr6950864lab.82.1430071889262; Sun, 26 Apr 2015 11:11:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 26 Apr 2015 11:11:29 -0700 (PDT) In-Reply-To: <20150426.193211.1077355394949650317.mbj@tail-f.com> References: <20150424073738.GC5506@elstar.local> <20150424.100644.959374717987870887.mbj@tail-f.com> <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> Date: Sun, 26 Apr 2015 11:11:29 -0700 Message-ID: <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Martin Bjorklund <mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/E2pg-Y6HLSysZFxZFV-h6PH-r8s> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Apr 2015 18:11:32 -0000 On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > Andy Bierman <andy@yumaworks.com> wrote: >> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> wrote: >> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >> >> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >> >> > >> >> > Let me try to explain my concern again... >> >> > >> >> > The authors of "bar" expect that module X rev 2 will be supported. >> >> > That is why they used import-by-revision. Mixing typedefs and >> >> > groupings from R2 and protocol accessible objects from R1 is not what >> >> > they expect. They cannot possibly write their module "bar" >> >> > for every possible combination of down-rev X modules the vendor may choose. >> >> > >> >> > It is not the fault of the designers if bar does not work with X@R1. >> >> > They expect X@R2 to be used. >> >> > >> >> >> >> I can easily construct cases where this may not be true nor >> >> problematic. If we make the interpretation min-revision, I am sure we >> >> will regret it at some point in time >> > >> > I agree. The min-revision rule would be an unnecessary CLR. >> > >> > I asked before for an example of where the proposed solution is >> > problematic, and where the min-revision would solve that. >> >> >> Here is a simple example that I find problematic. >> This is what I mean by coding to the model. >> The client developer adds code to augment a base node >> if the port-knob-type is 'fastest' >> >> >> module base { >> ... >> revision 2014-01-01; >> typedef port-knob-type { >> type enumeration { >> enum fast; >> enum faster; >> } >> } >> list port-knob { >> key name; >> leaf name { type string; } >> leaf knob-type { type port-knob-type; } >> } >> } >> >> >> module base { >> ... >> revision 2015-01-01; >> typedef port-knob-type { >> type enumeration { >> enum fast; >> enum faster; >> enum fastest' // added new enum >> } >> } >> list port-knob { >> key name; >> leaf name { type string; } >> leaf knob-type { >> type port-knob-type; >> default fast; >> >> } >> } >> >> module aug1 { >> ... >> import base { >> prefix b; >> revision-date "2015-01-01"; >> } >> >> augment b:/port-knob { >> when "b:knob-type = 'faster'"; >> leaf alt-knob-type { >> type b:port-knob-type; >> } >> } >> >> augment b:/port-knob { >> when "b:knob-type = 'fastest'"; >> leaf boost-factor { type uint32; } >> } >> >> } >> >> >> The 'aug1' developer clearly intends for the server to >> support base@2015-01-01. >> >> But the vendor decides to advertise base@2014-01-01. > > Well, boost-factor is only relevant if b:knob-type is 'fastest'. So > if the vendor advertises base@2014-01-01, b:knob-type can never be > 'fastest'. I don't see any problem with this. > >> The 'port-knob' list is augmented with the new version >> of the port-knob-type (if 'faster') even though the server implements >> the old version. >> >> The ''boost-factor'' leaf will never augment the port-knob list >> because server does not support the 'fastest' enum. >> >> This is more than just confusing, especially if the server >> advertises that it conforms to the "aug1" module. > > It advertises that it *implements* aug1. > This is the problem. If it does advertise "aug1", then it MUST advertise "not-supported" deviations for both leafs, because they both rely on the new revision of the typedef, and the server does not implement the new typedef. > I think Juergen has tried to say several times that what we're trying > to do is really to let the server advertise what it implements, and > then add possibly more useful conformance functions later (maybe > something like your packages). > This proposal does not let the client developer know what the server is supposed to implement. The conformance requirements are not very precise. > > > /martin Andy From nobody Sun Apr 26 11:48:33 2015 Return-Path: <mbj@tail-f.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740621B2C53 for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 11:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SGd2lzkjOHd for <netmod@ietfa.amsl.com>; Sun, 26 Apr 2015 11:48:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 143F11B2C41 for <netmod@ietf.org>; Sun, 26 Apr 2015 11:48:30 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 005B41AE00B6; Sun, 26 Apr 2015 20:48:27 +0200 (CEST) Date: Sun, 26 Apr 2015 20:50:33 +0200 (CEST) Message-Id: <20150426.205033.1440726706036395955.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund <mbj@tail-f.com> In-Reply-To: <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> References: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/QEegvG-nUkdjIYgSb63VlTapmlQ> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 26 Apr 2015 18:48:31 -0000 Andy Bierman <andy@yumaworks.com> wrote: > On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > Andy Bierman <andy@yumaworks.com> wrote: > >> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > >> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > >> >> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: > >> >> > > >> >> > Let me try to explain my concern again... > >> >> > > >> >> > The authors of "bar" expect that module X rev 2 will be supported. > >> >> > That is why they used import-by-revision. Mixing typedefs and > >> >> > groupings from R2 and protocol accessible objects from R1 is not what > >> >> > they expect. They cannot possibly write their module "bar" > >> >> > for every possible combination of down-rev X modules the vendor may choose. > >> >> > > >> >> > It is not the fault of the designers if bar does not work with X@R1. > >> >> > They expect X@R2 to be used. > >> >> > > >> >> > >> >> I can easily construct cases where this may not be true nor > >> >> problematic. If we make the interpretation min-revision, I am sure we > >> >> will regret it at some point in time > >> > > >> > I agree. The min-revision rule would be an unnecessary CLR. > >> > > >> > I asked before for an example of where the proposed solution is > >> > problematic, and where the min-revision would solve that. > >> > >> > >> Here is a simple example that I find problematic. > >> This is what I mean by coding to the model. > >> The client developer adds code to augment a base node > >> if the port-knob-type is 'fastest' > >> > >> > >> module base { > >> ... > >> revision 2014-01-01; > >> typedef port-knob-type { > >> type enumeration { > >> enum fast; > >> enum faster; > >> } > >> } > >> list port-knob { > >> key name; > >> leaf name { type string; } > >> leaf knob-type { type port-knob-type; } > >> } > >> } > >> > >> > >> module base { > >> ... > >> revision 2015-01-01; > >> typedef port-knob-type { > >> type enumeration { > >> enum fast; > >> enum faster; > >> enum fastest' // added new enum > >> } > >> } > >> list port-knob { > >> key name; > >> leaf name { type string; } > >> leaf knob-type { > >> type port-knob-type; > >> default fast; > >> > >> } > >> } > >> > >> module aug1 { > >> ... > >> import base { > >> prefix b; > >> revision-date "2015-01-01"; > >> } > >> > >> augment b:/port-knob { > >> when "b:knob-type = 'faster'"; > >> leaf alt-knob-type { > >> type b:port-knob-type; > >> } > >> } > >> > >> augment b:/port-knob { > >> when "b:knob-type = 'fastest'"; > >> leaf boost-factor { type uint32; } > >> } > >> > >> } > >> > >> > >> The 'aug1' developer clearly intends for the server to > >> support base@2015-01-01. > >> > >> But the vendor decides to advertise base@2014-01-01. > > > > Well, boost-factor is only relevant if b:knob-type is 'fastest'. So > > if the vendor advertises base@2014-01-01, b:knob-type can never be > > 'fastest'. I don't see any problem with this. > > > >> The 'port-knob' list is augmented with the new version > >> of the port-knob-type (if 'faster') even though the server implements > >> the old version. > >> > >> The ''boost-factor'' leaf will never augment the port-knob list > >> because server does not support the 'fastest' enum. > >> > >> This is more than just confusing, especially if the server > >> advertises that it conforms to the "aug1" module. > > > > It advertises that it *implements* aug1. > > > > This is the problem. > If it does advertise "aug1", then it MUST advertise "not-supported" deviations > for both leafs, because they both rely on the new revision of the typedef, > and the server does not implement the new typedef. No, the definition of the augment for boost-factor does not strictly rely on the new revision of the typedef. It's just that the when expression will never evaluate to true if the newer version isn't implemented. > > I think Juergen has tried to say several times that what we're trying > > to do is really to let the server advertise what it implements, and > > then add possibly more useful conformance functions later (maybe > > something like your packages). > > > > This proposal does not let the client developer know what the server is > supposed to implement. The conformance requirements are not very > precise. Agreed. This is why we want to address the conformance problem separately. Right now we try focus on what the different constructs really imply in terms of implementing other modules. /martin From nobody Mon Apr 27 07:42:30 2015 Return-Path: <steve.baillargeon@ericsson.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBABA1A1BC0 for <netmod@ietfa.amsl.com>; Mon, 27 Apr 2015 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cwJA1W-KpDr for <netmod@ietfa.amsl.com>; Mon, 27 Apr 2015 07:42:24 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BC21A6F02 for <netmod@ietf.org>; Mon, 27 Apr 2015 07:41:40 -0700 (PDT) X-AuditID: c618062d-f79a96d000007fb1-1d-553df328d7a0 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C9.5F.32689.823FD355; Mon, 27 Apr 2015 10:28:24 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 27 Apr 2015 10:41:38 -0400 From: Steve Baillargeon <steve.baillargeon@ericsson.com> To: "netmod@ietf.org" <netmod@ietf.org> Thread-Topic: New Version Notification for draft-baill-netmod-yang-ip-stats-01.txt Thread-Index: AQHQgPbDbsillD9UFkCuO1vXEPWoe51g7Blw Date: Mon, 27 Apr 2015 14:41:38 +0000 Message-ID: <DCF22B50497F7641B6DDD16ECC516F7F3F1F2CC4@eusaamb105.ericsson.se> References: <20150427143001.5700.94388.idtracker@ietfa.amsl.com> In-Reply-To: <20150427143001.5700.94388.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyuXSPn67GZ9tQgzVbxC3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrQVc5kKeoQr/m56zdrAeEaoi5GTQ0LARGLvvG2MELaYxIV7 69m6GLk4hASOMkq0rfzDDOEsZ5S40t/LDFLFJmAhsX7uMjBbREBdYuZOkA5ODmGBYIk9K14z QcRDJI7NX84IYRtJXN3VDFbPIqAqcfwhRJxXwFfi5cKzYHEhAQeJZVfes4LYnAKOEku7N7CA 2IwCshK7z14Hm8ksIC5x68l8JohLBSSW7DnPDGGLSrx8/I8VwlaSmLT0HJDNAVSvKbF+lz5E q6LElO6H7BBrBSVOznzCMoFRdBaSqbMQOmYh6ZiFpGMBI8sqRo7S4tSy3HQjg02MwLA/JsGm u4Nxz0vLQ4wCHIxKPLwP4m1DhVgTy4orcw8xSnOwKInzLnpwMERIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY/bX2fb1q3dsypW2mvTZ3USruLnusOj5S5rv+l68bPX09A1v37y35lVCcybb HG7rlcdFI79HHv1gvOq6+d8bJ6ftbdqdqai6RpZPm93rjujeu+eVJ0+54PJ5sXRFkdt0bT8D voUiDz9t2i5hoK2lG2Wz64bBwff7C9zW34l60ugeNo2VZ5cQgxJLcUaioRZzUXEiAJklMZZc AgAA Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/CKM-KdehWNzCruQOI7QjSfJbtTM> Subject: Re: [netmod] New Version Notification for draft-baill-netmod-yang-ip-stats-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Apr 2015 14:42:30 -0000 SGkNClRoZSBjaGFuZ2VzIGFyZToNCg0KLUZpeGVkIGFsbCBlcnJvcnMgZm91bmQgYnkgcHlhbmcg KHRoYW5rIHlvdSBmb3IgdGhlIHJlbWluZGVyKQ0KLUFkZGVkIG5ldyBJUCBpbnRlcmZhY2UgY291 bnRlciBjYWxsZWQgaW4tc2NyLWFkZHItZXJyb3JzIHRvIHNwZWNpZmljYWxseSB0cmFjayBJUCBt dWx0aWNhc3QgZGlzY2FyZHMgZHVlIHRvIGludmFsaWQgc291cmNlIElQIGFkZHJlc3MuDQotRGVm aW5lZCBhIHRvcC1sZXZlbCDigJ0gc3lzdGVtLXN0YXRzIiBjb250YWluZXIgaW50ZW5kZWQgdG8g aG9sZCBhbnkgc3lzdGVtIHdpZGUgc3RhdGlzdGljcy4gDQotSW1wcm92ZWQgY291bnRlci9zdGF0 aXN0aWMgZGVmaW5pdGlvbnMuDQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkg Y29tbWVudHMgb3Igc3VnZ2VzdGlvbnMuDQoNCi1TdGV2ZSBCDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBBcHJpbCAyNywgMjAxNSAxMDozMCBB TQ0KVG86IFN0ZXZlIEJhaWxsYXJnZW9uOyBTdGV2ZSBCYWlsbGFyZ2Vvbg0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iYWlsbC1uZXRtb2QteWFuZy1pcC1zdGF0 cy0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmFpbGwtbmV0bW9kLXlh bmctaXAtc3RhdHMtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN0 ZXZlIEJhaWxsYXJnZW9uIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZToJCWRyYWZ0LWJhaWxsLW5ldG1vZC15YW5nLWlwLXN0YXRzDQpSZXZpc2lvbjoJMDENClRpdGxl OgkJQSBZQU5HIERhdGEgTW9kZWwgZm9yIGJhc2ljIElQIGFuZCBJQ01QIFN0YXRpc3RpY3MNCkRv Y3VtZW50IGRhdGU6CTIwMTUtMDQtMjcNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczoJCTM3DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtYmFpbGwtbmV0bW9kLXlhbmctaXAtc3RhdHMtMDEudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmFpbGwtbmV0bW9k LXlhbmctaXAtc3RhdHMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYmFpbGwtbmV0bW9kLXlhbmctaXAtc3RhdHMtMDENCkRpZmY6ICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1iYWlsbC1uZXRtb2QteWFuZy1p cC1zdGF0cy0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcg ZGF0YSBtb2RlbCBmb3IgYmFzaWMgSVAgYW5kIElDTVANCiAgIHN0YXRpc3RpY3MgZm9yIG1vbml0 b3JpbmcgSVB2NCBhbmQgSVB2NiBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From nobody Thu Apr 30 06:56:54 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5071A903D for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 06:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSaeK0UwuS8N for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 06:56:49 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEB41A1EF6 for <netmod@ietf.org>; Thu, 30 Apr 2015 06:56:49 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa07-06.prod.phx3.secureserver.net with id NDwn1q00W4vySjM01DwoE4; Thu, 30 Apr 2015 06:56:48 -0700 Message-ID: <554234A1.9090900@seguesoft.com> Date: Thu, 30 Apr 2015 08:56:49 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: netmod@ietf.org References: <554233A9.1070109@seguesoft.com> In-Reply-To: <554233A9.1070109@seguesoft.com> X-Forwarded-Message-Id: <554233A9.1070109@seguesoft.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/PYgbBHj2i8sHRh3SpWgXLWf16vE> Subject: [netmod] Fwd: Re: closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 13:56:51 -0000 On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >> >> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>> >>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrote: >>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I like to close Y45. It seems most people are fine with Y45-04. Andy >>>>>>> may not be fully convinced or he wants a slight change of Y54-04 that >>>>>>> turns import-by-revision semantically into import-by-min-revision. >>>>>>> Xiang Li seems to support a motion to make import-by-revision mean >>>>>>> import-by-min-revision. So perhaps a possible solution is to settle on >>>>>>> Y45-04 with a slight change that import-by-revision mean indeed >>>>>>> import-by-min-revision. (We would have to write this variation down >>>>>>> and give it a new number - any volunteers?) >>>>>> Two questions: >>>>>> >>>>>> 1. Is import-by-revision supposed to mean import-by-min-revision only >>>>>> for augments? For groupings and typedefs it should IMO mean an exact >>>>>> revision. >>>>> Yes. >>>>> >>>> I guess this would be more than just augments. Essentially any >>>> reference to an 'object' defined in an external module, irrespective >>>> whether the reference is via augments or a must/when statement or >>>> anything else. >>> For must/when a revision makes even less sense because XPath expressions refer to an instance document rather than a module. >>> >> But isn't the same is true for an augment that refers to a target that >> is a list of a container? The target instance must not only be >> defined, it must also exist for the augment to have an effect. > No, the target node is by definition a schema node, an augment manipulates the schema - no instance is involved. > >> Anyway, the main idea behind Y45-04 is to use imports to handle schema >> tree dependencies that need to be unambiguous at module compile time >> and to leave instance tree dependencies to future work (e.g. a package >> definition system like Andy once proposed). > For augments the package is in fact given by the hello message or other form of data model specification, because an augment makes sense only if its target node is part of the schema. In fact, not only revision of the imported module is important here: "not only revision of the imported module is important..."? I thought you have been arguing for the contrary? Did you mean "not only revision of the advertised module is important..."? --Xiang > what if the target node depends on a feature? That’s why pyang accepts a hello message in a file where all this can be neatly specified (I plan to add support for yang-library). > Lada > >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Thu Apr 30 07:19:27 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2532C1B2B32 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 07:19:26 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9bMCcTkG1pS for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 07:19:24 -0700 (PDT) Received: from p3plsmtpa07-10.prod.phx3.secureserver.net (p3plsmtpa07-10.prod.phx3.secureserver.net [173.201.192.239]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836481B2B16 for <netmod@ietf.org>; Thu, 30 Apr 2015 07:19:01 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa07-10.prod.phx3.secureserver.net with id NEK01q0044vySjM01EK0h0; Thu, 30 Apr 2015 07:19:01 -0700 Message-ID: <554239D5.9030102@seguesoft.com> Date: Thu, 30 Apr 2015 09:19:01 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: netmod@ietf.org References: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> <20150426.205033.1440726706036395955.mbj@tail-f.com> In-Reply-To: <20150426.205033.1440726706036395955.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/4b-75n4iabai28HaBT_UGlFHKe4> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 14:19:26 -0000 On 4/26/2015 1:50 PM, Martin Bjorklund wrote: > Andy Bierman <andy@yumaworks.com> wrote: >> On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> wrote: >>> Andy Bierman <andy@yumaworks.com> wrote: >>>> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> wrote: >>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >>>>>>> Let me try to explain my concern again... >>>>>>> >>>>>>> The authors of "bar" expect that module X rev 2 will be supported. >>>>>>> That is why they used import-by-revision. Mixing typedefs and >>>>>>> groupings from R2 and protocol accessible objects from R1 is not what >>>>>>> they expect. They cannot possibly write their module "bar" >>>>>>> for every possible combination of down-rev X modules the vendor may choose. >>>>>>> >>>>>>> It is not the fault of the designers if bar does not work with X@R1. >>>>>>> They expect X@R2 to be used. >>>>>>> >>>>>> I can easily construct cases where this may not be true nor >>>>>> problematic. If we make the interpretation min-revision, I am sure we >>>>>> will regret it at some point in time >>>>> I agree. The min-revision rule would be an unnecessary CLR. >>>>> >>>>> I asked before for an example of where the proposed solution is >>>>> problematic, and where the min-revision would solve that. >>>> >>>> Here is a simple example that I find problematic. >>>> This is what I mean by coding to the model. >>>> The client developer adds code to augment a base node >>>> if the port-knob-type is 'fastest' >>>> >>>> >>>> module base { >>>> ... >>>> revision 2014-01-01; >>>> typedef port-knob-type { >>>> type enumeration { >>>> enum fast; >>>> enum faster; >>>> } >>>> } >>>> list port-knob { >>>> key name; >>>> leaf name { type string; } >>>> leaf knob-type { type port-knob-type; } >>>> } >>>> } >>>> >>>> >>>> module base { >>>> ... >>>> revision 2015-01-01; >>>> typedef port-knob-type { >>>> type enumeration { >>>> enum fast; >>>> enum faster; >>>> enum fastest' // added new enum >>>> } >>>> } >>>> list port-knob { >>>> key name; >>>> leaf name { type string; } >>>> leaf knob-type { >>>> type port-knob-type; >>>> default fast; >>>> >>>> } >>>> } >>>> >>>> module aug1 { >>>> ... >>>> import base { >>>> prefix b; >>>> revision-date "2015-01-01"; >>>> } >>>> >>>> augment b:/port-knob { >>>> when "b:knob-type = 'faster'"; >>>> leaf alt-knob-type { >>>> type b:port-knob-type; >>>> } >>>> } >>>> >>>> augment b:/port-knob { >>>> when "b:knob-type = 'fastest'"; >>>> leaf boost-factor { type uint32; } >>>> } >>>> >>>> } >>>> >>>> >>>> The 'aug1' developer clearly intends for the server to >>>> support base@2015-01-01. >>>> >>>> But the vendor decides to advertise base@2014-01-01. >>> Well, boost-factor is only relevant if b:knob-type is 'fastest'. So >>> if the vendor advertises base@2014-01-01, b:knob-type can never be >>> 'fastest'. I don't see any problem with this. >>> >>>> The 'port-knob' list is augmented with the new version >>>> of the port-knob-type (if 'faster') even though the server implements >>>> the old version. >>>> >>>> The ''boost-factor'' leaf will never augment the port-knob list >>>> because server does not support the 'fastest' enum. >>>> >>>> This is more than just confusing, especially if the server >>>> advertises that it conforms to the "aug1" module. >>> It advertises that it *implements* aug1. >>> >> This is the problem. >> If it does advertise "aug1", then it MUST advertise "not-supported" deviations >> for both leafs, because they both rely on the new revision of the typedef, >> and the server does not implement the new typedef. > No, the definition of the augment for boost-factor does not strictly > rely on the new revision of the typedef. It's just that the when > expression will never evaluate to true if the newer version isn't > implemented. But if a server advertises "aug1" the it is claiming that "aug1" is fully supported. Since 'aug1' augments "base 2015-01-01", I would think that I must be able to set the leaf "b:knob-type" to the value "fastest" and then expect to be able to play with the augmented "boost-factor" leaf. If the server advertises only "base 2014-01-01", this would not be possible. Is this an invalid scenario? Anyway, as I said earlier I agree with Y45-04 if no valid use-case exists for 'min-revision-rule" since that seems to be cleanest way to address the question we are trying to address. It is just different from what I thought originally that augmenting a module via "import-by-revision" implies the imported module version is the base of the augmenting and hence it must be supported first. --Xiang >>> I think Juergen has tried to say several times that what we're trying >>> to do is really to let the server advertise what it implements, and >>> then add possibly more useful conformance functions later (maybe >>> something like your packages). >>> >> This proposal does not let the client developer know what the server is >> supposed to implement. The conformance requirements are not very >> precise. > Agreed. This is why we want to address the conformance problem > separately. Right now we try focus on what the different constructs > really imply in terms of implementing other modules. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 30 08:09:14 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3D51A1B4A for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 08:09: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRbt6xBNUBnt for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 08:09:10 -0700 (PDT) Received: from p3plsmtpa07-04.prod.phx3.secureserver.net (p3plsmtpa07-04.prod.phx3.secureserver.net [173.201.192.233]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC811A8935 for <netmod@ietf.org>; Thu, 30 Apr 2015 08:08:43 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa07-04.prod.phx3.secureserver.net with id NF8i1q0094vySjM01F8it4; Thu, 30 Apr 2015 08:08:43 -0700 Message-ID: <5542457C.3040909@seguesoft.com> Date: Thu, 30 Apr 2015 10:08:44 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ladislav Lhotka <lhotka@nic.cz> References: <20150430102958.GB55253@elstar.local> <D3DE21C4-DABB-49D4-A440-722E45E684E5@nic.cz> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <A2E9E03C-C183-4776-8DAB-E80C1E8C68DF@nic.cz> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> In-Reply-To: <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/U1C8nWAhThjUBeYhV202vQV63r0> Cc: netmod@ietf.org Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 15:09:12 -0000 On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >> On 30 Apr 2015, at 15:52, Xiang Li <xiangli@seguesoft.com> wrote: >> >> >> >> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>> >>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>> >>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrote: >>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I like to close Y45. It seems most people are fine with Y45-04. Andy >>>>>>>>> may not be fully convinced or he wants a slight change of Y54-04 that >>>>>>>>> turns import-by-revision semantically into import-by-min-revision. >>>>>>>>> Xiang Li seems to support a motion to make import-by-revision mean >>>>>>>>> import-by-min-revision. So perhaps a possible solution is to settle on >>>>>>>>> Y45-04 with a slight change that import-by-revision mean indeed >>>>>>>>> import-by-min-revision. (We would have to write this variation down >>>>>>>>> and give it a new number - any volunteers?) >>>>>>>> Two questions: >>>>>>>> >>>>>>>> 1. Is import-by-revision supposed to mean import-by-min-revision only >>>>>>>> for augments? For groupings and typedefs it should IMO mean an exact >>>>>>>> revision. >>>>>>> Yes. >>>>>>> >>>>>> I guess this would be more than just augments. Essentially any >>>>>> reference to an 'object' defined in an external module, irrespective >>>>>> whether the reference is via augments or a must/when statement or >>>>>> anything else. >>>>> For must/when a revision makes even less sense because XPath expressions refer to an instance document rather than a module. >>>>> >>>> But isn't the same is true for an augment that refers to a target that >>>> is a list of a container? The target instance must not only be >>>> defined, it must also exist for the augment to have an effect. >>> No, the target node is by definition a schema node, an augment manipulates the schema - no instance is involved. >>> >>>> Anyway, the main idea behind Y45-04 is to use imports to handle schema >>>> tree dependencies that need to be unambiguous at module compile time >>>> and to leave instance tree dependencies to future work (e.g. a package >>>> definition system like Andy once proposed). >>> For augments the package is in fact given by the hello message or other form of data model specification, because an augment makes sense only if its target node is part of the schema. In fact, not only revision of the imported module is important here: >> "not only revision of the imported module is important..."? >> >> I thought you have been arguing for the contrary? Did you mean "not only revision of the advertised module is important…"? > Let’s go back to Andy’s example > > http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html > > Andy wrote: “The 'aug1' developer clearly intends for the server to support base@2015-01-01.” > > But let’s say the new enum in module “base” is defined like so: > > enum fastest { > if-feature foo; > } > > Then I could argue that ‘aug1’ developer clearly intends for the server to support not only base@2015-01-01 but also feature foo. However, the latter requirement is not expressed in import-by-revision. Current YANG "enum" does not allow "if-feature" as its substatement. But in general if things depend on some 'features' implemented in an augmented base module then they are IMO by definition optional. In other words, 'aug1' developer can't demand a server to support feature 'foo', if it is not advertised. I don't see that's relevant here. --Xiang From nobody Thu Apr 30 08:54:34 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4C81B2D15 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 08:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltEr6mBEzZdm for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 08:54:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE501B2D27 for <netmod@ietf.org>; Thu, 30 Apr 2015 08:54:18 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 4A19B140A3F; Thu, 30 Apr 2015 17:54:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1430409257; bh=OzcW06aKw2XI9qbx0sUR2u4OC7TAv20Oxn+7CsuBk6E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=w7EluVoE0/sPnqGLDGQ9dXaqDjJ5Z/7AJctcVCKFdkgbw6WFgpio74Q7LY158Bu5M nFpe5R5sfLZenzTy9QzjjDAuYIeJVFnAJtFSy4AP3x/ZT1M8UiYMDsS8PKSPbzW5Jp WiMakUHAVd/IBE8s94Ci8xpsyy1mtCGz9NDukQpc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <5542457C.3040909@seguesoft.com> Date: Thu, 30 Apr 2015 17:54:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <CCEE0F4B-9C98-4AED-BC88-62EFF2D18B27@nic.cz> References: <20150430102958.GB55253@elstar.local> <D3DE21C4-DABB-49D4-A440-722E45E684E5@nic.cz> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <A2E9E03C-C183-4776-8DAB-E80C1E8C68DF@nic.cz> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> <5542457C.3040909@seguesoft.com> To: Xiang Li <xiangli@seguesoft.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/1zuJihtIcSJDFQSkHQI5a3oJIA0> Cc: netmod@ietf.org Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 15:54:33 -0000 > On 30 Apr 2015, at 17:08, Xiang Li <xiangli@seguesoft.com> wrote: >=20 >=20 >=20 > On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>> On 30 Apr 2015, at 15:52, Xiang Li <xiangli@seguesoft.com> wrote: >>>=20 >>>=20 >>>=20 >>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>>=20 >>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>=20 >>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund = wrote: >>>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> I like to close Y45. It seems most people are fine with = Y45-04. Andy >>>>>>>>>> may not be fully convinced or he wants a slight change of = Y54-04 that >>>>>>>>>> turns import-by-revision semantically into = import-by-min-revision. >>>>>>>>>> Xiang Li seems to support a motion to make import-by-revision = mean >>>>>>>>>> import-by-min-revision. So perhaps a possible solution is to = settle on >>>>>>>>>> Y45-04 with a slight change that import-by-revision mean = indeed >>>>>>>>>> import-by-min-revision. (We would have to write this = variation down >>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>> Two questions: >>>>>>>>>=20 >>>>>>>>> 1. Is import-by-revision supposed to mean = import-by-min-revision only >>>>>>>>> for augments? For groupings and typedefs it should IMO mean an = exact >>>>>>>>> revision. >>>>>>>> Yes. >>>>>>>>=20 >>>>>>> I guess this would be more than just augments. Essentially any >>>>>>> reference to an 'object' defined in an external module, = irrespective >>>>>>> whether the reference is via augments or a must/when statement = or >>>>>>> anything else. >>>>>> For must/when a revision makes even less sense because XPath = expressions refer to an instance document rather than a module. >>>>>>=20 >>>>> But isn't the same is true for an augment that refers to a target = that >>>>> is a list of a container? The target instance must not only be >>>>> defined, it must also exist for the augment to have an effect. >>>> No, the target node is by definition a schema node, an augment = manipulates the schema - no instance is involved. >>>>=20 >>>>> Anyway, the main idea behind Y45-04 is to use imports to handle = schema >>>>> tree dependencies that need to be unambiguous at module compile = time >>>>> and to leave instance tree dependencies to future work (e.g. a = package >>>>> definition system like Andy once proposed). >>>> For augments the package is in fact given by the hello message or = other form of data model specification, because an augment makes sense = only if its target node is part of the schema. In fact, not only = revision of the imported module is important here: >>> "not only revision of the imported module is important..."? >>>=20 >>> I thought you have been arguing for the contrary? Did you mean "not = only revision of the advertised module is important=E2=80=A6"? >> Let=E2=80=99s go back to Andy=E2=80=99s example >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>=20 >> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for the = server to support base@2015-01-01.=E2=80=9D >>=20 >> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80=9D = is defined like so: >>=20 >> enum fastest { >> if-feature foo; >> } >>=20 >> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly = intends for the server to support not only base@2015-01-01 but also = feature foo. However, the latter requirement is not expressed in = import-by-revision. >=20 > Current YANG "enum" does not allow "if-feature" as its substatement. Th one in YANG 1.1 proposal does. =20 >=20 > But in general if things depend on some 'features' implemented in an = augmented > base module then they are IMO by definition optional. In other words, = 'aug1' developer can't > demand a server to support feature 'foo', if it is not advertised. I = don't see that's relevant here. It is relevant - for the sake of this example, base@2015-01-01 without = feature foo is essentially the same as base@2014-01-01. In both cases = the augment from the aug1 module cannot be applied. I am not saying it = is a problem but the two situations are effectively identical. My point is that for processing augments and leafrefs, a more complete = conformance information has to be supplied anyway, so taking into = account revisions in import statements is not really needed. Lada >=20 > --Xiang -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 30 09:15:49 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0B41B2D64 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 09:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf_A0cJGXDi4 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 09:15:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24861B2D6C for <netmod@ietf.org>; Thu, 30 Apr 2015 09:15:44 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:34b8:6281:344:6685] (unknown [IPv6:2a01:5e0:29:ffff:34b8:6281:344:6685]) by mail.nic.cz (Postfix) with ESMTPSA id 2E2E8140A45; Thu, 30 Apr 2015 18:15:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1430410543; bh=eBALRHo0B9zIVWNqIhubKQ5c90ksHrLD5C5k5jqSs7o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=R49nFzl79bSfdVPJ+28GCqBv5AuCOmYhMzkMI0mPZFqKMTXA5n+E3eqMgR6KdPNJA 7dmAVXRUZvmMV5Q+dgc0hU2LyFq2EIewqY2GwlnaaD217q9OgAuzLroPNBf2rwO/zY QOiWdH5LJg6f/J+l3qF6nx9OlwjmMgqOMW9ubjnM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <554239D5.9030102@seguesoft.com> Date: Thu, 30 Apr 2015 18:15:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <EA7216C8-C7D6-440B-A5EE-5693B339D321@nic.cz> References: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> <20150426.205033.1440726706036395955.mbj@tail-f.com> <554239D5.9030102@seguesoft.com> To: Xiang Li <xiangli@seguesoft.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/T-W5em2H8449xK2-Ok4xvTdYQbQ> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 16:15:48 -0000 > On 30 Apr 2015, at 16:19, Xiang Li <xiangli@seguesoft.com> wrote: >=20 >=20 >=20 > On 4/26/2015 1:50 PM, Martin Bjorklund wrote: >> Andy Bierman <andy@yumaworks.com> wrote: >>> On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> = wrote: >>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> = wrote: >>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote: >>>>>>> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >>>>>>>> Let me try to explain my concern again... >>>>>>>>=20 >>>>>>>> The authors of "bar" expect that module X rev 2 will be = supported. >>>>>>>> That is why they used import-by-revision. Mixing typedefs and >>>>>>>> groupings from R2 and protocol accessible objects from R1 is = not what >>>>>>>> they expect. They cannot possibly write their module "bar" >>>>>>>> for every possible combination of down-rev X modules the vendor = may choose. >>>>>>>>=20 >>>>>>>> It is not the fault of the designers if bar does not work with = X@R1. >>>>>>>> They expect X@R2 to be used. >>>>>>>>=20 >>>>>>> I can easily construct cases where this may not be true nor >>>>>>> problematic. If we make the interpretation min-revision, I am = sure we >>>>>>> will regret it at some point in time >>>>>> I agree. The min-revision rule would be an unnecessary CLR. >>>>>>=20 >>>>>> I asked before for an example of where the proposed solution is >>>>>> problematic, and where the min-revision would solve that. >>>>>=20 >>>>> Here is a simple example that I find problematic. >>>>> This is what I mean by coding to the model. >>>>> The client developer adds code to augment a base node >>>>> if the port-knob-type is 'fastest' >>>>>=20 >>>>>=20 >>>>> module base { >>>>> ... >>>>> revision 2014-01-01; >>>>> typedef port-knob-type { >>>>> type enumeration { >>>>> enum fast; >>>>> enum faster; >>>>> } >>>>> } >>>>> list port-knob { >>>>> key name; >>>>> leaf name { type string; } >>>>> leaf knob-type { type port-knob-type; } >>>>> } >>>>> } >>>>>=20 >>>>>=20 >>>>> module base { >>>>> ... >>>>> revision 2015-01-01; >>>>> typedef port-knob-type { >>>>> type enumeration { >>>>> enum fast; >>>>> enum faster; >>>>> enum fastest' // added new enum >>>>> } >>>>> } >>>>> list port-knob { >>>>> key name; >>>>> leaf name { type string; } >>>>> leaf knob-type { >>>>> type port-knob-type; >>>>> default fast; >>>>>=20 >>>>> } >>>>> } >>>>>=20 >>>>> module aug1 { >>>>> ... >>>>> import base { >>>>> prefix b; >>>>> revision-date "2015-01-01"; >>>>> } >>>>>=20 >>>>> augment b:/port-knob { >>>>> when "b:knob-type =3D 'faster'"; >>>>> leaf alt-knob-type { >>>>> type b:port-knob-type; >>>>> } >>>>> } >>>>>=20 >>>>> augment b:/port-knob { >>>>> when "b:knob-type =3D 'fastest'"; >>>>> leaf boost-factor { type uint32; } >>>>> } >>>>>=20 >>>>> } >>>>>=20 >>>>>=20 >>>>> The 'aug1' developer clearly intends for the server to >>>>> support base@2015-01-01. >>>>>=20 >>>>> But the vendor decides to advertise base@2014-01-01. >>>> Well, boost-factor is only relevant if b:knob-type is 'fastest'. = So >>>> if the vendor advertises base@2014-01-01, b:knob-type can never be >>>> 'fastest'. I don't see any problem with this. >>>>=20 >>>>> The 'port-knob' list is augmented with the new version >>>>> of the port-knob-type (if 'faster') even though the server = implements >>>>> the old version. >>>>>=20 >>>>> The ''boost-factor'' leaf will never augment the port-knob list >>>>> because server does not support the 'fastest' enum. >>>>>=20 >>>>> This is more than just confusing, especially if the server >>>>> advertises that it conforms to the "aug1" module. >>>> It advertises that it *implements* aug1. >>>>=20 >>> This is the problem. >>> If it does advertise "aug1", then it MUST advertise "not-supported" = deviations >>> for both leafs, because they both rely on the new revision of the = typedef, >>> and the server does not implement the new typedef. >> No, the definition of the augment for boost-factor does not strictly >> rely on the new revision of the typedef. It's just that the when >> expression will never evaluate to true if the newer version isn't >> implemented. >=20 > But if a server advertises "aug1" the it is claiming that "aug1" is = fully supported. Since =E2=80=98aug1' This is not sufficient, in order to decide whether =E2=80=9Caug1=E2=80=9D = is fully supported, =E2=80=9Cbase=E2=80=9D must be advertised, too, and = the supported features as well. Lada > augments "base 2015-01-01", I would think that I must be able to set = the leaf "b:knob-type" > to the value "fastest" and then expect to be able to play with the = augmented "boost-factor" > leaf. If the server advertises only "base 2014-01-01", this would not = be possible. Is this an > invalid scenario? >=20 > Anyway, as I said earlier I agree with Y45-04 if no valid use-case = exists for 'min-revision-rule" > since that seems to be cleanest way to address the question we are = trying to address. > It is just different from what I thought originally that augmenting a = module via "import-by-revision" > implies the imported module version is the base of the augmenting and = hence it must be > supported first. >=20 > --Xiang >=20 >=20 >=20 >>>> I think Juergen has tried to say several times that what we're = trying >>>> to do is really to let the server advertise what it implements, and >>>> then add possibly more useful conformance functions later (maybe >>>> something like your packages). >>>>=20 >>> This proposal does not let the client developer know what the server = is >>> supposed to implement. The conformance requirements are not very >>> precise. >> Agreed. This is why we want to address the conformance problem >> separately. Right now we try focus on what the different constructs >> really imply in terms of implementing other modules. >>=20 >>=20 >> /martin >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 30 09:38:13 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706D41A9174 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 09:38: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njb5xU7q11Xl for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 09:38:10 -0700 (PDT) Received: from p3plsmtpa12-10.prod.phx3.secureserver.net (p3plsmtpa12-10.prod.phx3.secureserver.net [68.178.252.239]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E551A3BA5 for <netmod@ietf.org>; Thu, 30 Apr 2015 09:38:09 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa12-10.prod.phx3.secureserver.net with id NGe81q0084vySjM01Ge8m7; Thu, 30 Apr 2015 09:38:09 -0700 Message-ID: <55425A71.3060501@seguesoft.com> Date: Thu, 30 Apr 2015 11:38:09 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ladislav Lhotka <lhotka@nic.cz> References: <20150430102958.GB55253@elstar.local> <D3DE21C4-DABB-49D4-A440-722E45E684E5@nic.cz> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <A2E9E03C-C183-4776-8DAB-E80C1E8C68DF@nic.cz> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> <5542457C.3040909@seguesoft.com> <CCEE0F4B-9C98-4AED-BC88-62EFF2D18B27@nic.cz> In-Reply-To: <CCEE0F4B-9C98-4AED-BC88-62EFF2D18B27@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/RjI89KcSrsN3ehBx0JjWbZQFWpU> Cc: netmod@ietf.org Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 16:38:12 -0000 On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >> On 30 Apr 2015, at 17:08, Xiang Li <xiangli@seguesoft.com> wrote: >> >> >> >> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>> On 30 Apr 2015, at 15:52, Xiang Li <xiangli@seguesoft.com> wrote: >>>> >>>> >>>> >>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>> >>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>> >>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrote: >>>>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I like to close Y45. It seems most people are fine with Y45-04. Andy >>>>>>>>>>> may not be fully convinced or he wants a slight change of Y54-04 that >>>>>>>>>>> turns import-by-revision semantically into import-by-min-revision. >>>>>>>>>>> Xiang Li seems to support a motion to make import-by-revision mean >>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is to settle on >>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean indeed >>>>>>>>>>> import-by-min-revision. (We would have to write this variation down >>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>> Two questions: >>>>>>>>>> >>>>>>>>>> 1. Is import-by-revision supposed to mean import-by-min-revision only >>>>>>>>>> for augments? For groupings and typedefs it should IMO mean an exact >>>>>>>>>> revision. >>>>>>>>> Yes. >>>>>>>>> >>>>>>>> I guess this would be more than just augments. Essentially any >>>>>>>> reference to an 'object' defined in an external module, irrespective >>>>>>>> whether the reference is via augments or a must/when statement or >>>>>>>> anything else. >>>>>>> For must/when a revision makes even less sense because XPath expressions refer to an instance document rather than a module. >>>>>>> >>>>>> But isn't the same is true for an augment that refers to a target that >>>>>> is a list of a container? The target instance must not only be >>>>>> defined, it must also exist for the augment to have an effect. >>>>> No, the target node is by definition a schema node, an augment manipulates the schema - no instance is involved. >>>>> >>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle schema >>>>>> tree dependencies that need to be unambiguous at module compile time >>>>>> and to leave instance tree dependencies to future work (e.g. a package >>>>>> definition system like Andy once proposed). >>>>> For augments the package is in fact given by the hello message or other form of data model specification, because an augment makes sense only if its target node is part of the schema. In fact, not only revision of the imported module is important here: >>>> "not only revision of the imported module is important..."? >>>> >>>> I thought you have been arguing for the contrary? Did you mean "not only revision of the advertised module is important…"? >>> Let’s go back to Andy’s example >>> >>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>> >>> Andy wrote: “The 'aug1' developer clearly intends for the server to support base@2015-01-01.” >>> >>> But let’s say the new enum in module “base” is defined like so: >>> >>> enum fastest { >>> if-feature foo; >>> } >>> >>> Then I could argue that ‘aug1’ developer clearly intends for the server to support not only base@2015-01-01 but also feature foo. However, the latter requirement is not expressed in import-by-revision. >> Current YANG "enum" does not allow "if-feature" as its substatement. > > Th one in YANG 1.1 proposal does. > >> But in general if things depend on some 'features' implemented in an augmented >> base module then they are IMO by definition optional. In other words, 'aug1' developer can't >> demand a server to support feature 'foo', if it is not advertised. I don't see that's relevant here. > It is relevant - for the sake of this example, base@2015-01-01 without feature foo is essentially the same as base@2014-01-01. In both cases the augment from the aug1 module cannot be applied. I think the two scenarios are different. When a client processes anything that involves "if-feature", it knows it must check if the server advertised that feature. If the feature is not available then it knows nodes in the aug1 will not be available. The contract is not broken because in this case "aug1" is *effectively*a conditional augment. --Xiang > I am not saying it is a problem but the two situations are effectively identical. > > My point is that for processing augments and leafrefs, a more complete conformance information has to be supplied anyway, so taking into account revisions in import statements is not really needed. > Lada > >> --Xiang > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Thu Apr 30 09:50:51 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA01B2E16 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 09:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_NrkjPuBhS5 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 09:50:48 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 AC77F1B2E0A for <netmod@ietf.org>; Thu, 30 Apr 2015 09:50:31 -0700 (PDT) Received: by laat2 with SMTP id t2so48928798laa.1 for <netmod@ietf.org>; Thu, 30 Apr 2015 09:50:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tj4Yh8gbBbMViyoU0hdAUoz+mmrBYF5yHBiVuFAZ8sg=; b=j+Y3BOb17OBQ7PA2Zg3ACRyg70/YEVPBHLfh0xOPtXj9nu3vaVhLQzSEMfbHKatN68 /+ofNaxQT7Lc1g2LwlkxJgs1am1QbdEBfdVRv5jgkWb4YzA7VsNM56r8BoXgDkEeU3PL /Yyg7ncBFOMiYB1NCKp3ac/a9klTOg7bftTDUQ0nN5+4qA0miTt7s3GuIei0wcL1//6G 4QM7OXfv8hh7IxkfBnsltuxxy8FKT2yVqoTKFmJ7YcC7WHZzyfWSlLfSTHMY92ZVFsc1 e+TNq8gJijti41uVsdiaU/RMDzD/MOrclvwt0831X2CWtNhQgA9UODFYqpfz+xJFP8Nb 2+Yg== X-Gm-Message-State: ALoCoQlGtDhum+Qv1wX3Mewrq66rSMLPy1XjvNgph92J7KzEQFter1bI9fQL8ly2JiNHvKVliVsM MIME-Version: 1.0 X-Received: by 10.112.77.234 with SMTP id v10mr4602152lbw.119.1430412630104; Thu, 30 Apr 2015 09:50:30 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 30 Apr 2015 09:50:29 -0700 (PDT) In-Reply-To: <55425A71.3060501@seguesoft.com> References: <20150430102958.GB55253@elstar.local> <D3DE21C4-DABB-49D4-A440-722E45E684E5@nic.cz> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <A2E9E03C-C183-4776-8DAB-E80C1E8C68DF@nic.cz> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> <5542457C.3040909@seguesoft.com> <CCEE0F4B-9C98-4AED-BC88-62EFF2D18B27@nic.cz> <55425A71.3060501@seguesoft.com> Date: Thu, 30 Apr 2015 09:50:29 -0700 Message-ID: <CABCOCHQSvBokbVGgh9MmN51VXHmmEO5be8zr0Fn1ncBHSEvDfw@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Xiang Li <xiangli@seguesoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/5prJ5roDdZ-9EX7lDS5t3VVQWu0> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 16:50:50 -0000 On Thu, Apr 30, 2015 at 9:38 AM, Xiang Li <xiangli@seguesoft.com> wrote: > > > On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>> >>> On 30 Apr 2015, at 17:08, Xiang Li <xiangli@seguesoft.com> wrote: >>> >>> >>> >>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>> >>>>> On 30 Apr 2015, at 15:52, Xiang Li <xiangli@seguesoft.com> wrote: >>>>> >>>>> >>>>> >>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>> >>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder >>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>> >>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>>>>> >>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder >>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>> >>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrote: >>>>>>>>>> >>>>>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I like to close Y45. It seems most people are fine with Y45-04= . >>>>>>>>>>>> Andy >>>>>>>>>>>> may not be fully convinced or he wants a slight change of Y54-= 04 >>>>>>>>>>>> that >>>>>>>>>>>> turns import-by-revision semantically into >>>>>>>>>>>> import-by-min-revision. >>>>>>>>>>>> Xiang Li seems to support a motion to make import-by-revision >>>>>>>>>>>> mean >>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is to >>>>>>>>>>>> settle on >>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean indee= d >>>>>>>>>>>> import-by-min-revision. (We would have to write this variation >>>>>>>>>>>> down >>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>> >>>>>>>>>>> Two questions: >>>>>>>>>>> >>>>>>>>>>> 1. Is import-by-revision supposed to mean import-by-min-revisio= n >>>>>>>>>>> only >>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean an >>>>>>>>>>> exact >>>>>>>>>>> revision. >>>>>>>>>> >>>>>>>>>> Yes. >>>>>>>>>> >>>>>>>>> I guess this would be more than just augments. Essentially any >>>>>>>>> reference to an 'object' defined in an external module, >>>>>>>>> irrespective >>>>>>>>> whether the reference is via augments or a must/when statement or >>>>>>>>> anything else. >>>>>>>> >>>>>>>> For must/when a revision makes even less sense because XPath >>>>>>>> expressions refer to an instance document rather than a module. >>>>>>>> >>>>>>> But isn't the same is true for an augment that refers to a target >>>>>>> that >>>>>>> is a list of a container? The target instance must not only be >>>>>>> defined, it must also exist for the augment to have an effect. >>>>>> >>>>>> No, the target node is by definition a schema node, an augment >>>>>> manipulates the schema - no instance is involved. >>>>>> >>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle >>>>>>> schema >>>>>>> tree dependencies that need to be unambiguous at module compile tim= e >>>>>>> and to leave instance tree dependencies to future work (e.g. a >>>>>>> package >>>>>>> definition system like Andy once proposed). >>>>>> >>>>>> For augments the package is in fact given by the hello message or >>>>>> other form of data model specification, because an augment makes sen= se only >>>>>> if its target node is part of the schema. In fact, not only revision= of the >>>>>> imported module is important here: >>>>> >>>>> "not only revision of the imported module is important..."? >>>>> >>>>> I thought you have been arguing for the contrary? Did you mean "not >>>>> only revision of the advertised module is important=E2=80=A6"? >>>> >>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>> >>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>> >>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for the serv= er to >>>> support base@2015-01-01.=E2=80=9D >>>> >>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80=9D is= defined like so: >>>> >>>> enum fastest { >>>> if-feature foo; >>>> } >>>> >>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly inten= ds for the server >>>> to support not only base@2015-01-01 but also feature foo. However, the >>>> latter requirement is not expressed in import-by-revision. >>> >>> Current YANG "enum" does not allow "if-feature" as its substatement. >> >> >> Th one in YANG 1.1 proposal does. >> >>> >>> But in general if things depend on some 'features' implemented in an >>> augmented >>> base module then they are IMO by definition optional. In other words, >>> 'aug1' developer can't >>> demand a server to support feature 'foo', if it is not advertised. I >>> don't see that's relevant here. >> >> It is relevant - for the sake of this example, base@2015-01-01 without >> feature foo is essentially the same as base@2014-01-01. In both cases th= e >> augment from the aug1 module cannot be applied. > > > I think the two scenarios are different. > quite different. The original point is that the designer of "aug1" is using definitions from the new "base" module. There is no way that the server can implement this "aug1" module using the old "base" module. The server does not support the new "fastest" enum. It is a lie to advertise that the leaf using this typedef is supported. Andy > When a client processes anything that involves "if-feature", it knows it > must check if the server > advertised that feature. If the feature is not available then it knows no= des > in the aug1 will not be > available. The contract is not broken because in this case "aug1" is > *effectively*a conditional augment. > > > --Xiang > > > >> I am not saying it is a problem but the two situations are effectively >> identical. >> >> My point is that for processing augments and leafrefs, a more complete >> conformance information has to be supplied anyway, so taking into accoun= t >> revisions in import statements is not really needed. > > > > > >> Lada >> >>> --Xiang >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 30 10:04:52 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882971A8873 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEuVM0OMZL1w for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:04:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1991A8884 for <netmod@ietf.org>; Thu, 30 Apr 2015 10:04:44 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id DAB95140A47; Thu, 30 Apr 2015 19:04:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1430413483; bh=xIsjKOP9no3/YHGVTXXP5/eWIgZUC6Pdi3XYkAnebHA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=RMgu0vTxKNgXeIv7z2e1dfS7MZIhGGJAdChmTGppFR6aULGzf4KOt4cSHM8m+rkR6 0lU8kSRsWki/LYQT3MY6o75TuilRWEOj9vTAjc7PqdIEyK4DFuGu03MhVZ2Lc7qiDE D7fsyLCFGYL+HhsG1T6ipL995fW+gToJ7h1Jlx0Q= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <55425A71.3060501@seguesoft.com> Date: Thu, 30 Apr 2015 19:04:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A79F368-080A-4070-8484-CCA375C4F526@nic.cz> References: <20150430102958.GB55253@elstar.local> <D3DE21C4-DABB-49D4-A440-722E45E684E5@nic.cz> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <A2E9E03C-C183-4776-8DAB-E80C1E8C68DF@nic.cz> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> <5542457C.3040909@seguesoft.com> <CCEE0F4B-9C98-4AED-BC88-62EFF2D18B27@nic.cz> <55425A71.3060501@seguesoft.com> To: Xiang Li <xiangli@seguesoft.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/461VbmW99SxK5Qw0bsUoT4n9JoM> Cc: netmod@ietf.org Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 17:04:51 -0000 > On 30 Apr 2015, at 18:38, Xiang Li <xiangli@seguesoft.com> wrote: >=20 >=20 >=20 > On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>> On 30 Apr 2015, at 17:08, Xiang Li <xiangli@seguesoft.com> wrote: >>>=20 >>>=20 >>>=20 >>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>> On 30 Apr 2015, at 15:52, Xiang Li <xiangli@seguesoft.com> wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>=20 >>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>=20 >>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund = wrote: >>>>>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> I like to close Y45. It seems most people are fine with = Y45-04. Andy >>>>>>>>>>>> may not be fully convinced or he wants a slight change of = Y54-04 that >>>>>>>>>>>> turns import-by-revision semantically into = import-by-min-revision. >>>>>>>>>>>> Xiang Li seems to support a motion to make = import-by-revision mean >>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is = to settle on >>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean = indeed >>>>>>>>>>>> import-by-min-revision. (We would have to write this = variation down >>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>> Two questions: >>>>>>>>>>>=20 >>>>>>>>>>> 1. Is import-by-revision supposed to mean = import-by-min-revision only >>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean = an exact >>>>>>>>>>> revision. >>>>>>>>>> Yes. >>>>>>>>>>=20 >>>>>>>>> I guess this would be more than just augments. Essentially any >>>>>>>>> reference to an 'object' defined in an external module, = irrespective >>>>>>>>> whether the reference is via augments or a must/when statement = or >>>>>>>>> anything else. >>>>>>>> For must/when a revision makes even less sense because XPath = expressions refer to an instance document rather than a module. >>>>>>>>=20 >>>>>>> But isn't the same is true for an augment that refers to a = target that >>>>>>> is a list of a container? The target instance must not only be >>>>>>> defined, it must also exist for the augment to have an effect. >>>>>> No, the target node is by definition a schema node, an augment = manipulates the schema - no instance is involved. >>>>>>=20 >>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle = schema >>>>>>> tree dependencies that need to be unambiguous at module compile = time >>>>>>> and to leave instance tree dependencies to future work (e.g. a = package >>>>>>> definition system like Andy once proposed). >>>>>> For augments the package is in fact given by the hello message or = other form of data model specification, because an augment makes sense = only if its target node is part of the schema. In fact, not only = revision of the imported module is important here: >>>>> "not only revision of the imported module is important..."? >>>>>=20 >>>>> I thought you have been arguing for the contrary? Did you mean = "not only revision of the advertised module is important=E2=80=A6"? >>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>>=20 >>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>=20 >>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for the = server to support base@2015-01-01.=E2=80=9D >>>>=20 >>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80=9D = is defined like so: >>>>=20 >>>> enum fastest { >>>> if-feature foo; >>>> } >>>>=20 >>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly = intends for the server to support not only base@2015-01-01 but also = feature foo. However, the latter requirement is not expressed in = import-by-revision. >>> Current YANG "enum" does not allow "if-feature" as its = substatement. >>=20 >> Th one in YANG 1.1 proposal does. >> =20 >>> But in general if things depend on some 'features' implemented in an = augmented >>> base module then they are IMO by definition optional. In other = words, 'aug1' developer can't >>> demand a server to support feature 'foo', if it is not advertised. I = don't see that's relevant here. >> It is relevant - for the sake of this example, base@2015-01-01 = without feature foo is essentially the same as base@2014-01-01. In both = cases the augment from the aug1 module cannot be applied. >=20 > I think the two scenarios are different. >=20 > When a client processes anything that involves "if-feature", it knows = it must check if the server > advertised that feature. If the feature is not available then it knows = nodes in the aug1 will not be Still the same: When a client processes anything that involves data = defined in a new revision of a module, it knows it must check if the = server advertises that new revision (and the server must advertise it in = any case). Lada > available. The contract is not broken because in this case "aug1" is = *effectively*a conditional augment. >=20 >=20 > --Xiang >=20 >=20 >=20 >> I am not saying it is a problem but the two situations are = effectively identical. >>=20 >> My point is that for processing augments and leafrefs, a more = complete conformance information has to be supplied anyway, so taking = into account revisions in import statements is not really needed. >=20 >=20 >=20 >=20 >> Lada >>=20 >>> --Xiang >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 30 10:13:22 2015 Return-Path: <lhotka@nic.cz> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4A11B2D9D for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhPCtJ5pOU9R for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:13:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9712A1B2E54 for <netmod@ietf.org>; Thu, 30 Apr 2015 10:13:08 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 8DF7D140A47; Thu, 30 Apr 2015 19:13:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1430413986; bh=eNWdww10e9T5ZDYDqTUdlimtu22I9f/LBQeYfvLw1A8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DgVdysOHCar0TzTTSfb5lEFJi+9krC6GVprd1N8AqyfSsLyTX8P1e+sBpW7RrRJFr t9BfbccpZLHUBvFAgoAr7zaHoiGwkoMsAu5AMjbG11Bdn6Wemiw+umk6wwL2Ug4MYD eAfZlRWVFE3oNxjYiZ3OK4zDYQhssoRrhOP3XBEU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka <lhotka@nic.cz> In-Reply-To: <CABCOCHQSvBokbVGgh9MmN51VXHmmEO5be8zr0Fn1ncBHSEvDfw@mail.gmail.com> Date: Thu, 30 Apr 2015 19:13:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <46CE075C-72CE-4E89-867F-3C751990967D@nic.cz> References: <20150430102958.GB55253@elstar.local> <D3DE21C4-DABB-49D4-A440-722E45E684E5@nic.cz> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <A2E9E03C-C183-4776-8DAB-E80C1E8C68DF@nic.cz> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> <5542457C.3040909@seguesoft.com> <CCEE0F4B-9C98-4AED-BC88-62EFF2D18B27@nic.cz> <55425A71.3060501@seguesoft.com> <CABCOCHQSvBokbVGgh9MmN51VXHmmEO5be8zr0Fn1ncBHSEvDfw@mail.gmail.com> To: Andy Bierman <andy@yumaworks.com> X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/j0iMrVqyD8wBr7gsMkHfjfieWpw> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 17:13:12 -0000 > On 30 Apr 2015, at 18:50, Andy Bierman <andy@yumaworks.com> wrote: >=20 > On Thu, Apr 30, 2015 at 9:38 AM, Xiang Li <xiangli@seguesoft.com> = wrote: >>=20 >>=20 >> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>=20 >>>> On 30 Apr 2015, at 17:08, Xiang Li <xiangli@seguesoft.com> wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> On 30 Apr 2015, at 15:52, Xiang Li <xiangli@seguesoft.com> wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder >>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>=20 >>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka = wrote: >>>>>>>>>>=20 >>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder >>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>=20 >>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I like to close Y45. It seems most people are fine with = Y45-04. >>>>>>>>>>>>> Andy >>>>>>>>>>>>> may not be fully convinced or he wants a slight change of = Y54-04 >>>>>>>>>>>>> that >>>>>>>>>>>>> turns import-by-revision semantically into >>>>>>>>>>>>> import-by-min-revision. >>>>>>>>>>>>> Xiang Li seems to support a motion to make = import-by-revision >>>>>>>>>>>>> mean >>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is = to >>>>>>>>>>>>> settle on >>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean = indeed >>>>>>>>>>>>> import-by-min-revision. (We would have to write this = variation >>>>>>>>>>>>> down >>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>=20 >>>>>>>>>>>> Two questions: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1. Is import-by-revision supposed to mean = import-by-min-revision >>>>>>>>>>>> only >>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean = an >>>>>>>>>>>> exact >>>>>>>>>>>> revision. >>>>>>>>>>>=20 >>>>>>>>>>> Yes. >>>>>>>>>>>=20 >>>>>>>>>> I guess this would be more than just augments. Essentially = any >>>>>>>>>> reference to an 'object' defined in an external module, >>>>>>>>>> irrespective >>>>>>>>>> whether the reference is via augments or a must/when = statement or >>>>>>>>>> anything else. >>>>>>>>>=20 >>>>>>>>> For must/when a revision makes even less sense because XPath >>>>>>>>> expressions refer to an instance document rather than a = module. >>>>>>>>>=20 >>>>>>>> But isn't the same is true for an augment that refers to a = target >>>>>>>> that >>>>>>>> is a list of a container? The target instance must not only be >>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>>=20 >>>>>>> No, the target node is by definition a schema node, an augment >>>>>>> manipulates the schema - no instance is involved. >>>>>>>=20 >>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle >>>>>>>> schema >>>>>>>> tree dependencies that need to be unambiguous at module compile = time >>>>>>>> and to leave instance tree dependencies to future work (e.g. a >>>>>>>> package >>>>>>>> definition system like Andy once proposed). >>>>>>>=20 >>>>>>> For augments the package is in fact given by the hello message = or >>>>>>> other form of data model specification, because an augment makes = sense only >>>>>>> if its target node is part of the schema. In fact, not only = revision of the >>>>>>> imported module is important here: >>>>>>=20 >>>>>> "not only revision of the imported module is important..."? >>>>>>=20 >>>>>> I thought you have been arguing for the contrary? Did you mean = "not >>>>>> only revision of the advertised module is important=E2=80=A6"? >>>>>=20 >>>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>=20 >>>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for the = server to >>>>> support base@2015-01-01.=E2=80=9D >>>>>=20 >>>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80=9D = is defined like so: >>>>>=20 >>>>> enum fastest { >>>>> if-feature foo; >>>>> } >>>>>=20 >>>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly = intends for the server >>>>> to support not only base@2015-01-01 but also feature foo. However, = the >>>>> latter requirement is not expressed in import-by-revision. >>>>=20 >>>> Current YANG "enum" does not allow "if-feature" as its = substatement. >>>=20 >>>=20 >>> Th one in YANG 1.1 proposal does. >>>=20 >>>>=20 >>>> But in general if things depend on some 'features' implemented in = an >>>> augmented >>>> base module then they are IMO by definition optional. In other = words, >>>> 'aug1' developer can't >>>> demand a server to support feature 'foo', if it is not advertised. = I >>>> don't see that's relevant here. >>>=20 >>> It is relevant - for the sake of this example, base@2015-01-01 = without >>> feature foo is essentially the same as base@2014-01-01. In both = cases the >>> augment from the aug1 module cannot be applied. >>=20 >>=20 >> I think the two scenarios are different. >>=20 >=20 > quite different. >=20 > The original point is that the designer of "aug1" is using > definitions from the new "base" module. There is no way > that the server can implement this "aug1" module using the > old "base" module. >=20 > The server does not support the new "fastest" enum. It is a lie to > advertise that the leaf using this typedef is supported. The server advertises the old revision of =E2=80=9Cbase, thus making = clear that is does *not* support the new =E2=80=9Cfastest=E2=80=9D enum. = Therefore, it doesn=E2=80=99t lie. Note that the fact that the augment = in =E2=80=98aug1=E2=80=99 doesn=E2=80=99t happen isn=E2=80=99t an error = from the YANG point of view - it just may or may not be what the server = implementer intended. Lada =20 >=20 > Andy >=20 >=20 >=20 >> When a client processes anything that involves "if-feature", it knows = it >> must check if the server >> advertised that feature. If the feature is not available then it = knows nodes >> in the aug1 will not be >> available. The contract is not broken because in this case "aug1" is >> *effectively*a conditional augment. >>=20 >>=20 >> --Xiang >>=20 >>=20 >>=20 >>> I am not saying it is a problem but the two situations are = effectively >>> identical. >>>=20 >>> My point is that for processing augments and leafrefs, a more = complete >>> conformance information has to be supplied anyway, so taking into = account >>> revisions in import statements is not really needed. >>=20 >>=20 >>=20 >>=20 >>=20 >>> Lada >>>=20 >>>> --Xiang >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Apr 30 10:22:54 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C631A88B9 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzoMYV2kKrUM for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:22:51 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30D41A887C for <netmod@ietf.org>; Thu, 30 Apr 2015 10:22:50 -0700 (PDT) Received: by laat2 with SMTP id t2so49581878laa.1 for <netmod@ietf.org>; Thu, 30 Apr 2015 10:22:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xeQuaavvJ+tCjl4tng7oT5jp63oaCB9eq5yhg4LsBCQ=; b=S7hgAAKjuZ+Thx7MaF3vgZ1q4gxItbUr2UntszPkp+eJzTjQz36Gb1/S12Nnp5a9jS hozv6gAkM/v3US0lp2qpiCTr9YBb/a2/B6O3QPmCQoq71aGppAJ1ijK0tOcSqIm9NgtL vYpCswD7JZqoJrCTEGPnmi0AyHxHtHInQq0ZFBxP7hk3dQFS1JA7wHi/QMUIrH9IwAJ1 7yS7+9n+YjpE8e7k6Qv+udZkI0tlZtO0SZKLAbf669kHBdyw77uhDwopKmIUQhmnTAss SWUzuYKUnBBfjKzaLO0RBd4JEF1YUuG+KzAWRtkBDdexao5EvwZG5m2OamsS7pSRs59g YLgg== X-Gm-Message-State: ALoCoQkfuXfmO5Gfk8xwd0bWR6DVTeAK7jQoF99CktGNT6ziczP7TplFYlwWAYQ0/15Nl6+nHyol MIME-Version: 1.0 X-Received: by 10.152.87.164 with SMTP id az4mr4842922lab.123.1430414569214; Thu, 30 Apr 2015 10:22:49 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 30 Apr 2015 10:22:49 -0700 (PDT) In-Reply-To: <46CE075C-72CE-4E89-867F-3C751990967D@nic.cz> References: <20150430102958.GB55253@elstar.local> <D3DE21C4-DABB-49D4-A440-722E45E684E5@nic.cz> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <A2E9E03C-C183-4776-8DAB-E80C1E8C68DF@nic.cz> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> <5542457C.3040909@seguesoft.com> <CCEE0F4B-9C98-4AED-BC88-62EFF2D18B27@nic.cz> <55425A71.3060501@seguesoft.com> <CABCOCHQSvBokbVGgh9MmN51VXHmmEO5be8zr0Fn1ncBHSEvDfw@mail.gmail.com> <46CE075C-72CE-4E89-867F-3C751990967D@nic.cz> Date: Thu, 30 Apr 2015 10:22:49 -0700 Message-ID: <CABCOCHTJaEeVf82-NUM084zT0tKhnbXuXSNWPzeSt3ms3NZ33A@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Ladislav Lhotka <lhotka@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/O23EUVHf5bl4hvclpwqfRiObukM> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 17:22:53 -0000 On Thu, Apr 30, 2015 at 10:13 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > >> On 30 Apr 2015, at 18:50, Andy Bierman <andy@yumaworks.com> wrote: >> >> On Thu, Apr 30, 2015 at 9:38 AM, Xiang Li <xiangli@seguesoft.com> wrote: >>> >>> >>> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>>> >>>>> On 30 Apr 2015, at 17:08, Xiang Li <xiangli@seguesoft.com> wrote: >>>>> >>>>> >>>>> >>>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>>> >>>>>>> On 30 Apr 2015, at 15:52, Xiang Li <xiangli@seguesoft.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>>> >>>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder >>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>> >>>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>>>>>>> >>>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder >>>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrot= e: >>>>>>>>>>>> >>>>>>>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I like to close Y45. It seems most people are fine with Y45-= 04. >>>>>>>>>>>>>> Andy >>>>>>>>>>>>>> may not be fully convinced or he wants a slight change of Y5= 4-04 >>>>>>>>>>>>>> that >>>>>>>>>>>>>> turns import-by-revision semantically into >>>>>>>>>>>>>> import-by-min-revision. >>>>>>>>>>>>>> Xiang Li seems to support a motion to make import-by-revisio= n >>>>>>>>>>>>>> mean >>>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is to >>>>>>>>>>>>>> settle on >>>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean ind= eed >>>>>>>>>>>>>> import-by-min-revision. (We would have to write this variati= on >>>>>>>>>>>>>> down >>>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>>> >>>>>>>>>>>>> Two questions: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Is import-by-revision supposed to mean import-by-min-revis= ion >>>>>>>>>>>>> only >>>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean a= n >>>>>>>>>>>>> exact >>>>>>>>>>>>> revision. >>>>>>>>>>>> >>>>>>>>>>>> Yes. >>>>>>>>>>>> >>>>>>>>>>> I guess this would be more than just augments. Essentially any >>>>>>>>>>> reference to an 'object' defined in an external module, >>>>>>>>>>> irrespective >>>>>>>>>>> whether the reference is via augments or a must/when statement = or >>>>>>>>>>> anything else. >>>>>>>>>> >>>>>>>>>> For must/when a revision makes even less sense because XPath >>>>>>>>>> expressions refer to an instance document rather than a module. >>>>>>>>>> >>>>>>>>> But isn't the same is true for an augment that refers to a target >>>>>>>>> that >>>>>>>>> is a list of a container? The target instance must not only be >>>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>>> >>>>>>>> No, the target node is by definition a schema node, an augment >>>>>>>> manipulates the schema - no instance is involved. >>>>>>>> >>>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle >>>>>>>>> schema >>>>>>>>> tree dependencies that need to be unambiguous at module compile t= ime >>>>>>>>> and to leave instance tree dependencies to future work (e.g. a >>>>>>>>> package >>>>>>>>> definition system like Andy once proposed). >>>>>>>> >>>>>>>> For augments the package is in fact given by the hello message or >>>>>>>> other form of data model specification, because an augment makes s= ense only >>>>>>>> if its target node is part of the schema. In fact, not only revisi= on of the >>>>>>>> imported module is important here: >>>>>>> >>>>>>> "not only revision of the imported module is important..."? >>>>>>> >>>>>>> I thought you have been arguing for the contrary? Did you mean "not >>>>>>> only revision of the advertised module is important=E2=80=A6"? >>>>>> >>>>>> Let=E2=80=99s go back to Andy=E2=80=99s example >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>>> >>>>>> Andy wrote: =E2=80=9CThe 'aug1' developer clearly intends for the se= rver to >>>>>> support base@2015-01-01.=E2=80=9D >>>>>> >>>>>> But let=E2=80=99s say the new enum in module =E2=80=9Cbase=E2=80=9D = is defined like so: >>>>>> >>>>>> enum fastest { >>>>>> if-feature foo; >>>>>> } >>>>>> >>>>>> Then I could argue that =E2=80=98aug1=E2=80=99 developer clearly int= ends for the server >>>>>> to support not only base@2015-01-01 but also feature foo. However, t= he >>>>>> latter requirement is not expressed in import-by-revision. >>>>> >>>>> Current YANG "enum" does not allow "if-feature" as its substatement. >>>> >>>> >>>> Th one in YANG 1.1 proposal does. >>>> >>>>> >>>>> But in general if things depend on some 'features' implemented in an >>>>> augmented >>>>> base module then they are IMO by definition optional. In other words, >>>>> 'aug1' developer can't >>>>> demand a server to support feature 'foo', if it is not advertised. I >>>>> don't see that's relevant here. >>>> >>>> It is relevant - for the sake of this example, base@2015-01-01 without >>>> feature foo is essentially the same as base@2014-01-01. In both cases = the >>>> augment from the aug1 module cannot be applied. >>> >>> >>> I think the two scenarios are different. >>> >> >> quite different. >> >> The original point is that the designer of "aug1" is using >> definitions from the new "base" module. There is no way >> that the server can implement this "aug1" module using the >> old "base" module. >> >> The server does not support the new "fastest" enum. It is a lie to >> advertise that the leaf using this typedef is supported. > > The server advertises the old revision of =E2=80=9Cbase, thus making clea= r that is does *not* support the new =E2=80=9Cfastest=E2=80=9D enum. Theref= ore, it doesn=E2=80=99t lie. Note that the fact that the augment in =E2=80= =98aug1=E2=80=99 doesn=E2=80=99t happen isn=E2=80=99t an error from the YAN= G point of view - it just may or may not be what the server implementer int= ended. > If it advertises the old version of "base" then it cannot advertise "aug1". The client sees that advertisement and believes that the new revision of the typedef is supported. It has no reason to suspect that setting the leaf to 'fastest' is going to fail. This is not typedef drift. The requirements for "base" are quite clear for both revisions. The server can advertise either one. The server does not meet the requirements for "aug1" if it only supports the old base module. > Lada > Andy >> >> Andy >> >> >> >>> When a client processes anything that involves "if-feature", it knows i= t >>> must check if the server >>> advertised that feature. If the feature is not available then it knows = nodes >>> in the aug1 will not be >>> available. The contract is not broken because in this case "aug1" is >>> *effectively*a conditional augment. >>> >>> >>> --Xiang >>> >>> >>> >>>> I am not saying it is a problem but the two situations are effectively >>>> identical. >>>> >>>> My point is that for processing augments and leafrefs, a more complete >>>> conformance information has to be supplied anyway, so taking into acco= unt >>>> revisions in import statements is not really needed. >>> >>> >>> >>> >>> >>>> Lada >>>> >>>>> --Xiang >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Thu Apr 30 10:30:39 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2480F1A8729 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96uC1w0hlLmn for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:30:36 -0700 (PDT) Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45791A88BC for <netmod@ietf.org>; Thu, 30 Apr 2015 10:30:35 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa12-06.prod.phx3.secureserver.net with id NHWa1q0094vySjM01HWaaJ; Thu, 30 Apr 2015 10:30:35 -0700 Message-ID: <554266BB.4060603@seguesoft.com> Date: Thu, 30 Apr 2015 12:30:35 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ladislav Lhotka <lhotka@nic.cz> References: <20150430102958.GB55253@elstar.local> <D3DE21C4-DABB-49D4-A440-722E45E684E5@nic.cz> <20150430.131522.695783704966842496.mbj@tail-f.com> <20150430120027.GC55470@elstar.local> <A2E9E03C-C183-4776-8DAB-E80C1E8C68DF@nic.cz> <20150430125741.GA55656@elstar.local> <6075448F-83C8-4646-9830-A3AD498A83BC@nic.cz> <554233A9.1070109@seguesoft.com> <E0EA4CE9-4EB9-4A5D-AEFB-55A8380CAF87@nic.cz> <5542457C.3040909@seguesoft.com> <CCEE0F4B-9C98-4AED-BC88-62EFF2D18B27@nic.cz> <55425A71.3060501@seguesoft.com> <7A79F368-080A-4070-8484-CCA375C4F526@nic.cz> In-Reply-To: <7A79F368-080A-4070-8484-CCA375C4F526@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/V1XQh4boqvo7PMfL5H3XY5okSvc> Cc: netmod@ietf.org Subject: Re: [netmod] closing Y45 - would an inofficial online meeting help? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 17:30:38 -0000 On 4/30/2015 12:04 PM, Ladislav Lhotka wrote: >> On 30 Apr 2015, at 18:38, Xiang Li <xiangli@seguesoft.com> wrote: >> >> >> >> On 4/30/2015 10:54 AM, Ladislav Lhotka wrote: >>>> On 30 Apr 2015, at 17:08, Xiang Li <xiangli@seguesoft.com> wrote: >>>> >>>> >>>> >>>> On 4/30/2015 9:09 AM, Ladislav Lhotka wrote: >>>>>> On 30 Apr 2015, at 15:52, Xiang Li <xiangli@seguesoft.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 4/30/2015 8:16 AM, Ladislav Lhotka wrote: >>>>>>>> On 30 Apr 2015, at 14:57, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>> >>>>>>>> On Thu, Apr 30, 2015 at 02:09:55PM +0200, Ladislav Lhotka wrote: >>>>>>>>>> On 30 Apr 2015, at 14:00, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>> >>>>>>>>>> On Thu, Apr 30, 2015 at 01:15:22PM +0200, Martin Bjorklund wrote: >>>>>>>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>>>>>>>>> On 30 Apr 2015, at 12:29, Juergen Schoenwaelder >>>>>>>>>>>>> <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I like to close Y45. It seems most people are fine with Y45-04. Andy >>>>>>>>>>>>> may not be fully convinced or he wants a slight change of Y54-04 that >>>>>>>>>>>>> turns import-by-revision semantically into import-by-min-revision. >>>>>>>>>>>>> Xiang Li seems to support a motion to make import-by-revision mean >>>>>>>>>>>>> import-by-min-revision. So perhaps a possible solution is to settle on >>>>>>>>>>>>> Y45-04 with a slight change that import-by-revision mean indeed >>>>>>>>>>>>> import-by-min-revision. (We would have to write this variation down >>>>>>>>>>>>> and give it a new number - any volunteers?) >>>>>>>>>>>> Two questions: >>>>>>>>>>>> >>>>>>>>>>>> 1. Is import-by-revision supposed to mean import-by-min-revision only >>>>>>>>>>>> for augments? For groupings and typedefs it should IMO mean an exact >>>>>>>>>>>> revision. >>>>>>>>>>> Yes. >>>>>>>>>>> >>>>>>>>>> I guess this would be more than just augments. Essentially any >>>>>>>>>> reference to an 'object' defined in an external module, irrespective >>>>>>>>>> whether the reference is via augments or a must/when statement or >>>>>>>>>> anything else. >>>>>>>>> For must/when a revision makes even less sense because XPath expressions refer to an instance document rather than a module. >>>>>>>>> >>>>>>>> But isn't the same is true for an augment that refers to a target that >>>>>>>> is a list of a container? The target instance must not only be >>>>>>>> defined, it must also exist for the augment to have an effect. >>>>>>> No, the target node is by definition a schema node, an augment manipulates the schema - no instance is involved. >>>>>>> >>>>>>>> Anyway, the main idea behind Y45-04 is to use imports to handle schema >>>>>>>> tree dependencies that need to be unambiguous at module compile time >>>>>>>> and to leave instance tree dependencies to future work (e.g. a package >>>>>>>> definition system like Andy once proposed). >>>>>>> For augments the package is in fact given by the hello message or other form of data model specification, because an augment makes sense only if its target node is part of the schema. In fact, not only revision of the imported module is important here: >>>>>> "not only revision of the imported module is important..."? >>>>>> >>>>>> I thought you have been arguing for the contrary? Did you mean "not only revision of the advertised module is important…"? >>>>> Let’s go back to Andy’s example >>>>> >>>>> http://www.ietf.org/mail-archive/web/netmod/current/msg12486.html >>>>> >>>>> Andy wrote: “The 'aug1' developer clearly intends for the server to support base@2015-01-01.” >>>>> >>>>> But let’s say the new enum in module “base” is defined like so: >>>>> >>>>> enum fastest { >>>>> if-feature foo; >>>>> } >>>>> >>>>> Then I could argue that ‘aug1’ developer clearly intends for the server to support not only base@2015-01-01 but also feature foo. However, the latter requirement is not expressed in import-by-revision. >>>> Current YANG "enum" does not allow "if-feature" as its substatement. >>> Th one in YANG 1.1 proposal does. >>> >>>> But in general if things depend on some 'features' implemented in an augmented >>>> base module then they are IMO by definition optional. In other words, 'aug1' developer can't >>>> demand a server to support feature 'foo', if it is not advertised. I don't see that's relevant here. >>> It is relevant - for the sake of this example, base@2015-01-01 without feature foo is essentially the same as base@2014-01-01. In both cases the augment from the aug1 module cannot be applied. >> I think the two scenarios are different. >> >> When a client processes anything that involves "if-feature", it knows it must check if the server >> advertised that feature. If the feature is not available then it knows nodes in the aug1 will not be > Still the same: When a client processes anything that involves data defined in a new revision of a module, it knows it must check if the server advertises that new revision (and the server must advertise it in any case). Scenario 1: * we have enum fastest { if-feature foo; } * a server advertises "aug1" and base@2015-01-01" (without feature foo) My point is that in this case the server's advertisement is "consistent". A client can not assume it can set the leaf to 'fastest' because that involves a checking to see feature "foo" is advertised. Scenario 2: * we have enum fastest (i.e. NOT based on feature foo) * a server advertises "aug1" and base@2014-01-01" In this case the advertisement is "inconsistent" because aug1 requires at least base@2015-01-01 and should be considered as an "error". When a client sees the server supports "aug1", it should be able to assume "base@2015-01-01" must also be supported without having to check the base version in server's advertisement. --Xiang From nobody Thu Apr 30 10:32:23 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FACD1A88BC for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsIUDgJp_52y for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:32:12 -0700 (PDT) Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D781A8729 for <netmod@ietf.org>; Thu, 30 Apr 2015 10:32:12 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa12-09.prod.phx3.secureserver.net with id NHYA1q00J4vySjM01HYBUm; Thu, 30 Apr 2015 10:32:11 -0700 Message-ID: <5542671C.8090905@seguesoft.com> Date: Thu, 30 Apr 2015 12:32:12 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ladislav Lhotka <lhotka@nic.cz> References: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> <20150426.205033.1440726706036395955.mbj@tail-f.com> <554239D5.9030102@seguesoft.com> <EA7216C8-C7D6-440B-A5EE-5693B339D321@nic.cz> In-Reply-To: <EA7216C8-C7D6-440B-A5EE-5693B339D321@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/BXup6otv20Eeno7jeZx35FcbiOE> Cc: netmod@ietf.org Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 17:32:18 -0000 On 4/30/2015 11:15 AM, Ladislav Lhotka wrote: >> On 30 Apr 2015, at 16:19, Xiang Li <xiangli@seguesoft.com> wrote: >> >> >> >> On 4/26/2015 1:50 PM, Martin Bjorklund wrote: >>> Andy Bierman <andy@yumaworks.com> wrote: >>>> On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> wrote: >>>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>>> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> wrote: >>>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >>>>>>>>> Let me try to explain my concern again... >>>>>>>>> >>>>>>>>> The authors of "bar" expect that module X rev 2 will be supported. >>>>>>>>> That is why they used import-by-revision. Mixing typedefs and >>>>>>>>> groupings from R2 and protocol accessible objects from R1 is not what >>>>>>>>> they expect. They cannot possibly write their module "bar" >>>>>>>>> for every possible combination of down-rev X modules the vendor may choose. >>>>>>>>> >>>>>>>>> It is not the fault of the designers if bar does not work with X@R1. >>>>>>>>> They expect X@R2 to be used. >>>>>>>>> >>>>>>>> I can easily construct cases where this may not be true nor >>>>>>>> problematic. If we make the interpretation min-revision, I am sure we >>>>>>>> will regret it at some point in time >>>>>>> I agree. The min-revision rule would be an unnecessary CLR. >>>>>>> >>>>>>> I asked before for an example of where the proposed solution is >>>>>>> problematic, and where the min-revision would solve that. >>>>>> Here is a simple example that I find problematic. >>>>>> This is what I mean by coding to the model. >>>>>> The client developer adds code to augment a base node >>>>>> if the port-knob-type is 'fastest' >>>>>> >>>>>> >>>>>> module base { >>>>>> ... >>>>>> revision 2014-01-01; >>>>>> typedef port-knob-type { >>>>>> type enumeration { >>>>>> enum fast; >>>>>> enum faster; >>>>>> } >>>>>> } >>>>>> list port-knob { >>>>>> key name; >>>>>> leaf name { type string; } >>>>>> leaf knob-type { type port-knob-type; } >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> module base { >>>>>> ... >>>>>> revision 2015-01-01; >>>>>> typedef port-knob-type { >>>>>> type enumeration { >>>>>> enum fast; >>>>>> enum faster; >>>>>> enum fastest' // added new enum >>>>>> } >>>>>> } >>>>>> list port-knob { >>>>>> key name; >>>>>> leaf name { type string; } >>>>>> leaf knob-type { >>>>>> type port-knob-type; >>>>>> default fast; >>>>>> >>>>>> } >>>>>> } >>>>>> >>>>>> module aug1 { >>>>>> ... >>>>>> import base { >>>>>> prefix b; >>>>>> revision-date "2015-01-01"; >>>>>> } >>>>>> >>>>>> augment b:/port-knob { >>>>>> when "b:knob-type = 'faster'"; >>>>>> leaf alt-knob-type { >>>>>> type b:port-knob-type; >>>>>> } >>>>>> } >>>>>> >>>>>> augment b:/port-knob { >>>>>> when "b:knob-type = 'fastest'"; >>>>>> leaf boost-factor { type uint32; } >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> The 'aug1' developer clearly intends for the server to >>>>>> support base@2015-01-01. >>>>>> >>>>>> But the vendor decides to advertise base@2014-01-01. >>>>> Well, boost-factor is only relevant if b:knob-type is 'fastest'. So >>>>> if the vendor advertises base@2014-01-01, b:knob-type can never be >>>>> 'fastest'. I don't see any problem with this. >>>>> >>>>>> The 'port-knob' list is augmented with the new version >>>>>> of the port-knob-type (if 'faster') even though the server implements >>>>>> the old version. >>>>>> >>>>>> The ''boost-factor'' leaf will never augment the port-knob list >>>>>> because server does not support the 'fastest' enum. >>>>>> >>>>>> This is more than just confusing, especially if the server >>>>>> advertises that it conforms to the "aug1" module. >>>>> It advertises that it *implements* aug1. >>>>> >>>> This is the problem. >>>> If it does advertise "aug1", then it MUST advertise "not-supported" deviations >>>> for both leafs, because they both rely on the new revision of the typedef, >>>> and the server does not implement the new typedef. >>> No, the definition of the augment for boost-factor does not strictly >>> rely on the new revision of the typedef. It's just that the when >>> expression will never evaluate to true if the newer version isn't >>> implemented. >> But if a server advertises "aug1" the it is claiming that "aug1" is fully supported. Since ‘aug1' > This is not sufficient, in order to decide whether “aug1” is fully supported, “base” must be advertised, too, and the supported features as well. Of course. "base" must be advertised. Though I don't think any "features" must be advertised. By definition a feature is optional. The question is whether a server should be allowed to advertise base@2014-01-01 and "aug1" at the same time. If we let a server implementation decide what "base" version that "aug1" is augmenting then a module designer has no say about which "base" that his/her "aug1" must be based on. If so the module designer may have to design "aug1" in a way that is base-version-agnostic. I am fine with that if that is intention of the working group. -Xiang > Lada > >> augments "base 2015-01-01", I would think that I must be able to set the leaf "b:knob-type" >> to the value "fastest" and then expect to be able to play with the augmented "boost-factor" >> leaf. If the server advertises only "base 2014-01-01", this would not be possible. Is this an >> invalid scenario? >> >> Anyway, as I said earlier I agree with Y45-04 if no valid use-case exists for 'min-revision-rule" >> since that seems to be cleanest way to address the question we are trying to address. >> It is just different from what I thought originally that augmenting a module via "import-by-revision" >> implies the imported module version is the base of the augmenting and hence it must be >> supported first. >> >> --Xiang >> >> >> >>>>> I think Juergen has tried to say several times that what we're trying >>>>> to do is really to let the server advertise what it implements, and >>>>> then add possibly more useful conformance functions later (maybe >>>>> something like your packages). >>>>> >>>> This proposal does not let the client developer know what the server is >>>> supposed to implement. The conformance requirements are not very >>>> precise. >>> Agreed. This is why we want to address the conformance problem >>> separately. Right now we try focus on what the different constructs >>> really imply in terms of implementing other modules. >>> >>> >>> /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 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Thu Apr 30 10:45:33 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882F1A1A11 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI190dsxtplf for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 10:45:30 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 5AA511A8A29 for <netmod@ietf.org>; Thu, 30 Apr 2015 10:45:29 -0700 (PDT) Received: by layy10 with SMTP id y10so50059874lay.0 for <netmod@ietf.org>; Thu, 30 Apr 2015 10:45:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BGZNByOLdyJlb9XEoOvjdXmrBEClZw79Hq65GoZPyoY=; b=Y4g7DUcH+80HwDza2KFrZGqk5S/ccjmV1VekUrRJkKR3rJjSK7hgYQ/doIN5HZZEGt VERktP9SGE0FKgmm6jSXcVl6EG2vbhF5ip+hiOUG5q7U7GxvNixLAEWfB1kh49Jv5mu5 czTzeoX6Q/fgHHUompnMkVWoeP0A6o/kO/ig2OyXNMZ7EvDMVC4b2+oTK+sU0dv4oyyv m6LwaKCMKPohIR7Mr5tiofpaQINi7lb01z2j67iox3p/mot3SUGaWg7WQITfgvBaO3XA FHnmvsGyGHiaEtwJ6JCCW95Y8kxiWSVrsUKUx2FdFqPY/eTYLqjMRlg2SLQ9UA6Htxm+ +o4w== X-Gm-Message-State: ALoCoQl3u9XvEQalrnOHSDKdaiP+BracTmcITDVduRkaJIdQnfK8cb3CAcQo0+mscsLDD0j043Rq MIME-Version: 1.0 X-Received: by 10.152.42.141 with SMTP id o13mr4926855lal.33.1430415927867; Thu, 30 Apr 2015 10:45:27 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 30 Apr 2015 10:45:27 -0700 (PDT) In-Reply-To: <5542671C.8090905@seguesoft.com> References: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> <20150426.205033.1440726706036395955.mbj@tail-f.com> <554239D5.9030102@seguesoft.com> <EA7216C8-C7D6-440B-A5EE-5693B339D321@nic.cz> <5542671C.8090905@seguesoft.com> Date: Thu, 30 Apr 2015 10:45:27 -0700 Message-ID: <CABCOCHQ=h5=OeqVD-xzvvKc0HYMrCnPOkaS77+hFF3gHmOXr=A@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Xiang Li <xiangli@seguesoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/28be8-3CF1UnZAd8fuon4tVgjcc> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 17:45:32 -0000 On Thu, Apr 30, 2015 at 10:32 AM, Xiang Li <xiangli@seguesoft.com> wrote: > > > On 4/30/2015 11:15 AM, Ladislav Lhotka wrote: >>> >>> On 30 Apr 2015, at 16:19, Xiang Li <xiangli@seguesoft.com> wrote: >>> >>> >>> >>> On 4/26/2015 1:50 PM, Martin Bjorklund wrote: >>>> >>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>> >>>>> On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> >>>>> wrote: >>>>>> >>>>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>>>> >>>>>>> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= : >>>>>>>>> >>>>>>>>> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >>>>>>>>>> >>>>>>>>>> Let me try to explain my concern again... >>>>>>>>>> >>>>>>>>>> The authors of "bar" expect that module X rev 2 will be supporte= d. >>>>>>>>>> That is why they used import-by-revision. Mixing typedefs and >>>>>>>>>> groupings from R2 and protocol accessible objects from R1 is not >>>>>>>>>> what >>>>>>>>>> they expect. They cannot possibly write their module "bar" >>>>>>>>>> for every possible combination of down-rev X modules the vendor >>>>>>>>>> may choose. >>>>>>>>>> >>>>>>>>>> It is not the fault of the designers if bar does not work with >>>>>>>>>> X@R1. >>>>>>>>>> They expect X@R2 to be used. >>>>>>>>>> >>>>>>>>> I can easily construct cases where this may not be true nor >>>>>>>>> problematic. If we make the interpretation min-revision, I am sur= e >>>>>>>>> we >>>>>>>>> will regret it at some point in time >>>>>>>> >>>>>>>> I agree. The min-revision rule would be an unnecessary CLR. >>>>>>>> >>>>>>>> I asked before for an example of where the proposed solution is >>>>>>>> problematic, and where the min-revision would solve that. >>>>>>> >>>>>>> Here is a simple example that I find problematic. >>>>>>> This is what I mean by coding to the model. >>>>>>> The client developer adds code to augment a base node >>>>>>> if the port-knob-type is 'fastest' >>>>>>> >>>>>>> >>>>>>> module base { >>>>>>> ... >>>>>>> revision 2014-01-01; >>>>>>> typedef port-knob-type { >>>>>>> type enumeration { >>>>>>> enum fast; >>>>>>> enum faster; >>>>>>> } >>>>>>> } >>>>>>> list port-knob { >>>>>>> key name; >>>>>>> leaf name { type string; } >>>>>>> leaf knob-type { type port-knob-type; } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> module base { >>>>>>> ... >>>>>>> revision 2015-01-01; >>>>>>> typedef port-knob-type { >>>>>>> type enumeration { >>>>>>> enum fast; >>>>>>> enum faster; >>>>>>> enum fastest' // added new enum >>>>>>> } >>>>>>> } >>>>>>> list port-knob { >>>>>>> key name; >>>>>>> leaf name { type string; } >>>>>>> leaf knob-type { >>>>>>> type port-knob-type; >>>>>>> default fast; >>>>>>> >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> module aug1 { >>>>>>> ... >>>>>>> import base { >>>>>>> prefix b; >>>>>>> revision-date "2015-01-01"; >>>>>>> } >>>>>>> >>>>>>> augment b:/port-knob { >>>>>>> when "b:knob-type =3D 'faster'"; >>>>>>> leaf alt-knob-type { >>>>>>> type b:port-knob-type; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> augment b:/port-knob { >>>>>>> when "b:knob-type =3D 'fastest'"; >>>>>>> leaf boost-factor { type uint32; } >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> >>>>>>> >>>>>>> The 'aug1' developer clearly intends for the server to >>>>>>> support base@2015-01-01. >>>>>>> >>>>>>> But the vendor decides to advertise base@2014-01-01. >>>>>> >>>>>> Well, boost-factor is only relevant if b:knob-type is 'fastest'. So >>>>>> if the vendor advertises base@2014-01-01, b:knob-type can never be >>>>>> 'fastest'. I don't see any problem with this. >>>>>> >>>>>>> The 'port-knob' list is augmented with the new version >>>>>>> of the port-knob-type (if 'faster') even though the server implemen= ts >>>>>>> the old version. >>>>>>> >>>>>>> The ''boost-factor'' leaf will never augment the port-knob list >>>>>>> because server does not support the 'fastest' enum. >>>>>>> >>>>>>> This is more than just confusing, especially if the server >>>>>>> advertises that it conforms to the "aug1" module. >>>>>> >>>>>> It advertises that it *implements* aug1. >>>>>> >>>>> This is the problem. >>>>> If it does advertise "aug1", then it MUST advertise "not-supported" >>>>> deviations >>>>> for both leafs, because they both rely on the new revision of the >>>>> typedef, >>>>> and the server does not implement the new typedef. >>>> >>>> No, the definition of the augment for boost-factor does not strictly >>>> rely on the new revision of the typedef. It's just that the when >>>> expression will never evaluate to true if the newer version isn't >>>> implemented. >>> >>> But if a server advertises "aug1" the it is claiming that "aug1" is ful= ly >>> supported. Since =E2=80=98aug1' >> >> This is not sufficient, in order to decide whether =E2=80=9Caug1=E2=80= =9D is fully >> supported, =E2=80=9Cbase=E2=80=9D must be advertised, too, and the suppo= rted features as >> well. > > > Of course. "base" must be advertised. Though I don't think any "features= " > must be advertised. > By definition a feature is optional. > > The question is whether a server should be allowed to advertise > base@2014-01-01 and "aug1" at the same time. > > If we let a server implementation decide what "base" version that "aug1"= is > augmenting then a module > designer has no say about which "base" that his/her "aug1" must be based = on. > If so the module designer may have to design "aug1" in a way that is > base-version-agnostic. I am fine with that if that is > intention of the working group. > I strongly object to this new interpretation of YANG conformance. The designer should pick the modules and revisions of those modules that are required in order to claim compliance with the standard. If the designer says import base@2015-01-01 then that is what is required for compliance to module "aug1". > -Xiang Andy > > >> Lada >> >>> augments "base 2015-01-01", I would think that I must be able to set t= he >>> leaf "b:knob-type" >>> to the value "fastest" and then expect to be able to play with the >>> augmented "boost-factor" >>> leaf. If the server advertises only "base 2014-01-01", this would not = be >>> possible. Is this an >>> invalid scenario? >>> >>> Anyway, as I said earlier I agree with Y45-04 if no valid use-case >>> exists for 'min-revision-rule" >>> since that seems to be cleanest way to address the question we are tryi= ng >>> to address. >>> It is just different from what I thought originally that augmenting a >>> module via "import-by-revision" >>> implies the imported module version is the base of the augmenting and >>> hence it must be >>> supported first. >>> >>> --Xiang >>> >>> >>> >>>>>> I think Juergen has tried to say several times that what we're tryin= g >>>>>> to do is really to let the server advertise what it implements, and >>>>>> then add possibly more useful conformance functions later (maybe >>>>>> something like your packages). >>>>>> >>>>> This proposal does not let the client developer know what the server = is >>>>> supposed to implement. The conformance requirements are not very >>>>> precise. >>>> >>>> Agreed. This is why we want to address the conformance problem >>>> separately. Right now we try focus on what the different constructs >>>> really imply in terms of implementing other modules. >>>> >>>> >>>> /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 >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Apr 30 12:20:33 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6AE1ACDBD for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 12:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzwbKlmxpOXK for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 12:20:23 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4199D1A8B84 for <netmod@ietf.org>; Thu, 30 Apr 2015 12:20:23 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa06-04.prod.phx3.secureserver.net with id NKLM1q0074vySjM01KLMHU; Thu, 30 Apr 2015 12:20:22 -0700 Message-ID: <55428076.30109@seguesoft.com> Date: Thu, 30 Apr 2015 14:20:22 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Bierman <andy@yumaworks.com> References: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> <20150426.205033.1440726706036395955.mbj@tail-f.com> <554239D5.9030102@seguesoft.com> <EA7216C8-C7D6-440B-A5EE-5693B339D321@nic.cz> <5542671C.8090905@seguesoft.com> <CABCOCHQ=h5=OeqVD-xzvvKc0HYMrCnPOkaS77+hFF3gHmOXr=A@mail.gmail.com> In-Reply-To: <CABCOCHQ=h5=OeqVD-xzvvKc0HYMrCnPOkaS77+hFF3gHmOXr=A@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/at7hevLICU3l19xGIPn3A7dl4Ak> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 19:20:25 -0000 On 4/30/2015 12:45 PM, Andy Bierman wrote: > On Thu, Apr 30, 2015 at 10:32 AM, Xiang Li <xiangli@seguesoft.com> wrote: >> >> On 4/30/2015 11:15 AM, Ladislav Lhotka wrote: >>>> On 30 Apr 2015, at 16:19, Xiang Li <xiangli@seguesoft.com> wrote: >>>> >>>> >>>> >>>> On 4/26/2015 1:50 PM, Martin Bjorklund wrote: >>>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>>> On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> >>>>>> wrote: >>>>>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>>>>> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> >>>>>>>> wrote: >>>>>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>>> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >>>>>>>>>>> Let me try to explain my concern again... >>>>>>>>>>> >>>>>>>>>>> The authors of "bar" expect that module X rev 2 will be supported. >>>>>>>>>>> That is why they used import-by-revision. Mixing typedefs and >>>>>>>>>>> groupings from R2 and protocol accessible objects from R1 is not >>>>>>>>>>> what >>>>>>>>>>> they expect. They cannot possibly write their module "bar" >>>>>>>>>>> for every possible combination of down-rev X modules the vendor >>>>>>>>>>> may choose. >>>>>>>>>>> >>>>>>>>>>> It is not the fault of the designers if bar does not work with >>>>>>>>>>> X@R1. >>>>>>>>>>> They expect X@R2 to be used. >>>>>>>>>>> >>>>>>>>>> I can easily construct cases where this may not be true nor >>>>>>>>>> problematic. If we make the interpretation min-revision, I am sure >>>>>>>>>> we >>>>>>>>>> will regret it at some point in time >>>>>>>>> I agree. The min-revision rule would be an unnecessary CLR. >>>>>>>>> >>>>>>>>> I asked before for an example of where the proposed solution is >>>>>>>>> problematic, and where the min-revision would solve that. >>>>>>>> Here is a simple example that I find problematic. >>>>>>>> This is what I mean by coding to the model. >>>>>>>> The client developer adds code to augment a base node >>>>>>>> if the port-knob-type is 'fastest' >>>>>>>> >>>>>>>> >>>>>>>> module base { >>>>>>>> ... >>>>>>>> revision 2014-01-01; >>>>>>>> typedef port-knob-type { >>>>>>>> type enumeration { >>>>>>>> enum fast; >>>>>>>> enum faster; >>>>>>>> } >>>>>>>> } >>>>>>>> list port-knob { >>>>>>>> key name; >>>>>>>> leaf name { type string; } >>>>>>>> leaf knob-type { type port-knob-type; } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> module base { >>>>>>>> ... >>>>>>>> revision 2015-01-01; >>>>>>>> typedef port-knob-type { >>>>>>>> type enumeration { >>>>>>>> enum fast; >>>>>>>> enum faster; >>>>>>>> enum fastest' // added new enum >>>>>>>> } >>>>>>>> } >>>>>>>> list port-knob { >>>>>>>> key name; >>>>>>>> leaf name { type string; } >>>>>>>> leaf knob-type { >>>>>>>> type port-knob-type; >>>>>>>> default fast; >>>>>>>> >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> module aug1 { >>>>>>>> ... >>>>>>>> import base { >>>>>>>> prefix b; >>>>>>>> revision-date "2015-01-01"; >>>>>>>> } >>>>>>>> >>>>>>>> augment b:/port-knob { >>>>>>>> when "b:knob-type = 'faster'"; >>>>>>>> leaf alt-knob-type { >>>>>>>> type b:port-knob-type; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> augment b:/port-knob { >>>>>>>> when "b:knob-type = 'fastest'"; >>>>>>>> leaf boost-factor { type uint32; } >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> The 'aug1' developer clearly intends for the server to >>>>>>>> support base@2015-01-01. >>>>>>>> >>>>>>>> But the vendor decides to advertise base@2014-01-01. >>>>>>> Well, boost-factor is only relevant if b:knob-type is 'fastest'. So >>>>>>> if the vendor advertises base@2014-01-01, b:knob-type can never be >>>>>>> 'fastest'. I don't see any problem with this. >>>>>>> >>>>>>>> The 'port-knob' list is augmented with the new version >>>>>>>> of the port-knob-type (if 'faster') even though the server implements >>>>>>>> the old version. >>>>>>>> >>>>>>>> The ''boost-factor'' leaf will never augment the port-knob list >>>>>>>> because server does not support the 'fastest' enum. >>>>>>>> >>>>>>>> This is more than just confusing, especially if the server >>>>>>>> advertises that it conforms to the "aug1" module. >>>>>>> It advertises that it *implements* aug1. >>>>>>> >>>>>> This is the problem. >>>>>> If it does advertise "aug1", then it MUST advertise "not-supported" >>>>>> deviations >>>>>> for both leafs, because they both rely on the new revision of the >>>>>> typedef, >>>>>> and the server does not implement the new typedef. >>>>> No, the definition of the augment for boost-factor does not strictly >>>>> rely on the new revision of the typedef. It's just that the when >>>>> expression will never evaluate to true if the newer version isn't >>>>> implemented. >>>> But if a server advertises "aug1" the it is claiming that "aug1" is fully >>>> supported. Since ‘aug1' >>> This is not sufficient, in order to decide whether “aug1” is fully >>> supported, “base” must be advertised, too, and the supported features as >>> well. >> >> Of course. "base" must be advertised. Though I don't think any "features" >> must be advertised. >> By definition a feature is optional. >> >> The question is whether a server should be allowed to advertise >> base@2014-01-01 and "aug1" at the same time. >> >> If we let a server implementation decide what "base" version that "aug1" is >> augmenting then a module >> designer has no say about which "base" that his/her "aug1" must be based on. >> If so the module designer may have to design "aug1" in a way that is >> base-version-agnostic. I am fine with that if that is >> intention of the working group. >> > I strongly object to this new interpretation of YANG conformance. My understanding is that this is not about "YANG conformance" anymore. > The designer should pick the modules and revisions of those modules > that are required in order to claim compliance with the standard. > If the designer says import base@2015-01-01 then that is > what is required for compliance to module "aug1". > > Not if the implication of any compliance meaning is stripped away from "import-by-revision". In this case if a server advertises "aug1" then it does mean "aug1" is supported. But what's really available in "aug1"? You have to examine the "base" version advertised and any "features", (as shown in Lada's example) as well. In other words, the author of "aug1" will now have extra work to do since he/she can't assume which (minimum) base version implementation is available. I imagine lots of nodes in "aug1" will have to be made optional, using when/must/if-feature to determine the start point of an augment. --Xiang From nobody Thu Apr 30 12:33:54 2015 Return-Path: <andy@yumaworks.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9771A8AF9 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 12:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xydOj5f8FVQs for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 12:33:51 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 587F61A88BE for <netmod@ietf.org>; Thu, 30 Apr 2015 12:33:51 -0700 (PDT) Received: by layy10 with SMTP id y10so52097329lay.0 for <netmod@ietf.org>; Thu, 30 Apr 2015 12:33:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ymoahqpvvkw6tZss83MwlGxM0YjQkyElsWkhM37a7OM=; b=l17o4GaoWMEWJP+k0OeYNbRud0Xv0+izaqK/wguTLyclrx7tZWQ75BlGY9Hvuqk18y 1xu6kRRZPC+x5I65THm2q+AyWuvA9FbVxetrIGyILqT64Kztm+yWq8FSDRIZgiHLIy5f dTcuMQZ46BNdT/JVmLIHw6qVN/Y6d4D3QT/yUZMzC4YTG97XaSlXOPvYME+kHkKAcKYg RupkFNntiHilipyn5CLCyG8vM7S31GaGMaaK9UjUafnbycpeSrtj8z3DGsTHu8N8VJV1 veEJllwb2+CINIPHsYTkPjqEvg9TfFOMMm6qoIvZM81nkSKW+3IRRhyGlXJrKN8pI0Fc 7PLQ== X-Gm-Message-State: ALoCoQl716uT5q5c3+WBSg2YY8RB1J/WS6XVJMfXrerJO9msFBXf5mwpE/Zl2cSVJIkMmqf14cMn MIME-Version: 1.0 X-Received: by 10.152.87.164 with SMTP id az4mr5329227lab.123.1430422429728; Thu, 30 Apr 2015 12:33:49 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 30 Apr 2015 12:33:49 -0700 (PDT) In-Reply-To: <55428076.30109@seguesoft.com> References: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> <20150426.205033.1440726706036395955.mbj@tail-f.com> <554239D5.9030102@seguesoft.com> <EA7216C8-C7D6-440B-A5EE-5693B339D321@nic.cz> <5542671C.8090905@seguesoft.com> <CABCOCHQ=h5=OeqVD-xzvvKc0HYMrCnPOkaS77+hFF3gHmOXr=A@mail.gmail.com> <55428076.30109@seguesoft.com> Date: Thu, 30 Apr 2015 12:33:49 -0700 Message-ID: <CABCOCHTxdcAFEWogMxOL4zhQrEh7W_WcqkyxJLUYO7vDL2+q7Q@mail.gmail.com> From: Andy Bierman <andy@yumaworks.com> To: Xiang Li <xiangli@seguesoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/w_7QmmI8WH3nnHcp4cYXt8GKoBU> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 19:33:54 -0000 On Thu, Apr 30, 2015 at 12:20 PM, Xiang Li <xiangli@seguesoft.com> wrote: > > > On 4/30/2015 12:45 PM, Andy Bierman wrote: >> >> On Thu, Apr 30, 2015 at 10:32 AM, Xiang Li <xiangli@seguesoft.com> wrote= : >>> >>> >>> On 4/30/2015 11:15 AM, Ladislav Lhotka wrote: >>>>> >>>>> On 30 Apr 2015, at 16:19, Xiang Li <xiangli@seguesoft.com> wrote: >>>>> >>>>> >>>>> >>>>> On 4/26/2015 1:50 PM, Martin Bjorklund wrote: >>>>>> >>>>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>>>> >>>>>>> On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>>>>>> >>>>>>>>> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com= > >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >>>>>>>>>>>> >>>>>>>>>>>> Let me try to explain my concern again... >>>>>>>>>>>> >>>>>>>>>>>> The authors of "bar" expect that module X rev 2 will be >>>>>>>>>>>> supported. >>>>>>>>>>>> That is why they used import-by-revision. Mixing typedefs and >>>>>>>>>>>> groupings from R2 and protocol accessible objects from R1 is n= ot >>>>>>>>>>>> what >>>>>>>>>>>> they expect. They cannot possibly write their module "bar" >>>>>>>>>>>> for every possible combination of down-rev X modules the vendo= r >>>>>>>>>>>> may choose. >>>>>>>>>>>> >>>>>>>>>>>> It is not the fault of the designers if bar does not work with >>>>>>>>>>>> X@R1. >>>>>>>>>>>> They expect X@R2 to be used. >>>>>>>>>>>> >>>>>>>>>>> I can easily construct cases where this may not be true nor >>>>>>>>>>> problematic. If we make the interpretation min-revision, I am >>>>>>>>>>> sure >>>>>>>>>>> we >>>>>>>>>>> will regret it at some point in time >>>>>>>>>> >>>>>>>>>> I agree. The min-revision rule would be an unnecessary CLR. >>>>>>>>>> >>>>>>>>>> I asked before for an example of where the proposed solution is >>>>>>>>>> problematic, and where the min-revision would solve that. >>>>>>>>> >>>>>>>>> Here is a simple example that I find problematic. >>>>>>>>> This is what I mean by coding to the model. >>>>>>>>> The client developer adds code to augment a base node >>>>>>>>> if the port-knob-type is 'fastest' >>>>>>>>> >>>>>>>>> >>>>>>>>> module base { >>>>>>>>> ... >>>>>>>>> revision 2014-01-01; >>>>>>>>> typedef port-knob-type { >>>>>>>>> type enumeration { >>>>>>>>> enum fast; >>>>>>>>> enum faster; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> list port-knob { >>>>>>>>> key name; >>>>>>>>> leaf name { type string; } >>>>>>>>> leaf knob-type { type port-knob-type; } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> module base { >>>>>>>>> ... >>>>>>>>> revision 2015-01-01; >>>>>>>>> typedef port-knob-type { >>>>>>>>> type enumeration { >>>>>>>>> enum fast; >>>>>>>>> enum faster; >>>>>>>>> enum fastest' // added new enum >>>>>>>>> } >>>>>>>>> } >>>>>>>>> list port-knob { >>>>>>>>> key name; >>>>>>>>> leaf name { type string; } >>>>>>>>> leaf knob-type { >>>>>>>>> type port-knob-type; >>>>>>>>> default fast; >>>>>>>>> >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> module aug1 { >>>>>>>>> ... >>>>>>>>> import base { >>>>>>>>> prefix b; >>>>>>>>> revision-date "2015-01-01"; >>>>>>>>> } >>>>>>>>> >>>>>>>>> augment b:/port-knob { >>>>>>>>> when "b:knob-type =3D 'faster'"; >>>>>>>>> leaf alt-knob-type { >>>>>>>>> type b:port-knob-type; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> augment b:/port-knob { >>>>>>>>> when "b:knob-type =3D 'fastest'"; >>>>>>>>> leaf boost-factor { type uint32; } >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> The 'aug1' developer clearly intends for the server to >>>>>>>>> support base@2015-01-01. >>>>>>>>> >>>>>>>>> But the vendor decides to advertise base@2014-01-01. >>>>>>>> >>>>>>>> Well, boost-factor is only relevant if b:knob-type is 'fastest'. = So >>>>>>>> if the vendor advertises base@2014-01-01, b:knob-type can never be >>>>>>>> 'fastest'. I don't see any problem with this. >>>>>>>> >>>>>>>>> The 'port-knob' list is augmented with the new version >>>>>>>>> of the port-knob-type (if 'faster') even though the server >>>>>>>>> implements >>>>>>>>> the old version. >>>>>>>>> >>>>>>>>> The ''boost-factor'' leaf will never augment the port-knob list >>>>>>>>> because server does not support the 'fastest' enum. >>>>>>>>> >>>>>>>>> This is more than just confusing, especially if the server >>>>>>>>> advertises that it conforms to the "aug1" module. >>>>>>>> >>>>>>>> It advertises that it *implements* aug1. >>>>>>>> >>>>>>> This is the problem. >>>>>>> If it does advertise "aug1", then it MUST advertise "not-supported" >>>>>>> deviations >>>>>>> for both leafs, because they both rely on the new revision of the >>>>>>> typedef, >>>>>>> and the server does not implement the new typedef. >>>>>> >>>>>> No, the definition of the augment for boost-factor does not strictly >>>>>> rely on the new revision of the typedef. It's just that the when >>>>>> expression will never evaluate to true if the newer version isn't >>>>>> implemented. >>>>> >>>>> But if a server advertises "aug1" the it is claiming that "aug1" is >>>>> fully >>>>> supported. Since =E2=80=98aug1' >>>> >>>> This is not sufficient, in order to decide whether =E2=80=9Caug1=E2=80= =9D is fully >>>> supported, =E2=80=9Cbase=E2=80=9D must be advertised, too, and the sup= ported features as >>>> well. >>> >>> >>> Of course. "base" must be advertised. Though I don't think any >>> "features" >>> must be advertised. >>> By definition a feature is optional. >>> >>> The question is whether a server should be allowed to advertise >>> base@2014-01-01 and "aug1" at the same time. >>> >>> If we let a server implementation decide what "base" version that "aug= 1" >>> is >>> augmenting then a module >>> designer has no say about which "base" that his/her "aug1" must be base= d >>> on. >>> If so the module designer may have to design "aug1" in a way that is >>> base-version-agnostic. I am fine with that if that is >>> intention of the working group. >>> >> I strongly object to this new interpretation of YANG conformance. > > > My understanding is that this is not about "YANG conformance" anymore. > Sure it is. There are no other YANG conformance mechanisms other than the YANG language itself. If it is unclear which version of any module is required for implementation, then YANG is a failure. Import without revision says "any possible revision of this module that you can find is OK to use". If that is not the case, then an import-by-revision says "use this specific revision". If module "aug1" says use base@2015-01-01 and the server has to use that revision (or a newer version). >> The designer should pick the modules and revisions of those modules >> that are required in order to claim compliance with the standard. >> If the designer says import base@2015-01-01 then that is >> what is required for compliance to module "aug1". >> >> > > Not if the implication of any compliance meaning is stripped away from > "import-by-revision". > > In this case if a server advertises "aug1" then it does mean "aug1" is > supported. But what's > really available in "aug1"? You have to examine the "base" version > advertised and any "features", > (as shown in Lada's example) as well. > > In other words, the author of "aug1" will now have extra work to do sinc= e > he/she can't > assume which (minimum) base version implementation is available. I imagin= e > lots > of nodes in "aug1" will have to be made optional, using when/must/if-feat= ure > to determine > the start point of an augment. > I don't want to design "aug1" to work with every possible back-revision of the base module. What is the point of all this extra complexity? I need to be able to define API features that rely of specific data model functionality. The implementation requirements must be clear at module compile-time, not decided at server run-time. > --Xiang > Andy > > > From nobody Thu Apr 30 15:09:14 2015 Return-Path: <xiangli@seguesoft.com> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AB31A6F27 for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 15:09:13 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slbPt9ckSryY for <netmod@ietfa.amsl.com>; Thu, 30 Apr 2015 15:09:10 -0700 (PDT) Received: from p3plsmtpa07-09.prod.phx3.secureserver.net (p3plsmtpa07-09.prod.phx3.secureserver.net [173.201.192.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE5C1A86FC for <netmod@ietf.org>; Thu, 30 Apr 2015 15:09:10 -0700 (PDT) Received: from [192.168.2.33] ([73.8.162.228]) by p3plsmtpa07-09.prod.phx3.secureserver.net with id NN981q00N4vySjM01N99WZ; Thu, 30 Apr 2015 15:09:10 -0700 Message-ID: <5542A806.4070401@seguesoft.com> Date: Thu, 30 Apr 2015 17:09:10 -0500 From: Xiang Li <xiangli@seguesoft.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Bierman <andy@yumaworks.com> References: <CABCOCHSR5=xQQvVBRMZS1vHkZ9k1G_K_zsBbm--KsEk2OFTKwA@mail.gmail.com> <20150426.193211.1077355394949650317.mbj@tail-f.com> <CABCOCHS3qGCfSNk6gmSVg7SM+Qp32ijQEZh=kQ2ibO-aHQfJaA@mail.gmail.com> <20150426.205033.1440726706036395955.mbj@tail-f.com> <554239D5.9030102@seguesoft.com> <EA7216C8-C7D6-440B-A5EE-5693B339D321@nic.cz> <5542671C.8090905@seguesoft.com> <CABCOCHQ=h5=OeqVD-xzvvKc0HYMrCnPOkaS77+hFF3gHmOXr=A@mail.gmail.com> <55428076.30109@seguesoft.com> <CABCOCHTxdcAFEWogMxOL4zhQrEh7W_WcqkyxJLUYO7vDL2+q7Q@mail.gmail.com> In-Reply-To: <CABCOCHTxdcAFEWogMxOL4zhQrEh7W_WcqkyxJLUYO7vDL2+q7Q@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/uVoC5pZcQh9ie51F2RjYhJgylpk> Cc: "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Y45 wrap up X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list <netmod.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/netmod/> List-Post: <mailto:netmod@ietf.org> List-Help: <mailto:netmod-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2015 22:09:13 -0000 On 4/30/2015 2:33 PM, Andy Bierman wrote: > On Thu, Apr 30, 2015 at 12:20 PM, Xiang Li <xiangli@seguesoft.com> wrote: >> >> On 4/30/2015 12:45 PM, Andy Bierman wrote: >>> On Thu, Apr 30, 2015 at 10:32 AM, Xiang Li <xiangli@seguesoft.com> wrote: >>>> >>>> On 4/30/2015 11:15 AM, Ladislav Lhotka wrote: >>>>>> On 30 Apr 2015, at 16:19, Xiang Li <xiangli@seguesoft.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 4/26/2015 1:50 PM, Martin Bjorklund wrote: >>>>>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>>>>> On Sun, Apr 26, 2015 at 10:32 AM, Martin Bjorklund <mbj@tail-f.com> >>>>>>>> wrote: >>>>>>>>> Andy Bierman <andy@yumaworks.com> wrote: >>>>>>>>>> On Fri, Apr 24, 2015 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> >>>>>>>>>> wrote: >>>>>>>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> >>>>>>>>>>> wrote: >>>>>>>>>>>> On Thu, Apr 23, 2015 at 12:28:13PM -0700, Andy Bierman wrote: >>>>>>>>>>>>> Let me try to explain my concern again... >>>>>>>>>>>>> >>>>>>>>>>>>> The authors of "bar" expect that module X rev 2 will be >>>>>>>>>>>>> supported. >>>>>>>>>>>>> That is why they used import-by-revision. Mixing typedefs and >>>>>>>>>>>>> groupings from R2 and protocol accessible objects from R1 is not >>>>>>>>>>>>> what >>>>>>>>>>>>> they expect. They cannot possibly write their module "bar" >>>>>>>>>>>>> for every possible combination of down-rev X modules the vendor >>>>>>>>>>>>> may choose. >>>>>>>>>>>>> >>>>>>>>>>>>> It is not the fault of the designers if bar does not work with >>>>>>>>>>>>> X@R1. >>>>>>>>>>>>> They expect X@R2 to be used. >>>>>>>>>>>>> >>>>>>>>>>>> I can easily construct cases where this may not be true nor >>>>>>>>>>>> problematic. If we make the interpretation min-revision, I am >>>>>>>>>>>> sure >>>>>>>>>>>> we >>>>>>>>>>>> will regret it at some point in time >>>>>>>>>>> I agree. The min-revision rule would be an unnecessary CLR. >>>>>>>>>>> >>>>>>>>>>> I asked before for an example of where the proposed solution is >>>>>>>>>>> problematic, and where the min-revision would solve that. >>>>>>>>>> Here is a simple example that I find problematic. >>>>>>>>>> This is what I mean by coding to the model. >>>>>>>>>> The client developer adds code to augment a base node >>>>>>>>>> if the port-knob-type is 'fastest' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> module base { >>>>>>>>>> ... >>>>>>>>>> revision 2014-01-01; >>>>>>>>>> typedef port-knob-type { >>>>>>>>>> type enumeration { >>>>>>>>>> enum fast; >>>>>>>>>> enum faster; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> list port-knob { >>>>>>>>>> key name; >>>>>>>>>> leaf name { type string; } >>>>>>>>>> leaf knob-type { type port-knob-type; } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> module base { >>>>>>>>>> ... >>>>>>>>>> revision 2015-01-01; >>>>>>>>>> typedef port-knob-type { >>>>>>>>>> type enumeration { >>>>>>>>>> enum fast; >>>>>>>>>> enum faster; >>>>>>>>>> enum fastest' // added new enum >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> list port-knob { >>>>>>>>>> key name; >>>>>>>>>> leaf name { type string; } >>>>>>>>>> leaf knob-type { >>>>>>>>>> type port-knob-type; >>>>>>>>>> default fast; >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> module aug1 { >>>>>>>>>> ... >>>>>>>>>> import base { >>>>>>>>>> prefix b; >>>>>>>>>> revision-date "2015-01-01"; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> augment b:/port-knob { >>>>>>>>>> when "b:knob-type = 'faster'"; >>>>>>>>>> leaf alt-knob-type { >>>>>>>>>> type b:port-knob-type; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> augment b:/port-knob { >>>>>>>>>> when "b:knob-type = 'fastest'"; >>>>>>>>>> leaf boost-factor { type uint32; } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The 'aug1' developer clearly intends for the server to >>>>>>>>>> support base@2015-01-01. >>>>>>>>>> >>>>>>>>>> But the vendor decides to advertise base@2014-01-01. >>>>>>>>> Well, boost-factor is only relevant if b:knob-type is 'fastest'. So >>>>>>>>> if the vendor advertises base@2014-01-01, b:knob-type can never be >>>>>>>>> 'fastest'. I don't see any problem with this. >>>>>>>>> >>>>>>>>>> The 'port-knob' list is augmented with the new version >>>>>>>>>> of the port-knob-type (if 'faster') even though the server >>>>>>>>>> implements >>>>>>>>>> the old version. >>>>>>>>>> >>>>>>>>>> The ''boost-factor'' leaf will never augment the port-knob list >>>>>>>>>> because server does not support the 'fastest' enum. >>>>>>>>>> >>>>>>>>>> This is more than just confusing, especially if the server >>>>>>>>>> advertises that it conforms to the "aug1" module. >>>>>>>>> It advertises that it *implements* aug1. >>>>>>>>> >>>>>>>> This is the problem. >>>>>>>> If it does advertise "aug1", then it MUST advertise "not-supported" >>>>>>>> deviations >>>>>>>> for both leafs, because they both rely on the new revision of the >>>>>>>> typedef, >>>>>>>> and the server does not implement the new typedef. >>>>>>> No, the definition of the augment for boost-factor does not strictly >>>>>>> rely on the new revision of the typedef. It's just that the when >>>>>>> expression will never evaluate to true if the newer version isn't >>>>>>> implemented. >>>>>> But if a server advertises "aug1" the it is claiming that "aug1" is >>>>>> fully >>>>>> supported. Since ‘aug1' >>>>> This is not sufficient, in order to decide whether “aug1” is fully >>>>> supported, “base” must be advertised, too, and the supported features as >>>>> well. >>>> >>>> Of course. "base" must be advertised. Though I don't think any >>>> "features" >>>> must be advertised. >>>> By definition a feature is optional. >>>> >>>> The question is whether a server should be allowed to advertise >>>> base@2014-01-01 and "aug1" at the same time. >>>> >>>> If we let a server implementation decide what "base" version that "aug1" >>>> is >>>> augmenting then a module >>>> designer has no say about which "base" that his/her "aug1" must be based >>>> on. >>>> If so the module designer may have to design "aug1" in a way that is >>>> base-version-agnostic. I am fine with that if that is >>>> intention of the working group. >>>> >>> I strongly object to this new interpretation of YANG conformance. >> >> My understanding is that this is not about "YANG conformance" anymore. >> > Sure it is. > There are no other YANG conformance mechanisms other than > the YANG language itself. True. But as I understand it is going to to addressed further separately and (possibly) use something like "package" you proposed? > Import without revision says "any possible revision of this module > that you can find is OK to use". > > If that is not the case, then an import-by-revision says > "use this specific revision". > > If module "aug1" says use base@2015-01-01 and the > server has to use that revision (or a newer version). > Sure... and for the purpose of augment, I agree and prefer that we use "augment by the min-revision-policy" . But this assigns overloaded meanings for "import-by-revision". For typedefs the data nodes in the imported module are not required to be implemented. For augment, they are. It is my understanding that this double meaning is potentially very confusing to people and have some side-effects so Juregen/Lada/Martin want to avoid it. > >>> The designer should pick the modules and revisions of those modules >>> that are required in order to claim compliance with the standard. >>> If the designer says import base@2015-01-01 then that is >>> what is required for compliance to module "aug1". >>> >>> >> Not if the implication of any compliance meaning is stripped away from >> "import-by-revision". >> >> In this case if a server advertises "aug1" then it does mean "aug1" is >> supported. But what's >> really available in "aug1"? You have to examine the "base" version >> advertised and any "features", >> (as shown in Lada's example) as well. >> >> In other words, the author of "aug1" will now have extra work to do since >> he/she can't >> assume which (minimum) base version implementation is available. I imagine >> lots >> of nodes in "aug1" will have to be made optional, using when/must/if-feature >> to determine >> the start point of an augment. >> > I don't want to design "aug1" to work with every possible back-revision > of the base module. What is the point of all this extra complexity? While I don't think you have to design "aug1" to work with every possible back-revision of the base module, and also not sure how much extra complexity it can add, I do agree this may put more burden on the developer of "aug1". > The implementation requirements must be clear > at module compile-time, not decided at server run-time. > I tend to agree. That's why I prefer augment-min-revision-policy you proposed: 1) For typedefs, "import by revision" does not mean a server to support imported module (implement its data nodes) at all 2) For augment, "import by revision" does require the base revision (or a newer revision) of an imported module to be supported. --Xiang